Discussion :

[waxman]

Bonjour à tous,

Je dois pour la premiere fois réaliser une application Android. Je ne m'y suis encore jamais frotté.

Développeur de métier, je travaille au quotidien en C#, Asp.net, php, MS Sql Serveur etc
Je viens donc chercher vos conseils non pas sur l'algorithmie en elle meme mais plutot sur les spécificité de la plateforme Android.

Voici en quelques lignes les besoins du projet:

• L'application ne sera pas disponible sur le market, c'est un dev interne que nous allons déployer sur un modele de terminal bien précis (non connu à ce jour mais le modèle sera arreté au démarrage du dev). J'élimine donc les problemes de compatibilité, de tailles d'écran etc etc
• L'appli devra permettre
  
  • La saisie d'infos via des formulaires
  • La prise de photos (donc s'interfacer avec l'appli app photo)
  • La lecture d'un code barre (donc s'interfacer avec l'appli de lecture de code barre)
  • La lecture d'une température via une sonde connectée en micro usb au terminal
• Ces infos doivent être stockée localement (donc bdd pour les infos et fs pour les photos)
• L'appli doit détecter la présence d'une connexion data (3g ou wifi) et flusher toutes ces infos (en bdd + photos) vers un serveur distant dès que possible

Je ne vous demande bien sur pas de faire le projet à ma place mais plutot des pistes pour partir dans la bonne direction sur chacune de ces problématiques
A savoir

• Comment m'interfacer avec un autre appli
• Comment détecter une connexion data

Pour gérer les interfaces, l'accès la bdd, meme si je ne les ai pas encore exploités, j'ai vu qu'il y avait bcp de tutoriels qui traitent de ces points

La grosse inconnue sera la lecture de la t° mais je me doute que vous ne pouvez rien pour moi, le modele de sonde n'étant pas encore connu

Bref, tous vos tuyaux pour partir du bon pied seront les bienvenus.

Je vous remercie par avance

[waxman]

Personne ?

[Hizin]

L'application ne sera pas disponible sur le market, c'est un dev interne que nous allons déployer sur un modele de terminal bien précis (non connu à ce jour mais le modèle sera arreté au démarrage du dev). J'élimine donc les problemes de compatibilité, de tailles d'écran etc etc => Ca, en soit, c'est pas un gros soucis. Ca en fait au moins un de moins.

La saisie d'infos via des formulaires => bâteau, gestion standard de vues.

La prise de photos (donc s'interfacer avec l'appli app photo) => Communication avec l'appareil photo via les Intent (des modèles peuvent réserver des surprises, oui terminal Samsung avec surcouche TouchWiz, je te regarde)

La lecture d'un code barre (donc s'interfacer avec l'appli de lecture de code barre) => Là, il faut voir si l'application de lecture permet une communication. Si ce n'est pas le cas, il faudra embarquer un lecteur de code barre. Si c'est le cas, suivre sa documentation. En théorie, l'application pourrait le permettre via des Intent aussi.

La lecture d'une température via une sonde connectée en micro usb au terminal => Là, pas de miracle, lire la documentation. Je n'ai jamais fait de la communication avec appareil externe non-pris en charge par Android, donc je ne peux pas vraiment indiquer. Soit vous avez une API de communication, et il faut la suivre, soit vous devrez faire un POC pour savoir comment communiquer avec la sonde.

Ces infos doivent être stockée localement (donc bdd pour les infos et fs pour les photos) => BDD SQlite à disposition, ainsi que la mémoire du terminal (interne ou SD).

L'appli doit détecter la présence d'une connexion data (3g ou wifi) et flusher toutes ces infos (en bdd + photos) vers un serveur distant dès que possible => Détection d'une connexion data, assez simple. Pour les données, si c'est uniquement de l'envoi, un WS et c'est mar. Si c'est de la synchronisation, ça demandera beaucoup plus de boulots.

Pour la connexion, tu as une méthode utilitaire qui traîne.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public boolean isOnline() {
    ConnectivityManager cm =
        (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo netInfo = cm.getActiveNetworkInfo();
    if (netInfo != null && netInfo.isConnectedOrConnecting()) {
        return true;
    }
    return false;
}

Attention par contre, cette méthode ne gère pas les problématiques de portail captif. Ca complexifie le tout, mais c'est tout à fait possible (pour se faire, tester en premier lieu une connexion sur une page quelconque, et bien vérifier qu'un y est connecté, et pas redirigé sur une autre).

[waxman]

Merci beaucoup pour ces éléments

Du coup, quelques questions complémentaires

La saisie d'infos via des formulaires => bâteau, gestion standard de vues.
=> Si j'ai bien compris, on fait une activité par vue. J'ai bon ?
Il y a également tout un scénario du cycle de vie d'une application avec la sauvegarde de l'état au moment du passage en arriere plan (car susceptible d'un kill sauvage par l'OS) et le rétablissement lors du retour sur l'appli. Ceci doit t il se gérer manuellement ou bien le framework automatise t'il tout ou partie de cet aspect ?

