I am developing an android application in which the user requirement is to have that app in multi language. I need to know which is the best way to do so.
By storing the languages(string.xml) in a folder. For eg: For french in a folder named as value-fr.
By storing all labels and respective languages in a Db table and retrieving those on different language selection.
From the above two method which is the best way to be done considering the app performance.
The best way is to go for the resources folder by storing all the languages of French in the res/values-fr folder and reflect it all over the application.
By following the resources way you do not need to bother about managing the each and everything in your application flow. The application will be directly changed according to the French language as the user will change its language to french. It will directly access all the resources from the value-fr folder if you have kept.
If you will go by database way then in that case you are supposed to check for the locale and you will have to manage all the values of your application according to the local each and everytime which will lead you to complexity of handling resources.
So, Why not go for the best way if android is providing you such great functionality.
You can do either way, but the best way is option 1. i.e. By storing the languages(string.xml) in a folder like values-Fr. Using this will allow android to do the handling automatically instead of you telling database which is the current locale you need.
You should make the different folder in the res to support your application in multiple language.
Android handle all the things automatically, it picks the string resources from that file which is your current language of the device.
Just playing the Devil's Advocate - Android only supports ISO 639-1 (2-letter) codes at this point, Java 7 which supports ISO 639-2 (the three-letter language codes) is not natively supported by the device's framework for resource directories.
If your requirements expect you to adhere to the three letter language codes set in the standard than you may have to look elsewhere for this support (be it an in-house solution or another third party solution).
Related
A few specific languages have been established within my Android application's Resources (such as res/values-es/strings.xml). I'd like the user to have the ability to select from those possible languages in order to set their preferred language, should they want to.
The way I'd like to go about obtaining the list of languages is by automatic means (in case a new language is added later).
By itself, getResources().getAssets().getLocales() is not acceptable, as this lists all possible languages supported by the device. Instead, I want to acquire only those listed within res/.
How may I go about doing this? Is there a built-in function from the API, should I resort to hard-coding a string-array?
Minimum Android API: 21, Current Android API: 30, Language: Java
Thank you!
...this lists all possible languages supported by the device. Instead, I want to acquire only those listed within res/.
That's not really a thing, sorry. Plus, it's not that simple:
You are using libraries, and some of those may have resources with translations whose languages may be a superset of the ones in your own source code
App Bundles will only ship a subset of your own languages to the user
The relationship of what the user has, compared to what is literally in your app module's res/ directory tree, is complex.
Is there a built-in function from the API, should I resort to hard-coding a string-array?
Yes, you should plan on maintaining your own language roster. You may need additional engineering work in the future for this (e.g., for App Bundles).
i'm working on a project which needs to support internationalization.
the solution we thought of is:
create HTML templates with placeholders for language (i.e. home.html).
create an i18n directory with files such as: "language_en_GB.json".
on the build process have them merged together to create an output HTML. the output file will sit on a language based directory (such as "views/en_GB/home.html" or "views/fr_CA/home.html").
so basically this:
<h1>{{i18n_welcome}}</h1>
<h2>{{userName}}</h2>
merged with this:
{
welcome:"Welcome!"
}
will become this during a build proccess:
<h1>Welcome!</h1>
<h1>{{userName}}</h1>
i have a few question and appriciate your input.
is this a good approach for i18n?
do you know of a templating engine that does that i18n process well?
is there a solution for client side "baking". i would like a UI developer to be able to bake localy as well.
There are several frameworks that support i18n out of the box depending on your needs and what you are currently using in your code. As a pure templating engine, you can take a look at Velocity or Freemarker. For a more complete framework, you can look at Spring and Spring example and Struts and Struts2 example.
There are, of course, numerous other options as well. I'm just listing four of the most popular that I've seen people use.
Basically, for any of the frameworks, you create resource bundles for each language (named using the language for the specific bundle. Ex: language_en_GB.properties). So your thought process is pretty much in line. Basically you start with your html file and include your placeholder. In your resource bundle for each language, you specify what the string is supposed to be. After that, the framework does the merging on the fly for you, using the appropriate resource bundle for the language in question.
So you're pretty much on the right track - it all becomes a question of integrating properly with your framework and leveraging it to do the merging instead of doing it during your build pipeline.
You failed to provide the necessary details, so I can't really answer your question. I can only say that what you plan seems to be another wheel re-invention (but not as round as original one).
There are certain i18n best practices. In Java world it usually mean using Resource Bundles (in form of properties files) and some mechanism like JSTL to translate them when the page is being rendered. This is the best approach, as you won't need to re-compile anything to introduce the support for another language.
If you care about providing support for client-side scripts, it is usually done by writing out some array from the web page and accessing it on the client side. I think this is the most common solution. Another would be having some web service to provide you with translations and read it via XHR (i.e. AJAX), but that may be problematic. Anyway, you need to push the translations from the server side to the client side somehow.
And of course you need to read them from resource bundles.
From what you wrote it seems that you want to build some kind of static web page, backed by the application server (thus static web pages compilation). If I guessed correctly, honestly using Java for it is a bit overkill. You'd better go with some CMS software like Joomla, Drupal or jEase.
I am doing a Java Messenger for people to chat and I an looking for a way to record the message archives on the user's computer.
I have 2 possibilities in my mind :
To Save the conversations in XML files that I store in my documents folder.
To use SQlite, but the problem is that I don't know how it is possible to integrate it to my setup package and I don't know if it is very useful.
What would be the best solution for you ?
Thank you
Another option is using JavaDb, which comes for free with Java 6 (and later versions)
Before you make a choice, you should think about questions such as:
presumably you want this transparent to the user (i.e. no admin involved)
is performance an issue ?
what happens if the storage schema needs migration
do you need transactionality (unlikely, I suspect)
etc. It's quite possible that even a simple text file would suffice. Perhaps your best bet is to choose a simple solution (e.g. a text file) and implement that, and see how far it takes you. However, provide a suitable persistence level abstraction such that you can slot in a different solution in the future with minimal disruption.
I would go for the XML files as they are more generic and could be opened outside your messenger with more or less human readable format. I use Pidgin for instant messaging and it saves chat history in XML. Also to read the history from your application you can transform then easily in HTML to display it nicely.
If you use JAXB, converting Java objects to/from XML is very easy. You just put a few annotations on your classes, and run them through a JAXB marshaller/unmarshaller. See http://docs.oracle.com/javaee/5/tutorial/doc/bnbay.html
Use google's protocolbuffer or 10gen's bson. they are much smaller and faster.
http://code.google.com/apis/protocolbuffers/docs/javatutorial.html
http://bsonspec.org/
One issue is these are in the binary presentation and you might want to make the archive transparent/readable to users
I'm developing an application for Android, and I'm thinking that it's functionality might be useful on other (Java-running) platforms (say a regular desktop app -- although I hope that the other platform(s) involved are immaterial to the question at hand).
It's unlikely that the UI will be in any way portable (there's just too much of a difference between a good touch-capable, 4in screen UI, and a mouse-and-keyboard 19in screen UI), so I'm happy enough reimplementing that separately.
However, the core "business logic" (ugh, horrid word) and model (data storage) classes could, in theory, be reused in managing the core app. I've noticed that there aren't a lot of classes I'm writing that don't end up referencing some Android-specific bits (I've got XML resources files, images, and SQLite databases, as examples). Basically everything I've written so far has at least one Android-related import.
My question is twofold:
What tools are available out there to help me use Android-related classes and features (eg resources, databases) on non-Android platforms; and
What classes, features, etc of the Android platform should I completely avoid using (for the sake of simplicity, let's exclude UI-related items) due to non-portability, and what should I use instead to improve portability.
Answers that consist of "hahahaha, you're doomed" are OK, as long as there's some rationale provided.
(P.S. I'd make this community wiki if that was still available; this seems like a perfect CW question to me -- a list of Android portability tips and tools)
Looks like you have already identified the key point by keeping UI and biz logic / model separate.
Also sqlite itself is used not only in Android. But of course the way you interact with it (e.g. SQLDBOpenHelper) is different again.
So I guess having the biz logic and model as separate as possible is the way to go.
You can then put a wrapper around it (e.g. "Data Access Object " pattern which talks to the specific DB).
Still keep in mind that the users experience is best when you are as specific to a platform as possible on the UI side.
Example: there is an App (Push & Ride) on the Android market, which seems to run in a J2ME emulator. So screen input does not use the normal soft (or hard) keyboard of the device, but a simulated phone keyboard with the "abc" "def" combos on the number keys, which makes data entry a bit strange.
This app is for sure very portable (and its functionality is really great), but it just does not feel right.
When you want to go multi-platform, you may perhaps also look at things like Appcelerator or Adobe AIR
I started off doing something similar - I wanted to write an app for Android, Blackberry and J2ME. Conceptually, you can layer your design such that platform-specific components (UI, network access, data storage) are separated from the core business logic.
In practice, I don't find this satisfactory. The issues I faced all related to the core version of Java being different in the different platforms (in Blackberry it is based on J2Se 1.4, while Android used Java 6 as base). This led to annoyances like
Not able to reuse code that uses generics
My preferred classes not being available uniformly (for example, forced to use Vector over List)
I have opened discussions regarding this on SO (here and here), but couldn't reach a conclusion.
The logging layer can be made portable by using the Simple Logging Facade for Java(SLF4J) which is available for java/log4j and for android.
Also,you can try this out
http://wp7mapping.interoperabilitybridges.com/Home/Library?source=Android
Contains documentation and tools to map your android app to windows phone
Also read this,even though it contains instructions specific to android - windows phone interop,im sure they apply to other platforms as well
http://windowsphone.interoperabilitybridges.com/media/49652/wp7_guide_for_android_application_developers.pdf
What I do is create a web service outside of the android app which can be used by the android app as well as other systems (websites, windows apps, iphone apps etc).
A simple REST web service which supports JSON is a good example to fetch data and also insert/update data. JSON is particularly suitable because its so lightweight, and doesn't require alot of bandwidth which is great for slow mobile connections.
This way you can store your models/data storage outside of the android app, and it can be used by other apps very easily.
The database layer can be made more portable by using android jdbc or by using a database abstraction layer/object relational mapper/ActiveRecord implementation.
Has anyone tried make android.database(.sqlite) runnable on a non android system?
If you carefully separate business logic from UI and android perks you would be able to reuse it in desktop environment. Android is quite different from it in intialisation and application lifecycle - abstracting creation and setup of BL is also necessary.
Usefull pattern for this purpose would be dependency injection. There are different frameworks around, and some are more suited for android (like roboguice) or desktop (spring or picocontainer or guice).
Android appliactions are very constrained in memory, and this puts limits on what frameworks you can use there. So you may need to abstract data storage as well ( hibernate comes handy on desktop / server side , but too heavy for mobile device)
I'm inclined to suggest trying out the new native extensions for Adobe Air. It allows you to create a device-specific chunk of native code, and connect it to the Air framework, accessing it as you would other objects in Air. (cf. http://www.adobe.com/devnet/air/articles/extending-air.html). This allows you to keep the Android-only code as is, and then replace that code with iOS, Windows DLL, etc. code as needed.
This doesn't solve the problem of translating Java code to other languages/platforms, of course. Still, some of the logic you are doing natively may very well exist already cross-platform in Air. For example, you can access the camera in Air in all supported OSes without writing any device-specific code.
You will probably need to go beyond the current Air classes, so some examples may help:
Android speech-recognition
iOS batttery
Windows and Mac tutorial
NE tutorial
I am currently trying to implement a database compatibility layer for Spring-Boot-JPA/Android-Room:
"compatibility layer" means my Service-layer-code is pure-non-android-code that can be used in android and in spring-boot. The Service-layer-code uses a common java-repository-interface that is either implemented in android-room or in JPA.
Currently i am stuck here:
Howto use methods of CrudRepository<T, ID> (or SimpleJpaRepository<T, ID>) in a Spring-Data-Repository-Fragment method?
we are planning to build a web based client side application framework. The main focus is to write native looking webapps using Java and compile them for your target platform.
Our planned target platforms would be the iPhone and Android (on top of PhoneGap), Backberry and Palm WebOS.
Our goal is to create a decent framework and that's what this post is about. We want to know what developers would expect of such a framework and on what topics are more important than others. We also want to know if it would be more important to provide a UI-framework which really feels like a native app on the target platform (e.g. scrolling behavior) or to provide some decent APIs to use HTML5 and PhoneGap features, store and manipulate data etc.
What would you, as developers, really like to see in that kind of a framework? After all, you're the ones that will (hopefully some day) be using it. And most important: Would you use it?
I would like a good GWT framework for mobile plateforms (at least iPhone and android), with a native feel UI (ie : smooth scroll, fast click), and UI customization by CSS.
I would pay for that !!
Make the setup and default behaviors of components work right out of the box -- give them either a builder pattern so that the component is ready to be useful in one line, or constructors that contain sufficient amount of parameters to create a well-formed object.
Along these lines, every GUI component should have an adapter to take a variety of model based data structures. Pass it along, no-fuss, no-muss, and absolutely no boxing/unboxing.
the bad thing about the webkit based mobile frameworks is they are not as smooth and fast as other applications. This is where all they stack. I would recommend you to write a JAVA Dalvik framework, which is easy to extend an use with a nice error handling and strong UI. It should definetly have it's own plugin pattern so the community can extend it if you are planning to go open source
My personal favourite would be something that would allow me to develop using the Widget Standard http://www.w3.org/TR/widgets/ and then publish to app stores by wrapping the widget into a webview or similar. Opera Mobile, Samsung Bada, Symbian and now Android support the platform already.. http://labs.opera.com/news/2010/12/22/
This would include a barebones JS framework that could be Closure Compiled smaller, using only the methods/ parts of the framework I really used, to keep the size minimal.
Um... if it's going to be
platform-specific and client side
Our approach is to be as device platform neutral as possible.
As said before: Our goal is to write an application in Java and to compile it then for a specific target platform. It should also be possible to compile the same application without any (or at least as few as possible) changes in your Java-Code for all our supported platforms.
We choose to use "the web" as our runtime because almost all mobile platforms provide some kind of web environment on which we could deploy our apps.