Comment créer un menu d’ingénierie qui répond à vos besoins avec Flutter | par Evgueni Landarsky

Un guide étape par étape pour créer un menu d’ingénierie efficace

Le sujet d’aujourd’hui est le menu d’ingénierie. Certains d’entre vous le connaissent peut-être en tant que menu pour les développeurs ou menu de débogage. Ce n’est pas un sujet brûlant dans le monde du développement mobile, mais dans la plupart des cas, un bon menu d’ingénierie peut ne pas réduire de manière significative mais très sensiblement le temps de développement et de test manuel.

Dans cet article, nous examinerons différentes façons d’organiser un écran spécial qui vous aidera, vous et votre équipe, à donner plus de contrôle pour manipuler et observer les données qui sont hors de vue de l’utilisateur final, telles que les points de terminaison du serveur, le statut premium, le jeton FCM. accès, localisations, logs, actions spécifiques pour déclencher certains scénarios, etc.

Cet article n’est pas réservé aux développeurs Flutter. Toute idée de ce sujet peut être appliquée à toute autre plate-forme mobile.

Dans les exemples suivants, nous utiliserons des packages tiers pour aider à développer plus rapidement le menu d’ingénierie. Les extraits de code avec des bibliothèques tierces incluront un package d’importation en haut afin que vous puissiez trouver des informations détaillées à ce sujet dans un pub.dev.

Si vous souhaitez utiliser une autre solution pour créer un menu d’ingénierie, ou si vous en avez déjà un, vous pouvez vérifier les idées et les mettre en œuvre dans votre projet si vous pensez qu’elles peuvent vous aider.

Il n’y a pas de différence là où vous placez le point d’entrée de votre menu d’ingénierie – n’importe quel endroit est OK. Vous ne devez vous soucier que de deux choses : le cacher dans votre version de production et éviter de modifier de manière significative l’interface utilisateur de l’application à un endroit où vous mettez le contrôle d’entrée.
Dans cet exemple, nous le plaçons juste après les autres sections de l’écran des paramètres.

L’écran des paramètres est un endroit logique pour mettre cette option, mais comme nous en avons discuté, vous pouvez choisir n’importe quel autre endroit. Et encore une fois, n’oubliez pas d’ajouter la vérification. Voici comment procéder :

Peu importe la voie que vous choisissez; la meilleure option consiste à ouvrir un écran séparé ou une boîte de dialogue contextuelle et à y placer tous les paramètres à des fins de débogage.

Avant d’aller plus loin, examinons les informations dont nous pourrions avoir besoin. Globalement, nous pouvons diviser les informations en trois classes :

• statique dans une production, modifiable dans les versions de débogage (valeurs par défaut prédéfinies, par exemple, point de terminaison)
• juste des informations, sans possibilité de modification (informations sur l’appareil, jeton FCM, etc.)
• actions qui peuvent effectuer certains travaux ou réinitialiser certaines valeurs par défaut (réinitialiser les drapeaux, ouvrir l’écran d’abonnement, etc.)

Les deux derniers points sont assez clairs. Par exemple, lorsque nous affichons des informations, nous devons donner accès aux données du fournisseur et les afficher dans un bloc sur l’interface utilisateur. Une chose assez similaire lorsque nous travaillons avec des actions – nous avons besoin d’accéder à l’exécuteur qui agira. Le premier est un peu compliqué, alors découvrons-le.

Comme de nombreuses parties de cet article, il peut avoir un autre nom, mais l’idée est de fournir un point d’entrée que vous pouvez utiliser en mode débogage et utiliser en toute sécurité en mode production. Pour y parvenir, nous pouvons construire une classe avec des méthodes qui renverront toutes les valeurs modifiables en mode débogage :

Malheureusement, nous ne pouvons pas faire des types de retour qui ne sont pas un Future car dans l’implémentation de débogage, nous devons stocker les valeurs dans le stockage interne. Mais, comme avantage, cela nous permet d’utiliser la configuration à distance pour certaines (ou toutes) propriétés.

Notre implémentation de débogage héritera de notre production et ajoutera quelques méthodes pour modifier et stocker les valeurs que nous définirons. Voici le code :

Donc, maintenant, nous devrions ajouter quelques méthodes à la Environment class pour résoudre le mode débogage et renvoyer une instance valide de l’environnement :

Cet extrait garantit que le travail avec les propriétés de débogage ne fonctionnera pas dans un code de production. L’option DI est également possible, mais dans notre exemple, nous ne compliquerons pas la solution pour nous concentrer sur d’autres détails.

Une des sections les plus utiles (bien sûr, si vous avez un backend). De quoi ça a l’air? Par exemple, sous forme de bloc extensible, comme dans l’image ci-dessous :

Voici à quoi ressemble le code :

