Develop Reference

How to parameterise all strings in android application

I am building an application and I am thinking of how to "parametrise" all the strings in the application (is it even possible) in order to allow me to change them easily without "redeploying" it again ...
meaning it will be somewhere in a file with strings (something like you have PO files in PHP when using templates and different languages) where I can manage it ..
it might be useful when I would like to use different languages :)
I am kinda struggling on this one, so I was thinking if you can give me a clue or show me where to "go" to study how this should be implemented ..
Thanks

If you want different langage in your app, create as many strings.xml files as you need. However, when you add new strings file, you have to redeploy.
To avoid that, you should call a specific API in backend which send you all the texts according to the langage of the device. For that you must manage back and front.

So if I understand your question correcly go to res - >value folder -> strings.xml - > open it and you will see something like this:
<string name="app_name">this is your app name</string>
And now every time that you want text to be "this is your app name" all you need to do is to add this line:
android:text="#string/app_name"
And when you will change the actual string in strings.xml it will also change in every place he is being used (android:text="#string/app_name")

Android has a built-in mechanism for localising assets (Strings included)
https://developer.android.com/guide/topics/resources/localization#creating-alternatives

What you are trying to do is known as 'Localisation', this can be helpful if you want to give users different language support and similar kind of stuff.
In android, this is done by putting all the strings in the Strings.xml file located in the res folder.
If you're using android studio, just press Alt + Enter on any hardcoded string and then select 'Extract string resource' from the popup, give the name of the string and Voila! you're done.
It is also a part of good coding practice, in fact you've might have noticed 'Lint warnings' in your layout files if you type any hardcoded string, and it asks you to add this string in the strings.xml file
You can create a separate String file for each language that you wanna include.

