Jetpack Composeの実装思考
Jetpack Composeの最初のalphaがリリースされました。 Jetpack Composeはモダンな宣言的UIツールキットです。これまでのAndroidのViewシステムは異なるものになるため、実装においても考え方が大きく異なります。 React, Vue.js, Flutterなどで開発したことがある方なら、実装時に考えることや気をつけることが理解できてるかもしれません。しかし、これらを開発したことない方にとってはもしかしたら難しく感じるかもしれません。 （ぼくは、React, Vue.js, Flutterはちょっと触った程度の人間ですが…Vue.jsは仕事で書いたかな。） ぼくが感じたJetpack Composeの実装においての考え方や気をつけたい箇所をまとめたいと思います。 （もしかしたら他の人と感じてることが違うかも？） Single source of truth
Paging 3 の変更点
The Paging library helps you load and display pages of data from a larger dataset from local storage or over network… ※Paging 3はJava/RxJava・Guavaでも実装可能ですが、今回は試していません。 ネットワーク通信と組み合わせることを想定しての解説になります。 今回の環境は 3.0.0-alpha01 になります。 KotlinPaging 3は現時点ではJetpackの中で唯一すべてKotlinで書かれています。Javaからももちろん使用可能ではあります。 Coroutines / Flowが全面的に使用されています。 基本的な実装以前と異なり大幅に簡単になっています。 以前は実装する際に様々なクラスを定義する必要がありました。Roomと連携する際はそこ
LiveDataとStateFlowの違い
Photo by Ussama Azam on UnsplashCoroutines 1.3.6 から StateFlow が導入されました。これは使い方等がLiveDataと似ているため、どういった違いがあるのか調べてみました。 これを書いてるときはまだ Exprimental なので、今後変更があるかもしれません。今回は1.3.7を使っています。 使い方まずは StateFlow の簡単な使い方です。 LiveDataと同じように定義してあげます。 MutableStateFlow をprivateにして、 StateFlow として外からは変更不可で公開してあげるのが丁寧ですね。 この例では数値をインクリメントしていくような処理になっています。 この StateFlow の変更通知を受け取る方法です。 見ての通り LiveData と使い方は非常に似ています。これらの違いについて分か
NavigationでFragmentの戻り値を扱う
Navigation 2.3.0-alpha02 からNavControllerに currentBackStackEntry と previousBackStackEntry が追加され、これらを使ってFragmentの戻り値を処理することが可能になりました。 内部的には各BackStackで SavedStateHandle と ViewModel を使ってるようです。 呼び出し元Fragment 呼び出し元のFragmentでは、 currentBackStackEntry の SavedStateHandle からLiveDataを取得して、それをobserveしておきます。 遷移後のFragmentで値が設定された場合にこの画面が再び表示されると、ここに通知されます。 値を返すFragment 値を返すには previousBackStackEntry の SavedStateH
Roomのマイグレーションまとめ
Roomのマイグレーションについてまとめておきます。 環境Room 2.2.0やっておいたほうが良いことRoomのマイグレーションはテストが可能なのですが、その前にやっておいたほうが良い設定があります。 build.gradleに以下の設定を最初から追加しておくことをオススメします。 android { defaultConfig { javaCompileOptions { annotationProcessorOptions { arguments = ["room.schemaLocation": "$projectDir/schemas".toString()] } } } }この設定がなくても、Room自体は使用可能なのですが、マイグレーションのテストするには必要になります。 この設定をしておくと、モジュール直下にschemasのディレクトリが作られ、 1.json のようなバー
PlayStoreからインストールされたかを検証する
App Bundleを使用してる場合、apkファイルがリソースも言語やdpi等で分割されますが、PlayStoreからインストールする際に自動でそのデバイスに必要なものをインストールするようになっています。 しかし、世の中にはapkファイルを取得してきて外部のストアに公開し、さらにそれをインストールする人がいます。 （正規のストア以外からインストールすることを Sideloading というらしいです） この場合、baseとなるapkだけが公開されたりするので、リソースのあるapkが足りずにエラーを起こすことになります。 原因不明の Resources$NotFoundException を見かけたら、これが原因の場合があります。 こういった不正な方法でインストールしたかどうかをチェックできる方法があります。 対策ライブラリ使用するのはPlay core libraryを使います。 imp
setUserVisibleHintのdeprecatedとsetMaxLifecycle
Photo by José Alejandro Cuffia on Unsplashfragment-1.1.0-alpha07 で setUserVisibleHint がdeprecatedになりました。それに伴い、 setMaxLifecycle というのが追加されました。 (ここでは fragment-1.1.0-rc01 ベースに記事を書いてます。) setUserVisibleHintはViewPagerでFragmentが表示されたイベントとしてよく使われています。ViewPagerで追加されたFragmentは表示されていない場合でもonResumeまでイベントが走っていました。 このあたりに変更が入っています。 setMaxLifecycleこれはLifecycleの上限を設定するものになっています。あまり直接使うようなものでは無い気がします。使い方は以下のような感じです
Internal App Sharingでアプリを共有する
Google I/O 2019で発表された Internal app sharing が便利そうだったので実際に試してみました。 事前準備Play Consoleでアプリを公開しておくて（内部テストだけも可能）テスターを設定しておく（後述）Android端末にてPlayStoreアプリで開発者モードになる （Playアプリの設定から、 Playストアのバージョン を7回タップする）Playアプリで、設定の 内部アプリの共有 をONにするテスター設定Play Consoleで対象のアプリを開く開発ツール -> 内部アプリ共有 を開くテスターの管理 タブでテスターを設定する テスターの管理テスター設定時の注意ですが、該当のテスターがPlayStoreで対象アプリをダウンロードできる必要があります。 例えば、内部テストしか公開してないときは、オプトインURLでPlayStoreでもダウンロードで
SavedState ViewModelを使ってデータを保持する
ViewModelを使うことで画面回転等のConfigurationが変更されたときもデータを保持することが可能になりました。しかし、OSからプロセスKillされてActivityの再生成に対応できません。 この場合は onSaveInstanceState を使うことで対応することになります。 ほとんどケースでUIの状態はViewModelと多いので、このあたりもViewModelのほうで対応できたらだいぶ楽になると思います。 これを SavedStateHandle というのを使って保存と取得を行えるようになりました。 まだalpha01なので今後変更はあるかもしれませんが。 環境implementation 'androidx.lifecycle:lifecycle-viewmodel-savedstate:1.0.0-alpha01'実装ViewModel定義
マルチモジュールとNavigation
マルチモジュールにおいて問題になりがちなのが、画面遷移です。 あるmoduleから、別のmoduleに遷移するときにどのようにするのが良いのかが悩ましい問題かと思います。 ぼくのなかではNavigation Componentを使うことで色々解決できると思っています。 Navigation GraphNavigationではNavigation Graphという画面遷移を定義したXMLを作成します。 このXML内にFragmentやActivityのクラスを記述するのですが、実はこのクラスはビルド時に参照できるかをチェックしていません。 そのため、モジュールを跨いだ定義が可能になります。 Navigationでは画面遷移は基本的にリフレクションを使ってるため、もし間違っている値を設定してる場合は実行時エラーになります。 モジュール間の画面遷移上記で書いたように、クラスが参照できるかをチェッ
CoroutinesのUnit Testメモ
suspend関数内でwithContextでDispatcherを切り替えてるものも、同様に runBlocking で囲むだけです。 注意として Dispatchers.Main だけはエラーになります。次で対応方法を見せます。 Dispatchers.Mainテスト対象。先程のは IO を使ってましたが、今回は Main を使ってます。 Dispatchers.Main を使った場合はそのままテストを実行すると以下のようなエラーメッセージが表示されます。 java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize. For tests Dispatchers.setMain from kotlinx-coroutines-test module can be use
2019年1月におけるAndroid開発状況
2019年1月におけるAndroid開発状況について簡単にまとめておきます。 ぼくが感じる個人的見解なので、人によっては違う印象だと思います。あくまで参考程度にしてもらえると。 Kotlinおそらく、ほとんどのプロジェクトがKotlinで書かれてると思います。新規プロジェクトでJavaを選択するのはかなりレアなのかと思います。 公式ドキュメントもKotlinでの記述が増えてますし、ktxとして便利な拡張関数も提供されてます。 Coroutines去年正式にリリースされたCoroutinesですが、まだ無理に入れる必要はないかなと思っています。特に既存プロジェクトに関しては。 新規プロジェクトに関しては導入するのもアリだと思いますが、必ずチームで相談しましょう。 Jetpackも対応が進んでるので、いずれはCoroutinesが当たり前になるかもしれません。 今すぐ慌ててやる必要はないと思い
LiveDataのUnitTest
ちょっとやっかいな部分もあったので、LiveDataのテストをどう書くのかまとめました。 build.gradle必要なものを追加します。LiveDataを使うので、もちろんArchitectureComponentを追加してます。 mockito-kotlin はmockitoをkotlinでいい感じに使うやつです。mockitoをそのまま使うとNull Safetyが影響したりするので、入れておくと良いと思います。 core-testing はLiveDataをテストする上で必要なものがあります。 同期処理テスト対象単純なViewModelをテストしてみます。この例だと、 fetchNameが呼ばれたらLiveDataに文字列を流してるだけです。 16行目: ここでは、Observerのmockを作成しています。mockitoを使って最後にverifyで値をチェックするためです。 17
RobolectricのOffline設定
Robolectricのインストールとかは省略 Offlineのgradle設定ファイルrobolectricのoffline設定とjarのダウンロードのタスクの設定したファイルをプロジェクト直下に配置します。ファイル名は prepare-roborectric.gradle にしてます。 この例だと、 .robolectric-dependencies というディレクトリにjarをダウンロードします。 dependencies に依存のjarを設定するのですが、これがテストの設定とかで微妙に異なります。 確認する方法です。後述するapp/build.gradleの設定をまだしない状態でやってください。 最初に ~/.m2/repository/org/robolectric が存在する場合は一度削除しておきます。次に ./gradlw testDebug -d を実行します。ログがたくさ
GradleのResolutionStrategy
Examples: Sets the length of time that changing modules will be cached. Gradle caches the contents and artifacts of… 依存関係は以下のようになります。 +--- com.squareup.okhttp3:okhttp:3.10.0 | \--- com.squareup.okio:okio:1.14.0 \--- project :mylibrary \--- com.squareup.okhttp3:okhttp:3.9.1 -> 3.10.0 (*)mylibrary側のバージョンが変更されてapp側に合わせられてます。 appとmylibraryのバージョンを逆にした場合も同様に、低いほうが新しい方へ変更されます。 +--- com.squareup.okhttp3:o
Dagger Android拡張の使い方
Dagger is a fully static, compile-time dependency injection framework for both Java and Android. It is developed by the… Android拡張とは今までのやり方だと、コピペのコードが多かったり、Injectを行うクラスが依存解決する方法を知ってるとか、なんとか…っていう問題があるので、なんとかしようってことです。 ぼくの理解としては AndroidInjection.inject でシンプルに依存性の注入をやっていこうっていう雑な解釈でいます。そのための準備がだいぶ複雑ですが。 なので、 AndroidInjection.inject でちゃんと依存性の注入ができるようにするためにどう定義していくかということになります。
Androidのライブラリを作る時はKotlinを使わないほうが良いかも？
判断迷ってます。何か間違ってたら教えてください。 ライブラリにKotlinを使ってる場合、アプリ側に多少デメリットがあります。 アプリサイズKotlinを使ったライブラリを依存関係に追加すると、こんな感じにKotlinのランタイムのライブラリも入ってきます。 \--- project :libkotlin \--- org.jetbrains.kotlin:kotlin-stdlib-jre7:1.2.21 \--- org.jetbrains.kotlin:kotlin-stdlib:1.2.21 \--- org.jetbrains:annotations:13.0アプリ側がJavaの場合は、その分、単純にアプリサイズが増加します。 とは言え、ライブラリ自体そんなに大きくないので、すごく増えるということはなさそうです。 ココに書いてる通り、全部で約934KBで、Proguardを使うと
DataBindingのコード取得とデバッグ
AOSPからDataBindingのコード取得方法とデバッグ方法について簡単にまとめておきます。 DataBindingと書いてますが、依存してるAndroid StudioとGradle Pluginあたりのコードも取得します。 環境mac OS High SierraSetupコードを取得する前に事前準備をします Disk Image作成Macは通常、ファイル名の大文字と小文字を区別していません。そのため、問題が発生することがあります。 なので、大文字と小文字を区別するDisk Imageを作って、それをマウントして使います。 以下のコマンドで作成します。容量は80Gとしています。 $ hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 80g ~/android.dmgこれを実行すると、 andr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Paging Library + ヘッダー
Dagger2の設定をグラフにする
