Ajouter plus de responsabilités aux activités de manière flexible

Question

Je considère comment je peux ajouter des tâches aux activités Android de manière flexible. Je ne peux utiliser que l'héritage de l'implémentation pour une chose en Java et je voudrais l'utiliser, si je l'utilise du tout, pour autre chose.

Je pense que j'ai besoin de dessiner le domaine Tout d'abord:

Activités Les fenêtres d'interface utilisateur sont-elles essentiellement, avec des responsabilités de cycle de vie intrinsèques appliquées par l'API. La Tâches Je parle de popovers UI-visible qui font des trucs hors ligne puis disparaissent. Ils proviennent d'asynctases. Le code de tout cela n'est pas un problème, j'ai déjà cela, même assez généralisé avec des interfaces. Je regarde d'autres améliorations de conception que je peux apporter.

Il existe de nombreux types d'activités et ils pourraient tous travailler avec certains types de tâches. Par exemple Une fenêtre de recherche aurait une tâche qui ajoute l'un des résultats de recherche, disons que c'est un livre, à la collection de livres dans l'application principale. Il vous permet d'ajouter plusieurs, d'où le popover. Une fenêtre qui affiche la collection a une tâche qui vous permet d'exporter un livre vers un format de fichier externe. Cela ne vous empêchera pas de parcourir votre collection, mais il doit afficher une barre de progression car cela peut prendre un certain temps à exporter.

Une tâche spécifique existant comme une classe imbriquée dans une activité spécifique. Il doit être sauvé et restauré avec les événements de cycle de vie: il y a un onSaveInstanceState(Bundle) et onRestoreInstanceState(Bundle) pour cela, entre autres. L'activité a une liste de tâches actives (ou simplement un membre pour une tâche). Un événement d'interface utilisateur créera une nouvelle tâche et l'ajoutera à la liste, à la onClick(): ATask task = new ATask(); task.execute(something);.

Voici ce que j'ai considéré jusqu'à présent:

• Héritage de la mise en œuvre

  Déplacez simplement cette entreprise de tâche vers une super classe abstraite de toutes les activités spécifiques.

• Motif de décorateur

  Créez un dastedActivityDecorator qui ajouterait cette responsabilité sur toute activité. Le décorateur devrait imiter l'interface d'activité entière telle que fournie par l'API, cependant principalement des passthroughs. Donc, cela peut déjà être un peu trop lourd. Il faudrait également ajouter les événements / boutons d'interface utilisateur qui lancent la tâche, ce qui peut ne pas toujours être possible si l'action est plus consécutive.

  Mais le plus gros problème que je pourrais trouver ici est qu'Android utilise un manifeste Pour associer vaguement toutes les activités ensemble. Là-bas, vous devez déclarer chaque activité spécifique ou elle ne peut pas être utilisée. C'est un problème car le décorateur fonctionnerait au moment de l'exécution, avec la composition. Je ne peux pas déclarer le décorateur et ajouter les informations dont elle a besoin pour envelopper une activité spécifique.

  Avec Android Je semble me retrouver avec l'héritage de la mise en œuvre beaucoup plus que je ne le souhaite. Par conséquent, j'ai trop de couplage ou de duplication de code. Les activités se développent toujours facilement vers de grandes classes de graisses. Ai-je raison de dire que cela est en partie à cause des choix de conception existants dans le cadre Android, tels que les solutions de composition enlectriques manifestes, ou l'objet de contexte? Ai-je raison de dire que dès le départ, il coupe une quantité importante de modèles de conception établis dans les zones clés, y compris le modèle MVC.

• Décorateur avec emballages:

  Le fait que je ne puisse pas spécifier le décorateur et l'activité spécifique à laquelle elle s'applique dans le manifeste ne signifie pas que je ne peux pas créer de classes qui représentent et organisent cette composition. Je pourrais bien sûr créer de nombreuses classes spécifiques aucoratorActivité, qui implémentent également l'interface d'activité et agir comme le décorateur, puis envelopper l'activité spécifique réelle. Je ne sais pas si cela résout mon problème. Cela semble être beaucoup de travail, beaucoup de classes de déchets et m'éloigne de mon objectif d'origine.

• Modèle de stratégie:

  Si je ne peux pas écorcher l'activité, je ferais mieux d'externaliser une partie de ses tripes. Cela me donnera encore plus de connexions, car les activités devront connaître la stratégie. La stratégie elle-même sera cependant plus légère en tant que décorateur. Pourtant, cela ne ressemble pas tellement à la stratégie où il y a un choix dont on, mais plutôt de déplacer une partie de la classe vers une autre classe. Je l'appellerais TaskManager. Et devrais-je encore tirer les connaissances des stratégies dans une super classe d'activité?

• Un autre modèle?:

Quel modèle est le meilleur choix? Ne évitez pas votre opinion sur le cas Android spécifique. Pas besoin de parler spécifiquement des tâches.