In the previous article we looked at using different controls in our ActionBar to provide custom behaviour. That’s all well and good, but suppose we actually want to do something a little more complex? In this article we’ll have a look at how we can use custom layouts within our ActionBar.
In Google Search for Jelly Bean, we can see quite a common UI pattern, the addition of an “X” button in an EditText field which allows us to clear the text entered in the control:
One way would be to write a custom control which extends EditText, but there is an alternative which we can achieve by combining standard controls inside a RelativeLayout. Let’s create a new layout in res/layout/search_layout.xml:
<?xml version="1.0" encoding="utf-8"?>
This is pretty straightforward: We have our EditText which is used to accept the search criteria, and then we have a Button which is used as our “clear text” button. Getting the positioning of the Button within the EditText is all achieved using the RelativeLayout to position the Button in relation to the EditText and the Layout itself.
I won’t bother explaining the state-list drawable that’s used for the button graphic, or the click handling as these should be understandable if you look at the source code for this article. Being an article on ActionBar, the key thing is how do we actually use this within our ActionBar? That is, once again, really quite easy. We add another menu item to our existing menu and use the
android:actionLayout attribute to specify the layout that we created.
Getting references to the controls within the menu is also pretty easy. The Action View of the MenuItem will be our layout and we can find the controls from this:
public boolean onCreateOptionsMenu( Menu menu )
getMenuInflater().inflate( R.menu.main, menu );
mSearch = (EditText) mSearchItem.getActionView()
.findViewById( R.id.search );
mDelete = (Button) mSearchItem.getActionView()
.findViewById( R.id.delete );
If we run this them the EditText with the delete Button appears within the ActionBar:
Before we finish with ActionBar, there are a couple more tricks that are worth mentioning. If we make a tiny change to res/layout/search_layout.xml, and change the
android:layout_width attribute of the EditText control to
match_parent, something rather different happens:
The EditText expands to fill the ActionBar, and we lose the rest of the menus, including the overflow menu. Sometimes this can be exactly what we require if we want a single control to fill the ActionBar. More often, it will cause us issues when we inadvertently use
match_parent to try and fill the available space, without realising that it will also push the other menus off screen.
Once final thing worth mentioning is that if you have a requirement to use a navigation model that is neither tab or list-based, then you can use
ActionBar.setCustomView() to specify a custom layout to use instead of the defaults. Obviously you will be required to implement all of the navigation logic yourself if you chose to implement you navigation in this way.
That concludes our introduction to ActionBar which is an extremely powerful and versatile component which is surprisingly easy to use.
The source code for this article can be found here.
© 2012, Mark Allison. All rights reserved.
Basic ActionBar – Part 5 by Styling Android is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at http://blog.stylingandroid.com/license-information.