Option 1
Using the Default Built-In Mechanism
You already have answers about this or you can read the official documentation about it.
Essentially, you maintain an xml file called strings.xml which is a key-value of Strings. Each file (one per language) will be located in a values folder. E.g.: for french, you'd want values-fr/strings.xml. Each file will include all the translated strings. If a value is not found in French, then the english file will be searched instead as a fallback. If the key is not there, the app will crash (if I am not mistaken).
Pros
Included with the system
Supports many languages
Packed at compile time, always available.
Cons
Resources are "read-only" once they are compiled; you cannot change a string and save the change this way.
Option 2
Roll your own Thing.
If you need to be able to dynamically alter these strings, you'll need a few key pieces:
A way to obtain/download said strings.
A default in case step 1 fails (what if the user cannot download them?) You need defaults.
To ensure every widget that needs to display text, calls your own creation of a class that can manage said dynamic strings (i'll elaborate down below)
You need to know what to do if a String is somehow magically missing; because this is dynamic, there has to be a fallback in case the string is not found (see 2)
This has to be relatively fast (you don't want expensive lookups when constructing strings and UI elements).
Pros
You can model this the way it works best for you
You will be able to load strings as you see fit and even change them at runtime.
Cons
You have to build all this.
It's error prone, and most likely slower than the native solution.
You must ensure you don't miss strings and that you have dafults.
You must modify normal widgets (say TextView) to understand how to fetch the strings (or you must always provide them), and this is not going to be automatic, you'll either have to delegate or subclass into a YourCustomTextViewThatUnderstandsYourStringThing extends TextView (name... is just a draft ;) )
You must ensure you don't leak memory by keeping strings in memory you don't care anymore.
If you want to "persist" these downloaded languages (and you should), you have to write/use your own persisting mechanism (either by writing the files or by using some database, shared preferences is not the place for these).
You need to cache them (see above) and manage the validity of the strings (what if they become old, can they become old? when should you re-fetch them?)
etc.
As you can see it's not trivial and each app has its own world of problems to solve, but that's roughly what it means.
As for "code"... the simplest way I can think of (or rather, the bare basics) are:
Find a way to "store" the strings: e.g.:
Map<String, String> oneLanguage
So in this Map, you store the KEY (to find the value) and the VALUE:
oneLanguage.put("app_name", "My Super App")
Keep all the strings in one place in memory:
Map<String, Map<String, String>> allLanguages
so then you do:
allLanguages.put("English", oneLanguage);
Now you can add other languages:
anotherLanguage.put("app_name", "Mi Super App"); //my Spanish is top-notch
allLanguages.put("Spanish", anotherLanguage);
Now you have a place where to store (in memory) all your keys/values for each language.
When you want to retrieve Spanish, you'd have a method like:
String getString(#NonNull String locale, #NonNull String key) {
return allLanguages.get(locale).get(key);
}
And then you'd need to (either manually or via subclassing or whatever approach you find more convenient) to set these strings like:
// I mean, don't hardcode the locale... but you get the idea.
appNameTextView.setText(yourLanguageManager.getString("Spanish", "app_name"));
What approach you take for this last step, is entirely up to you.
As usual, all the above is pseudo-code, and not a complete solution to this approach. Things you want to do: ask the device what locale is using, keep track of which locale is in use (so you don't have to pass it every time), fetch these locales from your server (not pictured) :), persist these to disk, as well as save in shared preferences, the "locale" key that the user has selected, add methods to your yourLanguageManager so it can have things like:
boolean updateLocale(String locale, Map<String, String newStrings)
boolean deleteLocale(String locale)
Map<String, String> getLocale(String locale)
etc.. you get the idea.
All in all, it's just a simple data structure that can contain keys and values.
Good luck!

What does this expression mean : "R.string.gcm_registered"?

I am trying to enable push notifications on my application.
I have the client sample code and now i am trying to get some of the code to implement it on my application. For those of you who have already implemented push notifications on your apps i am sure you are familiar with the class GCMIntentService.
So i am copying this class on my project , i configure the Manifest correctly(or i think i do) but i get errors in the file.
The errors are in expressions like R.string."something"
For example I get errors in :
R.string.gcm_registered
R.string.gcm_message
R.string.gcm_deleted
R.string.gcm_error
R.string.gcm_recoverable_error
R.drawable.ic_stat_gcm
The error is always that gcm cannot be resolved or is not a field.
But what exactly is this expression?! Is it a class or something?
Is it something on the Manifest that I haven't configured correctly?

It are strings, probably in the example app you're using, in /res/values/strings.xml
You put strings in there to have a localized place to put your user visible Strings in, so you have
1. One place to find all your strings, if you ever want to change and/or re-use
2. Easy access to translation by putting translations in per example /res/values-de/strings.xml
Look for that file in whatever example you're using, you'll find some XML defined strings. Copy them into your own project, in the same place.

this may helps you ,define all Reuired String in your strings.xml and save
R.string.gcm_registered
R.string.gcm_message
R.string.gcm_deleted
R.string.gcm_error

Android String File equivalent in iPhone(Monotouch)

In android we have files by name String. Developers define the string values that they used for naming objects in this file. This is a very useful way. Because avoid of hard coding string values(you can change them from a single file, less time to change), also useful to creating multi language application and etc. (for more info just google this).
But the question is this: whether iPhone(Monotouch) have a mechanism like this to define strings on them or developers have to define themselves mechanism for this?

In XCode, you'll find File/New File, then on the left, pick "Resource", and you'll find "Strings File".
From code, you'll be referencing the keys in your strings file with NSLocalizedString:
NSLog("%#", NSLocalizedString(#"YOUR-STRING-KEY-OR-DEFAULT-VALUE", #"Comment about what this is"));
For details on what that second param is for, What is the second parameter of NSLocalizedString()?

Put your strings in a single file. Make them global constants. Access them throughout the app. When you change these, the change will be reflected everywhere.
It's not a big deal to have persistent string references throughout your app. It can be done in any decent programming language and platform I suppose.

Still uncleared on the dex format

I had read the .dex format document on Google, but I still got some confuses with some layer.
link_size & link_off : Google said it left unspecified and then said it's hook for runtime, so what it is? The static hook for global or local? or the hook to native library?
map_off : Why it need this redundancy IDs list? is it some kinda like the file address table?
proto_size & proto_off : Not quite sure what it actually is. I had de-assembled an randomly picked dex and look on this section, this section contained some short sign like DD/LL/JLJJ/...brabrabra, that made me more confused about this section. What exactly this section doing for?
Can anyone enlighten me?

The link section has never been specified or used. You might run across some dex files that have a garbage value for these fields, as an attempt to prevent baksmali from being able to be run on them (due to an old bug, that has been fixed for a while).
For the map item, Yes, there is redundancy for the locations of the indexed item sections - the location for these are specified in both the header item and the map item. But the map item is the only place the locations of the offset item sections are specified (the variable size items in the data section)
The prototype section defines the prototype for a method, i.e. the parameters and return type. If you look in the method_id_item, you'll see that it has a reference to a prototype item.

Get a (Android.Graphics) Path of a String

I cannot find any way to retrieve a Path object representing a string. Does it exist? A list of the necessary points would be enough, but I guess, internally, a path is used.
For example in GDI+ there is:
GraphicsPath p = new GraphicsPath();
p.AddString("string");
From there any point of the "drawn string" can be accessed and modified.
PS: I do not mean drawing a text along a path.

I've spent quite a long time solving this problem (to draw vectorized text in OpenGL) and had to dig deep into libSkia sources. And it turned out pretty simple:
Indeed, canvas uses paths internally and it converts text to vector paths using SkPaint's getTextPath() method. Which is, luckily, exposed at Java side in public API as android.graphics.Paint.getTextPath(). After that, you can read Path back with android.graphics.PathMeasure.
Unfortunately, you can't read exact drawing commands, but you can sample the curve pretty closely using something like bisection.