Various devices use various backgrounds for their options menu. The problem this causes me is that the gray-ish icons I use for my options menu buttons don't look great on darker menu backgrounds. From my reading and experimentation I see three options for dealing with this. Number 3 is the one I intend to do, but I have a question about implementing it. Also, I would be very interested in any general thoughts/advice about this issue:
Use icons that look good regardless of the background color. Maybe dark-ish gray icons with white-ish outlines? This would be an easy option to implement, but getting the ideal icon is tricky.
Set a custom background color. The code for doing this appears to be very hacky, and this results in an options menu that doesn't conform to the device theme.
Have 2 sets of icons, programmatically set one light-ish menus and one for dark-ish menus. This seems promising aesthetically, but I can't find how to determine the color/lightness of the background?
The best option (and the one I've done before without any problems) is to set a custom background color. It isn't really that hacky, if you understand how the Options Menu works. When the Options Menu is inflated, it references a View Object that it uses for the background of each button. The problem is, different device manufacturers use custom themes (blech). The way around this to ensure that your Options Menu always looks the same regardless of the device your application is running on is to create a custom View and set that as the background.
This is the best resource I've found for this issue:
http://bit.ly/ymc0Zc
I hope that helps!!
Related
I've run into a very peculiar problem with Toolbars. The way my team currently uses the Toolbar is via a wrapper class, let's call it WrapToolbar.
So WrapToolbar will internally setup a Toolbar, and exposes some common Toolbar functions. Things like setTitle, getTitle, etc are available.
This WrapToolbar also sets up a default icon. This way all usages of the WrapToolbar will have this icon available for the screens that need it.
The problem with this approach is that for screens that require additional icons, have to add them via a Menu XML and the onCreateOptionsMenu function.
When we do that, the default icon setup with WrapToolbar gets pushed to the left, and the new icons from the Menu XML get added at the end.
This has worked fine for us until recently when requirements changed, and now are asking for the default icon to be at the end all the time.
I'm currently wrestling with the idea of doing a custom wrapper around Toolbar that exposes the ability to add icons, get the title, set the title, etc. This way we can put the icons in any order, and have ultimate flexibility in how our Toolbar looks.
I'm looking for some guidance on what that might look like. I also want to get some feedback on whether my initial idea to solve for this is flawed in some way I haven't foreseen.
Menus have a built in ordering based on the android:menuCategory attribute - you can use android:menuCategory="secondary" to push a menu item (like your default icon) to the end of the list - all MenuItems without a menuCategory will appear to the left of it.
Recently I became the proud owner of an Android 4.0 tablet and have been snooping around trying to create some apps. Now that I have the basics covered, I'm diving more into the "what's good/what's wrong" parts.
As far as I understand, the old "menu/settings"-button is deprecated (in the sense that you shouldn't use it anymore) and now the ActionBar is the way to go. Upon reading further, I came across this: http://developer.android.com/resources/samples/ActionBarCompat/index.html
It shows how to use the ActionBar on pre-API 11 systems. On the left you can see the typical menu where all options are shown a developer decided weren't important enough to be in the actual UI (the "wrong" way, but programmed using the newer ActionBar API). On the right, that same menu is now on the ActionBar.
My question is: Since it's been said such an "overflow"-menu is bad design on older mobile devices, is it also bad design when it's on the ActionBar as a button like shown on the right screenshot? Or is it only considered bad design because on a lot of devices it required you to press a physical off-screen button which makes it a non-issue when it's a virtual button on the ActionBar?
In short: Should I avoid it or not? Frankly, I like the idea of having a menu on the far right with all options that either don't fit or aren't important enough to be their own entity on the ActionBar.
Please also point out if any of the information I gathered and explained here is wrong.
The options menu hasn't been removed, it's just moved. It used to be hidden "behind" the Menu button on the device, but it's now moved to the ActionBar. Items on the menu either show as icons on the ActionBar, or on the overflow menu. You use exactly the same code to add items, whether to the old style menu, or the new style ActionBar.
A big part of the improvement that's been made is there is now a visible button on the top-right of the screen to open the "menu" (ActionBar overflow), which is right next to the other options. this is much better than before where the menu button had no visual connection to the app.
I suggest you look at ActionBarSherlock, http://www.actionbarsherlock.com, as it makes it pretty easy to add the full ActionBar to pre Android v3.0 devices.
http://developer.android.com/design/patterns/actionbar.html
Finally, I'd suggest that you follow the UI guidelines from Google. If they say the ActionBar is the right approach for navigation, then use it. It's best to use the provided UI patterns, and focus on the domain-specific stuff in your app.
I'm trying to cope with some problem in finding good idea. I would like to make interesting menu like in games on Android (eg. ANngry Birds or here: http://www.youtube.com/watch?v=Q3g6SdTODY4) In this panda game I supose that first menu are simply 3 color buttons, but what about this sliding menu later with stages description - this same as in angry birds? Telling the truth I have got no idea what object it can be?
I will be glad if someone can tell me that. Or the best to give some tutorials about it. I cant google any.
Well, it seems that this sliding stage description is implemented with some simple layout placed to HorizontalScrollView and some animation applied to the buttons.
It can be your custom view provided with your translation animations and handling its visibility on the click of the default menu button (via onKeyDown()) on Android.
There are similar questions:
Custom options menu in Android
Android: customize application's menu (e.g background color)
This is probably a simple question, but I really have tried searching here and google with no joy.
I can make listview lists by following the many tutorials on the net. The problem is, they always seem to churn out lists that don't seem similar in appearance to the bulk of the lists I see in apps.
For example, I've attached a screenshot of a menu in the Chainfire3D app. It uses the 'standard' blue dividers, white titles and smaller blue 'description' text for the second line. This style of menu/list is used in many of the market apps I have. Feedly is another example.
Every time I create a listview I get either all white text (or text which is themed by whatever I have used in the layout).
Are there 2 line menus, with white and blue text that are easy to create, because I'm having to specify the colours in XML etc if I want them to look this way.
Also, to get two line listviews I have been using a custom adapter and 2 textviews on top of each other in a layout. I tried a 'simple_list_item_2' and that worked but again it didn't take this 'standard' theme. I'm sure I'm missing something.
Anyone know what?
Ideally, can someone share some code with me that will create a 2 item listviews, ideally (if poss) with a suitable adapter that will allow the running of different activities based on menu items presses. Here's hoping you can help.
The easiest way is to customize your layout.
You can find good examples here or here.
I've seen references on how to SET system colours, but I need to find out how you GET them - how do you find out what they are?
On the Samsung Galaxy S for example, the tab views, ListView highlights when you select an item, and the Summary text line on the preference screen are all blue.
There are many apps which immitate this style and I want to do the same. Obviously I cannot just hard code and set the colour to Blue, as other handsets use different colours.
The question is, is there a way to programmatically find out what colour the Preference Screen Summary Line, Tabs, or ListView selections are, so that you can then set that against a TextView elsewhere in your app?
How do I get the android system colours?
There is an answer to this question, but it is probably not the one you wanted to hear. There is no way to reliably do this. The "selection color" is actually part of a nine-patch image, which is provided on a platform specific basis. Some use the standard orange color, some (Sense) uses green, and others use red. With an exhaustive list of these you might be able to create a mapping from hardware to color, but this is not very effective because new hardware comes out all the time, and some of these phones allow sense to be uninstalled.
The only real thing you can do is to make your buttons consistent within the application itself, which is a hard enough task by itself. If you really have to have a custom item with a selection color (which is common enough), then my advice would be to copy the button resources from the platform of your choice (I like the default sdk resources myself) and then manually set them throughout your application. This way they will always look the same no matter which platform you are on, and so will always match your custom views. Note that this will require you to do more than just buttons. Dialogs and menus also will need to be modified, which is possible, but hard.
Really this is a flaw in the way Android was designed, and it causes a lot of us grief. I wish I had a better answer for you, but I think this is the best we've got.
You can specify colours to elements in your XML layout using the #android:color system variable:
<TextView android:background="#android:color/white" android:textColor="#android:color/black" />