Override onSaveInstanceState / onRestoreInstanceState • Must serialize all fields required to restore state • Presenter (scoped Singleton instance) • Easy, but can lead to Presenter performing duties beyond its original purpose • Database or other long-term storage • Great for some cases (messaging app?), but may be overly complex for transient data that doesn’t need to be persisted beyond the session.
Presenter class for each view isn’t an issue—but dealing with the interaction between them can be bothersome • Null check on view every time Presenter wants to call a view method • Remembering to detach Presenter* • Separating “first attach” logic from subsequent attaches* *If using “scoped Singleton” Presenters
efficiency, several methods are exposed on the view to allow Presenter to update independently. • Each call to one of these methods involves a null check* • Presenter cluttered • View cluttered
logic isn’t perfect (must assume view receives call) • Above point not as important if view attached logic is sound, but… • Where do we store the state of each independent piece of the view? • Multiple fields in presenter? • Disassembled from some other larger object?
tells it what to display • View actions should be delegated to a class (Presenter still fits) • Methods to update view should not have to be defined or exposed
relevant Observables and unsubscribes when necessary • View Model can be updated at any time, even if view isn’t ready! • Presenter doesn’t have to know about the view • View doesn’t have to expose any methods to allow other classes to update it • View Model can be unit tested • Any manipulation of data into what the view needs is encapsulated in the View Model
have a strict implementation—can go a few different routes • View Model could talk directly with Repository in some cases • This could mean the Presenter never has to know about the view or View Model • Depending on view complexity—expose Observables for each widget/ property (title, message, background color, etc.) • Very simple cases could even have the Presenter act as the View Model
framework • Exposes Subjects/Relays as Observables • Exposed Observables may be behind Interface to obfuscate other methods required to update the View Model from the view
— do what makes sense for you • Main takeaways of an ideal implementation • All view state is kept in BehaviorSubjects/Relays • All interactions are one-way—no other class cares about the view