We want to implement the following requirement for localization -
The parameter values stored in strings.xml (and other language variants) need to refreshed periodically (almost daily). This is because of some dynamic texts that needs to be displayed based on the language. The entries in the strings.xml can be added, modified or deleted. The values are fetched periodically (based on defined refresh policy) from a backend api call.
If my understanding is correct, then we cannot modify the strings.xml dynamically in the apk file.
We are comtemplating 2 possible approaches -
Make use of the device DB and load values from there (personally I dont like this approach very much as I am not able to predict the impact on performance. Any comments? )
Create a wrapper implementation to parse xml's and have these values stored in the specific xml.
Depending upon the language selected parse the corresponding xml and use that to populate the map. The values are then fetched from this maps (in place of android Resource file)
If anybody who has faced similar issues,
can you please provide your inputs and possible approach.
If there is something default in Android api that I am missing and can be used in this situation ?
Looking forward to people's input on the above.
The problem is you need to depend on Android's ability to discover the correct localization based on locale, screen size, orientation, etc. These are conditions that are outside of your ability to influence and you don't want to try to reproduce the search logic.
Perhaps you could put a tag string in each of the individual string.xml files. This tag would have a keyword, perhaps the name of a table that is filled at runtime with your translated strings.
Related
I am building an android app that will ask user what they want to see. Based on that I will provide gifs, images and texts(one lines) based on time duration they choose. This would be an offline app.
I am confused about how I should proceed with storing large amount of gifs(1000), images(1000), and texts( sentences or words). After storing I would want to run them in some kind of time duration loop so that those they have seen won't be repeated.
In my opinion images, gifs or otherwise are just resources and should be stored as such. Text can be stored in another appropriate resource file.
What I'd recommend is then ensuring you have a database that provides names and links to the resources.
When the user provides you with a keyword, query your database to get a list of items that need to be provided. Your query can be used to change the order etc...
Your code should then cycle through the query response, retrieving and displaying the items as appropriate.
Remember, if you are displaying images to a user you may also need to consider screen resolution and thus may require the same image at different resolution. Equally you may wish to consider localising the text to support different languages.
Hope this helps.
(By the way, I'd recommend putting a rough plan together based on the above approach, breaking it down to ensure you know 'HOW' to do it. After you know how/what, then search to see if a library exists that allows you to do what you want to do in a simpler method. Search to see if there's a better method for handling the resources etc... the first step is always getting AN approach and then evaluating to see if it's the best approach for your needs/requirements.)
I have been looking at different ways to hold onto some predefined character data, however I am having a hard time nailing down which would be the best solution.
An example of data would be 10 strings, 5 int arrays (of size 10 each). There would be 10+ set's of this data. The application would load in the information and inflate generic "character" objects.
Possible solutions:
XML: Due to Android's structured XML requirements it can be hard to use without making a different XML file for every character, and even then it would have ID overlapping for similar named data values.
SQLite: Wouldn't be a huge database, but databases are ugly version controlled unless it is done with a create-database script which has its own downsides (such as making sure DB is up to date between builds).
Hard-coded Objects: By far my least favorite solution, using polymorphism to hardcode all of the objects. Too dirty, not nearly as dynamic as it should be.
I would like to consider things such as version controlling the files, ease of updating (due to them only being inflated, never changed by the app).
If this data is baked i would suggest to use harcoded data.
Reasons.
In those three solution you save the data in the application.
If you use XML-data, you have to consume the time while code parsing inside the code. And you have to write the code that parses your xml.
If you use SQLite, your data will be doubled because of you have to store this database in raw or assest directory, copied in the /data/data folder. Futhermore, if you use Strings and SQLite by default the data will be doubled again (due to UTF-16 encoding).
If think, if only you manage the data this is more usefull to store directly inside the code. Obviously, if you do not use tons of content:)
You might want to use the Realm framework, which is comparatively faster than SQLite and easy to implement inside in your current code.
It handles large data too and it feels like you're using only native android classes.
I have been storing option lists for my Android app in a cloud table. For example, categories like "historical fiction","biography","science fiction", etc. I see the following pros and cons:
Pro:
I can make changes to the list without sending an app update to Google Play
Not normalized - I can use the text in my other data tables instead of a reference ID
Con:
App needs to take time to download from the web each time (or at least check for changes)
English only
I believe the "proper" way to do this is the use the XML resource files. But I need to make sure the selection references correctly with my data. That is, my app needs to understand that "Poetry" and "PoesÃa" are the same thing.
Is the correct thing to do:
Forget about it since I'll never get to the point where I'm translating my app anyway
Use a string-array and use the index (0...x) to know what the selection is
Use a 2-dimensional string-array with a reference ID in the first column and the text in the second?
If you are handling the category list online, then why not handle the translations online as well. Here is what I would suggest:
In your application options, have a list of supported languages (each in their native translation). These language options should be stored on whatever server application is handling your web requests. Each language is associated with an integer ID that the user does not see, but is stored in the app.
Whenever you issue a web request to get a list of options, include the language id in the message. This will allow you to know what language the user has picked and can use a 2D array or some other structure to handle the conversion to and from the chosen language.
I'm not sure if this helps at all, since I don't know exactly what you are making or how you are designing it, but from the given description, this is an easy and effective course of action.
Yep I know its easy to fetch n it simplify code n even for localization. But I just wanna know because in android declaration of too much objects is not advisable, And im not too sure if arrays in resource is like dat in code (i.e in terms of object). That is why Im asking which is the best practice in android as we all know that each language as its own do n dont for effective output
I think the comments point to the answer that there is no real answer. What is the "best" depends on what you're trying to do.
Loading a fix array of strings from resources will be fast and negligably increase the size of the apk. However, as far as I know, a resource is fixed. You cannot add/remove entires to your XML resource file on the fly. You generally see fixed XML resouces when you know the values will not change, like with a ContextMenu where you know the options you will be offering will always be the same. In that situation, there is no need to set the values programatically (although you can if you want to).
Declaring the Array programatically is more flexible, i.e. it can be modified dynamically, but had other limitations. For example, it is not necessarily universally accessable like your resources file. I'd use the Array declared in you Java code if what you're doing is a dynamic function, e.g. generating a user selected list or grouping data on the fly.
As for speed someone who knows more may be able to elaborate but, unless the data size is extremely large, I cannot imagine that there would be huge performance differences for a basic string array in either form.
You just need to balance you're needs vs. the cost/benefit of each possiblity.
In MySQL database, I have a table in which there is a field named features. I have nearly 20 features to store there. I am trying to retrieve these features from my Android mobile application. In app, it has to be shown as line by line (so 20 lines in total). Is there anyway to store the 20 features in that single field by doing something like \n? Or is there anyway to get those features in new lines by doing something in my android app?
Firstly, this is almost certainly a terrible idea...by storing the features in a single field, you make it very hard to query and manage. For instance, finding all records where feature "x" is available requires you to parse the feature field in some way, which will almost certainly not make use of any indexing on the column.
If you have no choice, you have two options: store the features as some kind of string representation (XML, JSON, CSV), or store the features as a bit flag.
I strongly recommend using a structured text format - JSON is probably the most lightweight - because it's human readable, and easily parsed.
Well assuming you have the code set up to run a query and retrieve the data, you should store the data retrieved into a collection (an array or list) and loop through each item, displaying the needed data on the screen.
Displaying the data can work anyway you want, you can add a button for each record, write a line of text to a text field (which is probably good for your case), create a cell in a table etc....
I wouldn't place all of the data into the same record, it could get messy should you decide to add a field which is tailored to an individual feature. Plus, if you combine all the features into one record and decide to add or remove a feature later on, you will have to do string manipulation.
I would go with LONGTEXT. TEXT and BLOB can hold 64K of data while LONGTEXT and LONGBLOB (used primarily for binary data) can hold up to 4GB.
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
And yes, /n is fine for line delimiting