Pierre Marty

Développeur iOS (iPhone, iPad)

Sidebar
Menu

Bon Artisan : un exemple d'application dédiée à un site WEB.


P.S. Cette application a été développée en 2008 / 2009. On découvrait alors ce qu'était une application connectée. Depuis certains points sont devenus des évidences.



Pourquoi une application plutôt qu'un site dédié ?

Une application
  • Permet d'avoir accès à une interface utilisateur spécifique iPhone (picker, listes…)
  • Utilise toute la surface de l'écran (contrairement à un site WEB)
  • Permet de garder des informations localement (cache, identification de compte…) et donc d'avoir une meilleur réactivité.
  • etc.

Comment construire une application de ce type ?

il faut:
  • un développeur coté serveur, pour mettre en place des services (requêtes HTTP)
  • un développeur coté iPhone
  • un protocole de communication entre les deux.

Comment se passe la communication entre l'iPhone et le serveur ?

A priori pour ce type de développement ciblé, on maitrise les deux cotés de la chaine, ce qui permet de se mettre d'accord sur un protocole minimaliste
Le protocole HTTP est un choix naturel. Coté iPhone, c'est bien supporté au niveau SDK.
Ensuite il y a plusieurs variantes possibles sur la manière de présenter les requêtes et de transférer les données.
Pour les données on peut utiliser par exemple:
  • un format binaire pour sa compacité
  • un format XML, qui est un choix naturel (parser implémenté dans le SDK iPhone, ou librairie plus évoluée)
  • un format JSON, plus compact et moins pénible à lire par un humain. Il existe des librairies iPhone qui prennent en charge le parsing.

IHM de l'application

L'interface utilisateur de ce type d'application est relativement standard. Il faut éviter de s'en écarter pour:
  • ne pas dérouter l'utilisateur. S'il n'a pas compris comment ça marche en 10 secondes,c'est perdu !
  • éviter les aller retour lors de la soumission à Apple. Si on présente une IHM relativement classique, il faut coller aux guideline Apple.
  • moins on réinvente, moins de code et moins de bug !

Les onglets (Tabulations ?)

Chaque onglet correspond à une fonction relativement indépendante. Apple suggère de se poser la question de faire plusieurs applications indépendantes plutôt que d'avoir plusieurs onglets
Par défaut, quand l'utilisateur sélectionne un onglet, il retrouve le contexte associé tel qu'il l'a laissé. S'il (re)tap (?) sur l'onglet sélectionné, il revient au contexte initial de cet onglet.

La liste des articles

Les listes Cocoa permettent de faire beaucoup de choses. C'est un des principaux éléments d'interface utilisateur sur iPhone. C'est ce qui permet d'afficher la liste des articles ou la liste des demandes de devis dans notre application, mais c'est aussi ce qui permet l'édition des formulaires de demande de devis.

La barre de navigation ("NavBar", en haut de l'écran)

Elle permet en particulier de naviguer entre des vues avec une notion de pile. Par exemple dans l'onglet annuaire, la sélection d'une ligne de la liste ouvre la vue correspondante qui s'empile sur la vue courante. Le bouton "Retour" permet de dépiler. C'est une forme de navigation naturelle, qui a l'avantage de ne pas avoir besoin d'une incarnation pesante à l'écran !

Les "WebView"

Ce sont des vue qui présentent une page Web. Par exemple le contenu de chaque article corresponds à une page Web (une URL sur le serveur). Coté iPhone il n'y a pas grand chose à faire, coté serveur, cela permet de garder beaucoup de souplesse s'il n'y a pas d'interactivité à prévoir à cet endroit.

Alors qu'est ce qui est délicat dans une application comme celle là ?

En général, si on reste bien en phase avec ce qui est proposé par Cocoa, les choses se passent bien.
Quelques difficultés peuvent venir du coté asynchrone de la connexion au serveur. Il faut aussi se souvenir que l'utilisateur peut être connecté avec une liaison très lente ou instable, d'ou l'importance de gérer correctement des caches permettant d'avoir une application réactive.




Menu