There are many implementations of facebook app-like sliding menu, which are mentioned in that question.
Some of them, which implementation I checked, are using one activity for showing menu and data. When user selects item from menu no new activity is start. Thus, one activity is using for many part of the program, showing different data in one view.
IMHO, it could be messy to use one activity for all. So, I'm thinking of new plan:
Add menu to all activities;
When user select item in menu, close(pop/hide) current activity and start (push/show) activity, which is related to selected item.
Any ideas to implement such behavior?
I'm way to lazy to read through all those answers in the mentioned thread and check all provided libraries.
A good sliding menu library which works properly with Fragments is SlidingMenu
Also you should take a look at the documentation on Activities, Intents (the flags you can set to them) and how their life cycles are managed cause you seem to mix up some things.
Related
I want to write a clean, modern app. I've created several of apps and now have a simple question.
I want to create main menu to navigate app like on screen (not option menu / settings menu).
Should I create it in MainActivity of app, or is there a better design patterns where should it be store?
Is it good idea to create menu like this? Is it a good UI concept? I have to make an app, where user choose between 4 different activities, so I guess that is the best way?
look into what a fragment is. have one main activity who's job is to load other fragments as the user clicks. So having the main menu itself in the mainActivity is ok but when the user clicks it should load another fragment to display the results.
I don't see anything wrong with creating a menu like this. Some users with smaller screens might have to scroll through unless you can make the boxes smaller for those devices. Or add a scrollview.
if your talking about clean architecture thats a huge other story and you can look into model view presenter architecture.
UPDATE: its recommended to user fragment for this instead of activity. Fragments allow for reusability. So if some of your screens have the same basic behavior you can re-use a fragment. If you think there not going to look alike at all you could just use all activities i suppose. I've used both ways.
You might run into a case where when the device changes orientation you want to show a master/detail view or some other kind of view. Fragments come in handely for this.
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 have seen a few questions raised on this topic (for e.g.: https://github.com/jfeinstein10/SlidingMenu/issues/5) but I am still unclear. I hope somebody can clarify this.
Context:
See https://github.com/jfeinstein10/SlidingMenu
I have an android app that organizes screens by activities and fragments (i.e.) each screen is an activity containing one or more fragments.
The new requirement is to add a sliding menu (similar to what this library provides).
Issue:
It appears from the examples and discussion that the right model would be to have just 1 MAIN ACTIVITY that will then switch in/out fragments belonging to the different screens. In fact the author mentions in the above thread: "If you were to launch Activities based upon the list selection, then you would not have the behavior where you swap the views that you're talking about. " and also "You can't put an Activity into the above view. That doesn't really make sense when you think about what an Activity is. ".
Why doesn't it make sense? Obviously, I am missing the point here.
Question:
Given that my project already contains multiple activities (one corresponding to each screen), is my only option then to re-organize the project to have JUST 1 MAIN ACTIVITY, in order to use this library? Or alternatively, is there any way to launch a new activity when a list item in the sliding menu is clicked, and still observe the sliding menu behavior, [EDIT- added the last part to be more clear] or in other words, on how exactly to use this library within my existing app design.
Thanks in advance
First, you can't have an Activity inside another and activities are completely different from views as stated in the docs:
An activity is a single, focused thing that the user can do.
Now, to answer your question, it all depends on how you want your app to behave. You could have your activities with the sliding menu implement the onClosedListener and switch to the selected activity from there. This will give you the animation of closing the menu before switching activities. It will also give you a weird effect since every time you select something from your menu you'll see the animation of a new activity coming to the front.
I think the best approach would be to have a "common purpose" between all your sliding menu options. For example, in one of my projects I have to allow the users to select between lists of different types of data. When the user selects anything from the menu, I load a new list fragment into the right corner where he may choose the item he wants to view or edit. That's the app entry point and also the only place were I have a sliding menu in my app. It is pretty much the same for every app that implements this UI design pattern. Look at google+, currents and youtube where the side menu lets you choose which feed or content to show. Once a user makes a selection, just open a new activity for the selected item (a g+ post, a video, a news article, a tweet or whatever it is).
Your app doesn't have to have lists of different data or anything like that to use the sliding menu, but keep in mind that the activity with the sliding menu should have a clear, focused goal with respect to its functionality and purpose. Having a sliding menu because many other apps have one is a bad choice, you should use it with a specific objective. Also keep in mind that applying the sliding menu everywhere would interfere with the platform's navigation pattern and lead to an overall bad user experience since it wouldn't behave as the other apps.
It doesn't make sense to place an Activity into the above view because the Activity is the main controller for the view of each screen. The Activity also shows views and keeps track of Fragments (which in turn are mini controllers, with or without their own views). So placing an Activity in the above view would mean that you would place an Activity in an Activity... Wich is impossible.
From what I can derive from your text I think it would be wise to read through the Android developer guide on Activities and Fragment again (http://developer.android.com/guide/components/activities.html) to get a better understanding of how the concept of Android works.
Now to your question:
I am not clear on what you are trying to achieve but if you want your app, with menu to behave like, say, the Google+ app then one way of doing it is to implement a base class that extends the Activity class (or what ever base Activity used in your project) and let the base set the SlidingMenu. Then you would simple extend your base Activity in each of the Activities that are supposed to have a menu.
You could also do it the way you describe it, but then you would end up with a classic example of a God object (http://en.wikipedia.org/wiki/God_object). It's a neat way to practice your Fragment juggling skills and switching between Fragments instead of starting new Activities does have it's use cases, but I still wouldn't recommend it for a project with more then a few views.
Here is the answer that came closest to the issue I had - http://www.verious.com/article/polishing-the-sliding-app-menu/. Scroll down to the bottom of the page to see the last section titled "Using the fly-in app menu between Activities". This is one option if you have a lot of activities in your existing app and want to avoid extensive re-factoring. I haven't tried this out yet but its worth being aware of.
in my app I've launcher activity displaying summaries of different stuff. There's one SlidingDrawer set up in each activity having a dashboard with 9 menus as content. When user clicks on drawer's handle, content scrolls up to display that dashboard. These menu launch 9 activities from dashboard and there are no of activities that will be having same SlidingDrawer with dashboard.
Now the thing which is disturbing me is, I'm forced to put same code blocks in each activity that controls behaviour of dashboard. Dashboard itself is inflated from single layout. So design is not issue. But I've to attach event handlers to each button and start new activities from there. Problem is whenever I make changes I need to replicate those changes in all activities.
How can I avoid such redundant code and use a single class or something that let me define launching of those 9 activities?
Sorry for title and description. It's really hard for me to put it in words. If you find title or description not suitable then tell me or edit where appropriate.
Thanks.
This might be a perfect situation for an Android Fragment
Have two fragments for each activity, one for the sliding drawer and one for everything else.
Android fragments seem complex at first, but trust me, learning them will make your life easier.
I am working on an application in android. Where I need to use menu through out application. Actually it will be used for navigating within application from one activity to other and so on... I am wondering that it will need to write onOptionMenuCreat and OnOptionMenuSelect methods in each activity. Also if I make one parent activity where these two methods could be written even then on each activity Option Menu will be created again. So handling same menu while it is created again is becoming work of afaik. Any good design suggestions are most welcomed. Another very important thing how to map that user was on witch activity last time while selecting same menu again. My app has total five menu options so that means there are five different ways to move within application simultaneously.
Please Do tell me solution for both issues. Thank You.
You create the Menu in an Activity and inherit all the other Activities from this Activity.
To answer the second part.
create a different method for each menu handling in the parent activity. If you need a different menu/menu_item behaviour for your activity, just override that method.