I'm having serious problems getting three layers of nested tabs to work in an app that runs from Android 2.1 up and looks like Android 4 (uses support library fragments).
The goal
App should have an ActionBar (works, currenly uses ActionBarSherlock)
3 fixed tabs on the main screen, that don't move into the ActionBar even if the screen is large enough. The second of these tabs contains...
About 4 tabs that were loaded from a server when the user logged in the first time. Each of these contains
About 10 swipable tabs (like in the Play Store) that were loaded from a server when the user logged in the first time. My idea here is to use ViewPagerIndicator, since that library is written by the same guy who ActionBarSherlock which should keep problems down to a minimum. But I'm open to ideas here). Each of these swipable tabs contains something that is currently a Fragment, but could be changed.
The Problem
When this was an Android 2 app, it simply used nested TabActivities, but these don't work with all the Android 4 stuff. I don't understand how to do this probably, especially the "you can't nest fragments" restriction is causing me headaches. Also, it seems that you can only use one FragmentManager per Activity, so my idea to have one in each of the second row tabs didn't work (All except for the first tab remained empty).
How to do this the right way?
(Please understand that "Use a different GUI design" is not an option since this is what the customer asked for and he won't reconsider)
PagerAdapter does not require Fragments as children. You can inflate/manage your own custom views in there. So you could continue to use nested TabActivities. Or, you could put Fragments at the top-level, and manage your own Views in the bottom-level ViewPager.
You could also, theoretically, use ViewFlipper if you want to keep the Fragments in the ViewPager. You'll have to write your own LinearLayout with Buttons as tabs, but this is easy. If you're looking for the Holo look, simply set the style to the ones found in ABS.
Another option is to use TabHost without using the TabActivity. You can even use it with Fragments. See the example here.
Also note: If you're looking for the Google Play style of ViewPagerIndicator, thats now inlcuded in the Support package: PagerTitleStrip.
I'd imagine that your best option is to use Fragments as the top-level, as this will help with memory consumption.
That said,
I must say that this sounds like a terrible UI pattern. Even worse, we are talking about a lot of inflated views in one Activity. You may run into memory issues here, depending on whats being shown. I suggest heavy usage of ViewStubs and recycling if you keep the ViewPager at the bottom.
Keep trying to push the client toward using the ActionBar spinner pattern for top-level (main 3 tabs), or even consider the fancy sliding drawer pattern. Perhaps that smooth animation could be enough to sway their opinion.
Refer them to the official design website, and show examples of popular navigation patterns like the ones found in Gmail, YouTube, Google+, Evernote, etc. I recently dealt with a client requesting the exact-same pattern you describe, and after weeks of pushing was able to convince them that more-than` 2 layers of tabs is unacceptable.
You can also show them my Wall of Shame Google+ page, highlighting bad design patterns used in popular Android apps: Android UI Anti-Patterns. :-)
Related
From what I understand, and activity is equivalent to a "page" in a web app.
For example, the list view would be one activity, edit view another activity, and add view a third activity.
While this works as expected, android activities seem to operate as individual apps--the action bar is different for each activity and so are the menus.
Is my usage of activities above correct or should I be using some other mechanism such as swapping out layouts and views?
Fragments are a core part of activities - not that much different. The use of fragments comes since Honeycomb 3.0 and the idea is an option to split the screen in several fragments at once. For example if you look at the gmail app for a tablet - you have one fragment on the left dealing with navigation and then the next fragment on the right is the list of emails.
On a mobile device, viewing area is limited, so you it could be said that fragments sort of behave like an activity - you interact with one fragment, which triggers another and so on and so fort. But in the end you always reference a super activity of each of these fragments - for example when you want to access the context.
So if you just want to wrap web pages in WebViews, stick with activities. If your scenario might involve developing for both tablets and phones, then go for the fragments.
Alternatively, you can read about the design philosophies of both here:
http://developer.android.com/guide/components/fragments.html
Good luck!
Fragments are to be used when you have common feature across multiple activities. From my perspective you should use individual activities as there will be back-end code to support (fetch and validate data, i.e. business logic). This way you have more modular code. Fragments is a new feature from v3.0.
From what I know, Fragments would be a good option to be able use different configurations/real estates on different devices. For example, if you are on a device with big real estate like Tablets or TVs you can display more content in a single activity, on the other hand for a devices with smaller real estate you can show content based on a progressive manner.
See this: http://developer.android.com/training/multiscreen/adaptui.html
Note that Fragments are supported only on devices running Android 3.0, so you might have to use Support Fragments (See: https://stackoverflow.com/a/6528757/713778)
But Again it depends on your specific needs. I am not sure what your exact use case is, but I would suggest you to watch some Android design in Action for some examples to improve your design and make your app "User Centric" (See: https://www.youtube.com/playlist?list=PLWz5rJ2EKKc8j2B95zGMb8muZvrIy-wcF)
I recently came across this https://www.youtube.com/playlist?list=PLWz5rJ2EKKc-riD21lnOjVYBqSkNII3_k seems provide an in-depth analysis on User Experience.
I would recommend using fragment for web like views. Fragments are pretty snappy compared to activities and reusable.
But before you start, make sure to fragments are good fit for your requirements since they are supported from android 3.0.
You can declare fragments from xml itself or you can create frame layout and add that view in the code itself.
http://www.c-sharpcorner.com/UploadFile/2fd686/fragments/
The above link has a good example tabhost.
I've developed like 5 Android applications using only Activities (and from time to time Fragments for ViewPagers for instance).
I have to develop a new application targeting Android ICS for tablets and handsets, with a very simple and static menu bar on the top (like 4 buttons on a single line). I don't need any single-pane / multi-pane layout depending on if the user has a handset or a tablet.
Each button of the menu bar will open a different screen, always keeping the menu bar on the top of the application. My question is if using Fragments for each screen instead of Activities is the proper way to achieve this.
Apart from avoiding some code duplication (basically the behavior of the menu bar), I don't see any advantage of using Fragments.
EDIT
First of all thanks a lot for answering my question so precisely and so fast.
Your answers have been very helpful for me : for instance I was afraid of having just one single Activity one my app, but I now understand it's rather a good thing.
You wanted to know what my application will actually do, so... there will be like 4 different screens : a News screen, a Videos screen (with live streaming video players), a Search for past videos screen and a basic Contact screen.
My question is if using Fragments for each screen instead of
Activities is the proper way to achieve this.
Your scenario is pretty simple and you could go either way. I would choose fragments over activities mainly because:
always keeping the menu bar on the top of the application. - With a fragment based app you could have a smoother transition between the various screen(and it will also allow you to keep in place the buttons bar).
easier communication between the various screens of the app as you'll have all the fragments in one parent Activity(but as I don't know what your app does I'm not sure this is something relevant).
Your app may be small now but you may get new ideas/requests to improve it in the future and this may be an easier task to do when your app is composed from fragments(which should be designed as loosely coupled components). Again, not knowing what your app does, this may or not may be relevant. An example scenario would be the need(in the future) to insert a ViewPager for the content of the app(so you allow the user to also swipe to a page not only click a Button). Using fragments this would be very simple as you need to setup the ViewPager and insert the content fragments, using Activities would mean a lot more refactoring.
I've been slowly porting my iOS App to Android so I can take my time and make sure that it functions correctly and I'm now at the part where I need to create a TabBarController like environment. I've been searching for days and have come across numerous examples but with each example there's a problem.
First, most examples refer to using a TabActivity, which when I just checked is deprecated and can't be used. The one's that don't use TabActivity either use Fragments (sometimes with an Action Bar) or a Tab Host. It looks like Fragments is the way to go, but then how to you support older devices (from the Android website over 50% of there users are still on API 10).
Basically what I need to set up is a Tabbed environment that will let each tab load a new Activity, and then each of those Activities will have their own navigation based hierarchy as well so I'm trying to see what is the best option to pursue and if anyone has seen some examples that can help.
I've found 4 tutorials so far that have fragments and different activities for each Tab, so I'm going to look into those now but just wanted to see if any other developers that have already come across and issue like this did to work with the compatibility issues with older devices.
You can use Fragments all the way down to API 4 using the Support Library. I'd use a single Activity with multiple Fragments in ActionBar tabs, though you might need to do it with TabHost to support lower APIs.
I have been browsing the web for a while now and looking at different examples of how to implement a tab bar.
The problem I am having is deciding the correct approach to creating this feature. The option that seems most used is to have one main activity called MainActivity or something and using fragments as the tabs. This is all well and good and I have created an application like this fine.
The problem I am having is I am in two minds as to whether this is the right way to go about it as coming from an iOS development background it just doesn't seem right due to these tabs having different functions.
Any pointers would be great.
EDIT I have also looked into ActionBarSherlock but couldn't get to use it in a project as it kept coming up with errors and I couldn't find a thread that sorted the problems I was having out.
Disco
You should be using fragments, yes. There is an example of how to do it here: http://developer.android.com/guide/topics/ui/actionbar.html#Tabs
This "only" works with Tabs that are part of your Actionbar, though. Shouldn't be too much of a problem, because they usually should be part of your Actionbar. You can also manually move the tabs if you're not content with their location, or roll your own buttons that look like tabs.
Keep in mind that tabs in Android aren't quite the same beast as the tab bar is in iOS. They look similar and behave similar, but there are subtle conceptual differences in how they are supposed to be used. Don't use them for your basic app navigation, but rather for switching between similar "things".
If you want to employ this on device pre-3.0 though, you will have to use ActionBarSherlock. It does work fine and we're using it in several projects, so if you're having problems integrating it I suggest creating a new question for that, I'll be happy to help.
Could somebody please explain the exact advantages of using Fragments? In what cases should we use Fragments?
For what I understand, this framework:
Helps reuse existing code - if I implement functionality in a Fragment, then it's relatively easy to display this fragment in multiple parts of my app, when the functionality is needed.
Helps dealing with multiple screen sizes - a device with a huge screen may be able to display multiple fragments at once, and for smaller devices I can display the fragments in separate Activities.
Is there more to this framework?
Edit:
I've been using Fragments quite extensively in a larger project for 3.0 tablets. To me the greatest advantage was that using fragments I could break up the logic that would go in a single, monolithic Activity into multiple, smaller Fragments. Big screens mean huge Activities, difficult to read, understand (especially to new team members), develop and maintain. Fragments certainly helped in this matter.
Is there more to this framework?
Animated effects available when dynamically adding and removing fragments from the screen
Automatic BACK stack management, so the BACK button can remove dynamically-added fragments before eventually exiting the activity
Integration with the action bar for tabs, as a replacement for TabHost
Integration with the action bar for "list"-based navigation (really a Spinner in the action bar, toggling between different fragments)
Somewhat easier handling of configuration changes courtesy of setRetainInstance(true)
Also, responding to #Jim Blackler:
I share your confusion, since it's always been easy to customize Views which seems (to me) to solve all the same problems.
Everything offered by fragments can, by definition, be done using Views, simply because fragments are built on top of the view framework. However, fragments make more complicated scenarios involving dynamic fragments a bit easier IMHO.
Moreover, fragments in conjunction with the action bar seem quite likely to be a long-term area of attention for Google, meaning I expect a fair amount of additional work in this area over the next 2-3 releases.