MVP Android – Où enregistrer l'état de la vue?

J'ai quelques doutes concernant l'enregistrement d'état en utilisant MVP sur Android. J'ai défini mes fragments / activités en tant que vues puis j'ai mis en place les présentateurs correspondants.

Mon exemple est simple:

J'ai une activité avec des cases à cocher et des filtres. Si l'activité est détruite par le système Android, puis recréée, où devrais-je sauvegarder ces filtres et les cases à cocher? Sur la vue? Sur le présentateur?

Si sur la vue, dois-je avoir la logique de restauration sur la vue ou sur le présentateur?

Je vous remercie!

  • Android MVP, où vérifier la connexion Internet
  • Android MVP: Qu'est-ce qu'un Interactor?
  • Adapteur en tant que présentateur? Ou parler avec un présentateur? Android et MVP
  • MVP, la vision du présentateur est-elle nulle sur la destruction?
  • Android MVP avec Dagger 2 - Activité avec plusieurs fragments
  • Vérification Internet, où placer lors de l'utilisation de MVP, RX et Retrofit
  • Où le service Android doit-il appeler et appeler à GoogleAPIClient s'il-vous-plaît en utilisant le modèle MVP dans Android?
  • Exemples de présentateur / contrôleur de vue modèle modèle Android
  • 4 Solutions collect form web for “MVP Android – Où enregistrer l'état de la vue?”

    Dans le cas du MVP, le modèle est chargé de garder l'état de la vue.

    Par exemple, dans votre modèle, vous avez une entité Post avec une série de catégories . À votre avis, vous disposez d'une case à cocher pour chaque catégorie et, dans chaque action vérifiée / non vérifiée, vous ajoutez / supprimez des objets du tableau de catégories de messages.

    Une fois que l'activité est restaurée, la vue doit demander le groupe de catégories de messages afin de déterminer quelles sont sélectionnées et celles qui ne le sont pas, afin de pouvoir définir l'attribut correct vérifié / non vérifié.

    Voici une très bonne publication à ce sujet: http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/

    Le présentateur est une interface entre le modèle et la vue et ne devrait pas prendre en charge la sauvegarde d'un état quelconque. Il est plus logique de laisser soit l'état du modèle soit l'état de la vue:

    1. Maquette. Le présentateur est responsable du remplissage des données View with Model pendant l'initialisation de l'activité et engage toutes les interactions View au modèle immédiatement. Le modèle est toujours mis à jour, donc les changements de configuration ne sont pas pertinents.
    2. Vue. Le présentateur est responsable du remplissage des données View with Model lors de l'initialisation, mais la vue enregistre et restaure son propre état dans les modifications de configuration. Cela a du sens dans une situation de création / édition où un bouton 'Enregistrer' existe et vous avez un modèle transitoire (ou modèle de travail).

    Cette dernière approche est logique lorsqu'un bouton 'Enregistrer' existe. Le présentateur n'est pas impliqué dans les deux sens.

    1. Enregistrer et restaurer Afficher l'état dans la vue (Activité / Fragment).

    Je préfère économiser et restaurer l'état de la vue dans View-alone (Activity / Fragment)

    Par conséquent, il est de la responsabilité de sauvegarder son état (donc adhérer au principe de responsabilité unique).

    Exemple

    /** * On Save Instance State. * * @param outState Out State. */ @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); outState.putString(STATE_KEY_USERNAME, getUserNameFieldValue()); outState.putString(STATE_KEY_PASSWORD, getPasswordFieldValue()); outState.putBoolean(STATE_KEY_REMEMBER_ME, getRememberMeFieldValue()); } /** * On Restore Instance State. * * @param savedInstanceState Saved Instance State. */ @Override protected void onRestoreInstanceState(Bundle savedInstanceState) { super.onRestoreInstanceState(savedInstanceState); if (savedInstanceState != null) { String userName = savedInstanceState.getString(STATE_KEY_USERNAME, ""); String password = savedInstanceState.getString(STATE_KEY_PASSWORD, ""); boolean rememberMe = savedInstanceState.getBoolean(STATE_KEY_REMEMBER_ME, false); userNameEditText.setText(userName); passwordEditText.setText(password); rememberMeCheckBox.setChecked(rememberMe); } } 

    2. Enregistrer et restaurer l'état du présentateur dans le présentateur

    Si vous devez enregistrer n'importe quel état du présentateur, faites-le dans le présentateur.

    Mon présentateur de base aura l'air de

      /** * On Create View. * <p> * 1. Gets called from view's onCreate method. * * @param view View. * @param savedInstanceState Saved Instance State. */ void onCreateView(final View view, final Bundle savedInstanceState); /** * On Attach View. * <p> * 1. Gets called from view's onStart method. */ void onAttachView(); /** * On Detach View. * <p> * 1. Gets called from view's onStop method. */ void onDetachView(); /** * On Save State. * <p> * 1. Gets called before view is destroyed to save the state of the presenter. * * @param outState Bundle in which to place your saved state. */ void onSaveState(final Bundle outState); /** * On Destroy View. * <p> * 1. Gets called from view's onDestroy method. */ void onDestroyView(); 

    Peut-être que cela aide: https://github.com/Yarikx/reductor . C'est un conteneur d'état prévisible inspiré de Redux de JavaScript.

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.