Using Multiple Languages in Giggity app

Giggity app is used for conferences around the world. It becomes essential that it provides support for native languages as the users may not understand the terminologies written primarily in English from different countries. In this blog, I describe how to add a resource for another language in your app with the example of Giggity.  I recently worked on the addition of French translation in the app. We look at the addition of German in the app.

You can specify resources tailored to the culture of the people who use your app. You can provide any resource type that is appropriate for the language and culture of your users. For example, the following screenshot shows an app displaying string and drawable resources in the device’s default (en_US) locale and the German (de_DE) locale.

It is good practice to use the Android resource framework to separate the localized aspects of your application as much as possible from the core Java functionality:

  • You can put most or all of the contents of your application’s user interface into resource files, as described in this document and in Providing Resources.
  • The behaviour of the user interface, on the other hand, is driven by your Java code. For example, if users input data that needs to be formatted or sorted differently depending on locale, then you would use Java to handle the data programmatically. This document does not cover how to localize your Java code.

Whenever the application runs in a locale for which you have not provided locale-specific text, Android will load the default strings from res/values/strings.xml. If this default file is absent, or if it is missing a string that your application needs, then your application will not run and will show an error. Here is an example of default strings in the app.

<!-- Menu -->
<string name="settings">Settings</string>
<string name="change_day">Change day</string>
<string name="show_hidden">Show hidden items</string>
<string name="timetable">Timetable</string>
<string name="tracks">Tracks</string>
<string name="now_next">Now and next</string>
<string name="my_events">My events</string>
<string name="search">Search</string>

An application can specify many res/<qualifiers>/ directories, each with different qualifiers. To create an alternative resource for a different locale, you use a qualifier that specifies a language or a language-region combination. (The name of a resource directory must conform to the naming scheme described in Providing Alternative Resources, or else it will not compile.) You can specify resources tailored to the culture of the people who use your app. You can provide any resource type that is appropriate for the language and culture of your users. For example, the following screenshot shows an app displaying string and drawable resources in the device’s default (en_US) locale and the German (de_DE) locale.

<!-- Menu -->
<string name="settings">Einstellungen</string>
<string name="change_day">Tag ändern</string>
<string name="timetable">Zeitplan</string>
<string name="tracks">Tracks</string>
<string name="now_next">Jetzt und gleich</string>
<string name="my_events">Meine Veranstaltungen</string>
<string name="search">Suche</string>

Then you can use it in the app like this anywhere you need to use the string. This is an example of putting the options menu in the toolbar in Giggity app.

@Override
public boolean onCreateOptionsMenu(Menu menu) {
   super.onCreateOptionsMenu(menu);

   menu.add(Menu.NONE, 1, 5, R.string.settings)
           .setShortcut('0', 's')
           .setIcon(R.drawable.ic_settings_white_24dp)
           .setShowAsAction(MenuItem.SHOW_AS_ACTION_ALWAYS);
   menu.add(Menu.NONE, 2, 7, R.string.add_dialog)
           .setShortcut('0', 'a')
           .setIcon(R.drawable.ic_add_white_24dp)
           .setShowAsAction(MenuItem.SHOW_AS_ACTION_ALWAYS);

   return true;
}

References:

Continue Reading

Setting up Travis Continuous Integration in Giggity

Travis is a continuous integration service that enables you to run tests against your latest Android builds. You can setup your projects to run both unit and integration tests, which can also include launching an emulator. I recently added Travis Continuous Integration Connfa, Giggity and Giraffe app. In this blog, I describe how to set up Travis Continuous Integration in an Android Project with reference to Giggity app.

  • Use your GitHub account, sign in to either to Travis CI .org for public repositories or Travis CI .com for private repositories
  • Accept the GitHub access permissions confirmation.
  • Once you’re signed in to Travis CI, and synchronized your GitHub repositories, go to your profile page and enable the repository you want to build:

  • Now you need to add a .travis.yml file into the root of your project. This file will tell how Travis handles the builds. You should check your .travis file on Travis Web Lint before committing any changes to it.
  • You can find the very basic instructions for building an Android project from the Travis documentation. But here we specify the .travis.yml build accordingly for Giggity’s continuous integration. Here, language shows that it is an Android project. We write “language: ruby” if it is a ruby project.  If you need a more customizable environment running in a virtual machine, use the Sudo Enabled infrastructure. Similarly, we define the API, play services and libraries defined as shown.
language: android
sudo: required
jdk: 
 - oraclejdk8
# Use the Travis Container-Based Infrastructure
android:
  components:
    - platform-tools
    - tools
    - build-tools-25.0.3
    - android-25
    
    # For Google APIs
    - addon-google_apis-google-$ANDROID_API_LEVEL
    # Google Play Services
    - extra-google-google_play_services
    # Support library
    - extra-android-support
    # Latest artifacts in local repository
    - extra-google-m2repository
    - extra-android-m2repository
    - android-sdk-license-.+
    - '.+'

before_script:
  - chmod +x gradlew    

script:
  - ./gradlew build

Now when you make a commit or pull request Travis check if all the defines checks pass and it is able to be merged. To be more advanced you can also define if you want to build APKs too with every build.

References:

  • Travis Continuous Integration Documentation – https://docs.travis-ci.com/user/getting-started/
Continue Reading

Advantage of Open Event Format over xCal, pentabarf/frab XML and iCal

Event apps like Giggity and Giraffe use event formats like xCal, pentabarf/frab XML, iCal etc. In this blog, I present some of the advantages of using FOSSASIA’s Open Event data format over other formats. I added support for Open Event format in these two apps so I describe the advantages and improvements that were made with respect to them.

  • The main problem that is faced in Giggity app is that all the data like social links, microlocations, the link for the logo file etc., can not be fetched from a single file, so a separate raw file is being added to provide this data. Our Open Event format provides all this information from the single URL that could be received from the server so no need to use any separate file.
  • Here is the pentabarf format data for FOSSASIA 2016 conference excluding sessions. Although it provides all the necessary information it leaves the information for logo URL, details for longitude and latitude for microlocations (rooms) and links to social media and website. While the open event format provides all the missing details including some extra information like language, comments etc. See FOSSASIA 2016 Open Event format sample.
<conference>
<title>FOSSASIA 2016</title>
<subtitle/>
<venue>Science Centre Road</venue>
<city>Singapore</city>
<start>2016-03-18</start>
<end>2016-03-20</end>
<days>3</days>
<day_change>09:00:00</day_change>
<timeslot_duration>00:00:00</timeslot_duration>
</conference>
  • The parsing of received file format gets very complicated in case of iCal, xCal etc. as tags needs to be matched to get the data. Howsoever there are various libraries available for parsing JSON data. So we can create simply an array list of the received data to send it to the adapter. See this example for more information of working code. You can also see the parser for iCal to compare the complexity of the code.
  • The other more common problem is the structure of the formats received is sometimes it becomes complicated to define the sub parts of a single element. For example for the location we define latitude and longitude separately while in iCal format it is just separated by a comma. For example for

iCal

GEO:1.333194;103.736132

JSON

{
           "id": 1,
           "name": "Stage 1",
           "floor": 0,
           "latitude": 37.425420,
           "longitude": -122.080291,
           "room": null
}

And the information provided is more detailed.

  • Open Event format is well documented and it makes it easier for other developers to work on it. Find the documentation here.

References:

 

Continue Reading
Close Menu