I set up my application in the following way and am curious if it's considered "best practice." I have two activities and two fragments. Activity 1 launches and immediately uses Fragment 1 to display a RecyclerView of items. An Item is clicked in the Fragment, it's communicated back to the Activity through an interface, some logic occurs and Activity 2 is launched, which immediately uses Fragment 2 to display the detail of the selected item.
I did this because A)I like the logical flow of Activities within an application and 2) I needed to create tablet layouts in which I could use both the Fragments to fill the screen.
The more I'm looking at this thing, I'm thinking why not simply have 1 Activity that manages both of these Fragments? Activity 1 launches Fragment 1, item is clicked, info goes back to Activity, FragmentManager replaces Fragment 1 with Fragment 2.
My question does one of these ways adhere more to "best practices" or are they both fine and it's a matter of choice?
You've not described your problem clear enough to use more than one Activity, other than unrelated data to the list and what happens when you click there.
What you described is a "master-detail" flow, and that is a good use case for one Activity and two (or more) Fragments - a list + some detail page. This especially makes sense on larger screens when you can show those Fragments side-by-side.
For example, you can have an Activity that holds a navigation screen (whether that be tabs, a drawer, or a bottom view), then everything you navigate to within there is a Fragment.
Otherwise, you redirect to some "settings" page, for example, that is a new Activity, which demonstrates the "Single responsibility principle" in your UI.
Well you can go with the single activity - multiple fragments. You can pass data between fragments using bundle as well. Matter of choice also depends on the use case. But fragments are made to use as light weight activity that requires less resources then activity. Most of the things are possible with fragments. So unless it is not required to use activity my choice goes with single activity - multiple fragments.
Related
I am developing an app that has some ongoing process that almost all screens depend on.
Let's call it ActiveTransaction. So, one fragment prepares items, the other fragment prepares payment, another adds discounts, etc... If one part fails, everything needs to rollback.
So, basically, I need to achieve atomicity across multiple fragments. I've tried to use shared ViewModel for this, but since each fragment adds its own stuff, that shared ViewModel has become too big.
So, I wonder what would be the best way to handle those processes that stretch over multiple fragments.
Should I have perhaps a singleton object ActiveTransaction that is injected in each viewModel?
Is this maybe what other technologies call the app State?
I haven't found anything in the MVVM architecture guidelines.
You can create Tabbed Activity - blank Activity with tabs. New project -> Tabbed Activity.
You will have one activity and multiple fragments.
So all functionality will be in MainActivity. Your fragments will contain views, which will call methods from MainActivity. All objects and calculations will be in main activity, so if it fails (because of memory lack), everything will collapse too.
For Example:
You have one Tabbed activity MainActivity and 3 fragments: Item Fragment, PaymentFragment and DiscountFragment. MainActivity contains multiple methods, let's say prepareItems(), preparePayment(), addDiscount(). User can go through Tabs, opening fragments. MainActivity methods can be called only via fragments. So if MainActivity collapses, the whole process will collapse.
So you will achieve atomicity and user can see changes by going through tabs. You can replace Tabs Activity by other scenario with single activity and multiple fragments which don't have functionality but contain views which will call methods from MainActivity
I am trying to find a way to show two activities on the same screen, I have two activities main and content activity, the main activity has a mini-player that's implemented and only works in an activity and the content activity has some implementations that also only work in an activity so the solution of converting them into a fragment does not work for me. I need to find a way to show the mini-player in the main activity inside of the content activity. I have looked online and none of the solutions so far have been working for me!
You have 2 ways to complete task.
Fragments, They can do same things as activity. Its lite weight activity class with more flexible to attach and detach from the screen.
Views, If you think your task can be done by only activity then use views for it. you can apply different animations and show/hide feature to display content on the screen within single activity.
Fragment is a part of an activity, which contributes its own UI to that activity. Fragment can be thought like a sub activity. Where as the complete screen with which user interacts is called as activity. An activity can contain multiple fragments.Fragments are mostly a sub part of an activity.
From document
For example, a news application can use one fragment to show a list of
articles on the left and another fragment to display an article on the
right—both fragments appear in one activity, side by side, and each
fragment has its own set of lifecycle callback methods and handle
their own user input events. Thus, instead of using one activity to
select an article and another activity to read the article, the user
can select an article and read it all within the same activity
Use Fragment.Fragment are Runs inside the Activity.
you can display multiple fragment in same time.
Refer Fragments
Create a fragment
At first, Android system can show only one activity on the screen.
You should not use Activity.
Please use Fragment. You can use multiple fragment on the same screen.
I need some best practices ideas for my app. I think there is too much boilerplate code right now and I don't know if I'm using activities and fragments the right way.
There are 3 activities (A,B,C). The app starts at A. I can navigate to B which is a simple list and each of the items are clickable to show the item more detailed in activity C. A should be the "root" activity, so I set the parent activities in the manifest file.
Now I want to have a DrawerLayout navigation on B and C, which actually represents A in a smaller way.
I created an abstract NavigationActivity class for taking the view of the activity and set is as the first child of the DrawerLayout and add the navigation as second child. This works very well, but since the navigation has a state I embed the navigation as fragment, because I thought that the state is shared then, but it isn't and I don't know why I should use fragments at all.
Should I use one activity and load different fragments as main content? Then my app consists of 2 activities and maybe 50 fragments, when I finished it. I think that the way I try to implement it is not correct.
As an example: When you enter the PlayStore, there is the navigation on the left. You can browse the app and so on. Do you thing/know that it's the same activity with different main content or are there more activities?
Can you help me? Thanks :)
Single Activity applications are possible, but are not necessarily a best practice. IMHO, fragments have a very complicated lifecycle, so use Activituies when you don't HAVE to use fragments.
If your problem is to share the state of your drawer fragment through activities, you could pass it as an extra to each activity, or keep it in a static class/variable to retrieve it at every start.
Don't forget to also save this state during the destruction of one of your activity.
I've been struggling with this for a while now, I want to start off with a diagram of my problem:
The three navigation drawer buttons are part of my Base Activity. Each purple block below the three buttons are fragments, and the descendants of each of those blocks are in turn fragments. I'll use the master and detail fragments as a demonstration of the issue I am having...The user clicks the nav drawer button, which opens the master fragment that hosts a list of articles. Once a user clicks one of those articles, I then open the detail fragment inside of the master fragment. So If I find myself at the detail, and I decide to open the nav drawer and click the third button for instance, then click the second button again, I want the detail to be open still, and if I hit the phone's back button I want it to move back to the master fragment, and end there. Any tips will be helpful, as I am probably going to use a similar pattern for the first button, it's main fragment and it's children fragments as well.
In my opinion, the cleanest way to handle what you are describing would be to have three separate FragmentActivity classes that implement the DrawerLayout instead of one monolithic BaseActivity.
Each button in the drawer should start it's respective FragmentActivity using launchMode singleTask. This ensures that you launch the same activity instance each time, instead of a new one, which will maintain your back stack for each activity as you switch between them using the drawer buttons. See Android Developer Guide Activity:launchMode for more details.
Each of the three FragmentActivity instances should be responsible for starting and managing it's fragments using listener interfaces. For example, where you have your Master fragment opening a Detail fragment directly, you should instead have your Master fragment tell it's FragmentActivity that it needs to open the Detail fragment. See Android Developer Guide: Communicating with Other Fragments for recommended practices in implementing this type of decoupled communication between FragmentActivity and Fragment. It will make your life much easier down the road when you want different layouts for tablets, etc.
Each of the three main drawer "tasks" seem to be unique enough that isolating each within it's own FragmentActivity seems the best way to implement what you are trying to do. You can apply this same approach for each of your main sections.
I had the same problem and didn't want to go to multiple activities since that would complicate the back navigation of my application. Your fragments won't save their state automatically unless the activity lifecycle events are being called.
In our case those don't happen since we're not leaving the activity. You can use FragmentManager's saveFragmentState on the fragment you are replacing to manually trigger the state saving and get a Fragment.SavedState object. You can keep a list of your SavedState objects and when pushing a fragment check if you have a saved state for it. If so you can call Fragment setInitialSavedState which will cause your fragment to load the previous state.
Now in my app as a user toggles between fragments with their own child fragments the state is retained when they come back.
I have a question about whether to use View or Fragment with ViewPager.
Background:
I have an Activity A that contains a ListView. Each ListView item opens Activity B. Activity B shows different content depending on which ListView item is tapped in Activity A.
Activity B's content is shown inside a ListView.
Question:
Now, instead of going back and forth between Activity A and B to switch contents, I have a requirement to implement horizontal view swiping to switch contents all within Activity B.
One solution I found (tried it and it works) is to create many instances of Activity B's ListView and use it with ViewPager + PagerAdapter.
Another potential solution found on the doc (haven't tried it) is to bring that ListView into a Fragment, create many instances of the fragment and use it with ViewPager + FragmentPagerAdapter or FragmentStatePagerAdapter.
My question is, what's the benefit of using each approach? Should I go through all the trouble of bringing the ListView into Fragment or just simply use ListView with ViewPager?
Thanks
A Fragment is a useful approach, I think, when you want to tie some UI business logic to a particular View (or group of). As you know, that individual Fragment has its own lifecycle callbacks and so forth, just as an Activity would.
Rather than having a single Activity host many ListViews through a single PagerAdapter, it may be cleaner to use the Fragment approach because the Fragment only needs to deal with the logic behind driving a single ListView.
This is a very similar situation to one I've just been facing. I'm showing various vertically scrolling forms (consisting of lots of input fields) within a ViewPager. In my case I have gone for the Fragment approach because in my case, it's possible that the ViewPager will actually need to display a completely different kind of view on certain pages. For example, on the first few pages, user input forms might be displayed. But on the final page, a graph will be displayed. A whole separate set of logic is required to drive that graph. To drive those input forms and one graph from a single Activity would get a bit messy, and I would probably need to contain the business logic in several delegate classes or something. So for me, Fragments were the obvious choice in the end. I have my InputFormFragment and a GraphFragment, and they each contain only the applicable logic for the Views that they supply.
Another thing to consider is that in the near future you too may want to display a different kind of View in your ViewPager. Or, you might want to have another UI layout altogether, perhaps one that doesn't use the ViewPager but displays them all side-to-side (e.g. a layout used on a large tablet in landscape mode). With Fragments, things are just far more modular and you could factor the code to do this quicker. If on the other hand you achieved your objective by using a single Activity that contains a simple PagerAdapter and all the logic for the ListViews within, you might find it takes more work in the future to support new kinds of Views or special tablet layouts.
One thing I will say is having implemented Fragments in a ViewPager myself through FragmentPagerAdapter and FragmentStatePagerAdapter, things can get a bit awkward if you have any special requirements; managing Fragments can be tricky sometimes. For example, for my UI I needed to be able to programmatically add and remove the ViewPager containing the Fragments. I also needed to ensure that the adapter in use didn't destroy Fragments once they had been shown, because I needed to collect data from all Fragments simultaneously at a certain point. Furthermore, I had to extend and modify FragmentPagerAdatper to make sure that the Fragments go through their onDestroy() properly and are removed from the FragmentManager when the ViewPager was removed.
Fragments enable a very modular way of constructing UIs for various screen sizes and orientations, and are excellent in how they allow you to encapsulate business logic and lifecycles for individual UI elements. However if your scenario really is just as simple as several ListViews in a ViewPager and you know that you will never need the modularity, then the overhead of Fragments could be an overkill.