How to solve language issues in Android app, generated by GWPA
Within this Blog post, I’d like to share with you the trouble I had – and the solution for it.
I had generated an Android application with SAP Gateway Productivity Accelerator (GWPA).
For more information about GWPA please refer to the link section below.
The application connects to an SAP Backend on which Gateway is installed.
The application uses an API that was generated by GWPA.
The aim is to consume Backend-data, which is provided based on the ODATA protocol
When I ran the application on my real device, the backend data was provided in a different language than expected.
In my personal case, it was German.
The issue is not about the concrete language, or about existing or not existing translation of the backend data, short texts, descriptions, etc.
The problem is about how to control the language in which data is returned by the service-call.
In my SAP Backend, there’s a Gateway Service.
Built in ABAP, the implementation of the Gateway Service uses BAPIs and RFCs in order to retrieve the desired backend data.
The data is then provided based the ODATA protocol, and can be accessed via the internet.
When requesting the Backend data via a Service call, a URL is invoked, so the service can be explored with a simple Internet Browser, like e.g. Chrome, Firefox or the Internet Explorer.
In order to access the data, the browser fires an HTTP-request. For reading data it is a GET request.
When requesting data from the SAP Backend, a valid user in the respective system is usually required.
Such a user can have a default logon-language, according to his location and preferences.
1) The user logs into the SAP Backend System and provides his langage.
The result is: the data is presented in the desired language
2) When executing a service call, the language can be controlled with a parameter that is appended to the URL, after the question mark.
The following example tells the service to deliver the backend data in German translation, if available.
3) Now, instead of calling the service with the browser, a typical use case is to consume the data with a mobile application.
To make life easy, SAP has provided the GWPA, a toolset that is installed in Eclipse and allows to generate a mobile application with just a few clicks.
Please find a tutorial mentioned in the link section below.
In my case, I used GWPA and happily generated an Android application.
Right after generation, the app could be launched and provided the desired data.
I launched the app on my real device, my real smartphone connected to my (real) PC via (real) USB cable.
I mean: I didn’t use the Android emulator. This makes a difference.
Soon after the first happiness about the successful retrieval of data, I got the first trouble:
The data looked strange…
Some properties were empty, others had strange German texts.
So it looked like the logon happened in German language and some texts were simply not translated (therefore empty), others weren’t properly translated, probably because the connected backend wasn’t a productive system.
But why was the data delivered in German?
I set the default logon language of the specified user in the SAP Backend to English, without success.
I carefully checked the code: obviously, the generated code didn’t explicitly set the language to German.
I carefully checked the Android log file: no hint about a specific language setting.
It looked like the device-language was used.
So I had to control the language in my GWPA-based Android app.
After some research in the API that is provided by GWPA, the solution is to add the following 2 lines to the generated code:
That’s the solution.
The remaining question is: where to place these 2 lines?
The code snippets show that the generated Android application provides an object called RequestHandler which provides support for programmatically executing service calls to the service URL that is defined in the application.
It also provides one single entry for all the configuration that is required for executing service calls: e.g. the SAP backend-client, the user, the desired format (json or atom), the service-URL, etc
As a consequence, it is also the right place to configure the language settings.
In the generated code, the instance of the RequestHandler is obtained in the onCreate() method of the launcher-Activity .
You can also search the generated code for the member-variable named “requestHandler”.
Please note: since the RequestHandler is bound to the service, the name of the Java class is generated as a concatenation of service name and “RequestHandler”.
Once you’ve found the place where the RequestHandler is instantiated and configured, you can simply add the 2 lines mentioned above.
The object com.sap.gwpa.proxy.connectivity.SDMConnectivityHelper provides access to the instance of com.sap.mobile.lib.request.ConnectivityParameters, which contains a specific method setLanguage() for the language parameter.
If you need to set an own custom parameter, you have a different option.
The object where you can get access to the URL in order to add your own parameters is the com.sap.gwpa.proxy.ODataQuery object.
The instance of this object is used in the generated methods of the RequestHandler.
As expected, the RequestHandler contains methods which correspond to the HTTP operations: GET, POST, DELETE, etc
Each of such methods deals with the ODataQuery instance.
There, you can add your own parameter.
I hope that this blog post has been able to help anybody to get comfortable with configuring the code generated by GWPA.
If you have any suggestion or correction, please add it to the comment-section below.
GWPA introduction: http://scn.sap.com/community/netweaver-gateway/blog/2013/05/10/new-gateway-tool–sap-netweaver-gateway-productivity-accelerator
GWPA announcement: http://scn.sap.com/community/netweaver-gateway/blog/2013/06/03/gateway-productivity-accelerator-10-launched
Getting started with GWPA: Prerequisites
Getting started with GWPA: Android Preparation
Tutorial for Android Starter Application: http://scn.sap.com/community/netweaver-gateway/blog/2012/07/18/developing-an-android-app-consuming-data-from-sap-is-just-a-few-clicks-away