Compilation de l'application mobile (aide + proposition de documentation)

[coder-pour-changer-de-vie]

Bonjour,

premier point : je ne suis pas expert Kotlin, ni Android natif :-)

Nous souhaitons apporter quelques modifications d'ergonomie et donc compiler l'application en partant de zéro.

Nous le faisons car les modifications proposées n'ont pas été acceptées en tant qu'évolution dans la roadmap, nous allons donc partir sur un fork afin de répondre aux besoins exprimées par des utilisateurs, pas de souci.

Est-il possible d'avoir un coup de pouce léger pour le démarrage (première compile) ?

En contre partie nous pouvons rédiger une documentation développeur pour l'initialisation de la compilation mobile.

Voici la configuration existante :

• repository source gn_mobile_occtax 2.6.2
• Android studio 2023.2.1
• Target = Android 13 (API 33)

Ce que nous avons compris (from scratch, sans documentation) :

• gn_mobile_occtax contient des liens symboliques et n'écessite l'ajout des projets gn_mobile_core et gn_mobile_maps (récupération des repositories correspondant)

• il persite un probleme de lien symbolique du repertoire compat : compat -> gn_mobile_core/compat non résolu, pour permettre la compilation un répertoire vide est créé dans gn_mobile_core nommé compat

NB : Android studio propose une migration vers Gradle 8.3.0 que nous avons refusé pour rester en 7.4.2 (car problème de migration détectée sur le namespace du projet)

