http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#tabstructure
Are we sure this page was written correctly? It states that UNSELECTED icons must be "WHITE"; and SELECTED icons must be "GRAY". This seems backwards and looks quite odd in my application.
This is correct for Eclair (2.0/2.1) and FroYo (2.2) Android UIs. I'm not so sure about the UIs from 1.x, though.
Sense/Motoblur might have their own standards.
That's very true since usually active tab background is white and inactive tabs are gray.
Related
I am in a fairly serious predicament. I have built my entire app using ?attr/colorPrimary to pick the color for background shapes, as I have devised a way to dynamically change the theme and color. This works perfectly on 5.0, but on all 4.x devices, ?attr/colorPrimary crashes the app. Why does Android studio not alert developers to this incompatibility?
Is there a support version of ?attr/colorPrimary?
colorPrimary is already part of AppCompat as of version 21 and works back to API 7. Your problem is instead with your theming code.
I believe it was added after Android Lollipop - API 21.
At least this link shows that it was added between API 20 and 21:
https://developer.android.com/sdk/api_diff/21/changes/android.R.attr.html
attr/colorPrimary just point to colorPrimary defined in current theme.
I'm not sure how you implemented your theme.. But you can create your own attr... This option is good only if you support several themes.
If you have a single theme, I believe you can replace it by a color.
API 21:
Material design style
Notifications are drawn with dark text atop white (or very light)
backgrounds to match the new material design widgets. Make sure that
all your notifications look right with the new color scheme. If your
notifications look wrong, fix them:
Use setColor() to set an accent color in a circle behind your icon
image. Update or remove assets that involve color. The system ignores
all non-alpha channels in action icons and in the main notification
icon. You should assume that these icons will be alpha-only. The
system draws notification icons in white and action icons in dark
gray.
The problem is a glitch in Android code. See this, it is not the exact same but the reason is.
In case anyone out there has this problem, I want to explain my workaround.
Remove all instances of "?attr/color(Primary, Dark, or Accent)" and attempt to mimic the effect in each individual element in each individual activity. This is not a full work around, but for me it works. Google really needs to resolve this issue. If you know a better work around, please let me know and I will accept it as the better answer as long as it works.
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 recently updated my app, changing it's design a bit. Amongst other things, I styled buttons with custom drawables (well - not exactly custom, just taken from ICS release). Everything works well, except for one of the users.
Instead of:
He sees:
This is a Button, but I have also other controls styled with the same background drawable and the problems appears there (so, it's not limited to buttons).
There are two changed style properties that these controls have in common. One is, of course, a background drawable. The other is textAppearance:
<item name="android:textAppearance">?android:attr/textAppearanceMediumInverse</item>
I came to a conclusion, that this user is using some strange theme, which alters the default value of textAppearance* styles. But I have no idea what attribute may control this "text background color" (android:background does not work, checked this just in case). Or maybe I'm looking in the wrong place and this problem is not related to textAppearance?
EDIT:
The background image is a semi-transparent PNG file.
Android version 2.3.7, Motorola Milestone. That's all I got.
EDIT 2, Fixed:
OK, the problem was at the users side, it turned out he was using CyanogenMod7 with forced 16bit trasparency. After switching that option off, everything works.
OK, the problem was at the users side, it turned out he was using CyanogenMod7 with forced 16bit trasparency. After switching that option off, everything works.
In my application, I use some dialogs to display information.
The theme of my application is Theme.Light since 2 years, and these dialogs have always been black since the beginning.
Now with ICS, it seems that Google just changed his mind and turned these dialogs into white:
See the screenshot of my Moto Xoom and my Galaxy Nexus:
What is the best practice to handle that true fragmentation?
I have been thinking about creating different layout: layout-v14 but I will soon become crazy, if I have to create layout-v15,v-16, etc for the future?
Or is there a way to tell "lower than v14" and "higher than v14"?
layout-v14 apply to v14 and higher, so if any different style will appear in future you able to add layout-vXX to support this. And all versions between v14 and vXX will apply v14 layout.
On my Samsung Galaxy, application icons displayed on my Home Screen often don't match those displayed on the Applications Menu.
Firstly, I want to know if this is peculiar to Samsung/Galaxy (or some subset of Android phones), or if this is across the platform? Secondly, I'd like to know how to set this up in my Android project.
To illustrate what I'm asking, please refer to the following image:
Icons 1 and 2 are typical of a lot of third-party apps: on the Home Screen the icon transparency is honoured, but on the Applications Menu the icon is over-layed onto a button graphic. On my phone the latter is more-often-than-not a dirty-green, radial pattern.
Some apps have over-ridden this behaviour, however: icons 3 and 4 show that MapQuest has been able to specify a different base colour for the button (same radial pattern, though); and icons 5 and 6 show what appears to be a complete replacement of the button image or Application Menu icon.
Can anyone explain what I need to do to specify both forms of the icon in my project?
Thanks, in advance.
That particular effect is part of the Samsung Homescreen UI. It does something similar on the Galaxy Tablets.
icons 3 and 4 show that MapQuest has been able to specify a different base colour for the button
I don't think that they specified that I imagine that it is either luck of the draw(on Galaxy Tab there are many colors blue,green, orange, pinkish, etc...they don't appear to have any sort of pattern for which icons get which color), or it can tell that their icon is green also, and because of that it changes colors so that you don't end up with a green icon on top of a green backdrop.
and icons 5 and 6 show what appears to be a complete replacement of the button image or Application Menu icon.
I don't think they had control over that. I think it is just another one of the possible backdrops that the system uses.
Can anyone explain what I need to do to specify both forms of the icon in my project?
As far as I know you can't the backdrops are up to the 3rd part home/launcher replacement app. In this case Samsung's (but there are other home and launcher replacements on the market that could also use an effect like this if they wanted.)
Thanks, Tim - further playing around has revealed more...
As a result of refactoring my package names, I ended up with two copies of my app (with identical icons) on my Applications Menu.
As Tim suggested might happen, the second icon has a different, apparently randomly allocated, background. It would appear that the button colour is unrelated to any colour in my icon, however, as the same icon got allocated a different background.