Sergio Pereira : Android, Development

Android App From Idea to Market In a Few Hours

sergiopereira — Tue, 07 Dec 2010 04:11:00 GMT

I had been playing a little bit with Android development but not really worried about creating any useful or commercially viable application yet. I believe I'll end up creating a handful of small apps, some for personal use and some for fun. It will not hurt if a fraction of those yield some profit, but that isn't a realistic goal for now.

Maybe I'm wrong, but judging from what I've done professionally up to this date, I think any money that I eventually make with mobile apps will come from custom built LOB apps.

Nevertheless, the app I'm going to walk us through in this post is a free and for-fun project. You can find the complete source code at the bottom.

The Idea

Just the other day on Twitter I was poking fun at D'Arcy Lussier, then Don Belcham came up with a funny comment that triggered this colossal waste of code.

Fast forward to later that day, the app was ready for download.

The Lessons

Since this app is really a glorified Hello World and I had never let any other Android app leave the confines of my emulator, that's the perspective I'm hoping to share.

I'll try to show what's involved from when your first app is ready to fly to when it's finally available for download in the Android Market.

The Prerequisites

There are tons of compentent introductory articles to Android development, and I'll do everybody a favor and not rehash all that here. Suffice to say you can assume I went through some of those articles and have my development machine ready to go, with:

JDK (not just the JRE)
Android SDK
Eclipse IDE
Android Development Tools for Eclipse (ADT)
At least one virtual device (AVD) created (the emulator)

As you probably know, you don't need to use Eclipse but I think it makes your life easier if you're a total Java n00b like myself; most of the Android tutorials and Q&A out there refer to Eclipse.

The Code

In case I haven't said it enough, this is a very simple application, so I chose to target the lowest SDK version that I could, which in my case is the absolute lowest one available: SDK version 3 for Android 1.5 (Cupcake.)

To create the blinking 12:00 text I figured the easiest way would be to use two separate image files and alternate between them using a very basic animation. The animation is preferred over (animated) GIFs.

Images are embedded in your application as resources, under your project's res/drawable directory.

I used a pair of PNG images with transparent backgrounds. One of them is seen below.

Animations are defined in another type of resource. They are XML files with the animation specification. They support a nice range of tweening parameters but we'll only need a straight forward frame-by-frame animation. Here's the clock.xml file that I created inside that same drawable directory. Note the two image files drawable resource names that are the file names minus the extension.

<?xml version="1.0" encoding="utf-8"?>
<animation-list xmlns:android="http://schemas.android.com/apk/res/android"
  android:oneshot="false">
  <item 
    android:drawable="@drawable/dashes_red_alpha" 
    android:duration="500" />
  <item 
    android:drawable="@drawable/numbers_red_alpha" 
    android:duration="500" />
</animation-list>

Now we need to make that animation show up in the center of the screen. The application has only one activity (activities are the Android term for screens, windows, dialogs, etc.) That appearance of that screen is defined by the layout file main.xml, in the project's res/layout directory. If you're familiar with other XML based GUI layout formats like XAML or XUL (and even XHTML and ASP.NET webforms to some extend,) Android layout syntax is fairly reasonable. The sad part is that there isn't a good editor for them (there are some attempts out there but nothing worth praising yet.)

Anyway, here's the layout I used in main.xml. The animation will be displayed by that ImageView view (views are the individual elements or controls like textboxes and buttons, etc.) You can see that the image is centered in the layout (the layout_centerInParent attribute.)

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout 
    ...
  >  
  <ImageView android:id="@+id/digits"
    ...
    android:layout_centerInParent="true"
    android:background="@drawable/clock"
    />  
</RelativeLayout>

All that's left now is telling our activity to use the above layout and start the animation when the app gains focus (we need to wait until the app gets focus otherwise it might be too early to start and it will not do anything). The main activity class in this project is called Home, seen below

public class Home extends Activity {
  /* snip */

