I have a navigation bar with buttons which I would like to share between multiple activities:
Currently, when I start the same activity (for example, click on LOST.DIR) the whole screen changes, including the navigation bar (new list of folders appears).
I would like to keep the navigation bar static (to persist between same activity types and not to change or re appear after starting a new activity).
Is this possible?
It sounds like you want to use one activity and fragments.
But, if you really must use multiple activities. Another approach would be to use an actionbar, (actionbarsherlock is great for this) and have the menu switch between your different activities. The menu drop down can either be a list of icons on the action bar or a drop down spinner located in the top right of the actionbar. This actionbar will be static throughout your activities and consist of the same list of categories (i.e. the ones of your navigation bar).
Not straight away. Activities are exactly the opposite of what you want: they are independent pieces of interface.
You can use Fragments, or embed your activities in a master activity. TabHost does this, for example.
One approach for total control is to write your own custom class which takes a LinearLayout as a constructor argument and handles the visibility, click dispatching (via delegates), images etc of each button.
Add methods to do all of the above and whatever other functionality you need.
Create a layout.xml and it in each of your Activity layouts.
Instantiate your button bar class in each Activity and pass it the reference to it's layout that you get with findViewById on your content view.
As others have said, there are existing solutions and you might ask "why invent a new wheel". I have just such a class I use in many of my projects and it was a lot of work to do version one but now I have a class which I can totally control, add to, fix and customise with ease.
Something like this:
bar.setButtonClickHandler(Button.Favourites, favouritesButtonClickHandler);
bar.setButtonVisibility(Button.Edit, View.INVISIBLE);
etc
I've used a LinearLayout but if I have have the need to use something else, it's a simple matter to overload the constructors to accept, for example, a RelativeLayout argument.
Related
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.
On my app, I have a menu that I want to display for every activity and different page I have. The problem is that I can't find a way to apply this menu to ALL activities, nor can I find a way to load an activity into a certain part of the screen.
There is a generous sized rectangle in the center of the screen and I would love to have it so that whenever I open a new screen that screens layout loads inside the rectangle.
Or am I just going to have to copy and paste the xml code for every layout?
You should consider using Fragments. You can define a Fragment that can be reused in every Activity in your application without having to duplicate its logic between different Activities. Hope this helps.
You cant load Activity to a certain part of screen. For that (as suggested by #Egor) use Fragment.
However, regarding the common menu thinggy, I suggest you to create a base class which extends Activity and contains all the stuff you want to be commonly available in your activities. Later, use your base class to extend your activities.
There are someways to do this.
One is to write a Custom Menu that you can inflate by onCreateOptionsMenu, alternatively with the ActionBar.
Also you can do this by writing a separate xml with your menu and add it to all your layout-xmls with the <include> Tag.
The third way is using the Fragments-Class: link
you should never be cutting and pasting xml code from one layout to the next.. that is why we have includes:
<include layout="#layout/header"/>
don't over think your problem, you should look into fragments so that you can create reusable widgets like a menu, or extend your activity to abstract away your menu logic.
I have 2 Activities. One of it is displaying line chart, another is displaying pie chart. I would like to embed both in a single launched Activity. User is allowed to perform single click, to switch between line chart and pie chart.
I realize ActionBar's navigation tab, or drop-down navigation is the best candidate to help me achieve this purpose.
From Android API demo, and guideline found from http://developer.android.com/guide/topics/ui/actionbar.html, I realize all switched components are implemented as Fragment, not Activity
Does it mean that I need to port my previous 2 Activities into 2 Fragments, in order to embed them into ActionBar's tab navigation view/ drop-down navigation view?
Is there any other ways I can do without porting? But, is it advisable as I do not find an official example by using Activity.
In API demo, I realize most Fragment is implemented in the following pattern.
public class FragmentStack extends Activity {
...
public static class CountingFragment extends Fragment {
// CountingFragment never access any members in FragmentStack
}
}
Is there any reason to do so? Why don't they have CountingFragment is a separated file?
If you want to embed in a single activity, the preferred way is to use fragments. You could probably also use custom views, but Fragments have a well defined lifecycle and handle a lot thigs for you. So it might be a good idea to extract functionality into fragments, and have the activities only as shells, embedding the fragments (if you still need this with your new design). You can switch between fragments any way you like: with buttons, dropdowns or any other UI that fits your app; you don't necessarily have to use the action bar. As for 3. there is nothing wrong with defining fragments in separate files. Activity and fragment are in the same file in samples mostly to make it easier to follow the sample.
Im making a music player/library app in wich I would like a frame/toolbar on top of all other activities as a header. This frame/toolbar will show information about the current playing track and have some controlls like play, next and stop etc. and be a separate selfsufficiennt activity. Is this possible and if so, how?
You can create an ActivityGroup. This is how TabHost is implemented. So your ActivityGroup would fill the whole window and implement the toolbar. Then you could swap out Activities in the bottom part.
Currently I don't think that making a static top bar it's own activity in the life-cycle idea. However, what you can do is have every activity have the top bar and just re-create the bindings needed for each activity. It gives the idea that a section is static.
Now this breaks down if you start doing animations between the screens. Another solution is to just have a single activity and swap out the views. This allows for animations between screens be custom and only the parts that change need to create the connections they need. The trade off there is that you'll lose any kind of state saving and history that you gain by using an activity orientated approach.
I think you can do something like this on Honeycomb tablets as the fragments idea could be implemented like that but I've never explored it much.
i am using the following method in a new application i'm developing.
there is a main activity, which instantiates different classes that extends RelativeLayout, and i'm using setContentView to switch between the different modules of the application.
i wonder if this is a good approach or necesarily i have to use different activities to the several screens the app haves.
I'd recommend using different activities, then you automatically get navigation between them via the back button. Plus, there will be subtle things that won't work right if you do it the way you're describing -- for example, Android automatically saves the focused control when you switch activities. It won't do this for your content views; you would have to save/restore focus yourself.
Alternatively, if it doesn't make sense for a user to go "back and forth" between the screens of your application, then you could still implement the application with multiple activities, using android.app.TabHost. This is what the Contact app uses, for example. Then each screen is just a sub-activity, and the whole app is really treated as a single activity. And if you want, you can use TabHost without actually having tabs. You can hide the tabs and enable navigation via buttons or menu items instead.