I specified a meta-data in my manifest.xml like this:
<meta-data android:value="5555555555" android:name="foo"></meta-data>
When accessing the meta data like this:
ActivityInfo ai = act.getPackageManager().getActivityInfo(componentName, PackageManager.GET_META_DATA);
Object value = (Object)ai.metaData.get(key);
this value gets interpreted as int and - more importantly - incorrectly interepreted (1260588259).
Since the type is determined automatically by the build system ( booleans, ints, floats and strings ) i wondered if there is any way to force the datatype to string.
I tried adding a space at the end ( "5555555555 "), but then the value gets interpreted as 5.5555553E9 float! ).
I also tried using getString instead of get, but then null is returned.
Any ideas? TIA.
Instead of a space, try using a piece of punctuation that should have no role in a numeric value, like a colon, and see if that helps.
I recently came across this problem and it is a very frustrating that something like a Facebook application id is interpreted as an integer leading to problems due to overflow (of course). I would have thought/hoped it would be possible to override the implicit typing. For example, instead of:
it would be nice if we could write:
In order to compensate for this, I wrote some supporting code that requires manifest attributes to look as follows:
Note that this is intended to look similar to the Android
@string
/@integer
syntax except that I have dropped the@
, interpreting this as dropping the level of indirection.As well as solving the original problem of [0-9]+ always interpreted as integers it seems, it also allows for floats to be specified directly despite looking like an integer.
A further advantage of this is that it is possible to extend the set of types arbitrarily. e.g.
I have also such problem. My solution is as follows:
I added at the end of a variable - eskape sequence "\0" (NULL - is often used to define the end of a character string (for example, in the language C).
This work for me.
Best regards.
Putting an escaped space in front of the number seems to work:
The escaped space doesn't appear in the value returned by
get()
.I have no idea quite how this works, if I'm honest.
If you want something documented and therefore more reliable you can always put your string value as a resource and refer to it: