Modelli di progettazione per la navigazione tra le pagine su piattaforme mobili

6

Vorrei chiederti il modo migliore di gestire la navigazione tra pagine / attività su piattaforme mobili. Per essere più specifici: sulla gestione dello stato in app più complesse, sulla gestione delle azioni "Indietro", ecc ...

All'inizio vale la pena menzionare che sto cercando una soluzione che si adatti all'approccio MVVM (Windows Phone).

Ovviamente la prima pagina di Google mi dà alcune risposte ma nel 99% degli esempi abbiamo casi semplici come (C # mescolato con pseudocodice):

public class ExampleViewModel : INavigationViewModel
{
     public void Activate()
     {
           //load somehow saved state if it exists

           if(savedState != null) { //assign previously saved state to current VM }
     }

     public void Deactivate()
     {
           //save view model state and it will be ok
     }
}

Quindi sembra abbastanza chiaro, giusto? Interfaccia INavigationViewModel ha definito due metodi di base che simulano lo spostamento in avanti e indietro. Durante la modifica delle pagine vengono eseguiti i metodi, quindi potremmo pensare che tutto funzioni correttamente.

Ora diamo un'occhiata a una situazione più realistica:

public class ExampleViewModel : INavigationViewModel
{
     public void Activate(Dictionary<key,value> someParams)
     {
           //Activation, but from which case?
           // 1. From previous page? Ok, we have someParams != null.
           // 2. From 'back' button? Not good, someParams == null.
           // 3. From hidden state? Not good...

           // I think you get the point, right?
     }

     public void Deactivate()
     {
           //Deactivation types might be like:
           // 1. Going to another page
           // 2. Quick move forward and backward (yes, different than 1.)
           // 3. Closing app from this moment (what about filled data?)
           // 4. Full page activities (for eg. full screen datepicker)
           // Maybe some other deactivation cases?
     }
}

Alcuni sviluppatori (come me ora) utilizzano classi statiche - 'DataContainer' per gestire lo stato della pagina. Ok, va bene, ma abbiamo situazioni in cui sotto la stessa chiave ci sono valori indesiderati o diversi.

Non è tutto - con molti "casi di attivazione" abbiamo bisogno di scrivere molte dichiarazioni condizionali. Nelle app più complesse è quasi impossibile gestire tutte le varianti di avvio di ViewModel.

Nel mondo della programmazione abbiamo molti schemi di progettazione. Non posso credere che siano così poche le idee (o forse la mia ricerca non è stata abbastanza buona) per questo problema: la navigazione nelle app mobili senza scrivere metodi con centinaia di casi.

Sarebbe bello vedere qualcosa come il modello di strategia con casi incapsulati, basato su interfacce con metodi di attivazione veramente puliti, ecc ... è possibile?

    
posta psmyrdek 05.05.2015 - 21:27
fonte

1 risposta

1

Includere le informazioni di stato indispensabili come parametri url / cookie-as-last-resort (presumendo che in alcuni casi si perda la porzione di query querystring in alcuni casi). Proprio come potresti avere una parte di url del controller / azione per la tua configurazione MVC / VM, puoi includere id  Ad esempio link

In questo modo è ancora possibile continuare da dove è necessario relativamente facilmente e richiedere eventuali parametri rimanenti dall'utente o dal database.

    
risposta data 18.08.2015 - 16:11
fonte

Leggi altre domande sui tag