The way that Android implements Locales (from my understanding and readings) will leave your apps mis-behaving and acting oddly for users if you need to access cross-region features in your app while in another country.
A Real World Locale Problem
Imagine the scenario where your sell products pertinent to a location, like daily deals (think of any daily deals app).
Assume you’re currently in the USA and you have a family member living in Germany. You decide to open the deal application and view the deals in Germany because you want to purchase a deal for that family member. If you’re looking at a deal in Germany you should see the deal price information (and date/etc) in the German context, as this is where you’re buying it (yes, this is up for argument, but assume this is how the APP HAS to show it).
These deals SHOULD show you the deal information in Euro’s and the date formatting should be as you’d see it in Germany.
Unfortunately this is not the case with Android. It MAY or MAY NOT be formatted correctly. With Android you cannot guarantee correct formatting when using the DateFormat and Currency objects as you’d normally do in Java.
Why?
Its pretty simple actually (and makes sense, but it does suck) …
Android (as with other mobile OS’s) is an operating system that runs on embedded devices. Android’s runs on as many different mobile devices created by numerous different manufacturers. Due to size constraints, only certain Locales are loaded on the device. For example, a friend of mine has an incredible 2 device which has 17 languages (basically multiple Locales) while one of my test devices (Samsung Vibrant) has only 2. The Nexus S has been reported to have 39 Languages (many many locales). The larger, newer devices have more locales.
Example
So what happens when your device does not have a locale and you request it with code like this?
Currency.getInstance( “BRL” ); // Brazilian Real (the currency for brazil)
When you format items with this currency object the result is not what you expect. Depending on the device, the currency symbols are in the wrong location and sometimes certain currency symbols are incorrect altogether (i guess that would be gracefully degrading, not sure what to call it).
Solution
At this time I don’t have a great solution. I really hope someone (either a Googler, or another Android dev) will come along and point out that I’m wrong (but I’m fairly certain there is a problem with this somewhere). The only solution that I have at this point is to implement formatters for the known locales that my app will be dealing with. This means creating my own DateTime formatter, currency formatter and other formatters. While not a HUGE pain in the butt (Java’s not that hard … ) its still a nuisance because its not well documented anywhere that I can find.
You are correct. It is up to the phone maker and the telco to decide what locales are on the device and that decides what can be displayed. While reasonable due to storage constraints and so on it is also a problem for an app dev since nothing is guaranteed.
Implementing the formatters is a good plan and not too big a deal. On the other e.g. if you want users to be able to choose the locale the run the app in even if the OS is using a different locale you are up for some phone. E.g. look at how k9mail allows you to set the UI language independent of the language setting of the operating system. Now if you change e.g. to chinese on a phone without chinese characters/fonts installed you are up for some fun.
To at least give you warning, you can validate what locales are on the phone using Locale.getAvailableLocales() or by verifying that when creating a locale that either the the language or the country value is not null.
You’d still need a formatter for non-installed locales, but that would allow you to use the Currency class for Locales that are supported (unless you’d prefer a non-hybrid solution).
True. Thanks for the comment 🙂
The issue is that if I cannot be 100% sure that the locale is present then Ill have to implement my own formatter anyway (because I know in advance what locales my app has to support). At that point why even use a hybrid approach? Know what I mean?
That makes the most sense. The only reason I see for the hybrid approach is if you plan to gracefully degrade (or simply disable) other features that you can’t implement yourself (e.g. languages).
I’m sure android fans woun’t get dissapointed, as provider work hard on useful updates.
You will find 2011 Pro Bowl Jerseys is the best resource for the best deals on everything Internet makert. While the Cheap authentic NFL jerseys can be difficult to find. That’s for there so as tons of imitators as well as knock offs currently available. The good information is that you can easily spot the difference from a cutting-edge cheap Washington Redskins Jerseys along with a knock off, before you decide to shell out the money and now it’s as well late. Keep these ideas in your mind when you’re buying authentic NFL jerseys to ensure you end up with the genuine article.All trustworthy Wholesale Cheap authentic NFL jerseys tend to be manufessentired by Reebok. That’s the underside line, some additional breast supportnd title clwanting to haudio-videoe brand new trustworthy cheap New York Jets Jerseys is actually feeding you is. Reebok hwith respect to exclusive license bringitionallyy’re the only real legit source with this era.