debug panel
1.0.0
L'objectif principal de cette bibliothèque est d'avoir une définition de classe dans votre code commun qui spécifie comment le panneau de débogage doit être construit. En utilisant cette définition, la bibliothèque génère:
La liste de données de vue créée par le cas d'utilisation peut être transmise à un modèle de vue intégré qui gère les interactions utilisateur. Vous avez le choix d'utiliser l'interface utilisateur par défaut qui est livré avec la bibliothèque ou de construire le vôtre.
La bibliothèque est publiée dans le référentiel Maven public de Mirego, alors assurez-vous que vous l'avez inclus dans votre bloc Settings.gradle.kts dependencyResolutionManagement Management Block.
dependencyResolutionManagement {
repositories {
// ...
maven( " https://s3.amazonaws.com/mirego-maven/public " )
}
}Dans votre fichier build.gradle.kts de niveau supérieur, ajoutez la référence au plugin KSP:
plugins {
// ...
id( " com.google.devtools.ksp " ) version " 1.9.21-1.0.15 " apply false
}Dans le fichier Build.gradle.kts de votre module commun Ajoutez la référence au plugin KSP:
plugins {
// ...
id( " com.google.devtools.ksp " )
} Ajoutez également les dépendances core et annotations avec le répertoire source généré par KSP:
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 " )
}N'oubliez pas d'exporter la dépendance principale vers le framework iOS:
kotlin {
cocoapods {
framework {
// ...
export( " com.mirego.trikot:viewmodels-declarative-flow:x.y.z " )
export( " com.mirego.debugpanel:core:x.y.z " )
}
}
}Vous devez également ajouter la référence du compilateur au bloc des dépendances:
dependencies {
add( " kspCommonMainMetadata " , " com.mirego.debugpanel:compiler:x.y.z " )
} L'interface utilisateur de l'échantillon est résolu automatiquement à partir du module commun car nous incluons la bibliothèque avec la fonction api() .
Si vous avez des problèmes avec un META-INF/versions/9/previous-compilation-data.bin pendant la compilation, vous pouvez l'ajouter aux ressources exclues dans le fichier build.gradle.kts de l'application Android:
android {
packaging {
resources {
excludes + = listOf (
" META-INF/versions/9/previous-compilation-data.bin "
)
}
}
}Si vous souhaitez utiliser l'échantillon d'interface utilisateur sur iOS, incluez le pod dans le podfile de l'application:
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
Dans le module de votre commun, créez une classe avec l'annotation @debugpanel. Vous pouvez trouver les différents composants disponibles dans le tableau ci-dessous.
@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
) Une fois la configuration terminée, vous pouvez exécuter la tâche kspCommonMainMetadata Gradle pour générer les fichiers spécifiques pour votre projet.
Vous devriez maintenant avoir MyProjectDebugPanelUseCase.kt , MyProjectDebugPanelUseCaseImpl.kt , MyProjectDebugPanelRepository.kt et MyProjectDebugPanelRepositoryImpl.kt disponibles dans votre classpath.
Tout ce que vous avez à faire maintenant est d'instancier les implémentations:
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 */ )
)
} Vous pouvez contrôler la visibilité de chaque composant dans le paramètre componentsVisibility de la fonction createViewData() .
Exemple:
useCase.createViewData(
/* ... */
componentsVisibility = flowOf(
MyProjectDebugPanelComponentsVisibility (
button1 = false ,
button2 = true ,
)
)
) Dans ce cas, button1 sera masqué et button2 sera visible.
| Nom | Type de données persistant | Configuration |
|---|---|---|
| Debugpaneltoggle | Boolean | Valeur Boolean initiale |
| Debugpanellabel | - | Flow<String> |
| DebugpanelTextfield | String | Valeur String initiale |
| Debugpanelbutton | - | Initial () -> Unit |
| Debugpanelpicker | String | Valeur String initiale représentant l'identifiant d'élément sélectionné |
| Debugpaneldatepicker | Long | Valeur Long initiale représentant l'époque en millisecondes |
| Énumérer | String | Valeur d'énumération initiale |
Le panneau de débogage est configuré à l'aide de l'annotation @DebugPanel(val prefix: String, val packageName: String) .
prefix est inclus dans le cas d'utilisation généré et les classes de référentiel.packageName est l'endroit où les fichiers seront sortis dans le dossier generated . Par défaut, les valeurs sont enregistrées dans les paramètres en utilisant leur nom de champ en tant qu'identifiant. Cependant, ce comportement peut être remplacé à l'aide de l'annotation @Identifier(val value: String) .
Pour l'exemple, cela est utile dans le cas où vous voudriez remplacer un ancien panneau de débogage par celui-ci et conserver les clés d'origine.
Exemple:
@Identifier( " PREVIEW_MODE " )
val preview : DebugPanelToggle Par défaut, les composants s'affichent à côté d'une étiquette avec le nom de champ comme valeur. Vous pouvez utiliser l'annotation @DisplayName(val value: String) pour donner aux composants une étiquette plus significative.
Exemple:
@DisplayName( " Preview Mode " )
val preview : DebugPanelToggle Vous pouvez utiliser l'annotation @DebugProperty(val name: String) pour générer un composant lié à une propriété de classe.
Par exemple, vous pouvez avoir un référentiel avec une propriété String ou Flow<String> , et en mettant l'annotation sur le terrain, la bibliothèque générera une propriété déléguée.
Vous pouvez ensuite exposer ce champ de délégué dans l'interface et l'appelant recevra votre valeur interne ou celle du panneau de débogage (dans le cas où il est remplacé).
Veuillez noter que cette annotation ne peut être utilisée qu'avec les types: String , Boolean , Enum , Flow<String> , Flow<Boolean> et Flow<Enum> .
Exemple:
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
}Demandeur:
val repository : Repository = RepositoryImpl ()
repository.value.map {
println ( " Repository value: $it " )
} Cela imprimera soit
Repository value: String value ou Repository value: Overridden value en fonction si Overridden value a été entrée dans le champ de texte généré.
Le référentiel généré est livré avec une méthode resetSettings() que vous pouvez appeler afin d'effacer les valeurs de composants persistantes. Veuillez noter que les modèles de vue du panneau de débogage ne sont pas liés à ces valeurs, vous devrez donc soit quitter l'écran du panneau de débogage ou tuer l'application pour vous assurer que les valeurs sont correctement réinitialisées (voir RootViewModelImpl.kt dans l'exemple de dossier d'application).
Le cas d'utilisation généré et les implémentations du référentiel ont le modificateur open , ce qui signifie que vous pouvez les étendre pour ajouter plus de fonctionnalités si vous en avez besoin.
Si votre projet dispose d'une bibliothèque d'injection de dépendance comme KOIN et que vous avez vos propres classes étendues, vous pouvez les annoter avec @Factory ou @Single .
Si vous n'avez pas besoin de remplacer ces classes, vous pouvez simplement les mettre manuellement dans les modules d'injection de dépendances.
Le panneau de débogage est © 2013-2023 Mirego et peut être distribué librement dans le cadre de la nouvelle licence BSD. Voir le fichier LICENSE.md .
Mirego est une équipe de personnes passionnées qui croient que le travail est un endroit où vous pouvez innover et vous amuser. Nous sommes une équipe de personnes talentueuses qui imaginent et construisent de belles applications Web et mobiles. Nous nous réunissons pour partager des idées et changer le monde.
Nous aimons également les logiciels open source et nous essayons de redonner à la communauté autant que possible.