  @Override
  public void onWindowFocusChanged(boolean hasFocus) {
    AnimationDrawable frameAnimation = 
	  (AnimationDrawable) findViewById(R.id.digits).getBackground();

    if (hasFocus) {
      frameAnimation.start();
    } else {
      frameAnimation.stop();
    }
  }
}

And that's all there's to this application. We can start it in the AVD emulator and see it in all its blinktastic glory.

Package it up

Having an app running on the emulator or in your own phone is nice but it doesn't make the world a better place. We must push this application to the Android Market so everyone can have it.

At this point I should be telling you how a responsible developer would test his app in different AVDs, maybe different real devices, screen orientations, etc. But guess what? No siree, Bob. <sarcasm>In true Android developer fashion,</sarcasm> we're going straight to the Market and there's no stopping us.

Build it

The first step in packaging the app is to simply build the release binaries. Yo can do that in Eclipse by right-clicking the project in the Package Explorer and choosing Android Tools -> Export Unsigned Application Package and choose a directory to save it. You application .apk file will be created there.

Sign it

We can't simply send that file as-is to the market. To be accepted in the market, our application needs to be stamped with something that tells everyone who built it. This is akin to the strong naming keys that are used in .NET.

To stamp, or sign, our app we first need to create our own private key and certificate, which will live in a keystore file. If you already have one such file, you can obviously use the existing one instead. We can use the keytool.exe utility to do create it. In my box I have keytool in the JDK installation directory, so I'll run this command (one line):

C:\[JDKHOME]\bin\keytool.exe -genkey -v 
  -keystore your_secret_file.keystore -alias YourAliasHere -keyalg RSA 
  -keysize 2048 -validity 10000

When you run it, it'll ask you for a few identification parameters for the certificate and also a password that you'll need to remember later. Just like the SN key files in .NET, make sure you keep the produced keystore file in a safe place.

Time to use another tool to sign our .apk file with the information in the keystore file. Use this command.

C:\[JDKHOME]\bin\jarsigner.exe -keystore 
  your_secret_file.keystore YourApp.apk YourAliasHere

The above command will prompt you for the password again.

Optimize it

The last step in the .apk preparation is an optimization process to realign bytes in the file for faster reads on the device. You'd be surprised to know that there's another tool to do that. Not surprised? I thought so. Here's the command. You'll find the utility in your Android SDK installation directory. It will write the optimized version to another .apk file, which I'm choosing to name with the version number 1.0.

C:\[ANDROID_SDK_HOME]\tools\zipalign.exe -v 4 YourApp.apk YourApp_1_0.apk

Now to the market we go.

Publishing an app

The Android Market is where the vast majority of Android users go to find apps for their devices. You definitely want to have your application listed in there.

In order to upload an app to the market, you'll need to purchase a developer account, which at the time of this writing will cost you USD 25.00.

We're almost done here, I promise. Next we only need to logon to the market with our newly minted account and upload the application. The upload form will ask you for a couple of screenshots, a 512x512 high-res icon (?) and a bunch of other unsurprising fields.

Hit Publish and pat yourself on the back. You're officially an Android developer. I hope your first app isn't as lame as mine and that I could have helped you go through the process quicker than I.

Money flows in. Oh, wait

Okay, I can't promise an early retirement to anyone. That's on you to create the next viral app. But I can leave you with some good examples of successful apps.

Source code

Although there isn't really much to it, you can also download the source code of this app.

The Ground is Shaking Again. Get Mobile.

sergiopereira — Thu, 17 Jun 2010 05:08:00 GMT

A little over two years ago I commented how surprising it was that VisualBasic was still more popular than C# in the .Net world. Back then I checked the TIOBE Index and saw that VB (in all its flavors) enjoyed almost 11% of relevance while C# wasn't even at the 4% level.

When we look at the June 2010 rank below we see that C# has finally caught up with VB, and it's safe to say C# is now the most popular .Net language (remember, the VB index is not made up of just VB.NET.)