Question 1 : Faut-il passer à la derniere version de Gradle (j'imagine que non) ?

Question 2 : la compilation amène les 2 erreurs suivantes, y a t il un étape ou un prérequis que j'aurais oublié ? Constatez vous les mêmes points avec la version 2.6.2 ? :

Erreur 1 :

Une erreur de condition ternaire (remplacée par un boolean pour valider la compilation dans un premier temps) dans le fichier gn_mobile_occtax-master/datasync/src/main/java/fr/geonature/datasync/packageinfo/io/AppPackageJsonReader.kt :

//it.packageName != null && it.packageName.isNotBlank() && it.apkUrl != null && it.apkUrl?.isNotBlank()
it.packageName != null && it.packageName.isNotBlank() && it.apkUrl != null && it.apkUrl.isNotBlank()

Erreur 2 :

2024-03-04T11:38:04.659+0100 [ERROR] [system.err] public final class ObservationRecordViewModel {
2024-03-04T11:38:04.659+0100 [ERROR] [system.err] ^
2024-03-04T11:38:04.659+0100 [ERROR] [system.err] @HiltViewModel is only supported on types that subclass androidx.lifecycle.ViewModel.

=> je ne sais pas si cela vient du mécanisme de Hilt, ou d'un autre point lié au fichier "gn_mobile_occtax-master/occtax/src/main/java/fr/geonature/occtax/features/record/presentation/ObservationRecordViewModel.kt

Question 3 : que doit contenir le répertoire "compat" ?

NB : ce projet est l'occasion également de monter en compétence sur le dev Android / Kotlin, merci pour votre indulgence :-)

Tout coup de main au démarrage est vraiment apprécié, le but est d'être autonome rapidement, et si possible de contribuer au projet via de la documentation que l'on peut apporter en fonction de notre retour d'expérience.

D'avance merci et bonne journée !

[sgrimault]

Bonjour,

Bienvenue sur le projet! vous pouvez tout à fait y contribuer en proposant des PRs pour y apporter des petites corrections/évolutions.

Le projet est organisé autour de 3 dépôts git distincts :

• gn_mobile_core qui porte des modules "commun" et transverse (approche historique dans l'idée de pouvoir mutualiser certaines briques entre potentiellement plusieurs applications s'appuyant sur GeoNature)
• gn_mobile_maps, module cartographique "générique" qui ne porte aucune dépendance fonctionnelle avec l'application "Occtax". Ce module s'appuie sur la bibliothèque Android osmdroid.
• gn_mobile_occtax, le module qui porte le fonctionnel de l'application "Occtax", portée par les parcs nationaux. Ce module s'appuie sur les deux modules cités ci-dessus via des sous-modules git.

Une documentation est présente mais est plus portée sur l'aspect fonctionnel de l'application (installation, configuration, etc.), mais peu finalement autour du développement en lui même. Vous pouvez déjà regarder la documentation portée par le module gn_mobile_core dans le répertoire docs/. La documentation s'appuie sur le format AsciiDoc (plus riche et complet que Markdown) ainsi que dans le répertoire docs/ dans le module gn_mobile_occtax.

Pour commencer, il faut donc cloner à minima le dépôt git du module "Occtax" :

git clone [email protected]:PnX-SI/gn_mobile_occtax.git
cd gn_mobile_occtax
git checkout develop

Comme il s'appuie sur des sous-modules git, il faut aussi les récupérer via la commande suivante :

git submodule update --init --recursive

Les liens symboliques seront automatiquement résolus.

Au niveau de l'environnement de travail, je préconise :

• OS : Linux ou macOS (jamais testé sous Windows et il est fort probable que ça ne fonctionne pas sans réadapter les scripts...)
• IDE : Android Studio

Au niveau des contributions et de l'organisation des branches :

• Chaque module possède deux branches principales : master et develop. La branche master reflète la dernière release "officielle" (ici 2.6.2) et on va retrouver les tags des différentes versions selon l'approche semver. La branche develop reflète les versions snapshots ou future RC (avec les tags correspondant).
• Tout nouveau développement part de la branche develop depuis une "feature branch" (par exemple : feature/ma_contrib).
• Les "hotfix" partent de la branche master. La branche develop est mise à jour soit en "cherry-pickant" la ou les corrections (si develop a bien divergé par rapport à master), soit via un "rebase" par rapport à master.
• ⚠️ Les contributions sur les sous-modules ne doivent pas se faire depuis le module gn_mobile_occtax. Il faut donc cloner séparément les modules gn_mobile_core et gn_mobile_maps en respectant ce qui est décrit ci-dessus.
• La mise à jour des sous-modules depuis le module gn_mobile_occtax peut se faire via le script ./upgrade_submodules.sh

Actuellement le projet s'appuie au niveau du tooling sur gradle en version 7.4.2 et cible l'API 33 coté Android. Un travail est en cours pour migrer vers les dernières versions.

Voilà pour un premier début :)

[camillemonchicourt]

Je n'ai pas souvenir que des propositions d'évolutions fonctionnelles aient été discutées ?

De quelles évolutions s'agit-il ?

Si vous faites un fork, il faudra suivre les évolutions que nous faisons par ailleurs dans Occtax-mobile et GeoNature, donc cela sera complexe et coûteux pour vous. Très dommage il me semble.

[coder-pour-changer-de-vie]

Bonjour @camillemonchicourt et @sgrimault et merci pour ce retour.

Je reprends sur le projet (partie mobile) et je viens de passer en version 2.14.0 côté serveur (une update est sortie hier je crois en 2.14.1).

Oui je comprends et en effet c'est dommage, je n'ai pas la trace des demandes car ce n'est pas moi qui les ai formulé.

Je dois réaliser un ensemble d'évolutions demandées spécifiques à un client, qui sont actées avec une réalisation au plus tôt.

La decision de forker est pour avancer rapidement sur ces points, en autonomie et pour ne pas rentrer en conflits avec la vision principale du projet, avec un eventuel refus d'une fonctionnalité ou bien des délais trop long d'intégration pour le client.

L'idée est nécessairement de minimiser l'impact pour rester aligné avec les prochaines update de l'application mobile, tant que faire ce peut, et pourquoi pas soumettre certaines fonctionnalités plus tard.

Mais actuelement le temps manque, et la souplesse d'avancer en parralèle à court terme a été préféré, étant donnée que l'application mobile à un cycle d'évolution plus long que la partie serveur.

Ce n'est en effet pas un bon choix, mais un compromis au regard du contexte.

@sgrimault : je vais me familiariser avec l'utilisation des sous modules, merci encore.

Je pars sur la version 2.6.2, en ayant bien noté la 2.7.0-RC7 en pre-release.

Je vais me pencher dans le code (avec prise en main de Kotlin par la même occasion) pour me familiariser avec tout ça.

Bonne journée !
Nicolas.