I am coming from iOS and working to port an iOS app on android. In iOS there is the storyboard where you can connect different view (activities) and embed them into tab bars and navigation bars. I am having an issue to understand what is the best way to implement bottom navigation in android...
Let say I have 3 bottom navigation items with the following
tab1
page1.1
page1.2
tab2
page2.1
page2.2
page2.3
tab3
page3.1
page3.2
page3.3
As an example in tab1 I have page1.1. Then let say I have a button in page1.1 which bring me in page1.2. If I go back from page1.2 I want to go back to page1.1. Same story for page2.1, I can go to page 2.2 and from page2.2 I can go to page2.3. I also want to go from page3.2 to page 1.2
I have read fragments are the best way to do it (each page.x is to become a different fragment with a different layout) but it does not seem very easy. I have also read I can use activities but many suggest not to use it
What do you recommend that I focus on? Are there any other solution to consider on top of fragment and activities? Thanks
You should use Fragments with a Single Activity. If you don't, you will have to copy/include one bottom bar in multiple Activities. It might be useful in some cases however when Activity is switched, your bar will redraw which might turn out to be a bad user experience.
I have read fragments are the best way to do it (each page.x is to become a different fragment with a different layout) but it does not seem very easy
Using Fragments might actually make it easier than if you use Activities. If you use Fragments, you can have one Activity be in control of every fragment that is being displayed, meaning that you can control navigation based on which fragment is being shown. This way, you can handle some special scenarios that do not fall into usual navigation behavior.
Doing the same in Activities would be a little more difficult since you'd have to continuously pass around data in Intents and it would be difficult to control the behavior since your logic will be spread across Activities.
What do you recommend that I focus on? Are there any other solution to consider on top of fragment and activities?
These two are only recommended solutions. If some of your UI elements are same in all pages while some part of it is changed constantly, then its best to use Fragments with single Activity. For screens that are completely different or that are not part of your navigation flow, you add more Activities for them instead of Fragments.
For example, You can use Fragments in One Activity with Bottom Navigation Bar, but for settings screen or profile screen, you should make separate Activites.
Related
Is it possible to build up an architecture like this with fragments:
Navigation drawer showing the main menu and then when clicking one of the menu items an ordinary combo of list/detail is shown (so far so good, all tutorials explain this). But what if I want a button on the detailed fragment to show a second combo of list/detail fragments, which should not be reached through the Navigation Drawer?
As I have implemented it now, one fragment instatiates the next, which is wrong according to the guides (fragments should always communicate through an activity). But it works fine as long as the user is clicking deeper into the app. The issue comes when he starts to use navigate back, because all the UIs then start to be laid on top of each other.
I wouldn't. Fragments aren't 100 percent consistent across all versions of Android, unless you're using the support library. Even then- nested fragments have always been a bit broken. They weren't even supported at first. The more levels of nesting you add, the less likely it is to work as expected. I wouldn't add more than 2 levels of fragments, and I'd try hard to keep it to 0-1.
I've recently been looking into the navigation system that Android uses with as intention to port my iOS app that uses an UITabBarController containing multiple UINavigationControllers. To replace the tab bar (which is not available on Android) I settled on using the built in DrawerLayout.
From what I've read, navigation in Android is generally done by creating an Intent, providing it with extras and then just replacing the current activity. This automatically makes sure the back button works, and optionally the back button in the top left if enabled.
However, I am not sure how to implement this way of navigation with the navigation drawer. The tutorial tells me to create a DrawerLayout containing a FrameLayout and a ListLayout where the FrameLayout will contain the actual application and the ListLayout will contain the navigation. This would mean that when I use the method described above to "navigate", it would replace the activity and thus removing the drawer.
What would be the best way to implement what I want (basic navigation with back button support while maintaining a global drawer navigation menu)? The possible options I can come up with is always keeping the same activity and dynamically replacing the FrameLayout, but that would mean a lot of boilerplate to render and possibly a hack to support the back button (and there would be no animations :(). The other option would be to just render the drawer on every activity (via subclassing or something), but that would mean that if the user navigates a lot the back button "stack" would become quite large.
I have tried to explain what I need in as much detail as possible, but it is quite hard to explain the concept. Basically, I want something similar to the UINavigationControllers in the UITabBarController.
You can either have one Activity with one NavigationDrawer and present the user with different views by switching Fragments back and forth within that one Activity. You would use the FragmentManager to switch between different Fragments.
Or you can use multiple Activities that all have a NavigationDrawer.
Second option might sound more difficult but it really isn't. You create a base Activity that all your Activities inherit from and all let them have their own NavigationDrawer, no problem.
Sure there's something in between or something completely different, but that's the most straightforward approaches I can think of.
The tutorial you've probably used (the one with the planets) is imho a bit misleading because it assumes a very basic app structure. If you have only little different 'screens' that might work, for a very complex application it's not suitable (again, in my opinion).
I've always opted for the second option because handling the navigation / backstack is just easier with Activities / Intents.
There's loads of different flags that you can set to your Intent to influence their navigation behaviour.
Also see this and that documentation. These documents might have been written when the NavigationDrawer pattern was not all that common but they are still useful.
I'm starting to build my new application and I'm trying to go the right way from the start to make my life easier later in maintaining and extending the application.
I saw applications that are probably built in fragments only. Of course, there is a host activity that hosts the fragments, but everything else is in fragments.
I suppose they have a Main activity that has the action bar and a layout to host the content in it. Everything else, including different screens such as Login, Home, Settings, Profile, ... is in fragments.
When we click on an item in the navigation drawer, for example on the Settings button, they simply change the content fragment, instead of launching a new activity for Settings.
Is that a good idea to build the main screens all in fragments, and just have one activity to display them?
Yes, it's a good idea to split up your UI into Fragments.
Some advantages:
-reuse in multiple Activities
-self-contained, modular UI
-rearrange fragments
Cons:
-it's a bit more work
-slightly higher learning curve
There are few similar questions on stackoverlow, but I haven't find clear explanation at any of the answers how to implement Action Bar pattern for more complex/multiple activities apps.
As I understand, there are two options to do this:
1.) implement multiple activities and in each of them implement/include action bar
--> problem with this is that when ever you lunch new activity, although it has the same looking action bar, it has that transition, and jumps through the screen, so it's obvious it's a new "window",new separate screen, and it kills that feeling of single app navigation frame.
2.) Use single FragmentActivity, with action bar within, and with multiple fragments that inflate content frame.
--> this is pretty nice implementation of action bar pattern, but problem is that it goes against google's recommendation that one fragment should be in one activity in the case of phone. Or it doesn't? From the "look and feel" I would say that Gmail app is done mostly this way.
3.) TabActivity - which is deprecated.
For the second solution (single activity, multiple fragments) I'm concerned if there would be any performance issue in the future? How does android handle memory in that case? will it kill inactive fragments to free space just like it does with the activities? Or it will kill the whole app, or user phone will be overloaded?
Maybe I'm missing something there, but I found implementing android navigation patterns and usage of fragments very confusing :/
Is there any reason against having one activity with multiple fragments on the phone?
(there would be cca 5-6 fragments, with nested fragments in some of them)
First of all, you might think this question and this answer to be useful.
Though you are talking about the actionbar, the real question is about the pattern of ONE activity with multiple fragments or MULTIPLE activities. As the former link states, though the "oversimplified tutorial" suggests of starting another activity to display item's content in Phone situation, this will probably cause some duplicated logic or codes.
Finally, using "FragmentActivity with multiple fragments" is recommended. As it is against the the google's recommendation, Stephen Asherson says and I quote: " do not think of it as being forced to use many activities. Think of it as having the opportunity to split your code into many fragments, and saving memory when using them".
PS. just for your information, if you change the activity's actionbar in switching fragments, you might want to do something to correctly handle the UI change when "back" key is pressed and backstack is changed. Commonly, override the onbackstackchanged() function to handle the UI.
Are there any patterns on how to handle UI Transitions in Android Activities vs Fragments? I am currently looking into a UI that has at most 3 columns in Landscape.
I would like the UI to start with 1 column all the way across the screen and then on selection of something move in the second column and then on clicking on something in the second fade in the 3rd on tablets and phones and fade out the 1st column on phones.
I am wondering when I should do this as an Activity transition and when I should just use Fragments with Views that Appear. As far as I have read fragments can be moved over to other activities so my choice is either implement Activities with static column layouts that then transition taking the fragments with them or have one Activity with all 3 columns and have the Activity manage the Appearing of the Fragments. Both approaches could work but I was interested in pros and cons from as many angles for both solutions.
There are two questions similar to what I am asking but don't quite answer mine
Two panel UI with Fragments vs Separate activities
Android Honeycomb: layout problem - hide/show FrameLayouts
Fragments can seem like more code up front (since you're putting a view in a fragment, and a fragment in an Activity, instead of just a view in an Activity), but they're great at saving you from headaches in just this kind of situation- Definitely go with Fragments. They even handle the transitions for you.
We have some sample code called "Honeycomb Gallery" you can take a look at here, which has a two-column-plus-actionbar layout, and the ability to show/hide the leftmost column. This should give you a good head start in figuring out how to do layout for multiple fragments and show/hide them.
FYI, one important trade-off to using multiple fragments in an Activity instead of multiple Activities, is that fragments don't directly respond to intents - For instance, if you had a note-taking app where "View Note" page was an Activity, and you changed it so that there was a "view note" Fragment inside the main Activity, then you'd have to set it up such that the main Activity received a note ID AND a note action (create, view, edit, whatever) in the Intent, as opposed to just having the "view note" activity receive the note ID in the Intent. The main Activity would then need to set up the fragments on the page accordingly. Not a huge deal, but if external accessibility to various parts of your application via Intent is important, then it might be easier to break your app out into a few Activities, as well as use fragments to represent the individual components.
Based on the page The Android 3.0 Fragments API, an Activity is stand alone while a fragment can be though of as as a mini-Activity, which must be hosted within an actual Activity.
It goes on to say that the introduction of the Fragment API gave the android developers the opportunity to address many of the pain points developers hit with Activities, so in Android 3.0 the utility of Fragment extends far beyond just adjusting for different screens:
I think that using a single activity for an app is not necessarily a wrong decision, just a matter of style. It is a decision that you should make based on what you are trying to accomplish.
However, the introduction of Fragments was seen to solve real world problems. Based on that alone, I would recommend that you writing some "Proof of Concept" code and evaluate the results. At this time, this may be the only real world test that will matter
Use Activities for Full Screen
Use Fragments for Part of or no Screen (but not a service)
In my main application, there is on-screen tabs in a horizontal scroll-view I wanted to persist across multiple sections of the app. Sections include
News,Photos,Videos,Schedule etc. All single-user focusable tasks.
The main Application that houses it all is a application, and the tabs are just a view which call the fragment Manager.
However, I use Activities for complicated user activities deeper in the application. E.g. if someone plays a video, views a item detail page and the photo-gallery/slideshow sections, because they are all full screen components.
There is no need to show/hide fragments when transitioning to full screen because the activity stack handles everything you want to do it quickly and easily, and keep your code minimal and clean.
So I have Activity -> houses fragments -> launch full screen Activities for special commands.