La lecture d'un code barre (donc s'interfacer avec l'appli de lecture de code barre) => Là, il faut voir si l'application de lecture permet une communication. Si ce n'est pas le cas, il faudra embarquer un lecteur de code barre. Si c'est le cas, suivre sa documentation. En théorie, l'application pourrait le permettre via des Intent aussi.
=> Je comptais utiliser l'appli Barcode Scanner. J'ai déja vu d'autres appli l'utiliser pour scanner des codes barre (l'application Prixing si je me souviens bien) j'en déduis donc qu'elle est capable de s'interfacer

Ces infos doivent être stockée localement (donc bdd pour les infos et fs pour les photos) => BDD SQlite à disposition, ainsi que la mémoire du terminal (interne ou SD).
=>Pour cela oui, la question que je me posais était du chemin d'accès des photos. L'appli appareil photo va t elle
- me laisser le choix pour stocker dans les datas de ma propre appli
- stocker ou bon lui semble, et me retourner le chemin (auquel cas, je devrais copier le fichier vers mes propres data en le renommant )
- me renvoyer un stream avec la photo que je devrai enregistrer moi meme



L'appli doit détecter la présence d'une connexion data (3g ou wifi) et flusher toutes ces infos (en bdd + photos) vers un serveur distant dès que possible => Détection d'une connexion data, assez simple. Pour les données, si c'est uniquement de l'envoi, un WS et c'est mar. Si c'est de la synchronisation, ça demandera beaucoup plus de boulots.

Pour la connexion, tu as une méthode utilitaire qui traîne.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public boolean isOnline() {
    ConnectivityManager cm =
        (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo netInfo = cm.getActiveNetworkInfo();
    if (netInfo != null && netInfo.isConnectedOrConnecting()) {
        return true;
    }
    return false;
}

=> C'est en effet pour simplement faire remonter vers le serveur, pas synchro bi directionnelle, je vais donc poster les datas et la photo en http vers le serveur.
Ce job, je compte le mettre dans un service, qui vérifiera périodiquement si une connexion est dispo (pourquoi pas interroger une page spécifique sur le serveur avec une réponse convenue) et si dans la base il y a des éléments à flusher avec un flag indiquant lesquels ont déja été envoyés
L'appli avec IHM se contenant de remplir la base
La méthode indiquée me semble intéressante comme vérification mais je me disais aussi que je pouvais m'abonner à un événement pour être notifié/activé par l'OS lorsqu'une connexion arrivait, non ?

WS et mar, kézako ?

Encore merci, les différentes briques du projet commencent à se clarifier pour moi

[nicroman]

WS = Web service
Mar... "c'est mar" = "c'est marre" je pense.... http://dictionnaire.reverso.net/fran...39;est%20marre


Une activité par vue... non... pas forcément....
Une activité correspond à un "état" de l'application. L'activité peut être considéré comme un "point d'entrée" de l'appli. c'est ainsi que le "launcher" va utiliser une activité définie dans le manifest, mais un partage de photo utilisera une autre activité.
A l'intérieur d'une activité, rien n'empêche d'avoir plusieurs "vues" (Fragments, ...).

Ce job, je compte le mettre dans un service, qui vérifiera périodiquement

Il faut oublier la notion de "périodiquement" sur un mobile (cela est aussi vrai sur d'autres systèmes, mais principalement sur mobile). Il n'y a rien de périodique sur un mobile (quand un mobile passe en veille, il éteint une grosse partie de ses fonctions, et rien ne fonctionne). Par contre le mobile prévient (utilisation de broadcast intents) des modifications de tel ou tel partie (comme la partie "network"). L'utilisation de cet intent permettrait de "pousser" les données dès la connexion.
Il y a encore moyen de se simplifier encore plus la vie en utilisant un SyncAdapter (qui ne sera appelé que si il y a des choses à synchroniser, *et* que le réseau est disponible).

[Hizin]

=> Si j'ai bien compris, on fait une activité par vue. J'ai bon ?
Il y a également tout un scénario du cycle de vie d'une application avec la sauvegarde de l'état au moment du passage en arriere plan (car susceptible d'un kill sauvage par l'OS) et le rétablissement lors du retour sur l'appli. Ceci doit t il se gérer manuellement ou bien le framework automatise t'il tout ou partie de cet aspect ?

Une Activity par vue, et X Fragments par vue. Dans ton cas, je pense que tu peux zapper le notion de Fragment. Pour la sauvegarde, l'état est restauré lorsque l'Activity n'est pas tuée, juste endormie, mais il faut aussi prendre la sauvegarde à son compte, dépendant du besoin.

=> Je comptais utiliser l'appli Barcode Scanner. J'ai déja vu d'autres appli l'utiliser pour scanner des codes barre (l'application Prixing si je me souviens bien) j'en déduis donc qu'elle est capable de s'interfacer

Alors banco. Juste regarder comment s'interfacer avec cette application via les Intent.

=>Pour cela oui, la question que je me posais était du chemin d'accès des photos. L'appli appareil photo va t elle
- me laisser le choix pour stocker dans les datas de ma propre appli
- stocker ou bon lui semble, et me retourner le chemin (auquel cas, je devrais copier le fichier vers mes propres data en le renommant )
- me renvoyer un stream avec la photo que je devrai enregistrer moi meme

Potentiellement les trois, dépendant de l'application utilisée.
Un tuto : http://developer.android.com/trainin...otobasics.html

=> C'est en effet pour simplement faire remonter vers le serveur, pas synchro bi directionnelle, je vais donc poster les datas et la photo en http vers le serveur.
Ce job, je compte le mettre dans un service, qui vérifiera périodiquement si une connexion est dispo (pourquoi pas interroger une page spécifique sur le serveur avec une réponse convenue) et si dans la base il y a des éléments à flusher avec un flag indiquant lesquels ont déja été envoyés
L'appli avec IHM se contenant de remplir la base
La méthode indiquée me semble intéressante comme vérification mais je me disais aussi que je pouvais m'abonner à un événement pour être notifié/activé par l'OS lorsqu'une connexion arrivait, non ?

Pas de synchro, donc ça de moins à réaliser. Il ne faudra juste pas oublier de faire des contrôles de doublon lors des envois. Le cas idéal est : l'application envoie ses données, puis réinitialise sa BDD interne. Le cas à prendre en compte : l'application envoie ses données, mais à un problème quelconque de connectivité avant de terminer : pour éviter les parasites, il faudra faire attention que chaque donnée envoyée avec succès ne soit pas renvoyée ensuite.

Tu peux t'abonner à ce genre d'événement aussi, oui.

WS et mar, kézako ?

WS = WebService; un appel normé à un serveur.
Et "c'est marre" et une expression signifiant "c'est bon"

EDIT : et grillé

[waxman]

Merci à vous deux pour ces renseignements, c'est trrresss utile

Imaginons le fonctionnement suivant:
[menu principal] --> [choix 1] --> [sous choix 2] --> [formulaire en renseigner] --> [retour au menu principal]

Si je crée une activité pour chaque étape, certes le bouton back me permet de revenir en arrière à chaque moment mais à la fin, ai je la possibilité de purger la pile une fois le formulaire enregistré et revenu au menu principal ?
Ou bien dois je fermer chaque activité en indiquant à la précédente qu'on est en train de remonter pour qu'elle se ferme immédiatement à son tour ?

Si j'utilise les fragments, un appui sur le back permet t'il de revenir en arrière et de repasser au fragment précédent ?

Pour le contrôle des doublons, c'est déjà pensé.
Chaque élément à flusher a un id unique, le webservice vérifie si ce dernier n'a pas déjà été flushé et dans les deux les cas, répond à l'appli que le flush est ok. Ainsi l'appli met à jour sa bdd interne avec un flag
Du coup, peut importe le cas, soit le flush avait échoué, et l'appli retente, soit le flush avait réussi mais l'appli n'avait pas été notifiée, le process est ré-entrant et on garanti que le WS n'enregistre aucun doublon

Je vais regarder le SyncAdapter et quels sont les événements qui le déclenchent

Encore merci à vous deux !!!

[nicroman]

[menu principal] --> [choix 1] --> [sous choix 2] --> [formulaire en renseigner] --> [retour au menu principal]

Si je crée une activité pour chaque étape, certes le bouton back me permet de revenir en arrière à chaque moment mais à la fin, ai je la possibilité de purger la pile une fois le formulaire enregistré et revenu au menu principal ?

Oui et non... Il y a 1 activité [menu principal] (sans doute celle lancée par le launcher).
Une activité de formulaire (avec les divers choix avant d'afficher le formulaire)
=> 2 activités.

Ou bien dois je fermer chaque activité en indiquant à la précédente qu'on est en train de remonter pour qu'elle se ferme immédiatement à son tour ?

Tout dépend de l'implémentation.
Mais rien n'empeche de lancer l'intent de l'activité suivante et de terminer immédiatement celle en court (finish() ). Sauf pour [menu principal] bien sur.

Si j'utilise les fragments, un appui sur le back permet t'il de revenir en arrière et de repasser au fragment précédent ?

Oui

Je vais regarder le SyncAdapter et quels sont les événements qui le déclenchent

Il peut être déclenché de manière "automatique" (toutes les X heures), ou de manière "manuelle" (il suffit de faire appel à requestSync)
Par contre il sera désactivé si:
* Pas de réseau
* Pas de "synchronisation" (il y a un bouton pour désactiver les syncs en général sur le téléphone).

[waxman]

Mais rien n'empeche de lancer l'intent de l'activité suivante et de terminer immédiatement celle en court (finish() ). Sauf pour [menu principal] bien sur.

Je vais donc faire des tests entre les deux approches. Je ne peux terminer immédiatement celle en cours car il faut pouvoir revenir mais je peux mettre en place un systeme de pile personnalisé et lorsque le dernier formulaire de la derniere est validé, je finish toute la pile.
Ainsi, j'ai un retour possible tant que la saisie n'est pas complète

Il peut être déclenché de manière "automatique" (toutes les X heures)

Je vais regarder de plus pres, pour voir si c'est une vraie info (le X heures) ou un exemple

Dans tous les cas, encore merci, maintenant, faut s'y mettre

Bon weekend à tous !!