android10 / android10/Android-CleanArchitecture
Best way to keep user input data until persisted?
- Dominant language
- Java
- Stars
- 15.5k
- Forks
- 3.3k
- PR merge metrics
- No merged PRs in 30d
Description
All examples of Clean architecture that I could find either display an already available content (e.g. from an API call) or when there is a content creation example - it is a simple note with title and content. What about more complex examples?
Imagine the user has to create some complex entity - e.g. an event. The event can have multiple attendees, location, weather forecast, description etc. The event creation presenter takes care of asking the domain and data layers for locations, weather info from some API, list of users who can be added as an attendee and so on. All this is clear but I have the following question:
What is the best place to store all this information before the user hits "Save"? To make things simpler let's take the Weather model - the app get's the weather info from an API and the presenter and the view display that info. Where should we keep the Weather model before persisting it together with the event and all the other details? I don't think it is right to keep a WeatherModel member variable in the View and pass that variable together with the list of AttendeeModel and all other info to the presenter and down to the data layer when the user "saves" the event. On the other hand all this information must be persisted if the framework calls `onSaveInstanceState()` and later restored.
Thinking about it - the case is quite similar to [UserDetailsActivity](https://github.com/android10/Android-CleanArchitecture/blob/master/presentation/src/main/java/com/fernandocejas/android10/sample/presentation/view/activity/UserDetailsActivity.java) but instead of keeping only the `int userId` we must keep more complex data objects. Maybe keeping (until persisting) the info in the View is the right approach, I'm just not sure if that is the best one.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.