Une autre chose qui peut être très utile est de forcer le statut premium de l’utilisateur. Cette option permet de donner très rapidement accès à des fonctionnalités premium sans nécessiter de compte de test.

L’extrait de code ci-dessous montre comment nous pouvons l’implémenter dans notre Environment classe:

Vous pouvez remarquer que PremiumMode peut être l’une des trois valeurs suivantes : app, premiumet free. Les options premium et gratuites sont des options de force qui doivent basculer l’application dans un mode spécifique, alors que l’application est une valeur spécifique, ce qui indique que la logique pour détecter le statut premium doit être effectuée à un autre endroit. Quel est l’endroit ? Habituellement, le gestionnaire de facturation de l’application est responsable du traitement des achats, de la validation des reçus, etc.

Et voici notre widget UI :

Une partie très variée est celle des actions. Quel type d’actions peut-on mettre dans cette catégorie ? Il existe deux grandes catégories :

• réinitialiser certaines données – indicateur d’enquête d’intégration, distribution de tests A / B, nombre de tentatives restantes pour votre fonctionnalité premium, etc.
• appeler certaines actions – afficher l’écran d’abonnement, envoyer des notifications pour vérifier le lien profond, envoyer des demandes spécifiques à un serveur, exécuter la mise à jour des données en arrière-plan, etc.

Lequel d’entre eux vous allez implémenter dépend de la fonctionnalité de votre application.

Bien sûr, vous pouvez obtenir ces informations depuis la console, mais c’est très pratique pour accéder à cette valeur, même si vous n’avez pas d’ordinateur portable.

Le debug_bricks_fcm_token package vous permet d’afficher un bloc au-dessus dans une ligne de code :

Ce composant affiche le jeton FCM, le copie dans le presse-papiers et l’imprime sur la console si vous appuyez sur le contrôle de l’interface utilisateur.

Parfois, cela peut être très utile lorsque vous avez un écran avec des journaux, surtout si vous remarquez un problème quelque part en dehors de votre lieu de travail. Comme d’habitude, il y a beaucoup de solutions, mais dans notre échantillon, nous avons utilisé le talker_flutter package, qui est assez facile à intégrer et a une sortie lisible.

Ces informations peuvent être utiles si vous travaillez dans une grande équipe. Nous connaissons toujours toutes les informations sur l’appareil lorsqu’un crash se produit. Mais lorsque nous sommes confrontés à un problème d’interface utilisateur imprévisible, il est très important de connaître les principales caractéristiques de l’appareil (très souvent, avoir l’appareil et la version actuelle du SDK suffisent pour obtenir toutes les autres informations) :

Le debug_bricks_device_info package permet d’afficher des informations sur une seule ligne de code :

Sous le capot, le package utilise un autre package, device_info_plus, et offre la possibilité de personnaliser votre sortie. Cliquer sur le contrôle de l’interface utilisateur copie également les données dans le presse-papiers et les imprime sur la console.

Cette option est utile si votre application ne donne pas aux utilisateurs le contrôle explicite pour changer la langue.

Flutter ne fournit pas de règles strictes pour organiser vos fichiers de localisation, mais certains packages populaires le font. L’un de ces forfaits est easy_localization. Ce package fournit des fonctionnalités très riches pour maintenir vos localisations. Nous pouvons intégrer le contrôle de l’interface utilisateur dans l’image ci-dessus par le code suivant :

Si vous implémentez une autre solution pour travailler avec les localisations, vous pouvez créer vous-même ce contrôle, mais comme nous l’avons remarqué au début de l’article, ce n’est qu’une idée.

Une autre bonne idée est d’intégrer un écran avec un accès complet à toutes les clés et traductions pour aider l’équipe de localisation à suivre et vérifier les implémentations. Si tu utilises easy_localizationvous pouvez également utiliser le LocalizationsTable widget de la debug_bricks_easy_localization forfait:

Le code ci-dessus affiche le tableau suivant :

Donc, nous venons d’explorer quelques sections principales du menu d’ingénierie qui pourraient être utiles pendant votre processus de développement, résumons-les :

• points de terminaison du serveur
• statut premium
• Actions
• Jeton FCM
• enregistrement
• Info appareil
• localisations

Bien sûr, chaque application est unique et vous constaterez peut-être que la plupart des idées couvertes ne correspondent pas à vos besoins, et ce n’est pas grave. La chose la plus importante ici est que j’espère que cet article vous aidera à trouver des idées qui répondront à vos besoins. N’oubliez pas que dès que possible, vous créez un menu d’ingénierie dans votre application, ce qui permet à votre équipe de gagner du temps.

Voici le code complet d’un exemple de projet sur GitHub :

Quelles options « indispensables » avez-vous dans votre application ? Partagez votre expérience dans les commentaires ci-dessous et profitez du codage.