1	Java	18.03%
2	C	17.81%
3	C++	10.76%
4	PHP	8.93%
5	(Visual) Basic	5.87%
6	C#	5.20%
7	Python	4.27%
8	Perl	3.20%
9	Objective-C	2.47%
10	Delphi	2.39%
11	JavaScript	2.19%
12	Ruby	2.07%
13	PL/SQL	0.79%
14	SAS	0.70%
15	Pascal	0.70%
16	Lisp/Scheme/Clojure	0.65%
17	Lua	0.59%
18	MATLAB	0.59%
19	ABAP	0.58%
20	PowerShell	0.53%

Again, anyone can debate the importance of this ranking system, but at least it has been there for a while and to me it seems to represent the pulse of software development quite well.

Movers and shakers

But this post is not about C# vs. VB.NET.

This time around what caught my attention was the impressive rise of Objective-C (up 36 positions in one year). Now, no matter how more common Macs have become in the last few years, no one will convince me this increase in Objective-C is due to native OSX application development :)

Of course we all know it's caused by the surge in mobile and device app development (iPhone, iPad, and anything that they decide will run the iOS, like the AppleTV in the future, who knows?)

If you look at the trending chart on the TIOBE page you'll see that Objective-C started to gain significant steam around June of last year, coincidentally (maybe not?) when the iPhone 3GS was announced.

Keep your eyes on the ball

Are you playing with Mobile yet? Have you:

Started reading about mobile development?
Developed a Mobile web site?
Written and tested a native app against a device emulator/VM (iPhone, Android, WebOS, WP7)?
Written and deployed an app to your own mobile device?
Published an app on the market?

It's not like you will find yourself out of a job if you don't get into mobile but for many developers, from software shops to corporate environments, sooner or later a request for a mobile product or a mobile version of an existing one will swing by your desk.

It's an exciting time. Once again you have the chance of taking the lead and play an important role in your team by staying ahead of the game. Remember when you started seeing request for Ajax and fancy UI's in your web applications. Remember how you were one of the few that knew anything about it in your team? Same thing here. Only much bigger.

What I'm looking into

There are two different fronts that interest me in mobile development: Native Android apps and Mobile Sites. I'll explain.

The time I spent in Objective-C and XCode in the past was enough for me to know I'd be grinding my teeth and blowing off steam every single day if I wanted to develop for the iPhone (it's probably just me, I can live with that admission.) Besides, I don't like the idea of an approval process before I can give away or sell my apps.

Windows Phone is something that I'll have to wait more and see what kind of traction it gains. It also has the approval process issue. The big plus will be the development tools, which I think will better than iPhone and Android.

All that, combined with the enormous momentum that Android has, made me start coding for Android when it comes to native apps.

Don't forget Mobile Web

Native mobile development is fun and rewarding but let's not kid ourselves. History shows that businesses will favor the simplicity of web development.

I went through that transition period when custom desktop application development quickly lost market to web applications. And that happened in a world where Windows was virtually in every workstation that mattered.

Now imagine the mobile scene, where there's more than one big player, none equivalent to what Windows was back in 1998. Do you really think anyone will want incur the cost of maintaining 3 or 4 different native versions of each mobile application that we will start cranking out like we do web apps today? Native apps will probably be the minority, for environments where you have the luxury of dictating your end-user's choice of mobile device.

Didn't we just spend the better part of the last 10 years trying to get out of a certain single-browser paradigm? Do we want to repeat that mistake?

Moving to HTML5

Why is HTML5 so important in Mobile and not as much in the standard Web yet? Well, for one there is a greater percentage of HTML5-capable browsers in Mobile than on the desktop browsers. Android, iPhone, WebOS (and soon BlackBerries) have WebKit browsers.

With things like richer forms, offline support, canvas, video and the Geo-Location API (not really HTML5 but present in those WebKit browsers) we can build really capable mobile web apps. Not just small screen versions of the regular web apps.

To be very straight forward about it, the way I personally see it is that HTML5 is where the bulk of the mobile development will happen in the Enterprise and consumer-facing applications.

Maybe something like Flash, AIR, or Silverlight makes a run for their mobile money too but with all the bullying from Apple and diverging opinions everywhere, that's not something I'm spending time on right now.

Native or Web?

Both. But definitely much more of the Web kind.