search

PnX-SI / gn_mobile_occtax

Application mobile pour la saisie dans le module Occtax de GeoNature
GNU General Public License v3.0
13 stars 4 forks source link

[Occtax2] Problème de récupération de la liste des JDD #129

Closed JeromeMaruejouls closed 2 years ago

JeromeMaruejouls commented 2 years ago

Bonjour à tous, Je viens d'installer la version 2 sur un teléphone Android 10 qui avait la v1 fonctionnelle.

L'installation et la synchronisation se passent sans problème mais lors de la configuration, je n'ai pas accès à la liste des JDD (aucun soucis avec la liste des observers).

Je pense à un problème de droit ou une erreur dans la route. En regardant dans les logs, je vois une requete dans la base sqlite avec un 'WHERE dataset_module = ? et args =['occtax2'].

Au besoin, je pourrai extraire les logs complets.

PS : j'ai voulu tester avec le serveur démo mais je pense que le fichier de conf json n'est pas présent sur le serveur ou qu'il y a plusieurs fichiers json car l'appli ne peut pas le récupérer.

Serveur Géonat en 2.9.2. Tel Mi8 Xiaomi Android 10

camillemonchicourt commented 2 years ago

OK il semble y avoir un effet de bord du fait que le package a été renommé "occtax2" pour la version 2.0.0 et si c'est ce même nom qui est passé en valeur du paramètre dataset_module, alors c'est normal que la liste des JDD renvoyée soit vide. C'est bien "occtax" qui est le nom du module au niveau de GeoNature.

sgrimault commented 2 years ago

Oui, je suis allé trop vite et le changement du nom de package implique des petits effets de bord, notamment le lien entre le module GeoNature et le package name de l'application.

Plusieurs solutions possibles :

DonovanMaillard commented 2 years ago

Merci Sébastien pour ta réactivité,

Pour le premier point, ca ne me semble pas écarté définitivement, donc pas à retenir selon moi. Pour la 2 passons si tu ne penses pas que ca soit le plus adapté.

A mon sens on peut bien mettre occtax en dur dans l'application et privilégier cette option, dans tous les cas le nom du module n'est pas configurable en soit, et bien en dur coté serveur.

Edit : vu avec Camille, OK également pour l'option 3 :)

JeromeMaruejouls commented 2 years ago

Merci pour ses infos. Juste une remarque supplémentaire : dans la table t_mobile_apps, on doit mettre deux app_code différents si on utilise la v1 et la V2 de occtax mobile. (j'ai renommé la ligne de la V1 en OCCTAX1 pour avoir OCCTAX pour la v2). Je ne sais pas si ce champs est utilisé par la suite dans geonature mais si oui, cela peut avoir un impact sur la cohabitation entre les deux versions.

camillemonchicourt commented 2 years ago

La version 2.0.0 a été corrigée et l'APK associée remplacée par la version corrigée : https://github.com/PnX-SI/gn_mobile_occtax/releases/tag/2.0.0

Il y avait un lien entre le package name de l'application et le nom du module GeoNature associé. Maintenant, il n'y a plus aucune correspondance et le nom du module GeoNature est simplement défini par configuration dans l'application : https://github.com/PnX-SI/gn_mobile_occtax/blob/develop/occtax/src/main/java/fr/geonature/occtax/di/DatabaseModule.kt#L33 Même chose pour le fichier de settings de l'application : https://github.com/PnX-SI/gn_mobile_occtax/blob/develop/occtax/src/main/java/fr/geonature/occtax/di/DataSyncSettingsModule.kt#L24

Je viens de tester cette version 2.0.0 sur le serveur de DEMO de GeoNature et tout fonctionne désormais correctement.

L'APK de la 2.0.0 est sur le serveur : https://demo.geonature.fr/geonature/api/static/mobile/occtax/occtax-2.0.0-generic-release.apk

J'ai les 3 applications sur le serveur GeoNature avec cette configuration : https://demo.geonature.fr/geonature/api/gn_commons/t_mobile_apps

Et dans la table gn_commons.t_mobile_apps :

id_mobile_app app_code relative_path_apk url_apk package version_code
1 SYNC static/mobile/sync/sync-1.3.0-generic-release.apk fr.geonature.sync 3150
2 OCCTAX static/mobile/occtax/occtax-1.3.0-generic-release.apk fr.geonature.occtax 2290
3 OCCTAX2 static/mobile/occtax/occtax-2.0.0-generic-release.apk fr.geonature.occtax2 2570

Je ne crois pas que le champs app_code de la table soit utilisé par l'application mobile. Par contre le nom du package est important ainsi que son code de version pour la mise à jour automatique de l'application.

JeromeMaruejouls commented 2 years ago

Parfait, tout fonctionne chez moi, merci !

sgrimault commented 2 years ago

Je ne crois pas que le champs app_code de la table soit utilisé par l'application mobile.

Il est encore utilisé et sert à simplement "nommer" l'application (au lieu d'afficher simplement le package name de l'application). C'était utile avec l'application de synchronisation qui gérait les applications disponibles en les affichant sous forme de liste.

Maintenant que le module datasync est intégré directement dans l'application "Occtax", la route GET -> /api/gn_commons/t_mobile_apps ne sert plus qu'à mettre à jour l'application.

camillemonchicourt commented 2 years ago

OK donc désormais seuls les champs package et version_code de la table t_mobile_apps sont utilisés, pour vérifier si la version installée sur le terminal doit être mise à jour par une version plus récente. Merci @sgrimault pour les précisions.