5 Tips to Get Started with Android Development

With sales of Android devices growing, there’s no better time to get started crafting your first Android app. Here are the five things you need to know before creating that first killer app.

1. Understand the Java Programming Language. Java is Android’s main programming language. Learn object-oriented programming concepts, Java language fundamentals, including packages, classes and objects, interfaces and inheritance, numbers and strings, Generics, Collections, and concurrency. The more you understand Java, the more robust and elegant your Android apps will be. The best-selling book Head First Java is a great place to start learning the fundamentals.
head first java

2. Choose Your Development Environment and Tools. Get familiar with the integrated development environment and the build automation tools. For development tools, you can use Eclipse, or the newer Android Studio IDE. Both are free. In Developing with Eclipse, from Android Developer Tools, you’ll learn about the basics about Eclipse and many ways to use IDE to improve your code.dev with eclipse

For build automation, learn Apache Ant, Apache Maven, and Gradle, which provide a robust set of tools to manage your builds. Finally, get familiar with source control concepts and tools: learn git and create a git-source repository by creating an account on GitHub or Bitbucket. The Git Pocket Guide will help you understand the basic terms and concepts of how the platform operates. git pocket guide

3. Be Aware of Fragmentation. Given Google’s philosophy with respect to openness, Android is a fragmented market with its different OS versions and devices. Keep in mind that the more versions and devices your app supports, the more testing and maintenance (and related costs) that you will have.

The Gingerbread (introduced in 2011) version of Android still commands 20% of the Android device distribution. The market, however, is consolidating on Android 4.x and newer (this represents the last three major Android releases). Smartphones, tablets, and hybrid “phablets” each have different sizes and resolutions. You’ll need the appropriate assets, fonts and layouts that ensure the best possible experience across such different screen characteristics. See Design Apps for Tablets from the Android Developers Blog.

You also need to consider the array of Android supported sensors and/or UI facilities. For example, not all Android devices may support the same kind of camera, and they may not support Bluetooth. A good example is the Kindle, which is based on Android 2.3, but it doesn’t provide support for many of the hardware sensors or UI facilities found on other Android devices.

4. Understand the Android Application, Activity, Fragments and Services Application Components. All Android apps consist of an application class, along with one or more activities with one or more fragments. You may or may not have services for background tasks that need to continuously run. Android Fundamentals, from Building Hybrid Android Apps with Java and JavaScript, will help you learn the essentials of these components.
android fundamentals

5. Learn About Threads, Tasks, and Loaders. Delivering a “great user experience” is the golden rule on mobile, so the main system (user interface) thread must never be blocked to ensure a great and smooth user interface. So, long operations (network, I/O, computations) must all be run asynchronously in the background, typically on a different thread of execution. For this, you must learn the Java language concurrency facilities. Read about thread and synchronization in Java: A Beginners Tutorial:java threads

You’ll also want to understand Android’s own facilities that allow parts of your app to run asynchronously in the background. This chapter from Pro Android 4 will walk you through building your first AsyncTask: pro android

Special thanks to C. Enrique Ortiz for his help in writing this blog post. Ortiz (@eortiz) is a well-known expert and author on mobile software development.

Using your iPad to learn about Android?

Android has been trending in the news because of this recent Gartner report, showing the Google OS as the clear number one among new tablet sales in 2013, surpassing iOS.

Not surprisingly, the subject of Android development has been steadily rising in popularity in Safari Flow. During 2013, Android was the twelfth most popular topic among Safari Flow users. During the first two months of 2014, it climbed to our ninth most popular topic. And the week following the release of the Gartner study (March 3), Android surged to the sixth most popular topic. “Android” is also the sixth most common search term since the beginning of the year.

But it’s difficult to ignore the irony that the vast majority of our Flow users sign in with their Apple mobile devices to learn about Android. Of all the visits from mobile devices to Safari Flow, the iOS share increased from 56.7% in 2013 to 62.4% in 2014. Android devices, meanwhile, have dipped slightly from 41.2% of the visits in 2013 to 35.8% in 2014.

