Custom Android app development with Kotlin

Androïde-l'application vous permet de transférer des services clés, des ventes, du service client ou des processus internes vers un appareil mobile. Sur DitWork, vous pouvez comparer les développeurs par expérience de plateforme, architecture, qualité des questions, tests, publication et support continu. Pour une évaluation précise, il est important de décrire non seulement la liste des écrans, mais également les rôles des utilisateurs, la source de données, les intégrations requises, les appareils pris en charge, le fonctionnement hors ligne et les résultats mesurables de la première version.

Quelles applications pouvez-vous commander ?

Dans la catégorie « Android », vous pouvez commander des applications Android MVP et commerciales, des comptes personnels et des applications pour les employés, des magasins, des catalogues et des programmes de fidélité, des applications avec caméra, cartes, NFC et Bluetooth, l'intégration avec API, CRM et paiements, ainsi que la mise à jour, la migration et la correction d'un projet Android existant. Tout d’abord, séparez le MVP indispensable des fonctionnalités des futures versions. Pour chaque scénario, indiquez qui initie l'action, quelles données sont saisies, quelle réponse est attendue, que se passe-t-il en cas d'erreur et où le résultat est stocké. Ce niveau de granularité permet d'éviter que l'estimation du projet ne devienne une multiplication approximative du nombre d'écrans.

• Applications Android MVP et commerciales
• comptes personnels et applications pour les employés
• magasins, catalogues et programmes de fidélité
• applications avec appareil photo, cartes, NFC et Bluetooth
• intégration avec API, CRM et paiements
• mettre à jour, migrer et corriger un projet Android existant

Résultat par étapes

Ce qu'il faut inclure dans les spécifications techniques

Pour préparer la mission, collectez l'objectif du produit et les rôles des utilisateurs, les écrans clés et les scénarios d'utilisation, la version minimale d'Android et les types d'appareils, les mises en page ou les exigences d'interface, la description de l'API, l'autorisation et les données, les paiements, les processus push et en arrière-plan et les critères MVP et les plans de versions futures. Ne publiez pas de vrais mots de passe, clés de signature, jetons, bases de données client ou informations personnelles. Joignez des exemples anonymisés et des comptes de test. Si l'interface n'a pas encore été conçue, il est raisonnable de commander séparément une carte de scénario, des wireframes et un prototype cliquable, puis de transférer le périmètre convenu au développeur.

• objectif du produit et rôles des utilisateurs
• écrans clés et scripts utilisateur
• Version minimale d'Android et types d'appareils
• mises en page ou exigences d’interface
• description de l'API, de l'autorisation et des données
• paiements, processus push et en arrière-plan
• Critères MVP et plans pour d’autres versions

Que vérifier avant de commencer le développement

Avant de commencer le travail, il est utile de vérifier l'état de préparation de la conception et de l'API backend, les modules existants, le SDK et les licences, les droits du compte Google Play et de l'équipe, les tailles d'écran et les architectures d'appareil prises en charge, les autorisations et la nécessité d'un travail en arrière-plan, la quantité de données locales et de synchronisation et le plan de migration des utilisateurs depuis l'ancienne application. Si le backend n'est pas prêt, le développeur doit obtenir un contrat API convenu, des exemples de réponses et un banc d'essai. Si l'application existe déjà, l'audit doit montrer si la build est reproductible, à qui appartient les clés, quelles dépendances sont obsolètes, où se trouvent les configurations et si une mise à jour peut être publiée en toute sécurité.

• conception et API back-end prêtes
• modules, SDK et licences existants
• Compte Google Play et droits d'équipe
• tailles d'écran et architectures d'appareils prises en charge
• autorisations et nécessité d'un travail en arrière-plan
• volume de données locales et synchronisation
• plan de migration des utilisateurs depuis l'ancienne application

Comment se passe le développement ?

Le développement séquentiel comprend la clarification du MVP et des appareils pris en charge, le prototypage des principaux scénarios, la conception de modules et de contrats API, le développement de l'interface et de la logique métier, l'intégration des paiements, des tâches push et en arrière-plan, les tests sur la matrice des appareils et les canaux de test et la préparation de l'App Bundle, la publication et le support. Il est préférable de suivre les étapes sur les versions de test plutôt que d'attendre une seule démo à la fin. Au début, ils confirment l'autorisation, le parcours utilisateur principal et le module technique le plus risqué. Après cela, les écrans restants, les états de chargement, les résultats vides, les erreurs, les règles d'analyse et de récupération sont ajoutés.

1. clarification du MVP et des appareils pris en charge
2. scénarios de base de prototypage
3. conception de modules et de contrats API
4. développement d'interface et de logique métier
5. intégration des paiements, des tâches push et en arrière-plan
6. tests sur une matrice d'appareils et de canaux de test
7. Préparation, publication et support de l'App Bundle

Exigences techniques

Les exigences techniques incluent Kotlin et une approche cohérente de Jetpack Compose ou Views, une architecture et une gestion d'état claires, un stockage sécurisé des jetons, le fonctionnement correct des autorisations et des tâches en arrière-plan, l'adaptation à différents écrans et densités, l'accessibilité, la localisation, le thème sombre et la journalisation, l'analyse des crashs et la minimisation des données personnelles. L'interface mobile doit prendre en compte la taille du texte du système, les zones de sécurité, le clavier, la rotation de l'écran, le thème sombre et les scénarios de réseau lent. La demande d'autorisation doit être présentée dans un contexte clair. Les secrets ne doivent pas être stockés dans un référentiel, et les journaux et rapports d'erreur ne doivent pas révéler d'informations personnelles.

