Localisation or Internationalisation

The adaptation of a product or service to meet the needs of a particular language, culture or desired population’s “look-and-feel”.

1. Translation - you should always design your app in a way that can be easily translated to other languages. To do so, any text that you would expect to be translated like labels and titles and button descriptions should all be defined as a string resource in res/values/strings.xml. This allows you to create other versions of strings.xml for other languages. This is done by creating a new values folder with the pattern value-xx where xx can be the abbreviation of any language from the ISO 639 code list here, for example res/values-fr/strings.xml will contain the french version of the strings.xml file with all the strings translated from the default language to French. Label Strings you do not want to translate like so:

<string name="timeFormat" translatable="false">hh:mm a</string>

2. RTL Support - if you’re distributing to countries where right-to-left (RTL) scripts are used (like Arabic or Hebrew), you should consider implementing support for RTL layouts and text display and editing, to the extent possible. By using the Start and End instead of Left and Right you make it possible for Android to reverse elements when necessary (if supporting API 16 or less include the Left and Right attributes as well):

android:layout_marginStart
android:layout_marginEnd

When images with a directional context are used, allow Android to reflect them to maintain the relevance of the image:

<vector android:autoMirrored="true"> </vector>

For more info on localisation click here.

Services

Services are Android Framework components meant for running background tasks that don’t need a visual component, therefore they do not provide a User Interface (UI). An Activity can start a Service which can then continue to run, even after the Activity is shut down. They are ideal for loading and processing data in the background, regardless of whether any of the app’s Activities are open. A common example of this is how you can receive notifications when an app is not running.

A Service should be used when the task is decoupled from (does not directly affect) the UI, and needs to exist even when there is no UI.

There are 3 ways to start a Service:

  • Start – manually from a context e.g. Activity. Executes but will not normally communicate back to the component that started it.
  • Schedule – if you want to have a Service execute at some point in the future, or when some conditions are met, you can create a JobService. You can control when this starts via a Scheduler e.g. JobScheduler
  • Bind – offers a client-server-like interface, with the Service being the server, and the various components being bound to the Service being the clients. Components bind to the Service via the bindService() method. These Services can easily communicate with the components that are bound to them (unlike the started Services above). An example might be an audio player, where the Service plays the audio while the Activity controls the UI, with the UI being updated as to the progress of the audio file play. Likewise, pressing the Pause button will mean sending a command to the Service.

A Service can be both STARTED and BOUND.

If you want to run a Service in a completely separate thread you can use an Intent Service.

The Lifecycle of a Started Service is depicted below: