Réaliser une librairie en Android

Bonjour à tous,

Comme vous l'aurez peut-être vu dans mon précédent topic, je suis en train de voir comment je peux réaliser une sorte de réseau social réutilisable, avec des modules, sur Android (donc en Java).

J'aimerais réaliser pour cela une librairie avec des modules (un module de timeline par exemple, un autre de messagerie, etc), que l'on peut assembler / désassembler à sa guise. On aurait donc le droit d'implémenter ou non les modules de son choix. Et même les modules seraient personnalisables (une personne peut par exemple vouloir une fonctionnalité de "like" sur son réseau, alors qu'une autre ne voudrait pas).

Vaste projet, j'en conviens !

Le principal problème que je rencontre pour le moment est que je ne sais pas trop comment réaliser une librairie, et à coté de cela, un projet de test qui implémente cette librarie.

Concrètement, est-ce que ça vous semble possible de pouvoir réaliser une librairie avec des activités, des fragments, etc; éventuellement overridable dans l'app de test, pour personnaliser certains traitements ? Car il y aura une base commune à toutes les implémentations de la librairie, j'ai donc besoin, d'activités, de fragments…

En fait, j'aimerais faire quelque chose de fort personnalisable mais avec une base assez grande pour avoir à coder le moins possible pour avoir un réseau social utilisable presque "from scratch" avec ma librairie. Je ne sais pas du tout si j'arrive à être clair, j'espère que oui.

Je vous remercie par avance pour votre aide.

Bonjour Ikikn,

Je n'ai pas lu ton précédent sujet mais de ce que j'en comprends avec celui-ci, tu veux pouvoir développer plusieurs réseaux sociaux grâce à des modules que tu assembles à ta guise pour constituer tes différents réseaux sociaux. Bien que le "pourquoi" m'échappe un peu, je suppose que tu as tes raisons. Par contre, je pense que tu as une mauvaise approche.

D'après ce que je comprends, tu penses vouloir intégrer dans tes librairies des vues, des fragments ou des activités qui correspondent à certaines fonctionnalités de tes modules. Alors, d'un point de vue uniquement interface, sache qu'il est difficile de "surcharger" une interface graphique d'un fragment ou d'une activité, voire quasiment impossible. Et même si c'était possible, cela serait hautement déconseillé. Normalement, une librairie ne se charge pas de l'interface. Limite, pour certains cas, tu peux concevoir des vues génériques mais je pense que tu dois t'arrêter là.

Par exemple, je suis en train de développer un SDK Android pour Zeste de Savoir et l'unique vue dont je dispose dans ce SDK (que tu peux voir comme une grosse librairie), c'est un bouton pour le "ZdS Connect". Tout le reste, ce n'est que l'"intelligence" du SDK.

Pour conclure sur l'aspect graphique, je ne peux que te conseiller de te limiter à l'"intelligence" de tes différents modules et de ne pas te soucier de l'aspect graphique. Laisse cette partie aux applications clients qui vont utiliser tes modules.

Maintenant d'un point de vue code, c'est un peu difficile de t'aider. Oui, tu peux créer un module par "grosse" fonctionnalité et y placer toutes les sous fonctionnalités dans chacun des modules. C'est quelque chose qui peut se faire. Je ne sais pas si tu connais un peu Maven ou Gradle mais tu peux créer un projet avec des sous modules pour y placer tes différentes "grosses" fonctionnalités. Après, dans une application cliente, ils se chargeront de récupérer le module A et le module C et pas le module B.

Pour finir, en ce qui concerne les tests, cela fait bien longtemps qu'il est possible d'inclure les tests directement dans tes projets pour ne pas devoir te trimballer un projet annexe avec une forte dépendance vers ton projet (ici ta librairie).

J'espère avoir été aussi clair que toi au moins parce que tu t'engages sur quelque chose qui va te demander énormément de boulot. Limite, c'est le travail d'une équipe entière pendant quelques mois pour un travail bien fait.

Avant toute chose, merci pour ta réponse.

Effectivement, c'est un travail gargantuesque, mais c'est ce qui m'est demandé pour mon stage en entreprise, et même si je me vois mal avoir le temps de finir le tout, proposer une base solide serait déjà idéal.

