Architecture ASIS pour le développement iOS

1. ARCHITECTURE ASIS POUR LE
DÉVELOPPEMENT IOS
HELA BEN KHALFALLAH

2. YOU SHOULD BE ABLE TO EXTEND
THE BEHAVIOR OF A SYSTEM
WITHOUT HAVING TO MODIFY THAT
SYSTEM.
Robert C. Martin
OBJECTIF 2

3. CONTEXTE
CARACTÉRISTIQUES D’UNE APPLICATION MOBILE - PSCR
APPLICATION
PERFORMANTE
CONFORME RÉGLABLE
STABLE
3

4. CONTEXTE
CARACTÉRISTIQUES D’UNE APPLICATION MOBILE - PSCR
▸ Performante : rapide (algorithme optimal), fluide , précise, ne
consomme pas beaucoup de mémoire, des précautions contre
les « memory warning ».
▸ Stable : pas de crash, pas de bug, toujours la même réponse et
le même affichage, des précautions contre les « cas
particuliers » de son environnement.
▸ Conforme : aux guidelines Apple, aux guidelines UI/UX et aux
demandes clients.
▸ Réglable : maintenable et extensible facilement et rapidement.
4

5. CONTEXTE
CONTRAINTES DE DÉVELOPPEMENT MOBILE
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNE
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
BACKEND
APPLICATION
MISE EN
FORME & THÈMES
RÉ-ORGANISATION
STRUCTURE DES
TABLES DB
COMMUNICATION
HTTP & PARSING
APIS - EXTERNES
IMAGES,
SONS & VIDÉOS
MULTI - LANGUES
5

6. CONTEXTE
APPLICATION MOBILE BOÎTE NOIRE
APPLICATION
Mise en forme
Données statiques
Backend
OS
Accès aux ressources
matériels, Connectivité , push
Ressources (images,…)
Langues
6

7. CONTEXTE
CONTRAINTES DE DÉVELOPPEMENT MOBILE
▸ Les demandes clients (mise en forme, langues, ressources, réorganisation,
backend,…), les évolutions « OS » ainsi que les évolutions « APIs » nuisent
à la « santé » de l’application.
▸ L’application doit être « Réglable » : s’adapte aux changements.
▸ L’application est assimilé à un jeu de « Lego » : réorganisation sans altérer
la stabilité.
▸ La « mise en forme » ne doit pas toucher le code source.
▸ Le gestion multi-langue ne doit pas toucher le code source.
▸ Le changement des ressources (images, vidéos, sons,…) ne doit pas
toucher le code source.
▸ Le changement des données statiques ne doit pas toucher le code source.
7

8. CONTEXTE
SITUATION ACTUELLE DE DÉVELOPPEMENT IOS
▸ Le changement de la mise en forme via les fichiers xib est lent
(lourd surtout pour les storyboards) et ne peut pas être automatisé.
▸ La gestion des différents thèmes ne peut pas s’effectuer via les
fichiers xib.
▸ La « mise en forme » doit être faite par un développeur (via les xib).
▸ Couplage entre la partie « mise en forme » et la partie
« développement ».
▸ Le dossier xcassets devient illisible si le nombre d’assets devient
important et la recherche devient inefficace.
8

9. CONTEXTE
▸ La communication entre l’application et l’OS peut changer avec la version
d’OS.
▸ L’évolution des API-EXTERNES altère la stabilité de l’application.
▸ Chaque changement dans la partie « backend » entraîne des changements
côté « application mobile » (communication http, parsing (json,object-
mapper), les modèles, les tables de la base de données).
▸ L’évolution de l’application (ré-organisation, mise en forme, ajout d’une
nouvelle langue, …) est coûteuse.
▸ La maintenance de l’application est coûteuse (correction des bugs, mise en
forme, …).
▸ La passation et le partage du code source entre les développeurs nécessitent
beaucoup de temps.
SITUATION ACTUELLE DE DÉVELOPPEMENT IOS
9

10. PROBLÉMATIQUES
▸ Tenant compte de ces contraintes, comment peut-on
effectuer des mises à jour, des extensions, des
réorganisations et des maintenances en changeant le
minimum de code?
▸ Est-il possible de gérer la « mise en forme » sans
passer par le code ?
▸ Peut-on déléguer la responsabilité de « mise en
forme » à une personne tierce (non développeur ) ?
▸ Est-il possible de changer le contenu « statique » sans
toucher le code ?
▸ Comment préserver la stabilité de l’application face
aux changements de contenu « dynamique » ?
▸ Est-il possible de s’adapter aux changements « OS » en
changeant le minimum de code ?
▸ Comment mettre à jour le dossier « Xcassets » sans
perdre du temps dans la recherche et éviter les retours
en arrière ?
▸ Comment ajouter une nouvelle langue sans altérer au
fonctionnement de l’application et changer le métier
déjà fait ?
10

