iPhone Development: 12 Tips To Get You Started

Going Undercover on Android Apps

In this article we go undercover on the approach to developing Android apps. As a professional programmer, with some iOS experience, Bruce Cooper can offer a qualified viewpoint on the experience. His report touches on user interface guidelines, the tools available to craft them, publishing in the Android Market place, platform fragmentation, in app advertising, open source and the future.

Profiling Android

About a year ago, a new generation of Android phones became available, and the buzz was that Android could now compete with iOS for features and desirability. I had already done some iPhone coding, plus I was in the market for a new phone, so I thought it would be a good opportunity to learn a new technology and hopefully produce something useful while I was at it.

Quick & Painless

When I was deciding what sort of app to write, I wanted it to be something simple, for a couple of reasons. Firstly, I wanted to learn the API and not over-tax myself. Secondly, by making it simple, I’d be more likely to finish up quickly and get it out to the public.

Publishing my app was important as I wanted to compare the experience of developing on Android to that of iOS. We’ve all heard the stories about having to deal with Apple’s mysterious approval process, and Google’s was supposed to be much easier. So off I went to the local phone store and I came back with a shiny new Samsung Galaxy S i9000.

One other thing I wanted to try out was mobile advertising. Again, we’ve all heard about people being able to make more money through in app advertising than through revenue from store sales. I didn’t expect much, but the only way to understand something is to do it. For advertising, I chose AdMob, as it appeared to be the preeminent platform at the time.

Taking Aim

I wanted to write something that would be useful for my target audience: me. I settled on writing a usage checking application, that would show the bandwidth usage of my phone (Optus) and my home ISP (Internode) to ensure that I didn’t go over my quotas. It would be called NodeDroid. Most of the existing usage checking apps for Android are either very basic or only work for one provider, and its information that I look up all the time. More information can be found about NodeDroid at 8bitcloud

After reading up on the technical details of how to program for Android, I started thinking about how the application should flow, and this is where I noticed the first differences between iOS and Android. Apple has gone to great lengths to specify the way that you will interact with iOS and the UI guidelines. The graphical interface builder goes a long way towards helping developers produce layouts that look like Apple UIs.

Whilst Android also has UI guidelines, they are less rigorously enforced. The GUI builder built into Eclipse for Android is terrible, meaning most people will end up building their interfaces by hand in XML rather than using a GUI builder, which often leads to ugly interfaces (As an aside, I think that programmatically built layouts can often work better than GUI built ones, but you need to put more effort in to get them right).

Other people have noted that the Android experience isn’t as consistent as iOS, and in my opinion this is one of the reasons why. I still wanted a good experience though, so a lot of effort was spent on making swipe gestures work correctly, including animation between states. I was a bit disappointed that it didn’t work out of the box. Some of this required specialised coding, which I will cover in another post.

Anatomy of a Mobile App

It is important to keep apps simple. Whilst it is tempting to put a whole bunch of stuff into an app, for mobile devices the limitations of screen real estate and input mechanisms mean that often, less is more. I didn’t want lots of buttons on my app; buttons, in general are a no-no on mobile apps, with gestures being a better way to interact.

Colour is also an important tool that allows you to differentiate between different components. NodeDroid supports accounts from multiple suppliers, with each provider displayed on a separate page. Colouring the pages with the colours of each provider means they become instantly identifiable by brand. Internode accounts ended up an orangey red, whilst Optus came out yellow. I’m no graphic artist, so the result was only partially successful, but I’m happy with the user experience that the colours provide. The effect would be even stronger with logos.

The last aspect of user experience I wanted to get right was how to show the results. The most easy to read format for info is graphs. I went looking for available plotting libraries, and found a few, but they were over complicated or too immature. In the end, as the graphs I was writing were very simple, I wrote my own components to draw the graphs.

Bringing it Together

So how did it end up? The first version of the application was quick to develop. This was aided by the use of Java as the programming language because I am a professional Java programmer, and switching to the Android APIs was easier than learning Objective-C for iOS. Working with Eclipse as a tool, in my opinion, is much easier than the awful XCode. Also, most Java APIs work very well on Android, meaning there’s lots out there already.

