Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation about inter-view-model communication #10

Closed
Blackhex opened this issue Sep 14, 2015 · 4 comments
Closed

Documentation about inter-view-model communication #10

Blackhex opened this issue Sep 14, 2015 · 4 comments

Comments

@Blackhex
Copy link

Hello.

Could you please describe on the wiki what is the preferred way to communicate between view-models for this library? Especially the important part is how to abstract communication with view-model lifecycle, e.g. how pass data and messages to view-models that have not been instantiated yet?

A straighforward solution is to store data that needs to be passed from one view-model to another to shared preferences or SQLite database that are then loaded when the target view-model is instantiated and send events via broadcasts but I don't see this as a nice and clean solution.

Another option is to use observable pattern managed in static Application context but there is no option to keep observable object state when application object is terminated.

Thank you for the library anyway!

@ninadmg
Copy link

ninadmg commented Sep 22, 2015

I think the view-Models should communicate through their corresponding views.

@DanielNovak
Copy link

This dependes on the use-case. Each screen instance has it's ViewModel instance (if you open the same activity 3 times, each one will get it's unique ViewModel instance). So it's not possible to send data to viewmodels for screens that are not created yet.

Other cases should be handled with the standard android way - you can open a new Activity from the View (Activity/Fragment) and forward the data with a Bundle object (Intent extras/Fragment arguments). This Bundle is directly accessible in AbstractViewModel.onCreate(). There is no need to persist the data in database.

If you have multiple activities open and you would like to send an event from one ViewModel to others, then you could use Otto or a simple Broadcast. ViewModels can listen to these events directly and handle them.

@Blackhex
Copy link
Author

Thank you for the response. Otto seem as a good alternative to not very readable Broadcasts. Do you know if Otto can send old messages (that was sent prior to registration) when the new and the only listener is just registered?

Add Bundles: They can be used when you want to communicate from the one view-model and the other that was created by the first one. But it does not solve the case when you want to communicate between two view-models that was created by the third one in case that one of the first two does not exists yet.

Possible solution would be that all the view-model instances would have some kind of instance identifier (a tag) and such a view-model would be singleton (in respect of its tag, not its class). There would also have to be an accessor method what would return or create view-model instance identified by the tag even if its fragment or activity does not exists yet. This would require modification to the android-view-model library so that view-models instances would be created by the library user in some kind of factory class or method.

PS: You mentioned that you would create a new Activity/Fragment from another Activity/Fragment. Isn't that breakage of the view-model-(controller) concept? Shouldn't the navigation logic (startActivity, etc.) be handled by the view-models?

@Blackhex
Copy link
Author

To answer the first of my own questions: Otto producers may solve the issue with old messages receiving while just registering and it can also solve the problem with non-existing view-models too:

The source view-model registers itself as a producer and sends messages during its lifetime, the target view-model registers itself as a receiver and immediately calls the producer method to get the old value of the previously generated message - problem solved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants