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.
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'm coming from the iOS world and need to port an app with the typical tabbar/navigation pattern to Android. The UI design is the client's decision, so I can't change it (I'd still like to hear from you if you think it's appropriate or not for Android).
So the idea of the app is the following:
3 Tabs are always shown on the bottom of the screen. Inside each tab there can be a hierarchy of screens, with the title and up-button showing in the action bar on the top.
How do I implement this in Android? Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity? How should the hardware back button behave? Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
As you can see I'm struggling with all these basic concepts and I'm very thankful for any tip that can help me to implement this navigation structure.
Edit:
Thanks to the competent answer of CommonsWare and looking deeper into it, I realise that I really should push the client to use an UI that's more suitable for the platform. (Also, I know I should use an Android device for some time to get used to the concepts, but I can't change that for now. So I'm sorry for these newbie questions).
The thing is, the app existed before as a web container app with an ugly jquery mobile UI with the above described UI elements. The idea is now to make the app navigation native with native animations, while keeping the content views in html/css/js inside webviews. So while it's possible to adapt each platform's UI principles, I cannot change the general structure of the app, which is: 3 different main entry points, and in each of them the content is navigated hierarchically. I've implemented that in iOS with a tabbar and navigation controllers which works great. The challenge is now to implement it in Android. To reassure that I'm on the right path and understood the points of CommonsWare correctly as well as to maybe receive more tips, I'm writing down what my thoughts on the steps involved:
As CommonsWare suggested, I could replace the tab idea with action buttons in the action bar, which will work well as there are only 3 of it. So it's appropriate to use action buttons for navigation? There will be an additional button for switching the language (Yes I know, usually I should pick the current language of the system, but in this particular app language switching is important and the user will switch it several times while using the app). To separate the navigation action buttons from the language switcher, which works on the current content and is a bit less important, I put the language switcher under the so-called "action overflow" (the 3 dots on the upper right corner).
Now there is an action bar button for each "tab", so far so good. But is there a way the user can tell on which "tab" he is? Or should I only show two action bar buttons at any given time, hiding the one he's currently "in"?
Each of these action bar buttons starts a new activity (with it's own action bar, right?). Inside such activity, the user can navigate hierarchically and back using the up button or back button. He can also use the hardware back button to go back to the last "tab"; would this be appropriate?
Every screen in the navigation hierarchy is a separate activity with a title and a webview.
In the end, to make the whole app compatible back with gingerbread, I would use the actionbarsherlock library, right?
3 Tabs are always shown on the bottom of the screen
That violates the Android design guidelines. On Android, tabs go at the top.
Inside each tab there can be a hierarchy of screens
Outside of a Web browser, I truly detest this navigation concept.
Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity?
You do not appear to have more than one activity in your proposed design.
Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
And this is one of the reasons why I truly detest in-tab navigation. Tabs are for presentation of content, not as a navigable container in their own right.
should it mirror the up-button's functionality?
Since you do not appear to have more than one activity, it is unclear to me that you even have an up button.
How do I implement this in Android?
Ideally, you dump the tabs and use action bar items to switch between the different navigable areas, each of which would be its own activity. In that case, back (and to a lesser extent up) will flow more naturally.
If you had more than three tabs, you might go with the navigation drawer pattern, with the navigable areas each having an entry in the drawer. Three, though, would make the drawer look rather empty.
There is plenty more on app structure in the Android design guidelines that can help.
The UI design is the client's decision, so I can't change it
The objective of an app is to allow the users to accomplish their objective. Using design patterns native to a platform help in this regard, by allowing the users' existing experience to guide them in the use of the new app. This is not to say that true innovation beyond the guidelines is inappropriate, but it requires experience and deft hand.
Your client appears to be saying, "hey, this one firm came up with a design pattern for their platform, so therefore let's use it everywhere, as we want a consistent UI design". The problem is that nobody cares about consistency between platforms except them. Few people own mobile devices from multiple platforms, let alone use the same app on both, let alone expect the same UI design on both. Certainly, design touches (e.g., color scheme) could be similar, and the objectives of the app will be similar if not identical. But the delivery of that functionality should use design metaphors and patterns that are native to each platform, as the user is far more important than is your client.
(and if your client says "well, we are the users", because this is an internal-use-only enterprise app, kindly explain to them the concept of the passage of time, introduce them to the notion of employee turnover, and point out that they won't be the users all that long compared to the possible lifetime of the app)
Your client, if they ran a US-based car rental agency, would argue that their firm should rent left-hand-drive cars in the UK, for a consistent UI experience, despite all the accidents that will cause in a left-hand-traffic country.
Now, let's pretend for a moment that you need to write this app following their UI design anyway. Hostages are being held at gunpoint, somebody has a nuke on a hair trigger, the bad guy is demanding the app, the clock is ticking, you're Kiefer Sutherland, and so on.
(and if you really are Kiefer Sutherland, ummm... hi!)
You will wind up with a single activity for this core UI. Ancillary stuff (e.g., preferences, help) would be separate activities, but the three-tabs-to-rule-them-all UI would be in one activity.
The tabs themselves probably would use a FragmentTabHost, perhaps with modifications to better support tabs on the bottom. This is not a common choice, but it's the best fit. ViewPager and a tabbed indicator would be another possibility, if the client does not consider a horizontal swipe to change tabs to be "the devil's gesture" or something. Action bar tabs are at the top and are not always tabs, as they sometimes convert to drop-down navigation in certain screen size and orientation combinations.
Each tab would be a fragment and most likely would use nested fragments for the in-tab navigation between panes of content. Again, there are other possibilities (e.g., lots of hiding and showing of widgets within a single fragment to handle the navigation), but I think you'll go crazy trying to manage all of that.
With respect to the BACK button, without knowing the context of the tabs, my gut instinct would be to follow the tabbed browser metaphor of "BACK is local to a tab". I think that you'll need to manage this manually, unless it magically works because you are using nested fragments, and I don't think that's the case. When you are at the beginning (nested) fragment for a tab, and the user presses BACK, exit the activity.
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.
I have a hard time trying to come with a good and acceptable layout for an activity for a tablet, but I'm not sure that if my design is compatible with Google's design guidelines.
In short: my application receives a network sniffer log file and shows statistics on different features on the data. For example, traffic over time, PM over time, show the traffic as a time line, different graphs, pie charts etc.
The first thing comes to mind for a design for this activity is a multi-pane layout (like Gmail's for tablets). The first pane would be the different features specified above, the second would have controls on the third one (which would display a graph) to filter different data, colorize and other things and settings.
The problem is, the second pane is not a list that opens a content (like in Gmail), but a pane that controls the third one.
My solution for this is to create just a two-pane layout: Only the second one (with the controls) and of course the third one with the graphs. The list of the features would be on a navigation drawer that the user would have to slide in order to switch to another feature.
Is this design compatible with Google's design guidelines? Is it logical for the user?
I don't recommend using the navigation drawer for tablets, at least not in landscape mode. Three panels should work fine and you can use the navigation drawer for portrait mode only.
Android design methodology is flexible so instead of trying to use the latest design patterns try figuring out what best suits your data.
Anyway, a good example for an app displaying content in 3 different panels is the Android Wordpress app. Check it out here: https://play.google.com/store/apps/details?id=org.wordpress.android
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.