Closed remipichon closed 9 years ago
L'idée est tout simple : informer l'utilisateur de nos mises à jour + le forcer à mettre à jour
Pour cela nous allons utiliser une donnée application-version sur deux entier : major.minor.
Coté backend :
Coté application
Que pensez vous de cela ?
Leo, je pense qu'utiliser un autre verbe n'est pas un mauvaise idée car l'idée est de faire cette vérification le plus tôt possible et pour des raisons techniques la recuperation des ressources n'est effectuée dès le démarrage.
Je préfèrerais que l'appli fasse appel à une page spécifique plutôt qu'envoyer un verbe POST. Parce qu'il n'y a pas de logique applicative sur le serveur qui sert les JSON pour l'appli mobile.
Du coup, une page /get-version t'irait ? Précise-moi le format de la réponse.
Kiki m'avait assigné à cette issue au départ mais honnêtement je n'ai aucune idée de comment faire, je pense qu'il sera beaucoup plus à même de le faire (et ça lui prendra sans doute moins de temps que si il doit m'expliquer).
Je me suis fourvoyé, bien sur qu'un /get-version irait très bien. Le POST est plutot un PUT ou un PATCH enfin n'importe quoi qui permette de faire un UPDATE sur la version de l'application. Par mesure de sécurité, pourrais tu exiger les droits super admin sur le backend pour autoriser la mise à jour de la version ?
Pour le format de la réponse au /get-version :
android : 'major.minor'
(un jour il y aura une version iOs !)
(1) Le slashscreen instancie le singleton de check app version (2.1) qui effectue la comparaison et envoie un event à destination de BaseActivity (2.3) le singleton check app version stocke le type de popup dans les sharedPref (major, minor, toDate)
(3) a la reception de l'event, lance (2)
BaseActivity au onStart (2) check le localPref :
C'est en prod ! ;)
Ca ne répond pas chez moi
Chez toi doit avoir un problème alors... Fonctionne en Wi-Fi (Free) et 3G (Bouygues). Le 13 avr. 2015 19:46, "Remi Pichon" notifications@github.com a écrit :
Ca ne répond pas chez moi
http://mobile.24heures.org:3030/version
— Reply to this email directly or view it on GitHub https://github.com/24HeuresINSA/24h-android-app/issues/34#issuecomment-92443298 .
Depuis le réseau de l'INSA ca sort pas, un soucis de proxy ? Je code ca ce soir depuis chez moi
Un blocage de port, pas étonnant à l'insa...
Le lundi 13 avril 2015, Remi Pichon notifications@github.com a écrit :
Depuis le réseau de l'INSA ca sort pas, un soucis de proxy ? Je code ca ce soir depuis chez moi
— Reply to this email directly or view it on GitHub https://github.com/24HeuresINSA/24h-android-app/issues/34#issuecomment-92460677 .
Léo MARTINEZ
le 3030 ? Noway ...
Et pourtant si. Du coup ça soulève un problème intéressant. Il serait peut-être plus judicieux de servir les JSON sur le port 80. Par contre, cela implique une migration d'Assomaker sur un autre serveur... Il faut qu'on y réfléchisse, mais ça peut être une solution.
Yep, je pense qu'on peut partir du principe que les users seront sur des réseaux mobiles ou les ports sont ouverts. Les gens ferment pas trop leur port chez eux en Wifi... Je pense qu'on peut rester sur le 3030, peut etre fournir un backup en get sur le 80 avec une URL dégueulasse qui sera utilisé si timeout des get sur 3030. On verra si on a du temps
il reste à gerer :
les erreurs de connectivité internet (juste un crouton demandant d'activer internet)
les feebacks de l'appel /version (peanuts....)
les labels des popups
mettre en place un coutron avec un bouton reassayer si erreur
faire comme pour data version bloquant.minor
bloquant empeche la recuperation des données et propose avec instance de mettre a jour a chaque restart et regulierement minor propose de mettre a jour a chaque restart