綴ります。プログラミング、アプリ開発について。

Tag

Android

Showing 4 Result(s)

Android の Dialog の基礎

on

前略: ダイアログはDialogではなくDialogFragmentで作るというめんどくささ Android でダイアログを作ろうとすると、今は「DialogFragment で作る」というのが一般的です。ただ、調べると、DialogFragmentを使わずにAlertDialogだけでダイアログを作る記事なども見受けられると思います、、、、ここでは、ダイアログはDialogFragmentで作るのが一般的だということと、その時の注意点を。 Dialog is ダイアログUIを提供するクラスです。代表的なサブクラスはAlertDialogやDatePickerDialogなどがあります。DialogFragmentを使う場合でも、UIを実現しているのはこれらのクラスが実態になります。UIとしては画面上の一部で表示するのが一般的ですが、全画面として表示するようにカスタムすることも可能です。参考 DialogFragment is 公式サイトによると、以下のように。 これらのクラスでは、ダイアログのスタイルと構造が定義されますが、ダイアログのコンテナとして DialogFragment を使用してください。DialogFragment クラスでは、Dialog オブジェクトでメソッドを呼び出す代わりに、ダイアログの作成と表示の管理に必要なすべてのコントロールが提供されます。DialogFragment を使ってダイアログを管理すると、ライフサイクル イベント（戻るボタンを選択したときや画面を回転したときなど）が正しく処理されます。DialogFragment クラスを使用すると、従来の Fragment のように、大きな UI で埋め込み可能なコンポーネントとしてダイアログの UI を再利用することもできます（ダイアログ UI を大小の画面で異なって表示させる場合など）。 少しかいつまんで言うと↓↓↓ ダイアログのコンテナとして DialogFragment を使ってね。 ダイアログ制御に必要なすべてのコントロールができるよ。 戻るボタン押したときや画面回転したときなどのライフサイクルイベントで正しく動くよ。 DialogFragment 使わないといけないの？？ 「ダイアログ表示したいだけなのに、何？ダイアログ「フラグメント」って」「なんか直感的じゃないんだよな、ダイアログでいいじゃん」と思う人もいると思います。少し歴史を紹介しますが、使わないといけないというわけではないです。が、もう Google 的には Dialog 使う場合は DialogFragment を使うという感じになってます。 Android2系時代当時、Dialog表示は Activity の onCreateDialog メソッドでダイアログ表示処理を書いて、 showDialog というメソッドを呼び出すことで onCreateDialog が実行され、表示していた。これが一般的だった。 ちなみに、 onCreateDialog で実装しないと画面回転時などにクラッシュするか、落ちないにしても WindowLeak …

BroadcastReceiver の基礎

on

前略: BroadcastReceiver の概要とポイントをまとめた 開発チーム内での共通認識レベルとして必要かなと思われる概要とポイントをまとめました。図とかあったらよいかと思ったんですが、そこまでできていないです。文字だけです。そして、基本は公式サイトを抜粋・文言変更して作ってます。 ブロードキャスト(ブロードキャストメッセージ)とは BroadcastReceiver を調べると、用語としてブロードキャスト(またはブロードキャストメッセージ)というのが出てきますので、念の為それも整理します。そもそもブロードキャストとは？調べてみると、 「コンピューター-ネットワークで、接続されているすべての端末に対し相手を特定せずにデータを送ること。」 というようなことが書いてあります。なので、 ブロードキャストメッセージとは 「コンピューター-ネットワークで、接続されているすべての端末に対し相手を特定せずに送られるデータのこと。」 と言えそうです。これらを念頭に置くと、以下がわかりやすくなるかもしれません。 BroadcastReceiver is Android は OS やアプリから、なんらかのイベントが発生したことをシステム全体に対して送受信することができます。まず、これが Android におけるブロードキャストです。たとえば、端末の起動、デバイスの充電の開始など、さまざまなシステムイベントが発生したときに、OSがイベント発生をブロードキャストします。また、アプリから独自のブロードキャストを送信することもでき、この場合はアプリ間のイベント通知として使用されたりするのが一般的です。Androidでは、そういったOSやアプリから送信されるブロードキャストを受信するためのコンポーネントとして、 BroadcastReceiver というものを用意しています。アプリは BroadcastReceiver を使って、特定のブロードキャストを受信するように登録することで、そのブロードキャストをシステムから受信できる仕組みになっています。ブロードキャストメッセージの実態は intent を使うようになっており、ブロードキャストをアプリが受信すると、受信した BroadcastReceiver の onReceive が動き、引数の intent にその中にイベント発生を表すアクション文字列が入ってくるようになっています。たとえば、機内モードに切り替えたときであれば android.intent.action.AIRPLANE_MODE という文字列がアクションとして intent に入っています。電源ONや機内モード切り替えなどのシステムのイベント発生によるブロードキャストをシステムブロードキャストといいます。システムブロードキャストのアクション一覧は BROADCAST_ACTIONS.TXT に記載されています。（ググれば出てきます。） システムブロードキャストの動作変更 Android OSのバージョンアップに応じて、システムブロードキャストの動作についても定期的に変更されています。特に、OSのバージョンが挙がっていくにあたって、ブロードキャストに対する制約が増えていく傾向にありますので実装観点でも注意が必要です。 Android 9(API レベル 28)以降NETWORK_STATE_CHANGED_ACTION のブロードキャストはユーザーの位置情報や個人を特定できるデータを受信しなくなっている。Android 9 以降のデバイスは、Wi-Fi からのシステム ブロードキャストに SSID、BSSID、接続情報、スキャン結果は含まれない。- Android 8.0(API レベル 26)以降システムはマニフェストで宣言されたレシーバーに対して追加の制限を課します。アプリのtargetSdkVersionが …

