I've noticed when using the design library's Floating Action Button that when the app is put in multi-window mode, the FAB is automatically resized to its "mini" size. Other apps such as Gmail share the same behaviour.
As opposed to that, my own UI elements and buttons don't change size. I set a fixed dp size for them, and they stay with that same size.
Is there any design recommendation to provide smaller UI elements when the app is in multi-window mode? Should one listen for app size changes and resize buttons depending on it? Or is this behaviour only recommended for the FAB button?
Related
Is there a way where we can control for every screen different states of the keyboard, for example I have one screen where I want to adjust size of the keyboard to the screen and other screens where I do not want that. Currently I was using this
android:windowSoftInputMode="adjustResize" , but when other cases come along this is not working anymore, is there any workaround?
I'm trying to design a layout similar to LinkedIn screen for sharing an update.
When you enter the screen for the first time the layout is split something like this:
half the screen is an edittext
half the screen is a gallery of images with a bar above the gallery
Now when I click the edittext - the keyboard comes up and it's just as high as the gallery, leaving the bar with the camera icon visible.
How did they design this layout so that the keyboard height is kinda the same as the gallery height?
In fact every keyboard can have different height, so to achieve this you should resize your activity to fit current 'height' when keyboard is shown status.
Tricky part is, android doesn't provides you that current status is keyboard shown status or not, so you should manage this status smart(One tip can be comparing curent height or height/width ratio to check it's resized or not by keyboard.
I'm working with the Kindle Fire HD 8.9", and unlike other Android tablets, its navigation bar (Back, Home, etc.) resides on the right edge of the device rather than the bottom edge. This is causing layout issues for myself since I need to calculate sizes as a percentage of the available screen width.
I've tried Display#getPoint(Point), as the Javadoc wording makes it sound like it will exclude system decor, but it does not for this device. I'm also aware of setting a OnLayoutChangeListener on my root view, but I need to know the available size prior to when this listener is triggered.
So is there a way to get the size of the navigation bar programmatically? I've calculated the size to be 90px, but I want to avoid hardcoding as it's risk-prone.
I'm developing a simple app with a customized background and a button in the middle.
I've got the whole different resolutions for different screens down, but do all the versions of the background need to be 9patches? How do I take into consideration the always there android top navigation bar and the possible use of advertisements at the bottom? Do they just cover the design or do they change the resolution?
I've got the whole different resolutions for different screens down
that's not how it works on android. see this:
http://developer.android.com/guide/practices/screens_support.html
do all the versions of the background need to be 9patches?
no . you decide . normally, buttons and views use the 9 patch images, but it can be useful for many other things. more info:
http://android10.org/index.php/articlesother/279-draw-9-patch-tutorial
http://radleymarx.com/blog/simple-guide-to-9-patch/
How do I take into consideration the always there android top
navigation bar and the possible use of advertisements at the bottom?
you can put a linear layout which has the ad on the bottom , and once it will be shown , the upper view will shrink its size.
about the action bar on the top, it doesn't matter , since the layout is below it anyway.
if you wish, you can also hide the top bar. however , if you have the bottom navigation bar (as on honeycomb and some ice-cream sandwich devices ) , you can't just hide it , since the end user must be able to press the back and home buttons .
Do they just cover the design or do they change the resolution?
you (and also those components) can't change resolution just like on a PC . everything takes space depending on your code and layout.
it seems that you need some guidelines of how to design for android. may i suggest checking out those links:
http://developer.android.com/design/index.html
http://www.google.com/events/io/2011/sessions/designing-and-implementing-android-uis-for-phones-and-tablets.html
http://www.google.com/events/io/2011/sessions/honeycomb-highlights.html
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.