Reprise du message précédent :

Je l'installe déjà, je verrai quand je peux la tester, sachant que je m'en sers ponctuellement
En tout cas les screens sont cools

La V2 est un "remake" amélioré de la V1 avec une UI plus typé "Android 4".

je suis parti sur une app à part pour plusieurs raisons mais la principale est que la V2 n'est pas compatible avec les anciennes versions d'android  (< 4 ) et que je voulais absolument une application avec 1 seul et unique apk (fonctions débloquées par l'in-App purchase en V2 vs 1 apk pro + 1 apk lite en V1)

Pour m'y retrouver au niveau du support la gestion d'un apk pour Android < 4, + un apk pour Android >= 4 (et ceci en version pro + lite) aurait été un peu penible.

Sinon, je voulais laisser la possibilité à l'utilisateur de pouvoir garder l'ancienne version (habitude de l'UI + quelques différences dans les features : pas d'enregistrement a la suite d'un enregistrement existant dans la V2 par exemple)

Et le moment ou la V2 aurait remplacé la V1 aurait pu posé problème à certains utilisateurs en cas de bugs (certains ont une utilisation "critique" de l'appli).

La le seul truc qui à été pénible à gérer, c'est de ne pas faire repayer les utilisateurs de la V1. Il n'y a rien de prévu par Google pour ca.

Merci

Arf. Du coup t'as fait comment ?

 
Je détecte si il y a l'apk payant de la V1 d'installé (et je vérifie qu'il a bien été installé depuis le market).
Rien trouvé de mieux
C'est dommage que dans le in-app purchase, ils autorisent pas les produits gratuits (le moins cher, c est 0.50€)
 
Sinon faut mettre en place un système de serveurs pour gérer les licenses (mais pour une petite appli, aucun interet).

Bonjour,
 
Je débute dans le développement android et je suis en train de programmer une petite application pour me familiariser au système.
 
En gros, l'application permet à plusieurs utilisateurs inscrits de synchroniser des événements chaque jour.
 
La communication se fait via une base de données mysql sur internet, et en gros, j'ai une activité qui créé un service, qui lui même crée une Asynctask qui va aller périodiquement consulter la base de données.
 
Ca, ca fonctionne.
 
Par contre, je souhaite mettre en place un système de notification pour m'indiquer que le statut de l'événement a changé ( quelqu'un vient, ou a changé son état ).
 
L'algo est donc le suivant : ma tache va lire la base de données, et si elle constate que les données ont changé, elle appelle une callback de mon service , et cette callback fait 2 choses : 1erement, elle envoie un message à son activity pour prévenir de rafraichir la vue , et 2emement, elle génère une notification dans la barre de notification.
 
Le but est de notifier lorsque l'application est en arrière plan.
 
Voici comment j'ai créé ma notification ( code de android developer )
 

 
La notification s'affiche bien, mon activité est rafraichi si elle est en premier plan. Par contre, si mon activité n'est pas en premier plan, si je clique sur ma notification pour appeler mon activité, l'application arrive en premier sur mon activité, puis elle plante sans rien afficher. Je ne comprends pas trop pourquoi, à part le fait que vu que j'étais en arrière plan, elle est probablement détruite, alors comment la recréer ?
 
Merci d'avance  

Si la consultation de ta bd se fait de manière périodique, il y'a un mécanisme plus adapté qu'un service qui tourne en permanence. Une sorte de tache planifiée.

Sinon, pour les notifications, à la place de

j'utilise

par contre, pour la compatibilité avec les vieilles versions d'android, il te faut un wrapper pour startForeground
On trouve un peu de doc sur le net pour ca.

Edit : en fait ca a rien avoir avec ton plantage je crois
T'as rien dans le logcat ?
Sinon, peut etre : android:launchMode="singleTop" dans le manifeste

 
Merci pour ta réponse.
 
Pour ton premier point, il faut savoir que je suis issu du monde de l'embarqué ( en C et C++ ) donc j'utilise naturellement ce que j'ai l'habitude de faire, en l'occurence ici un thread qui s'endord et qui se réveille quand j'ai besoin. C'est surement pas le meilleur mécanisme, mais je n'en connais pas d'autre.
 
A savoir que je ne me réveille pas régulièrement, mais de cette facon : toutes les 15 mn entre 8h et 11h , toutes les 5mn entre 11h et 12h et toutes les mn entre 12h et 12h30 ( les valeurs sont toutes paramétrables ). Je ne sais pas si un mécanisme de tache périodique me permet de faire ca, j'ai utilisé précédemment le timer , mais il ne me permet pas de faire ca.
 
Il me faut également quelque chose qui me permet de réveiller immédiatement et non d'attendre le prochain "tick" , pour un bouton refresh par exemple.
 
 
 
Sinon, dans le logcat, je n'ai rien de particulier, mais a vrai dire, je ne lis pas trop ( j'aimerai pouvoir le faire je précise ) car il est pollué par des dizaines de messages / seconde venant du téléphone ( galaxy S4 ) et je n'arrive pas à filtrer correctement.

Tu peux filtrer et ne garder que les messages provenant de ton appli.
 
Ensuite, si il y'a plantage, tu peux rajouter un filtre pour ne garder que les logs de type "Error" (ceux en rouge).
 
C'est indispensable pour le debug

 
 
Rien ne s'affiche. Par contre le debugger veut afficher du code et ne le trouve pas : ActivityThread.performLaunchActivity line 2246
 
Je suppose qu'il break. Il ne me génère pas d'exception "à priori".
 
Edit : si , il génère bien une exception , je le vois dans la pile d'appel , il s'agit d'une runtime exception.
 
edit 2 : voici la stack :
 
DalvikVM[localhost:8601]  
 Thread [<1> main] (Suspended (exception RuntimeException))  
  <VM does not provide monitor information>  
  ActivityThread.performLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 2246  
  ActivityThread.handleLaunchActivity(ActivityThread$ActivityClientRecord, Intent) line: 2296  
  ActivityThread.access$700(ActivityThread, ActivityThread$ActivityClientRecord, Intent) line: 151  
  ActivityThread$H.handleMessage(Message) line: 1281  
  ActivityThread$H(Handler).dispatchMessage(Message) line: 99  
  Looper.loop() line: 137  
  ActivityThread.main(String[]) line: 5293  
  Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]  
  Method.invoke(Object, Object...) line: 511  
  ZygoteInit$MethodAndArgsCaller.run() line: 1102  
  ZygoteInit.main(String[]) line: 869  
  NativeStart.main(String[]) line: not available [native method]  
 Thread [<10> Binder_2] (Running)  
 Thread [<9> Binder_1] (Running)  
 Thread [<11> Binder_3] (Running)  
 Thread [<12> Binder_4] (Running)  
 Thread [<13> AsyncTask #1] (Running)  
 Thread [<14> AsyncTask #2] (Running)  

Pas tres parlante cette exception ^^
 
Faudrait voir les appels fais dans ActivityClientRecord aux lignes 2246, 2296 et 151
 
Y a que cette exception la ?

A priori je n'ai pas accès au code source de cette partie de code. J'ai bien pointé vers le répertoire sdk\source\android-17 , il me trouve le code source pour certains appels, mais pas celui là.
 
Je vais tenter de faire un projet à partir de 0 qui va juste créer une activité, qui va créer un service à partir d'un bouton, et ce service va creer regulierement des notifications qui devront me rappeler mon activité ( c est en gros ce que je veux faire ). Ca fera un code minimal, et je pourrai poster le code complet si ca ne fonctionne pas pour me dire où je me trompe.
 

J'ai trouvé le code source, mais il n'y a pas les bons appels aux lignes citées. J'aurais pas un pb de sdk corrompu ? c'est pas la première fois que je dois refaire un projet de 0 ( en copiant-collant du code ) car mon code n'arrivait plus à s'exécuter sans générer une exception incompréhensible.

Je pensais que ActivityClientRecord etait une de tes activity.

Recherche une exception mentionnant un de tes fichiers java, et tu remonte jusqu'au dernier appel (dans ton code) ayant généré l'exception.

Il y a très peu de chance pour que le plantage soit au niveau du code source Android.

Filtre bien sur les exceptions générées par ton appli ("By Application name" et tu mets le nom de package de ton apk - attribut "package" de ton manifeste)

ok merci, j'ai trouvé.
 
J'ai mis un point d'arret dans le onCreate, et ca plante sur un bundle.getExtras().
 
En effet, cette activité était créée par une précédente activité , à laquelle je fournissais des datas supplémentaires via l'intent.
 
Mais là, je crée mon activité via une intent/pendingintent fournie à la notification, et je n'ai pas fourni les paramètres dont je parle. Du coup, ca plante.
 
Merci pour l'orientation de la recherche en tout cas  
 
Edit : c'est un peu merdique le debug sous eclipse / android sur ce point, il n'est pas capable d'identifier la ligne qui génère l'erreur, et l'état de la pile me donne une information inexploitable

Perso pour avoir une stack beaucoup plus importante et mieux identifier la ligne d'erreur, j'utilise acra. Très utile pour loger toutes les erreurs en prof dans un Google docs et avoir une trace précise du problème.

J'ai l'impression surtout qu'il faudrait que je mette des try/catch partout, j'ai pris la mauvaise habitude de ne jamais m 'en servir en C++ car on peut s'en passer, visiblement ici non.

 
 
Je faisais ca aussi. C'etait pas mal, mais il fallait régulièrement purger le document dans google doc, et la c’était vite pénible (quand il y a beaucoup de crashs )
 
Maintenant je passe par google Analytics. C'est quasi aussi efficace, et beaucoup moins galère à gérer/maintenir.

 
ne cède pas trop vite à la tentation (/facilité), parce que ça peut vite devenir un piège
y a pas d'exception sans raison

 
 non non, c'est surtout pour avoir un retour exploitable en debug. Là, il y avait manifestement une erreur, et elle ne m'était pas remonté au break automatique. J'ai pas eu le réflexe de debugguer pas à pas, car je pensais que le problème venait d'ailleurs ( à tort ).

 
Pour l'instant c'est pas compatible avec des lunettes existantes (oui, c'est un peu le comble) mais la version finale le sera, on pourra mettre des verres.

Parce la cible geek est un peu concerné quoi

Oui, en plus pouvoir faire des google glass de soleil ça claquerai.

En fait j'utilise plus Google Docs non plus, j'ai demandé à me faire envoyer ça sur une page php et je traite en interne un envoi de mail avec juste ce dont j'ai besoin pour récupérer l'erreur, beaucoup plus pratique !

Piège par rapport à quoi d'ailleurs ? Je sais qu'en .NET, trop faire de try catch génère trop de montée en mémoire et fait ralentir le bouzin, c'est pareil en Java/Android ?
 
Je sais que j'en fais pas mal d'ailleurs, j'ai du refactoring à potasser

 
 
Non, c est surtout que c est facile, le truc plante, tu regardes vites fais, tu met un try catch. Mais a la fin ton appli devient in-debugable.
 

C'est vrai

Catcher ou pas les exception c'est un art, maîtriser leur portée et avoir une bonne hiérarchie d'exceptions c'est indispensable pour avoir du code propre.

Les exceptions, c'est aussi un design pattern.
Quand c'est bien utilisé, c plutôt puissant.
Après je me pose aussi la question de la montée en ressource, genre mettre un try/catch dans un for ou en dehors (suivant ce qu'il faut faire).

J'avoue que je ne sais pas bien utiliser les exceptions donc j'évite de m'en servir.  
 
Par exemple, je travaille depuis plus de 10 ans sur une application en C++ développé from scratch  , 250000 lignes de code environ et portable sous windows / wince / linux / iOS et bientot android ( c est pour ca que je m'initie à android ). Aucune exception dedans car je ne sais pas bien m'en servir. Le code lui est très stable malgré tout.
 
Je ne sais pas si sous android on peut également s'en passer, en faisant du code suffisamment propre et en gérant tous les cas, ou justement, parcequ'on ne peut pas gérer tous les cas, les exceptions sont là pour anticiper le reste.
 
Bref, en l'occurence, dans mon cas, il s'agissait d'une initialisation de String de la façon suivante :
 

 
Or, dans la partie de code où je me trouvais, le bundle ne contenait pas de champ "monparam". Ca a apparemment généré une exception, mais plus en amont dans la pile. Résultat, lorsque le programme plante avec le debugger , je ne vois rien ( preuve en est la pile que j'ai fournie plus haut ).
 
Alors dans ce cas, j'ai plusieurs solutions : soit j'entoure tout appel d'API avec des exceptions , soit je mets plus de tests ( si l'API me le permet ) par exemple ici , tester si le param est bien contenu dans le bundle , ou soit encore j'architecture mon application autrement pour qu'en amont, je m'assure que le paramètre existe forcément dans le bundle.
 
Quelle est la meilleure solution dans ce cas précis ?

Dans ton cas, c'est juste vérifier que les objets ne sont pas nuls.
Ce n'est évidemment pas là qu'il faut blinder de try/catch.
 
En revanche, en Java, certaines méthodes déclarent "throws Exception" et tu ne pourras simplement pas te passer de protéger cet endroit, car sinon, ça ne compilera même pas.
C'est le cas par exemple de tout ce qui est I/O.

Dans le sdk Android, les classes de base envoient une floppé d'exceptions. S'e'n passer en java et particulièrement sous Android c'est impossible.

Si tu veux t'en passer tu seras obligé de try catcher en bas niveau la moindre ioexception pat exemple. Sale.

 
Apparemment, tester que la valeur de retour est null dans ce cas précis n'est apparemment pas suffisant. L'exception arrive avant le retour de la fonction getExtras. C est donc de fournir un paramètre inconnu qui pose probleme.
 
Pour ta 2eme phrase, en effet j'avais remarqué qu'on est obligé d'entourer certains appels de try / catch . Appels réseaux par exemple.
 

 
Je ne veux pas m'en passer, je veux simplement faire de la façon la plus propre possible

 
C est ton bundle qui est null, je crois.

 
 
exact    
 

 
Je suis confus du coup, c'est vraiment un bug de débutant  

oui et non, c'est pas évident, parce qu'il peut y avoir 50 façons d'appeler une activity et donc le bundle peut être décliné suivant ces 50 façons, qu'il faudra toutes gérer.

 
 
C'est dans ce sens que je dis que c'est un bug de débutant.
 
En pratiquant, je me suis aperçu qu'une activity peut être appelée de plusieurs façons comme tu le dis, et dans mon cas, je n'avais géré que la première façon, pas la 2eme.  
 
Maintenant, je le sais, il faut que je voie maintenant comment architecturer au mieux la création de mon activity.

Yop,
 
Je viens de déployer une appli mais l'icone que je vois sur le store correspond à l'icone en 512x512 que je mets sur la fiche, et non l'icone launcher comme d'habitude. Ca vous a fait le coup ? Une idée pour y remédier ? Je dois mettre une icone 512x512 correspondant à mon icone launcher ?

je crois que je viens de voir ça hier, maintenant c'est cliquable et je me suis dis "tiens c'est la 1024, première fois que je vois ça !"

Oui.
Le libellé c'est "Icône haute résolution", donc ça doit être la même.

Merci pour l'info !