• Approche cohérente de Kotlin et Jetpack Compose ou Views
• architecture claire et gestion de l'état
• stockage sécurisé des jetons
• bon fonctionnement des autorisations et des tâches en arrière-plan
• adaptation aux différents écrans et densités
• accessibilité, localisation et thème sombre
• journalisation, analyse des accidents et minimisation des données personnelles

Que doit transmettre le développeur ?

Une fois terminé, demandez le référentiel de code source, le projet Gradle et les versions de dépendances validées, la description des variantes et des environnements de construction, les instructions et signatures de construction, la liste des variables et des secrets sans valeurs, les scripts de test et la matrice de périphériques, ainsi que la documentation pour transférer le projet vers une autre équipe. Le client doit pouvoir assembler une nouvelle version sans l'intervention de l'entrepreneur précédent. Cela nécessite des sources, des dépendances, des instructions, des droits de compte, des identifiants d'application et des clés transférées de manière sécurisée. La documentation doit expliquer la configuration des environnements, la publication des versions de test et de production, les migrations et le retour à une version précédente.

• référentiel de code source
• Projet Gradle et versions de dépendances validées
• description des variantes de build et des environnements
• instructions de montage et signatures
• liste de variables et de secrets sans valeurs
• scénarios de test et matrice des appareils
• documentation pour transférer le projet à une autre équipe

De quoi dépend le coût ?

Le coût de développement d'Android dépend de facteurs tels que le nombre d'écrans et de rôles d'utilisateur, l'état de préparation de la conception et de la partie serveur, la largeur de la matrice des appareils pris en charge, le mode hors ligne, les tâches de synchronisation et d'arrière-plan, les paiements, les cartes et les capacités matérielles, la complexité de la migration d'une application existante et la période de test, de publication et de maintenance. Comparez les offres avec la même composition : conception, backend, panneau d'administration, analyses, publication, tests et période de correction des défauts. Une note faible peut ne pas inclure les erreurs d'interface, l'adaptation de l'appareil, la prise en charge de la modération ou le transfert de source.

• nombre d'écrans et rôles d'utilisateurs
• conception et partie serveur prêtes
• largeur de la matrice de périphériques pris en charge
• mode hors ligne, synchronisation et tâches en arrière-plan
• paiements, cartes et capacités matérielles
• complexité de la migration d'une application existante
• période de test, de publication et de maintenance

Comment choisir un développeur

Lors de la sélection d'un développeur Android, demandez à voir les applications pertinentes et expliquez vos contributions personnelles, l'architecture et le processus de publication. Un bon professionnel pose des questions sur les utilisateurs, les API, les analyses, l'accessibilité, la sécurité, le mode hors ligne et la propriété du compte. Il ne promet pas de passer la modération sans vérification et sépare de manière proactive les corrections de bugs des nouvelles fonctionnalités.

Comment accepter la candidature

Avant acceptation, vérifiez que les principaux scénarios s'exécutent sur une matrice cohérente d'appareils, que l'interface ne se casse pas sur de petits écrans et avec des polices plus grandes, que les autorisations ne sont demandées que dans un contexte compréhensible, que les tâches en arrière-plan respectent les restrictions du système, que la perte de réseau n'entraîne pas de duplication d'opérations, que les données personnelles ne se retrouvent pas dans les journaux et que la build de la version est reproduite conformément aux instructions. Utilisez des données de test et des appareils réels, pas seulement un émulateur. Vérifiez le premier lancement, la reconnexion, la perte de réseau, l'expiration de la session, le double-clic, le retour en arrière-plan, l'autorisation refusée et la mise à niveau à partir de la version précédente. Les actions critiques ne doivent pas être dupliquées après une demande répétée.

1. les principaux scénarios se déroulent sur une matrice cohérente d'appareils
2. l'interface ne casse pas sur les petits écrans et avec des polices plus grandes
3. les autorisations ne sont demandées que dans un contexte clair
4. les tâches en arrière-plan respectent les limites du système
5. la perte de réseau n’entraîne pas de duplication des opérations
6. les données personnelles ne sont pas incluses dans les journaux
7. La version de version est reproduite conformément aux instructions

Un projet Android doit être testé sur plusieurs téléphones phares. Le résultat dépend de la taille et de la densité de l'écran, de la taille de la mémoire, de la version du système, du shell du fabricant, des limitations de la batterie et de la qualité du réseau. Il est donc utile dans cette tâche de définir la matrice minimale d’appareils et de scénarios critiques, plutôt que de promettre le même test sur tous les modèles existants. Pour publier, le client doit contrôler le compte, la clé de signature, le nom du package, l'accès à Google Play Console et le stockage de sauvegarde des éléments nécessaires.

Accès, données et responsabilité

Dans le projet Android, le client est responsable de la légalité des données, des textes, des marques, des conditions de paiement, des politiques de confidentialité et de l'exactitude des informations de la boutique. Le développeur est responsable de la cohérence du code, de la gestion des erreurs, des droits minimaux, de la documentation et de la communication du résultat. Avant de commencer, vous devez vous mettre d'accord sur les licences SDK, le stockage des analyses, la suppression de compte, les sauvegardes et la période d'assistance.

Comment publier un devoir sur DitWork

Pour commander un développement Android sur DitWork, créez une tâche avec une brève description du produit, les rôles des utilisateurs, le MVP requis, un lien vers les maquettes, l'API et les critères d'acceptation. Spécifiez les appareils, les langues, les scénarios hors ligne, les paiements, les notifications, les délais souhaités et le responsable de la publication. Comparez les propositions en fonction de la compréhension des processus métier, de la qualité de l'architecture, du plan de test, du contenu des fichiers transférés et du support post-version.