My App (minimum API 14) uses an ActionBar with 3 tabs.
The tabs are:
i. enter data (approx 10 fragments)
ii. manage data (15 fragments)
iii. view data (8 fragments).
Each tab has a default fragment, but then has multiple fragments depending on user choices.
I would like the user to be able to swipe between the 3 tabs (by swiping the content) hence I need to use ViewPager and the compatibility library v4.
The advice I have picked up (after much research) is to use a MainActivity which hosts the ActionBar and tabs with fragments for the tab contents. But I'm worried about the number of fragments. Also some of the fragments need to use date and time pickers which means DialogFragments coming out of fragments. It's starting to get very complicated.
Does anyone see any problem with my using Activities instead of fragments for the tab contents?
Fragments act on the UI side just like activities except you can combine multiple together. So you don't need to create a different fragment based on user choices, you just need to change the fragment just like how you would change an activity dynamically.
Also if you want to use ViewPager, you are basically forced into using fragments.
The nice thing about fragments is that they are reusable, so most likely you only need a few fragments and then you can combine them in different ways for the different use cases. This also makes your tablet UI a lot easier to create.
For reference: http://developer.android.com/guide/components/fragments.html
Related
I used to have 3 activities with 3 layouts.
1. HomeActivity.java (activity_home.xml)
2. HelpActivity.java (activity_help.xml)
3. SettingsActivity.java (activity_settings.xml)
Whenever i had to open other activities, i used animated slide-in-out intents using overridePendingIntent. In this way, all the variables of HomeActivity stayed in itself and HelpActivity's variables/methods were in itself and same for SettingsActivity. I used onCreate() in these to perform some activity specific code. and, android:onClick="fetchSarcasm" from activity_home.xml was calling specified method in HomeActivity.java. So, there were no conflicts. All the normal things, that happen in an AndroidProject with 3 activities and used intents to switch to one another, were happening as i wanted.
But now, I wanted to migrate to ViewPager instead of slide-in-out intent transitions. In this way, there will be only one Activity with an XML of ViewPager. This ViewPager and its FragmentPagerAdapter gets the Pages from 3 classes extending Fragment with relative XML layouts.
I want to ask: Where do i write my Page Specific Code for onCreate(), layoutView's onClick="" and for onChangeListeners. Because, 3 classes extending Fragment do not have any Context or findViewById() and they do not respond to android:onClick="method" in different layouts.
Do i need to mix all that code of three activities into one containing ViewPager? If so, this makes ViewPager activity pretty heavy. and, writing if(page=2){ dothis(); } seems absurd for all pages at every code point. Any checkbox(view) that is in page 3, becomes null in other pages.
I know this might be a stupid question. I have spent almost 4 days trying to achieve something but i can't. Also, this is just my 2nd month in android, so i am new. I do not use Action Bars, Tabbed Bars or Navigation Drawers.
I am available on SO Chat too if you want to ask something more.
I just want to know how do i merge all the work i did when I was not using ViewPager.
If you're only reading the Preferences once for each Fragment, you can move your previous Activity.onCreate() logic to each Fragments onViewCreated() or onCreateView(). Read your shared Preferences there and set your Checkboxes accordingly.
Fragments inside a ViewPager aren't necessarily recreated on each page change. You can change how many Fragments are instantiated at a time with ViewPager.setOffscreenPageLimit(int).
Fragment Lifecycles explained
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.
In one app, I would like to use three activities with a swipe view with three tabs; each tab triggering an activity
(In the doc I have read about ViewPager and fragments, but it is for a different purpose); if it is possible how can i do that ?
if it is not, must i break my app in three app ?
Thank you.
Having activities in tabs has been deprecated as a technique for over five years.
Whether you use fragments or views for your ViewPager pages is up to you.
if it is not, must i break my app in three app ?
No, you can have multiple fragments or multiple views within one app.
Make one activity with three tabs and one ViewPager. Each tab then change fragments in the ViewPager
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'm trying to create a layout that has a stationary footer with activities that slide behind it. I've been told to use Fragments, but that would mean that I would have to convert my already existing Activities to Fragments - right? Here is a diagram of what I'm trying to achieve: http://i.imgur.com/K8Iao.jpg
What I think #TarunMaheshwari is trying to say is that instead of having 3 activities (eg. classes with extends activity), replace it with extends fragment (obviously there are other minor changes you might have to make for the code to work) and then create a main activity (with extends FragmentActivity) that has the static footer you want which can call on the 3 different fragments.
Recommended readings:
http://developer.android.com/guide/topics/fundamentals/fragments.html
http://android-developers.blogspot.ca/2011/02/android-30-fragments-api.html
I believe using fragments is the right solution for your app. However, from what I understand from your question and comments, you really want to avoid using them. To use activities instead of fragments, implement a Tab Layout with a Tab Host and Tab Widget as explained in this tutorial. This solution allows you to use the tabs to switch between activities.
To align the Tab Host to the bottom of the screen, have a look at this tutorial.