I'm designing my first watch face (just for me) I've been through the "Adding Complications to your Wear OS Watch Face" codelab (https://developer.android.com/codelabs/complications#0) and I would like to make the complications a darker grey (in the sample they show as white) when in ambient mode. An added complication (the normal kind, not the watch face kind) is that it seems to work in the android emulator, but not on my physical device (Ticwatch C2+, I don't have another to test it with).
I've been through everywhere I can look and the sensible place seems to be in custom_complication_styles.xml which I have edited as below:
<ambient
app:backgroundColor="#android:color/black"
app:borderRadius="50dp"
app:borderStyle="solid"
app:borderWidth="1dp"
app:highlightColor="#color/gray"
app:iconColor="#color/gray"
app:rangedValuePrimaryColor="#color/gray"
app:titleColor="#color/gray"
app:textColor="#color/gray"
app:borderColor="#android:color/transparent"
app:rangedValueSecondaryColor="#android:color/transparent"/>
The colours come from the colours.xml in the sample project, which (sensibly) includes gray. Just to make sure it isn't just my eyes not seeing the colours properly, I've tried something really obvious, like blue, and it still shows as white.
Adding the border information seems to work (initially in the sample there were no borders), but it doesn't seem to matter what I change the colours to, they are always white. I have tried this with an unedited copy of the sample with the same outcome.
I can change the colour of other elements of the watchface in ambient mode, just not the complications.
Hopefully, it is something really obvious and easy to someone out there, but documentation/tutorials seem a bit thin on the ground for wear os development. Thanks in advance to whoever can help!
TofferJ's comment was the answer I was looking for, disabling low bit ambient on the watch means the complications now use the colour set in the styles xml. Thanks!
Related
I recently started developing in Unity and I like it a lot so far, but there is this one bug, I can't tell where it comes from and similar reports of others I read didn't help me.
The problem is that buttons sometimes (almost always by now, not so often in earlier versions of my project) are straight up black and have very dark grey text in them, which is completely different from how they are supposed to look like.
Even if I put all buttons of the color to straight white, this happens - only in Android btw! (Not tested in iOS, but it's neither happening in the editor, nor in desktop builds.
As I said, this seems to happen more often, now that the game got bigger, has more buttons etc. - so I would guess that is has something to do with setting the Source Image of those buttons to UISprite. Also this does not happen to buttons that have an actual image as Source Image, not the default UISprite.
So this is an example of how it is supposed to look like
And this is how it actually looks like:
Has someone got an idea? I assume it is something about loading the UISprite.
According to your comment, the correct answer was what I thought (see my comment).
Too big textures are hardly supported by Android devices, because of the heavy memory consumption. Scaling down all textures should solve the problem. You can also simply add a lower scale of the texture and switch it before rendering if the device is a mobile. Add a script to your buttons and insert this :
public Image loweredSprite;
public Button button;
void Start() {
#if UNITY_ANDROID
button.image.overrideSprite(loweredSprite);
#endif
}
So I have been through the wild wild west. But as if all the magic paths weren't enough, I am having the opposite problem as they: my SearchView's text color is white. And no matter what I do I cannot change it to black. Of course I first went with the style approach, since it keeps out the voodoo. But nothing works no matter what theme I use. So I tried the magical approaches mentioned in the referenced wild wild west, but nothing there works for me either. To begin with I am afraid of their approach as it is inherently susceptible to failure from device to device, etc. All the same, I tried them. Does anyone else have some different information/approach on how to make this work?
My api level is 11 and up.
Different Android devices have different themes.
That means, that background colors, like in dialogs, may differ among Android versions and among manufacturers.
This may result into icons getting "invisible":
The problem with stock Android themes could be solved relatively easy, by providing different colored icons in target specific folders, e.g. white icons in a folder drawable-v14, and black ones in drawable-v10.
But that does not solve the issue that comes with customized themes from manufacturers, may it be TouchWiz, Blur or Sense.
It is simply not possible to cover every device by this method.
Another way would be, to draw a small black border around white icons, and vice versa.
But if the background would be gray, like in ICS, it wouldn't look good, either.
So, the question is: How to provide custom icons, that will work well on every theme, without touching the theme itself?
Accounting for all vendor choices (and mistakes) would be a pain.
I see a couple of options:
Explicitly select a stock theme and hope for the best
Select a custom theme derived from a stock theme, where you control the background color
Dynamically evaluate the background color for the chosen theme, and set the icon based by a tipping point (e.g. dark icons if background is light enough). Not sure if this would be practical, but at least it should be somewhat universal.
I recently went with the hard-coded colors in a derivative theme to fix a bug in the Nook dialog color selections for a dialog. More extensive testing would probably show me another platform that I just made worse with that.
Hopefully someone has a better answer than those, because none of those seem completely clean and universal. Reading your post again, it looks like none of those options meet your criteria of not touching the theme, either.
I have realized that there are at least two background colors on Option menu of Android. On the HTC Hero, the background is white and on Samsung Galaxy S II, the background is black.
This became a problem when I set the icons for the background menus. Is there some way to detect the background color of the Option menus in Android?
Possible solutions:
Don't use icons.
Design icons according to the guidelines - http://developer.android.com/guide/practices/ui_guidelines/icon_design_menu.html. There are three different guidelines for up to 2.2 (white background), 2.3 (black background) and 3.0+, so it's a lot of work...
As Profete162 suggested, use #android:drawable/ic_menu_*
For Android 4.0+, you can also set the light / dark Holo theme, which is guaranteed (at least in theory) to remain unchanged across different phone manufacturers - so it'll look the same in HTC Sense, Samsung TouchWiz etc.
That's indeed a very annoying issue.
On my implementation, I always try to use standards icons from android.R.drawable.IC_menu_*, so I am sure these icons are part of the framework and users are always positively surprised to see their generic icons in my app!
That gives a really good continuity in the user experience on the device, but that doesn't answer your question, but at least provide a workaround.
Here are for instance all android 2.2 icons: http://androiddrawableexplorer.appspot.com/
You can trust me, using these icons will always fit your colors.
First of all to answer your title question:
You can reference and read the background of the options menu by reading the attributes of the current theme. The attribute for this is panelFullBackground. E.g. set it as the background of a textview in XML¹:
<TextView android:background="?android:attr/panelFullBackground"
... />
Note that the background seems to be a solid color, but it's not - it's actually a bitmap. If you look closely you can see a grey border at the top (android 2.3+), or a drop shadow (<= android 2.2), so its'a bit difficult. Luckily there is a different attribute called panelColorBackground which matches the background color of the drawable as close as possible. So if you want just the normal background color, use this instead.
¹ This can surely also be read from code, but I don't know how from the top of my head at the moment, maybe I'll look it up and edit it in later.
Regarding icons
So you have the color as stated above, but you still have to process it to know if it's a dark or a bright color. You can do that, but that's not the usual way to deal with these icons and probably a good bit of work until you cover all the possible cases - not to mention that you have to create icons for each variant.
Normally you should adopt the platform menu icon style. This works across all devices and looks familiar to your users (custom icons that dont follow this often look "wrong" - e.g. astro file manager does this I believe).
You can do that by hand (see the guidelines), but the way better alternative is the Android Asset Studio.
It comes in two flavors:
As a webapp
Integrated in the latest version of the ADT plugin for eclipse
(under File->New->Other->Android Icon Set)
The workflow for both is pretty similar, select the point "Menu Icon" and follow the wizard. It will promt you to enter a simple, black and white bitmap of your desired icon that just outlines it's shape. After you specified one, the asset studio will generate everything for you. Play a bit around with the "clipart" option, that has a few example bitmaps ready to see how it works. When finished, the webapp gives you a simple zip which can be extracted into your project directory, the eclipse version adds it directly to the project that you select in the wizard.
The background color can be anything, because its implemented in Framework by manufacturer. You can't read it, in fact you will never need to read it.
Just create your custom menu layout in res/menu folder, set style and use it.
My Android app displays text in a few different ways, and there are some annoying differences between them I was hoping folks could help with.
When I use display methods that might be termed "automatic," the text is displayed very nicely. By automatic methods, I'm referring tools, like Toasts and Button widgets where I just have supply the text, and the OS (or "environment" or whatever) displays it for me. The letters are nicely curved, pleasant to look at, and easily legible.
However, in my code where I handle the text display (using Canvas.drawText() in a Surface Runner View), the text quality is poor. The text is still legible, but it looks pixelated. The letters just don't look their best.
I've tried experimenting with Paint.setTypeface(), using Typeface.SANS_SERIF for example, but the quality of the display when it's my code is always poor. Doable, but poor.
Has anybody else experienced this? By any chance does anybody have a solution?
You might also try playing around with Paint.setAntiAlias(boolean) or Paint.setSubpixelText(boolean).