序文
最近、Jetpack/AndroidXでいくつかの新しい技術について学び、さらにブロックチェーンについてもっと学びたいと思ったので、それを統合する簡単なウォレットアプリを書こうと思いました。このプロジェクトは
APP
ビットコイン、イーサリアム、CRO 3コインをサポートし、サポートされているコインを表示するホームページの設定、送金、受信、取引履歴の表示をサポートします。GitHubにコードを投稿しました。
GitHub:Wallet
注意: Android Studio 4.1-betaを使用しているため、Gradleのバージョンが高く、4.1ではコンパイルできない可能性があります。時間的な問題もあり、このプロジェクトはあまり完成度が高くありません。
カスタムプラグイン + includeBuild
プロジェクトの中にdep-versionという依存ライブラリがありますが、これは依存ライブラリのバージョン管理モジュールです。
- org.gradle.api.Plugin
- ビルド.gradle
gradlePlugin {
plugins {
version {
id = 'com.dougie.version'
implementationClass = 'com.dougie.version.DependencyVersionPlugin'
}
}
}
- settings.gralde
includeBuild("dep-version")
- この時点で設定は完了です。次のステップは、オブジェクト kotlin ファイルを作成するために、依存する必要があるライブラリを dep-version に追加することです。
object Other {
const val material = "com.google.android.material:material:1.3.0-alpha01"
const val flexbox = "com.google.android:flexbox:2.0.1"
const val coroutineCore = "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.2"
const val coroutineAndroid = "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.2"
...
}
- 最後に、必要なモジュールで
// kts
plugins {
id("com.dougie.version")
}
// not kts
plugins {
id "com.dougie.version"
}
dependencies {
api("org.jetbrains.kotlin:kotlin-stdlib:${BuildConfig.kotlinVersion}")
api(AndroidX.coreKtx)
api(AndroidX.startup)
api(AndroidX.constraintLayout)
api(Other.material)
api(Other.Retrofit.retrofit)
api(Other.Retrofit.moshi)
api(Other.okHttpLogger)
api(Other.coroutineCore)
api(Other.coroutineAndroid)
...
}
ここでapiが使われているのは、ライブラリを使う必要があるときにゼロから新しい依存関係を追加する必要がないからです。
Activity Result API
Google公式ドキュメントより引用
基礎となる startActivityForResult() および onActivityResult() API は、すべての API レベルで Activity クラスで利用可能です。AndroidX Activity 1.2.0-alpha02およびFragment 1.3.0-alpha02で導入されたActivity Result APIを使用することを強く推奨します。
startActivityForResult()とonActivityResult()をAndroidXの新しいAPIに置き換えることです。
このプロジェクトはNavigation Componentを使っているため、onActivityResultが必要な状況は少し面倒なので、この新しいAPIはこの問題を解決するために、よりエレガントです。権限要求Contractの追加に続いて、より便利なものもあります。詳細については、公式ウェブサイトの更新参照してください
MVVM
MVVMアーキテクチャのために非常に精通している必要があり、MVVMは、モデル-ビュー-ビューモデルに対応するM / V / VMに分割
- モデルとは、インターフェイスをレンダリングするために使われる状態やプロパティで、インターフェイスのさまざまなコンポーネントのレンダリング結果を駆動するために使われるものだと考えたいのです。
- 細かく言うと、android.viewのViewのことです。もっと大きく言うと、多くの人が理解しているように、Fragment/Activityのことです。 いずれにせよ、Fragment/ActivityであろうがViewであろうが、ユーザーに表示するためのものです。
- ViewModelは、名前を見て、1つの単語に最初の2つの組み合わせですので、ビューとモデルの間の赤線として理解されています。過去、LiveDataがない時、この層は、データ・モデルとViewの関係を駆動するために、ViewInterfaceインターフェイスを保持する必要がありました。そのため、データ・ソースはRepository/DataSourceレイヤーに抽出することができ、このレイヤーは主にデータがRemoteDBからかLocalDBからかを管理します。
最後に、MVVMのために、私は使用するいくつかのアイデアを持っています：
- ビューはロジックを必要としません。
- ビューのレンダリングはモデルによって駆動される必要があるため、このレイヤーをモデル化すると、インターフェイスのニーズに応じて定義することができ、パブリックまたはユニークなパッケージを考慮し、また、MVIの状態を考えることができます。
- ViewModelは、データソースの結果だけを気にし、それがどこから来たかを知る必要はありません。Viewのレンダリングを駆動するためにModelとLiveDataを介して結果を取得することは良いことです。
不正確な点は遠慮なくご指摘ください。
