I have a tab-based Android app. Currently, it does not support landscape mode - the one and only activity swallows all orientation changes. Now, a user asks that I support landscape for the sake of the hardware keyboard convenience.
On one hand, it makes sense. On the other, the default behavior of a tab host is rotating the tab strip; when it does, it takes a good one third of the precious screen space for the tabs alone. So I lose a lot of real estate.
Are there any common ways out of this conundrum? As far as as I can see, a vertical tab strip is not an option.
I suggest following the technique discussed in Timores's answer to android:orientation="vertical" does not work for TabWidget, where he describes how to set up the TabHost to display the tabs on the left of the screen, with tabs vertically stacked.
Don't use tabs. That's probably the best suggestion anyone can give. Tabs on a mobile devices are a great way to display quick information, and a lot of information. But when it comes to handling user inputs, it doesn't really help considering that it's a mobile device with limited real estate.
While this has already been answered (and I like the one you accepted--will probably implement it myself), there is another option.
Use buttons instead of tabs to navigate between Activities. Each Activity has the same series of buttons in the same locations, much like a navigation bar on web pages.
You can place your buttons however you like, depending on the orientation or however your design sees fit.
For examples, just look at any of the millions of websites with navbars, such at StackOverflow.com at the top of this page.
Related
I was recently looking at apps like Blinkfeed and My Magazine that run as fully functional apps but live right next to the Android home screen. Given that widget can only take up a certain amount of space of the home screen and have limited functionality,I could conclude that they aren't widgets.
I would be interested to know how companies like HTC and Samsung implement these full screen apps that live to the left of the screen. I tried googling it but perhaps I am not googling the right thing as I couldn't find a word about how both of these things were implemented. Hence I decided to turn to the wisdom of the internet !! :D
Consider homescreen as the Activity that has floating buttons (those that are at the bottom).
This activity (fragmentactivity to be precise) contains ViewPager of fragments on each page.
And the leftmost page/fragment is the ListView (Blinkfeed).
(*) are the floating buttons , probably LinearLayout that has transparent background and contains buttons.
I have an application I want to adapt to tablets and handheld devices
When handheld device is in portrait or landscape I want to display ListView and when list item is selected I start another activity.
When tablet device is in portrait - see above.
When tablet device is in landscape I want to display ListView in one part of the screen and selected item content in another part of the screen. Basically something like this:
How should I achieve that? I was thinking different activities and layout resources for each orientation. But I have a feeling that there is a smarter and better way.
Of course I could stuff everything in one activity somehow but it doesn't feel right. Nor looks nice :)
Thank you
What you want to achieve can be done using Fragments. Here is an example depicting the use of Fragments.
To communicate between fragments see this link.
What is the best way to go about designing an Android application that features quite a bit of formulas and conversions? I was thinking that multiple Activities with ListViews sort of like a tree with the leaves being the actual calculations. However, after reading Android design principles it's better to avoid a pure navigational structure and try to reduce the deepness of the app.
For example:
Main Menu
Conversions
Weight
Distance
Distance - Speed - Time
Calculate air speed
Calculate distance traveled
Weather
METAR
TAF
So by the 3rd or 4th screen we've reached the actual individual calculator. Does this make sense? And if it does, is there a better way of designing this (maybe using action bars or tabs)?
By using a very simple UI concept of Expandable Listviews, in which there is more than one child row for each section of the parent row, by tapping on the "Conversions", could expand into sub-rows, likewise for each section as you see fit, and treat that as a Main Menu in a sense of a word, that is, your main application screen.
The nice advantage is that the nesting of the menus in the Android way, is eliminated and can accomodate as many as you wish.
The third or forth screen sounds like it's too deep down the rabbit hole, how about instead having multiple tabs for each "type"?
For example;
[Conversions][Distances][Weather]
If you add an ActionBar to it, you could have a type of filter as the GMAIL app has (where you select the account) and use it to toggle the different "modes" so to speak.
Another approach would be to have it all in one screen, just that you switch the active layout (or perhaps Fragment) via the filter I mentioned above.
Check out the GMAIL app, and you'll see what I mean in terms of the filter. :-)
I'm developing an Android Tablet application with Android 3.1 SDK.
I have to implement a form in an Android Tablet. Now I'm doing on one screen with TableLayout, TableRow, TextView, Spinner, buttons, etc.
At this moment I have more than 80 views and then I get a warning about it.
The form is divided into sections and I think I can divide it into tabs but I don't know if I will have the same problem (I'm very new on Android development and now I learning how tabs work).
What do you recommend me? I will have, probably, 160 view or more.
I recommend that you split this huge form into multiple screens / steps somehow, it seems much more useable and managable to me. You could use fragments to hold the steps, and use some paging mechanism to navigate between these fragments. By switching fragments and saving their state you can keep the number of Views on the screen relatively low.
Check out the ViewPager component for this to navigate between fragments by swiping. Or you may use the plain old button based navigation (next/previous step e.g.).
If you really need to display all the form elements on one screen and want to keep the number of instantiated Views, you may be able to do this by using the virtualizing ListView, though it seems quite awkward to me. ListView constructs the rows as needed during scrolling, and you need to tell its adapter that you have X type of rows where X is the number of form-parts.
Why don't you logically break this Enormous form and using something like a Next button show the form in multiple activities. This would keep the screen clean, won't bombard the user with too much of information and finally won't give the warning of excess views on screen.
I have an app on iPhone with cascading design like on the picture, and I'd like to port it to Android. Is there a simple and recommended way to do this?
The section menu on the left (Section A, B,C,D) is the first that the user needs to select, then the user needs to pick a category in the middle (all, popular, pc, xbox,...), then he is presented with a list of articles for chosen category.
I could imagine doing it with three ListViews, but then the app could also listen to a swipe gesture to make the rightmost ListView "full screen", and hide the first two listviews. I could implement a swipe listener for the whole activity and set first two listviews' visibility to hidden, right?
Are my assumptions correct and would this be the right way to do this?
It could definetly work the way you explain it - if the design is good is another discussion. Personally I'm not a fan of throwing in endless amounts of data in one screen, when the space is as limited as it is on most mobile phones (I would probably do it with 3 different screens with a ListView on each)
Implementing the mentioned swipe gesture is doable and you could certainly just hide the two other ListViews with the function setVisibility( View.GONE ).
Hope it helps.
You might want to use the new fragments API, it's specifically built for this kind of thing (and it's compatible all the way down to Android 1.6). Also, as KasperMoerch says, putting all that info on a small screen can get ugly. Using fragments will make it easier for you to gradually increase the amount of information displayed as the screen size increases.
I'm not sure you can just listen for a swipe gesture over an entire activity like that. I think you have to wrap the fragments in a custom view (for example an extended LinearLayout) and do the swipe listening there. However, achieving a finger-tracking animation (i.e. where the rightmost pane follows the finger precisely as it swipes across) is a pretty daunting task (I wouldn't really know where to begin, probably in the custom view though). The best way (I think) to do it is to make a compromise and just start an animation (right-to-left slide) when you detect a swipe. However, the simplest solution is to not animate at all.
You can also take into consideration dropping the swipe gesture altogether and just providing an "expand" button.