Concevoir un projet android compatible J2ObjC

Catégorie: Mobile (Mis à jour le 07-07-2015 19:17:04)

Dans la série sur J2ObjC, nous avons vu ce qu'était ce convertisseur Android vers iOS, et comment convertir notre premier fichier java.

Autres articles de la série J2ObjC

Maintenant je vous propose d'étudier une architecture qui permettra d'extraire le code convertissable du code qui ne l'est pas.

A la fin de ce billet, vous aurez une idée claire sur comment organiser le code de votre prochaine application Android/iOS.

Pourquoi séparer?

Une application classique est souvent composée de 3 parties: la vue, le modèle et le contrôleur.

La vue est propre à chaque plateforme et devra donc être recrée.

Par contre le contrôleur (votre logique métier) et le modèle (le stockage) peuvent en grande partie être récupérés.

Le but est d'avoir un module dans notre project que l'on peux convertir grâce au script suivant:

Une proposition d'architecture

Ce que je décrit ici est un choix personnel. Libre à vous d'adopter une architecture différente ou d'en proposer de nouvelles dans les commentaires!

Tout d'abord, tout le code a convertir sera placé dans un module à part. On utilisera un autre module pour le code de notre vue. De plus, tout le code propre a Android ou IOS sera placé dans des classes préfixées par le nom de la plateforme (par exemple: AndroidSQLiteDriver et IOSSQLiteDriver).

Côté modèle

Le mode de stockage entre Android et iOS sont proches (SQLite pour le premier, SQLite ou CoreData pour le second) mais les appels entre les deux plateformes sont différents : pour Android on dispose d'un helper tout fait, pour iOS il faut faire avec la librairie C de SQLite à la main.

Le code du modèle doit donc être abstrait de manière à ce que les appels bas niveaux vers le stockage soient clairement abstraits et faciles à implémenter pour les deux plateformes.

Personnellement, j'utilise le repository pattern, couplé à un driver de base de donnée. Ce driver contient les 5 méthodes CRUD de base et est ensuite décliné en deux implémentations (SQLite pour Android et CoreData pour iOS).

Je fournirais le code du driver dans un article ultérieur.

Côté business logic

Coté contrôleur, le code doit être totalement découplé de la vue. On oublie donc le code contrôleur placé directement dans le listener des boutons.

Pour cette couche, j'ai choisi d'adopter le service pattern: le code qui fait quelque chose est alors encapsulé dans des classes autonomes (principes SOLID) que l'on n'a pas a réécrire.

Cas général

Pour tous les autres cas que je n'ai pas traité ici, la procédure est toujours la même.

Premièrement on identifie les portions de code qui ne convertissent pas.

Ensuite on abstrait ce code dans une classe autonome derrière une interface.

Enfin on réécrit une version spéciale pour iOS et on charge l'une ou l'autre version suivant la plateforme.

Resultat

Avec cette organisation, les services dépendent uniquement des repositories, et les repositories dépendent uniquement d'une interface de driver.

Le code propre à la plateforme du driver est simple à réécrire et la vue n'a plus qu'à appeler les services suivant les actions demandées.

Cette architecture me semble un bon compromis entre la simplicité et la maintenabilité sur le long terme.

Dans un prochain article je fournirai des extraits de code pour montrer comment mettre en place cette architecture (pas de théorie, juste de la pratique et des lignes de code!)

A lire aussi:

J2ObjC, le convertisseur Android vers iOS: présentation

[Mobile] Les plateformes Android et iOS sont les deux grands du marché mobile, et proposer une application sur ces deux plateformes est un avantage économique intéréssant. Je vous présente ici J2ObjC, un convertisseur qui permet de porter du code Java vers iOS.
Suite...

Convertir votre premier fichier java vers ObjectiveC via J2ObjC

[Mobile] Pour faire suite a ma présentation sur J2ObjC, voici un article sur comment effectuer votre premiére conversion d'un fichier Java vers Objective C
Suite...