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.
Related
I am new to developing on android, finding myself somewhat confused regarding fragments and activities, and when to use the former specifically.
I want to achieve the following:
Have an activity with buttons for displaying different graphs. The selected graph should appear on screen in a panel overlaying the screen, or in fullscreen, and it should have functionality/buttons e.g. for selecting a graph timeframe.
Would creating each graph-page as fragments, routing events to the main activity be a good idea here, or should I just make a new activity for each? Or are there better options?
Cheers
I wouldn't recommend to use separate activities for this task.
The fragments are a great option for your case. You can save the state of each fragment and thus avoid recreating the graph views every time (which saves lots of CPU time if amount of data is big).
Read info about FragmentTransaciton and of course learn about working with Fragments in general. Maybe you should also try using ViewPager if you want to avoid switching fragments by yourself.
In case of using ViewPager you should use FragmentPagerAdapter (this one saves fragments for you) and you will just switch between them from your MainActivity. In each of the fragments you will implement your own graph with its own (or shared) layout file.
This version of the pager is best for use when there are a handful of typically more static fragments to be paged through, such as a set of tabs. The fragment of each page the user visits will be kept in memory, though its view hierarchy may be destroyed when not visible.
I have a NavigationView used as a slide-in menu. Each of that menu items is a use case itself, therefore I tend to using activities containing different fragments.
But nearly every example of NavigationView/NavigationDrawer uses fragments, so I don't know what to use here.
I thought different use cases should be "encapsulated" in own activities, therefore I don't really understand why Navigation[View/Drawer] uses fragments. And that leads me to my question: for a Navigation[View/Drawer] containing completely separate use cases - should I link to activities or fragments?
I posted a similar question
I have created around 4-5 apps with mid-big size project. I used Fragments for Navigation Menu clicks and had to manage lots of Lifecycle events and Memory Leaks and shit stuff. The Performance degrades and app becomes slow.
Then in one of the app I Used Activities for each Navigation menu clicks, treating it separate Entity/Module. This Activity would then use fragments if they had child views.
Doing so I had a great app, less trouble and I could concentrate on Business Logic rather than maintaining fragments.
Although Google recommends Fragments, But I never liked them, they always put me in trouble and handling them is a mess.
In my current Project I have created a BaseActivity implementing Navigation and all the other Activity extend it.
the NavigationDrawer and the contents are all just Views inside the Activity view hierarchy.
The use it of fragments is usually shown in tutorials because you can encapsulate each item inside a fragment, and fragments is the usual Google advice, even though they're a pain in the ass and have horrible drawbacks regarding animation.
But the direct answer to your question is: It's all just a matter of structure and organisation and it really does not matter how you do it, because in the end they're all just views in the Activity view hierarchy.
You can "manually" inflate views and put in the content area.
You use fragments to separate the views and logic and their own container.
You can use activities with different content and the same NavigationDrawer.
With the NavigationDrawer and the recommended way to implement it according to google it should be with fragments. Which creates a lot of nesting which does not seem to be too supported. And kind of messes up the idea of having activities with fragments for supporting different layouts.
So I wonder what the best suggestion would be if you have have a layout, that on a phone will be a list on the whole display, and on tablet you will have a list on the left side and detailed information about the item clicked on the right side? Ses images attached as links. It would have felt more natural to have activities instead of Fragment A, different for each layout.
Fragment A is the fragment that your navigating to. Fragment B in both variants should be the same except for what's gonna happen when you click on an item. In the phone example the Fragment B should be an expandable list and on the tablet it should show the details in Fragment C.
What do you mean by "Which creates a lot of nesting which does not seem to be too supported."? Nested Fragments do have some different behaviour (e.g. the "for result" stuff is a bit trickier to do), but it's not that much different from an Activity with Fragments. Just always make sure that your Fragments are correctly attached and detached, then you can use them however you want.
Some people don't like Fragments, because of their "lazy loadingness" and they're sometimes harder to see through, but that's just the cost for having a more flexible way to structure your components. It really depends what you want to do and how fit you are with the Android Framework.
We recently converted an app from a multiple activity based one, to one with a single activity with multiple fragments. The activities that became Fragments used to contain fragments themselves, so we use child fragment managers to host the Fragments in the Fragments (these child fragments I should add, are small and there can be 4 or 5 these on the screen at one time).
This has caused a few issues, namely having to create, and keep track of Unique IDs for the Fragment holders. (Which cause headaches when dealing with the Backstack as well as if any are in any sort of AdapterViews).
We're thinking of just rewriting these components to extend some sort of ViewGroup, likely FrameLayout or LinearLayout. We already do that anyway in some cases, but I was wondering if there are any disadvantages to doing it that way? (I must admit, I don't really see the big deal about Fragments... anything you can do with Fragments, you can do by creating a Custom View. Is this wrong?).
This is a bit of a reverse answer, explaining fragment use. In general you can do most things with Activities, but as the SDK supports fragments, many things will become more cumbersome (ViewPager is an example where fragment use is great).
The advantages (of fragments): code encapsulation, reusable chunks of UI.
The disadvantages (of fragments): more code (e.g. FragmentManager, FragmentTransaction).
Your original use of activities was good, it's not a case where I would have switched to fragments.
Let's say I designed a mobile phone app with two activities: ContactList and ContactDetails. So far so good, no reason to use fragments yet. If I wanted to support a larger device, it would behoove me to display both screens side by side. This is where fragments come in handy. In terms of exactly how to structure your activities/fragments, there's some good advice here:
https://developer.android.com/guide/practices/tablets-and-handsets.html#Fragments
Here are the important bits:
Multiple fragments, one activity:
Use one activity regardless of the
device size, but decide at runtime whether to combine fragments in the
layout (to create a multiple-pane design) or swap fragments (to create
a single-pane design).
Or...
Multiple fragments, multiple activities:
On a tablet, place multiple fragments in one activity; on a handset,
use separate activities to host each fragment. For example, when the
tablet design uses two fragments in an activity, use the same activity
for handsets, but supply an alternative layout that includes just the
first fragment. When running on a handset and you need to switch
fragments (such as when the user selects an item), start another
activity that hosts the second fragment.
.
The approach you choose
depends on your design and personal preferences. The first option (one
activity; swapping fragments) requires that you determine the screen
size at runtime and dynamically add each fragment as
appropriate—rather than declare the fragments in your activity's XML
layout—because you cannot remove a fragment from an activity if it's
been declared in the XML layout. When using the first technique, you
might also need to update the action bar each time the fragments
change, depending on what actions or navigation modes are available
for each fragment. In some cases, these factors might not affect your
design, so using one activity and swapping fragments might work well
(especially if your tablet design requires that you add fragments
dynamically anyway). Other times, however, dynamically swapping
fragments for your handset design can make your code more complicated,
because you must manage all the fragment combinations in the
activity's code (rather than use alternative layout resources to
define fragment combinations) and manage the back stack of fragments
yourself (rather than allow the normal activity stack to handle
back-navigation).
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.