Currently we are have a container activity that hold 2 buttons(next and cancel) along with a content layout that switches depending on the fragment. The fragments follow the mvp pattern but the omain questions seems to how to correctly implement the Next and Cancel button on click events.
Would it be better to make a Presenter for the MainActivity and pass that through to the Fragment and have the fragment work with that for the two button events? Or should the Fragment create new onClicks for the button on each fragment change? My way of thinking seems to go along the lines, the two buttons can be considered part of the fragment view at that moment in time, so the Fragment should be concerned with handling them. But wouldnt this lead to more code writing? Any help would be appreciated.
In your case my choice will be a simple way.
Activity register as listener onto fragment. Fragment handle the button event and call to activity. Each acitivty deal with event action.
As in your description fragment is a plain unit just to introduce next & cancle functions. Implements MVP on this unit cause more code but no income.
Now the question is on the activity side. If there is full business procress then go MVP way, if not just add two functions to respond button is good enought.
There always exchange, MVP more code & complex relationship for extention & team work, plain function call less code & simple procress for small unit & extention unfriendly.
Related
The idea of using MVVM is that view observes ViewModelchanges and acts. I'm using an Activity which uses 7 Fragments and the navigation between them goes through observing individual changes in the Activity from different Fragments and launching/replacing Fragments accordingly. For instance,Fragment L calls setValue, then as a result the main Activity receives the event and switches to Fragment M and Fragment M calls getValue from the observed MutableLiveData and not directly functioning as a listener to changes. Does that the right structure or should each Fragment observe changes by himself ? What would the right way to handle multiple navigations between multiple Fragments
I don't see anything wrong in what you just said. Fragments should be independent from each other unless they are nested.
If you need communication between fragments that can be done in many ways. The most basic way is to do that through activity. Activity knows how its fragments interact with each other, but fragments remain independent. They can listen to events, no problem here, but make sure you have a 'rule' in your project about how you handle events.
E.g. I prefer having one listener at a time to have the order more predictable. If I want multiple fragments to handle the event, I usually place the handler in the activity and then pass the event to fragments in the exact order I need. Otherwise it might quickly get out of control.
There are other ways too, such as EventBus, BroadcastReceivers or any other event-based mechanism.
I hope that helps. If I didn't answer your question then to answer it more precisely I'd need the question to be more specific.
As the title states, does it considered as a good practice to use a single fragment within an activity to display the content? I began to notice that more and more developers start to use the fragment as an insulation layer to separate the lifecycle logic from UI that activity (sorry, fragment) displays. The most recent example that I stumble on is the architecture blueprints provided by Google developers. They use just one single fragment for UI while the activity handles ViewModel and all the navigation between screens.
So, is this a good practice or just a personal preference? Would you care to share your opinion on the subject?
Using Fragments as your UI is a good practice.
Activity can hold all common logic, while you can use different fragments to show different UI for mobile vs tablet.
If the UI is in Fragment, you can reuse it in multiple activities.
If you have a workflow scenario like Registration flow, using a single activity with multiple fragments will help you out a lot.
Manipulation of fragment backstack is a lot easier than trying to do the same with activities.
Use fragment for display the UI is good,Reason is listed below:-
1.You can create one activity,and display multiple fragment inside that activity.
2.Handling back press is easy as you can override onBackpress() in main activity class and handle back key event from fragment(s) as check its(fragment) visibility and handle event.
3. Reusability of layout.
4. Reusability of fragment.
5. Handling different action menu is very easy for different fragment(s).
I am working on an Android test project composed of 3 main parts, each of which developed following the MVP pattern.
These parts are nested into each other and I would like to know if the strategy I am following is the correct/best one or not
Structure:
Book: ViewPager containing different Pages
Page: Custom LinearLayout containing multiple Items
Item: Custom View (in this example a simple button)
Each part uses a MVP structure (so for example for Book I made BookPresenter, BookView and BookModel, and the same for Page and Item)
As a user case I would like to keep track of how many times the user clicks the button and for each time change the Page background to a random color, and when the user reaches the 10th click tell the BookPresenter to go to the second page.
To do so I set up things so
BookView creates the BookPresenter, which in turns creates each PageView.
Each PageView creates the PagePresenter which in turns creates the ItemView (which ultimately creates the ItemPresenter)
In all this, the BookPresenter has a reference to the PagePresenter, and the PagePresenter has a reference to the ItemPresenter, so when some actions need to take place they can communicate to the child or the parent presenter in the structure
Now the question:
Is this the right way to set up a system with nested MVPs?
Because if I then want to have a PageView but instead of in a Book I need to put it in a Newspaper (other class with some alternative behaviour to Book) I still would need to recreate the whole chain of dependencies with Presenters and all the rest...
How does a “Child-Presenter” communicate with its “Parent-Presenter”? They don't (directly, not via EventBus)
From my point of view such Parent-Child relations are code smells because they introduce a direct coupling between both Parent and Child, which leads to code that is hard to read, hard to maintain, where changing requirement affects a lot of components (hence it’s a virtually impossible task in large systems) and last but not least introduces shared state that is hard to predict and even harder to reproduce and debug.
So far so good, but somehow the information must flow from Presenter A to Presenter B: How does a Presenter communicate with another Presenter? They don’t! What would a Presenter have to tell another Presenter? Event X has happened? Presenters don’t have to talk to each other, they just observe the same Model (or the same part of the business logic to be precise). That’s how they get notified about changes: from the underlying layer.
Whenever an Event X happens (i.e. a user clicked on a button in View 1), the Presenter lets that information sink down to the business logic. Since the other Presenters are observing the same business logic, they get notified by the business logic that something has changed (model has been updated).
Source: http://hannesdorfmann.com/android/mosby3-mvi-4
So let's apply this on your example.
You should have something like a Readable (if you want to make an abstraction over Book implements Readable and NewsPaper implements Readable). With Readable.getPageCount() you get the number of pages for ViewPager. With Readable.getCurrentPage() you get the current Page. Then you need some kind of Observer Pattern to be notified whenever the page is changed. You also need a Listener / Observer pattern when the user clicks on a button in ItemView. Such a click would be an Event X from the graphic above. On click on the button you let the information flow down through Presenter to your business logic which changes the Readable object. This change will then notify observers of this Readable object like PagePresenter that then updates the PageView to set the background color of the page.
So the key is: communicate via Business Logic, instead of some View to View or Presenter to Presenter communication.
Hope that helps.
Hi I am developing android application in which I am using one activity and two fragments. Consider same example which google explain like one list view and detail view. on click of list item we are rendering respective detail fragment.
So I learn how to do fragment transaction and i come up with two solutions. One which is standard way which google explain that make one interface and implement that interface into main activity. And do fragment transaction there inside main activity.
I tried with another way. when I click on list item inside click listener instead of calling interface I change fragment inside my list fragment only and its working fine.
So i want to know what is difference between those to methods. changing fragment from main activity and changing it from fragment only.
What kind of problem i will face if i implement with second method.i.e. changing from fragment only.
Need Help. Thank you.
What kind of problem i will face if i implement with second
method.i.e. changing from fragment only.
There isn't an actual problem, it's more of a design discussion. Using the second approach means you're making a very specific fragment, one that on a click on one of its rows will make a transaction with a specific fragment on a specific place of the holder activity. This would be a problem if you plan on reusing this fragment.
Suppose you have this ListFragment and you decided that it should be used in five other activities(with different data). Because it has a very precise action when clicking one of its rows, this fragment will always require the holder activity to have a specific container(where the transaction will be done) along the specific detail fragment with which it was initially used. The problem is that in each of those five activities you may want to use a different fragment when clicking a row of the ListFragment, this would require making changes to the class of the ListFragment.
Now suppose you have the same behavior with the interface approach. As the ListFragment doesn't know or care who handles that click event(as it passes it to whoever registers as the listener) you can simply put the ListFragment in the five activities with no problem(so no changes to it at all). In the interface method of the activity you could then implement the desired behavior with whatever fragment you want and in whatever container setup you want.
I've recently decided to update my app to support the new fragments feature in honeycomb 3.0.
My Application currently works on a list view that opens different activities depending on which list item is clicked.
Using an adaptation of the code in this tutorial I have created an app that consists of only two activities, but depending on which list item is clicked the second "viewer" activity launches using a different layout xml.
Unfortunately I haven't been able to figure out how to call the old methods that had all the functionality. Should I Import all of my old activities and then call the methods into the viewer activity (I may need some advice on how exactly to do this) or should I just put all the methods directly into the same viewer activity (please consider the size of these methods(which is very large by the way)).
Once everything is working with two activities upfront then it will be a pretty simple task of "fragmenting" the app as demonstrated here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
Thanks
As James has pointed out you will have to move the business logic from your Activities to your Fragments.
To handle events you can create a listener Interface. The CONTAINER activity/ies will implement this interface. As fragments has access to the container activity you will be able to delegate to the container Activity the "logic" for the desired events. For this events the activity will decide whether to launch a new activity, show/hide new fragments or whatever.
I had a similar question, take a look to the question and answer: here
Although I haven't considered that there might be a way to allow multiple fragments to occupy the same space in an activity(If this is the case then please let me know how it's done)
I think its possible to allow multiple fragments to occupy the same space in an activity. Again, take a look to the answer here ... I think the concept/scope of Activity has change a bit and now an Activity can contain different Fragments which every one will allow user to do a single focused thing.
I'm not sure what you mean by "call the old methods that had all the functionality". You'll want to rewrite all of your activity classes as fragments. Check out this tutorial here (it's very concise). Basically, you'll want an activity that consists of a ListFragment and a FrameLayout. Your ListFragment will update the FrameLayout by changing to the appropriate Fragment based on which row was selected.