[TIMOB-7741] Anvil: android/android_string and locale fail on Droid 1
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2014-04-07T21:09:00.000+0000 |
| Affected Version/s | Release 2.0.0, Release 2.1.1 |
| Fix Version/s | n/a |
| Components | Android |
| Labels | core |
| Reporter | Ping Wang |
| Assignee | Allen Yeung |
| Created | 2012-02-21T16:01:16.000+0000 |
| Updated | 2017-03-21T18:10:12.000+0000 |
Description
Run drillbit test -> string and locale on Motorola Droid 1.
Failure info for string test:
stringFormatDecimal false 237 should be: "5.123,33", was: "5123.33"
stringPPEnhancements false 14 should be: "2,5", was: "2.5"
Ran Anvil test on Droid One with 2_1_X branch. Those two tests are failed.
This is a known issue coming from drillbit when we run it on droid 1 and apparently also exists on anvil as well.
So the issue is not reproducible on any of my hardware including a Droid 2 but the issue seems clear based on my research into the problem. There are two problems here: 1) We can't perform conversions based on Locale if the Locale is not present on device 2) If a Locale is not found, the default Locale is used as a fallback but there is no notification to the user There are a few paths that can be taken with this problem. One is to use http://developer.android.com/reference/java/text/DecimalFormat.html for defining custom numeric conversions for Locales. Note that NumberFormat will not support custom Locale providers (http://developer.android.com/reference/java/text/NumberFormat.html#getAvailableLocales()) so the use of DecimalFormat is required. If this route is taken we should both A) define a common set of Locales that we ship with the platform along with B) supporting a mechanism for developers to define a custom Locale conversion Another route is to only utilize the default Locales that the device is meant to support and instead provide a means to notify the user in the event of a conversion "failure" along with utilizing a fallback value. Parity discussion is required on this as basically we are talking about a new feature and ideally a robust look at the Locale handling with various additions to the overall localization API's. To see the meat of the implementation, refer to TitaniumModule.java and TiPlatformHelper.java. Moving to Sprint 21 for discussion.
We no longer support the Droid 1.
Closing ticket as the issue will not fix.