Publishing to the Android market was a breeze. After a one time US$25 registration fee (cheaper than Apple’s US$99 per year), I could publish my App immediately, through a straight forward web interface. This was especially useful when I found a bug in the first release, and needed to republish immediately to fix it. If I were dealing with Apple, there could have been a whole palaver about getting the new version out, but on Android it was simply a matter of uploading the new app bundle, and pressing Publish again. The market developer console also has a bunch of handy reporting tools which give you great feedback on downloads, issues, and comments.

Advertising was a mixed bag. Whilst installing and using adverts was easy, and I had a reasonable click through rate when adverts were available, often the service would be unable to provide adverts when requested leading to a poor number of ads shown (known as the fill rate). When this happened, it pretty much stopped the revenue dead. In the end, I made about $20 from advertising before I ended the experiment after two months. This sounds terrible, but remember this is a little app with only a few thousand users. It’s not going to pay the bills, but I can see why people like it as an approach: if you have a popular application with tens of thousands of users, advertising revenue could start to stack up.

Challenges

One challenge that I thought was inevitable would be the sheer variety of different screen sizes and versions of Android that are out there, otherwise known as “fragmentation”. People have been making a big fuss over this, but I can’t say I’ve really had a problem. The Google tools allow you to target a specific version, and as long as you are willing to do without the latest APIs, you can target fairly old devices easily. I had to make a few adjustments, but it was easy to target all Android 1.6+ devices.

Screen resolution was a bit more tricky. You tend to write your application for one screen resolution, then see how well it works in others. Luckily Google has provided pretty good tools to make your UI scale well, and if you write your application correctly it should work smoothly. I won’t say that my application works perfectly on every screen, but it works well on the vast majority. In the end, fragmentation really hasn’t been that much of a problem for me.

The Future

There are a lot of improvements I could make to my little application. I want to add a home screen widget to it, plus it would be great to add additional network providers to it. I’m still trying to work out how to do this in a secure fashion so that collaborators don’t have to share passwords with me. Its hard to debug without an account to work with.

As a first step, I have open sourced the application, it is available at my GitHub NodeDroid repository. If you just want to try the application, you can get it from the Android Market.

Twitter, Meet Android

You’ve said Hello Android. You’ve written your first app. You want to write something “real world” now. Daniel Bradby is back to develop a Twitter feed. This tutorial covers data lists, customization, accessing remote services, parsing data, and responsive interfaces. You should have a complete, functioning set of example code at the end.

In my recent article Hello Android, we created our first Android app featuring a basic Hello World function. Well, it seems the real Hello World of the mobile world is a Twitter feed.

This tutorial will guide you through creating a simple Android app to display a list of tweets coming from the JSON based search API provided by Twitter. We will work through the following points:

• Displaying a list of items
• Customizing the look of each list item
• Accessing remote services and parsing data
• Creating responsive user interfaces

For instructions on how to set up an Android development environment, take a look at the previous article Hello Android, which guides you all the way from installing software and establishing a workspace through to running a skeleton app in the Android Emulator.

Displaying Lists

To get started on our new project, create a new Android project in Eclipse (File -> New -> Other -> Android and select Android Project), entering an appropriate project name, application name, package name, and a name for the single launch activity.

You can see the options I’ve used below:

To check that you have created the project correctly, run the skeleton app in the emulator by highlighting the project name in Eclipse and selecting Run -> Run As -> Android Application.

Currently the Activity you have created will be extending android.app.Activity, and in your onCreate method you will be setting the ContentView of the activity to R.layout.main (linking to the layout as specified in /res/layout/main.xml). The Android SDK provides a convenient way to quickly display a list of data using a superclass called android.app.ListActivity. This Activity already provides a ContentView, configured with a ListView, ready to use and populate with data.

Now change the superclass of TwitterFeedActivity to extend ListActivity, removing the setting of the ContentView from the onCreate method.

The ListView now needs to be given data to display, along with a means to map that data into rows. ListAdaptors provide this mechanism and are set on the underlying ListView of the ListActivity using setListAdaptor.

Create some sample data containing two Strings, and an Android SDK provided adaptor (ArrayAdaptor) that knows how to handle arrays of arbitrary data into ListViews (The Android SDK also comes with several other ListAdaptors, such as Cursor Adaptors, which can assist when connecting local data storage to a ListView). You also need to provide the adaptor with a layout it can use to render the elements onto each row. In the example below we are using the Android SDK provided layout, simple_list_item_1, which is a single text label–perfect for laying our single strings:

