The emulator that comes with ADK for use under Eclipse is fine for testing basic Android application functionality, but:
it's not very performant
it doesn't reflect real-world hardware and software configurations
it doesn't support varying input devices such as d-pads, touch screens, trackballs or even Bluetooth/USB controllers.
Android Developer posts some very helpful rolling graphs of Platform versions, Screen sizes and densities, and OpenGL ES versions as extracted from Android Market:
http://developer.android.com/resources/dashboard/platform-versions.html
http://developer.android.com/resources/dashboard/screens.html
http://developer.android.com/resources/dashboard/opengl.html
Those really help to narrow the scope of some of the choices, but I find myself really wanting to know what the proportions of input methods various devices support are... is touch represented by 90% of the market, or only 5%? What proportion of those support multi-touch?
For example... anyone who has played the free and open source game Replica Island ( http://replicaisland.net/ ) will know that how you control the game varies between devices because it supports multiple input methods. I think Chris and Genki have done a fantastic job here, but if you use touch screens you know that the game is much more playable on 5-7 inch devices than it is on 10+ inch devices. This is because the left-right slide control doesn't maintain the same physical size as the screen size increases - meaning that you have to move too far on large touch screen devices (such as Honeycomb tablets) to be comfortable.
These are the sorts of issues you only find out when you start using various hardware devices to do your testing on. Or you can wait until users do your testing for you and start bringing your app ratings down.
So after my long introduction, here are my questions to you:
What collection of hardware devices have you bought to use in your software development and have you found those choices to have been beneficial or detrimental?
Do you instead use 3rd party testing services and just tolerate the long turnaround times between test reports (hours/days instead of instant gratification)?
For me test devices are sort of like pickup trucks: I'll make friends just to get access to their phones ;-)
Seriously, I do tap friends and family as resources. I'm a small shop and can't afford to buy a lot of test devices. Yet even with this limited pool of resources I've go the following devices available and it seems to have served me well:
Original Moto DROID (seems like such a dog now).
DROID Pro (broken screen but still good for testing).
Asus eTransformer
Samsung Galaxy Tab (7")
HTC Rezound (my personal phone--it rocks)
Samsung Charge (my wife's phone)
DROID X (son-in-law)
HTC-something I can't remember right now (daughter & son)
Amazon Kindle Fire (father).
So, as you can see, without spending a fortune I've got a pretty good set of test devices, not counting all the friends I press into service as beta-testers. With all those I really haven't had many problems with platform specific issues. I hear a lot of grumbling about fragmentation (perhaps mostly from iOS developers), but if you develop your app intelligently it isn't a huge issue.
At this stage I'm just testing with two phones:
HTC Magic (3.5" touchscreen)
Samsung Galaxy S II (4.3" touchscreen)
There's a pretty big difference in the perceived density between these phones, so it's been helpful for comparison in testing my own games. The major omission at this stage is a tablet - just haven't been able to justify the cost yet.
I'm also playing around at the moment with LCDDensity for Root which allows you to change the screen resolution on-the-fly. Interesting to see what the same sized screen would look like with more pixels stuffed in (i.e. closer to Retina display)
I have own collection of devices:
tablet with 10" screen (Motorola Xoom);
Nexus S as reference smartphone;
device with hardware keyboard (Motorola Droid);
one device from HTC (HTC Desire HD). I need it because it has slightly different UI (HTC Sense) and HTC phones are quite popular in my country. It is the least useful device in the collection;
a pair of devices with non standard screen resolutions.
Related
I am working on an android Audio Recording application, our app is currently designed to work on all android phones, the Nexus 7 and the Motorola Xoom tablets.
I was wondering if there are any guidelines or best practices to re-design/modify our app for Nexus 10. More specifically, any pointers on the below points would be really helpful:
UI guidelines to support the new 2560x1600 resolution
Android resource files related modifications (based on similar guidelines)
Any sample or open sources apps that have been modified to work on the nexus 10
Best practices creating and running a nexus 10 emulator since there is no such AVD device by default (screenshot below). Any thoughts on creating one, keeping the high resolution in mind.
As long as you have xhdpi assets, and layouts made for 10" tablets, you shouldn't have to do anything (except add a new xxhdpi launcher icon, as #Mattias mentioned).
To make a Nexus 10 AVD, navigate to Device Definitions:
Then, click New Device. Fill it out something like this:
Now it will be listed in the devices drop-down that you show above.
Regarding your second point, resources:
While the nexus 10 is a xhdpi device, it will use the launcher icon from xxhdpi "one bucket up" if available, so make sure to provide one as it will look much better/clearer/sharper. Reason is that there is room for a bigger icon on this device. Launcher icon size at xxhdpi is 144x144 pixels.
For reference see:
https://plus.google.com/118292708268361843293/posts/ePQya3KsTjW
The best way to emulate the Nexus 10 is to use AndroVM. I am currently running Android on it with the full Nexus 10 2560x1600 resolution and it fits onto my HD screen if I set AndroVM to use 320dpi.
Oh.. and it's VERY fast :-)
I personally use it over emulators and real hardware devices as it's extremely responsive and the deployment of the APK is lightning fast.
I do not contribute to the AndroVM project myself by the way, but it has speeded up my own development cycle considerably. In all development cycles, a developer waiting to see if their code tweaks work using an emulator or a hardware device adds considerable time overhead. I would thoroughly recommend using AndroVM regardless of screen size during normal code development.
I made an application under Android emulator provided worked perfectly on all types of dispositives (small, normal, large, xlarge) (-ldpi,-mdpi, -hdpi,-xhdpi). But the last few days I saw that in some phones with the latest versions of android (these phones consist with a lower bar like tablets) did not look properly.
So my question is: what kind of phones have or can upgrade to these versions of android? (small-HDPI, normal-HDPI, normal-xhdpi???)
Thank you!
Theoretically, nothing stops a manufacturer from making an ldpi device capable of running ICS or JB. However, in practice, most devices with ldpi and even mdpi to some extent do not have good enough processors in both CPU and GPU departments to be able to run the newer version of Android.
Till date, the lowest I've seen an ICS device go screenwise is a normal-mdpi display. However, I do not know the details of every device in existence, and there could be lower devices as well.
You should design your app keeping in mind all device configs, at most excluding only ldpi and small displays.
I encountered a weird behaviour when starting to test my app on some 7in Android models and I would like to find out if others are finding the same problem and what people recommend as a fix.
Here are the details:
The application has full tablet support, which is triggered with qualifiers for the layouts. xlarge devices get the tablet mode with multiple fragments being displayed on the screen.
For newer Android versions there are also some values that set variable that change the UI on the flow using the sw600dp qualifier as well as the xlarge one.
The problem:
I am now testing on the Kindle Fire and the RIM BlackBerry Playbook and also want to support the upcoming Google Nexus Tablet (or whatever it will be called) and other 7in form factor devices.
Both the playbook as well as the fire have a 7in screen and a 1024x600 screen resolution.
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Both the tablet as well as the standard UI work fine, but imho the tablet mode is nicer and is fine to be used on the 7in device. However if I push the layout into the large qualifier to also get that tablet mode on the fire I will also get it e.g. on the Note or other quite a bit smaller devices.
With Android 4x I can use the sw600dp and other qualifiers but what about older versions? I assume a 7in device is supposed to behave like a tablet but what about e.g. the Note..
What are best practices for this scenario? Are my observations with the playbook reporting xlarge correct?
However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.
Device manufacturers are the ones who choose which buckets a device goes in with respect to size and density. This goes double for manufacturers like RIM and Amazon, who do not want the Play Store and therefore do not have to abide by any particular compatibility requirements the Play Store dictates, so they are welcome to thumb their noses at Google's guidance.
What are best practices for this scenario?
I can't tell you "best".
However, if there are specific devices for which you wish to override some layouts to use a specific size, here's what I would try (assuming the layout you would be using for normal cases is known as R.layout.main):
Step #1: Create res/layout/main_funky.xml as a symlink or hardlink to res/layout-xlarge/main.xml (and likewise for -land, etc.).
Step #2: In your Java code, wherever you refer to R.layout.main (e.g., onCreateView() of a Fragment), decide whether to load R.layout.main or R.layout.main_funky depending upon android.os.Build data to detect these oddball devices by model. Since R.layout.main_funky is one of your normal main layouts, all of your code that depends upon widgets should be unaffected by this choice.
Step #3: In your particular case, add MMPD (magic Maven pixie dust) to steps #1 and #2... :-)
Are my observations with the playbook reporting xlarge correct?
I bought a Playbook, determined that RIM's distribution model is... unpleasant, and did the bare minimum to have a book chapter on it. I haven't tried to see if it is -large, -xlarge, or something else.
That being said, the NOOK Tablet IIRC suffers from this (claiming to be -xlarge rather than -large).
I would expect a Google Nexus tablet, if such a thing comes to fruition, to correctly honor size buckets, plus be running a new enough Android version that -sw600dp and kin will work.
I wonder how other people handle this issue, and can't seem to find a definitive answer.
I am doing a JSP redirect for a mobile version of a website, and things are working fine for other platforms, but Android presents an issue. According to the comments in the answer of this post, can one really infer that simply targeting mobile in the User Agent string will target Android devices and exclude all Android tablets? I would love to hear a resounding "YES!", but would also like to hear different angles on this.
I was considering using screen resolution if the User Agent string contains android, but am wondering how much longer that will continue to be a good gauge. We are seeing a variety of tablets that don't have the real estate of an iPad, but are definitely bigger than a Smartphone size. I also think it won't be long before we see phones with resolutions of 1280x800, considering some of the in-between devices we are starting to see.
According to the comments in the answer of this post, can one really infer that simply targeting mobile in the User Agent string will target Android devices and exclude all Android tablets?
Well, it's what Google tells you to do.
I would love to hear a resounding "YES!"
<resounding>YES!</resounding>
(moving this into a <span> with resounding CSS is left as an exercise for the reader)
We are seeing a variety of tablets that don't have the real estate of an iPad, but are definitely bigger than a Smartphone size.
That's probably difficult to address via a pure server-side redirect. There are instructions for targeting different screen sizes for Web apps, but they assume you're doing the work on the client. The mobile or not is a very coarse-grained solution. I'm not aware of a reliable user-agent way to determine screen sizes or densities.
I also think it won't be long before we see phones with resolutions of 1280x800
The HTC Rezound is 1280x720 (i.e., 720p), as is the Galaxy Nexus, AFAIK.
I want to begin development for mobile and android seems like a good choice (with iphone requiring a mac and WP7 not being that popular).
I have a question regarding the testing platform, I'm pretty low on cash and have been wondering if using a mid range phone would hinder my development? I have the ability to buy either a LG Optimus One, a Motorola Milestone or a Nexus One, all representing different segments of the market and each one costing more than the previous.
two concerns I had were screen resolution and CPU power, how much does these two variables matter to development?
Well:
Resolution - there are 3 main groups:
ldpi - Low Density - devices with screens 240 x 320,
mdpi - Medium Density - 320 x 480,
hdpi - High Density - 480 x 800, or 480 x 854.
Of course the bigger screen == the more expensive phone.
2 . CPU power - all currently available CPUs (besides a few low-end phones) will propably serve you well (of course, it depends on what do you really want to do)
I, as a developer, would like to add here a third element - which API level (version of Android) are you targeting? Nowadays, 2.1 - 2.3 rocks, and 3+ if the device is a tablet.
Keep in mind, that if you buy a great phone, you may develop application which will be running quite fast on it, but it will not on other low-end devices. Btw, you can always check if all elements will properly layout on the lower screen using built-in emulator(s). So, in my opinion, there is good to have mid-end phone, just to check sth(s).
PS : Nexus one - AFAIK this phone is a debug version (means you can do a little more than with a standard retail phone :) ).
If you can buy a Nexus One that will serve perfectly. Obviously it doesn't cover every form factor but its BETTER than a midrange phone.
If you come across issues on a specfic device you can always use a cloud debugging service like:
http://www.perfectomobile.com/ (they used to have 2 hours free when you register)
You can emulate the different screen sizes
CPU power depends completely on what you are coding, but most the time you should be ok.
Me Personally I've got:
a Nexus One running 2.3
a HTC G1 running 1.6 (flip out keyboard formfactor)
I also use perfecto for issues with the SonyErricson X10mini (ldpi)
I emulate Honeycomb 3.0 on the PC (altho hoping to buy a XOOM soon).
Putting on my MBA hat: From a product development perspective it's probably a good idea to make sure your product runs on the widest product segment of whatever platform you're developing for. If that happens to be a mid-range product, your development efforts are probably aimed at the largest market segment and potential customers might be more likely to own/purchase this device. Even better if there's a common platform across all segments. You should probably perform some sort of market analysis to prove this out.