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:

 

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:

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

At the end of 2009 I found myself with a little too much free time and started looking for something new to experiment with. I’ve always been interested in mobile development but I don’t own a Mac or an iPhone nor do I have any interest in purchasing one. I had read an article about Android and was starting to think about a new phone so I started looking at the Android SDK. There’s no fee to download the SDK or any of the tools.

Developing for Android requires writing code in Java and designing screens (called Layouts) using XML (although layout elements can be created all in code if you wish.) I’ve never programmed in Java before but Java and C# are so similar in syntax and there is such a wealth of information on the Internet about Java that I found it very easy to learn the basics. Also, the concept of designing layouts using XML is very similar to designing WPF and Silverlight UI’s in XAML.

To start Android developing you need a few things (all the details are at http://developer.android.com/intl/fr/sdk/requirements.html and http://developer.android.com/intl/fr/sdk/installing.html.)

• A PC running Windows XP, Vista, or Windows 7 (32bit or 64bit); Mac OS X 10.5.8 or better; or Linux. I’ve been using 64bit Vista and 64bit Windows 7.
• The Eclipse IDE version 3.4 or 3.5
• The Eclipse JDT plug-in.
• The Java JDK 5 or JDK 6 (the JRE isn’t enough, you need the full dev kit.)
• The Android Development Tools (ADT) plug-in. This isn’t strictly required but it does make life easier.
• Apache Ant (http://ant.apache.org) if you want to be able to build from the command line or if you want to use a continuous integration server. Yes, Ant is where the .NET tool Nant came from.
• The Android SDK itself.
• SDK Add-ons (mainly the Google Maps API) and the USB driver for Windows. The driver allows you to run and debug an application on an actual Android device but isn’t required if you don’t have a device or are using an OS other than Windows.)

You need 500MB of additional disk space for the SDK tools, platforms, samples, and offline documentation plus additional space for each virtual device you create. Each platform targets a different version of the Android OS and you must install at least one platform. If you don’t have an Android device you’ll need to create at least one Android Virtual Device (AVD). When you create an AVD you’ll specify which version of the Android OS it will run and how large the SD card will be. If you create an AVD with an 8GB SD card the emulator will create an empty 8GB image file that represents the SD card so plan disk space accordingly.

I won’t go into the details of installing all the pieces because the web site has excellent step-by-step directions.

So what have I been doing with it? Well, I started with the tutorials of course. The ubiquitous “Hello, World" tutorial does a good job of walking you through all the steps needed to build an app. The “Hello, Views” tutorial has several examples that highlight the different base layouts and views. “Hello, Localization” talks about using resources to localize an application and “Notepad Tutorial” goes step-by-step into writing a notepad application.

In March 2010 at the Microsoft MIX conference one of the announcements was about the Open Data Protocol and one of the partners was Restlet and their Java extension for OData. Restlet has a version of the library for Android. One of the things it will do is query the metadata from a .NET WCF service and generate all the service refs and POCO, excuse me, POJO objects similar to using “Add service reference” in Visual Studio. I started using Restlet to query the Netflix OData feed that was demonstrated at MIX but discovered some problems with the Restlet library that made working with the Netflix feed difficult (Restlet is in the process of fixing the problems.) Then I saw a tweet from Chris Woodruff (Woody from Deep Fried Bytes) that he had made a database of baseball statistics available via an OData feed. For the last couple of weeks I’ve been working on a demo Android app that can search this database by player last name and display player details, batting, fielding, and pitching stats. In the next post I’ll start showing the application and talk about what mistakes I made and what I learned while building it.

No tags