Tag Archives: Android

Reflection on the development of Animol – an Android app for Chemistry

The summer, I took a job offer from a lecturer that taught me in the last semester. The task was to develop Animol – a “simple” Android app for a lecturer from Chemistry department. The main functions proposed were displaying videos and short info for different experiments, synchronising experiment data with the server, on which new experiments can be added. I was in charge of developing the Android app, there are two more students working on iOS and server respectively.

The app was release under NUS account, but is no longer visible in Play Store for some reason. There is a brief description about it on NUS website.

The initial UI proposed looked very simple, so I did not expecting to spend too much time on it. After all, accepting the offer would mean that I will be working on 2 programming projects this summer, the other one being the orbital. I thought that my experience in Android game development would make this an easy job. As it turned out, making a “normal” Android app is somehow harder than making a simple Android game.

I started working on the project in late May. To set up the basic structure of the app, I need to learn about ListView and ListAdapter, to be able to populate data into a list. This did not take very long. After reading a few tutorials, I managed to find a good template that includes a ListView and a ListAdapter for displaying a list of songs. After removing some extra items, the basic list layout was done. Along with the ListView I also learnt simple SQLite functions to insert and retrieve data from Android’s SQLiteDatabase.

From there I got the basic framework and started working on specific requirements of the project. The next big thing is the embedded YouTube video. This was relatively easy for me(as compared to my counterpart working on iOS version of the app) as Google provides a YouTube Android Player API. (It was only later that I found out the downsides of the API.)

As I expected, the part that took the most time is the layout/UI. I had one YouTubePlayerView, several ImageViews and  scrollable TextViews and the whole layout also needs to be scrollable. So I did some research and followed the recommended way: Wrap all the ImageViews and scrollable TextViews in a LinearLayout which is then wrapped in a ScrollView. I also need to add some codes in the Activity to prevent scrolling conflicts between the inner views and the ScrollView wrapper.

After several modifications according to the requirements, my UI for the app was accepted in the weekly meeting. Then we all started working on server communication, I had a few choices here. I can either use the DefaultHttpClient (inherited from HttpClient) from Apache for Android, or the AndroidHttpClient (deprecated). Since there were several templates for DefaultHttpClient, I just followed the templates and wrote a ServiceHandler Class(just a utility Class, not inherited from Service or Handler Class) that handles the http calls. Then, I can use AsyncTasks in my activities to call methods in ServiceHandler for server communications.

It was on 1 July that things that things got a bit messy. I got my new MacBook Air and decided to shift all programming related work there. It just so happened that Android Studio had update moments ago. So it was a cross-platform and cross-version migration of an Android Studio project. This caused me several problems:

First, the Gradle version needed to be updated for the new Android Studio version, however my project was already set up for the old Gradle version and there was no way to do a straight forward upgrade of my project. So I decided to create a fresh project and copy paste my old codes into it, saving time to research on solving the compatibility issues.

The other problem was that the new build versions (version 19 and 20) does not seem to have good support for the package com.android.support:appcompat-v7. So I decided to strip the support package and made my app only compatible with devices running SDK version 15 (Android 4.0.1) or above.

The last and the most annoying one is the rendering of the ActionBarView in Android Studio. For some strange reasons, after I migrated the project, all the views stopped showing previews in Android Studio, saying that there are some problems with the ActionBarView. It worked fine on phones but lack of preview made it extremely difficult for me to design the layout as required. So I raised the issue on stack overflow. It seemed that removing the appcompat package helped to some extent but the new views created still has errors in rendering. Hence, this problem is still not solved.

Having solved most issues with the migration, I then started on more sophisticated operations involving retrieving and processing data from server and updating local database accordingly, as well as sending app usage statistics(click counts for each experiments) back to the server. There was an interesting problem regarding the timing for server communication. Initially, my implementation was to fetch new experiments and send the counts when the user opens the app (via onCreate in the splash screen activity). However, the concern was that the Android user may not have the habit to close the apps and server communication won’t happen unless the user explicitly kills the app. Then I planned to change the implementation to sending the count  and fetching new data when the app is sent to the background, but the disappointing news is that this is very hard for Android to detect sending app to background unless I use some hacks(which may not work in a long term).

So to ensure that the count is sent to the server, I created a BaseActivity that extends Activity, in which onPause will trigger AsyncTask to send count and onResume will trigger AsyncTask to fetch new data. This implementation suited the purpose, but it cost too much network traffic. This is because when user navigates from activity A to activity B, onPause in A and onResume in B are both called, effectively meaning 2 http calls will be executed for each tap on the screen.

Hence, the final decision was to add an interval of 30 seconds between any two server communications. This means after the first server communication, a timestamp is saved to the SharedPreferencesSubsequent server communications will need to go trough a check on timestamp to see if 30 seconds has passed from the previous server communication. This way, we can be sure that when the user launches the app (or relaunch from background), new data will be fetched. And for each subsequent navigation, onPause will be called before onResume, ensuring that the count will be sent in the next server communication.

The next big thing is push notification. This function was not in the original plan, but we all agreed that this should be an important part of the app in the event that we want to notify the users of new experiments or announcements. As it turned out, Google was kind enough to provide a Google Cloud Messaging(GCM) service for Android. The implementation was quite straight forward, except for the fact that it requires Google Play Services, which could be a potential problem for phones purchased in other countries that do not have Google services pre-installed.

The last problem was to dynamically refresh the view when the database gets updated by background server communications. I did not researched into how I can get a result from AsyncTask in my activity and the Android app is structured such that the views are drawn in onCreate of the activity, via setContentView(R.layout.activity_main); .  So in order to refresh the view with updated data, I need to either redraw the whole view or detect the changes to database and update the corresponding view elements. And I can either do it in onResume or set up a listener for database activities. In the end, I took the easy way out and forced a re-draw of the views in onResume (with 2 seconds delay) for each successful fetching of new data in the background.

Overall, I would say that this an awesome experience for me. I learnt a lot of things, not only on Android development but also on server communication techniques involving http request/response and database operations with SQLite. I am looking forward to working on my next Android project, or even pick up an iOS one if I have the necessary resources.

Using Java Naming Conventions and Andriod Naming Issue

This article on naming conventions is based on Java, some rules apply to other programming languages as well.

I highly recommend this article to new programmers who are yet to have their own naming styles (for functions, variables, etc).

This is especially useful if you are just starting to learn programming.

If you are a experienced programmer with your own naming styles, you may want read this and see if there is anything to improve your naming techniques.

Original article: http://java.about.com/od/javasyntax/a/nameconventions.htm

Note on meaningfulness and length:

When choosing a name for an identifier make sure it’s meaningful.

Don’t worry about the length of the name. A longer name that sums up the identifier perfectly is preferable to a shorter name that might be quick to type but ambiguous.

There are 4 types of letter cases for naming:

Lowercase is where all the letters in a word are written without any capitalization e.g.

Uppercase is where all the letters in a word are written in capitals. When there are more than two words in the name use underscores to separate them e.g.

CamelCase (also known as Upper CamelCase) is where each new word begins with a capital letter e.g.

Mixed case (also known as Lower CamelCase) is the same as CamelCase except the first letter of the name is in lowercase e.g.

Standard Java Naming Conventions:

Basically, follow the naming guidelines below when you write your programs, you will find your programming process more systematic, efficient and professional than if you don’t.

Packages: Names should be in lowercase. With small projects that only have a few packages it’s okay to just give them simple (but meaningful!) names:

Continue reading