Currently I have an app which works on Android 1.6 and above, works on QVGA screens upwards. I'd rather not have to rewrite a separate application for Honeycomb and I can't find much help anywhere. Is there an easy way for me to adapt it to work on Android 3.0+ with a proper tablet interface rather than just magnifying my Android-phone interface. I've noticed there is something called fragments, but they seem to involve a major rewrite? Thanks!
As you say, it's all about Fragments. To make a nice app that makes full use of a large screen and of course a small screen the layouts will be different. Fragments help to break up you UI and make it easier to have larger screens use more pieces of your UI (fragments).
Generally it isn't a big change moving from Activities and Views to using Fragments.
Related
I want to add black padding (a thick black border) to the android screen such that every app is displayed with the padding around it. I know how to do this for my app but how do I do this such that when my app is running in background the display is padded?
I don't believe this is possible unless you're willing to create and run a custom ROM.
Thankfully, this is not possible for the average non-ROM third party Android developer.
The screen on mobile devices is actually very limited, and when programming for the mobile environment, you have to learn to get away from the windows metaphor used by traditional desktop PCs.
On the other hand, may be your app could pretend it is running in the background, but still stay in the foreground with its transparency enabled. And perhaps if you can't do something, may be you can find a way to fake that something for your users.
Also, note that the default home launcher is capable of doing something similar to what you want, but only for widgets. And if being able to run widgets is sufficient for you, perhaps you could write your own launcher application that can embed widgets.
I'm writing a game for Android and am laying out the playing screen myself, handling both vertical and horizontal orientations, and haven't done anything if the width and height are the same.
Does anybody know of at least one Android device that has a perfectly square screen resolution?
The MotoACTV is 220x176 (not square but close), the WIMM One is 160x160 (square).
The MotoACTV has been rooted, but the default device runs a customized Android. It's a pretty cool device, though. The WIMM is slick and runs a more-standard Android.
None the I'm aware of. Every device I'm familiar with has a distinctive "portrait" vs "landscape" mode.
It would probably be wise to make sure your code can always gracefully handle portrait vs landscape - even if you ever happen to run across a square device.
Conversely, if you want a square - just "crop" the image appropriately. The cropping, of course, will become "zero" if you ever encounter this hypothetical "square screen". :)
This is a rather late answer to this question, but things have changed somewhat since then, and although there are still no mainstream Android devices with square screens, there are 3 square BlackBerry devices (Q10, Q5, and Passport) that can run Android apps, and so would fall under that criteria. Interestingly, when an app is run on a square BlackBerry Passport, and the device is rotated to its side, the app also rotates, however none of the onPause(), onStop(), or onDestroy() events are called, and so the activity is not destroyed and re-created, but the current activity layout is re-used. So, in that respect, nothing happens, and you don't have to worry about saving/loading resources and such.
This behaviour is actually built-in in Android -- it will only destroy and re-create an activity, if the screen dimensions change. The API docs don't talk about this edge case, as there are no square Android devices, but you can see that the reason for destroying and re-creating the activity during orientation change is to load alternative resources specific for the new orientation. Since rotating a square device doesn't change the screen dimensions, there is no need to load alternative resources, and therefore, there's no need to destory and re-create an activity. I hope that helps.
I believe the WIMM ONE is the only square screen Android device out there. It has capacitive touch display at 160x160.
Yes, the Motorola Flipout is one.
I have to write an app for tablet and for phones too. The two app has the same functionality, but they have absolute different GUI.
For example the phone have 2 button on the main screen, but the tablet going to have 5, because we would like to use the space what we have. I know, I˜m able to define different layouts, depends on dpi, but how should I handle the layout-s in the Activiies? I think, to use if(sdkVersion >=11) bla..bla... is not will works through the hole code and the hole project! Is this the situation where I have to use multiple application support ?
readed articles:
http://developer.android.com/guide/practices/screens_support.html
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
http://developer.android.com/guide/market/publishing/multiple-apks.html
I don`t understand how should I handle this problem... please if you able help , thx
Put your tablet layouts in res/layout-large/. Put your phone layouts in res/layout/. Name them the same. Your activities will load the right ones based upon the device they run on. When you call findViewById() to retrieve the extra buttons, and see that you get null back, ignore them.
You may need additional layouts in places like res/layout-large-land/ (landscape for tablets), res/layout-xlarge/ (if you want to handle 10+" tablets differently than stuff in the 5-9" range), res/layout-small/ (if you want to handle <3" screens), etc.
I am hoping to save some time with a project and wonder if this is possible to do.
Currently there are some android phone screens that have already been developed by a former colleague. I am developing a new screen for a tablet that needs to have the content of an existing screen that he developed appear as a sub-screen (say a little box in the bottom right corner of the screen. This is aesthetically ok because the existing screen is small (phone). The screen I am developing is for a 10.1" tablet, so it only takes up a tiny portion of my screen.
However, the problem is that he had the screen all coded up in a nicely and integrated with an associated Activity. I am hoping to just reuse it by calling an Intent from my screen/activity unit, modifying it as little as possible.
QUESTION: Is it possible to have an activity appear as a subscreen of another activity?
Mind you I know that you can launch a fire and forget activity from one screen with an Intent + startActivity(). But that will only take the new screen appear on top of the old screen.
Where as I want the new screen to appear as a subscreen of the existing screen. Any idea?
All pointers and recommendations are appreciated. TIA
You're looking for Fragments!
From the Android documentation:
A Fragment represents a behavior or a portion of user interface in an
Activity. You can combine multiple fragments in a single activity to
build a multi-pane UI and reuse a fragment in multiple activities. You
can think of a fragment as a modular section of an activity, which has
its own lifecycle, receives its own input events, and which you can
add or remove while the activity is running.
If you're developing for devices running Android versions prior to 3.0, take a look at the compatibility library, which allows the use of Fragments in versions 1.6 onwards.
Further, if you're developing for phones and tablets, you can reuse the same Fragment in both interfaces.
Is there any way in Android to determine whether a device is running Sense UI? I'm working on an app that is working fine with vanilla Android, but Sense UI is messing with layouts and sizes. I'd like to be able to see whether the device is running Sense UI and so I can take appropriate action.
There is nothing built into Android that indicates what sorts of modifications like Sense are running on the device. You would either need to use PackageManager to look for HTC Sense components or use the Build class to determine what model device you are on. In either case, you would need to keep updating that "sniffing" logic as Sense is changed and is rolled out to new devices.
but Sense UI is messing with layouts
and sizes
If you have a reproducible test case with source code that demonstrates these problems, I would be interested in seeing it.
There are only two scenarios I can think of that would fit your description:
App widgets may display differently on the HTC Sense home screen, just as they may display differently on other home screens. Ideally, there would be no modification, but since you are running in another app's process, I can't rule it out.
If you rely on android.R resources, those might have been modified by HTC as part of creating Sense, though you can always grab the standard ones from your SDK and ship them with your app.