I want to implement MVP pattern in my android project .
So , for Login-activity I did not have any problem .
But in Activity-Main I get confused a little and now i`m not sure how should I implement its Presenter !!!
In Activity-Main there are 3 sections as Navigation-Drawer , Toolbar and a fragment .
How can I make Presenter(s) now ? I doubt to create one presenter that implements 3 others implements or
directly create 3 presenter that have access to Activity-Main ?
Thanks
You can create refer to google's android-architecture .According to me you should create three different presenter for your each view and then bind them.you should check this part of sample,which has very basic design
What we did for a complex activity (30+ screens) was to divide each screen into View and Presenter components, where View battles with Android Views, and Presenter works out the logic (pulling and preparing data from controllers, network or local storage). But yeah, Google samples contain information about pretty much everything you'll need to start. Either way you should spend more time designing and thinking about the structure rather than actually implementing it. Good luck :)
From my understanding about MVP and its implementation is "P" is logic part which does all the logic/action handling. For this case i have personally created two presenters : Navigation Drawer/Home Presenter & Fragment Presenter.
Navigation/Home P : Only responsible to action related to Navigation and related to Main-Activity.
Fragement P : Having 1-1 relationship ie each fragment will have its own presenter.
For toolbar Presenter : I don't see much of a case where you should create separate presenter for toolbar, as all the action delegated via fragment and each fragment will have different items in toolbar and different handling as well.So collating them in one would just add complexity.
Related
When working with Bottom Sheets and Dialog how to perform operation:
Use a SharedViewModel with fragment that created this bottom sheet?
Don't use a ViewModel at all?
Creating a separate ViewModel for the BottomSheet?
Any other approach that is best practice
If the bottom sheet/dialog is tightly bound to your "host" fragment (it shares some specific live data), and it is never going to be created from some other fragment, then it's OK to use a shared view model.
If the dialog is dead simple (like one input + 2 buttons), then the viewmodel might not be needed
If the dialog really needs a viewmodel (i.e. it fetches and displays some dynamic data), then a separate viewmodel makes sense
I'll go with the first approach by using a ShareViewModel, but if you understand the underlying layer, shared ViewModel is also ViewModel it's just a name convention we gave it to them.
Also sometimes it becomes tedious to write separate ViewModel to deal with fragments and bottom sheet where a MainActivity ViewModel can also do the exact same thing.
What I meant, in order to avoid complexity I use one view model per activity. Now, whenever I want to execute something in fragment or bottom sheet I just pass the view model in the constructor itself. Many people will think this is bad practice but it's not coz as per the concept of view model it will only be created and destroyed in accordance with the activity's lifecycle and only one instance will be created all along. Also by doing this, I can use Dependency injection with the fragment (I don't think that DI works with navigation component but I think you got my point).
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 android application and some team members suggested using one activity and one parent layout for the whole application and each time we need a new screen we just inflate a new layout in the parent layout and destroy the old one.
I on the other hand think that using fragments would be the way to go.
Do you think one way is better than the other?
I would be grateful if you can think of solid arguments to support your claim.
Thank you
UPDATE:
We are using MVC in our application. They want to create a new class for the view while i opted for using the fragment as my view. As it stands now the application has one activity and one layout. To change the view we are calling the same layout,removing its child views and inflating the new view .I dont see how that would be better then just using the fragments as views
I think most Android developers will tell you to use one or more Activities or Fragments. But why?
Basically, because one Activity which is responsible for each and every View in your app would be something like a "god object". This is considered an antipattern, I suppose because it may fast become a maintenance nightmare.
The Android pattern of one Activity and several Fragments on the other hand is following the Single Responsibility Principle, so your code is easier to maintain. All the more so because Android-specific things like saving state on configuration change are much easier to implement if you are able to use the built-in methods.
I've been coding android apps for a couple of years now and when I started fragments was the way to go so I've been using them since.
From the beginning I thought the lifecycle and handling of fragments was a mess and tried a couple of different approaches with a single activity or 1 activity per groups of fragments etc.
I was more comfortable with the single activity approach but then ran into problem where to show and hide fragments etc.
I tried to have all logic for showing/hiding a fragment in its own class and then using a model-notifier pattern for pushing out a message containing information about which fragment to show and hide. The last thing I tried was to have a "FragmentService" that gets notified, using EventBus, with a message (DTO) containing information about what fragment to show/hide and a bundle to pass with it.
I'm not totally satisfied with my architecture for managing fragment yet so now I'm curious how you solve this problems? I want every fragment to be loosely coupled from each other and able to start Fragment1 from Fragment2, 3 or 4 etc.
Can this be solved in a centralized and understandable way?
I am planning an app and trying to explore all the possible development options/methods I have available. One thing I'm struggling to get my head around is Fragments. I see a lot of people praising them as you can "resuse" fragments throughout the app but I can't think of an example situation.
From some example apps I have looked at (all been tabular layouts) the code for each fragment has one layout, so why not have a seperate activity instead?
I am hoping to implement a tabular layout in my app. If anyone can give me an example of a fragment being reused within an app I hope it will give me a better understanding of the benefits.
"Reuse" is overrated. Of course - you can put this same fragment (with this same features) in different places of your application - let's say that you can use a fragment in different, horizontal and vertical layouts (as you probably saw in Google's tutorial).
But at the end using fragments simplifies your project - for example - you can switch fragments inside one activity and get benefits of much easier navigation and in app communication.
Using fragments gives you one more thing - flexibility. It's much easier to move some view from one place to another, or just remove from application. All that because fragment encapsulates logic and usually a view, still offering power of externally managed lifecycle.
(Thanks for comment from Richard Le Mesurier)
Fragment is not a View neither a ViewGroup. It is not a visual element at all. Fragment inherits directly from Object.
One should think of a Fragment as a unity of a reusable code, reusable in various Activities (the Activities consist of visible elements).
Thus if you can think of any code you can reuse through several Activities (even the same Activity with different layout) and that code somehow depends on Activity lifecycle, then you probably should make this code a Fragment.