source : www.webcssdesign.com

Le terme n’étant pas connu de tous, il est préférable de débuter ces quelques lignes par une petite explication sur la localisation : la localisation permet à votre application de détecter la langue utilisée par le périphérique et proposer ainsi du contenu de la même langue.

Ainsi, avec une seule et même application :

• si un Français l’utilise, il aura une application en Français
• si un américain la télécharge, il l’aura également dans sa langue
• si un suédois la télécharge et que vous ne disposez pas d’une traduction en suédois, vous pourrez par exemple lui proposer la version anglaise.

Récemment nous avons du, pour le compte d’un client, localiser (traduire) une application iPhone en plusieurs langues. Lors du développement initial de l’application, nous n’avions pas anticipé cette évolution et donc rien n’était prévu en ce sens. Par exemple, certains textes étaient embarqués dans les images. Grave erreur! La conversion de l’application en multilingues a été une vraie gageure et nous a servi de leçon.
Dans un premier lieu, à part dans des cas extrêmes, il ne faut pas embarquer les textes dans les images, il faut préférer des UILabel que l’on pourra traduire aisément. Les libellés sont regroupés dans le fichier Localizable.strings avec une version par langue. Il s’agit d’un fichier simple avec mécanisme de clé/valeur. Par héritage du développement en Java, j’ai pour habitude d’utiliser des clés en majuscule mais rien n’est imposé de facto.
Lors de la création de ce fichier et des variantes dans chaque langue, veillez à bien gérer votre gestionnaire de code source. Dans notre cas, il s’agit de SVN. Pourquoi cette remarque? Il est intéressant d’étudier la structure physique (sur votre disque) de ces fichiers de localisation. Pour chaque langue, un dossier nommé xx.lproj (exemple: fr.lproj) est créé et regroupe tous les fichiers localisés dans cette langue. On y retrouvera donc un fichier physique Localizable.strings. Dans le projet sous Xcode, on retrouvera sous le nom de fichier Localizable.strings, toutes les variantes linguistiques (exemple: fr). Comme l’archivage physique de ces données de localisation est fait dans des répertoires, il faut bien veiller à les intégrer correctement dans SVN (ou autre outil de gestion de code source).

Dans certains cas, pour des raisons d’esthétisme évidentes, il est tout à fait possible de localiser les images et d’avoir dans ce cas une image par langue. L’iPhone (ou l’iPad), comme pour les textes, choisira automatiquement la bonne image en fonction de la langue actuelle du périphérique. Les images seront physiquement stockées dans le répertoire de type xx.lproj (comme pour le fichier Localizable.strings).

Il est également possible de localiser le nom de l’application. Pour cela il faut activer l’option « Application has localized display name«  dans le fichier Info.plist et créer un fichier InfoPlist.strings avec la clé « CFBundleDisplayName ».

Il est certain qu’à l’avenir nos applications seront localisées par défaut ce qui permettra, entre autres,  de fournir au client l’ensemble des libellés utilisés dans l’application afin qu’il affine le « Wording » de l’application.

Et vous, localisez-vous vos applications par défaut?

Les notifications Push sont des petites alertes envoyées par les éditeurs des applications installées sur son iPhone. Ces alertes sont reçues même si l’application n’est pas active. L’utilisateur a la possibilité, à tout moment, de bloquer la réception de toutes les notifications ou uniquement celles de certaines applications.

Au sein de I See U, nous avons mis en place pour nos clients un service de Push. Nous avons souffert de quelques loupés sur la mise en place de ce service jusqu’à ce que nous mettions en place ce que je vais vous présenter ce jour : les « Enhanced Apple Push Notifications« , en d’autres termes, l’envoi avancé de notifications.

En quelques mots, comment se passe l’envoi de notifications sur votre iPhone? Le service Web de l’application envoie des messages avec un formalisme défini et signé numériquement aux serveurs d’Apple. Les messages sont entassés dans une file d’attente chez Apple. Ils seront dépilés par la suite en fonction de la charge des serveurs d’Apple. Le mécanisme d’envoi de notifications n’est donc pas synchrone. Si un deuxième message est envoyé pour le même périphérique alors que le premier n’a pas encore été délivré, seul le deuxième sera envoyé au périphérique. Il peut donc arriver que toutes les notifications ne parviennent pas au destinataire. Pour les informations critiques, Apple conseille d’utiliser un autre canal pour informer l’utilisateur (mail, message interne à l’application, …)

La cinématique d’envoi des notifications classiques aux serveurs d’Apple est la suivante :

• Ouverture d’un canal d’échange crypté avec les serveurs d’Apple. Le cryptage se fait grâce à un certificat généré sur le portail de développement.
• Envoi des messages au formalisme suivant :

• Si une erreur se produit, il faut recréer une connexion avec le serveur et continuer l’envoi.

Sur Internet, on trouve certaines personnes qui conseillent d’envoyer les notifications par lot et de clôturer la connexion pour en recréer une aussitôt. Il faut alors décider du nombre de messages envoyés par lot. La bonne pratique semble être d’un millier environ.

Dans ce mode standard, nous n’avons aucun retour sur l’envoi réel des notifications. Nous savons juste que les messages ont été envoyés à Apple.

