Chris Risner . Com

It’s been just over a week since I wrapped up the last day of the 31 Days of Android.  This was a really fun series to work on but it took a lot out of me.  Today I’d like to talk about some of the lessons learned during and after writing the series.  These are tips that might be useful to you if you’re planning a long running series and are certainly things I’d like to remember going forward.  Unlike the rest of the series, there won’t be any coding in this article. 

Don’t Overcommit

Naming a blog series “31 Days of Android” and starting to post an article every day, kind of implies that you’re going to post an article every day for 31 days straight.  Not 7 for the first 7 days and then 1 every other day for the next 48 days.  It may not seem like it due to the quality of some of the articles (I can admit that many of them could be better) but each one takes a while to write.  While some of them took a few hours, most of them took much longer.  If you’re going to try to get one out every day, make sure you’ve got the time to commit to it or plan ahead.

Plan Ahead

If you’re going to get an article out every day and you know, or even suspect, that it’s going to take a while to write each one, write as many as you can ahead of time.  I didn’t start the series until I had written rough drafts for about 8 articles.  However, shortly after I started posting, I lost my 8 article head start.  I think the big risk on not posting an article as soon as you’re done writing it is that it becomes irrelevant.  This could have happened with my first entry which detailed out to set up and install your development environment.  I’m sure it will only be a matter of time before Google releases a new version of the ADK that slightly alters the installation and setup steps.  However, I think the risk is worth it to make sure you’re not putting too much work on your shoulders every night to get an article out each day.  If you don’t plan ahead, you’ll need to make a decision about how much time you can devote to your writing.

Be Willing to Sacrifice or Be Flexible with Standards

Since I didn’t plan ahead appropriately, I ended up working several hours each night (and sometimes the following morning) to make sure I got an article out.  I was insistent that I get out one article every single day and didn’t have a gap (one of the articles actually went out about 30 minutes after midnight on the following day).  This meant that during the week I’d get home from work and then focus, as much as I could, on writing an article so it would be ready for posting the next morning.  As a result, some of the articles I got out weren’t the best they could have been.  Looking at some of the articles, it’s clear the quality and amount of information could have been better.  I hadn’t planned on 3 days of Intents but had to move things to follow up articles when I ran out of time.  At one point in the content provider article (deleting), I just didn’t have time to figure it out.

Sketch out your Series Plans

This is something I did before starting the series and was very thankful I had.  Prior to starting writing on anything, I mapped out what I wanted to write about for each day of the series.  My failure was in completing each article as planned.  At some points I had to break out what I was writing into several days or move articles earlier or later in the series to make more sense.  Having a roadmap already defined was key in making sure I still accomplished what I wanted in the series even when I was making cuts.

In the End

While this series took quite a toll on me, it was totally worth writing.  I feel like I’ve learned a lot about both Android and blogging.  I’m much more capable of explaining some of the concepts of Android now and that’s already coming in handy at work.  Furthermore, I think future articles I write will benefit from this experience.  I don’t know if I’ll write a “Days of” series again (and if it is, I don’t think it will be 31!), but I hope it will end up being a better experience having learned the lessons above.

What’s Next

The series ended just over a week ago and I’ve taken a much needed break from writing anything since then.  I haven’t, however, taken a break from thinking about stuff I’d like to write about.  At the beginning of November, I wrote an article about some thoughts on Siri and how Google could probably roll out a Siri like product.  Shortly after that I had a quick Google Plus talk with a person in Developer Relations at Google about how they’d like to control their music with their voice.  This was already somewhat possible using Voice Actions, but there were some pieces missing.  I got motivated and wrote an Android app to handle it.  Over the next couple of months I’m planning on open sourcing that program and writing some articles about how it works.  Hopefully this will enable other developers to more easily get voice control into their own apps.  In addition to that, there were a few articles I had to cut out of the 31 Days series (dialogs, maps, animations) that I would still like to write about.  Some of these are stubs I’ve already created and should be able to get out soon(ish).  Others will probably come later.  Lastly, I’ve got a few more personal things to talk about (more beer brewing and chromebook experiences).  If you’re finishing up reading the 31 Days of Android and have thoughts, feedback, or requests for other articles on Android development, let me know.

Sadly, we’ve come to the end of the 31 Days of Android.  If you’ve been paying attention so far, you should be capable of making some fairly sophisticated applications.  Now it’s finally time to take the roast out of the oven and move your apps into the Android Marketplace.  You certainly don’t have to do this.  Due to Android’s loose restrictions on installing new app’s, you could distribute your app yourself or even use one of the competing app stores.  To my knowledge though, the Android Marketplace is the best place to put your applications and the one app store most highly used among Android owners.  There isn’t any sample code today as there isn’t anything you need to add on the code side once your application is ready, though there are some things you may need to change.

Cleaning your Project and Building for Release

The first thing you should do is turn remove any calls to Log as well as turning off debugging.  Debugging can be turned off in your manifest file by either removing the android:debuggable attribute or setting it to false.  Any debug calls to startMethodTracing or stopMethodTracing should also be remove.  Next, make sure that you’re not including any unnecessary files.  These may be class files inside src that you used at one point and aren’t anymore, drawables or layouts in the res folder that aren’t needed, or jars in the lib folder that you’re not including.  If you include them in your release, it will increase the size of your installable unnecessarily.  Lastly, make sure your manifest file only specifies permissions your app actually needs.  Some users are picky about what their apps can do and if you leave in permissions that don’t make sense for your app, you may lose out on installs.  If you are using external resources (i.e. web services, web sites, databases, etc) you may also want to make sure you’re using the correct production resources.

