Langages de développement d'applications Android — quel langage spécifier sur le devis et quelles différences ?

Si l'appareil photo ou le lecteur laser de code-barres tourne en continu sur les terminaux, la gestion de la mémoire devient cruciale. Les solutions multiplateformes génèrent parfois plus de latence et drainent la batterie sur ce type de matériel. Un dev natif en Kotlin reste bien plus stable pour des outils de terrain de ce genre.

En 2021, on n'a pas fait préciser le langage dans le cahier des charges. L'agence nous a pondu un mix immonde de vieux blocs Java et de webview hybride. L'an dernier, quand on a voulu mettre à jour le module de scan, les 3 devs qu'on a contactés ont refusé d'y toucher. Résultat : on a dû tout faire réécrire.

Ne signez rien en l'état. Demandez par écrit aux agences : « Quel langage, quelle architecture et quelle version minimale du SDK Android seront utilisés ? » et annexez leur réponse écrite au contrat.

Les points à faire figurer sur le devis doivent être clairs : 1) Langage de programmation spécifié (Kotlin ou framework moderne convenu). 2) Architecture logicielle définie (MVVM ou équivalent). 3) Engagement formel de livrer l'intégralité du code source sur un dépôt indépendant.

Cette manie des agences d'écrire juste « application Android » sur les devis est insupportable. du coup peu importe à qui vous confiez le boulot : si demain ça se passe mal, n'importe quel autre dev qui ouvre le projet ne doit pas tirer la tronche.

s'ils codent en java ca marchera aujourd'hui mais l'année prochaine pour greffer une nouvelle lib vous trouverez personne. bon faites ecrire koltin direct et soyez tranquilles.

edit : j'ai écrit depuis mon téléphone, désolé pour les fautes.

Quelle est la version d'Android installée sur vos terminaux ? Certains appareils industriels restent bloqués sur de vieilles versions. Avez-vous vérifié que les bibliothèques prévues par l'agence sont bien compatibles avec vos machines ?

Si l'agence évite de donner des détails techniques, c'est probablement qu'elle essaie d'adapter un template tout fait. Une boîte de dev honnête affiche fièrement sa stack technique dans son devis, de toute façon.

Comment avez-vous résolu ce point ? Quand on décide sans mesurer, on revient toujours au même point.

Si les critères d'acceptation ne sont pas écrits, la date de fin du projet est ouverte à discussion.

Je suis une petite entreprise, laissez-moi expliquer de mon point de vue. Quand on décide sans mesurer, on revient toujours au même point.

Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère.

Je suis intéressé.

J'ai une objection à faire ici. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant j'ai appris cela trop tard.

Si vous obtenez trois réponses différentes sur un sujet la question est mal posée. franchement voilà, désolé si je me suis étendu.

Il y a un point que je ne comprends pas. L'offre la moins chère est généralement la moins réfléchie.

Corrigez-moi si je me trompe.

Vous avez raison.

comment avez-vous résolu ce point ? bon essayer de fire cela seul est la voie la plus coûteuse.

avnt de décider regardez quelles données vous avez en main. voilà désolé si je me suis étendu.

J'ai été soulagé en lisant cette réponse, donc ce n'est pas seulement mon cas. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

je me pose aussi la question.

Je parle du point de vue du fournisseur, c'est mon côté. Le système continue de vivre après la livraison ; la maintenance est un poste à part.

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