Getting started in Android development?

On Wednesday, we’ll offer five tips to help you get started with Android development. Follow our blog (click + on the bottom right of this page) to get a reminder when the post is live.

In the meantime, check out our Android topic page to get a sampling the most popular books and videos about Android. And here are three titles released this year that we highly recommend:

image of book cover
Android: How to Program, January 2014

by Paul Deitel, Harvey Deitel, and Abbey Deitel



image of book cover

Android Recipes: A Problem-Solution Approach, February 2014

by Dave Smith and Jeff Friesen


image of book cover
Learning Android, January 2014

by Marko Gargenta and Masumi Nakamura

Detecting Available Free Space in WebSQL

At Safari, we’re working on some web products that allow offline usage. For various reasons, using the Application Cache isn’t appropriate for our use case; we need a “real” database. The browser requests the data from the server and then inserts it into the relevant tables in WebSQL. (Yes, I know WebSQL is deprecated, but unfortunately iOS doesn’t yet support IndexedDB and this functionality is particularly important on mobile phones, so that’s what we’re focusing on for the moment.)

The Problem

Generally speaking this works well, but you have to navigate the landscape of device capabilities, and there are times when it is particularly frustrating. Take for instance this scenario: I chose some content that has a lot of images, adding up to 18MB of stuff, and decide to save it offline. On iOS, we get 50MB of storage per domain (though the data is actually encoded as UTF-16, so it’s about half that in reality), so this should be OK.

So the content is requested from the server, streamed to the client, and the client attempts to save it in the database. What we didn’t know is that there’s already  12MB worth of stuff stored in the database. So what happens? After making the user wait to download the entire 18MB blob and then wait to parse it and try to load it all in the database (which could amount to a fairly large amount of time depending on a variety of conditions) – the database throws an error and we tell the user they’re out of space. I think you’ll agree that this experience is sub-optimal.

A solution?

Can we do better? I think we can. I want to preface this by saying that this most likely isn’t for everyone. It may very well be faster to just throw your data at the database and see if it sticks, but in our situation most of the time it will be faster to detect and then decide what to do. The problem is that there’s no built-in way to determine how much space is left before you’ve hit whatever cap there may be. Believe me, I googled quite a lot looking for a solution. After that search and chatting with some co-workers, we came up with something and that’s what I want to share: a proof-of-concept I’m calling yardstick.js. I’ve created a gist of the code on Github.

Using it

