Tikal Fuse #3 - Android session summary
For Tikal's 3rd fuse day, we wanted to experience developing for the Android. The session was lead by Igor Zelmanovich and had 12 people.
Our goal was to create an application that will show feeds from Tikal's community site.
We divided the application into several functionalities and smaller teams tackeled each. The functionalities were:
- Settings - allows selecting which groups to pull feeds from
- Main GUI - 2 screens: The first shows the list of registered groups, and on selecting one leads to a second that shows feeds from that group which can be opened in the browser
- RSS parser to read the feeds
- Splash screen
The application's source code can be found here: http://git.tikalk.com/fuse-3/android-application/trees/master/com.tikalk.community
We first set up the git repository for the project. As with previous occasions, people had trouble connecting to the repository, mainly due to problems setting the ssh keys required.
We then setup an IDE environment. People used either Eclipse or IDEA.
We then continued to try and learn how the GUI framework worked. This was the most tricky part, since it's a framework that is different from the ones we're used to and is influenced by the need to conserve memory which made the design a bit unusual.
At the end of the day we integrated all components and had a working application!
High Level Description
The Android GUI framework is centered around the concept of Activity. Each user interaction is mapped to an activity. Essentially, a GUI screen. Each activity creates the GUI by creating objects that represent the widgets. In order to separate logic from design, the GUI can also be defined in an XML file and then "Inflated" to create objects. The XML file is referenced through the R class, which is auto-generated. This is simple as calling setContentView(R.layout.main) in the first line of the activity. It is possible to get individual widgets (e.g., to see if a checkbox is checked), by using findViewById with an id that is assigned in the XML and automatically added to the R class. Again, simple as findViewById(R.id.mycheckbox)
Interactions happen by registering listeners.
Switching between activities is done by creating an Intent object and then calling startActivity. The activity to start is passed as class argument or string id. The latter allows to start activities provided by the system. For example, to start a brower, create an Intent with Intent.ACTION_VIEW and pass it a URI (in general this allows to start also other activities, based on what the URI means)
Google has buildin supprt for different types of activities. We used the ListActivity as base class for our 2 screens. This activity makes it easy to create screens that show lists (duh) by creating an adapter over the data list.
- IDE Support - While all IDEs provide support, Eclipse's killer feature is the ability to show how the screen will look like. The flow is also natural: code then hit run/debug, which deployes the application to an emulator.
- API - Android's API looks clunky in some aspects, at least for newbies. For example, passing objects between screens is awkward.
- Few utility libraries - We couldn't find a library that provides RSS read and had to create one of our own
- The concept of the 'R' resources class is nice, since it allows a safe way of referencing resources, with intellisense. We wish it was possible to navigate from a resource id to the source xml file - great for learning how android.R.layout layouts look like
- Some classes were removed from the stock java package. One problem is that these show up as verification errors at runtime, and not at compile time.