2018年:技術的なメモ達

投稿者: | 2018年12月30日

2018年は1つしかアプリを作成しませんでしたが、新しいことに挑戦した学びの多い年でもありました。そんな技術のメモをとっていたのですが、規模が小さくてブログ記事にできないものがあったので今回まとめることにしました。

関連記事は以下の2つ。2018年はwebアプリやハイブリッドアプリの知識を高めました。

ハイブリッドアプリ制作メモ

ランチナビというハイブリッドアプリの制作を通して学んだことのメモ。webアプリよりも制限が少なく制作は比較的容易な気がします。

ブラウザアプリの制作で得た知見

2014年にスマホ向けに作成したアプリをブラウザゲームに改造しました。この制作過程で得た知見や思ったことなどをここにメモしておきます。

アプリ以外ではホームページも更新しました。

DESIGNDRILL.jp

スマホ向けの弾幕ゲームや脱出ゲームを作っています。ブラウザゲームも作っていきたい!

あとはvue.jsを学びました。これはランチナビの制作にも役立っています。自分用のメモなので分かりにくいかもしれませんが、私はこういうメモを作成しながら学ぶのが好きです。暗記するのではなく「思い出すためのメモ」といった感じです。

vue.js:自習メモ

独学でvue.jsを覚えるよ!。実習ファイルをまとめたページで、勉強内容はサンプルhtmlのソース内にコメントで記述しているよ。


 
 
 
 

swiftとkotlin

ランチナビではネイティブ側の処理をswiftとkotlinで記述しました。両方ともNull対応(Optional / Nullable)が印象的でしたが個人的にはメリットを感じませんでした(素直にクラッシュした方がバグを探しやすい)。

しかしデータベースと連動した処理では「Nullが正解(フォームで未必須)」のケースもあり、その処理をシンプルかつ安全に実行できたりするらしいです。技術的には以下のサイトが詳しいです。
→参考:SwiftのOptional型を極める
→参考:【Swift】Optional型を安全にunwrapしよう

 

両言語とも思想は同じだけど、微妙に構文が違うので混乱してしまう。ということで以下の比較サイトをメモ。個人的にはOptional/Nullableに馴染めずアンラップを多用してました。なのでアンラップ系のメモばかり…
→参考:iOSエンジニアのAndroidアプリ開発備忘録 – Swift、Kotlinの構文比較編

swiftの強制アンラップは「!」だけど、型指定で利用すると「暗黙的アンラップ」になる。
→参考: Forced Unwrapping

kotlinの強制アンラップはswiftと異なり「!!」。swiftの暗黙的アンラップはkotlinには無いけれど「lateinit」で代用できる。
→参考:暗黙的アンラップ・Implicitly Unwrapped Optional

swiftにはエルビス演算子は無いけれど「??」で代用できる。
→参考:Nil Coalescing Operator

 

 

ハマった問題

次は少しハマった問題のメモ。以下の3件。
Mac版SafariでGoogleFontの太さが正確に表示されない
Androidで位置を測定できない端末があった
iPad画面方向設定の落とし穴

Mac版safariのGoogleFont対応

ホームページの見出しにGoogleFontを利用したのですが、Mac版のsafariでフォントの太さが正しく表示されない問題に遭遇しました。
解決できたのは以下のStack overflowのおかげ。
→参考:Google Font not working on Safari

色々議論されていますが解決につながるのは「A 2018 update」の項目。sfari以外のブラウザでは単一のweightしか読み込んでいないとweightの指定をしなくても表示されます。しかしsafariではそれでも指定しなければいけません。私の場合は以下の様に「Lato」というフォントのweight 100のみを読み込んでいます。

122901

1つのweightしか読み込んでいないから指定する必要は無いと思っていたのですが、以下の様にweightを指定しないとmac版のsafariでは異なったweight?で表示されてしまいます。
※ちなみにiOSのsafariでは指定しなくてもOKでした。

122902

動作的にはsafariが正解なのでしょう、他のブラウザは「気を利かせた」感じだと思います(たぶん)。ということでGoogleFontは単一のweightしか利用しない場合でもcssで設定しましょう

 

Androidの位置測定は2種類平行で

