I'm currently designing a digital menu application for Android tablets.
Here's how we are currently working: each restaurant receives a number of Android devices with our application installed (mostly 7 inches tablets) - they are low-end devices of various unknown and weird brands. They are all 4.0+, though.
We tried our best to optimize the interface based on a 7" 1024x600 testing device, using dp and sp units. Unfortunately, there are a lot of models that behave differently from this one despite the fact that they have exactly the same physical size and resolution! Actually, I did not find any device to behave the same as another... how is this possible?
Another great issue is instability. Even after exhausted testing on some models (some low-end, some high-end - such as Samsung's latest models) showing no exceptions or errors at all, we find some tablets randomly crashing with no apparent reason - same setup, same app, different tablets. Many times it is impossible to know what caused the crash, since it won't happen on a developing environment and there's no log; also, reproducing the steps that led into the crash won't result on any problem whatsoever.
My question is: are those problems sitting on the low-end tablets manufacturers' hands or is this somehow related to the way we are developing? Are those issues manageable at all?
Related
I am facing a weird issue, which is already driving me crazy, so ANY help is most welcome and appreciated.
I have created an Android application, which is working quite fine on all kinds of phones and tablets, but on some Galaxy S3 devices, the images are not loaded at all.
Here are the facts, both from myself and information that I gathered from the complaining users of the app:
all images are packaged in the application, in the drawable folder, so accessible from all resolutions
the images are referenced either by mypackage.R.drawable.image_id, or directly via #drawable/image_id in the XML
the images are semi-transparent and are stored in .gif format
there are about 40 images altogether, each is 25x25 pixels, the "largest" is 1.25Kb
for now I have got only complaints from S3 owners
the issue occurs on the standard OS and not on custom roms (at least I have no info about custom roms)
at least one S3 owner, who is facing the issue, claims that his phone is updated to the latest Android version
on many S3 devices the issue is not reproducible and the application works as designed
I am testing my apps on S2, S3, HTC Desire, Sony tablet S and of course the emulator - on all those I am not able to reproduce the issue
I am using FrameLayout, where the main drawing area takes the whole space, the controls (where the images are used) are packed in a LinearLayout, which is floating above
Here is a link to the application on the market:
https://play.google.com/store/apps/details?id=com.rts.android.spacesim&feature=search_result
This is NOT intended as some weird way to promote my app, if you are an S3 owner and decide to check if the issue is reproducible on your device, please write a comment here if it is and if not - what do you observe.
My questions are:
have anyone observed such an issue?
any ideas how to overcome it?
The following links suggest that GIF support might be broken again on 4.1, which most Galaxy S3's are running if I'm not mistaken. My personal phone is a Galaxy S3 at the moment, and I have 4.1.1 on it
GIF doesn't display on Samsung Galaxy Note 2
http://code.google.com/p/android/issues/detail?id=3422
Why not use png?
Recently, we had released an app. Before we releasing, we tested it on Samsung Nexus S, Samsung Galaxy S and Samsung Galaxy Tab.
However, recently, we realize our app cannot detect the front camera, for users who are running HTC EVO 4G Cyanogen 7
I was wondering, how do you guys start to debug on such edge cases, without purchasing new hardware?
The joys and sorrows of platform fragmentation, especially where custom firmware is concerned. The short answer? You can't test all the edge cases, and you'll certainly never catch the CM-derived defects. It's the nature of the beast. Even independent branches of the CM baseline do their own things that may entirely break something (e.g. the front camera) or get something else working (.e.g the CPU sleep). I mean, think about it: custom firmware is by definition custom. I could have -- and do! -- my own branch of CM7 that I could do anything in the world with. I could make it so that it ignores the ldpi resources altogether and always pulls hdpi, regardless of dot pitch or anything else. And, more importantly, I could completely screw it up. Unless you run my branch, you won't see that behavior.
The best you can do is program for the largest platforms (targeting API level 7 currently nets you about 99% of the overall market) and then wait for the edge cases to be reported and handle them as quickly as possible. Acquire devices that can cover the vast majority of platforms based on your spending resources. Elect beta testers to receive early builds on esoteric devices or firmware.
Then keep your fingers crossed :).
I have an LG phone (OS 2.2.1) and an original Droid X phone that I use for testing my app on. I prefer testing on actual phones over the emulator or say the Android-x86 and VirtualBox. Is it worth it to also test on other Hardware Manufacturer's phones like Samsung or HTC? Are there any serious discrepancies on other vendor's phones to consider? -Mike
YES, there are. Here are a few examples, off the top of my head:
Motorola saw fit to change how phone birthdays and other dates are stored in contacts, from a string as in "YYYY-MM-DD" to an integer value with a UNIX timestamp. MotoBlur phones only.
Motorola also messed up the FLAG_BLUR_BEHIND window flag, at least one some phones like the OG Droid. Using that flag will render your activity all but unusable since a screen refresh will take a second.
HTC phones (mostly Sense-based) have issues with date handling, so using SimpleDateFormat may not work in the same way as others.
Your notification icons (especially if they have gray tones) might look weird on phones with custom skins, like HTC Sense phones.
So, yes - definitely check your phone against as many different vendors as you can.
As a general practice, I try to test on as many phones as possible. Sometimes phones (especially oddball mini-form phones) can have unexpected screen resolutions that might mess with your layouts if you hadn't accounted for them. But, yes, if at all possible, test on as many physical devices as you can.
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.
I have a G1 and an HTC Hero handset. All the applications that I've written were tested only on these devices; come new SDK and Android handsets with (support for) different screen resolutions, densities and capabilities I have been asked to estimate the efforts required to port some of the application to new Android handsets such as Droid, Nexus One etc.
I know that making such an estimation would depend a lot on the application that is being ported, what device capabilities it uses and assumes and the way it is written.
This question is an effort to highlight all the things that a developer needs to consider(in general) when making such estimates. Please help.
Thanks.
In general, you're going to want to consider the following issues:
Resolution - different resolutions will cause your UI to look different than the original.
Input methods - not all phones have keyboards, some might be missing some other keys, etc. Think about the different possible configurations and how the user would interact with your application in each of them.
Performance - on some devices you might have performance issues that you do not see on the G1.
Device specific bugs/issues - this isn't really something you can "estimate", but it's definitely something to consider.
Of course, some of these may not be relevant for your application or the devices you intend to target, or you may decide that they aren't important enough to change.
EDIT: Another thing I forgot - if you're using native code in your application (don't remember what it was called, NDK?) it may not run on all devices.