Is there any way I can achieve the desired behaviour on rotation of the device, as illustrated in the following sketch (the wavy thing is a widget). Most likely this is something that would be controlled by the launcher, rather than controlled programmatically from any one app -- if so, is there any launcher that allows this?
Basically the reason I'm asking is because I want the widget to behave as illustrated (the widget is what I'm coding), even when the user's device is set to rotate the home screen on device rotation. Basically the only way I can see this working is if the grid layout is fixed relative to the physical screen, with the app icons just rotating within their box, and the widgets either updating their content for the new layout, or just keeping the previous content (so that the content rotates with the screen).
For updating of widget content, is there any way of detecting screen home screen rotation programmatically (different to screen rotation, since the home screen may not rotate)? This is relevant to me even for the "what I get" scenario, because the aspect ratio of the widget seems to change when the home screen is rotated, and I need to detect this and update the widget content to fit better.
dfdd
Use:
1. layout-sw480dp
2. layout-sw600dp
3. layout-sw720dp
You are unlikely to find a solution for this as the home screen (launcher) varies wildly in implementation. Many launchers don't support landscape orientation, and expecting the launcher to accommodate a widget which can expand in two different directions is simply asking too much of them.
For the launchers which do support landscape orientation, the widget should be repositioned for free without effort on your part. You may wish to detect which orientation the widget is in (such as via getResources().getConfiguration().orientation) when your provider is choosing a layout, setting up views etc, but that's about it.
Related
I've been searching docmentation and forums, and from all I've read so far, I conclude that in order to support portrait and landscapce modes, I need to code two identically named layout XML files, one in res/layout, the other in res/layout-land. Each layout places the widgets corresponding to the mode.
But what if there is no corresponding layout in res/layout-land (or if the later doesn't even exist)?
From a simple app containing a single text view in a ConstriantLayout, I see that the layout correctly adapts to the device orientation when run on my physical phone.
However, when run on a virtual device (Pixel 4 XL API 28, if that matters), the view is not changed when I click on the Rotate left or Rotate right buttons.
But, after clicking on the rotate button, a rotate icon appears at the bottom right of the virtual device. Clicking on that rotates the view.
Basically, my questions are:
Why is the layout correctly rotated on my physical device despite the fact that no landscape layout is present?
Why does the virtual device not rotate the layout when clicking on the rotate buttons, but offers me a rotation by displaying a temporary rotate icon?
A pointer to some documentaiton where all this is described in detail would be nice. It sure must be documented; I just haven't been able to find it.
Devices have a setting to enable or disable auto-rotation - on newer devices, when this is off, that rotate button appears which allows the user to choose to rotate (i.e., manually rotate).
As per the providing alternative resources, the most specific matching resource is used. So if you had a layout in layout-land, it will take precedence over that same resource in layout. (but wouldn't apply at all if you where in portrait mode as -land would disqualify that alternative resource).
That means that alternative resources are entirely optional - you'd only use them if your layout needs to be very different from one configuration to another. ConstraintLayout, for instance, uses relative positioning (i.e., position a view relative to the parent or to another view), which is often quite flexible to different orientations, screen sizes, etc. thus removing any need to need an entirely different landscape layout for a simple layout.
It's a bit of a frustration that as of Android 4.0, app widgets are automatically given margins between the widget frame and the app:
The space on a small phone's screen is at a premium, and the margin can represent quite a large loss, particularly when the widget is small too. Despite hours of looking, I can't see a way to override or control the widget's margins.
However, I have been playing recently with the Nova launcher, and note that it's possible to control widget margins using that launcher. What is more, although there's a global widget margin setting (something like None, Small, Medium, Large), this setting can be activated per widget.
And it's lovely to get widgets that extend from edge to edge. See, for example, the following screenshot from my meteogram app:
So, the question is... how does the Nova launcher control widget margins, and can the same method be used at the widget level, or does the control necessarily come from launcher level so that there is no hope for ever controlling widget margins unless you're a launcher developer?
Your assumptions are correct.
Widget margin control lies with launcher so there is not much you can do about it unless you build a launcher.
I have built an appwidget with an square layout, and so it doesn't fit exactly in the standard widget sizes as recommended in http://developer.android.com/guide/practices/ui_guidelines/widget_design.html#sizes.
I chose a 3x2 size (android:minWidth="220dip" android:minHeight="146dip") as it is the smalllest that covers the widget's layout.
In http://developer.android.com/guide/practices/ui_guidelines/widget_design.html#design Google recommends:
"All widgets must fit within the bounding box of one of the six supported widget sizes, or better yet, within a pair of portrait and landscape orientation sizes, so your widget looks good when the user switches screen orientations"
My widget looks good in portrait mode. When switched to landscape mode (in the emulator) the layout is clipped. I tried inverting the minWidth and minHeight values in the provider's XML and then it looked perfect in landscape mode but clipped in portrait mode. Setting the size to 3x3 solves the problem, but then the widgets takes a lot of unnecessary space.
I know I can define different layouts in res/layout and res/layout-land, but in this case the layouts are not different at all, in both modes I want the widget to look square.
What I would need is something like 'xml' and 'xml-land', AFAIK this is not supported in Android.
Ideas?
What I would need is something like 'xml' and 'xml-land', AFAIK this is not supported in Android.
It is supported. All resource set qualifiers (e.g., -land) are supported for all resource types.
Whether it will help you is another matter entirely, as I am not aware that you can change actual app widget size on the fly this way.
Setting the size to 3x3 solves the problem, but then the widgets takes a lot of unnecessary space.
You are the one who is trying to force a particular pixel size (or, at least, aspect ratio). This will be fragile, as you are discovering. Furthermore, app widget cells are not guaranteed to be the same size on all devices and home screen implementations.
Hence, you are either going to need to choose an app widget size that gives you tons of extra space (your 3x3 scenario), or design a fluid app widget layout that adapts to the actual size that you are given (and therefore will not be square). Personally, I recommend the latter.
On Android the user can place a widget on the desktop and then to move it by long touch and moving the finger while still holding.
Is it possible to programmatically get the position on the screen where the widget was moved by long touch?
I need my desktop widget to know if it's near the edge of the screen of the device. Depending on whether it's on the top of the desktop or at the bottom different layouts for the widget will be chosen.
I would expect that this position is not given in pixels, but as pair of 0-based indexes. E.g. if the device can display 4x7 cells on the desktop, the widget in the bottom-right corner should have coords (3, 6). Also it should be somehow possible to ask the device how many cells fit into the screen.
Or am I misunderstanding something?
On Android 2.1 and later, with some select home screens, you can find out where an app widget resides when it is clicked via getSourceBounds() -- this value is attached to any Intent you spawn via a PendingIntent via setOnClickPendingIntent().
However:
this only works on Android 2.1 and newer
not all home screens might do this, as this is part of the Launcher code IIRC
the coordinates are in pixels IIRC
there is no way to interrogate the home screen to find out this information any other way, since there is no API to interact with the home screen
Hence, I think your stated goal ("Depending on whether it's on the top of the desktop or at the bottom different layouts for the widget will be chosen") is impossible, I think.
We are writing an application for the T-Mobile MyTouch which is an Android based mobile phone. We have images that will be displayed on the default screen portrait mode (320 x 480).
Anticipating that the Android OS will be appearing on Netbooks with default landscape 16 : 9 screen format, what is the best way to handle images that are in a portrait mode format? In other words since you can't rotate the screen on these Netbooks, if you display a portrait mode image on landscape mode screen there will be large blank rectangles on either side of the image.
In terms of image resources within the application, such as is the case with background images, it is a common practice to have different image set for landscape and portrait mode, or even different screen sizes. Surely, you will adapt your layout to it, or at least have a good relative layout.
However, if you are wondering what to do when an image of an unknown size has to be drawn on the screen (e.g. in case of photo album application), it is fine to leave those black rectangles on both sides. Take a look at the behaviour of video player view on the Android Dev Phone 1. It will adapt the video frame height to landscape mode, and it will play the video in the landscape mode whether or not a portrait mode is more suitable.
You deal with it the same way you would deal with the user turning their phone sideways. This is as much a presentation decision as a UI one.
Remember Android supports using alternative layouts for identical Views. If you have a portrait layout e.g. res/layout/gallery.xml, you can create a landscape equivalent in res/layout-land/gallery.xml and Android will automatically load the latter layout file if the Activity is launched in landscape mode.
With the separate layout XML file, you can then arrange your image as you feel best fits the intent of your application (an application displaying medical images may well have different presentation priorities than one displaying a family portrait). You could for example just fill the background with a gradient, or more information that is otherwise hidden in portrait mode. It all depends on what you wish to achieve with your application and the lengths you are willing to go to to account for all possibilities.
But ultimately, provided the user can see the image in it's entirity without needing to flip their netbook on it's side, I imagine they'll be happy :)
You should design your screen with certain anchor points and then position the rest of the views in relation to those anchor points. For example if you have a screen layout which has a banner, a list of items and some buttons under the list then 2 of the ways these can be positioned on the screen:
Place banner at the top. Put the
list under it and then the buttons
under the list.
Place banner at
the top. Place the buttons at the
bottom of the screen and then the
list takes the space between the
banner and the buttons.
Layout 1) will have trouble with different screen sizes and the layout will look odd or may not appear correctly at all. Whereas, 2) gives you a better appearance for most screen sizes.