Since space is at a premium in an app widget, particularly when sized at 4x1 or 3x1, it's a bit frustrating that Android 4.0+ enforces a blank margin around the widget. See the Design Guidelines and Adding Margins.
How does one reduce the size of the automatic margin for 4.0 and above? I know that Android would frown upon it, but I know that it can be done because I have some widgets that don't have any margin around them, on my 4.1 device. Or is that because the app would have been built against a lower API (compileSdkVersion)? The compileSdkVersion for my app is 21.
Thanks for any insight on this issue.
Related
I am developing an app, however, I have noticed on phones that have edge-to-edge screens, the black notch at the top blocks out some of the features I've added in (for instance, information on the action bar).
I know there are simple fixes such as using
<item name="android:windowLayoutInDisplayCutoutMode">
shortEdges <!-- default, shortEdges, never -->
</item>
within the activity style, however, I have noticed that the incision of this requires a minimum API level of 27, which is much higher than the minimum of 14 I have been trying to maintain, and I don't want to cut out that high of a percentage of the market.
Do any of you know how to deal with edge-to-edge screen layouts without compromising the minimum API level?
I would advise you to just use newer API, as since then new models with notch started showing up on market (thus Android introduced that API), keeping API 14 as min. You can still support older devices without calling non-existing methods from newer APIs. As you have here only one attribute in XML - these aren't resolved on older OS versions, but don't break nothing
PS. Note that before Android introduced this API there was some freshly introduced devices with notch and you don't have any option for proper handling layout on them (too old for API, device manufacturer didn't provide any API either). But most (all?) of them got update to API27, so your issue may occur only on never-updated devices with "experimental" notch
Android Wear Watches are a lot smaller then Android phones, but when looking over the Android API pages and training guides, I didn't see any restrictions on layout elements. Some layouts, however, wouldn't make sense on some watches. For example, a large custom layout ListView wouldn't fit very well on round watches. Are all layout elements really available on Android Wear?
Not all layouts are available (WebView for example). You can see the unsupported libraries here.
And some layouts are meant to be used in Android Wear only.
There is no restriction as far as I know. There are some adjustments that one need to pay attention to in order to have a pleasant UI on both square and round displays, by adjusting the location of items and taking advantage of what the platform adds for handling round vs square, etc but outside of that, all the layouts are, as far as I know, available there too.
While testing our site on different devices we found a problem on recent Android versions. There is a bug with textures under the page, where the content ends (actually there is no any content where appears the bug). The bug appears only when the height of the page zoomed out is smaller then the screen of a device. Previous Android versions (4.1 etc) show there just white space (as Apple and Windows mobile devices also do), but 4.4 and later randomly repeats some portions of the site. We tried different viewport metatag options as well as different "height=100%" and "min-height=100%" tricks in CSS with no result. Any ideas on how we can fix it? Thanks.
Screenshot: http://i11.pixs.ru/storage/7/5/4/2jpg_2263155_16706754.jpg
I'm trying to figure out how to enable vertical scroll for an Android widget.
From what I read in the documentation and this post it's possible to do that only from Android version 3.0 and up.
However, I saw a phone (Motorola Razr) with Android version 2.3.6 that had a Gmail widget with a vertical scroll.
So I can't understand if it's possible or not? And if it is possible, how to implement it?
Manufacturers generally build out Android from a custom version of AOSP. Since the entire source for Android 2.3.x is available, it is quite possible that Motorola simply added support for scrolling widgets by modifying the source for their own devices (potentially using the same techniques that AOSP 3.0 does). And if this is indeed the case, that will require changes in the underlying operating system and hence will likely not be available to you if you are building the widgets using the SDK.
If by widgets you are talking about ? extends widget.View, you can always build you own View that does vertical scrolling.
This envolves parsing onTouchEvent (and probably onDispatchTouchEvent) and a lot of math.
I did it myself at work.
I wrote simple aplication for android. It works great in emulator. But when I installed it on real device (htc wildfire) then the interface became ugly. Except that it works good. TextViews look fine but the buttons, sprinners and list items look bad. Button corners seem wretched. All the lists (list view and list preference have no delimeter(line) between rows! When I scroll a bit the delimeter appears). Why?
The buttons probably become stretched because you're not using 9 patch images. Here's a good tutorial on 9 patch images http://developer.android.com/guide/developing/tools/draw9patch.html
Regarding the list view, you might want to set this field inside listview in your xml file
android:cacheColorHint="#00000000". That might do the trick.
Have you specified a targetSdkVersion in the uses-sdk tag in your manifest? If you haven't, Android will assume your app does not know about newer platform versions with different screen sizes/densities and run your app with compatibility scaling.
You should always set targetSdkVersion to the newest version of Android that you are targeting. This helps let Android know what compatibility behaviors to use for your app if things changed in newer versions. targetSdkVersion can be greater than minSdkVersion, meaning your app knows how to take newer platform features into account while remaining compatible with a minimum version.
Most likely, screen density is different on the device. Instead of specifying sizes in pixels (px), use sp for font size and dp for everything else. This way they will scale properly.