Yardstick works by using a temporary table to measure how much space is left by filling up to a given targetSize. Originally, I wanted to create a separate database and exploit the per domain storage limitationbut there were some issues with the allocation of the two different databases. Say we are in that situation above, we have already prompted for the max size (see here for why this is important), and we know that the content we want to insert is 18MB, usage of yardstick.js would look like this:

  var ys = new Yardstick();
  ys.measure(18, function(avail, err) {
      // continue what you wanted to do here
      alert(avail + 'MB available for saving');

What’s happening

An in-memory string of 1024 * 1024 characters is used to fill the database using targetSize for the number of loops. So we can assume that each loop inserts 1MB. On each successful iteration we set the internal available attribute to equal the result.insertId of the SQLResult returned, letting the auto-incrementing table do the counting for us. The result of this setup is that if we get to targetSize loops, we know that amount can be inserted, if we error before getting there, we have the internal available attribute that will tell us how much we can safely insert. Upon completion, it deletes the in-memory fake data and drops all of the records that were created, and then calls the passed-in callback with the value of available and the error object, if an error occurred.

Now we can determine if we can save that content locally before we make the (even more) expensive call to the server. And if we can’t save the 18MB, we know how much we can save so that we might be able to suggest saving alternate content that’s smaller.

What do you think?

This is currently just an idea and I’d love to get some feedback on it because I think there are others who know more about this than me. There are obvious downsides to this approach (speed being the obvious one; I also killed the browser on my iPhone 3GS trying to use it, and it probably has battery life implications) and I’m sure there are improvements to be made as well. In addition to the gist, I wired up a little playground. The first input will create a database and fill it with that much dummy data, you can then input a size you’d like to save and it will use yardstick.js to determine if that’s possible. If you have any feedback or want to talk about this, please leave a comment here, on the Github gist, or contact me on twitter at @meirish.

Touch Input and Responsive Web Design

With the release of Windows 8, touch has finally landed on the desktop. There have been some great posts about the design implications of this change, but I haven’t seen much about technical implications, so I decided to write this. Chances are you’ve thought about  touch interaction if you were building a separate mobile site, but what does it mean for a desktop site or a responsive site?

Why Optimize for Touch?

Why is this something you’d want to do? It boils down to making things better for those who visit your site regardless of the device they’re using. This is why many people and companies have chosen Responsive Web Design. But what does Windows 8 have to do with any of this? It’s the first desktop operating system to include touch (and pen input, but more about that later) as an OS-wide, first-class input mechanism. So suddenly, if you have touch hardware, your desktop browser is going to be firing real touch events instead of using a third-party software abstraction to fire mouse events in the OS.

Who should be checking to see if their site needs any changes? If you’re doing anything with JavaScript click-handlers – most sites these days are doing something - then there are some touch-related things to think about. Additionally, maybe you want to consider gestures of some sort or you want to incorporate two or three-finger touch events. But the most important thing to consider is how you handle the simple single-touch event. Often you’ll want to trigger a touch event instead of click.

I’m going to focus on this last one as I think it’s the most common case. The reason single-touch needs “fixing” is that click events incur a penalty in the form of a 300 millisecond delay on many touch-enabled devices. This is to allow the OS to determine if you meant to pan or zoom instead of just clicking. You can speed up this interaction by checking those things yourself.

Optimizing (allthethings) for Touch

There are a few ways to do this. You can feature-detect touch events and then bind to “touchend” instead of click. (Modernizr is great for this but may be overkill for this one use case.) If you decide to go this route you will have to manage everything yourself: handle touch, determine if the user is scrolling/panning/zooming (if they are: don’t fire the handlers, if they’re not: fire it), and then after you fire it there will still be a click event fired.

What—you were expecting this to be straightforward? We are dealing with web browsers after all! What can we do to make this easier? Use a library, of course! But before doing that, I recommend reading through this Google post (this was the first place I read about the technique) so that you understand everything involved with overriding the default browser behavior. The library I’d recommend using is FTLabs’s FastClick. Be sure to read through the source too, it’s well documented. The nice thing about FastClick is that you only have to bind it once for the whole document and it only inserts itself if your device supports touch, as it has the feature-detection built in.

The Touch Future (or: When Touch is Not Enough)

Touch and click events are closely related as there was some effort to have backwards compatibility. But leave it to IE to break up the party. Turns out IE10 and “Metro” apps don’t have touch events (read more about the problem in this Modernizr issue on Github). Instead, Microsoft has abstracted and unified input mechanisms with what they’re calling pointer events. Instead of binding to touch or click, you bind to pointer event and the OS knows when to fire it based on the input method you’re currently using (touch, mouse, pen, laser, etc.). Boris Smus has written a polyfill for pointer events and has a great post explaining it, though I think it might not be ready for primetime. Recently, the W3C has formed a committee to begin the standardization process for pointer events, so it’s definitely something to keep an eye on.

I think pointer events will be the way forward because they are a better abstraction, and you don’t have to do a bunch of hokey pokey to get things to work properly, you simply let the browser do the heavy lifting for you. Even if that’s true though, touch events aren’t going anywhere anytime soon. They’re something you’ll need to feature-detect (there’s talk of defining Modernizr.pointer or Modernizr.mspointer in the above Modernizr issue) and then do what web developers always do: treat IE differently.

Using Charles Proxy to Optimize Mobile App Performance

With today’s metered data plans and intolerance for slow apps, mobile app users are very sensitive to excessive data consumption and underperformance.

Even a well-functioning app can have underlying inefficiencies, and a great way to fully understand your app’s data usage pattern is by running all its traffic through an HTTP proxy like Charles. When connected to the proxy you can complete tasks as a user would, to see exactly what’s being requested by your app, what’s being returned by the servers, and even the server response times.

Set up a Charles environment

(NOTE: Device and PC must be on the same Wi-Fi network)

On your computer:

  1. Download and run Charles
  2. Go To Help -> Local IP and write down the IP Address
  3. If you use SSL for your data requests:
    • Go to Proxy -> Proxy Settings -> SSL -> Check “Enable SSL” and add the host and port for your requests
    • You may also want to disable Desktop and web proxies from the Proxy dropdown so you can better isolate your app traffic

On your device:

  1. Install the Charles SSL Certificate on your device, visit one of these URLs on your device, and accept the security warning:
  2. Configure Device
    1. For Android: go to Settings -> Wifi -> Tap and hold wi-fi SSID -> Modify Network -> Show advanced Options -> Proxy Settings -> Manual
      • Server = IP address from Step 2
      • Port = 8888
    2. For iOS: go to Settings -> Wi-Fi -> (>) button for Wifi SSID -> Proxy=Manual ->
      • Server = IP address from Step 2
      • Port = 8888
    3. You might want to turn off cellular data to ensure all traffic is run through Wi-Fi/Charles Proxy

NOTE: If you quit Charles the device will have no connection until you undo the items in step 2b or 2c.

Fire it up

Launch Charles and switch to the “sequence” tab in the top window to see each call and status as they are made in real-time, including response size and duration. Click on a request to view details in the bottom pane including:  Overview, Request, Response & Summary.

Make sure you explore the options for the different data types. For example, if your response is an image, you can see the actual image and dimensions. If your app consumes JSON, you have a choice of a JSON Tree Navigator, or you can “copy response” by right-clicking the request in the top “Sequence” tab. Paste the results into something like http://www.uize.com/examples/json-prettifier.html for easy-to-read output.

I typically start with a fresh install of my application to ensure nothing is being read from the cache and that all data comes from the server, and then I start a new session. Here’s my list of some things to consider to ensure data transfer is optimized and the app doesn’t have to work harder than is necessary:

Things to check during app launch

  • Is your app making a reasonable amount of data requests to balance startup time and pre-fetching, to speed up “next pages”?
  • Is any request fetching more data than necessary?
  • Are the response times high due to server configuration or a poorly performing backend?

Things to check during app usage

  • Is there a common navigation path that is slow and could benefit from pre-fetching at launch?
  • Is data actually coming from the cache rather than initiating a new data request?
  • Is any tracking data being sent (e.g. Omniture, Google Analytics, or other third-party services), and if so is it sent properly ?
  • Are there any requests being made erroneously or repeatedly due to a coding error?
  • If you serve video, is the proper encoding/format selected? (Charles can throttle speeds to mimic wireless phone connections.)
  • Are images appropriately sized for the device?

More Resources:


Chapter 10. Secrets of High Performance Native Mobile Applications

Web Performance Daybook Volume 2

A brief history of mobile writing (1500-1700)

On November 2, 2012 I attended Take Note, a conference on note-taking and annotations, held at the Radcliffe Institute for Advanced Study. There was a lot I found interesting, but this one topic spawned enough digression that it became a post in its own right. [Edit: See also my overview of the online exhibition.]

My tables, my tables

Draw your tables, and write what wise I speak. (a 1592) R. Greene Sc. Hist. James IV in Wks., 1861  - OED

Tiffany Stern, Professor of Early Modern Drama at Oxford University, presented on the intersection of note-taking, transcription, and English dramatic performance. She didn’t use this phrase, but to me, the talk was about the origin of mobile writing.

The challenge of writing on-the-go in a quill-pen-slow-drying-ink world hadn’t really occurred to me before, but it was a real problem that required technological innovation. Writing tables (or table-books) were the literal notebooks of the 16th and 17th centuries, providing a hard writing surface and a custom stylus. Unlike ink-based home writing desks, table books were portable and, more importantly, erasable. A user would transcribe in the field and then write up the notes more formally with pen, ink, and powder at home. The table-book could then be wiped clean and available for re-use on the next outing.

The ability to erase a table-book was its signature feature to users of that time. References to its inherent mutability can be found through writings of the period, particularly in Shakespeare. It’s interesting that this quote is less metaphorical than it seems to modern readers — Shakespeare is pretty much describing a literal Renaissance Etch-A-Sketch:

Yea, from the table of my memory
I’ll wipe away all trivial fond records
- Hamlet Act 1, Scene V

Anonymous table-book scribble, 1581

This feat was accomplished in part due to the writing device (the graphite pen or stylus) but mostly due to the unique coating of the table-book paper, typically some highly-proprietary preparation of varnish. Like any good gadget freak, 17th century blogger Samuel Pepys could not wait to unbox the latest in erasure technology, nor did he fail to heed the charming urgings of a booth babe:

“…thence [I went] to one Lovett’s, a varnisher, to see his manner of new varnish, but found not him at home, but his wife, a very beautiful woman, who shewed me much variety of admirable work, and is in order to my having of some papers fitted with his lines for my use for tables and the like. I know not whether I was more pleased with the thing, or that I was shewed it by her, but resolved I am to have some made.
- Samuel Pepys, May 5, 1665

(It’s also interesting to read the 21st century commentary on his journal, particularly here, where readers naturally assumed that this varnish is to be applied after writing, as a preservative, rather than before, as a method to enhance ephemerality.)

According to Stern, table-books became a status symbol: they demonstrated that you were so highly literate that you couldn’t bear to be without your tables, even if you in fact barely wrote on them. At the conference, someone on Twitter wryly compared them to Moleskine notebooks (and I resemble that remark), but iPad covers may be more apropos. The frequent mismatch between the expense of table-books and the enlightenment of their owners did not go unnoticed at the time:

In hast plucks forth his Tables as to write
Some Sermon-Note, mean while does only scrawl,
Forgotten Errands there, or nought at all.
- Characters of Vertue and Vice (Nahum Tate, 1691, via Woudhuysen, 2004)

Because of the very everyday nature of these items, table-books were not often preserved, and today are considered to be exceedingly rare.


Once technology enabled mobile writing, the limiting factor on live transcription rate became writing speed. Thus began an arms-race in shorthand writing systems; dozens proliferated in the period between 1570 and 1650. Stern highlighted the system proposed by P. Bales in Arte of Brachygraphie, and it had an intriguing quotation about the right of universal access to knowledge for all [men], but unfortunately I can’t find an online edition with full text.

A much later book on brachygraphy held by the Internet Archive provides some samples, if you, like me, had never really seen shorthand –

Shorthand example from Gurney, 1838

And fittingly, this digital edition preserved the print book’s own note-taking: a student at practice in the flyleaf –

Student note in the flyleaf of Gurney, Brachygraphy. I did try translating it using the book, but got stuck on the very first character.

Portability plus high throughput dramatically reduced the difficulty of producing live transcription, and thus a form of book piracy was born. Audience members would hastily transcribe sermons and play premieres and then rush them into printingexactly analogous to today’s cam bootlegs. Variations between transcribed versions and authentic publications are usually errors, but can also be records of how dramatic works were actually rendered in a particular performance.

Shorthand persisted into the 20th century, of course, but I’d never released the extent to which it was never a unified “standard.” Curiously, of all the forms of shorthand invented in the history of writing, only one character from one system exists among the 110,180 glyphs available in Unicode: the Tironian et, first invented in 1st century BCE. Its sole frequent use today is in Irish and Scottish signage, as an abbreviation for “and”. I end then, improbably, with a conjunction: .