このライブラリの主な目標は、デバッグパネルの構築方法を指定する共通コードにクラス定義を作成することです。この定義を使用して、ライブラリは次のことを生成します。
ユースケースによって作成されたビューデータリストは、ユーザーインタラクションを処理するビルトインビューモデルに渡すことができます。ライブラリに付属のデフォルトのUIを使用するか、独自のデフォルトのUIを使用するかを選択できます。
ライブラリはMiregoのPublic Mavenリポジトリに公開されているため、 dependencyResolutionManagementに含まれていることを確認してください。
dependencyResolutionManagement {
repositories {
// ...
maven( " https://s3.amazonaws.com/mirego-maven/public " )
}
}トップレベルのbuild.gradle.ktsファイルで、KSPプラグインへの参照を追加します。
plugins {
// ...
id( " com.google.devtools.ksp " ) version " 1.9.21-1.0.15 " apply false
}Common Moduleのbuild.gradle.ktsファイルで、KSPプラグインへの参照を追加します。
plugins {
// ...
id( " com.google.devtools.ksp " )
}また、KSP生成されたソースディレクトリとともに、 coreとannotations依存関係を追加します。
val commonMain by getting {
dependencies {
// ...
api( " com.mirego.trikot:viewmodels-declarative-flow:x.y.z " )
api( " com.mirego.debugpanel:core:x.y.z " )
implementation( " com.mirego.debugpanel:annotations:x.y.z " )
}
kotlin.srcDir( " build/generated/ksp/metadata/commonMain/kotlin " )
}コア依存関係をiOSフレームワークにエクスポートすることを忘れないでください。
kotlin {
cocoapods {
framework {
// ...
export( " com.mirego.trikot:viewmodels-declarative-flow:x.y.z " )
export( " com.mirego.debugpanel:core:x.y.z " )
}
}
}また、コンパイラの参照を依存関係ブロックに追加する必要があります。
dependencies {
add( " kspCommonMainMetadata " , " com.mirego.debugpanel:compiler:x.y.z " )
}サンプルUIはapi()関数にライブラリを含めるため、共通モジュールから自動的に解決されます。
コンピレーション中に複製されたMETA-INF/versions/9/previous-compilation-data.binファイルにいくつかの問題がある場合は、Androidアプリのbuild.gradle.ktsファイル内の除外されたリソースに追加できます。
android {
packaging {
resources {
excludes + = listOf (
" META-INF/versions/9/previous-compilation-data.bin "
)
}
}
}iOSでサンプルUIを使用する場合は、アプリケーションのPodfileにポッドを含めます。
pod 'Trikot/viewmodels.declarative.SwiftUI.flow', :git => '[email protected]:mirego/trikot.git', :tag => 'x.y.z', :inhibit_warnings => true
pod 'DebugPanel', :git => '[email protected]:mirego/debug-panel.git', :tag => 'x.y.z', :inhibit_warnings => true
Common's Moduleで、@debugpanel Annotationを使用してクラスを作成します。以下の表にあるさまざまなコンポーネントを見つけることができます。
@DebugPanel(prefix = " MyProject " , packageName = " com.myproject.app.generated " )
data class DebugPanelConfig (
val toggle : DebugPanelToggle ,
val label : DebugPanelLabel ,
val textField : DebugPanelTextField ,
val button : DebugPanelButton ,
val picker : DebugPanelPicker ,
val datePicker : DebugPanelDatePicker ,
val enumPicker : SomeEnum
)構成が完了したら、 kspCommonMainMetadata Gradleタスクを実行して、プロジェクトの特定のファイルを生成できます。
これで、 MyProjectDebugPanelUseCase.kt 、 MyProjectDebugPanelUseCaseImpl.kt 、 MyProjectDebugPanelRepository.kt 、およびMyProjectDebugPanelRepositoryImpl.ktをクラスパスで入手できます。
今やる必要があるのは、実装をインスタンス化することだけです。
private val repository : MyProjectDebugPanelRepository = MyProjectDebugPanelRepositoryImpl ()
private val useCase : MyProjectDebugPanelUseCase = MyProjectDebugPanelUseCaseImpl (repository)
/* ... */
class ParentViewModelImpl (
coroutineScope : CoroutineScope ,
useCase : MyProjectDebugPanelUseCase
) : ParentViewModel, VMDViewModelImpl(coroutineScope) {
override val debugPanel = DebugPanelViewModelImpl (
coroutineScope,
useCase,
useCase.createViewData( /* Configure the components here */ )
)
} createViewData()関数のcomponentsVisibilityパラメーターの各コンポーネントの可視性を制御できます。
例:
useCase.createViewData(
/* ... */
componentsVisibility = flowOf(
MyProjectDebugPanelComponentsVisibility (
button1 = false ,
button2 = true ,
)
)
)この場合、 button1が非表示になり、 button2が表示されます。
| 名前 | 永続的なデータ型 | 構成 |
|---|---|---|
| debugpaneltoggle | Boolean | 初期Boolean値 |
| Debugpanellabel | - | Flow<String> |
| debugpaneltextfield | String | 初期String値 |
| Debugpanelbutton | - | initial () -> Unit値 |
| debugpanelpicker | String | 選択したアイテム識別子を表す初期String値 |
| debugpaneldatepicker | Long | ミリ秒単位でエポックを表す初期のLong値 |
| 列挙 | String | 初期列挙値 |
デバッグパネルは@DebugPanel(val prefix: String, val packageName: String) annotationを使用して構成されています。
prefix 、生成されたユースケースおよびリポジトリクラスに含まれています。packageNameは、ファイルがgeneratedフォルダー内に出力される場所です。 デフォルトでは、値は識別子としてフィールド名を使用して設定に保存されます。ただし、この動作は@Identifier(val value: String) Annotationを使用してオーバーライドできます。
例として、これは古いデバッグパネルをこれに置き換えて元のキーを保持する場合に役立ちます。
例:
@Identifier( " PREVIEW_MODE " )
val preview : DebugPanelToggle デフォルトでは、コンポーネントは、フィールド名が値としてラベルの横に表示されます。 @DisplayName(val value: String) annotationを使用して、コンポーネントにより意味のあるラベルを与えることができます。
例:
@DisplayName( " Preview Mode " )
val preview : DebugPanelToggle @DebugProperty(val name: String) annotationを使用して、クラスプロパティにバインドされているコンポーネントを生成できます。
たとえば、 StringまたはFlow<String>プロパティを備えたリポジトリを使用でき、アノテーションをフィールドに配置することにより、ライブラリがデリゲートプロパティを生成します。
その後、インターフェイス内のこのデリゲートフィールドを公開すると、発信者は内部値またはデバッグパネルからのフィールドを受け取ることができます(それがオーバーライドされている場合)。
このアノテーションは、 String 、 Boolean 、 Enum 、 Flow<String> 、 Flow<Boolean> 、およびFlow<Enum>のタイプでのみ使用できます。
例:
Repository.kt
interface Repository {
val value : Flow < String >
} RepositoryImpl.kt
class RepositoryImpl : Repository {
@Identifier( " custom_value_identifier " )
@DebugProperty( " value " )
val internalValue = flowOf( " String value " )
override val value by RepositoryImplValueDelegate
}発信者:
val repository : Repository = RepositoryImpl ()
repository.value.map {
println ( " Repository value: $it " )
}これはどちらかを印刷しますRepository value: String valueまたはRepository value: Overridden value Overridden valueが生成されたテキストフィールド内に入力されているかどうかに応じて。
生成されたリポジトリには、永続化されたコンポーネント値をクリアするために呼び出すことができるresetSettings()メソッドが付属しています。デバッグパネルビューモデルがこれらの値にバインドされていないことに注意してください。したがって、デバッグパネル画面を終了するか、アプリケーションを殺して、値が適切にリセットされていることを確認する必要があります(サンプルアプリケーションフォルダーのRootViewModelImpl.ktを参照)。
生成されたユースケースとリポジトリの実装には、 openモディファイアがあります。つまり、必要に応じて機能を追加するように拡張できます。
プロジェクトにはKoinのような依存噴射ライブラリがあり、独自の拡張クラスがある場合は、 @Factoryまたは@Singleいずれかで注釈を付けることができます。
これらのクラスをオーバーライドする必要がない場合は、依存関係の注入モジュールに手動で配置することができます。
デバッグパネルは©2013-2023 Miregoであり、新しいBSDライセンスの下で自由に配布される場合があります。 LICENSE.mdファイルを参照してください。
Miregoは、仕事はあなたが革新して楽しむことができる場所だと信じている情熱的な人々のチームです。私たちは、美しいウェブとモバイルのアプリケーションを想像し、構築する才能のある人々のチームです。私たちは一緒になってアイデアを共有し、世界を変えます。
また、オープンソースソフトウェアが大好きで、できる限りコミュニティに恩返しをしようとしています。