The App Store for Apple set a very good precedent for people paying at least something (often 99 cents) for mobile apps. There are a large number of apps, but if you can catapult to the “Top 100” list in iTunes, you can generate some revenue from the sale of your app. $0.99 can add up if you get 500,000 customers. On Android, I see a LOT of free apps and doubt there are as many people buying apps as on Apple’s system. On my first Droid phone, I had over 200 apps on it and I think I paid for 3 of them. A breakdown:
Paid apps - When you buy them on Android, you use Google Checkout and the app manifest is recorded in your Google account. If you ever replace your phone, the paid apps can be re-hydrated for free. An example one – GolfShot lets you use your Android as a GPS and scoring tool on the golf course. $30 is pricey for a mobile app and you need an extended battery to make it through a round, but this app is great. Lets you know how far to the hole, hazard, etc. Also keeps score for you and your friends and emails out a scorecard at the end. Goodbye, short pencil and paper scorecard and $300 dedicated GPS unit. A port of an app that started on the iPhone. Another example: a WiFi remote control that will work with your Tivo. Great if you misplace the Tivo remote:
Donation-ware: Some apps have a free version, and a second version with the exact same bits in it but you can donate money to the author by purchasing the donation version. I bought the donation-ware version of myRemote, a cool app that lets you control a PC running Windows Media Center using a WiFi connection. Time for dinner? Pause the movie the kids are watching in the other room. This is really the same as a paid app, just a different marketing angle. There are also ad-free paid apps that are just the same as the free ones but with no ads.
Most Android apps are free as in beer, you can download and install them free of cost. The installation of free apps are also tied to your Google ID, so your rating and comment for the app will remain and survive install/uninstall and even if you drop your phone and power up a new one. If that happens you will have to manually re-install all of your free apps, though. See below for an example of comments/rating persistence on my new phone.
More notes on free apps:
- You can uninstall and re-install free apps any number of times. Some people seem to have uninstalled the Gong (really?) as our total installs number is much higher than active installs.
- Starting this month if your app is free it may never become a “paid” app in the Android Market. You would have to release a completely separate version to be paid. Note that this might kill some “freemium” models but might still support “in-game revenue” models.
- A subset of free apps have advertising in them as a way to produce revenue. The next article will focus on how to enroll in the different mobile application advertising networks, and implementing the code to serve up their ads. But first, a little more background info…
Ad-supported free apps: A lot of data suggests that across mobile platforms and on Android in particular, mobile ads can pay off as well as or better than selling an app. Recently Android passed Apple in monthly ad revenue according to Millennial Media:
http://www.droid-life.com/2010/10/19/android-eclipses-iphone-in-ad-revenue-for-first-time/
The difference between free and even charging one cent is huge. There is a wealth of information on the web. about the disruptive force of “free”, etc. From our data, the free Gong app reached over 1,000 installs in a month. The paid-for Gong app that existed before us (at 77 cents) has between 50 and 100 downloads. So at the most he made between $38 – $77. If you could beat $77 in ad revenue, you’d be outperforming (but still not terribly lucrative). We decided to see how it worked. We installed ads at both the top and bottom of the page. So far we’re still short of hitting $25 to recoup our Android Market developer fee, but we learned a lot in the process. More in the next post on the “how”.
We’ll back up a bit, to when I decided to try publishing to the Android Market. I had read that the Android publishing system was very open and quick with little to no oversight. This was considered a benefit for the following reasons
- No draconian “App Store” committee to tell you whether or not you can publish your app
- No lag in time for App Store approval – publish when you want
- An open system versus a closed one
- Crowding – fewer apps on Android right now, so it’s easier to get noticed and used
(more depth on this here - http://ezinearticles.com/?Android-Market-Versus-Apple-App-Store&id=4266917)
I went to the main Android market page and clicked the link for developers, which brings you to http://market.android.com/publish/Home. You can sign up to become a developer, all I needed was a Gmail account and $25 on a credit card. I landed on the “upload your app” page, which asks you for an .apk and some supporting files. The following screen is the “update” screen and not the “initial add” screen but you get the idea.
This is a double edged sword that must be wielded with care. In about ten minutes I was able to sign up and upload an apk into the market. It showed up INSTANTLY in the search results in the market and could be installed by users. I had figured when I went to the movies that no one else would search for or download the Gong app. I thought I could consider the launch “semi-private beta”. I was wrong! I made the change to launch the correct class name and used the upgrade feature to launch the “1.1” version of the app. There are two changes you make to your manifest, a VersionName which is the readable name of the major.minor.patch or whatever naming convention you choose for your releases. There is also a VersionCode which must be an integer and must increment in each release. This is what signals the market to recognize an upgrade. The VersionName can’t be counted on because my 1.1 might be your 1.0.1 or 1.0.0.1 which is our second release in any case.
When you log in to see how your uploaded app is doing, here is the dashboard:
I signed up for a merchant account too in case I wanted to do any paid apps down the road. There’s also an offer for you to buy unlocked developer phones that can have the OS flashed if you want as well, they are around $400 – $550.
When I clicked through to see the error reported, here is what I saw
This is what got me to stop looking at how I packaged/loaded the apk, and start looking at the refactoring I did. Renaming my main class to Gong worked. Version 1.1 went up on Sunday morning and there have been no problems since. I uploaded a 1.2 later in the week with some snazzier graphics (icon and gong image). I have thought about some other feature ideas (a widget for direct play, ability to shake the phone to ring the gong, etc.) but haven’t implemented them. I am debating whether to work on those or try doing an iPhone gong. There are already a few in the App Store. There are some interesting articles on the viability of the App Store and Android Market, from a market share and a “how much money do developers actually make” perspective. A sampling:
http://blog.flurry.com/bid/18265/Can-Developers-Still-Make-Money-in-the-iPhone-App-Store
http://www.wired.com/gadgetlab/2010/03/android-developer/
http://www.readwriteweb.com/mobile/2010/10/android-generates-more-ad-revenue-than-iphone.php
When I first got my HTC Incredible, I went to the Android Market and downloaded apps until I killed my battery. There are a ton of free apps, and one of the most popular genres is the “soundboard”. Name any popular TV show or movie (Family Guy, The Office, Star Wars, whatever) and there is probably a soundboard of popular audio samples from it. For very popular shows/movies, there may be a soundboard per character. Here’s an example one from the popular movie “The Hangover”
(Note also this is an example of an “advertising supported” app. More on the how, why, and economics of this in another article.)
If you tap on the line (or button, or whatever) of the soundboard, an audio sample of that line will play. My idea was to basically make a single sound version, where there is one button (the gong) and a gong sound plays when you press it. There is an ImageButton class in the Android SDK that would handle showing the image. There is a SoundPool class that can hold several sound samples and play one of them. I Googled for sample code for these and there are several out there.
The actual coding of the app is minimal, it just loads the sound in, sets up a handler to handle when the button is clicked, and then plays the sound when clicked. If you store the sound in a subdirectory called /res/raw in your project, a generated class R will have R.raw.soundname, where soundname is the name of the file minus its extension. You can refer to the “R Class” in your code to load one or more sounds into memory using the load() method from SoundPool. When your button is clicked, grab the stream volume from the AudioManager and pass it to the play() method on SoundPool along with the sound. The image for the button (and for the app’s icon) are handled in a similar manner. The icon is stored under /res/drawable as a .png file, and the gong image is stored under /res/raw. The latter is an attempt to avoid optimization of the .png when it’s loaded. The first version of the gong artwork was super ugly when loaded, as the palette got crushed on load from /res/drawable.
There are a couple important XML files in the project. One is the Manifest, which controls where to find the icon, app name, whether it is debuggable, and the version codes. The latter matters when you go to release to the market in order to handle application updates correctly. More on that in the Android Market post. The other important XML file is the layout. It describes how the screen is laid out, how to center and size controls on it, and where to get the gong image from. Making this XML-based instead of code-based makes it easier to change layouts, control nesting, and adjust sizing. There are tools to let you graphically lay out a screen and then generate the XML layout for you. Example:http://www.droiddraw.org/
Eclipse is integrated with adb, and if you have your phone connected, it detects the phone and uses it for launches and debugging sessions. If no phone is connected, it will launch an emulator. The setup is pretty robust, but once in a while adb would no longer see my phone when it was connected by USB. Some connects/disconnects and a reboot fixed this. There were also a few gotchas to Eclipse – if you hit Control-F11 (run) while in an XML file instead of in a Java file in the project, it gave an error. Also, Eclipse can get in an error state where it cannot find other class definitions even though they are in the same project. This is called the “cannot be resolved to a type” error or “red squiggle hell”. More info on and solutions to this:
http://philip.yurchuk.com/2008/12/03/eclipse-cannot-be-resolved-to-a-type-error/
I was now able to compile and run on my HTC Incredible. Eclipse would compile the files, create a signed .apk file, and deploy the file to my phone and optionally attach a debugger to the process. An example:
I felt confident that this was working well, so I started refactoring and simplifying my Gong project. I renamed a few things, changed my manifest to reflect a class name of Gong, and recompiled. At the same time (can you feel a rathole mistake with red herring troubleshooting coming?) I prepared the project for export to a final .apk file for the Android Market. Eclipse wraps a multi-step process of compilation, key generation, and signing of an .apk all into a nice wizard. I stepped through the wizard and produced a “release” version of the .apk. I manually pushed this .apk onto my phone using adb install and now saw errors when I tried to open the app. It Force Closed immediately upon opening. I thought maybe I was doing something wrong installing directly and maybe the “release” .apk file needed to install through the market to work correctly.
I instrumented every other line of my code with logging. Even the first logging statement failed to fire, so it looked like my code wasn’t even being hit. I’ll skip ahead a bit – I signed up for the Google Android Market, uploaded my release APK, and tried downloading/installing it through the market. I still had the same force close problem. I had run out of time to work on this for the day (it was Saturday, date night with my wife, and time to go see “Due Date”). So I left for the evening.
When I came home around 11, I happened to refresh the Android Market page. 56 people had downloaded the broken Gong app while I was out! They had complained about the force closes, some had rated it “one star” and one had submitted a crash report. Through looking at the exception info, I could see that when I told the manifest to launch the “Gong” class, it could not find the class com.syrinx.gong.Gong. I needed to rename my main class to “Gong”. Once I did this, my apk’s were working again. I found it odd that the compiler would let me create an .apk that you could not actually “run”, and the Android Market did not detect this either. More detail on the market in my next post..
When I started thinking of the Gong project, I considered “How should I build it?”. I had heard some good things about Appcelerator’s Titanium. Their product lets you code mobile apps in JavaScript, and compiles it down to native code for either the iPhone or Android. This appealed to me for the portability factor and for speed. Side benefits – they have Paypal integration, are in Beta for Blackberry support, and Titanium is open source. I’m not a JavaScript whiz these days, but I figured I would give it a try. I proceeded here and followed the instructions:
http://www.appcelerator.com/products/download/
The getting started guide available from that page was great, walking me through all the prerequisite steps for developing with Titanium on Windows. It told me where to get the latest JDK, where to install it, avoid space characters in my path to it, etc. It told me how to set my environment variables for everything as well. Very nice screenshots and sanity check steps (“run javac –version from the command line, if you did things right you’ll see this"). The same goes for the Android SDK setup and installs. Blow by blow directions with numerous screen shots.
TIP: The guide did not directly tell me to install Eclipse or which version – you will want 3.5 (Galileo) not 3.6 (Helios). They cite better compatibility between Titanium and 3.5. I put eclipse.exe in my PATH too so I could run it from Start->Run or the command line.
Buzzkill: You can only build/deploy iPhone apps using Titanium from a Mac, so you’d need a Mac to “cross compile” for both Android and iPhone. I don’t have a Mac readily available.
I installed Titanium and created an account for it. By default you have a “free” account. There are in-product promotions for you to upgrade to “Pro” to get better tutorial videos, etc. I figured I would tough it out for now.
I had trouble getting even “Hello World” to run at first. I did some Googling and found some KB articles about the /build directory not being created on new projects. I copied over the /build directory from the sample “Kitchen Sink” project provided by Appcelerator. I now got “Hello world” to run. When you compile an app and tell it to “run”, by default you will launch a “virtual device” using the Android SDK. This emulator is a virtual machine that runs the Android OS. You can pick from which versions of the OS you want to run on the VM, to whether or not it has an SD card in it, etc. The one thing I can tell you about the emulator is it is PAINFULLY slow. I am on a halfway decent desktop machine. It’s not a developer’s dream box but it is dual core 3+ GHZ with 3GB of memory. It took so long to launch the first few times that I killed it assuming it was hung up. When I finally let it run for five minutes I came back to my desk and it was up. The following process can take 2 – 5 minutes to complete:
Note the red boxes, on the top one you may get complaints about waiting for tasks, just say “Wait”. If your app does not come up, click the arrow at the bottom to bring up a list of apps an launch your app.
I next tried plugging my HTC Incredible phone in to my development machine using the micro USB to USB cable I had to charge it. I enabled the debugging ability:
http://developer.android.com/guide/developing/device.html
I told the phone to launch HTC Sync, then killed it. Now I could build and deploy to my phone. This reduced the compile/sign/deploy cycle to under 30 seconds. If you estimate costs at $100/hour for development time and you saved about 4 minutes each compile cycle, it quickly becomes worth it to buy an Android phone off Craigslist, a refurb from your carrier, or a dev phone from Google. By my math, with 16 compile cycles per day it would be about 5 days. It’s probably more than 4 minutes each time when you figure a developer faced with 4 minutes of wait time may wander off, do other tasks, and then have to get “back into the mode” to developing that app again.
The JavaScript code looks like this (abbreviated – you also create a tab group, window, etc)
var label1 = Titanium.UI.createLabel({
color:'#999',
text:'Hello, Andrew!',
font:{fontSize:20,fontFamily:'Helvetica Neue'},
textAlign:'center',
width:'auto'
});
win1.add(label1);
If you’re a JavaScript whiz and can get used to the syntax you could be super-productive. The Gong app can probably be done in 3-4 statements, create a window, create a ImageButton, play a sound when pressed. But when I tried to adapt the sample code from Kitchen Sink, I found the learning curve hard and Googling for help limited. I was tempted to start with Kitchen Sink and then start stripping out all code except the sound playing part, but it was tedious to strip it, compile, hope to not break anything, and in a scripted environment, debug if I did break something. I feel if I invested some more time I could do it, but my attention span for this project and affinity for Java over JavaScript pointed me towards a compiled app. Fortunately, pretty much everything was set up already. More to come…
I have been curious about development for the Android mobile phone platform since I bought my HTC Incredible back in May. I knew that the Verizon phone ran Java, especially from the occasional misbehaved app that would blow up with a message like “com.somecompany.AppName has stopped unexpectedly” or a “null pointer exception”. That brought me back to the old days in 1999, doing Java 1.1 development. I let the vague feeling of “I should build something, just to try it out” stew for a few months.
Last Thursday I was laughing at one of those office inside jokes. Luke from our sales team has a catch phrase to describe an organization that is in disarray, often saying “That place is a GONG SHOW!” I found a sound effect on the web for a gong and decided to see what it would take to make “an app for that”. I had read that it was relatively easy to build and publish an Android app, so why not give it a try?
The application is simple, when you open it you are presented with an image of a gong that acts like a button. When you tap the image, a gong sound is played. It is brisk and amusing, even my two year old can operate it, and it only took a couple hours to develop. The rest of the time was setup, prototyping, learning, debugging, and packaging. I’ll be doing a series of articles to describe the process. I’ll cover the setup steps, coding, development environment, packaging, and the Android Market “behind the scenes”. I’ll also throw in some commentary about mobile app dev, the Android platform, iPhone, etc.
The Gong app icon, the app running, and in the app in the Android Market
The app in action:
Gong app demo from YouTube
This is our new blog at Syrinx for the tech industry - gadgets, trends, business items, things that don't fall under our other blog umbrellas. Enjoy! -Andrew