React Nativeアプリ開発の覚書
本記事は覚書になります。
React Nativeアプリの開発で思ったこと、考えたことを忘れないようにメモしたものです。
しっかり調査や整理をしたものではないため、チラ裏程度にどうぞ。
これ以降の覚書はこっちで↓
Expo、React Native Cli
Expoはフレームワーク、React Native Cliはライブラリという印象。
フレームワークが好きかライブラリが好きかでどっちが好みか分かれるように思う。
Expo
Expoの場合、ライブラリ管理にExpoを経由することが多い。
Expo側でしっかり各ライブラリの整合性を見てくれているのか、たまたま引っ掛からなかっただけなのか、特に何か新しく入れて動かなくなったということはなかったように思う。
ただ、フレームワークの常というべきか、やっぱりExpo側で用意したレールにしっかり乗る必要がある。
個人的に一番ネックだったのはビルドをクラウドで行うところ。
しっかり調査したわけではないけど、どうにもExpoでやる場合はクラウド上でビルドを行うのが基本らしい。
その辺りもすべてExpoのフレームワークにマスクされているため、どうにも何をしているか分かりにくく感じる。
私がフレームワーク苦手人間だから悪い印象を感じているだけかもしれない。
React Native Cli
Expoに比べるとだいぶシンプルなライブラリに感じる。
ReactのコードをReact NativeとしてAndroid/IOS用アプリケーションにビルドする機能を提供するって感じ。
これまた偶然かもしれないけど、Expoと違い何か新しく入れた時にビルドでこけることが多かったように思う。
ライブラリによってはAndroid用のコードやIOS用のコード(本記事ではネイティブコードと呼称します。正式名称がわからない……)に変更を加える必要がある。
もともとReact Native自体がReactのコードをKotlinやC++として読み込めるようにしてるみたいで、ライブラリを導入するならライブラリ用の読み込み機能も追加しないとだよねってことみたいだけど、どうもここの噛み合わせが崩れやすい模様。
各種言語やライブラリのバージョン等にも影響を受けるみたいで、直近だとReact Nativeの最新バージョンで生成したプロジェクトにReact Navigationを導入するとビルドがこけるということがあった。
このときはGradleの設定でKotlinのバージョンを指定することで対応したけど、そういうなんかよくわからないエラーが起きることがままあるみたい。
なのでReact Nativeだけではなく、Gradle等のネイティブコードに関する知識も要求されるように思う。
でも使う。こっちの方が透明性が高い気がして私は好きです。
React Navigation、React Native Navigation
この二つ、名前が似てるけど別ライブラリなんですよ。
メジャーなのはReact Navigationらしい。
どっちもネイティブコードに変更を加えるけど、React Navigationの方が少ない。
特にReact Native Navigation(以下、RNN)はnpx rnn-linkで機械にお任せしてしまうので、うまく通らなかったり後々別ライブラリに変えようとすると面倒なことになる。
その点React Navigationは手作業で数行コピペするだけで済むのでお手軽だし戻しやすい。
使い勝手でいうとRNNの方が良さそうではある。
特にReact Navigationだと関数を引数として渡すことができないこともあり、RNNの方が感覚的に扱えるように思う。
けど、Redux時代ならともかく今はRecoil導入が大前提の流れが来ているように感じるので、直接関数を引き渡す機会はあんまりなさそう。
後はRNNの方がTypeScriptの型定義が簡潔に済むように感じたけど、そこもRecoilを使う前提ならそこまで苦じゃなさそう。
つまり理由がなければReact Navigationでいいんじゃないかな。
まだしっかり触れていないので、今後アプリ開発を続けていけばまた違った意見になるかもしれない。
React Native CliのAABビルドに必要なkeystoreファイル
署名の関係でkeystoreファイルが必要になる。
そのあたりはReact NativeおよびAndroid Studioのドキュメントを読んでやればいいけど、問題はkeystoreファイルをどこに保存するか。
もちろんその辺に置いとくと無くしそうだし、かといってリポジトリに保存するには怖いよねこういうの。
ってことで悩んでいたけど、こちらの記事を読んで解決しました。
そっかBase64で文字列化してSecretsに入れてCD/CIを構築すれば全部忘れていいんだ。
Secretsならリポジトリの管理者も簡単には見れないしちょうどいい。
ダークモード対応は必須(ダークモードを用意しろってわけではない)
ダークモードはスマホ側の設定で行える。
もちろんスマホ側の設定でダークモードにしたところでアプリ側で設定した色が勝手に変更されるわけではない。
が、今時はあれこれライブラリを入れてアプリを作っているはずなので、ライブラリ側で勝手にダークモードしてしまうことがある。
なのでダークモードを考えずに全部作り、後々ダークモード設定したスマホで開いてみると色が毒々しくなってたりすることがある。
そうならないようにダークモードを意識して作っていこうねという話。
問題はライブラリによって対応したりしなかったりが違うところ。
たとえばReact Native Calendarsは対応してないし、ライブラリ側で簡単に調整できるような機能も備えていない(あるいは私が見つけられていない)。
一方でReact Native Date Pickerはテキスト色が自動で対応するものの背景色が変わらなかったりする(あるいは私の設定が悪い)。
なので各ライブラリ利用箇所で細かく調整する必要が出てきたりする。
こういうところこそRecoilを使ってアプリ全体のダークモード状態管理を行うことで調整しやすくしたい。
もちろんAndroidでビルドしたときとIOSでビルドした時で異なる部分も多いので、こちらも同じく意識して作っていきたい。
他、1行メモ
- Androidアプリとしてリリースするにはプライバシーポリシーが必要になる。素のHTMLでいいので、S3の静的ホスティングで事足りる。
- Androidアプリのリリースはテスト用と製品版で異なる。バージョン名はそれぞれ付けられる。
- Androidのバージョンコードは表に出てこないGoogle Play Consoleで管理するための値。なので適当に連番でつけていけばいい。
- IOSはまだリリースしたことないからよくわからない……いつかやります。
- UIフレームワーク、個人的にはReact Native Paperが好き。
Discussion