11. DÉFINITION
L’ARCHITECTURE ASIS
11
A S I S
APIS
SERVICES
INTERFACE (UI)
SETTINGS (MISE EN FORME)

12. DÉFINITION
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNEAPPLICATION
SETTINGS
SERVICES
UI
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
BACKEND
APIS
12

13. DÉFINITION
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNEAPPLICATION
SETTINGS
SERVICES
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
BACKEND
APIS
VIEWS
VIEWCONTROLLERS
APPDELEGATE
OBSERVER/PROTOCOLS
UI
13

14. DÉFINITION
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNEAPPLICATION
SETTINGS
SERVICES
UI
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
BACKEND
APIS -
EXTERNES
APIS -
INTERNES
API
14

15. CONTEXTE
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNEAPPLICATION
SERVICES
UI
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
BACKEND
APIS
SETTINGS
PLIST
SETTINGS
LANGUAGE
FILES
FILES
XCASSETS
CONSTANTS
SETTINGS
15

16. CONTEXTE
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT INTERNE ENVIRONNEMENT EXTERNEAPPLICATION
SETTINGS
RESTFULSERVICES
REPOSITORIES
MANAGERS
UI
ACCÈS AUX
RESSOURCES
MATÉRIELS,
CONNECTIVITÉ ,
PUSH
OS
CLIENT
MODELS
BACKEND
APIS
SERVICES
16

17. CONTEXTE
COMPOSANTS DE L’ARCHITECTURE ASIS
ENVIRONNEMENT
INTERNE OS
APPLICATION
UI
RESTFULSERVICES
PLIST
SETTINGS
LANGUAGE
FILES
FILESFILE MANAGER
UI-MANAGERS
LANGUAGE
MANAGER
LOCATION
MANAGER
PUSH MANAGER
REACHABILITY
MANAGER
MANAGERS
NOTIFICATION MANAGER
MODELS REPOSITORIES
ENVIRONNEMENT
EXTERNE
CLIENT
BACKEND
LOCALISATION
CONNECTIVITÉ
PUSH-NOTIFICATIONS
NSNOTIFICATIONCENTER
APIS
CONSTANTS
FILES
AUTRES
XCASSETS
17

18. CONTEXTE
LES COUCHES DE L’ARCHITECTURE ASIS
18

19. CONTEXTE
L’ARCHITECTURE ASIS
▸ Découplage entre la partie « mise en forme » des UIs et UI.
▸ Habillage et ré-habillage facile de l’application avec des différents thèmes uniquement en changeant les propriétés
dans les fichiers plist.
▸ Abstraction de la communication UI et « backend ».
▸ Découplage entre la partie communiquant avec « backend » et la partie UI.
▸ Abstraction de la communication UI et « base de données ».
▸ Découplage entre la partie communiquant avec la « base de données » et la partie UI.
▸ Abstraction de la communication « OS » et « Application ».
▸ La communication avec l’OS est faite à travers une seule et unique frontière: managers (centralisation des
évolutions et changements au niveau d’une seule couche).
▸ Les managers communiquent avec les autres composants de l’application.
▸ La partie UI est consommatrice : elle exploite les données en entrées sans faire des traitements.
▸ La partie UI est responsable à l’affichage uniquement.
▸ Les traitements métiers sont assurés par la couche service. Ce qui donne l’opportunité de gérer l’exécution de ces
traitements (Mainthread, Background, Ordonnancement (série, parallèle)).
▸ La partie UI restera claire et simple et elle ne fait que ces taches : affichage et interaction avec l’utilisateur.
19

20. SETTINGS
PLIST DE MISE EN FORME
▸ Problématique 1: Est-il possible de gérer la « mise en forme » sans passer
par le code (ni xib ni code) ?
▸ Solution : la « mise en forme » doit être détachée du code source en
utilisant des fichiers externes.
▸ Les fichiers externes doivent reproduire la structure « attribut »/« valeur ».
▸ Les formats des fichiers adoptant le concept key/value : json, plist, xml.
▸ Problématique 2: Peut-on déléguer la responsabilité de « mise en
forme » à une personne tierce (non développeur) ?
▸ Les formats (json, plist , xml) sont lisibles et compréhensibles par les non
développeurs.
20

