views:

95

answers:

3

I'm trying to implement a menu in the footer of an app, similar to i.e. the Engadget app. As I understand, getting a standard TabLayout to work in this way is not trivial (if at all possible?).

As I see quite a few apps using this interface paradigm, I would assume there is a clever way of doing it. Currently, I'm defining the layout by adding an include line at the end of every layout. This works fine as far as rendering is concerned, but I have to add the onClickListeners to each activity. can we define clickListener through XML?

To sum up my question: What is the best way to implement a shared footer navigation accross several Activities?

A: 

Here's a long shot and I've never tried it to see if it works:

  • Create a special class which contains onClick methods for the elements in your footer. import this class in every Activity you have;
  • Use android:onClick in your included XML file with values pointing to methods in that class.

Now, I'm not sure whether this class would need to be instantiated in every Activity or if you can use its methods as static, but something like this should work and it's still better than adding the listeners to every activity.


In my opinion (and I emphasize that it's just my opinion), this interface paradigm as you call it is a poor attempt to copy the iPhone. This paradigm is very popular on the iPhone, mainly because it only has one button. I even hate the Engadget app for doing it (and again, it's copied from the iPhone app) -- it wastes screen real estate.

In short, my advice: use the MENU button.


Last note: never played around with a TabLayout, but if you want a separate Activity in each tab then I'm 99.9% sure you can't do it (you can't embed whole activities in any kind of View or ViewGroup). The TabLayout only houses child Layouts, not activities. Also, with the TabLayout, you can say bye bye to the BACK button (are you going to waste yet another button to copy a UI from the iPhone?) -- unless you plan to override it, in which case you can say bye bye to your users.

Felix
Wrong. TabLayout can have a separate activity in each tab, and I have an app on the market that does so.
Rich
So you can have multiple active activities on the screen at once? Is there some kind of ViewGroup that can hold activity children? If you're right, then that should be the way to go, although I still think using menus is better, for screen space if not for anything else.
Felix
A: 

Not sure if this idea is workable,

Set a TabLayout1 on the footer, but set it up so only the tabs are visible, not the content (which would go below the footer, in an invisible space).
Then have a second View on the rest of the screen, and you can switch views there. If you set the second layout (the top) as a TabLayout2 and bind the tabs to Activities you can share this view across activities. Also note you have to setup TabLayout2 in top in such a way that the tabs are not visible only the content area is visible. I think with some padding can be resolved.

Pentium10
Sounds like a total hack. I agree that it *might* work, but that doesn't change its hack status. Also, launching a new activity when clicking on a tab seems.. un-user friendly. I would hate such an app. And on top of all that, positioning the `TabLayout` just right would be a nightmare, especially considering the variety of screens and densities Android supports.
Felix
Launching a new activity when clicking on a tab is already built in, and you can use it very simple.
Pentium10
+3  A: 

You can make all your activities derive from a common base class that extends Activity and put a method in there for building out the menu. Use a RelativeLayout as the main container, stick a horizontal LinearLayout on the bottom (layout_alignParentBottom="true"), and then align your main "content" container (whatever type of layout you want for the particular activity) above that. Using android:weight on whatever you put in your menu (ImageButton, for example) and then android:weightSum on the container of the menu, they'll be spaced evenly. So, if you have four ImageButtons with android:weight="1" and the LinearLayout that contains them have android:weightSum="4" you should be good.

So, TabContentActivity can extend Activity, and then all of your specific activities extend TabContentActivity. TabContentActivity has an onCreate that calls super.onCreate and then call some private method for building out the menu. Then, when your derived classes call super.onCreate in their own onCreate, your "tabs" are built. You can have an Enum in TabContentActivity representing each tab with a local variable of that Enum type to dictate which tab is highlighted.

Don't listen to people telling you not to do it that way. If that's the UI you want, don't be constrained by the environment you're working in. Just as you have responses telling you that's not the "right way to do it in Android", you also currently have two up votes.

Rich