I'm currently working on my first ever Android application and it's for my University. The structure of this app is that there 5 specific tabs each of which when inside that tab give you multiple options to perform other actions. So for instance when you click on tab 1, you are given the option to view a news feed, twitter feed, rss feed, etc. Tab 2 might give you information about different parts of the school, so there might be a button to go to Academics Info, another button for Financial Info, etc. I started on this about a month ago and was making good progress using ActivityGroups nested inside TabActivities. Then one day I found that both of those class had been deprecated and it was suggested that Fragments be used instead, so I restarted using Fragments. So my question is can anyone give me guidance on the overall structure behind what I'm trying to accomplish. Right now I have my basic tabs setup using fragments, but that doesn't allow me to have activities running inside my tabs, let alone the option for switching between separate activities all in their own respected tab.
I've been working for a very long time and I just need some guidance, so any help is appreciated. Thank you for your time and if you need any additional information please let me know. Thanks.
Im sure you've read the documentation on TabActivity. Bottom line is that the Activities you had for each of the tabs should be replaced by Fragments. An activity is now more of a superstructure which can contain multiple fragments each with their own views. The reason behind it is that it makes your application more modular. You could have the fragments as tabs on the phone, but next to eachother on bigger screens etc.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm building an android app which, although it has a completely different function, has a very similar UI to Instagram. There is a bottom bar with buttons for viewing timeline, posting (my app's content), checking notifications, and viewing your own profile.
I am a fourth year electrical engineering student, but I am relatively new to Android development. In order to teach myself more stuff faster, I went ahead and made a lot of the functions of my app (like viewing posts, profile, timeline, friends, etc.) their own activities with their own bottom bar (which are just buttons as of now). In doing this I have learned a lot about development and have built an app that, for what I have built out so far, functions as it's supposed to, but is not too fast or pretty. I realize this is probably not the best practice and I wanted to ask you all what you think a simple explanation of how to implement an Instagram-like UI would be? When I say Instagram-like I mainly mean: it includes a bottom bar; the app "preserves" where a user is, like if I'm viewing a friend from the timeline, then press the view profile button, then press the timeline again, then I will still be viewing my friend.
I have tried to read up as much as I could to tackle the redesign but I'm still a little fuzzy on the standard for doing something like this.Should I try TabHost (which is deprecated)? should each button represent an activity with swappable views (for example in IG I click a post on my timeline and it swaps to the pictures post view)? Should I associate an activity with each button and swap fragments based on where the user navigates? I realize this is an open ended question, and I hope it's not too vague for Stack Overflow, but I have thought about it a great deal, and I would appreciate the feedback of some more experienced developers! Thanks!
You can use the new TabLayout that is contained in the support design library along with a view pager to switch between your different fragments.
You can read about the TabLayout as well as some of the other things packed in to the design library here.
Reference for TabLayout
edit: In the comments I mentioned an analogy for you to think about how to use fragments vs. activities. In the interest of not spreading misinformation I'm gonna back peddle on what I said a little bit. You can absolutely use separate activities and switch between them using the tabs. So, the correct answer is kind of somewhere in the middle. The MainActivity would still hold the tablayout and manage the tab listener and switch between the tabs but you can set the content of the tablayout to hold the content a new activity. But you can do it with fragments as well and possibly more efficiently.
It really depends on the structure of your app and how deep it goes. If you only have 4 fragments and the information is centric to one work flow then you might choose to only use one activity with four fragments. It is really up to the developer on how to manage this.
Since fragments have come out, one philosophy has been if the space that you are using can be repurposed, that is, if you are working in the same box (the area above the tab bar of the instagram application for example), use a fragment. (Referencing from here). The camera tab is a good example of where to use an activity. The camera functionality represents an entirely different workflow than is seen when navigating feeds, pictures and profiles of the instagram application. So the feed might be one fragment, and the user profile another fragment but they are all being managed by the same activity and using the same content frame.
There are other answers posted in the reference I provided above which should help your understanding further.
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 was able to get a TabActivity working properly with multiple Activity's using ActivityGroup. However, I noticed a weird behavior. When clicking on multiple screens in one tab, going to another tab and navigating back to the original tab where user was already navigating several screens, the ActivityGroup goes back to the main Activity rather than the last visited one.
I was following the tutorial here:
http://ericharlow.blogspot.com/2010/09/experience-multiple-android-activities.html
Is there a work around for the ActivityGroup to prevent this kind of behavior?
I think it is better to look for a tutorial on Fragments.
I know this is not really the answer to your question, but I think it would be better to immediately use Fragments. This because Fragments are now recommended for Android development, and should be used as much as possible in favor of older technologies. And the stuff you want to do, are the perfect example of things that should now be done with Fragments.
The tutorial you are pointing to is from 2010, so that means that the technology used there will be rather old (I haven't read it though, but I can imagine it will). It is best if you want to develop something, to immediately use the latest technology, in this case: Fragments.
Some information on Fragments
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'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. :-)