Adjust your code as above and confirm the following results in the emulator:

Customizing List Items

The basic Twitter client needs to display at least two fields per row: the author of the tweet, and the content of the tweet. In order to achieve this you will have to move beyond the inbuilt layout and ArrayAdaptor and implement your own instead.

Start by creating a class called Tweet that can be used to hold both the author and the content as Strings. Then create and populate a Tweet object with some test data to be displayed in the custom list item:

Create a layout XML file in /res/layout/list_item.xml to define two TextViews to display the content and author on separate rows. In order to display them one above the other, use a LinearLayout, configured to render each element within it vertically (android:orientation="vertical").

Once the XML file has been created, the Android Eclipse plugin will automatically add it as a reference into the generated R file. This R file is kept under the /gen folder of your project and acts as a bridge between your XML elements and your Java code. It allows your Java code to reference XML elements and files created under the /res folders. The file you have just created can now be referenced as R.layout.list_item in the Java code, as you will do next in the custom list adaptor.

Create a private class (inside the Activity) called TweetListAdaptor which subclasses ArrayAdaptor. This class should be used to store an ArrayList of the Tweets being displayed, as well as providing a way to map the Tweet objects to the TextViews you created in the layout above.

This mapping overrides the getView method in ListAdaptor, and should return a View object populated with the contents of the data at the requested position:

Furthermore, it should–if possible–reuse any View objects being passed into the method through the convertView parameter. If a new View object has to be created for every element in a list, large lists would stutter when they scroll. Caching Views allows the minimum amount of View objects to be created to populate a large list of data.

The complete implementation of the custom TweetListAdaptor is below. Note the “if statement” checking whether the passed convertView is able to be reused. If the View is null, the ListView has run out of Views to display and requires a new View to be created for this row.

This is achieved using the LayoutService, which is able to inflate (or load) the layout as you specified earlier in XML. You will see here how to reference the layout file using the generated R class through the R.layout.list_item reference.

Once a View is created (or reused), the particular Tweet is extracted from the ArrayList at the position required to be rendered by the ListView. You are then able to obtain references to the two TextView elements using the ids assigned to them in the XML (for example, android:id="@+id/toptext"). Once you have the references, you can set them with the appropriate content and author from the Tweet object.

Now the onCreate method can be adjusted to use the custom list adaptor with the created test data as shown below:

which will display the following, when run in the emulator:

Accessing Remote Services and Parsing Data

The Android SDK contains packages aimed at simplifying access to HTTP-based APIs. The Apache HTTP classes have been included and can be found under the org.apache.http package. You’ll be using these classes, along with the org.json classes to parse the data coming back from a call out the to Twitter search API.

Before any remote services can be accessed from an Android app, a permission has to be declared. This will alert the user (of your app) of what the app might be doing. Permissions could be to monitor incoming SMS, read the address book or, in your case, to simply make a request on the internet. These permissions are displayed to a user in the Android Market place before an app is installed, giving the user the choice of whether they want to give this app the declared permissions.

The permission you need to use is INTERNET and should be inserted outside of the application tag in the AndroidManifest.xml file.

With the permission in place, we can create a private method in the Activity that makes a request, parses the result, and returns an ArrayList of Tweet objects. The code listed below makes the request and looks for the resulting JSON array, which is iterated to extract each tweet’s text and from_user elements.

Now replace the dummy data you previously used with a call to the loadTweets method when constructing the custom list adaptor in the onCreate method.

Run this in the emulator and you should now see real data coming back from the API request being displayed in the list view as below:

Creating Responsive User Interfaces

The code in its current state has the potential to cause an Application Not Responding (ANR) dialog to appear, prompting the user to quit your app. This can occur due to the long-running work of making a remote request for data being performed within methods such as onCreate.

Long-running tasks should never be performed on the main application thread (which drives the user interface event loop). They should instead be spawned off into child threads to perform the work.

While Java’s Thread class can be used for this task, there is a complication in that once the long-running task is complete, it generally wants to change the user interface to report the results (that is, display a list of tweets loaded from a request).

