Comment2018年は1つしかアプリを作成しませんでしたが、新しいことに挑戦した学びの多い年でもありました。そんな技術のメモをとっていたのですが、規模が小さくてブログ記事にできないものがあったので今回まとめることにしました。関連記事は以下の2つ。2018年はwebアプリやハイブリッドアプリの知識を高めました。ハイブリッドアプリ制作メモランチナビというハイブリッドアプリの制作を通して学んだことのメモ。webアプリよりも制限が少なく制作は比較的容易な気がします。ブラウザアプリの制作で得た知見2014年にスマホ向けに作成したアプリをブラウザゲームに改造しました。この制作過程で得た知見や思ったことなどをここにメモしておきます。アプリ以外ではホームページも更新しました。DESIGNDRILL.jpスマホ向けの弾幕ゲームや脱出ゲームを作っています。ブラウザゲームも作っていきたい!あとはvue.jsを学びました。これはランチナビの制作にも役立っています。自分用のメモなので分かりにくいかもしれませんが、私はこういうメモを作成しながら学ぶのが好きです。暗記するのではなく「思い出すためのメモ」といった感じです。vue.js:自習メモ独学でvue.jsを覚えるよ!。実習ファイルをまとめたページで、勉強内容はサンプルhtmlのソース内にコメントで記述しているよ。swiftとkotlinランチナビではネイティブ側の処理をswiftとkotlinで記述しました。Nullable)が印象的でしたが個人的にはメリットを感じませんでした(素直にクラッシュした方がバグを探しやすい)。データベースと連動した処理では「Nullが正解(フォームで未必須)」のケースもあり、その処理をシンプルかつ安全に実行できたりするらしいです。技術的には以下のサイトが詳しいです。→参考:SwiftのOptional型を極める→参考:【Swift】Optional型を安全にunwrapしよう両言語とも思想は同じだけど、微妙に構文が違うので混乱してしまう。いうことで以下の比較サイトをメモ。個人的にはOptional/Nullableに馴染めずアンラップを多用してました。Swift、Kotlinの構文比較編swiftの強制アンラップは「!」だけど、型指定で利用すると「暗黙的アンラップ」になる。Unwrappingkotlinの強制アンラップはswiftと異なり「!!」。swiftの暗黙的アンラップはkotlinには無いけれど「lateinit」で代用できる。Optionalswiftにはエルビス演算子は無いけれど「??」で代用できる。次は少しハマった問題のメモ。・Mac版SafariでGoogleFontの太さが正確に表示されない・Androidで位置を測定できない端末があった・iPad画面方向設定の落とし穴Mac版safariのGoogleFont対応ホームページの見出しにGoogleFontを利用したのですが、Mac版のsafariでフォントの太さが正しく表示されない問題に遭遇しました。overflowのおかげ。update」の項目。sfari以外のブラウザでは単一のweightしか読み込んでいないとweightの指定をしなくても表示されます。safariではそれでも指定しなければいけません。100のみを読み込んでいます。1つのweightしか読み込んでいないから指定する必要は無いと思っていたのですが、以下の様にweightを指定しないとmac版のsafariでは異なったweight?で表示されてしまいます。※ちなみにiOSのsafariでは指定しなくてもOKでした。動作的にはsafariが正解なのでしょう、他のブラウザは「気を利かせた」感じだと思います(たぶん)。いうことでGoogleFontは単一のweightしか利用しない場合でもcssで設定しましょう。Androidの位置測定は2種類平行でランチナビの動作確認でNexus7(Android6)は位置測定ができたのに、P20lite(Android8)は位置測定ができませんでした。Androidの位置測定は精度の高いPGSを利用したものと、精度が低めのWifiを利用したものの2種類があります。GPSが利用できるかを確認して利用できるならGPSでの測位を開始という処理を書くわけです。「GPSが使えること=GPSで測位できること」ではないのです。いうことで両方の処理を実行して測位できた値を利用する仕組みにしなければなりません。以下サイトのおかげで解決できました。→参考:位置情報取得でonLocationChangedが呼ばれない現象を改善するwebアプリでブラウザからGPSを使う場合は緯度経度の値を1回取得して処理が終わるのですが、ネイティブアプリでは位置が移動したら処理されるような仕組みになっています。ナビ系のアプリも作成できるのですが、もし1回取得して終わりたい場合はlocationManagerに対してremoveUpdatesをする必要があります。removeUpdatesちなみにiOSはGPSとwifiの処理は分かれていないので問題は発生せず、比較的容易に実装できました。参考になったのは以下のサイト。今年はアプリのiPad対応作業をしました。このときにiPadの画面方向が設定できなくてハマったのでメモ。以下のサイトが参考になったのですが、画像がリンク切れしているので補足。→参考:アプリの画面を縦固定や横固定に設定する方法(ユニバーサルアプリの注意点)iPhoneとiPadの両方に対応したアプリはUniversalアプリと呼ばれ、下図のようにDeviceにUniversalを選択して画面方向を設定します(画像ではPortraitのみ)。これでiPhoneとiPadの両方の設定が完了すると思ったら違うのです!。DeviceをiPadに選択し直して、ここでも「portrait」に設定しないといけません。本当にナゾ仕様です...。Universalならまとめて設定してくれればよいのに。機会があったら使ってみるもの今年は使わなかったけれど機会があったら使ってみたいもの。・外部svgファイルのアニメに再挑戦JavascriptInterfaceを利用したkotlinとwebviewとの連携ランチナビではwebView(javaScript)からネイティブ側の処理を実行するためにonJsAlertを利用しています。以下のサイトが詳しいです。→参考:[Android][Kotlin]JavaScriptと相互通信しかし2014年にjavaでハイブリッドアプリを作成した際には別な方法を使っていた気がします。いうことで調べたらJavascriptInterfaceというのが見つかりました。結局Alertをつかうのか...。相互呼び出し比較的自由にネイティブ側にアクセスできるので、公式サイトで少し注意書きがありました。自分で作成したhtmlデータしか使わないのであれば大丈夫だと思うけれど。addJavascriptInterfaceちなみにiOS(swift)でのWebViewとの相互通信はこちらを利用しました。lazyという仕組みを知って便利に使わせてもらいまた。所定の関数外で初期化できるので、関数を跨いだ変数を簡単に定義できます(下図ではwebViewの設定で利用しています)。1番目のリンクはシンプルなサンプルで説明しているサイトで、2番目はkotlin公式サイトでの説明。委譲プロパティこの段階でiOS版のランチナビはリリース済みだったのでiOSではlazyな仕組みは利用しませんでした。調べるとswiftでもlazyの仕組みはあるのでメモ。→参考:kotlinとの構文比較webアプリでも方向固定ハイブリッドアプリでは画面方向の固定は簡単。webアプリでもPWA(Android)なら固定は可能。webアプリは固定できない...と思っていたのですが情報があったのでメモ。→参考:スマホを横にした時、横表示を無効にしたい外部svgファイルのアニメに再挑戦リッチなマイクロインタラクションにはsvgが重要になってくると考えています。外部svgはほとんどのブラウザでcssで操作できないため、内部にタグとして記述する必要があります。ランチナビのトップメニューもsvgで作成されています。GPSと経路検索モックは一旦完成。あとでブログにまとめる。スイッチOFFのグレーはやめて中抜きにした。svgアイコンはcssで操作できるようにhtml内に組み込んだ。2018年7月22日シンプルな演出でさえ上記の通りなので、複雑なものは考えられない...。javascriptを使えばある程度操作できたっけ?2017年にいろいろ試したけれど、ほとんど忘れたので再挑戦しなければいけないかもしれない。svg検索結果その他(Android編)Androidの細々としたメモ。AppCompatActivityでフルスクリーンは面倒Androidでアプリを作成するときは基礎的なUIを利用できる「AppCompatActivity」を継承するのが普通らしい。ゲームではAndroidのUIは邪魔なので、もっと上流のActivityを使う(Cocos2d-xでも利用してる)。以下のサイトではAppCompatActivityでのフルスクリーン(基礎的なUIの除去)に挑戦していて逆説的にUIを理解できる(気がするのでメモ)。するAndroid6からのパーミッション処理AndroidだけでなくiOSもだけど、「位置情報」や「画像の保存」といったプライベートに関わるような処理は使う前にユーザーに許可をとる。Android6以前はインストール時にダイアログが表示されたけど、Android6以降は利用するときにダイアログを表示するように開発者が作成する必要があります。これ初回起動時ではなく最初に機能を使う時に確認することが推奨されている。いうことでランチナビは「serchボタン」をタップした時に確認のダイアログを表示しています。この処理がAndroidは非常に面倒だったので様々なサイトを参考にしました。→参考:辛すぎるAndroidのApp開発を、Kotlinとコルーチンで楽にするその他(iOS編)iOSの細々としたメモ。iPhoneXのセーフエリアiPhoneX以前は画面上部のみセーフエリアがありました。iPhoneX以降は画面下部のホームインジケータが追加されたため下部にもセーフエリアが存在します。コードで取得してSafeAreaに対応するちなみにiPhoneXでもstatusBarFrameを利用した画面上部のセーフエリアの取得はできる。回転させるとレイアウトが狂う問題iPhoneXの回転処理時にレイアウトが崩れる場合があるらしいのでメモ。CSS側の設定やWKWebViewの利用で対応するらしい。ランチナビは縦画面固定なので関係ありませんでした。X対応させる際のハマりどころなどデフォルトで2つのstoryboardxcodeの以前のバージョンではデフォルトのstorybordは1つだけだったと思う。今では2つあり間違えてしまったのでメモ。下図でMain.storybordとLaunchScreen.storybordの2種類がある(ってことは以前は必須だったランチ画面も削除できたりするのかな?)。階層フォルダと整理用フォルダ上図のついで。xcodeのフォルダは青と黄色の2種類ありますが、htmlを移植した際に間違えたのでメモ。references(青フォルダ)を選択する。groups(黄フォルダ)では階層が解除されてしまう。来年は2019年にはアプリではなくゲームをリリースしていく予定です。弾幕ゲームと脱出ゲームを作る予定ですが、年間を等して継続的にステージを追加する形に挑戦する予定です。詳細は来年のブログに書く予定です。それでは皆さま良い年を!twitterを本格的に初めてみた。ブログの更新記事をつぶやくのがメイン。あとCocos2dやUnity、その他アプリ開発に関連するツイッターの方をフォローして情報も集められたらなぁと思います。コメントをキャンセルメールアドレスが公開されることはありません。