Effectivement, j'ai réfléchi, et je me rends compte que proposer des vues directement dans le SDK est tout sauf une bonne idée. J'ai en fait du mal à bien séparer ce qui doit se trouver dans le SDK, et ce qui doit se trouver dans l'application de test.

Prenons un exemple simple : un fragment contenant simplement une recyclerView qui elle contient des cardview dont chacune contient un post. On retrouve déjà pas mal de notions, notamment :

• La notion de "Post", pour moi, ce qu'est un Post peut être défini dans le SDK (avec possibilité éventuelle d'overrider cette classe Post dans l'app de test pour ajouter des champs ? Peut-être)
• La vue (donc le layout de l'affichage d'un post, le layout contenant la recyclerView, …), j'imagine que tout ça ne peut être QUE dans l'app de test
• l'adapter qui permet de gérer la RecyclerView. Comme je vois les choses, il disposerait d'une méthode permettant de setter la list de Posts, et se trouverait dans le SDK. Seulement voila, je ne sais pas trop commenter gérer tout ce qui concenre RecyclerView.ViewHolder, étant donné que la vue ne se trouvera pas dans le SDK. Mais ça m'ennuie de ne pas pouvoir conserver l'adapter dans le SDK car la plupart du traitement qu'il aura à faire sera inchangé quel que soit le réseau social utilisé, tu vois où je veux en venir ?

Est-ce que tu vois une façon simple de séparer ce qui peut se trouver dans le SDK, et ce qui doit être dans l'app de test ? J'ai vraiment beaucoup de mal à faire cette séparation. Notamment pour le problème concret de l'adapter dont je parle, j'espère qu'il existe une solution "propre" pour le conserver dans le SDK mais rien n'est moins sur, donc toute suggestion / avis m'intéresse très fortement !

Merci beaucoup !

Ravi de voir que tu sembles avoir compris ce que j'ai expliqué. Je n'étais pas bien sûr d'avoir été clair.

• La notion de "Post", pour moi, ce qu'est un Post peut être défini dans le SDK (avec possibilité éventuelle d'overrider cette classe Post dans l'app de test pour ajouter des champs ? Peut-être)

Tout à fait. Une classe Post doit figurer dans ton SDK. Par contre, je ne suis pas certain de la pertinence de l'overrider. Qui dit surcharge de cette classe, dit modification de toutes les classes qui l'utilise comme son DAO (accès à la ressource Post par la base de données) ou, ce que j'appelle moi, des actions (accès à la ressource Post par des web services). Je pense qu'il vaut mieux prévoir un Post le plus générique possible. Je suppose qu'ils ne seront pas bien différents entre les réseaux sociaux. Il n'y a qu'à voir les réseaux sociaux actuels, tout est assez semblable finalement.

• La vue (donc le layout de l'affichage d'un post, le layout contenant la recyclerView, …), j'imagine que tout ça ne peut être QUE dans l'app de test

Exactement. Ici nous sommes uniquement dans de l'interface graphique. Chose qui ne doit pas figurer dans ton SDK.

• l'adapter qui permet de gérer la RecyclerView. Comme je vois les choses, il disposerait d'une méthode permettant de setter la list de Posts, et se trouverait dans le SDK. Seulement voila, je ne sais pas trop commenter gérer tout ce qui concenre RecyclerView.ViewHolder, étant donné que la vue ne se trouvera pas dans le SDK. Mais ça m'ennuie de ne pas pouvoir conserver l'adapter dans le SDK car la plupart du traitement qu'il aura à faire sera inchangé quel que soit le réseau social utilisé, tu vois où je veux en venir ?

Là c'est un peu entre les deux et tu as deux choix :

• Soit tu parviens à concevoir des adapteurs assez génériques pour qu'ils soient réutilisables entre les applications et donc les mettre dans le SDK. Les types génériques seront probablement tes amis.
• Soit tu te rends compte que ce n'est pas possible et il faudra les mettre dans les applications clientes.

A noter quand même qu'une des grandes problématiques du développement Android est son importante répétition de code. C'est un fait que tu pourras difficilement totalement effacer. C'est le combat quotidien de tous les développeurs Android.