Making a Private Key

In order to send your application to the Marketplace it needs to be signed by a private key.  Furthermore, whenever you want to make updates to your application in the Marketplace, it NEEDS to be signed by the same private key.  If you lose your private key, you lose your ability to update your app.  This is critical to remember.  After you follow the steps below to create a private key, copy it to a usb drive, and put that drive in a safe, inside of a firerpoof safe, in a bank vault. 

keytool is an executable available in the JDK that is used to generate a private key.  On my windows computer, this is located at c:\program files (x86)\Java\jdk1.6.0_25\bin\keytool.exe.   The command to create your key is as follows:

keytool –genkey –v –keystore my-app-release-key.keystore –alias my_alias –keyalg RSA –keysize 2048 –validity 10000

This will generate a key that is 2048 bits and will last for 10,000 days (27 years) using the RSA algorithm.  Once you’ve ran that, you’ll be asked to enter a keystore password.  It is highly advised that you use a strong password here.  You’ll also be asked for your name, organization, department, city, state, and country code.  When that is done, you’ll be prompted to enter a password for the alias.  It’s again advised that you use a strong password here.  If you run this command FROM the JDK directory, you may get an “Access is denied” error.  The solution is to either run it from another directory or put a path in your command to another directory for the .keystore.  Here, I’ve created the keystore in a directory named Java on the C drive:

keytool –genkey –v –keystore c:\Java\my-app-release-key.keystore –alias my_alias –keyalg RSA –keysize 2048 –validity 10000

Building an APK in Eclipse

Now that you’ve generated your key and cleaned your application, you’re ready to produce a signed.  Open your project in Eclipse and right click on the project in the Package Explorer.  Under Android Tools select Export Signed Application Package:

In the next window, the project should already be entered.  Click Next and you’ll then need to browse to the location of your keystore file and enter your keystore password.  Then you need to select the alias you created and enter the password you set for that.  Lastly, you’ll need to enter a Destination APK file.  This won’t require you to put “.apk” at the end of your file but make sure you do:

After a moment the window should close and you should see your .apk file in the directory you chose.   Congrats, you’re done in Eclipse (until your next update).

Creating an Android Market Publisher Account

Before you can add any applications to the Android Marketplace, you need to create a developer profile and pay the registration fee.  The developer profile determines how you appear in the market and allowes you to enter a name, email address, web site, and phone number.  The registration fee is a one time $25.00 fee that is paid using Google Checkout.  When that is done and you’ve agreed to the terms of service, you should be presented with an “Upload Application” button.  Tap that to continue on with the process. 

Uploading and Setting Up your Application

Immediately after hitting “Upload Application” you’ll need to pick and upload the .apk.  This is required as the first step in adding your application.  Once you’ve selected it, you’ll get a summary of the package name, app name, version name and code, as well as the permissions and features listed in the manifest:

Provided you’re happy, hit Save.  Next, you’ll be able to upload assets and specify listing details.  Some of this is required and MUST be added before you can save.  These required things include:  Screenshots, a High Resolution Application Icon, a Title, a Description, a Category, and a Content Rating.  If you’re just trying to get your app into the Marketplace and you don’t care about getting featured or presenting your app as being professional, go ahead and just fill out the info so you can get to the Save point.  If you do desire to have your app be featured and you want people to get to your app in the Marketplace, pay a lot of attention to what you use for images and make sure they are in the correct format.  Furthermore, don’t treat the optional images and promotional video as optional.  Google really looks at these things when deciding what applications to feature.

Saving your Package Name and Publishing

Once you’ve filled out the necessary details you can Save your application.  Once you’ve done that, you now reserve the package name and no one else can use it.  This means that you own that package name (unless Google decides you’ve violated their terms of service and erases you from history).  No one else can use it and only you can update it and you can only update it with APKs signed by the same private key you created earlier (again, its very important that you don’t lose your private key file).  You aren’t required to publish your app right away so if you’re concerned with reserving the package name, fill out this form early on with dummy data and a dummy .apk.  Once you’re happy with everything, you can Publish your app. 

Once you’ve published it will take a few minutes for your app to show up on the Marketplace and a good deal longer for the app to show up when searching for it (I presume it has to propagate to a lot of servers).  In the mean time, you should be able to access your app and send people to it with a URL that looks like this https://market.android.com/details?id=com.package.name.

Updating your Application

Now that you’ve published your application, let’s talk about how to update it.  Once you have a new version of your .apk (make sure you’ve updated the VersionCode and VersionName in your manifest file) and log into the developer portal.  You should see a list of all your applications.  Click on the name of the application you want to upload (it should appear as a hyperlink).  The first page you will see is a Product Details page that has all of the screenshots and app details on it.  At the top of the page are two tabs for Product Details and APK files.  Clicking on APK files will show you the current and active version of your app.  Beneath that should be a button to Upload APK.  After clicking that and uploading, you should now see the new version beneath the active one.  To the right of that there should be a link to Activate your new apk.  Once you’ve uploaded, it’s VERY important that you click the Save button at the top right of the page.  If you don’t, your new apk will not be published.

Congratulations, you’re finally ready to start putting your applications out for people to use.  Good night, and good luck.