21. SETTINGS
PLIST DE MISE EN FORME
▸ JSON : non organisé, taux d’erreur élevé (format, encodage, caractères spéciaux, …),
illisible et incompréhensible si la quantité de données devient importante, besoin de
passer par un validateur. => ce format ne peut pas être utilisé.
▸ XML : organisé (balises) et toujours lisibles et compréhensible. Sauf que le parsing
« xml » est très coûteux en terme de performance et développement. => ce format ne
peut pas être utilisé.
▸ Plist : format particulier d’XML.
▸ Les fichiers plist sont utilisés nativement pour sauvegarder les propriétés de
l’application, les bundles,….
▸ En outre, le contenu des fichiers plist est directement « sérialisé" dans les array, les
dictionnaires, les strings,… sans passer par un « parseur ». => le format plist va être
utilisé pour sauvegarder les propriétés de « mise en forme ».
The preferred way to store property lists on OS X and iOS is as an XML file called an XML property list or XML plist. These files have the
advantages of being human-readable and in the standards-based XML format. The NSArray and NSDictionary classes both have methods for
saving themselves as XML plists and also have methods to convert XML property lists back to objects in memory. CFPropertyList provides
functions for converting property lists to and from their XML representation. - Mac Developer Library - Property List Programming Guide - Apple
21

22. SETTINGS 22

23. SETTINGS
ACCESSIBILITY LABEL
▸ Problématique 3: comment relier les paramètres
définies dans le fichier plist à un composant ?
▸ Solution : à travers l’accessibility.
▸ À chaque composant UI on associe une
« Accessibility Label ».
▸ Le key dans les fichiers « plist » sont les
« Accessibility Label ».
23

24. SETTINGS
ACCESSIBILITY LABEL
▸ Les noms doivent être en Anglais.
▸ Ils doivent être significatifs et intuitifs.
▸ ecran.fonction : pour les écrans simples ayant un seul
niveau. Exp : inscription.editprofil
▸ ecran.emplacement.fonction : pour les écrans multi-
niveaux (navigation parallèle : menu, toolbar, tabbar).
Exp : menu.inscription.editprofil
À TRAVERS L’ACCESSIBILITY ON IDENTIFIERA L’EMPLACEMENT ET LE RÔLE DU COMPOSANT
24

25. SETTINGS
STRUCTURE DES PLISTS
▸ Les fichiers plists sont décomposés par type de composant : button, label,
textfield, …
▸ Le key dans les fichiers « plist » sont les « Accessibility Label ».
▸ À chaque key correspond un dictionnaire de « propriétés » .
25

26. SETTINGS
LIAISON ENTRE LES PLISTS DE SETTINGS ET LA COUCHE UI
ENVIRONNEMENT
INTERNE OS
APPLICATION
UI
RESTFULSERVICES
PLIST
SETTINGS
LANGUAGE
FILES
FILESFILE MANAGER
UI-MANAGERS
LANGUAGE
MANAGER
LOCATION
MANAGER
PUSH MANAGER
REACHABILITY
MANAGER
MANAGERS
NOTIFICATION MANAGER
MODELS REPOSITORIES
ENVIRONNEMENT
EXTERNE
CLIENT
BACKEND
LOCALISATION
CONNECTIVITÉ
PUSH-NOTIFICATIONS
NSNOTIFICATIONCENTER
APIS
CONSTANTS
FILES
AUTRES
XCASSETS
26

27. SETTINGS
LIAISON ENTRE LES PLISTS DE SETTINGS ET LA COUCHE UI - UIMANAGERS
▸ La liaison entre les plists de settings et la couche UI est assuré par les UI-
managers.
▸ Les UI-managers sont des singletons qui se chargent au démarrage de
l’application (chargent et encapsule les propriétés sous format de dictionnaire).
▸ À chaque composant UI on associe un ui-manager qui lui alimente par les
propriétés nécessaires.
▸ On accède aux propriétés des composants à travers les Accessibility.
27

28. SETTINGS
AUTOMATISATION DE LA MISE EN FORME
Règles:
Tous les composants UI doivent hériter des customs-UI.
Au niveau de chaque custom-UI est implémentée le processus
d’automatisation.
Le type de fichier plist identifie le type de composant : bouton, label,
textfield,…
L’accessibility précise l’emplacement et le rôle du composant.
28

29. SETTINGS
AUTOMATISATION DE LA MISE EN FORME - LABEL
1. Le label, ajouté par code ou par xib, doit hérité de la classe
CustomLabel et non de la classe UILabel.
29

30. SETTINGS
AUTOMATISATION DE LA MISE EN FORME - LABEL
2. On associe une Accessibility à ce label.
3. On ajoute un dictionnaire avec le key « equipment.societe.label » dans le
fichier labelsettings.plist sans donner les valeurs correctes des attributs et on
continue la préparation de l’UI.
30

