debug panel
1.0.0
Das Hauptziel dieser Bibliothek ist es, eine Klassendefinition in Ihrem gemeinsamen Code zu haben, die angibt, wie das Debug -Panel erstellt werden soll. Mit dieser Definition generiert die Bibliothek:
Die durch den Anwendungsfall erstellte Ansichtsdatenliste kann an ein integriertes Ansichtsmodell übergeben werden, das die Benutzerinteraktionen übernimmt. Sie haben die Wahl, entweder die Standard -Benutzeroberfläche zu verwenden, die mit der Bibliothek geliefert wird, oder um Ihre eigenen zu erstellen.
Die Bibliothek wird im öffentlichen Maven -Repository von Mirego veröffentlicht. Stellen Sie daher sicher, dass Sie es in Ihre dependencyResolutionManagement enthalten.
dependencyResolutionManagement {
repositories {
// ...
maven( " https://s3.amazonaws.com/mirego-maven/public " )
}
}Fügen Sie in Ihrem obersten Aufbau von Build.gradle.KTS-Datei den Verweis auf das KSP-Plugin hinzu:
plugins {
// ...
id( " com.google.devtools.ksp " ) version " 1.9.21-1.0.15 " apply false
}Fügen Sie in der Datei Ihres gemeinsamen Moduls Build.gradle.KTS die Referenz zum KSP -Plugin hinzu:
plugins {
// ...
id( " com.google.devtools.ksp " )
} Fügen Sie auch die Abhängigkeiten von core und annotations zusammen mit dem KSP -generierten Quellverzeichnis hinzu:
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 " )
}Vergessen Sie nicht, die Kernabhängigkeit in das iOS -Framework zu exportieren:
kotlin {
cocoapods {
framework {
// ...
export( " com.mirego.trikot:viewmodels-declarative-flow:x.y.z " )
export( " com.mirego.debugpanel:core:x.y.z " )
}
}
}Sie müssen auch den Verweis des Compilers auf den Abhängigkeitsblock hinzufügen:
dependencies {
add( " kspCommonMainMetadata " , " com.mirego.debugpanel:compiler:x.y.z " )
} Die Beispiel -Benutzeroberfläche wird automatisch aus dem gemeinsamen Modul aufgelöst, da wir die Bibliothek mit der Funktion api() einbeziehen.
Wenn Sie während der Kompilierung einige Probleme mit einer doppelten META-INF/versions/9/previous-compilation-data.bin Datei haben, können Sie sie den ausgeschlossenen Ressourcen in der Datei "Build.gradle.KTS" der Android-App hinzufügen:
android {
packaging {
resources {
excludes + = listOf (
" META-INF/versions/9/previous-compilation-data.bin "
)
}
}
}Wenn Sie die Muster -Benutzeroberfläche auf iOS verwenden möchten, fügen Sie die POD in die Podfile der Anwendung auf:
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
Erstellen Sie im Modul Ihres Common eine Klasse mit der @Debugpanel -Annotation. Sie finden die verschiedenen Komponenten, die in der folgenden Tabelle verfügbar sind.
@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
) Sobald die Konfiguration abgeschlossen ist, können Sie die kspCommonMainMetadata Gradle -Aufgabe ausführen, um die spezifischen Dateien für Ihr Projekt zu generieren.
Sie sollten jetzt MyProjectDebugPanelUseCase.kt , MyProjectDebugPanelUseCaseImpl.kt , MyProjectDebugPanelRepository.kt und MyProjectDebugPanelRepositoryImpl.kt haben.
Alles, was Sie jetzt tun müssen, ist, die Implementierungen zu instanziieren:
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 */ )
)
} Sie können die Sichtbarkeit der einzelnen Komponenten im componentsVisibility der Funktion createViewData() steuern.
Beispiel:
useCase.createViewData(
/* ... */
componentsVisibility = flowOf(
MyProjectDebugPanelComponentsVisibility (
button1 = false ,
button2 = true ,
)
)
) In diesem Fall wird button1 versteckt und button2 ist sichtbar.
| Name | Den Datentyp bestanden | Konfiguration |
|---|---|---|
| Debugpaneltoggle | Boolean | Anfänglicher Boolean Wert |
| Debugpanellabel | - - | Flow<String> |
| Debugpaneltextfield | String | String |
| Debugpanelbutton | - - | Initial () -> Unit Einheitswert |
| Debugpanelpicker | String | String , der die ausgewählte Elementkennung darstellt |
| Debugpaneldatepicker | Long | Erst Long Wert, der die Epoche in Millisekunden darstellt |
| Aufreum | String | Anfänglicher Umlaufwert |
Das Debug -Panel wird mit dem @DebugPanel(val prefix: String, val packageName: String) -Notation konfiguriert.
prefix ist in den generierten Anwendungsfall- und Repository -Klassen enthalten.packageName ist, an dem die Dateien im generated Ordner ausgegeben werden. Standardmäßig werden die Werte in den Einstellungen unter Verwendung ihres Feldnamens als Kennung gespeichert. Dieses Verhalten kann jedoch mit der Annotation @Identifier(val value: String) überschrieben werden.
Ausführlich ist dies nützlich für den Fall, in dem Sie ein altes Debug -Panel durch dieses ersetzen und die Originalschlüssel aufbewahren möchten.
Beispiel:
@Identifier( " PREVIEW_MODE " )
val preview : DebugPanelToggle Standardmäßig werden die Komponenten neben einem Etikett mit dem Feldnamen als Wert angezeigt. Sie können die Annotation @DisplayName(val value: String) verwenden, um den Komponenten ein aussagekräftigeres Etikett zu geben.
Beispiel:
@DisplayName( " Preview Mode " )
val preview : DebugPanelToggle Sie können die Annotation von @DebugProperty(val name: String) verwenden, um eine Komponente zu generieren, die an eine Klasseneigenschaft gebunden ist.
Sie können beispielsweise ein Repository mit einer String oder Flow<String> -Meigenschaft haben. Durch die Annotation auf das Feld wird die Bibliothek eine Delegierte -Eigenschaft generiert.
Sie können dieses Delegierfeld dann in der Schnittstelle aufdecken, und der Anrufer erhält entweder Ihren internen Wert oder den einen aus dem Debug -Panel (für den Fall, in dem er überschrieben ist).
Bitte beachten Sie, dass diese Annotation nur mit den Typen verwendet werden kann: String , Boolean , Enum , Flow<String> , Flow<Boolean> und Flow<Enum> .
Beispiel:
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
}Anrufer:
val repository : Repository = RepositoryImpl ()
repository.value.map {
println ( " Repository value: $it " )
} Dies wird entweder gedruckt
Repository value: String value oder Repository value: Overridden value Abhängig ob Overridden value im Feld generiertes Text eingegeben wurde.
Das generierte Repository verfügt über eine methodie resetSettings() , die Sie aufrufen können, um die anhaltenden Komponentenwerte zu löschen. Bitte beachten Sie, dass die Modelle der Debug -Panel -Ansicht nicht an diese Werte gebunden sind. Sie müssen daher entweder den Debug -Panel -Bildschirm beenden oder die Anwendung abtöten, um sicherzustellen, dass die Werte ordnungsgemäß zurückgesetzt werden (siehe RootViewModelImpl.kt im Beispiel -Anwendungsordner).
Die generierten Anwendungsfall- und Repository -Implementierungen haben den open Modifikator. Dies bedeutet, dass Sie sie erweitern können, um bei Bedarf weitere Funktionen hinzuzufügen.
Wenn Ihr Projekt eine Abhängigkeitsinjektionsbibliothek wie Koin hat und Sie über Ihre eigenen erweiterten Klassen verfügen, können Sie sie entweder mit @Factory oder @Single kommentieren.
Wenn Sie diese Klassen nicht außer Kraft setzen müssen, können Sie sie einfach manuell in die Injektionsmodule der Abhängigkeiten einfügen.
Das Debug-Panel ist © 2013-2023 Mirego und kann unter der neuen BSD-Lizenz frei verteilt werden. Siehe die LICENSE.md -Datei.
Mirego ist ein Team von leidenschaftlichen Menschen, die glauben, dass die Arbeit ein Ort ist, an dem Sie innovativ sind und Spaß haben können. Wir sind ein Team von talentierten Leuten, die sich vorstellen und schöne Web- und mobile Anwendungen erstellen. Wir kommen zusammen, um Ideen zu teilen und die Welt zu verändern.
Wir lieben auch Open-Source-Software und versuchen, der Community so viel wie möglich zurückzugeben.
