Développer sous Android Studio : impact sur le devis et risque de dépendance ?

Comme Android Studio est l'IDE officiel, les nouvelles versions d'Android, les exigences d'API cibles et les correctifs de sécurité publiés chaque année par Google y sont intégrés dès le premier jour. Sur les solutions hybrides, il arrive parfois de devoir attendre 3 à 4 mois que les bibliothèques soient mises à jour.

Pour trancher entre les offres, posez-vous cette question : vos équipes utiliseront-elles uniquement des tablettes ou terminaux durcis sous Android ? Si oui, Android Studio et le dev natif restent incontestablement l'option la plus robuste. En revanche, si vos commerciaux de terrain comptent utiliser leurs propres iPhone demain, une approche hybride couvrira les deux plateformes avec une seule enveloppe budgétaire.

En 2022, impossible de trouver une agence pour reprendre notre appli B2B de stockage développée en hybride, car l'équipe d'origine avait utilisé des librairies obscures qui n'existent plus. On a dû tout faire réécrire de zéro sous Android Studio et Kotlin ; ça nous a coûté 160.000 TL et 4 mois de travail.

Avertissement crucial : ajoutez une clause de « remise de la clé de signature (keystore/upload key) » dans le contrat. L'agence peut très bien pondre un code parfait sous Android Studio, mais si elle ne vous donne pas la clé, vous ne pourrez pas mettre à jour votre appli sur Google Play et vous serez obligés d'en recréer une toute nouvelle.

edit : j'ai écrit une erreur ci-dessus, désolé.

Le code natif offre des standards élevés, c'est vrai, mais si l'application de commande pour les distributeurs n'a pas besoin de graphismes 3D ou d'une communication Bluetooth lourde, les technos hybrides font largement l'affaire. L'agence qui répond à l'appel d'offres pousse peut-être le natif simplement parce qu'elle ne maîtrise qu'Android, posez-leur la question.

android studio c'est juste un logiciel en vrai c'est pas le monopole de l'agence. ouvrez un compte gitlab ou github et faites pousser le code sur votre propre repo des le premier jour c'est tout, vous dependrez de personne.

Tous vos distributeurs sont sur Android ? Envisagez-vous à l'avenir de prendre des commandes de clients finaux extérieurs ? Si la réponse est oui, êtes-vous prêts à payer 210 mille TL pour du natif Android maintenant, puis à remettre la même somme dans 6 mois pour iOS ?

Je suis du même avis. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Tous ceux qui se pressent sur developpement android studio se heurtent au même obstacle. C'est mon avis, je ne l'écris pas comme une vérité absolue.

J'ai vécu la même chose. Si le périmètre s'agrandit, il faut augmenter soit le délai, soit le budget. Il n'y a pas de troisième option.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. C'est confirmé par l'expérience.

Je suis d'accord. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

Voilà, désolé si je me suis étendu.

Je vais essayer. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Oui, la situation est exactement ainsi concernant developpement android studio. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Ce conseil ne convient pas à tout le monde je pense. Quand on décide sans mesurer, on revient toujours au même point.

À votre place, j'irais par cette voie.

Ce sujet est archivé. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Tous ceux qui se pressent sur developpement android studio se heurtent au même obstacle.

C'est vrai en théorie, mais ça ne marche pas ainsi en pratique. Un code sans documentation d'installation ne vous appartient pas, même si vous l'avez.

Un rapport d'avancement écrit hebdomadaire est bien plus utile que de demander des dates. Voilà, désolé si je me suis étendu.

Je parle du point de vue du fournisseur, c'est mon côté. Les décisions hâtives finissent par être corrigées six mois plus tard.

C'est confirmé par l'expérience.

Je suis intéressé.

Je vais expliquer comment c'est fait en pratique. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.