I've read the official documentation with regards to designing apps for both phone and tablet here:
http://developer.android.com/guide/practices/screens_support.html
However, I'm unable to relate this to my use-case. My app is made of 4 main screens, all accessed using a view-pager which only works on fragments and as such, I have 4 top level fragments embedded inside my main FragmentActivity which are arranged in a tab layout structure with a view pager.
Question is: would it be possible to somehow achieve the different design for phone/tablet using fragments instead of activities? Based on the link above, if I was using fragments instead of activities for my top level items, it would be simple since I would simply instantiate a different layout with the same fragments but from what I understand, up until very recently, fragments were not able to include other fragments in them and since I would like my app to be accessible for older phones (I'm targeting SKD v14), I don't think I'm able to achieve this using different fragment layouts and composite fragments.
Ideally, I would love to be able to have the same code base and use the same fragments for both tablets and phones, albeit define separate layouts for each device, but I'm not sure on how to go about it.
Many thanks in advance,
you can display two fragments simultaneously on tablet whereas on phone you can show one fragment at a time-that is the main flexibility fragments provide.refer gmail app screenshots for phone and tablet and you will get better idea about what I am talking about-https://play.google.com/store/apps/details?id=com.google.android.gm.
If you dont have similar UI flow as gmail(click on UI element in one fragment to open other fragment to show details) I dont think using fragments will provide much benefits.
Related
I just read the Google lesson on fragments and I found it really useful. It shows clearly how to use fragments. I also checked this post
When to use and when not to use fragments in Android?
and with my research on the net too, I understood that fragments are useful when one needs to define multipane layout for tablets and single-pane layout for phones, but I was wondering if there are another cases in which we can use fragments for phones (apart from listviews) ?
Fragments are used like containers of activities.
Why do you need this? Again, it's simple.
Android 4 (ICS) supports both Smartphones and Tablets. This means the SAME application will be running on both a smartphone and a tablet, and they are likely to be very different.
Tablets has big screens, which will be empty or unused - unless you assign it properlly.
Thant means- Putting to activities on one fragment. like Contacts List, and Contact Info.
Smatpone will Display contact List, and on a touch- display the contact's Info.
On tablet, the user will still see the list and the info will be next to it.
Check this tutorial
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’m in the process of implementing a new version of an app and want it to move towards using fragments and thereby enabling it to be used on tablet devices.
I have read several approaches (e.g. How many Activities vs Fragments?) and the guidelines on developer.android.com (http://developer.android.com/guide/practices/tablets-and-handsets.html).
The Android Guide aims for one monolithic Activity for Tablets that deals with replacing fragments as needed whereas the handheld version does it by using multiple activities.
See example: http://developer.android.com/images/fundamentals/fragments.png
Why are these two approaches not combined?
Let’s say FragmentA from the above image is the menu of my application where I can select a different aspect and FragmentB is the corresponding Content for the selected item.
Tablet devices
If my application can be separated into different aspects that correspond to the items in the menu, wouldn’t it make more sense to encapsulate the functionality behind each menu item inside a different Activity instead of using one monolithic one?
Selecting an item in the menu would exchange Activity A by ActivityB/C/D/E. Whereas those are configured in the same way, in the sense that is has a menuFragment on the left and its content fragment on the right. Interactions in the contentFragment would replace it with different fragments and so on. But the functionality would be covered by the specific Activity that holds it. So I would not have one monolithic Activity, but smaller and more specific ones.
Handheld devices
Similar to the above, instead of using a different activity per ”screen” I could reuse ActivityA/B/C/D/E and their contentFragment in a singlePane-Layout by replacing it accordingly by specifying the singlePane-layout for handheld devices. One Activity manages one task with several fragments.
So I would end up with the same number of Activities for tablets and handheld devices that are configured the way to handle both cases a bit different. Activities would be neither gigantic and full of logic nor totally dumbed down, but somewhere in between.
Is there something wrong with this approach?
I’m currently thinking about how to move forward and this approach seems reasonable to me, but maybe there are things I have not considered that make it not the best choice.
For very long time, I think what is the reason of using fragment in Android if I just develop the application for Android Phone only but not 10.1.
Is it necessary to use fragment? Also, what is the usage of fragment,
I found that it may use for 'tab' and 'separate view'...
I really think it is very confusing. Can anyone explain briefly and give example?
From documentation
You can think of a fragment as a modular section of an activity, which
has its own lifecycle, receives its own input events, and which you
can add or remove while the activity is running (sort of like a "sub
activity" that you can reuse in different activities).
Some advantages are..
A particular UI part, once done in fragment, can be reused in
same/different activities.
You can separate different sections of UI, hence code will be neat,
and easy readable.
The ability of fragment to be able to reuse is very helpful when you are creating applications for different kind of android devices (phones, tablets). A well designed fragment can be just plugged into your UI hierarchy.
Fragments is a new concept introduced in 3.0 version.
The basic purpose of fragments is:
Fragments are designed to use the device UI space efficiently.
When you are writing an application in android, then some people can download it into phone, some into tablets. If you see the space in tablets it will be little bigger than phones. You should be able to use that space efficiently. But you can't keep writing different applications one targeting for phone, and other targeting for tablets. In order to do it efficiently, i.e writing only application that can fit well with all screen sizes, we use fragments concept.
fragments are designed as a reusable UI components between more than one activity.
Once you design a fragment, you can view it as a detachable independent unit, so that you can plug it into any activity where ever there is a space. That means you can reuse the code designed for a fragment.
Fragment you can think of it like a sub activity, which sits with in an activity and which contributes its own UI to the activity screen.
Fragments are always part of an activity. With out an activity, a fragment will not exist. So your fragment life cycle will always be affected by activity life cycle.
An activity can contain more than one fragment. Similarly a fragment can be re used in multiple activities.
If you use Fragment in your application, your apps will support all the device like small device, tablet and even google TV. In one .apk file, we will have different design for various devices.
This is the best Android tutorial that I've ever found. Section 21 covers fragments
Refer Here
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. :-)