Lors des dernières mises à jour que nous avons faites sur des applications iPhone (iPad), nous avons été confrontés à une nouvelle problématique que l’on croyait réservée aux développeurs Android. Depuis la version 4 du SDK de l’iOS, il apparait indispensable de tester les versions sur les versions 3.x de l’iOS pour éviter de se retrouver face à des instabilités qui n’existaient lors des compilations précédentes.

Il est donc indispensable de conserver les anciens périphériques sous des versions anciennes de iOS. En effet, d’après l’article de Casey Tschida, il y aurait encore, une dizaine d’utilisateurs sur cent avec une version 3.x de l’iOS sur iPhone. Beaucoup d’utilisateurs n’ont pas mis à jour leur iPhone en version 4 car les iPhone 3G sont particulièrement lents sur ces nouvelles versions d’iOS. Cette cible n’est donc pas négligeable et ne doit pas être négligée. De plus, ces instabilités peuvent entraîner très rapidement des commentaires néfastes sur l’AppStore.

Chez I See U, comme vous pouvez le voir sur la photo, nous avons mis tout en oeuvre pour assurer une compatibilité maximale en utilisant un maximum de périphériques de test sous différentes versions d’iOS. Notre seul souci reste de les mettre tous à la même heure.

Et vous, avez-vous déjà rencontré des soucis avec des applications sous iOS 3.x?

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