2. Présentation
Damien Laureaux
@timoa
Développeur mobile dans une SSII de
Montpellier, je développe des applications
iPhone, iPad et Android depuis plus de 3 ans
en utilisant le framework Appcelerator Titanium.
3. Certifié "Titanium Certified App Developer",
"Titanium Certified Mobile Developer", je fais
partie de la centaine d'experts sélectionnés par
Appcelerator pour aider la communauté
Titanium via le programme "Titan".
5. La plateforme Appcelerator
Appcelerator Titanium est une plateforme
ouverte de développement pour créer des
applications natives entre les différents
terminaux mobiles et systèmes d'exploitation,
dont iOS, Android, Windows, BlackBerry,
Tizen, HTML5 et bientôt Windows Phone.
7. Le framework Titanium
Il comprend un SDK open source avec plus de
5 000 APIs, Titanium Studio, un puissant IDE
basé sur Eclipse, et Alloy, un framework MVC.
9. Des services complémentaires
Pour répondre à ce cycle de vie, Appcelerator
a construit un ensemble de services
complémentaires dont :
● Appcelerator Analytics
● Appcelerator Cloud Services
● Appcelerator Functional Test *
● Appcelerator Performance Management *
* disponible depuis le 30 janvier 2013 mais peu d'informations pour le moment.
10. Le choix de milliers d'entreprises
Appcelerator Titanium est la plateforme de
développement mobile la plus plébiscitée pour
des milliers d'entreprises, y compris eBay,
Merck, Mitsubishi Electric, NBC et PayPal.
11. +50 000 applications mobiles
Avec plus de 50 000 applications mobiles
déployées sur 110 000 000 de terminaux, le
framework Titanium aide les entreprises à
déployer 60% plus vite et obtenir un avantage
concurrentiel significatif.
12. Simplifie le dévelopement
Titanium simplifie le processus de
développement des applications mobiles
permettant aux développeurs de développer
rapidement, tester, compiler et publier des
applications mobiles en utilisant JavaScript.
13. Simplifie le développement
Les développeurs ayant de
l'expérience en développement
Web peuvent devenir productifs
immédiatement pour créer des
applications natives mobiles riches à
partir d'une seule base de code sans
avoir à gérer de multiples outils de
développement, de langages et
méthodologies.
14. Plateformes compatibles
Le SDK Titanium permet de créer des
applications pour les plateformes suivantes :
● iPhone
● iPad
● Android mobile & tablette
● Mobile Web (HTML5)
● BlackBerry 10
● Liseuse Nook Color
● Assistant de navigation Denso
● Tizen (Intel / Samsung OS basé sur Linux)
16. Le futur de Titanium
Développements en cours :
● Windows Phone 8 (fin 2013)
● Windows 8 (fin 2013)
17. Licence Appcelerator
Appcelerator a choisi la licence Apache 2 pour
le SDK Titanium ainsi que pour Titanium
Studio, ce qui les rend gratuits pour une
utilisation personnelle et commerciale.
19. Titanium VS PhoneGap
De loin, Titanium et PhoneGap paraissent
similaire...
Le but commun est de créer une application
mobile cross-platform en utilisant des langages
comme le JavaScript.
Ils sont tous les 2 open-sources et sponsorisés
par de grosses sociétés.
20. L'approche de PhoneGap
L'approche de PhoneGap est de proposer une
application native socle dans laquelle on va
embarquer des pages HTML5 et du JavaScript
pour communiquer avec celle-ci.
Les pages HTML5 sont affichées dans une
fenêtre navigateur (WebView) proposée sur la
plupart des plateformes.
21. Points forts de PhoneGap
La création d'une application mobile simple est
facilitée par l'utilisation du HTML5 et JS.
C'est pour cela que l'équipe de PhoneGap n'a
implémentée qu'une partie des API natives, ce
qui permet ainsi de porter PhoneGap sur
d'autres plateformes plus rapidement.
L'accès au développement mobile est ainsi
facilité pour les développeurs Web.
22. Points faibles de PhoneGap
La qualité du rendu est dépendant de la
plateforme... iOS utilise Webkit comme moteur
de rendu et offre les meilleurs performances
mais celui d'Android est juste fonctionnel sur
les versions 2.x
Le support d'HTML5 peut être incomplet entre
navigateurs et donc entre les plateformes.
23. Points faibles de PhoneGap
Les performances sont donc variables d'un OS
à un autre et les animations de transition sont
gérées en JavaScript et n'utilise pas
l'accélération matérielle (GPU).
Comparé à du natif, la surcouche navigateur +
moteur JavaScript rend une application
PhoneGap plus lente et réactive dès lors que
l'on utilise beaucoup de données ou traitement
(liste, animation, etc).
24. Points faible de PhoneGap
Le workflow peut être aussi un point noir si l'on
utilise pas PhoneGap Build car il faut configurer
et utiliser un IDE par plateforme :
● XCode pour iOS
● Eclipse pour Android
● Visual Studio pour Windows Phone
● etc...
26. Présentation
A l'origine, Aptana Studio était un IDE open
source basé sur Eclipse et adapté au
développement Web (PHP, HTML, CSS,
Javascript, Python ou encore Ruby).
Aptana a été racheté par Appcelerator et c'est
comme ça qu'est né Titanium Studio.
27. Fonctionnalités spécifiques
En plus des fonctionnalités d'Eclipse, celles
héritées d'Aptana, Titanium Studio apporte
d'autres fonctions indispensables :
● Gestion de projet (création pas à pas,
éditeur pour tiapp.xml, nettoyage des
projets)
● Configuration de projet (choix de l'API,
réglages émulateurs, etc...)
● Console de sortie et filtres
● Menu "Démarrer" et "Déploiement"
● Déploiement mobile et distribution (stores)
28. Autres fonctions de Ti Studio
● Intégration de Git, SVN, etc...
● Navigateur intégré pour les tests HTML/Web
● Déploiement HTML/Web, PHP (ftp, sftp,ftps)
● Déploiement et distribution pour PHP, Ruby
(Engine Yard, RedHat Cloud, Capistrano)
31. Chaîne d'outils
Pour créer une application mobile de bout en
bout, il faut un certain nombre d'outils pour :
● La gestion du projet
● Ecrire le code source
● Compiler le code source
● Debugger l'applicaton
● Simuler l'application
● Signer et distribuer l'application
32. La chaîne d'outils pour Android
Exemple de la chaîne
d'outils nécessaire à
la création d'une
application Android
native.
33. La chaîne d'outils pour iOS
Exemple de la chaîne
d'outils nécessaire à
la création d'une
application iOS native.
34. La chaîne d'outils Titanium Studio
Avec Titanium Studio,
l'ensemble de la
chaîne nécessaire à
un projet mobile est
traité en utilisant un
seul logiciel.
36. L'environnement Javascript de Ti
Interpréteur V8 / Rhino sous Android et
JavaScriptCore sous iOS.
Le code est exécuté dans un "contexte
exclusif", similaire au thread JS dans un
navigateur.
Le fichier app.js définit le contexte "racine" de
l'application et la plupart du temps, un contexte
suffit.
37. Base d'une application JavaScript
Pour la plupart des développeurs, le 1er projet
Titanium est leur première application écrite en
JavaScript.
Il est important d'adhérer à certaines règles :
● Protéger le scope global (variables globales)
● Être modulaire
● S'efforcer de garder le code DRY (Don't
Repeat Yourself)
38. Namespaces
JavaScript partage un seul espace de nom
global et unique.
Placez vos variables dans cet espace pour :
● Prévenir des collisions
● Fournir un "conteneur" pour vos variables
● Suivre le modèle de Titanium :
Titanium.UI, Titanium.App, Titanium.API, ...
39. Namespaces
Création de l'objet qui servira de variable
globale pour l'application :
var MyApp = {};
MyApp.someproperty = 'foo';
MyApp.somefunction = function() {};
Création d'un sous namespace :
MyApp.DB = {};
40. CommonJS
Avantages de l'utilisation de CommonJS :
● Les modules ont leur propre espace de nom
global
● Pas d'accès à l'espace de nom du contexte
appelant
● Retourne seulement les propriétés et
méthodes que vous avez spécifié
● Le reste est "privé"
41. Base saine d'une application
1. Le fichier app.js doit être votre "bootstrap"
2. Définir l'espace de nom de votre application
3. Utiliser Require() pour charger vos modules
4. Créer et ouvrir votre premier composant UI
42. Les événements
Similaires aux événements JavaScript dans un
navigateur Web.
On peut utiliser addEventListener() sur
pratiquement tous les objets JavaScript.
On peut aussi programmer de déclencher des
événements sur des objets avec fireEvent().
43. Les évènements
Les événements sont accessibles au travers de
l'application, ce qui s'avère utile pour
communiquer entre plusieurs contextes
(modules CommonJS par exemple) via des
données JSON sérialisées.
Ti.App.fireEvent('myEvent', { "id": 396 });
Ti.App.addEventListener('myEvent', function(e) {
Ti.API.log('ID: ' + e.id); });
45. Présentation
Comme nous l'avons vu plus tôt, les interfaces
d'iOS et d'Android ont des éléments communs
mais aussi beaucoup de composants
graphiques spécifiques à celles-ci.
48. Pour un développeur Web...
Une window est l'équivalent d'une page
Une view est l'équivalent d'une div
L'espace de nom Ti.UI fournit plusieurs
contrôleurs spécifiques (button, textfield,
picker, scrollview)
Les objets UI sont composés de la même
manière que les fragments du DOM JavaScript
49. Position et agencement
Position
● top et left
● bottom et right
● center
● size (rendu)
Agencement
● Absolute
● Vertical
● Horizontal
50. Agencement absolu
Pour iOS, le bouton va se positionner à 170pt
et pour Android à 170px, du haut de la window.
51. Agencement absolu
Pour iOS, le bouton va se positionner à 170pt
et pour Android à 170px, du haut de la window.
52. Agencement vertical
L'agencement
vertical permet
d'empiler les
éléments
verticalement.
La valeur de top
devient alors
relative à l'élément
précédent et non à
celle de la window.
54. Introduction
La caractéristique unique de Titanium vis à vis
des différentes solutions mobiles cross-
plateform disponibles, est qu'il crée
véritablement des applications natives.
C'est ce qui contraste avec les solutions Web
qui offrent des fonctionnalités via une vue Web
améliorée comme la solution PhoneGap.
55. Introduction
Appcelerator, ne souhaitant pas être limitée par
l'affichage Web natif, ils se sont engagés dans
une intégration beaucoup plus profonde avec
les plateformes iOS et Android par exemple.
Cela donne aux développeurs la possibilité
d'utiliser des services et composants UI natifs,
avec des performances quasi-natives,
caractéristiques que vous ne trouverez pas
dans d'autres solutions cross-plateform
mobiles.
56. Introduction
De plus, vous aurez accès aux fonctionnalités
suivantes :
● APIs spécifiques à chaque plateforme
● Géolocalisation
● Partage sur les réseaux sociaux
● Multimédia
● Données en ligne ou stockées en local
● Extensibilité via des modules
● et bien d'autres !
57. Vue d'ensemble du SDK Titanium
Performance native Multimédia
Performance native + Interface native Appareil photo, caméra, lecture en
(tableaux, animations, gestes, etc.) streaming / local, format audio / vidéo
Géolocalisation Analytics
Réalité augmentée, géolocalisation, Statistiques d'utilisation personnalisé, utilisation
boussole, cartes natives / adoption de l'app. par l'utilisateur
Réseaux sociaux Titanium+Plus
Authentification à Facebook, Twitter, Base de données cryptée, ecommerce,
Yahoo YQL. E-mail et carnet d'adresse natif publicité, lecteur de code barre, etc
Données Outils développement
Base SQLite locale, webservices, Créer, tester et publier votre application avec le
enregistrement simplifié de clef / valeur même outil peu importe la plateforme
58. Développer pour plusieurs OS
L'API Titanium fournit une variable "plateforme"
qui peut être utilisée avec des instructions if.
Les ressources qui peuvent être spécifiques à
une plateforme :
● Fichier de code
● Images, texte et autres types de fichier
La configuration de chaque plateforme se
trouve dans le fichier tiapp.xml
59. Répertoires par plateforme
Le répertoire
Ressources peut
contenir les
répertoires android,
iphone, mobileweb,
blackberry afin de
placer les fichiers
spécifiques à chacune
de ces plateformes
(images, fichiers JS,
etc...).
61. Internationalisation
Que ce soit pour distribuer votre application en
plusieurs langues ou une seule, il est conseillé
d'utiliser l'i18n avec les projets Titanium.
En effet, c'est un bon moyen de séparer les
termes utilisés du code source et facilitera la
maintenance de l'application.
Le support multilingue est très simple à
implémenter avec Titanium.
62. Internationalisation
Dans le code, il faut utiliser :
Ti.Locale.getString('welcome_message');
ou son alias plus court :
L('welcome_message');
63. Composer l'interface utilisateur
50% ou plus, de votre travail va reposer sur la
construction des composants de l'interface
utilisateur.
Le reste, consiste à créer la logique de gestion
des événements.
La maintenance de votre application sera plus
facile si elle est découpée en "petits"
composants.
64. Les windows
Une window est un conteneur de niveau
supérieur qui peut contenir d'autres views.
Elle peut être ouverte et fermée.
A l'ouverture, la window et les views enfants
sont ajoutées à la pile de rendu de l'application,
au-dessus de toutes les windows
précédemment ouvertes.
65. Les views
Les views sont la base de tous les composants
de l'interface utilisateur.
Après avoir créer une view, il est important de
ne pas oublier de l'ajouter à son view parent ou
à une window, sinon elle ne s'affichera pas.
66. Les événements
La liste des événements déclenché par les
objets Titanium est différente en fonction de
ceux-ci, il est donc conseillé de consulter la
documentation.
Les événements peuvent aussi être utilisés
pour communiquer entre différente partie de
l'application ou module CommonJS.
67. Les événements
Pour déclencher un événement personnalisé,
on utilise la fonction Ti.App.fireEvent() :
var dbCount = 15;
Ti.App.fireEvent('myApp:saveDB', {
count: dbCount
});
68. Les événements
On intercepte ensuite l'événement avec Ti.
App.addEventListener() :
Ti.App.addEventListener('App:saveDB',
function(e) {
alert(e.count + ' éléments sauvés');
}
);
70. L'objet Titanium HTTPClient
Ti.Network.HTTPClient implémente la
spécification XHR (XMLHTTPRequest).
C'est une interface client HTTP de bas niveau
avec support de tous les "verbes" HTTP (GET,
POST, PUT, DELETE, etc).
La façon d'utiliser XHR devrait être familière
aux développeurs Web utilisant Ajax.
71. JSON en tant que format d'échange
JSON est recommandé comme format de
transport de données pour Titanium Mobile.
Il est très simple de sérialiser les données de
réponse :
JSON.parse()
Convertit un string vers un objet JavaScript
JSON.stringify()
Convertit un objet JavaScript vers un string
73. Introduction
Le framework Alloy est un nouveau framework
d'Appcelerator, conçu pour développer
rapidement des applications Titanium de
qualité.
Il est basé sur l'architecture MVC et contient un
support intégré pour Backbone.js et
Underscore.js
74. Modèle-Vue-Contrôleur
Alloy utilise une structure model-view-controller
(MVC) pour séparer l'application en
3 composants différents :
● Les modèles
● Les vues
● Les contrôleurs
75. Les Modèles
Les modèles fournissent la logique métier,
contiennent les règles, les données et l'état de
l'application.
Les modèles sont spécifiés avec des fichiers
JavaScript qui fournissent un schéma de la
table, la configuration de l'adaptateur et de la
logique.
76. Les Vues
Les vues fournissent les composants de
l'interface graphique pour l'utilisateur ou permet
à l'utilisateur d'interagir avec les données du
modèle.
Les vues sont construites à partir des
composants graphiques du SDK Titanium et
définies à l'aide de balises XML et de feuilles
de style Titanium Style Sheets (.tss).
77. Les Contrôleurs
Les contrôleurs fournissent le ciment entre les
composants du modèle et la vue sous la forme
d'une logique d'application.
Les contrôleurs Alloy ont généralement une
relation directe avec les vues.
Les contrôleurs ont accès à tous les éléments
de la vue et peuvent profiter des événements
de l'API Backbone.js.
78. Avantage du MVC
Un avantage du MVC est la possibilité de
réutiliser le code en séparant la fonctionnalité.
Par exemple, vous pouvez avoir des vues
spécifiques pour les différents terminaux, tout
en gardant le code du contrôleur relativement
le même, et les données du modèle
inchangées.
80. Alloy : MVC avec Backbone
Les modèles d'Alloy sont construits autour de
Backbone.js, profitant des API Model et
Collection de celui-ci.
On définit les modèles en JavaScript pour
étendre les fonctionnalités des modèles et des
collections Backbone.
81. Underscore.js
Alloy intégre aussi le support de la librairie
Underscore.js, qui fournit un ensemble de
fonctions supplémentaires à JavaScript comme
par exemple, la manipulation des tableaux.
82. Structure et conventions
Pour simplifier le développement, Alloy utilise
une structure de répertoire et des conventions
de nommage pour organiser l'application plutôt
que d'utiliser des fichiers de configuration.
Tout dossier ou fichier qui ne respecte pas les
conventions suivantes, sont ignorés par Alloy.
83. Structure et conventions
Par exemple, au moment de la génération,
Alloy va chercher les fichiers requis
app/views/index.xml et
app/controllers/index.js, puis le fichier
optionnel de style app/styles/index.tss.
Alloy a besoin de ses fichiers pour créer la
vue-contrôleur suivante :
Resources/alloy/controllers/index.js.
84. Structure des répertoires
app Contient les modèles,
vues, contrôleurs et
les médias (images,
pdf, sons, vidéos, etc)
app/config.json Configuration du
projet Alloy.
85. Structure des répertoires
app/assets Contient les images et
autres fichiers que
vous avez besoin de
copier dans le
répertoire Resources.
Il peut comporter
d'autres répertoires
comme app/fonts
pour les polices.
87. Structure des répertoires
app/lib Contient les librairies
spécifiques à
l'application, la plupart
du temps au format
CommonJS.
Contient le fichier de
app/migrations
migration de la DB au
format
<DATETIME>_fichier.json
88. Structure des répertoires
app/models Contient les modèles
dans le format
fichier.js
app/styles Contient les styles des
vues au format
fichier.tss appliqué
au fichier de la vue
app/views/fichier.xml
89. Structure des répertoires
app/themes Contient les thèmes,
avec des styles et
médias personnalisés
en fonction du thème.
app/widgets Contient des widgets
permettant d'utiliser
des composants d'une
application Alloy à une
autre.
90. Structure des répertoires
app/views Contient les vues au
format fichier.xml
correspondant aux
fichiers
app/controllers/fichier.js
et app/styles/fichier.tss
Contient les fichiers
i18n
i18n/fr (exemple)
de langue au format
i18n/en (exemple)
strings.xml
91. Structure des répertoires
Ressources Contient le projet
Titanium généré par
Alloy à partir des
fichiers présents dans
le répertoire app.
Tous les fichiers sont
écrasés à chaque fois
qu'Alloy génère
l'application Titanium.
92. Notes
Les répertoires lib, migrations, themes et
widgets ne sont pas automatiquement créés
lors de la création d'un nouveau projet.
Les répertoires migrations et widgets
peuvent être créés lorsqu'un composant est
généré à partir du menu contextuel.
Les répertoires lib et themes sont à créer
manuellement.
93. Gestion des plateformes
Les controleurs, vues et styles peuvent avoir
des fichiers spécifiques pour Android, iOS ou
Mobile Web (HTML5).
Il suffit d'ajouter un répertoire android, ios ou
mobileweb dans les répertoires controllers,
views ou styles.
On peut aussi, utiliser des conditions et
attributs dans le code des contrôleurs, vues et
95. Widgets
Les widgets sont des composants autonomes
qui peuvent être facilement intégrés dans les
projets Alloy.
Ils ont été conçus comme un moyen de
réutiliser le code dans de multiples applications
ou pour être utilisés plusieurs fois dans une
même application.
96. Widgets
Les widgets ont leurs propres modèles, vues,
contrôleurs, styles et médias et doivent se
trouver dans le répertoire app/widgets.
Des widgets sont déjà fournis avec Alloy et il
est recommandé de créer ce type de
composant pour rendre le plus modulable
possible son application et pouvoir réutiliser
ceux-ci dans d'autres applications.
97. Builtins
Alloy contient aussi des utilitaires additionnels
utilisés pour simplifier certaines fonctions
comme les animations ou la manipulation des
variables par exemple.
Ces utilitaires sont appelés des builtins et
peuvent être chargés dans le contrôleur.
98. Utiliser les Builtins
Pour utiliser les builtins, il suffit de les déclarer
dans le contrôleur avec le répertoire alloy
comme répertoire racine.
Dans cette exemple, la vue courante vibre
quand on clique sur le bouton shake :
var animation = require('alloy/animation');
$.shake.addEventListener('click', function(e){
animation.shake($.view);
});
99. Installation d'Alloy
Alloy est installé automatiquement à partir du
SDK Titanium 3.0
Il est possible de l'installer manuellement, en
ligne de commande (exemple sur un Mac OSX
ou Linux Ubuntu) :
$ sudo npm install -g alloy
100. Le fichier View
Le fichier view déclare la structure de l'interface
graphique.
Cet exemple défini une window avec une
image et un label.
Fichier app/views/index.xml
<Alloy>
<Window>
<ImageView id="logoImage" onclick="clickImage"/>
<Label id="logoLabel">Cliquer sur le logo Apple</Label>
</Window>
</Alloy>
101. Le fichier Style
Le fichier style formate et style les composants
du fichier view dans un format proche des
feuilles de style CSS.
Par exemple, le style suivant définit la couleur
de fond de la window, la position, dimensions
et couleur du label et position, dimensions et
chemin de l'image.
103. Le fichier Controller
Le fichier contrôleur contient la logique de
présentation, qui répond à l'entrée de
l'utilisateur.
Par exemple, le code suivant crée une boîte de
dialogue lorsque l'utilisateur clique sur l'image.
104. Le fichier Controller
Fichier app/controllers/index.js
function clickImage(e) {
Titanium.UI.createAlertDialog({
title:'Image View',
message:'Vous avez cliqué !'
}).show();
}
$.index.open();
105. Le répertoire Asset
Pour que l'image de l'exemple puisse être
utilisée, il faut la copier dans le répertoire
app/asset/images.
Elle sera copiée dans le répertoire
Ressources/images par Alloy durant la
compilation.
106. Compilation et exécution
Avec Titanium Studio, il suffit de cliquer sur le
bouton Run et de sélectionner le type de
terminal pour lancer la compilation.
Alloy va générer les fichiers Titanium à partir du
projet Alloy (contenu du répertoire app) qui
seront ensuite compilés par Titanium Studio.
107. Utilisation des contrôleurs
Tous les éléments de l'interface ayant un
attribut id dans une vue sont automatiquement
définies et disponibles en tant que propriété
préfixé par la variable spéciale $ dans le
contrôleur.
Le $ est une référence au contrôleur.
109. Utilisation des contrôleurs
Dans l'exemple précédant, le préfixe $.label
dans le contrôleur est utilisé pour accéder à
l'instance de l'objet Ti.UI.Label dans la vue.
Cette référence est utilisée pour accéder
directement aux propriétés ou aux méthodes
de cet objet.
Par exemple, l'appel de $.label.hide()
cache le label de la vue ou vous pouvez
modifier le texte du label avec $.label.text.
110. Utilisation des contrôleurs
Pour accéder à des contrôleurs externes et des
vues, utilisez respectivement les méthodes
Alloy.createController (pour ouvrir une
nouvelle window par exemple) et Controller.
getView.
Si l'objet UI du plus haut niveau n'a pas
d'identifiant défini (id), la référence utilisée est
le nom du contrôleur préfixé par $.
111. Utilisation des contrôleurs
Mais si un attribut id a été défini, par exemple,
<Window id='window'>, le contrôleur a besoin
d'utiliser $.window pour accéder à l'objet
Window.
$.index ne sera pas défini et l'application
renverra une erreur lors de l'appel $.index.
open().
112. Constantes Alloy
Constantes définies par Alloy, à utiliser dans le
contrôleur :
OS_IOS
true si la cible de compilation en cours est iOS
OS_ANDROID
true si la cible de compilation en cours est Android
OS_MOBILEWEB
true si la cible de compilation en cours est Mobile Web
113. Constantes Alloy
ENV_DEV
true si la cible du compilateur actuel est de compiler pour
le développement (en cours d'exécution dans le simulateur
ou émulateur)
ENV_TEST
true si la cible du compilateur actuel est de compiler pour
les essais sur un appareil
ENV_PRODUCTION
true si la cible du compilateur actuel est de compiler pour
la production (exécuté après une installation du paquet)
114. Utilisation des widgets
Pour utiliser un widget, il faut d'abord l'ajouter
en tant que dépendance dans le fichier
config.json :
"dependencies": {
"com.appcelerator.loading":"1.0"
}
115. Utilisation des widgets
Ensuite, ajoutez-le à une vue dans le projet, en
utilisant la balise Require ou Widget (Alloy
1.0) :
<Widget id="loading" src="com.
appcelerator.loading"/>
116. Utilisation des modèles
Avec Alloy, les modèles héritent de la classe
Backbone.Model.
Ils contiennent les données interactives et la
logique utilisée pour les contrôler et y accéder.
Les modèles sont spécifiés avec les fichiers
JavaScript qui fournissent un schéma de la
table, la config. de l'adaptateur et la logique
pour étendre la classe Backbone.Model
117. Utilisation des modèles
Les modèles sont automatiquement définis et
disponibles dans le scope du contrôleur du
fichier JavaScript du même nom.
Le fichier JavaScript exporte une définition de
l'objet composé de trois objets différents.
Le premier objet, appelé config, définit le
schéma de la table et de l'information de
l'adaptateur.
118. Utilisation des modèles
Les deux autres objets extendModel et
extendCollection définissent des fonctions
pour étendre, outrepasser ou implémenter les
classes Backbone.Model et Backbone.
Collection.
128. Projet JUG Mobile Titanium
Les sources de l'application JUG Mobile codé
en Titanium lors de la 2ème partie se trouve
sur Github.
Vous pouvez y contribuer ou le récupérer pour
démarrer un projet par exemple.
https://github.com/timoa/JUGMobile_Titanium