I'm working on an Android piano "quiz" app - users tap on the piano keys and then click the yellow "check" button to submit the answer for evaluation and see the correct answer drawn on the piano. The main QuizActivity has this layout:
The upper part of the screen hosts a couple of controls (Text, submit buttons, etc.).
The lower part of the screen is occupied by a custom PianoView component, that handles drawing of the piano keyboard.
According to the MVVM principles, the PianoView should have its own PianoViewModel, that stores its state (i.e. currently pressed keys, highlighted keys, etc...) in a KeysStateRepository.
The enclosing QuizActivity should also have a QuizActivityViewModel, that handles the various controls (submitting an answer, skipping a question...).
The QuizActivityViewModel needs to be able to query the selected keys from the PianoView (or rather from its KeysStateRepository), submit them to the Domain layer for evaluation and then send the results back to the PianoView for visualization.
In other words, the QuizActivity's ViewModel should own/be a parent of the PianoView's ViewModel to facilitate communication and data sharing.
How can I model this parent-child relationship to communicate between the ViewModels?
AFAIK a ViewModel cannot depend on another ViewModel (What would I pass as the ViewModelStoreOwner to obtain a ViewModel in another Viewmodel?). I don't think it's possible to achieve with Dagger-Hilt at least.
Three solutions to work around this problem came to mind, all of them unusable:
1 - The official way of sharing data between Views
The Android dev docs recommend using a shared ViewModel to facilitate sharing of data between two Fragments / Views. However, this does not fit my use-case. The PianoView (or its ViewModel) should be the sole owner of its state with a Repository scoped to its ViewModel. Otherwise, the PianoView component would not be reusable. Consider for example another Activity, where I'd like to have two independent PianoView instances visible:
Reusing a Shared ViewModel from the quiz activity would be obviously wrong, because it contains irrelevant methods and logic (i.e. submitting quiz answers) and would not fit the two-keyboard scenario.
2 - Application-scoped repository
A similar problem was tackled on Reddit with a proposed solution of using a shared instance of the repository. However, using a #Singleton KeyStateRepository would once again prevent the two independent keyboards to display different data.
3(EDIT) - 2 duplicate repositories replicated by an Event Bus
I could in theory create 2 independent ViewModels and 2 KeyStateRepository instances. The ViewModels would subscribe to an event bus. Each time a ViewModel invokes a mutable operation on its repository, it would also fire an event and the operation would get replicated via the other ViewModel subscribed to the same event bus.
However, this feels like a fragile & complicated hack. I'd like to have a simple MVVM-compatible solution. I can't believe a simple parent-child relationship for two UI components is something unattainable in MVVM.
I think you got a decent answer from Pavlo up there, I'll just clarify what he meant with other words.
KeyStateRepository is a storage for the state of piano keys. There's nothing stopping you from making it to support N number of Pianos at the same time, this would solve the scenario where you have NNN Pianos on Screen, each with different keys pressed.
The PianoView should be contained in a Fragment, that should be your "unit". Why? Because you want a ViewModel to handle the state and events coming to/from the view. And a Fragment is the Android artifact provided for that regard. Think of it as an annoying piece of baggage you need. Android Devs used to call these things "Policy Delegates" because you delegate to these (a Fragment/Activity) some things you cannot do without "the framework" (the Android Framework, that is).
With this in mind, you have an Activity whose viewModel/State is handled independently. What State/Events do this viewModel handle? Things that are not in the PianoFragment/View(s). E.g. if you wanted to handle the back navigation, or a "record" button at the top, this is the activity's domain. What happens inside the "PianoView/Fragment" is not this activity's problem.
Now the Fragment that will contain the actual PianoView can be designed to contain "more than one" or just one. If you go for more than one, then the PianoContainerFragment will be designed with a ViewModel designed to handle more than one PianoView (so each view will have a "name/key") and the KeyStateRepo will be able to handle the "CRUD" operations of any Piano View you throw at. The ViewModel will sit in between, dispatching events for different "subscribed" views.
If you elect to go for "one fragment contains one piano view", then it's a similar architecture, but now handling the multiple "fragments" in one "activity" is now responsibility of the Activity (and its view model). But remember, the PianoViews (via a Fragment either shared or not) talk to a ViewModel that can be shared among piano views, that talks to a common KeyState Repo. The activity coordinates the views and other Android things (navigation, etc.) but the views operate independently, even of each other.
You don't really need a shared viewModel I think, in fact, I wouldn't do it until really needed, the more you separate things, the less the chances of "violating" one of the fancy patterns... but if you elect to use the PianoViewModel as a shared among all views, that's perfectly acceptable, you're going to have to include the Piano "Name" to differentiate whose events are for whom.
In other words (showing with ONE PianoViewModel for ASCII Simplicity),
// One QuizActivityViewModel, Multiple Fragments:
Activity -> PianoFragment (PianoView)|
| <-> PianoViewModel <-> KeyRepo
PianoFragment (PianoView)| /
-> QuizActivityViewModel <----------------------/
Here the QuizActivity creates N fragments (in a list maybe?). These fragments internally initialize their pianoView and connect to a PianoViewModel (can be shared like in the graph above) or each can have its own. They all talk to the same Repo. The repo is your "single source of truth about what each "piano". What keys are pressed, and anything else you can think of (including a name/key to make it unique).
When QuizActivity needs to evaluate the state of these, it will ask (via its own viewModel) for the state of NN pianos.
Or
// 1 Act. 1 Frag. N Views.
Activity -> PianoFragment (PianoView)|
(PianoView)| <-> PianoViewModel <-> KeyRepo
-> QuizActivityViewModel <---------------------------/
With these, the QuizActivity (which created the pianos to begin with as well), also knows the keys of the pianos that will/are displayed. It can talk to its viewModel that talks to the same KeysRepo (you only have one of these and that's fine). So it can still handle the "nav" buttons and it can ask (via its QuizActVM) what the current state of the Keys are (for all involved pianos). When a Piano key event is fired in a PianoView, the PianoViewModel will receive the event (what key was touched, in what piano); the KeyStateRepo will record this, and perhaps update a flow {} with the events coming from the pianos...
The Flow will be expressed in a sealed class which will contain enough information for both QuizActivity + VM (to perhaps perform a real-time validation), and to the PianoViewModel to update the state and push a new state to the PianoFragment (Which will update the state of its view(s)).
This is all common to either method. I hope this clarifies the sequence.
Does this make sense to you?
Edit
In a multiple architecture activity if you wan't PianoViews to have ViewModels and your ActivityViewModel to know about them - don't use Dagger injection with them but create PianoViewModels inside an ActivityViewModel and assign some callback to them on the stage of creation - thus you will have an access to them and will be able to listen to their events and influence their behaviour as well as save their state, from inside the ActivityViewModel. It is not an uncommon and in some cases even a correct approach. Dagger - is a mere instrument that is not intended to be used everywhere, but only there were it is needed. It is not needed to create PianoViewModels - you can inject all the needed stuff into the ActivityViewModel and pass all the needed elements to PianoViewModels constructors.
Also you don't need to wrap your Views into Fragments if you don't want to.
Edit end
You are making wrong assumptions based on a flawed architectural approach.
I am curious why do you need ActivityViewModel at all. View model should exist only for the elements that have some View. Current android development suggests that the Activity should not have a view representation and serve as a mere container of other views(Single activity principle). Depending on your architecture Activity may handle showing the loading state(progress bar) and some errors, but once again it should not contain anything that is being handled by other views. Thus PianoView should be a PianoFragment with its own ViewModel that handles access to its repository on the data layer via interactor on the domain layer.
The shared view model would work in case you would need one, and you would be using the Single activity principle with multiple fragments. Because Jetpack Navigation has the support of the shared view model out of the box. In the case of a shared view model - each fragment would have its own view model along with a shared one for communication. Each navigation graph could have a separate shared view model only for the fragments it contains.
Also regarding KeyStateRepository - you need only one of those(or a Dagger #Scoped multiple copies - but I do not recommend it). The only change should be - the addition of an extra key for each separate PianoView - to distinguish them inside a KeyStateRepository. To easily achieve that you may be using Room or some other file/memory/database cache mechanism.
Hence the initial problem of your app is not an inverted dependency of ActivityViewModel on a PianoViewModel, but a flawed architecture of the app and its inner interactions. If you want to continue work with your current architecture - there is no easy answer to your question, and almost every chosen solution would not be 'clean' enough to justify its usage.
I would do the following, if you don't want to tie the PianoViewModel to your ActivityViewModel, I'd just create an interface, which the ActivityViewModel implements, and the PianoVM could have a nullable reference to that interface. This way neither the implementation, nor the existence of the component would be required for the PianoViewModel to work.
How you get the ActivityViewModel is another question. Check out by activityViewModels() implementation for fragments, you probably can do the same with by viewModels() passing in the viewModelStore of the activity instead
Related
Hi am using viewmodel in my application. Since my logic is large in single activity. Am implementing that logic in my viewmodel. Anyway i want to separate this logic from my viewmodel. Any idea how to segregate the logic out my from my viewmodel.
Since it's UI logic, you can isolate each piece of code that has to do with the same behavior (or even UI section) into its own fragment/view and corresponding view model (think Single Responsibility Principle). If it makes sense, you can also share view models between the same UI components. Then, you orchestrate everything in the activity. For code that has nothing to do with the Android framework, you can also extract it to its own independent class, and then use it in the view model through composition.
I have been reading up on the Android API and it seems like Fragments are meant to sort of modularize an Activity. So if an Activity has a ListView and DetailView then it should be split into two separate fragments and have the Activity act as the master controller.
In my previous project that I worked on we were using Fragments kind of like children of the Activity.
For example: Let's say there is a AutomobileActivity that is designed to save automobile input data to the cloud.
We have fragments like:
SedanFragment
TruckFragment
SportsUtilityFragment
These fragments take up the entire view of the Activity and only one is displayed at a time. While these fragments use methods in the Activity to call common webservices like saving automobile information, getting car information. They also do different things like the Truck may have an additional entry to set the "Bed Size" and SportsUtilityFragment may have "Tow Limit" etc.
So in a way we are leveraging a lot of re-use and modularizing, but it's not exactly what the Android API is detailing. Is this a bad way to use Fragments?
This is a very objective question and this will have a lot of different answers. In my opinion what you are doing is correct. The reason behind this is that they have a set of common webservices. If we go by the mvc approach they can all have the same controller(for calling webservices), a model class(Superclass- vehicle) with separate models which inherit from this vehicle model class. By doing this you can have an additional entry parameter which will be present in these models. Your view, the fragments can easily call the instance of these models. If you modularize in this manner, you will be making life very easy for yourselves.
I have few gwt mvp design related questions:
Can we use event bus to switch views from one presenter to other via controller using custom event?
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can take a decision, which presenter to show?
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if someone has any thing to mention in favor of this.
PS: all my views make use of custom widgets and there is no gwt specific widgets(buttons, checkbox etc...) in views.
You can do anything you want, but you have to consider the consequences. For example, if you switch views without creating a history event, a user may be thrown out of your app when a user hits a back button expecting to see the previous view.
I very much like the Activities and Places design pattern. It takes care of all of the issues (history handling, bookmarks, tokens, etc.) You can also extend it to add animation effects when switching views on mobile devices - mgwt does that.
I have few gwt mvp design related questions :
Can we use event bus to switch views from one prsenter to other via controller using custom event ?
This is a bad practice, unless you have real good reasons to do that. Since you're changing the view without having an impact on the url, you won't know what is a the state of a view at a choosen moment, you cannot get back to a previous view in an easy way, and finally, people will have difficulties reading the code, since you're out of the "standard".
The only reference for you should be the url, you cannot assume data is loaded neither the applicatio is in a given state: each and any view may be the start of the navigation story for your users, so if you get information from any other source than the Place, you're probably doing wrong, especially if your source is an event. the only special case here is you don't want users to enter your app in a certain view state, so you 'impose' that another url is called before, and restrict the access to the view through an event starting from a given application state
If above is true, can the custom event (say changeViewEvent) contain name of next view, on the basis of which controller can
take a decission, which prsenter to show ?
as said before, you're reinventing the wheel. It's far better to adapt to the existing mechanism that is well thought and covers the majority of cases. You can put a json formatter to tokenize your url while developing so it's not a nightmare to put variables in. And when you're done, create a nicer regular url format
Is it a good design to make views reusable(as a widget) in an application, though i don't agree with this, but will be happy if
someone has any thing to mention in favor of this.
depends on what you call a View. if it's the activitie's view then youm might need that in very few cases, it's better to inherit a basic view and fork its children for each activity (even if the view does nothing, time will show it will evolve differently): this is better since the base view contains what is common without the specifics of each child activity.
Finally if you mean a composition of widgets when you say, a view, then you should definitely reuse them, it will make you obliged to improove your widgets and compositions to be in a constant improvement, this will heop you for the rest of the project, and maybe for other projects
If I understand correctly :
an Activity is a User action on widgets
This activity moves the application state in another Place
The url moves along, thanks to anchors (thought modern browsers have an api)
When we share the url, it define a Place, and it's enough to rebuild the State
(As I'm also a javascript guy, this looks much like Backbone's router and other modern JSFrameworks)
But to rebuild the State, we need to fetch some data to the Server. Is there anything in the P&A api to do this ? With RPC, this role is clearly done by GreetingServiceImpl that extends the RemoteServlet. With Backbone, we have the Sync object.
But I never see such code such when I look at A&P tutorials. Where is the Server ? Do we need RPC there ? Does it mix with RequestFactory ?
First, a small note about terminology:
A Place represents where you are in the app. When you look at that screen, it's generally composed of different "blocks", each dedicated to a specific activity, e.g.: a header (let's say with search box and logout link), a navigation menu, the "master" in a master-details view, the "details" in a master-details view. All these can be activities (though not necessarily, things that are never swapped to anything else won't gain anything being activities).
Because activities are by definition displayed on screen, you can interact with them, possibly triggering a move to another place (PlaceController#goTo).
The place is optionally synchronized with the URL (both ways) and generate browser history items; by default using the hash, but you can swap the implementation to use HTML5.
(places are similar to Backbone's router except they're type-checked, activities are a light layer on top with no equivalent in Backbone AFAICT)
Now to answer your question:
GWT is a toolkit, not a framework. That means most building blocks don't force you into using any other building block (places can work without activities, editors can work without widgets, etc.)
Activities start asynchronously, which is where you'd generally get the data from wherever it is. In the spirit of a toolkit, you're free to use whatever fits your needs: GWT-RPC, RequestFactory, RequestBuilder, Errai JAX-RS, Errai Bus, XMLHttpRequest, WebSockets, AppEngine Channels, etc. Some people also post events to their event bus to decouple the activity from how they get their data.
MVP describes the Client-architecture.
M_odel:
The business objects handled by you app.
V_iew:
UI elements, showing a representation of your model.
P_resenter:
A class which handles all userinteractions and modification to your model.
Lets assume you have an application which shows and stores Notes.
You have some Places:
a Place is like an good old HTML page in older days. In MVP it can be described a a set of running Presenter. In our simple application there are two places. Every Place does only have one running Presenter
NotesListPlace -> shows all stored notes
NotesEditPlace -> Creates / Edit a Note
The NotesEditPlace:
There is a View and a Presenter.
The View has an TextArea (for the Note) and a save button.
The presenter has a clickHandler for the save-button (there may be more, but as example it should be enough)
The User select a Note from the NoteList
PlaceChange from NoteListPlace -> NoteEditPlace
The Presenter starts and registers the click-handler at the view. If the button is pressed, the presenter reads the input from the textarea and update the Model (A new Notes-onject)
Now comes the server interaction. You can use every (GWT) transportlayer you want.
The success callback fires a PlaceChange event to the NoteListPlace.
All starts again. The presenter starts, a new server interacction to load the MOdel ( A List of Notes). The view is updated by the presenter...
Update 1
There is no need of a server. The presenter may persist the Model to the localStorage of the browser.
Update 2
You can use every transport mechanism you want. RequestFactory, GWT-RPC. I use RequestBuilder and GWT AutoBeans.
I have just read the description of MVC desing pattern and I havesome questions: I am Android developer (junior), and I want to make my code more clear. So, should I use MVC for it? And must every activity has own model? Is there any good tutorial for it? Thank you.
It's already implemented. MVC pattern on Android
you need not to do anything, As Android is prebuilt MVC
MVC is kind of an idea more than a specific way of doing things (like a 1-to-1 relation between activities and models). The idea is to separate the model, view, and controller, so that stuff makes sense.
In Android, more than one activity can refer to a single model (for example, an activity with a list of houses you can search on, an "edit house" activity, and a map that shows them as points in their coordinates). So, to answer your second question: no, they don't need to have their own model.
And yes, you should use MVC, if it makes sense. Just think about your models as a separate entity from the actual application, and your activities as "users" of the models.
On Android, I've found the MVP (Model, View, Presenter) pattern to be a more direct correlation with the overall system architecture. Your activities comprise the Views, which in the MVP setup are responsible for managing their own events and controlling their own appearance. The presenter serves as a facilitator between the model and the view, providing the data when the View requests it. Depending on your needs, the presenters may or may not be a service. As for the View/Model ratio, it really depends on what you're trying to show on your screen at any one point. When android was running on phones only, it made sense to have pretty much a one to one correlation between Activities and your model. Now, the normal case is to have a one to one correlation between your model and your fragments, which your activity then marshalls about by showing the appropriate fragments.
If you want to do MVC, though, again, now that fragments are a tool in the toolbox this is much easier than it once was, especially with well developed event system (such as the one included in RoboGuice) - Think of your fragments as your Views, and your activities as controllers - Ordering your views about, providing them data from the model, and handling transitions to other controllers.
The choice of pattern depends on your needs - if one's application is to be heeavily service driven, MVP is probably a better way to go. If, however, the app is just a thin client over a database, then MVC might be easier. It's all up to you :)
'get started' resource for MVP : http://www.jamespeckham.com/blog/10-11-21/MVP_on_Android.aspx