ランチナビの動作確認でNexus7(Android6)は位置測定ができたのに、P20lite(Android8)は位置測定ができませんでした。Androidの位置測定は精度の高いPGSを利用したものと、精度が低めのWifiを利用したものの2種類があります。なので、まずGPSが利用できるかを確認して利用できるならGPSでの測位を開始という処理を書くわけです。

しかし「GPSが使えること=GPSで測位できること」ではないのです。ということで両方の処理を実行して測位できた値を利用する仕組みにしなければなりません。以下サイトのおかげで解決できました。
→参考:位置情報取得でonLocationChangedが呼ばれない現象を改善する

122903

webアプリでブラウザからGPSを使う場合は緯度経度の値を1回取得して処理が終わるのですが、ネイティブアプリでは位置が移動したら処理されるような仕組みになっています。なのでナビ系のアプリも作成できるのですが、もし1回取得して終わりたい場合はlocationManagerに対してremoveUpdatesをする必要があります。

→参考:Android developer : LocationManager – removeUpdates

ちなみにiOSはGPSとwifiの処理は分かれていないので問題は発生せず、比較的容易に実装できました。参考になったのは以下のサイト。
→参考:【iOS 11対応】知っておきたい位置情報周りの変更点
→参考:[Swift] 位置情報の利用許可

 

iPad画面方向設定の落とし穴

今年はアプリのiPad対応作業をしました。このときにiPadの画面方向が設定できなくてハマったのでメモ。以下のサイトが参考になったのですが、画像がリンク切れしているので補足。

→参考:アプリの画面を縦固定や横固定に設定する方法(ユニバーサルアプリの注意点)

iPhoneとiPadの両方に対応したアプリはUniversalアプリと呼ばれ、下図のようにDeviceにUniversalを選択して画面方向を設定します(画像ではPortraitのみ)。これでiPhoneとiPadの両方の設定が完了すると思ったら違うのです!。DeviceをiPadに選択し直して、ここでも「portrait」に設定しないといけません。本当にナゾ仕様です…。Universalならまとめて設定してくれればよいのに。

123004 

 
 

機会があったら使ってみるもの

今年は使わなかったけれど機会があったら使ってみたいもの。以下の4件。
JavascriptInterfaceを利用したkotlinとwebviewとの連携
Swiftにもlazyあった
webアプリでも方向固定
外部svgファイルのアニメに再挑戦

JavascriptInterfaceを利用したkotlinとwebviewとの連携

ランチナビではwebView(javaScript)からネイティブ側の処理を実行するためにonJsAlertを利用しています。以下のサイトが詳しいです。
→参考:[Android][Kotlin]JavaScriptと相互通信

しかし2014年にjavaでハイブリッドアプリを作成した際には別な方法を使っていた気がします。ということで調べたらJavascriptInterfaceというのが見つかりました。でも結局Alertをつかうのか…。

→参考:Crosswalk WebView でNativeメソッド と JavaScript 相互呼び出し

比較的自由にネイティブ側にアクセスできるので、公式サイトで少し注意書きがありました。自分で作成したhtmlデータしか使わないのであれば大丈夫だと思うけれど。念のため。
→参考:Android developer : webview- addJavascriptInterface

ちなみにiOS(swift)でのWebViewとの相互通信はこちらを利用しました。
→参考:[iOS][Swift]JavaScriptと相互通信

 

Swiftにもlazyあった

kotlinの勉強中にby lazyという仕組みを知って便利に使わせてもらいまた。所定の関数外で初期化できるので、関数を跨いだ変数を簡単に定義できます(下図ではwebViewの設定で利用しています)。1番目のリンクはシンプルなサンプルで説明しているサイトで、2番目はkotlin公式サイトでの説明。
→参考:Kotlinのlazyを使ってみた
→参考:kotlin – 委譲プロパティ

122904

この段階でiOS版のランチナビはリリース済みだったのでiOSではlazyな仕組みは利用しませんでした。調べるとswiftでもlazyの仕組みはあるのでメモ。構文は結構異なる。
→参考:【Swift4.1】lazyプロパティの使い所
→参考:kotlinとの構文比較

 

webアプリでも方向固定

