Androidでダークモードにするとアラートの文字が黒いままで見にくい現象が起きた Androidでアラートを出そうとした時、通常はこのようなUIになります。 実装はとても簡単でこんな感じです。 import React from 'react'; import {Alert, Button, View} from 'react-native'; export const AlertView = () => { const onAlert = () => { return Alert.alert('こんにちは') } return ( <View> <Button title="タップ" onPress={onAlert} /> </View> ); }; React Native標準のAlertを使えば簡単に表示できます。 ただ、アラート内の文字にスタイリングを当てることはできないというデメリットもありますが、基本的にアラートを出すときはこれで十分だと考えられます。 しかし、スマホをダークモードにしてしまうと。。。。 アラート自体は暗くなるのに文字が黒いままで非常に見にくくなります。 自動的に対応してくれないのかよ！と思いました。 解決策 プロジェクト内のandroidディレクトリ内にダークモードでも文字色を黒にするように標準で設定されていました。 その文をなくせば解決します。 プロジェクト名/android/src/main/res/values/styles.xmlに行きます。 <resources> <!-- Base application theme. --> <style name="AppTheme" parent="Theme.AppCompat.DayNight.NoActionBar"> <!-- Customize your theme here. --> <item name="android:textColor">#000000</item> ←問題のコード </style> </resources> item name="android:textColor">#000000</item> これを消しちゃってください。それで問題解決します。 実際に検証してみると、、 こんな感じになります！ アラートの文字以外にもTextInputのPlaceholderなど文字にカラーを設定していないところはダークモードにしても黒くなってしまいます。 是非ご参考までに！！

licence error > Failed to install the following Android SDK packages as some licences have not been accepted. こんなエラーが出ることがある。 $ cd ~/Library/Android/sdk/tools/bin $ ./sdkmanager --licenses Accept? (y/N): y ・ ・ All SDK package licenses accepted

licence error > Failed to install the following Android SDK packages as some licences have not been accepted. こんなエラーが出ることがある。 $ cd ~/Library/Android/sdk/tools/bin $ ./sdkmanager --licenses Accept? (y/N): y ・ ・ All SDK package licenses accepted

実務でfirstOrNullのメソッド使う時があったため備忘録としてここにメモしておきます //以下のようなlistがあった場合に頭の1を取得したい場合に`firstOrNull`や`first`を使います val list = listOf("1", "2", "3","1") list.firstOrNull { 1 == it.1} fist,firstOrNullの違いについて val list = listOf("1", "2", "3","1") list.first {2 == it.4} //listの中に4がないのでnullになりおちます list.firstOrNull {2 == it.4} //listのなかに4はありませんが、該当する値がない場合はnullをあつかってくれるので、あらかじめnull許容にしておけば問題ありません

