Affichage des articles dont le libellé est OS X. Afficher tous les articles
Affichage des articles dont le libellé est OS X. Afficher tous les articles

dimanche 21 décembre 2014

Android Studio Mac : conseils d'installation

Lorsque nous installons Android Studio version Mac pour la première fois, quelques erreurs peuvent apparaître.

Par définition les développeurs n'aiment pas les erreurs - autant partir sur une base "saine".

Par exemple une erreur sur une version du JDK Java non installée.

OS X n'installe plus depuis un certain temps les dernières versions du JDK Java - c'est donc à la charge de l'utilisateur de le faire.

Vous devez donc vous assurer que le bon JDK Java soit installé et que le <SDK Location> "pointe" bien sur ce JDK.

Pour la plateforme Android 5 (Lollipop) par exemple le JDK 7 est requis.

Autre erreur : lorsque Gradle (outil d'automation du build de votre application) est exécuté, ce message peut aussi apparaître :

"Gradle : No resource found that matches the given name ..."

En général vous pouvez avoir une centaine d'erreurs de ce type.
Pour résoudre ce problème, cliquez dans un premier temps sur le SDK Manager    et vérifiez que les composants ci-dessous soient installés :



Ensuite quelques modifications dans les propriétés de votre <App> (<open Module settings>).

Dans l'onglet "Properties", veuillez choisir comme <compile SDK version> la dernière version du build d'Android.



Il n'est pas obligatoire de changer la version du SDK pour la <target> de votre application (onglet "Flavors") mais il est recommandé de choisir la dernière version du build d'Android.



Vous pouvez faire la même chose en modifiant directement le fichier <build.gradle>.

Une fois ces modification appliquées, synchronisez votre projet à nouveau.

jeudi 18 décembre 2014

Publication sur Mac App Store : quelques conseils !


Avant de soumettre (et de publier) votre application sur le Mac App Store, il est nécessaire de prendre quelques précautions.

  • La première précaution (qui est peut être la plus importante) : vérifier que toutes les fonctionnalités de votre application fonctionnent correctement !

Cela peut sembler évident mais dans les faits, vous pouvez avoir quelques surprises.

Ayez à l'esprit que lors de la REVIEW de votre application par Apple, tout ce qui est "visible" dans votre application sera testé.

Ce qui est un peu normal car les équipes Apple ne sont pas censées connaître tous les métiers - ils vont donc favoriser les tests IHM.

Par exemple si vous avez des palettes d'outils, soyez certains que la personne en charge de tester votre application va "cliquer" sur chaque outil.

Le conseil qui peut être donné est d'effectuer votre propre REVIEW avant publication.


  • Développez, testez et packagez votre application sur la dernière version officielle de OS X et de XCode

Il est important d'être à jour avec les outils système et de développement officiels (sont exclus les outils en BETA version).

Les tests de votre application peuvent fonctionner sur une version précédente des outils et non sur la nouvelle version - nous sommes dans ce cas dans une phase de régression.

Partez du principe que les équipes Apple travaillent avec les dernières versions des outils et c'est sur ces versions que seront effectués les tests de la REVIEW.


  • Faites une pré - soumission de votre application

Il est possible de faire une pré - soumission sous XCode avant publication finale.

Cette pré - soumission permet de valider "techniquement" l'archive qui va être utilisée pour la publication.

C'est une étape importante qui ne doit pas être négligée.


  • Vérifier le délai de la REVIEW des applications

Même si le délai moyen d'une REVIEW s'est bien amélioré depuis quelques années, il n'en demeure pas moins que ce délai doit être pris en compte.

Cet outil vous donne un aperçu du délai moyen constaté.

Prenez en compte ce délai dans votre planning.

Pour rappel, une REVIEW de votre application ne signifie pas systèmatiquement qu'elle va être approuvée (et donc publiée).

Prévoyez aussi un délai pour d'éventuelles corrections et re-soumissions (avec REVIEW) de votre application.

mercredi 26 novembre 2014

Ouvrir plusieurs instances d'une application OS X


Par défaut, vous pouvez ouvrir qu'une seule instance d'une application sous OS X.

Comment faire pour en ouvrir plusieurs ?

A ne pas faire : copier votre application et lancer "l'original" et la "copie" de votre application.

Car en fait, vous êtes toujours sur la même instance !

La conséquence : les données manipulées par vos deux applications ("l'original" et la "copie") risquent d'être "inconsistentes". 

La bonne pratique :  ouvrir le Terminal et taper :

open -n -a "votre nom d'application"

Une nouvelle instance est ouverte ! Ceci étant possible car OS X est basé sur un noyau UNIX qui permet cette "opération".

mardi 25 novembre 2014

Conseils sur l'intégration de iCloud dans votre application OS X


Quand vous intégrez iCloud dans votre application, il est nécessaire d'être très attentif.

Ce type d'intégration n'est pas si "simple" qu'elle n'y paraît.

Les précautions à prendre sont différentes entre une application OS X et une application IOS.



Voici les étapes qui doivent donc être respectées :

1/ Activer les capacités de iCloud pour votre application sous XCode - pas très compliqué jusque là !


2/ Soyez bien sûr que vos certificats et profils sont corrects et sont à jour (tant au niveau développement qu'au niveau soumission sur l'Apple Store - production) - je vous conseille de vérifier tout cela sur votre compte <apple.developer>.

Si cela n'est pas le cas, vous allez vous trouver devant de grosses difficultés pour tester et soumettre votre application.

XCode est capable d'initialiser correctement cette phase du processus à condition que le nécessaire soit fait sur votre compte <apple.developer>.

A noter que XCode peut se "synchroniser" avec votre compte <apple.developer>.

Ne pas oublier enfin que la durée de validité des certificats & profils est limitée dans le temps et qu'il faut donc les mettre à jour.

Il n'est pas très agréable de gérer ce type de problème lors de la soumission de votre application.


3/ Lisez attentivement le guide d'Apple <iCloudDesignGuide >.

Cela est indispensable pour avoir une vue globale de ce que peut représenter une implémentation de iCloud.

Vous y trouverez de bons conseils et des bonnes pratiques à suivre.

Ce document a pour objectif de vous faire aussi réfléchir sur les fonctionnalités de iCloud qui seront (ou devront être) réellement implémentées dans votre application.

Prenez donc le temps de lire ce document.


4/ Réfléchissez sur la "stratégie" à suivre lors d'un partage (et la modification) d'un même document iCloud par plusieurs utilisateurs connectés sur le même compte iCloud.

Je peux vous dire par expérience que cette étape est cruciale : le travail de développement va dépendre de la "stratégie" que vous allez choisir !

Vous pouvez vous poser ces quelques questions :

Dois-je systématiquement "fusionner" les modifications appliquées par les utilisateurs ?

Quelle est la nature ou le type de document qui est utilisé par mon application ?

Dois-je envisager de faire une "copie" par utilisateur du document modifié ?

Comment intégrer les modifications si je souhaite les gérer ?

Comment notifier aux utilisateurs les actions qui vont être menées ?


5/ Définissez les cas d'utilisation où il sera nécessaire de gérer les modifications d'un document iCloud


6/ Définissez les cas d'utilisation qui vont nécessiter un travail de développement.

Ce qui n'est pas forcément le cas : iCloud dans certains cas gére très bien la situation sans aucun développement de votre part.


7/ Définissez votre "stratégie" de test en mode iCloud


8/ Comment gérer vos problèmes techniques ? 

Ne pas oublier que dans votre contrat développeur vous disposez de tickets <support technique> (support assuré par les équipes d'Apple).

Pour les avoir utiliser plus d'une fois, je vous confirme que le support est de bonne qualité et sérieux.

C'est une aide à ne pas négliger.

Un petit conseil : soyez très précis quand vous utilisez un ticket.

D'abord le nombre de tickets est limité mais surtout pour obtenir une aide précise, il faut être précis.


Comment récupérer l'identifiant "BUILD" de votre application OS X ?


Lorsque vous "buildez" votre application sous OS X, vous générez un identifiant de type UUID.

Cet identifiant peut être utile pour comparer par exemple deux "build".

Il faut toujours s'assurer que nous travaillons sur la bonne "version" de notre application.

Comment alors récupérer cet identifiant ?

Ouvrez le Terminal, puis tapez :

$ dwarfdump —uuid MonApplication.app/Contents/MacOS/MonApplication


Vous devez récupérer une chaine de caractères de type UUID.

Ex : 2E7DA2D7-D494-31E6-BDE9-6DC701BB8D28