ハイブリッドアプリでは画面方向の固定は簡単。webアプリでもPWA(Android)なら固定は可能。しかしwebアプリは固定できない…と思っていたのですが情報があったのでメモ。
→参考:スマホを横にした時、横表示を無効にしたい

 

外部svgファイルのアニメに再挑戦

リッチなマイクロインタラクションにはsvgが重要になってくると考えています。しかし外部svgはほとんどのブラウザでcssで操作できないため、内部にタグとして記述する必要があります。ランチナビのトップメニューもsvgで作成されています。

シンプルな演出でさえ上記の通りなので、複雑なものは考えられない…。しかしjavascriptを使えばある程度操作できたっけ?2017年にいろいろ試したけれど、ほとんど忘れたので再挑戦しなければいけないかもしれない。けど来年はゲーム制作がメインなので機会は少ないか?
→参考:DesignDrillDiary – svg検索結果

 
 
 

その他(Android編)

Androidの細々としたメモ。

AppCompatActivityでフルスクリーンは面倒

Androidでアプリを作成するときは基礎的なUIを利用できる「AppCompatActivity」を継承するのが普通らしい。しかしゲームではAndroidのUIは邪魔なので、もっと上流のActivityを使う(Cocos2d-xでも利用してる)。以下のサイトではAppCompatActivityでのフルスクリーン(基礎的なUIの除去)に挑戦していて逆説的にUIを理解できる(気がするのでメモ)。
→参考:[Android] アプリのタイトルバーを非表示、全画面表示にする

Android6からのパーミッション処理

AndroidだけでなくiOSもだけど、「位置情報」や「画像の保存」といったプライベートに関わるような処理は使う前にユーザーに許可をとる。Android6以前はインストール時にダイアログが表示されたけど、Android6以降は利用するときにダイアログを表示するように開発者が作成する必要があります。

これ初回起動時ではなく最初に機能を使う時に確認することが推奨されている。ということでランチナビは「serchボタン」をタップした時に確認のダイアログを表示しています。

この処理がAndroidは非常に面倒だったので様々なサイトを参考にしました。
→参考:Marshmallow でやってきたパーミッション要求まわりを1つのフラグメントにまとめてみた
→参考:kotlinで実行時パーミッションを実装する方法
→参考:辛すぎるAndroidのApp開発を、Kotlinとコルーチンで楽にする

 
 

その他(iOS編)

iOSの細々としたメモ。

iPhoneXのセーフエリア

iPhoneX以前は画面上部のみセーフエリアがありました。しかしiPhoneX以降は画面下部のホームインジケータが追加されたため下部にもセーフエリアが存在します。

→参考:[iPhone] safeAreaInsets をコードで取得してSafeAreaに対応する

ちなみにiPhoneXでもstatusBarFrameを利用した画面上部のセーフエリアの取得はできる。

123001
 

回転させるとレイアウトが狂う問題

iPhoneXの回転処理時にレイアウトが崩れる場合があるらしいのでメモ。CSS側の設定やWKWebViewの利用で対応するらしい。ランチナビは縦画面固定なので関係ありませんでした。

→参考:WebViewアプリをiPhone X対応させる際のハマりどころなど

 

デフォルトで2つのstoryboard

xcodeの以前のバージョンではデフォルトのstorybordは1つだけだったと思う。しかし今では2つあり間違えてしまったのでメモ。下図でMain.storybordとLaunchScreen.storybordの2種類がある(ってことは以前は必須だったランチ画面も削除できたりするのかな?)。

0822_1

階層フォルダと整理用フォルダ

上図のついで。xcodeのフォルダは青と黄色の2種類ありますが、htmlを移植した際に間違えたのでメモ。Resourcesにhtml関連のフォルダをドラッグする際にはCreate folder references(青フォルダ)を選択する。Create groups(黄フォルダ)では階層が解除されてしまう。

 
 

来年は

2019年にはアプリではなくゲームをリリースしていく予定です。弾幕ゲームと脱出ゲームを作る予定ですが、年間を等して継続的にステージを追加する形に挑戦する予定です。詳細は来年のブログに書く予定です。それでは皆さま良い年を!

 

 
 
 


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

Time limit is exhausted. Please reload the CAPTCHA.