ActivityとFragmentの違い

on

前略: Activity と Fragment の使い分けがわからん！ 「Androidのプロジェクトを作るとActivityもFragmentもセットで出来上がったりするけど、お互い似たような性質はあるし、結局どのような切り分けで使い分けたら良いかわからない！」という方向けに、それぞれの簡単な仕様や歴史を説明して、それぞれの役割を明確にするための参考情報なればいいなと。 Activity is ライフサイクルを持ったUI兼UIコントローラー。setContentViewで設定したレイアウトをUIとして使うことができる。画面単位で使うのが一般的。画面履歴をスタックで管理でき、バックで前のActivityに戻ることができる。この仕様は、Androidのタスク、起動モード、Activityバックスタックの仕様に密接に関係している。 Fragment is ライフサイクルを持ったUI兼UIコントローラー。onCreateViewで生成したViewをUIとして使うことができる。今は画面単位で使うことが一般的。画面の一部分を表現したり、Fragment同士で親子関係を持つこともできたり、ライフサイクルに合わせたロジックだけを持つこともできるため、幅広い用途で使える。スタック管理ができ、バックで前のFragmentに戻ることができ、このスタックはActivity（または親Fragment）が管理し、Androidのタスク、起動モード、Activityバックスタックの仕様とは関係ない。 Fragment誕生の経緯と有用性 Fragmentは、Tablet用に作られたAndroid3.0から、よりフレキシブルなUI実現のためにActivity上のUIの断片化を目的として生まれた。そのためレイアウト内にどのように配置するかという点でも、Viewのように扱えるように設計されている。これにより、ActivityだけではやりづらかったTab機能やActionBarなど、実際にさまざまなUIを実現しやすくなった。ライフサイクル管理の難しさや、クラスも３種類（※）もあって紛らわしかったりプログラマを躓かせる要素は多く、Fragment反対論もあったが、今は Android Architecture Components （NavigationConmponentやLifeCycleなど）の登場や kotlin-android-extentions(2020以降は非推奨) によって使いやすくなっている。※Fragment３兄弟：長男 android.app.Fragment次男 android.support.v4.app.Fragment年の離れた三男 androidx.fragment.app.Fragment ViewはFragmentの代わりにならないのか？ 単純に、ViewをFragmentの代わりにできないのか？という話です。ViewはActivityと連動するようなライフサイクルを持たないため、Activityのライフサイクルと連動する必要のある処理を作ろうとすると、ActivityからViewにライフサイクル完了と終了を通知する仕組みを考えなければならず、相当しんどいです。代わりにならないことはないですが、相当しんどいですので、代わりにならないといっても過言ではないです。 タスクとActivityバックスタックの呪縛からの解放 Fragmentができる前までは、Activityのスタック管理が Android の「タスクとバックスタック」管理の仕様と密接に関係しているため、設定を間違えるとバックで戻ったときなどに意図しない画面遷移をしてしまうというような、アプリ間遷移を考慮したアプリ内画面遷移の設計の難しさの問題がありました。Android は、タスクにActivityを積む仕組みで履歴を管理しているが、このタスクというのはアプリに閉じているわけではありません。別のアプリのActivityも同じタスクに積んだり、同じアプリでも別のタスクとして積むことができます。これは、インストールされたapkのActivity（公開されている）というのは Android からみればただのパッケージ名を持ったActivityの集合でしかなく、どのアプリかという厳密な枠組みは持たずに、設定値に準じてスタック管理する仕様だからです。（どういう意図かはわかりませんが。）基本的には同一パッケージ名のActivityがスタックされていく仕様ですが、UIUX検討の中で細かい設定を入れざるを得ない場合があり、そういったときにはどうしてもこの問題にぶつかります。（例えばとあるサービスを利用するためのライブラリが提供するそのサービスのログインUIのActivityが、アプリのActivtiyの起動モードの方針と違う設定で、ライブラリを使う部分だけアプリの意図しない遷移を実現できてしまい、バグの要因になる、とか。抽象的でわかりにくい例かもしれないですが。。。）しかし、FragmentスタックはActivity（または親Fragment）が管理しておりアプリに閉じているため、アプリ内でOSのタスク仕様に依存しないスタック管理がしやすくなりました。 Activity神格化からの解放 プレゼンテーションロジックがActivityに集約されがちで、神オブジェクト化し人間が手を出せなくなることは珍しくありませんでしたが、Fragmentができてから処理が分散され軽減されました。また、今では、MVPアーキテクチャ、MVVMアーキテクチャ、クリーンアーキテクチャなどのアーキテクチャパターンをアプリに適用することで、プレゼンテーションロジックを持つクラスはFragmentとは別に管理しようとすることが主流です。 まとめ こういった理由から（他にもあると思うけど）、ActivityもFragmentの似たような性質はあるけど、Fragmentを使うことで以下の利点が出てきます。 Activityが神オブジェクトから開放され、コードの可読性があがる フレキシブルなUIUXを提供しやすくなる Activityのスタック仕様を意識しなくてよくなる ただし、似たような性質があるので役割を明確にしないとチーム開発では混乱を招きますので役割を明確にするのがよいと思います。個人的には↓のように切り分けるのが好みです。 Activity は Fragment をコントロールする Fragment がUIをコントロールする Activity はアプリ全般（アプリのフォアグラウンド・バックグラウンド）のライフサイクルを管理する Fragmentには画面単位のライフサイクルを管理する 以上です！ 参考 Activity起動モード仕様参考- ＊＊激参考になる＊＊： https://itnext.io/the-android-launchmode-animated-cheatsheet-6657e5dd9b0f https://developer.android.com/guide/components/activities/tasks-and-back-stack?hl=ja …

