Autre à singleton dans Android

Question

Travailler en architecture logicielle de nombreuses années je déteste utiliser singletons dans les cas où je pourrais les éviter. Mais ayant à faire une tâche pour l'application Android, je rencontre le cas où le singleton semble être la seule alternative. Peut-être que quelqu'un pourrait proposer autre chose?

La tâche est de faire un assistant d'interface utilisateur pour créer une nouvelle entité (description de voyage dans mon cas). L'entité est complexe et nécessite plusieurs pages pour remplir toutes ses données.

Assistant est organisé comme plusieurs fragments Poussé à l'arrière d'une pile après un que les utilisateurs vont à la page suivante. Mais tous les fragments doivent fonctionner avec une instance d'édition. Et cette entité devrait rester en vie lorsque l'activité est recréée (après rotation ou dans d'autres cas). Si la page était seulement une, je pourrais simplement enregistrer/restaurer l'entité dans onSaveInstanceState. Mais si je le ferai dans tous les fragments de mon sorcier, tous les fragments contiendront leurs propres instances d'entité (parce que tous le sauveront et ensuite restaureront). Et l'assistant fonctionnera mal (par exemple lorsque vous revenez aux pages précédentes).

Pour plus de douleur, disons que l'activité qui détient ces fragments ne devrait pas savoir quoi que ce soit à propos de cet assistant spécifique et je ne mettrai pas un code spécifique à cet assistant à l'activité. L'activité désactivante n'est également pas une option dans mon cas.

Ainsi, dans cette situation, la solution évidente est de créer le singleton qui détient mon entité d'édition. Et fait tous les fragments de sorcier fonctionne avec ce singleton. 90% de mes programmeurs choisiront cette solution sans aucun doute. Mais mon cerveau proteste contre cela. Pourquoi je devrais faire l'entité singleton quand ce n'est pas un singleton par sa nature ???

Donc, si quelqu'un pourrait suggérer quelque chose de différent, je serais très apprécié.

Answer 1

Supposons que vous avez ci-dessous:

• classe d'application;
• WizardManager;
• SomeWizardDataEntity;

Vous pouvez créer WizardManager dans la classe d'application et l'utiliser avec l'entité de données pour votre flux de l'assistant, à savoir:

//BaseFragment: 
WizardManager manager = getApplication().getWizardManager(); 
SomeWizardDataEntity entity = manager.getWizardEntity(); 

//Fragment1: 
entity.addSomeData(); 

//Fragment2: 
entity.addSomeData2(); 

//Fragment3: 
entity.addSomeData3(); 

//Fragment4: 
entity.addSomeData4(); 
manager.wizardFlowFinihed(); 

Ainsi, vous aurez par exemple non-singleton de WizardManager qui vivra jusqu'à la classe d'application est vivant.

Ensuite, vous pouvez écrire quelques tests moqueur cette entité, i.e. .:

@Mock 
WizardManager mWizardManager; 

//start some fragment 

verify(entity, times(1)).addSomeData(); 
verify(manager, times(1)).wizardFlowFinihed();