octobre
2012
Un article de bouye
Shai Almog, Chen Fishbein (Codename One)
TUT qui fait suite à la CON d’hier.
La salle est pleine avec même des gens (qui ne s’étaient pas inscrit à l’avance et n’ont donc pas de place réservée) qui font la queue dehors. Le sujet est très porteur malgré le fait qu’il soit totalement ignoré par Oracle cette année.
Le code est écrit sur leur API, construit, compilé et testé dans NetBeans et Eclipse via leur plugin. Les binaires sont alors expédiées sur leurs serveurs de compilation pour être compilées en natif et signé.
Ils ont ajouté hier qu’en plus de la version limité gratuite (100 compils sur Android et 5 sur iOS) et payante illimitée ($9 par mois), ils ont une licence entreprise pour installer des serveurs de compilation chez leur clients.
– installer le plugin depuis leur site (rajout download center dans NetBeans ou Eclipse). Pour le moment pas de ressources pour le support IntellijIDEA mais les contributions sont acceptées.
– créer un nouveau projet en utilisant le template.
– le choix du package est ultra-important à cause des limitations des différents stores (difficile à changer après coup).
– sélection du thème (thème prédéfini et/ou qui s’adapte à chaque plate-forme).
Il est possible de customiser le style.
– le fichier de ressources contient les images et autres ressources (design des écrans, localisation, fichiers de données, thèmes, etc.) de l’application.
– le fichier app contient la classe principale de l’app. Les méthodes par défaut sont des callbacks appelés au cours du cycle de vie de l’app.
– le fichier state machine base est généré par le GUI builder. Les listeners sur les boutons etc. sont générés ici.
– le fichier state machine hérite du fichier state machine base. Le code du programmeur va dans ce fichier en surchargeant les méthodes de la classe parente.
– l’app crée peut immédiatement être compilée et lancée sur l’émulateur.
– les paramètres propres à chaque plateforme sont accessibles dans les propriétés du projet.
– lorsque la compilation native revient, elle est fournie avec les natifs uniquement. Le code source natif généré est disponible pour les clients payants ou en utilisant directement les solutions OpenSource sur lesquelles sont basées leur produits.
– la compilation native prend soit de générer tous les splash screens iOS (toutes orientations, formats et DPI) nécessaires pour donner l’impression que l’app se lance rapidement (truc utilisé par Apple). Par contre l’usage de ces screenshot fait exploser la taille de l’application.
– créer une interface étendant Native, click droit et Generate native -> génère les codes sources natifs pour toutes les plateformes supportées (C#, Objective-C, davlik, etc.)
– les design doivent être édités via le GUI builder. Des layouts similaires à ceux de AWT/Swing sont utilisés pour s’adapter automatiquement aux différentes tailles d’écran et orientations. Certains layouts vont s’adapter différemment pour s’afficher correctement sur la plateforme cible.
– Il faut prendre soit de fournir des images adaptées pour chaque DPI, les ressource MultiImage se chargent de faire cela de manière transparente pour le programmeur. Il faut pré-scaler les images sur PC car le PC est plus puissant et le scaling est de meilleure qualité. Leur outil de création de multiimage permet de faire cela automatiquement.
– il est possible de rajouter des évents via le GUI builder. Cela ouvre le state machine file dans NetBeans pour permettre d’éditer le code de l’action.
– API unifiée pour accéder au storage propre à l’application, car chaque plateforme gère son storage différemment des autres.
– la méthode beforeMain() permet de faire les pré-chargements avant que l’app ne s’affiche.
– il faut un certificat Apple (payant à l’année, $100) qu’on ne peut obtenir que sur Mac.
– il faut aussi un Mac pour publier sur l’iTunes store.
Commentaires récents
- dans Back from the future…
- dans Back from the future…
- dans Static linking = does not Compute
- dans Paquetage x 2
- dans Why you little…