CleanArchitecture要素のMVVMサンプル作った

on

サンプル 出来上がったサンプル(GitHub) アーキテクチャ図 動機 現場のプロダクトで、内部品質を高めるために定期的なリファクタリング習慣を取り入れて行きたく、リファクタリング計画を作るにあたり、目標とするアーキテクチャをはっきりさせたかった。 アーキテクチャサンプルの概要 CleanArchitecture の考え方を一部取り入れた MVVM です。構成は以下のようなレイヤーのマルチモジュール構成になっています。マルチモジュールにしている理由は依存性をシステム的に制御して人為的なミスによる間違った依存関係を生むのを減らすためです。 モジュール構成と主要ライブラリ app UI、バックグラウンド系のAndroidコンポーネントを持つモジュール 画面遷移: [Navigation Component](https://developer.android.com/guide/navigation?hl=ja) 画像取得: Coil domain ビジネスロジックを持つモジュール ViewModel、LifeCycleのための androidx.lifecycle系 repository データアクセスを持つモジュール Coroutine DB: Room HTTP通信: Retrofit2 JsonParser: Kotshi di DI機能を持つモジュール DI: Koin testlib テスト系の共通クラスを持つモジュール JUnit5: JUnit5 Mock: mockk 以下に、どのようにして上図のようになったかを解説します。(ライブラリはKotlinの言語仕様に合わせて簡単に書けるものやパフォーマンスが良いものを選んでいるつもりです。) アーキテクチャの方針 目指すところとしては、変更しやすいアーキテクチャを目指したいので、変更に特化した考え方の Clean Architecture を参考に考えます。 CleanArchitectureの基本的な考え方の1つである「関心事の分離」により、コンポーネント間、レイヤー間を切り離しを容易にすることで、柔軟性を上げます。関心事の分離の観点は以下の５つで フレームワーク非依存：システムをフレームワークに縛るのではなく、フレームワークをツールとして使う。 テスト可能：ビジネスロジックはUI、DB、外部IFなどがなくてもテストできる。 UI非依存：UIはシステムの他の部分を変更せずとも簡単に変更できる。（例えばビジネスロジック） データベース非依存：例えばOracleをMySQLに簡単に置き換えることができる。 外部エージェント非依存：ビジネスロジックは外部IFの世界を知らなくて良い。 これらを実現するために ソースコードの依存性は上位レベルの方針にだけ向かっていなければならない …