※Pixel 5 Android 12 betaでほぼ確実に発生することを確認しましたが、他の端末・バージョンだと発生するかどうかはまちまちです。 Foreground Serviceを実行している間にアプリをタスクキル（タスクリストからActivityをスワイプして消す）すると、ServiceのonDestroyは呼ばれず、Foreground Serviceの通知が残り続けます。 LogCatを見ていると ActivityManager: Scheduling restart of crashed service のような行が見えます。おそらくタスクキルの操作により一度Serviceが強制停止されるが、システムにより自動的にServiceが再起動されているのでしょう。 以下のようにログを仕込んで、タスクキル時にServiceに何が起こっているかを調べてみました。 class MyService : Service() { override fun onCreate() { Log.d("HOGE", "onCreate") super.onCreate() } override fun onDestroy() { Log.d("HOGE", "onDestroy") super.onDestroy() } override fun onStartCommand(intent: Intent, flags: Int, startId: Int): Int { Log.d("HOGE", "onStartCommand") // Serviceで行う処理 } } すると、タスクキル操作をした後に以下のログが出ていました 10-13 11:46:34.649 1741 3928 W ActivityManager: Scheduling restart of crashed service my.app/my.app.MyService in 1000ms for start-requested 10-13 11:46:35.661 1741 1892 I ActivityManager: Start proc 28886:my.app/u0a522 for service {my.app/my.app.MyService} 10-13 11:46:37.281 28886 28886 D HOGE: onCreate このログから、以下のことがわかります。 タスクキル操作によりonDestroyは呼ばれない Serviceがシステムにより再起動されonCreateが呼ばれる 再起動時はonStartCommandは呼ばれない タスクキルをしてもForeground Serviceは動き続ける（一旦止まるがシステムにより再起動される）ので、通知が消えないようです。 解決方法 シンプルにタスクキル操作時にServiceを止めたいという場合は、AndroidManifest.xmlにandroid:stopWithTask="true"を付ければ良いです。 <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="my.app" > <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <application> <service android:name=".MyService" android:exported="false" android:foregroundServiceType="microphone" android:stopWithTask="true" /> </application> </manifest> Serviceを止めるだけでなく、なんらかの処理を行いたい場合はandroid:stopWithTask="true"を付けずに（または"false"を付ける）ServiceでonTaskRemovedをオーバーライドします。 class MyService : Service() { override fun onTaskRemoved(rootIntent: Intent?) { // タスクキル時の処理 // Serviceを止めたいならstopSelf()する // super.onTaskRemovedは空なので、呼ばなくても大丈夫そう。将来仕様が変わる可能性を考慮して一応呼んでおいたほうが安全かも？ } } ただし、onTaskRemovedが呼ばれるのはServiceがシステムにより再起動された後です。すなわち、一度Serviceは強制停止された後、新しいServiceが開始され、そのインスタンスでonTaskRemovedが呼ばれます。ちょっと直感的ではない動き方なので気をつけましょう。 タスクキルする Serviceが強制停止される（onDestroyは呼ばれない） システムによりServiceが再開される（onCreateが呼ばれる） onTaskRemovedが呼ばれる onTaskRemovedが呼ばれる時点ではServiceのインスタンスが作り直されているので、注意しましょう。「Serviceのインスタンスは一つだけ」というつもりでコードを書きがちなので… Foreground Serviceを使うときは、タスクキルに要注意です。

Androidプロジェクトに新規参加することになり、 利用されているDependency Injection(以下、DI)について調査しました。 プロジェクトで使われているDIがなぜ選択されたのか、 他との比較をした上で良い点、悪い点も把握するため調査した内容になります。 DIとは？ 依存性の注入、依存関係インジェクション と表記されます。 依存関係インジェクション（DI）はプログラミングで広く使用されている手法で、Android 開発にも適しています。 DI の原則に従うことで、優れたアプリ アーキテクチャの土台を築くことができます。 依存関係インジェクションを実装すると、次のようなメリットがもたらされます。 ・コードを再利用できる ・リファクタリングが容易になる ・テストが容易になる 引用：https://developer.android.com/training/dependency-injection?hl=ja Android DI フレームワーク一覧 ★Dagger ★Hilt ★Koin Kodein Katana RoboGuice Proton 調べたところ多数見つけることが出来ましたので絞って更に調査を行うことにしました。 ただしDaggerとHiltはAndroid Developersに記載されている為、無条件で対象とします。 更新状況 スター数 Koin 継続中 7k Kodein 継続中 2.6k Katana 継続中 180 RoboGuice 最終更新2016年 - Proton 最終更新2014年 - Dagger Java、Kotlin、Android 向けの完全に静的なコンパイル時依存性注入フレームワークになります。 元々はSquare社が開発したものをGoogleがforkした形になります。 この時に呼び名が変わっており、明確にはSquare社のv0.9.0~1.2.1をDagger、 Googleのv2.0.0~v2.3.6をDagger2と呼ばれています。 導入方法についてはAndroid Developersに記載されています。 ただし現在(2021年10月)はHiltの方を推奨しているようです。 Hilt HiltはAndroid Dev Summit 2019にて発表されました。 2020年5月にalphaバージョン、2021年5月に1.0.0がリリースされています。 HiltはDaggerの上に構築されているため下記のDaggerの恩恵を受けられます。 コンパイル時の正確性 実行時のパフォーマンス スケーラビリティ Android Studioのサポート こちらも導入方法についてはAndroid Developersに記載されています。 Koin Kotlin開発者向けの実用的で軽量な依存性注入フレームワークになります。 Android Kotlinだけではなく、Android Java、Ktorでも利用可能です。 使い方がかなり簡易であり以下の操作で使うことが出来ます。 injectしたいモジュールの宣言 Koinの開始 利用箇所でinject Koinを使ってみて Android DIへの入りとして学習コストが易しそうなKoinを触ってみました。 以下サンプルではActivityにViewModelを注入する事としました。 まずはViewModelの定義を行います。 このViewModelでは2つのUseCaseを利用するので定義します。 SampleViewModel.kt internal class SampleViewModel( private val hogeUseCase: HogeUseCase, private val fugaUseCase: FugaUseCase ) 次にViewModelを注入する為、モジュールに定義します。 この時、依存関係のネストである2つのUseCaseは明確に定義する必要がなく、 get() のみで判別してくれる為大変楽でした。 myModule.kt val myModule = module { viewModel { SampleViewModel(get(), get()) } } 次に定義したモジュールをKoinに読み込ませます。 読み込ませるにはKoinを開始する時に定義するだけで大丈夫です。 App.kt startKoin { androidContext(this@App) modules(myModule) } 最後にViewModelを利用する箇所でViewModelを注入します。 SampleActivity.kt private val sampleViewModel: SampleViewModel by viewModel() わずか数行で依存性の注入を実装することが出来ました。 また、Daggerのようなアノテーションベースではない為大変分かりやすかったです。 まとめ 現在選択肢に上がるのはHiltかKoin。 ただしAndroid Developersで推している為、スタンダードはHilt。 以下コストから(個人的に)Koinも選択肢として有り。 導入のしやすさ 記述の見やすさ 学習コスト 参考 https://developer.android.com/?hl=ja https://insert-koin.io/