Roger's Blog | Well, I think it's interesting.



Experimenting With Android – Part 2

In part 1 I introduced the pieces needed to start developing for Android. For the remaining parts I’m going to make a few assumptions:

  • You installed the 32bit version of the JDK to the default location.
  • Eclipse is installed in C:\eclipse. There is no installer, just unzip the distribution archive into the rot of the C: drive.
  • The Android SDK was installed in C:\android-sdk-windows.
  • You followed the directions here to install the ADT Plugin, set the Android preferences to point to the SDK install location, and added the Android platforms to the SDK.
  • You downloaded the Restlet Java extension for OData and unzipped the Android version into C:\lib\restlet-android-2.0rc3 and unzipped the JSE version to C:\lib\restlet-jse-2.0rc3. I found it easier while learning Java and OData to use the JSE version rather than the Android version. Release Candidate 3 is the current release recommended for new development (and version 2.0 is the one with OData support.)
  • The first time you started Eclipse you accepted the default location for the workspace. You can have multiple workspaces even though the default for Eclipse is to put everything in the same workspace.

(Note: I actually completed this post a few days ago but as I was getting ready to post it Restlet posted Release Candidate 3 so of course I had to stop and test the sample with the new version. We now resume our regularly scheduled post.)

I’ll start with a few user requirements for the baseball application:

  • The user should be able to enter a player’s last name. She should also be able to specify that she wants to search only for active players or for all players that ever played Major League Baseball.
  • The user should then be able to select the player she is interested in from a list of all the players whose last name matched. The list should show enough information about the matching players to let her determine the correct one (you would be surprised how many players with the same name have played decades or even a century apart. Yes, the data goes that far back.)
  • After the user selects the player we should show her more details about the player: where he played, where he went to college, where he was born, his  batting statics, fielding statistics, and pitching statistics.

And some technical requirements:

  • The statistics generally will not fit on a standard Android screen in portrait mode. This means we will need to react to and intelligently handle a device orientation change. We may even want to force landscape mode and not permit changing to portrait mode.
  • We will be querying a live server over the network (either wireless or WiFi.) Obviously network queries can be time-consuming and Android has similar issues as .NET with respect to long running, blocking tasks running on the UI thread. Android also has similar restrictions as .NET with respect to updating the UI from a background thread.
  • We would like to use good, solid software engineering principles. Separation of concerns, good testability, DRT, etc.

So without any further delay here are some prototype screen shots:

startscreen playersearchlistscreen playerdetailsscreen

playerbattingstats playerfieldingstats playerpitchingstats

First row left to right: start up screen, search results list, player details.
Second row left to right: batting stats, fielding stats, pitching stats (if none found.)

OK, so it’s obvious where I fall on the whole designer vs. developer spectrum.

To get started our first job will be to create a project to generate the OData references and code for the baseball stats service. The Restlet library can query the service’s metadata and generate the entity classes automatically but that functionality isn’t in the Android libraries; it’s only in the JRE libraries. So within Eclipse click the File menu and select New->Java Project (not Android Project.) In the “New Java Project” dialog enter “JRERestletServiceRefGenerator” as the Project name and leave all the other settings at their default. The dialog should look like this:

New Java Project

Click “Next". On the second page (Java Settings) we’re going to add the additional libraries we need (this is comparable to Visual Studio’s “Add Reference” dialog except in Eclipse you can specify the external libraries at the same time you create the project.) Select the “Libraries” tab, click “Add External JARS…” and navigate to C:\lib\restlet-jse-2.0rc3\lib. Select “org.restlet.jar” and “org.restlet.ext.odata.jar” and click Open. It should look like this:


Click the triangle next to “org.restlet.ext.odata.jar” to expand the node. Select “Source attachment: (None)” and click the Edit button. In the Source Attachment Configuration dialog click the External Folder button, select “C:\lib\restlet-jse-2.0rc3\src” and click OK twice. Then select “Javadoc location: (None)”, click the Edit button, select “Javadoc URL” (which should be selected by default,) click the Browse button, select “C:\lib\restlet-jse-2.0rc3\docs\ext” and click OK twice. These settings tell Eclipse where to find the source code and the Javadoc for the Jar file (Javadoc is roughly equivalent to Intellisense.) We’re going to repeat the process for “org.restlet.jar” except the Javadoc location is “C:\lib\restlet-jse-2.0rc3\docs\api”. When done, the library settings tab should look like this:


Click “Finish.” Eclipse will chug for a second or two and then drop you into the Package Explorer with the newly created project.

If you expand JRE System Library you will see some of the Jar files that make up the Java runtime. If you expand Referenced Libraries you’ll see the two Restlet libraries we added plus a few more that were automatically added due to references:


“src” is where our source will go. Right click src and select New->Package. Think of a Package like a .NET namespace. We’ll use “com.droidbaseball.svcgenerator” as the package name.

In straight Java the package name can be just about anything you want but for Android the package name must follow a specific pattern. This is because on Android every application must have a different name so the OS can tell them apart and the package is part of the unique name. Click Finish to create the new package.

The final step for this post is to create our first source file. Right click the package we just created and select New->Class. This brings up the New Class Wizard:


Most of the fields are already filled in for us; we only have to add a couple of things:

  • Give the class a Name; we’ll use “MainClass”
  • Since this is our main class, we need an entry point; check the box next to “public static void main(String[] args)” – this should look familiar to C# developers.

Like .NET, everything in Java is an object that ultimately derives from java.lang.Object. One other point before we leave this dialog: many dialogs in Eclipse have content assist in various fields. Click in the Superclass field and notice a tiny light bulb show up to the left of the field:


That’s an indicator that content assist is available. Blank out the field, then type Obj and press Control+Space:


Every class that Eclipse currently knows about and that matches what you started entering in the field will be displayed in a popup list that you can choose from. This will come in handy later when we start creating Android classes.

For now, be sure the superclass is “java.lang.Object” and click Finish. Eclipse will think for a second then open our new class file.

Next time we’ll look at customizing Eclipse to make it a little more like Visual Studio. We’ll also add the code to our generator class (there isn’t much) and generate out service classes. Then we’ll set up the Android project.

No tags



Theme Design by