I'm about to make my first Android application and I am currently reading about activities and fragments. I intend to use the Lollipop navigation drawer feature to load different screens in my application for different features. Like settings, About, Add new x, browse x, etc. Should my nav drawer be loading different activities for each item click or loading a new fragment?
All my screens will have the same style associated with them, but will have obviously much different content.
If I load a new activity, do I "lose" the nav drawer to the side? or is it always present as I want it to be accessible from any screen in the application.
I am quite unfamiliar with the Android system so far, but no matter what I choose do I need to use an intent to launch either of these. A real lay mans explanation would be greatly appreciated.
Thanks
EDIT: Within one of my screens I hope to use a tab system and have it change.
This is a mockup I have designed, as you can see I would like the nav drawer to be used from this screen but also allow the switching of 3 different tabs, within the Add new timetable screen.
How would I go about having a tab at the top and then 3 different (linked) screens under it. This would be the deepest level I would go. Every other screen would just be one screen, no tabs.
Activity typically takes the whole screen, so yes, if you launch an Activity, you will temporarily "lose" everything that's placed in other activities.
Fragments, on the other hand, can be stuffed to smaller areas, and you can have several fragments on the screen at once.
Related
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.
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
I'm trying to design an application where the main mode of navigation through the application's several primary screens uses Tabs. I've basically copied the approach shown in the tutorial here: http://www.androidhive.info/2013/10/android-tab-layout-with-swipeable-views-1/
However, on some of these screens there are clickable elements that are supposed to kick off a full-screen page (the tabs should no longer at the top of the page). I've been able to get this working by creating a new activity for the new screen, but I believe I want to use a fragment for the new screen because in a tablet layout, I want the new screen to appear beside the main screen rather than replacing it. I haven't been successful doing this. If anyone can give examples or pointers on how to get a single activity to run fragments with tab-based navigation and other fragments that that don't have the tab navigation.
In a similar vein, I also have a settings screen accessible from the Options Menu. Are settings screens like this typically done as activities or fragments?
Thanks in advance.
You have to design your application in two ways.
Firstly you should know if you are running big device (tablet) or smaller one (smartphone).
You could make that by preparing two different layouts, one layout in layouts resource folder for smartphone and second layout in layout-xlarge resource folder for bigger devices.
In smaller layout make only one container for one fragment (list fragment for example). In bigger layout in layout-xlarge folder you coul have two containers one for fragment with list and second for fragment with content.
In onCreate method you could see if you are using multi pane layout or not.
If your secod pane in bigger layout is for example R.id.right_panel. You just make findViewById(R.id.right_panel) and if this is null, you know that you are not running multi pane.
Now if you are in multi pane, pressing item on the list should notify activity, and activity should change/replace right fragment with another one.
If you are not in multi pane, pressing item on the list should open new activity with only one fragment of content.
There are many tutorials of this of simmilar solutions like link or link
Regards
Sorry, I know that this topic has been covered a bit. I've read the related posts and am still a bit confused. I am working on an app that while the prototype will have 3 main screens, it will eventually have dozens. Each screen will present either dynmically changing status or take user input. To visualize, it is required to be laid out similar to how MS Word or a typical PC is. It has a status bar at the top and a navigation bar at the bottom that is common to all screens (slight tweaks for some screens, like different icons) in the middle is what I would call a view pane that needs to be updated with a applicable layout.
The status, nav bar, and each screen are defined in their own layout xml file. For my first swag at it I just used a ViewFlipper and loaded the 3 screen layouts into it. However that means that currently I have one main Activity which will not be maintainable as I continue to add screens.
It feels right to me that each screen layout should have an associated Activity class that understands how to control that screen. I need to figure out how to load that into the center pane dynamically. However I thought I read in another post that using multiple Activities can be a CPU and RAM drain.
Currently I tried making one of the screens it's own Activity and kick that off from the main Activity by creating an Intent and than calling startActivity. However that causes the new screen Activity to reside on top of the main Activity. The interesting thing is that then pressing the back button dismissed that activity and returns me to the main.
So far I haven't figured out how to setup having a different Activity control what happens in the center pane.
If I continue down the multiple Activity path, should my main Activity be inheriting from ActivityGroup?
Are using View classes more applicable in this case?
I know this has been a long post. I'd appreciate any advice.
Thanks!
CB
As you noticed, Android will implicitly track a stack of started activities in a task, and the 'back' button ends the top one, reactivating the next one down. I would advise you to think about which kinds of things the user might expect the back button to do, and make it so that activities are separated along those lines.
I haven't played with ActivityGroup so I can't advise you there. If you go with completely separate activities, you can have them all use the same "shell" content view with the common nav/status bar. Have a superclass or utility class handle populating and managing that from there. Then use a a LayoutInflater (you can call getLayoutInflater()) to fill in the middle with your Activity-specific view.
If you want one of the activities to have multiple screens, you might still end up with a ViewFlipper in the center slot. Again, you want to have an Activity transition wherever you want the user to be able to go "back"; that also means you may NOT want to have a change of activities in cases where screens are closely related or part of the same logical thing-being-done. (You can override the back button's behavior, but unless you have a good reason to, it's best to just arrange the app so that Android's basic setup helps your app's UI rather than working at cross purposes.)
If you want to use activities in the fashion you talked about, you might look into using a tab activity. It actually works in the way you want, you just need to hide the tab widget and put your navigation bar there instead. Or, you could go a little deeper and make you own similar tab-like ActivityGroup like Walter mentioned if you have more time.
You could use a view pager with fragments to accomplish the flip between the different views but still allow your activity to have full control over it. The activity can control the menus while the fragment controls your viewing area. This way your back button will properly dismiss the activity containing all pages related to the activity instead of walking down the stack.