31. SETTINGS
AUTOMATISATION DE LA MISE EN FORME - LABEL
3. On ajoute un dictionnaire avec le key « equipment.societe.label » dans le
fichier labelsettings.plist sans se focaliser sur les valeurs correctes des
attributs et on continue la préparation des layouts.
SÉPARATION ENTRE UI ET
« MISE EN FORME » DES UIS
CONCENTRATION UNIQUE SUR LA
PRÉPARATION DES LAYOUTS (DISPOSITION
DES COMPOSANTS)
4. La « mise en forme » : après la préparation des layouts, les fichiers plists
pourront être donnés à une partie tierce pour mettre les valeurs correctes
des attributs.
AVANCEMENT PARALLÈLE DE
DÉVELOPPEMENT
5. Le développeur n’a qu’à intégrer les changements dans son fichier plist.
GESTION DES THÈMES SIMPLE
ET FACILE
31
AUCUN PARAMÉTRAGE N’EST FAIT À
TRAVERS LES FICHIERS XIB OU LES
UIVIEWCONTROLLERS.

32. SETTINGS
AUTOMATISATION DE LA MISE EN FORME - BUTTON
32
Attribution de l’Accessibility Label
Ajout des paramètres dans le fichier plist correspondant
Ajout des « keys » dans les fichiers langues
Les attributs button.text, label.text, textview.text, placeholder.text
correspondent au « key » qui va être utilisé par le LanguageManager pour
retrouver la valeur correspondante dans la langue correspondante
Chargement automatique des propriétés
1
2
3
4

33. SETTINGS
FONCTIONNEMENT D’UN CUSTOM-UI : CUSTOMLABEL
1
CHARGEMENT AUTOMATIQUE DES
PROPRIÉTÉS
EXTRACTION DE L’ACCESSIBILITY
33

34. SETTINGS
FONCTIONNEMENT D’UN CUSTOM-UI : CUSTOMLABEL
2
COMMUNICATION AVEC
« LABELMANAGER » POUR EXTRAIRE
LES PROPRIÉTÉS
chargement des apparences
depuis un fichier html local
chargement des apparences
depuis une string html
Mise en forme attribut par
attribut
34

35. SETTINGS
FONCTIONNEMENT D’UN CUSTOM-UI : CUSTOMLABEL
3
extraction du texte (dans la
langue courant de
l’application)
chargement de la font et la
taille de texte
chargement de la couleur de
texte
35

36. SETTINGS
FONCTIONNEMENT D’UN UI-MANAGER : LABELMANAGER
36
chargement des propriétés
depuis le plist de settings
(singleton)
les propriétés sont de format
dictionnaire

37. SETTINGS
FONCTIONNEMENT D’UN UI-MANAGER : LABELMANAGER
37
extraction du texte (dans la
langue courant de
l’application)
chargement des apparences
depuis un fichier html local
chargement des apparences
depuis une string html

38. UI
VIEWS
▸ Les views sont décomposés par type : uiview,
uilabel, uibutton,…
▸ Les views doivent hériter obligatoirement des
UICustomers du package api-internals.
▸ Les composants UI communiquent avec les UI-
viewcontrollers à travers les protocols (delegate).
▸ xib sous format d’objet (division top/center/
header)
▸ composants générique :datasource/delegate
▸ déclaration tableview/collection dans des
classes séparés pour garder controller lisible

39. UI
VIEWCONTROLLER
▸ Les viewControllers sont décomposés par écran.
▸ Les viewControllers doivent hériter obligatoirement de CustomViewController de
package api-internals.
▸ CustomViewController encapsule et centralise les traitements en commun :
méthodes gérant la navigation pop/push/dismiss, affichage des alertes, envoi des
mails, affichage des loaders, mise en forme de UINavigationController, mise en
forme de l’UIViewController, …

40. SERVICES
UI LAYER
(OBSERVER)
BACKEND
Front-end mobile
refresh data
RESTFUL PROVIDER
Facade
RESTFUL MANAGER
SERVICES LAYER
PREPARE
REQUESTS
(FACTORY)
RESTFUL SERVICE 1
RESTFUL SERVICE 2
RESTFUL SERVICE 3
REPOSITORIES
MANAGE
REQUESTS
(STACK)
UPDATE LOCAL
REPOSITORIES
Notify UI
NOTIFY UI
(PROVIDER)
Mediator
PREPARE
REQUESTS
RESTFUL LAYER
reload data
fetch data
DAO & ORM
READERS WRITERS
40

41. UI
API