Kotlinの静的解析ツールDetektを導入する (Part 1/2)
Detekt comes with a set of plugins that helps you configure it easily in your Gradle, Maven, Bazel, ... build. Enjoy… DetektはKotlinのコード静的解析ツールになっていて、フォーマットエラーやCode smellを検出してくれるものになります。 ktlintに比べて更に細かいことをしてくれますし、コードで問題がありそうな箇所も検出してくれるの、うまく運用すると非常に強力なものになると思います。 セットアップDetektの導入はドキュメントを見ても分かりにくい部分があるので、まずは最低限の設定でやっていきます。 今回はKotlin DSLを使った例になります。 まずはDetektのGardle Pluginをプロジェクト直下の build.gradle に追加します。
フルスクリーン画面対応のこれまでとこれから
Photo by Erik Mclean on UnsplashAndroidのバージョンアップとともに、フルスクリーン画面を実現する方法が変更されてきたので、まとめておきます。 さらに次のAndroid 12でも一部変更が入りそうな気配です。 これまでの対応方法Android 4.0 以下テーマ (Theme.Holo.NoActionBar.Fullscreen)もしくは Window.setFlags で実現していました。 window.setFlags( WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN )ただ、この FLAG_FULLSCREEN はAPI Level 30からはDeprecatedになっています。 Android 4.1以降、Android
UiStateを使った状態管理
Photo by Med Badr Chemmaoui on Unsplash状態管理する方法は色々ありますが、UiStateという状態を一つのclassでまとめて管理する方法を紹介します。 （UiStateの他にはUiModel, ViewStateなど色んな呼び方を見かけます） UiStateでも大きく2つやり方があるかなと思っています。 sealed class を使ったやり方と data class を使ったやり方です。 sealed class を使った管理sealed class を使って画面が取り得る状態を定義して、必要なデータは各継承クラスのプロパティに持たせる方法です。 以下のコメントに書いてる通り、各状態を sealed class を継承した data class や object で表現しています。
SharedFlowを使ったイベント通知
Photo by Adam Solomon on Unsplash追記: まだまだ検討する必要があります。この記事は参考程度にしてもらえると助かります。 これまでViewModelからViewへのイベント通知を行うには、SingleLiveEvent がよく使われてきました。 これに代わる手法を個人的に色々模索してたのですが、Coroutines 1.4で導入された SharedFlow が使えるのではないかと思っています。 まだ実際にプロダクションに投入してるわけではないので、なにか見落としてることはあるかもです。そのときは指摘してもらえると嬉しいです。 SingleLiveEventの問題点SingleLiveEvent は LiveData を改造したものになり、そもそもの LiveData の挙動から大きく異なるものになります。 こちらの IssueTracker ではそういった理
2021年1月におけるAndroid開発状況
Photo by Moritz Knöringer on Unsplash今年もAndroid開発状況を個人的な観点からまとめたいと思います。 去年のはこちら KotlinKotlinはもう言うことは特にないですね。 個人的には KSP がどうなるかが気になるところですね。 CoroutinesAndroid11のリリースと合わせて正式にCoroutinesが推奨される非同期処理となりました。（あとAsyncTaskがDeprecatedになりましたね） これまで以上にCoroutinesを使っていく場面が増えてくると思いますし、Jetpackライブラリでも当たり前のように使われていくと思います。 また、StateFlowやSharedFlowなどの便利なものも出てきています。 まだ触ったことない方はぜひチャレンジしてみてください。 https://developer.android.co
ActivityResultContractを使ったActivity間のデータ受け渡し
Activity 1.2.0-alpha02 と Fragment 1.3.0-alpha02 から ActivityResultContract が追加されました。 ActivityResultContract を使うことで、従来の onActivityResult とは違った方法でActivityの結果を受け取ることが可能になります。 ActivityResultContracts にいくつか用意されてるものがあります。 build.gradleimplementation "androidx.activity:activity-ktx:1.2.0-alpha02" implementation "androidx.fragment:fragment-ktx:1.3.0-alpha02"注意実装時の注意は別の記事で書きましたので、合わせて確認してください。
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 でちゃんと依存性の注入ができるようにするためにどう定義していくかということになります。
2019年1月におけるAndroid開発状況
2019年1月におけるAndroid開発状況について簡単にまとめておきます。 ぼくが感じる個人的見解なので、人によっては違う印象だと思います。あくまで参考程度にしてもらえると。 Kotlinおそらく、ほとんどのプロジェクトがKotlinで書かれてると思います。新規プロジェクトでJavaを選択するのはかなりレアなのかと思います。 公式ドキュメントもKotlinでの記述が増えてますし、ktxとして便利な拡張関数も提供されてます。 Coroutines去年正式にリリースされたCoroutinesですが、まだ無理に入れる必要はないかなと思っています。特に既存プロジェクトに関しては。 新規プロジェクトに関しては導入するのもアリだと思いますが、必ずチームで相談しましょう。 Jetpackも対応が進んでるので、いずれはCoroutinesが当たり前になるかもしれません。 今すぐ慌ててやる必要はないと思い
AndroidでKotlin Coroutineを非同期で使うときの注意
AndroidでKotlinのCoroutineを使うときの注意です。CoroutineDispatcherの選択を誤ると意図しない結果になります。 環境はkotlinx-coroutines-android:0.16になります。 非同期処理をCoroutineで実現する場合、以下のようなCommonPoolを使ったサンプルが多いと思いますが、これではジョブをキャンセルした場合にasync内の処理がキャンセルされません。 では、違う方法にします。先程CommpnPoolを渡してた場所をcontextを渡すようにします。contextを指定し場合は親のジョブの子のような扱いになり、ジョブをキャンセルしたときに子もキャンセルされます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KSPを使ってコード生成してみる
Dagger AndroidからHiltに段階的に移行する
Google Developer Expert (Android) になりました
お金を払ってるサービス