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?
Related
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);
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.
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.
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!!
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.