Ce mécanisme n’était pas acceptable pour nous qui souhaitions fournir un service d’envoi fiable d’autant plus que nous avions remarqué quelques échecs sur certains périphériques. Nous avons donc étudié la solution avancée qui permet de recevoir quelques retours de la part d’Apple.

La cinématique devient donc la suivante :

• Boucle tant qu’il y a des notifications à envoyer
• Ouverture de la connexion sécurisée avec les serveurs d’Apple
• Envoi de n (1000 dans notre cas) notifications avec le formalisme suivant

• Lecture du canal SSL ouvert avec les serveurs d’Apple pour récupérer les potentielles erreurs
• Interprétation des informations renvoyées par Apple au formalisme suivant

• Traitement adéquat s’il y a des erreurs
• Si coupure de la connexion, réouverture (comme en mode standard)
• Fermeture et réouverture de la connexion pour boucler

Grâce à ce mode avancé, nous avons donc plus d’informations sur les éventuelles erreurs. Voici les codes erreur renvoyés :

• 0 : Pas d’erreur rencontrée
• 1 : Erreur de traitement
• 2 : Le « token » du périphérique est manquant
• 3 : Le « topic » du périphérique est manquant
• 4 : Le « payload » du périphérique est manquant
• 5 : La taille du « token » est invalide
• 6 : La taille du « topic » est invalide
• 7 : La taille du « payload » est invalide
• 8 : Le « token » est invalide
• 255 : Inconnue

Lors de nos expérimentations, nous avons remarqué que si une erreur se produisait sur un des messages d’un lot de 1000, les notifications devant être envoyées après celles en erreur n’étaient pas reçues. Nous n’avons trouvé aucune information sur ce point dans la documentation et donc cette information est à prendre avec précaution. Dans nos cas, nous renvoyons donc les notifications qui ont lieues après une erreur dans un lot.

Depuis la mise en place de ce mécanisme, nous n’avons plus de souci avec les notifications.

Si vous aussi vous avez rencontré des soucis avec les notifications Push d’Apple, nous serions ravis d’échanger avec vous sur le sujet.

Source : Documentation Apple

Il n’y a pas que dans les réseaux sociaux que l’on se livre une bataille par chiffres interposés. Chaque mois, des analystes choisissent le vainqueur du combat Android – iPhone au regard de statistiques, laissant places à beaucoup d’interprétations.

Ainsi, selon les chiffres de Novembre produits par Comscore, Android dépasserait en nombre de systèmes d’exploitation l’iPhone aux Etats-Unis avec 26% de part de marché (19.6% en août) contre 25% pour Apple (24.2% en août). La nuance de 1% de part de marché n’est en aucun cas significative, du moins pour les éditeurs d’application, puisque cette différence n’est pas suffisante pour déterminer une prédominance sur le marché.

Cette récente suprématie de l’OS de Google doit d’ailleurs être tempérée par d’autres chiffres : le nombre de périphériques connectés et la fragmentation par version d’Android.

Android, roi de la fragmentation

Android est un système d’exploitation qui peut être installé sur n’importe quel périphérique. Cette souplesse a assuré son succès puisque différents constructeurs s’en sont emparés et ont pu le faire fonctionner sur leurs téléphones. Cette force est aussi la faiblesse d’Android : en effet, les périphériques n’ayant pas les mêmes ressources matérielles, ils n’utilisent pas les mêmes versions du système d’exploitation.

Google joue d’ailleurs la transparence sur le sujet, communiquant régulièrement sur la fragmentation de son système d’exploitation.

Ainsi, si on peut constater qu’Android 2.2 et 2.1 sont de loin les plus utilisés, Android 1.5 et 1.6, avec plus de 10% de part de marché, conservent une place relativement importante. Pour développer une application, il faudra donc choisir entre une application compatible avec l’ensemble du parc mais avec des fonctionnalités limitées ou au contraire bénéficier des mises à jours les plus récentes et écarter de facto une part non négligeable des utilisateurs.

Sur iPhone, il existe également plusieurs déclinaisons de l’iOS. Néanmoins, la fragmentation est beaucoup moins pénalisante pour les éditeurs : en effet, Apple tend à faire évoluer son système d’exploitation en même temps que ses périphériques et à restreindre l’accès aux anciennes générations d’appareils. Cette pression économique tend donc à l’uniticité du parc, au moins d’un point de vue fonctionnel.

iPhone, le navigateur mobile

Net Marketshare publie de son côté une analyse sur les connexions effectuées via mobile. L’iOS arrive loin devant Android. Cet domination est une constante, et ce, malgré l’essor d’Android.

En décembre, la part de marché d’Android n’est que de 0.4% contre 1.7% pour iOS. Si l’on se réfère aux 1er chiffres donnés ici, on peut considérer qu’il y a grosso modo autant de périphériques Android et iOS sur le marché ; or, on constate que ces derniers sont bien plus utilisés pour se connecter à Internet.

Android en 2011 ?

Entre un marché fragmenté et un manque criant d’habitude à utiliser l’internet mobile, le marché de l’édition semble encore assez compliqué sur Android. L’investissement pour un éditeur et/ou un annonceur sera plus facilement rentabilisé sur iOS en développant une application iPhone par exemple ou en mettant en place une campagne iAd qu’en mettant en place une application sur Android. Cela est d’autant plus vrai dans le marché Français puisque l’hexagone, avec plus de 800 000 périphériques, est le pays Européen où l’iPad a rencontré le plus gros succès.