Does elevation not work within Android Home Screen Widgets? - android

Tried all sorts of different ways to do this but not matter what view I apply an elevation to (such as android:elevation="10dp") it does not render correctly on a Home Screen Widget.
Is this a known limitation, that home screen widgets do not support elevation. I am running this on an Android L device so its should not be a compatibility issue.
If this is impossible I figure I could use 9-patch or layer-list drawable to achieve a similar but not as good effect.

I've played with all widgets I have on my phone (both with Nova Launcher and Nexus 5 stock launcher, which is Google) and none of them have this feature, even Google apps (excluding Google Now!).
I've added app:elevation="10dp" on my widget and I think that it is not possible to have this feature on Widget directly, without playing with code and fantasy.
If you really want a widget that include elevation design, just "copy" the style of Google Now widget.
I suppose that they have a transparent layout (the black parts on image) wich contains another layout (grey) with elevation and grid filled with CardView with elevation too.
Let me know if you want an example code.

Related

Is the padding for icons in PreferenceHeaders different to PreferenceScreens?

I'm working on two apps - one uses PreferenceHeaders for the settings page, whilst the other entirely uses PreferenceScreens. I've got icons next to the setting items in the PreferenceHeaders screen and it works entirely as I'd expect:
Unfortunately, in the other app, the use of the android:icon attribute has a very different outcome, with lots of padding between the icon and the text:
Is this just an issue due to the different preference system, or is it caused by something else in the app, and if it is due to the use of PreferenceScreen, is there any way to make it mirror the behaviour of PreferenceHeaders or should I just switch it?

Android 10: 3-button navigation is obscuring bottom of the screen

I have had feedback from Pixel 3/4 users that the bottom of the screen on this app is cut off, obscuring buttons and possibly other controls that the user requires.
This has only started happening on Android 10. The app contains both Xamarin.Android axml and Xamarin.Forms xaml layouts for the views (the particular page that you are viewing below is Xamarin.Forms).
I don't want to set margins, paddings, gravity or such like on the entire app as obviously that would impact non Android 10/Pixel users. I don't really want to check the operating system version and programatically change those properties as that seems quite hacky and will quickly become unmanageable.
I've looked for something similar to a UseSafeArea property for navigation bars rather than notches but there doesn't seem to be any. Is using WindowInsets the only way to this or has someone else had/solved this issue?
How it looks (controls at bottom are obscured):
How it should look (and does on every other device, the data is different here but it's the view that matters):
I had a similar issue which I solved by removing a few lines of code that were there to fix a bug that has since been fixed in Xamarin Forms.
It directly relates to this forum topic: https://forums.xamarin.com/discussion/87176/windowsoftinputmode-doesnt-work-in-xamarin-forms-android
If these lines exist in your MainActivity.cs, try removing them and see if that works:
Window.SetSoftInputMode(Android.Views.SoftInput.AdjustResize);
Window.SetSoftInputMode(SoftInput.StateHidden);
AndroidBug5497WorkaroundForXamarinAndroid.assistActivity(this);

android lollipop ViewGroup child hierarchy changes?

I have an app that has a minSdk of 15 and I'm working out all the bugs that came with the lollipop upgrade. Our software is very complex and it dynamically creates views using custom ViewGroups and then an array of elements that are explicitly sized and placed inside the group. I'm running into an issue where for example I'll have a ViewGroup and the first child object is a Button...this button is sized to fill the view (not clickable). The second child is a FrameLayout containing a single view. This single view is a video object. In all prior versions of Android this works just fine. The FrameLayout is layered over the button (that is acting as a background) and the video is inside the framelayout. You can interact with the video without any issues.
Something changed in lollipop - suddenly, even though the button is showing up as the 0 index element, it is laying OVER the rest of the children...so I cannot get to the video underneath. If I remove that button element, the video renders and plays just fine...I have no issues interacting with it.
I ran the app in UI Automator Viewer just to make sure I was really setting up the UI as I expected (keep in mind the entire view is dynamically rendered at runtime using image/video assets and xml config files).
I'm not able to share code since this is proprietary software, but I am working on a little test project to see if I can manually recreate the issue with static objects. Once I get that up and running I'll be sure to update this ticket. For now, here is a screenshot of the hierarchy:
https://goo.gl/photos/a8on9CJDnN66XYnV6
Notice the highlighted object, this is the custom ViewGroup, the children below it are what I am describing above.
Does anyone know of a change in Lollipop that would effect the ordering of things? I found earlier that if you have a disabled object but don't have a disabled state drawable assigned to that object it would become invisible, previous versions just used one of the other state drawables..okay that makes sense and it was very easy to fix, but this object is not invisible...so it must be something different.
Any direction would be greatly appreciated.
~A
UPDATE -- FIXED
With the help of #alanv and #BladeCoder I figured out this functionality was due to the new elevation feature of Material design. I was able to fix my particular issue by first checking what version of android the device was using, and if lollipop, I just add this new property to the button:
android:stateListAnimator="#null"
This prevents my explicit child hierarchy from being overridden by the OS.
Lollipop introduced elevation as a way to position the elements on the Z axis and cast shadows between them depending on their difference of elevation.
Enabled buttons have a default elevation of 2dp (and it increases when you press them). So, your button has a higher elevation than the FrameLayout (0dp by default) so it will be drawn on top of it.
Disabled buttons have an elevation of 0dp. That's why disabling the button solved your issue.
Using buttons as backgrounds looks like a bad idea (why not setting a custom Drawable background on your FrameLayout instead?) but if you really need that, you can disable the button like you did and, just to be sure, enforce its elevation to 0dp. Another workaround is to increase the elevation of the FrameLayout but then it may cast a big shadow under Lollipop if it has a background, and maybe that's not what you want.
Okay, UPDATE! I figured out how to fix the issue, although I'm still not sure (even after pouring over the diffs between several classes in grepcode) what changed in lollipop that is causing a change in how this works.
If the button is enabled...and you are placing it using something equivalent to AbsoluteLayout (We have our own ViewGroup we created called Explicit layout, but it does pretty much the same thing as AbsoluteLayout), it will always be on top of anything else in the stack that isn't also a button of some sort (at least that's what I'm finding...I didn't test through every possible widget).
Setting the button that is acting purely as a background image to enabled=false solves this issue. I know, it doesn't make sense that we use Buttons as background images, but our code uses it for dynamic element creation so there are many possible states and uses for each element.
Anyway, not sure if anyone else would even run into this issue, but just in case you do...here it is.
Thanks!

Android Icons: Home Screen vs Applications Menu

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.

Title of Android AppWidget below widget-icon

I am working on a small application which should be represented by an AppWidget.
The AppWidget should look like many other widgets on my HTC Desire. Most of them consist of an icon and a title below the icon. The title always looks identical, it is white text on a black rounded banner. I have not found a way to get this layout without painting all by myself. What do I have to do, to get the app title shown below the AppWidget?
Thank in advance,
Wolfgang
Per a previous answer here this is actually discouraged by the Android UI guidelines: An App shortcut has such text below it, and it may change in future Android releases or in custom skins such as HTC Sense or MOTOblur. A widget should be a wholly contained graphical element without a text label below it. You need to find a way to make graphics / text in your widget which are self identifying to the user.

Categories

Resources