User interface elements can only have their state altered from the main thread, as the Android UI toolkit is not thread-safe, therefore the background thread needs to message back to the main thread in order to manipulate the UI.

Thankfully, the Android SDK provides a convenient class AsyncTask, which provides an easy mechanism for asynchronous tasks to interact safely with the UI thread. This is achieved by subclassing AsyncTask and overriding the doInBackground method to perform the long-running task, then overriding onPostExecute to perform any manipulations on the UI.

When the AsyncTask is created (it has to be created on the UI thread) and executed, the doInBackground method is invoked on a background thread. On completion, the onPostExecute method is invoked back on the main UI thread.

To use this in your app, you will need to implement a private class within the Activity (like the custom adaptor class) called MyTask, which subclasses AsyncTask. You can override the doInBackground method with the contents of your previous loadTweets method.

Instead of the ArrayList being returned, you maintain an instance variable in the Activity so that the data can be shared across the private classes. Then in the onPostExecute you can set the List Adaptor with the data, as was done previously in onCreate. The onCreate method now simply creates the MyTask object and calls the execute method.

In order to demonstrate the UI responding while the background request is being performed, I have added a ProgressDialog to the AsyncTask as well. The complete listing of the Activity is below:

You should now have a complete app requesting the Twitter data in the background.

The AsyncTask has quite a few more features to explore. You can be sure we will cover those in future articles. In the meantime you should read the excellent Android document covering these classes at Android Developers site.

Hello Android

Writing your first app and seeing it running on your phone is only half the fun when it comes to Android. It’s relatively simple to have your app up and live in the Android Market, being used by Android users almost instantly.

Head over to http://market.android.com/publish and using your Google Account, register as a developer in the Android Market. The registration process is immediate and requires a one-off registration fee of $25.

By the end of this article, you’ll be ready to submit an Android app to the Market (although it’s probably best to avoid submitting this HelloWorld-style app that we’re about to create).

Setting Up Your Development Environment

Java developers, especially those using Eclipse, will have an easy transition to the Android development world. Most apps are written in Java (you can drop down to using native C), and it’s typical for development to be done within the Eclipse IDE due to the tooling support provided by Google (although everything can be done outside the IDE from the command line). Android development is supported on the three major operating systems: Windows (XP, Vista, and 7), Mac OS X, and Linux.

In order to set up your environment, you’ll need to download and install the following:

• A Java Development Kit (JDK 5 or JDK 6)—the Java Runtime Environment (JRE) alone is not enough. You can download the specific JDK for your system from http://java.sun.com/javase/downloads/index.jsp.
• Eclipse 3.5 (Galileo), which can be downloaded from http://www.eclipse.org/downloads/. “Classic” is the recommended version.
• Android SDK Tools available from http://developer.android.com/sdk/index.html. Take note where this is installed or unzipped for the next step.
• Android Developer Tools (ADT)—Eclipse Plugin, which needs to be installed from inside Eclipse:
  • From the Help menu, click on Install New Software, then select Add.
  • In the dialog box, enter ADT Plugin for the Name and https://dl-ssl.google.com/android/eclipse/ in Location; then press OK.
  • Select Developer Tools and click Next, and Next again when presented with the items to be installed.
  • Read and accept the license terms, and click Finish.

When the installation is complete, restart Eclipse.

Now configure the installed plugin by clicking on the Window menu and selecting Preferences. If you’re on a Mac, select Eclipse -> Preferences.

Select Android, and then for the SDK Location, browse to where you installed the Android SDK Tools, and select that. Click Apply, then OK.

Using the tools now installed, you need to install the SDK components. This is done using the Android SDK and AVD Manager found under the Window menu in Eclipse. Launch the manager and select Available packages. Then select Documentation, SDK Platform Android 2.3, and Samples for SDK API 9; click Install Selected.

Running the Emulator

Now that you have all the tools required to started developing and running Android apps, you need to create a virtual device for your apps to run on in the Android Emulator. An Android Virtual Device (AVD) defines a device profile that the emulator can use when running your apps. You can also create multiple AVDs to test against, which comes in handy when you want to test your app on different-sized screens and various versions of the SDK.

To create an AVD, select Virtual Devices from the Android SDK and AVD Manager, and click New. Give the device a name and select the target SDK from the drop-down. Here, you’re also able to select different screen sizes and emulator storage sizes; for now, we’ll leave everything as the default and click Create AVD.

Now you’re able to run the emulator by selecting the created AVD and clicking Start, and then Launch. After some time, you’ll see the emulator running; you’re now able to run some of the built-in apps.

Creating a Project

Leaving the Emulator running, restart Eclipse so as to create our first Android project. Once Eclipse has finished loading, go to File -> New -> Other -> Android and select Android Project.

Fill in the Project and Application names, and then enter a package name for the app. This package will not only become the top-level Java package for your source files, but also provides a unique identifier for your app. No two apps can have the same package identifier installed on the phone at the same time, and the same goes for apps submitted to the Android Market.

With Create Activity selected, provide a name for the Java class that will become the entry point to your app, and click Finish.

Explore the contents of the generated project. You will find various Java, XML, and configuration files.

This is a good time to explain three key concepts used in Android app development.

Activity (HelloWorldActivity.java)—An Android Activity is a single-focused task that makes up part of your app. The Activity will display a user interface in the supplied Window, and interact with the user to perform the task. A single Activity could be displaying a list of emails or showing a map of the current location.

Typically, multiple Activities together form a complete Android application.

The generated Activity extends from the class android.app.Activity and overrides a single method, onCreate. Activities are driven by events coming from the Android operating system, moving the Activity through different stages of its life cycle. The onCreate method is called when the Activity is being created with the intention of being the current running Activity.

It’s worth becoming familiar with the life cycle of an Activity and the methods that can be overridden as detailed in the Android developer docs.

Manifest (AndroidManifest.xml)—This is the central configuration file required by Android to understand the various pieces of your app and how they fit together. Take a look at the generated Manifest, where you’ll see:

• package="com.sitepoint" which forms the unique identifier of the app
• <application ... > contains the attributes required for the app icon and name as it appears on the phone
• <activity ... > is where the single Activity that was generated is described with attributes for the class name (relative to the app package), and a display label for the Activity.
• <intent filter> these XML elements indicate that this Activity is the entry point for your app when it’s launched:
  • <action android:name="android.intent.action.MAIN" />
  • <category android:name="android.intent.category.LAUNCHER" />

Intents—Android is designed in such a way that apps can call out to other installed apps without having to know the specific details of their interfaces. This is achieved using the concept of Intents and Intent Filters. An Intent is an abstract description of an action (such as VIEW, SEND, EDIT), and typically references some data on which the action is to be performed (for example, a Contact in the address book).

Activities can create Intents as a way of passing responsibility for a task onto other Activities. This can be either within the same app (such as going from an Activity that displays a list of contacts to an Activity that displays the details of the single selected contact) or out to an external app (when, for example, you want to display a PDF using an installed PDF viewer).

Activities advertise their abilities to handle combinations of actions and data types through Intent Filters. Our generated Activity advertised that it’s able to handle a MAIN action when the app is being launched. A PDF viewer may advertise that it can display data of type PDF. If two apps advertise the same ability, Android will prompt the user to select which one they want to use. The Intent is run, and can make the selection the default as an option.

Running and Debugging

Now let’s run the app in the emulator, which you should already have running. Select the project in Eclipse, and from the Run menu, select Run; then select Android Application and OK in the dialog. While the app is loading (or the emulator starts up again if you closed it), you should add some of the Android-specific views to your current Eclipse perspective. You can add them from Window -> Show View -> Other -> Android. I typically add Devices, Emulator Control, and LogCat.

From the Devices view, you can see any emulators or phones you have plugged into your system that are available to debug apps on. You’ll also be able to see the processes currently running along with your own, identified by the package name you gave your app. If you select the emulator in this view and then move to the LogCat view, you’ll see all the logging that the system has been writing.

This view is extremely useful for debugging your apps. It allows you to create filters, so you can switch between seeing different levels of logging (warning, debug, fatal) and different tags. (Typically, an app will output logging with a tag that’s the same as the class name for where the logging is coming from).

Switch back to the emulator, and you should now see the app running as pictured below.

Once you’ve figured out a desirable functionality, writing an app for Android is largely a matter of ensuring you have the right tools installed, and then configuring them to do the hard work for you. After that, you can submit your app to the Market for other Android users to pick up.