Steven Paul Jobs, 56, died Wednesday at his home with his family. The co-founder and, until last August, CEO of Apple Inc was the most celebrated person in technology and business on the planet. No one will take issue with the official Apple statement that “The world is immeasurably better because of Steve.”

With Steve Jobs’ passing, we have lost one of the greatest technological innovators of our time.

Jobs wasn’t just a savvy businessman, he was a visionary who made it his mission to humanize personal computing, rewriting the rules of user experience design, hardware design and software design. His actions reverberated across industry lines: He shook up the music business, dragged the wireless carriers into the boxing ring, changed the way software and hardware are sold and forever altered the language of computer interfaces. Along the way, he built Apple up into one of the most valuable corporations in the world.

Apple I, 1976

Apple Computer was founded on April 1, 1976 by a small group headed by Jobs, engineer Steve Wozniak and industry vet Ronald Wayne, who was brought in to provide “adult supervision.”

Priced at $666.66, Apple’s first computer was little more than a circuit board. Once you bought one, you still had to hook up your own keyboard, monitor and power supply. As such, the Apple appealed mostly to the DIY hardware hackers of the day, who had these things on hand already.

Apple II, 1977

The company hit the jackpot one year later with 1977′s Apple II, a fully assembled desktop computer in a handsome case. Hackers still took to it because of its expandability. More importantly, schools used it to teach programming (it ran Integer BASIC) and offices started snatching them up once VisiCalc launched on the nascent platform.

Macintosh, 1984

The Macintosh arrived in 1984, and it was the first computer to successfully integrate two things that are now commonplace: a graphical user interface and a mouse. Little pictures of folders, the piece of paper denoting a file, the trash can — most of us learned how all of these things worked when we sat down at the Mac. Drag-and-drop, too.

Apple launched the Macintosh with a massive media campaign spearheaded by a minute-long TV commercial (riffing on Orwell’s 1984) that aired during the Super Bowl.

Apple’s Super Bowl Ad

Apple IIc, 1984

Only a few months after launching the Macintosh, Apple released the Apple IIc, a slimmed-down version of the Apple II that was much more portable. It had a handle on the back so you could carry it around comfortably with one hand. It wasn’t quite a laptop — the monitor and power supply weren’t attached — and the guts weren’t a whole lot different than what you got in the bigger Apple II models. But the little white eight-pound box was an important step for desktop computers.

It was one of the first small-form-factor PCs to hit the market, signaling the industry-wide move toward compact, integrated designs that would come later. Also, its diminutive size and unassuming looks were far less intimidating than the hulking machines common in the mid-1980s. It was an era when computers beginning to creep into middle-class homes, and first-time buyers found the IIc a “friendly” and appealing option. It looked equally attractive in the family room as it did in the office.

LaserWriter, 1985

It cost $7,000 and was bigger than your microwave. But put one on your desk and you could publish your own newspaper.

The LaserWriter wasn’t the first desktop laser printer to hit the market, but it was the first created for the Macintosh, and the first to use the cutting-edge PostScript language that gave designers a new level of control over page layout, text options, and graphics. It was announced on the same day as its killer app, Aldus PageMaker.

So while the LaserWriter wasn’t the first shot fired in the desktop publishing revolution, it was the first to draw blood.

Pixar, 1986

Steve Jobs bought Pixar in 1986. At the time, it was a small group of engineers spun off from the computer graphics department at Lucasfilm. Jobs paid $5 million to George Lucas and sank $5 million of his own money into the company.

His original vision for Pixar was to develop graphics-rendering hardware and software, but the business eventually evolved into an animation studio. Jobs signed a distribution deal with Disney and Pixar began cranking out a string of hit family films, all of them computer-animated. 1995′s Toy Story was the first blockbuster. Toy Story 2, Monsters, Inc., Finding Nemo, The Incredibles, Cars, WALL-E and Upfollowed. Accolades and Oscars came rolling in, along with massive mountains of cash.

In 2006, Jobs flipped his original $10 million investment, selling Pixar to Disney for $7.4 billion in stock. That’s one hell of an exit.

NeXT, 1988

After the success of the Macintosh, Jobs was marginalized by Apple’s board of directors, so he left to found a new computer company called NeXT. Without Jobs at the helm, Apple floundered through the early 1990s. A series of missteps eventually caused the company’s market share to fall into the low single digits.

Meanwhile, Jobs launched a new computer system at NeXT. Its most famous workstation was an austere black cube — Jobs constantly pushed his designers to experiment with innovative case constructions throughout his career — that cost $6,500. It ran a new operating system, NeXTSTEP, which was based on Unix.

Though it was pricey, it was fast and especially adept at math functions, and it had a built-in Ethernet port in an age when most computers still needed a network interface card. Because of these high-end features, NeXT boxes were ignored by the mass market, but quickly snatched up by academics and programmers. Tim Berners-Lee used one to write the first web server and the first web browser. The first server node on the World Wide Web was a NeXT box.

iMac, 1998

After NeXT failed to gain traction, Jobs sold the company to Apple and came back into the fold in 1996. Two years later, the company released a complete rewrite of the desktop PC — the candy-colored iMac. It kicked the boring beige PC box to the curb, and it marked the return of the revolutionary all-in-one design first introduced by the original Macintosh. The first iMac was a runaway hit, and the all-in-one design is still used by today’s iMac (and widely copied by other PC manufacturers).

Power Mac G4 Cube, 2000

Jobs wasn’t ready to let go of his dream of a cube-shaped computer, which he first tried at NeXT. He encouraged Apple designer Jonathan Ive to work the shape into the Power Mac line, and the company pumped out the eight-inch clear acrylic cube in 2000.

It didn’t do so hot. It was $1,800, the disk drive had problems, and the case developed stress cracks easily.

Still, it was a forward-thinking step that design nerds still drool over. There’s even one in the MoMA’s permanent collection.

iPod, 2001

The first iPod was a $400 MP3 player with a 5-gigabyte hard drive and a mechanical scroll wheel that didn’t sync to Windows machines. Not a very likely candidate for the device that would completely change the music industry.

But it did, pouring fuel on the fire of online mayhem lit by Napster and creating a mindset among music device buyers where ease-of-use, convenience and sex appeal trump all other features.

The iPod’s all-white design was minimalist compared to other players that came before and, more importantly, the user interface was remarkably easy for anyone who picked it up to figure out.

The hardware had its quirks — if you got sand in the scroll wheel, you’d get stuck listening to Spin Doctors all day — but it was quickly refined to incorporate further innovations: the touch-wheel, a color screen for watching videos and eventually, the industry-standard touchscreen.

Mac OS X, 2001

When Steve Jobs returned to Apple, he ordered a rethink of the Mac’s native operating system. Of course, he pushed for NeXTSTEP — the Unix-based OS he developed independently and sold to Apple in 1996 — to serve as the blueprint.

Eventually surfacing in 2001, Mac OS X was a complete departure from earlier Mac operating systems and, as Jobs had promised, a true “next generation” OS.

It appealed to novices fluent in Windows (enabling the craze of “switching”) but it retained enough of its Unix guts and enough of Apple’s well-established interface conventions to keep the Apple geeks interested.

Apple Stores, 2001

Walk into any big-box store — BestBuy, Wal-Mart, Target — and go to the computer department in the back. Look at all the PCs on display. It’s a mess of machinery, heaps of humming boxes all shaped, priced and configured differently. The sales people aren’t always well-trained, and concise technical answers are difficult to come by. Jobs understood purchasing decisions are made on the sales floor, and he didn’t want Apple’s appeal to get lost in the quagmire of somebody else’s retail failure. His solution? Build your own house.

Apple retail stores began popping up in 2001. Everything about their environment is tightly controlled. Only Apple computers are displayed and accessories are thoughtfully curated. Employees are approachable and well-trained, and they carry hand-held point-of-sales devices. Every store has a Genius Bar, the retail-level customer support help desk, and most have a classroom where you can learn how to use your Mac.

There are now over 300 Apple Stores worldwide. Even more phenomenal than the boost they provide to Apple sales is the way they fuel the Apple culture. On regular days, the stores buzz with the excitement of a crowded nightclub. On product launch days, eager customers queue up for hours, even days.

iTunes Store, 2003

iTunes was the first hint at Jobs’ vision to turn the home PC into a “digital lifestyle hub.” That plan was cemented in 2003 by the debut of the iTunes Store. Suddenly, it wasn’t just about creating or collecting media, but purchasing it, too.

And because it was directly plugged into the iPods everyone already owned, the iTunes Store was a huge hit. With it came the era of the digital single, easily downloadable for $0.99 and offering instant satisfaction.

Of course, the record companies weren’t happy to see their monopoly on distribution challenged. But traditional retail tapered while iTunes exploded. Tower Records folded. Virgin Megastores were boarded up. By 2007, Apple was selling 5 million songs a day.

Intel MacBook Pro, 2006

In 2006, Jobs announced that Apple would be switching from PowerPC processors to Intel’s Core Duo chips. The MacBook Pro, released soon after the announcement, was Apple’s first laptop with an Intel CPU. The whole Apple line was transitioned to Intel before the end of the year, an astonishingly short period of time.

Jobs said he and the Apple engineers felt the PowerPC architecture had hit a ceiling and wasn’t improving fast enough. By switching to Intel, the average clock speeds of Macs were drastically improved, especially in laptops. Sales soared, too, as Apple laptops could finally compete on both price and performance with Windows-based machines (and they could even run Windows).

iPhone, 2007

During his keynote address at Macworld 2007, Jobs said Apple would announce three things: “A widescreen iPod with touch controls, a revolutionary mobile phone and a breakthrough internet communications device. An iPod, a phone and an internet communicator.” Of course, it was all three of those things in one — the iPhone.

Years on, Apple’s phone has not only completely changed our expectations of how a smartphone should look, feel and behave, but Jobs’ famous wrangling with the wireless carriers has toppled the long-standing power structure in the industry.

Before Apple, carriers insisted on controlling the hardware and software on their phones. Now, if they want the hottest phones, the carriers have to play ball.

App Store, iPhone SDK, 2008

The next time you’re in an Apple Store, take a look at that constantly shrinking shelf of boxed software. Smells like 2007, right?

With the arrival of the iPhone SDK in 2008, developers could create their own native apps for the iPhone and sell them through the App Store built into iTunes. This not only set up a clean, centralized distribution model for apps, but also introduced a budget-minded pricing structure — $1 and $2 apps — that encouraged you to download as many apps as you wanted. It was a boon for developers.

Unfortunately, it also earned Apple the title of “Gatekeeper,” souring relationships with developers who were suddenly subjected to the company’s arcane app approval guidelines.

But the damage is done. Today, it’s all about apps.

MacBook Air, 2008

When it showed up in 2008, the MacBook Air was touted as “the world’s thinnest notebook.”

Thin and light have always been sexy, but this one was weird. It shipped without an optical drive. You could buy an external DVD drive if you really needed one, or you could simply “borrow” another computer’s DVD drive and beam the data over Wi-Fi. Even though many laughed at the notion, the Air was Exhibit A to those predicting the death of the optical drive.

Close to four years later, disks and drives are still around, but they are disappearing quickly as software increasingly moves into the browser and into cloud-based app stores.

Also, Windows laptop manufacturers are now competing in an entirely new category: “ultrabooks.” These super-portable laptops cost a little more, but they are thin, very light, use SSDs, ship without optical drives and are fitted into brushed metal cases — just like the MacBook Air.

iPad, 2010

It’s the device everyone wanted Apple to create, even though most of us weren’t sure how it was going to fit into our lives once it got here. But Jobs got sentimental when showing off the first iPad in 2010. He said it was a culmination of years of work, starting with OS X, then iTunes, then the iPhone, then the App Store.

The shockwaves are still evident more than a year later as manufacturers race to catch up, pumping out their own tablets. But they can’t match Apple’s success.

The iPad 2 was Steve’s swan song. We all felt it, but few chose to accept it. What nobody can argue is that the man went out on top, crossing the finish line well ahead of everyone else.

Local notifications and push notifications are both ways for an application that isn’t running in the foreground to let its users know it has something for them. That something could be a message, an impending calendar event, or new data on a remote server. When presented by the operating system, local and push notifications look and sound the same. They can display an alert message or badge the application icon. They can also play a sound when the alert or badge number is shown.

Push notifications were introduced in iOS 3.0, and local notifications in iOS 4.0. Push notifications and local notifications are not related to broadcast notifications (NSNotificationCenter) or key-value observing notifications.

Once users are aware that the application has a message, event, or other data for them, they can launch the application and access that item. They can also choose to ignore the notification, in which case the application is not activated.

When a device receives a notification for an application and that application isn’t running, it notifies the user through an alert message or a sound, or by adding a numbered badge to the application. The APNS does not provide any feedback as to whether the message was successfully delivered to the user.

Restrictions

• The payload is limited to 256 bytes in total – this includes both the actual body message and all of the optional and additional attributes you might wish to send. Push notifications are not designed for large data transfer, only for small alerts. For example we only send a short alert message detailing the server monitoring alert triggered.
• APNS does not provide any status feedback as to whether your message was successfully delivered. One reason for this is that messages are queued to be sent to the device if it is unreachable, however only the last sent message will be queued – overwriting any previously sent but undelivered messages.
• Push notifications should not be used for critical alerts because the message will only be delivered if the device has wifi or cellular connectivity, which is why we recommend combining push with another alerting method such as e-mail or SMS for our server monitoring alerts.
• The SSL certificates used to communicate with APNS, discussed below, are generated on an application level. The implementation discussed in this tutorial only concerns a single iPhone application so if you have several, you will need to adapt the code to use the appropriate certificate(s) where necessary.

Device Token

Each push message must be “addressed” to a specific device. This is achieved by using a unique deviceToken generated by APNS within your iPhone application. Once this token has been retrieved, you need to store it on your server, not within your iPhone application itself. It looks something like this:

c9d4c07c fbbc26d6 ef87a44d 53e16983 1096a5d5 fd825475 56659ddd f715defc

For iPhone applications, we call the necessary generation methods on app launch and pass it back to our servers via an HTTP API call. This stores the deviceToken in a database on our servers for that user so we can then communicate with the device linked to that user

Feedback Service

Apple provides a feedback service which you are supposed to occasionally poll. This will provide a list of deviceTokens that were previously, but are no longer, valid, like if the user has uninstalled your iPhone application. You can then remove the deviceToken from your database so you do not communicate with an invalid device.

Using the feedback service is not covered by this tutorial.

Certificates

The first thing you need is your Push certificates. These identify you when communicating with APNS over SSL.

Generating the Apple Push Notification SSL certificate on Mac:

1. Log in to the iPhone Developer Connection Portal and click App IDs
2. Ensure you have created an App ID without a wildcard. Wildcard IDs cannot use the push notification service. For example, our iPhone application ID looks something like AB123346CD.com.mobilesnapp.iphone
3. Click Configure next to your App ID and then click the button to generate a Push Notification certificate. A wizard will appear guiding you through the steps to generate a signing authority and then upload it to the portal, then download the newly generated certificate. This step is also covered in the Apple documentation.
4. Import your aps_developer_identity.cer into your Keychain by double clicking the.cer file.
5. Launch Keychain Assistant from your local Mac and from the login keychain, filter by the Certificates category. You will see an expandable option called “Apple Development Push Services”
6. Expand this option then right click on “Apple Development Push Services” > Export “Apple Development Push Services ID123″. Save this as apns-dev-cert.p12 file somewhere you can access it.
7. Do the same again for the “Private Key” that was revealed when you expanded “Apple Development Push Services” ensuring you save it as apns-dev-key.p12 file.
8. These files now need to be converted to the PEM format by executing this command from the terminal:
   openssl pkcs12 -clcerts -nokeys -out apns-dev-cert.pem -in apns-dev-cert.p12
   openssl pkcs12 -nocerts -out apns-dev-key.pem -in apns-dev-key.p12
9. If you wish to remove the passphrase, either do not set one when exporting/converting or execute:
   openssl rsa -in apns-dev-key.pem -out apns-dev-key-noenc.pem
10. Finally, you need to combine the key and cert files into a apns-dev.pem file we will use when connecting to APNS:
    cat apns-dev-cert.pem apns-dev-key-noenc.pem > apns-dev.pem

It is a good idea to keep the files and give them descriptive names should you need to use them at a later date. The same process above applies when generating the production certificate.

Payload Contents

The payload is formatted in JSON, compliant with the RFC 4627 standard. It consists of several parts:

• Alert – the text string to display on the device
• Badge – the integer number to display as a badge by the application icon on the device home screen
• Sound – the text string of the name of the sound to accompany the display of the message on the device
• This tutorial will only deal with the basics of sending a simple alert text string but this can also be another dictionary containing various options to display custom buttons and the like.[CK1]

Creating the payload

Using PHP, it is very easy to create the payload based on an array and convert it to JSON:

$payload['aps'] = array(‘alert’ => ‘This is the alert text’, ‘badge’ => 1, ‘sound’ => ‘default’);

$payload = json_encode($payload);
Echoing the contents of $payload will show you the JSON string that can be sent to APNS:

{“aps” : { “alert” : “This is the alert text”, “badge” : 1, “sound” : “default” }}

This will cause a message to be displayed on the device, trigger the default alert sound and place a “1″ in the badge by the application icon. The default buttons “Close” and “View” would also appear on the alert that pops up.

For the iPhone application, it is important for the user to be able to tap “View” and go directly to the server that generated the alert. To do this, we add an extra dictionary of our own custom values:

$payload['aps'] = array(‘alert’ => ‘This is the alert text’, ‘badge’ => 1, ‘sound’ => ‘default’);

$payload['server'] = array(‘serverId’ => $serverId, ‘name’ => $name);

$output = json_encode($payload);
The custom dictionary server is passed to the application on the device when the user taps “View” so we can load the right server. The JSON looks like this:

{ ”aps” : { “alert” : “This is the alert text”, “badge” : 1, “sound” : “default” },

“server” : { “serverId” : 1, “name” : “Server name”)}

The size limit of 256 bytes applies to this entire payload, including any custom dictionaries.

The raw interface

Once an alert is generated within Server Density, the payload is built and then inserted into a queue. This is processed separately so that we can send multiple payloads in one go if necessary.

Apple recommends this method because if you are constantly connecting and disconnecting to send each payload, APNS may block your IP.

As described by Apple:

The raw interface employs a raw socket, has binary content, is streaming in nature, and has zero acknowledgment responses.

Opening the connection

The PHP 5 code to open the connection looks like this:

$apnsHost = 'gateway.sandbox.push.apple.com';

$apnsPort = 2195;

$apnsCert = 'apns-dev.pem';

$streamContext = stream_context_create();

stream_context_set_option($streamContext, 'ssl', 'local_cert',

$apnsCert);

$apns = stream_socket_client('ssl://' . $apnsHost . ':' . $apnsPort, $error, $errorString, 2,

STREAM_CLIENT_CONNECT, $streamContext);

If an error has occurred you can pick up the error message from $errorString. This will also contain the details if your SSL certificate is not correct.

The certificate file is read in relative to the current working directory of the executing PHP script, so specify the full absolute path to your certificate if necessary.

Note that when testing you must use the sandbox with the development certificates. The production hostname is gateway.push.apple.com and must use a separate and different production certificate.

Sending the payload

At this point, the code we use loops through all the queued payloads and sends them. Constructing the binary content to send to APNS is simple:

$apnsMessage = chr(0) . chr(0) . chr(32) . pack('H*', str_replace(' ', '', $deviceToken)) . chr(0)

. chr(strlen($payload)) . $payload;

fwrite($apns, $apnsMessage);

Note that the $deviceToken is included from our database and stripped of the spaces it is provided with by default. We also include a check to send an error to us in the event that the $payload is over 256 bytes.

$apnsMessage contains the correctly binary formatted payload and the fwrite call writes the payload to the currently active streaming connection we opened previously, contained in $apns.

Once completed, you can close the connection:

socket_close($apns);

fclose($apns);

There are 3^rd party tools that take care of push notifications for your app, like Urban Airship. I will be covering its implementation in my next blog spot. Please feel free to leave a comment.

You might find these additional sources of information useful for understanding and implementing push notifications:

• The reference documentation for UILocalNotification, UIApplication, and UIApplicationDelegate describe the local- and push-notification API for client applications.
• Security Overview describes the security technologies and techniques used for the iOS and Mac OS X platforms.
• RFC 5246 is the standard for the TLS protocol.

Secure communication between data providers and Apple Push Notification Service requires knowledge of Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). Refer to one of the many online or printed descriptions of these cryptographic protocols for further information.

This tutorial is for getting started with Android Cloud to Device Messaging (C2DM) on Android. In the iOS world this is known as “push notifications”.

There are many good resources out there for getting started, but all of them, I felt, were lacking in one way or another, which is why I decided to put together this tutorial of my own. A lot of my code and structure is borrowed from other posts that are referenced in the links at the end.

On the iPhone, notifications are easy to implement and include, since iPhone OS 3.  However, it’s a little more complex on Android. Additionally, the Google provided “Android Cloud to Device Messaging” is only built into its OS starting from Android 2.2. That said, C2DM is not designed to just send simple messages, they can include any kind of payload and are used for all kinds of updates, not just text alerts:

“Android Cloud to Device Messaging (C2DM) is a service that helps developers send data from servers to their applications on Android devices. The service provides a simple, lightweight mechanism that servers can use to tell mobile applications to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queueing of messages and delivery to the target application running on the target device.”

What if we want to support Android 1.6+?  Fact: 1.6 and 2.1 make up 56.8% of deployed versions.  We can’t just ignore over half of the Android population.  We need an alternative to C2DM.

C2DM Alternatives

• Polling. The application itself will periodically poll your servers to check for new messages. You will need to implement everything from queuing messages to writing the polling code. Alerts are no good if they are delayed due to low polling periods.  But the more frequently you poll, the faster your battery is going to die.
• SMS. Android can intercept SMS messages.  You could include a payload to tell the app what to do, but then why not just use SMS in the first place?
• Persistent connection. This would solve the problem of periodic polling but would destroy the battery life. Apple’s push notifications work well because there’s only ever 1 service connecting to Apple’s servers. This is also how the C2DM service works.  This means you don’t have every app leaving open connections.

Working with C2DM

Google provides detailed documentation and sample projects onhow to implement C2DM in your Android Java project. They also have a good mailing list with Google employees who actually reply in just a few hours. However, like Apple, their documentation is lacking on how to implement the server side aspects – the bit that actually sends the message from you to Google, and then onto the user.

The complex part of Apple’s service is setting up the SSL certificates. This isn’t necessary for Google but they do require a ClientLogin token, which is equally complex:

“With programmatic authorization implemented, your users can log into their Google account and grant access to their Google service data from inside your application. The application then contacts Google with the login data and requests access to a specified Google service. Once Google authorizes access, your application can access the Google service data, allowing the user to create, read, update, or delete service data as needed using your application interface.

Authorization with the ClientLogin API is a step up from the “low-tech” approach, which required applications to include the user’s login name and password in every request to a Google service. With programmatic login, Google issues a token that can be referenced in all subsequent requests.”

Once you have that token you can then communicate with the C2DM service. How this might work in practice with a real app is as follows:

1. The user launches your app on their Android device. You call the C2DM registration method.
2. After the user has logged in, Google provides a registration ID to uniquely identify the device. You must send that ID to your servers and store it so you can communicate with the user.
3. You send a message to the user using their registration ID. This consists of a POST to the Google C2DM service.
4. The user’s device receives the message and you handle it.

Step 3 is the server side code that we’re going to deal with here. The other steps are all implemented in Java in the app itself, and are outside the scope of this tutorial.

Sending messages to Google C2DM – ClientLogin authentication

You first need to register to use C2DM. It’s recommended that you set up a separate Google account just for this. If you use a Google Account that is both a Google Account and a Hosted Google Account (through Google Apps) then you may have a conflict. In this case, the Hosted account will always get registered (source).

“You can also try to request “HOSTED” instead of “HOSTED_OR_GOOGLE” in ClientLogin – the hosted account is enabled for C2DM if there are both a hosted and a consumer ( google ) account. If your domain is converted to use the new ‘consumer’ account style – the problem may go away as well, since the old consumer account will be renamed.”

You then need to obtain the ClientLogin token for the account you registered with C2DM. The process is well documented and there are plenty of things you need to handle (like CAPTCHA and expiring tokens) but this Python sample code will get a token for you:

import urllib, urllib2

class ClientLoginTokenFactory():

_token = None

def __init__(self):

self.url = ‘https://www.google.com/accounts/ClientLogin’

self.accountType = ‘GOOGLE’

self.email = ‘example@gmail.com’

self.password = ‘password’

self.source = ‘Domokun’

self.service = ‘ac2dm’

def getToken(self):

if self._token is None:

# Build payload

values = {‘accountType’ : self.accountType,

‘Email’ : self.email,

‘Passwd’ : self.password,

‘source’ : self.source,

‘service’ : self.service}

# Build request

data = urllib.urlencode(values)

request = urllib2.Request(self.url, data)

# Post

response = urllib2.urlopen(request)

responseAsString = response.read()

# Format response

responseAsList = responseAsString.split(‘\n’)

self._token = responseAsList[2].split(‘=’)[1]

return self._token

(Code taken and modified from sample posted here).

You need to replace self.email, self.password and self.source with your own credentials. The self.email and self.password are for the account you signed up to C2DM with and self.source can be anything identifying who you are to Google – see here for details. If you’re using a hosted Google account then you need to change self.accountType too – see here for details.

To execute this code you’d use:

clientAuthFactory = ClientLoginTokenFactory()

clientAuth = clientAuthFactory.getToken()

Sending messages to Google C2DM – cd2m/send

The payload you send to Google has a number of requirements, as detailed in their documentation. You need to specify the registration ID the user’s device has sent you and also provides a collapse key:

“An arbitrary string that is used to collapse a group of like messages when the device is offline, so that only the last message gets sent to the client. This is intended to avoid sending too many messages to the phone when it comes back online. Note that since there is no guarantee of the order in which messages get sent, the “last” message may not actually be the last message sent by the application server.”

You’ll also notice that there is no required “message” field. This is because the payload can contain many “data” fields and it is up to your app to handle them. This might just be a single field called data.message that is displayed by your app, or you could use it to send any other kind of data to update the app. For example, we could use it to send the latest data from a server, upon receiving it, to automatically refresh the values in the app.

This sample Python code will build the request, get your ClientAuth token (using the class posted above) and then send it.

class C2DM():

         def __init__(self):

               self.url = 'https://android.apis.google.com/c2dm/send'

               self.clientAuth = None

               self.registrationId = None

               self.collapseKey = None

               self.data = {}

        def sendMessage(self):

               if self.registrationId == None or self.collapseKey == None:

                       return False

               clientAuthFactory = ClientLoginTokenFactory()

               self.clientAuth = clientAuthFactory.getToken()

               # Loop over any data we want to send

               for k, v in self.data.iteritems():

                       self.data['data.' + k] = v

               # Build payload

               values = {'registration_id' : self.registrationId,

                                 'collapse_key' : self.collapseKey}

               # Build request

               headers = {'Authorization': 'GoogleLogin auth=' + self.clientAuth}

               data = urllib.urlencode(values)

               request = urllib2.Request(self.url, data, headers)

               # Post

               try:

                       response = urllib2.urlopen(request)

                       responseAsString = response.read()

                       return responseAsString

               except urllib2.HTTPError, e:

                       print 'HTTPError ' + str(e)

(Note this code is designed to be used in the same file as the previous sample code. If you separate them it requires import urllib, urllib2)

To use this code you need to call it like so:

sender = C2DM()

sender.registrationId = 'hats'

sender.collapseKey = 1

sender.data = {'message' : 'Hello there', 'hats' : 54}

response = sender.sendMessage()

sender.data takes a Python dictionary, which will be converted to the right format to send to C2DM. Note that the sender.registrationId is not set – it should be the registration ID for the user you want to send to.

What else you need to do

This sample code is useful for development but doesn’t do some things you’ll need for production:

• Error handling – you’ll need to do more advanced handling of any HTTP errors. If the Google service is down it’ll return a 503 HTTP code and a retry value, which you must honor.
• You must queue messages if the service returns a quota error. This needs to use Exponential backoff.
• The ClientLogin code does not handle CAPTCHA or resetting the auth token. See this post for how this might be presented.

Final words

Push notifications on Android are fairly fragmented right now. The Urban Airship solution provided in my upcoming blog post will provide a good solution; but it requires installing a separate 3^rd party app – not ideal.

More resources listed here:

• http://code.google.com/android/c2dm/index.html
• http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html

Finally, the moment you’ve been waiting for: submitting your completed app to the Android Market. The process is actually pretty straight forward: you just need to prepare a release version of the app and upload it.

Preparing a Release Version of Your App

You need to do a few things to get the app ready for distribution:

• Remove any debugging or logging code
• Version the app
• Compile the app
• Sign the compiled app with a private key

Removing Debug Code

There’s no reason to have debugging or logging code.  Those slow down your app while it’s running on a user’s phone.  You should open up the AndroidManifest.xml file in the KiloGap folder, search for “debuggable” and set it to false. When you are done, it should look something like this:

…

<application

android:icon=”@drawable/icon”

android:label=”@string/app_name”

android:debuggable=”false”>

…

Versioning Your App

Near the top of your AndroidManifest.xml file, you should see values set for the version name and version code for your app:

…

<manifest

xmlns:android=”http://schemas.android.com/apk/res/android”

package=”com.jonathanstark.kilo”

android:versionName=”1.0.0″

android:versionCode=”1″>

…

If this is probably your first app, these values are fine as is. Once you’ve published your app and later want to release an update, you’ll change these values appropriately. The Android system doesn’t      check or enforce this version information, but it’s a critical piece of data for your long term app strategy.

The version name is the value that will be shown to the user. It’s a string, so you can put whatever you want here, but the common practice is to use a <major>.<minor>.<point> format (such as 1.0.0).

The version code is expected to be a positive integer value. It need not correspond to the version name in any way. In fact, it probably won’t—you should just increment it by 1 every time you release an update, regardless of whether the release is a major upgrade or a minor bug fix.

Signing Your App

Android requires that all apps be digitally signed by the developer. The process for doing so is easy, but a little cryptic.

1) Launch the Terminal application and navigate into the KiloGap directory:

cd ~/Desktop/KiloGap

2) Compile the app in release mode:

ant release

You’ll see a page or so of output scroll by, ending with BUILD SUCCESSFUL. An unsigned binary named Kilo-unsigned.apk will now be sitting in the ~/Desktop/KiloGap/bin/ directory

 

3) Create a private key:

keytool -genkey -v -keystore keystore -alias alias -keyalg RSA -validity days

This command is interactive and will ask you a bunch of questions. Mine looks like this:

JSC-MBP:KiloGap jstark$ keytool -genkey -v -keystore myAndroidKey.keystore \

-alias myAndroidKeyAlias -keyalg RSA -validity 10000
Enter keystore password:
Re-enter new password:

What is your first and last name?

[Unknown]: John Doe

What is the name of your organizational unit?

[Unknown]:

What is the name of your organization?

[Unknown]: Jonathan Stark Consulting

What is the name of your City or Locality?

[Unknown]: Cupertino

What is the name of your State or Province?

[Unknown]: CA

What is the two-letter country code for this unit?

[Unknown]: US

Is CN=John Doe, OU=Unknown, O=Jonathan Stark Consulting, L=Cupertino, ST=CA, C=US correct?

[no]: yes

Generating 1,024 bit RSA key pair and self-signed certificate (SHA1withRSA) with a validity of 10,000 days for: CN=John Doe, OU=Unknown, O=Jonathan Stark Consulting, L=Cupertino, ST=CA, C=US
Enter key password for <myAndroidKeyAlias>
(RETURN if same as keystore password):
[Storing myAndroidKey.keystore]

When the process completes, you should see myAndroidKey.keystore created in the ~/Desktop/KiloGap directory. If you’d like to use this keystore for other apps in the future, you might want to move the keystore file to a more central location. 



4) Sign your app with the key you just created:

jarsigner -verbose -keystore myAndroidKey.keystore

./bin/Kilo-unsigned.apk myAndroidKeyAlias

When you run this command, you’ll be asked for your keystore password.

5) Align the .apk file:

zipalign -v 4 ./bin/Kilo-unsigned.apk ./bin/Kilo.apk

You’ll see a page or so of output scroll by, ending with “Verification successful.” A signed binary named Kilo.apk will now be sitting in the ~/Desktop/KiloGap/bin/ directory. This .apk file is your completed app!



Uploading Your App to the Android Market

All that is left to do is upload our signed binary to the Android Market.

1. Launch your web browser, navigate to http://market.android.com/publish/, and sign in to your Google account.

2. If you aren’t forwarded automatically after logging in, navigate to http://market.android.com/publish/Home and click the Upload Application button

3. Click the Choose File button next to “Application .apk file,” browse to Kilo.apk on your hard drive, and click the Upload button.

4. You can optionally upload a couple of screenshots to be displayed on the Market page for your app.

5. Enter a title for your app in the Listing Details section (30 characters max).

6. Enter a description for your app (325 characters max).

7. Select a type and category for your app.

8. Specify a price for your app.

9. Indicate your copy protection and location preferences in the Publishing Options section.

10. Enter your website address, email address, and phone number in the Contact Information section.

11. Agree to the terms in the Consent section.

12. Click the Publish button.

Congrats! Your app will be available in the Android Market almost immediately. 

Distributing Your App Directly

One very attractive feature of the Android platform is that it lets developers skip the Android Market completely and distribute apps directly to users. This is a great option in many situations. For example, a corporate IT department might want to distribute a private app to employees. Or maybe you want to run a private beta of your app before uploading it to the Android Market.

Whatever the case, direct distribution couldn’t be easier: upload your signed .apk binary to your web server and provide your users with a link to it. Users click the link— say, from an email message or a web page—and the app is downloaded and installed. Simple.

The only caveat is that users have to first allow installation of non-Market applications by navigating to Settings→Applications and enabling the Unknown Sources option. If the user has not first enabled downloads from unknown sources, the user will still be allowed to download the app, but will be alerted that the install is blocked. The alert dialog will allow him to navigate directly to the relevant setting or cancel the installation. When the user first activates the checkbox, they will see a confirmation dialog that warns them about the implications of their choice.



 

It’s the moment you’ve been waiting for! You are submitting your completed app to iTunes App Store. There are several steps to this process, so you’ll want to have all your ducks lined up before you even think about submission. At a minimum, you’ll need the following to complete the app…

Store submission process:

• A plain-text description for the application (4,000 characters max).
• A URL where people can learn more about your app.
• A support URL and email address so people can contact you with issues pertaining to your app.
• If your app requires a login, give full access credentials for a demo account so reviewers can test your app.
• A 512 × 512 pixel icon.
• A 320 × 480 pixel screenshot of your app.
• A distribution provisioning profile for the app.
• A zipped version of the application binary.

Everything you need for submission is fairly straightforward except for the last two items – the distribution profile for the app and the application binary. I’m going to cover those in detail in the following sections.

Creating an iPhone Distribution Provisioning Profile

You need to create a distribution provisioning profile in order to submit your app to iTunes App Store.

1. Navigate to the iPhone developer site (http://developer.apple.com/iphone/) and log in.
2. Click iPhone Developer Program Portal on the right sidebar.
3. Click on Provisioning on the left sidebar.
4. Click on the Distribution tab.
5. Click the New Profile button.
6. Choose App Store as your distribution method.
7. Enter a profile name (e.g., Kilo Distribution Provisioning Profile).
8. If you have not created a distribution certificate, you should do so before proceeding. If you see a link on this page labeled “Please create a Distribution Certificate,” click it and carefully follow the instructions. You’ll be making a couple of trips into the Keychain Access application (located in /Applications/Utilities) to create certificate signing requests and to install signed certificates that you download from the portal into your own keychain.
9. Select the appropriate App ID.
10. Click the Submit button (you’ll be returned to the Distribution Provisioning Profile list view).
11. Refresh the page until the Download button appears.
12. Click the Download button to save the profile to your local download directory (usually the Downloads folder in your Home folder).
13. Drag the downloaded profile into the Xcode icon on the dock.



Installing the iPhone Distribution Provisioning Profile

Now that the profile is in Xcode, you need to configure the project to use it.

1. Open Kilo in Xcode if it is not already open.
2. Select Edit Project Settings from the Project menu (the project settings window will appear).
3. Click the Build tab if it’s not already active.
4. Select Distribution from the Configuration pop up.
5. Select “Settings Defined at This Level” from the Show pop up.
6. Locate Code Signing→Code Signing Identity→Any iPhone OS Device in the main area of the window.
7. Click the pop-up list to the right of Any iPhone OS Device to display a list of profile options.
8. Locate your distribution provisioning profile in the list and select the distribution identity directly beneath it.
9. Close the Project Info window.

Renaming the Project

Before you submit your app, you need to rename it to Kilo. To do so:

1. Open the project in Xcode.
2. Select Rename from the Project menu.
3. Type Kilo in the “Rename project to” field.
4. You can leave “Take Snapshot before renaming” checked if you want to save the state of the project prior to making the change, but it will significantly increase the amount of time it takes to process the request.
5. Click the Rename button.

You will see a series of green circles with white checkmarks in them that indicate that the changes have taken effect.

Prepare the Application Binary

Next, we need to build the application executable and prepare it to be uploaded.

1. Select iPhone Device – 3.1.2 (or the current version of the iPhone OS) from the Active SDK pop up, then select it again and pick Distribution. This should set the target to something like “Device – 3.1.2 | Distribution.”
2. Select “Clean All Targets” from the Build menu.
3. Select “Build” from the Build menu. You may be prompted to allow the application codesign to access your keychain. Allow it to do this so it can sign the app.
4. Make sure that you didn’t get any errors.
5. Reveal the app in the Finder.
6. Compress the app into a ZIP archive.

Submit Your App

Now that you have everything you need:

1. Log in to iTunes Connect (https://itunesconnect.apple.com/).
2. Click on “Manage Your Applications”.
3. Click on the “Add New Application” button.
4. Follow the onscreen instructions to proceed with the submission process.

If all goes well, you should see your app listed as “In Review”.

While You Wait

Congratulations! You’ve officially submitted your app to the iTunes App Store!

Now what? You’ll probably have to wait a week or two to hear back from Apple. Here are some things you can do in the meantime to keep yourself busy:

• Set up a nice-looking web page for your app that is located at the URL that you submitted to Apple. Be sure to include the following elements:
  • A video of your app in action. Loren Brichter has posted a great tutorial on making beautiful iPhone screen casts at http://blog.atebits.com/2009/03/not-your-average-iphone-screencast/.
  • A brief description of your app. Just a paragraph or two and 5–10 bullet points.
  • An iTunes link to purchase your app.
  • A few testimonials, with a link to more if you have them.
  • A support email address. You could opt to set up a support forum instead, but you’ll learn more about your customers via email.
• Send personal email messages to bloggers who you think would be interested in your app. Target blogs that are relevant to the market for your app, and blogs that are about the iPhone in general.
• Clean out your inbox. You’ll probably get about 5–20 email messages per 100 sales, so if your app is popular, you’re going to be getting a lot of email. Start with a clean slate!
• Start working on your first upgrade. The more popular apps seem to upgrade about twice a month, which causes a steady buzz and lots of customer goodwill.

An app’s success has as much to do with the experience that it delivers as it does the content it contains.

At the end of the day, how users perceive your brand through your app is up to you.  When thinking about creating a mobile app be very clear about what results you desire out of your mobile app.  Do you want to interact with customers? …bring traffic into your stores? …educate people?

“Me Too” Solutions

The following are some ideas for basic apps.  A lot of companies and retails stores have implemented these and seen success.

• FEATURE: Location-based mobile apps.  GOAL: It’s the essential on-the-go tool, so people near you can find you.
• FEATURE: Deals and coupons.  GOAL: Create customer loyalty and keeps your app on their phone.
• FEATURE: News and product releases.  GOAL: Be the trusted source for latest and greatest information.  The Parenting Magazine mobile app has seen a ton of success due solely to its amazing content.  Read more: http://www.mobilemarketer.com/cms/news/content/9839.html

Forward Thinking Mobile App Ideas

CREATE A TOOL.  Create a mobile app that is useful to the general public, regardless of whether it promotes your brand or not.  For example, the Allergycast mobile app, created by Zyrtec, tells you what allergens you might encounter that day depending on your location.  Regardless of whether you use Zyrtec or not, this mobile app is useful.

EDUCATE.  Offer the latest and greatest expert information on your topic of choice.  I was talking to a friend the other day and he mentioned that his career counselor blogs these amazing articles.  He gets something out of it every single time.  As we were chatting he was trying to recall a point in one of the articles.  With that he said to me, “I refer to [the career counselor’s] advice often during conversations throughout the day.  If only he had an app I’d show his articles to more people.”  Can you imagine what that could do for his counselor’s business and his credibility?  Opportunities missed.

MOBILE COMMERCE.  Offer your users the ability to buy via your mobile app.  What good is it to show them a bunch of product but not create an avenue for purchase?  I have seen this mistake being made over and over again.  If you want your customers to leave that app expecting them to purchase on your website (or worse, go to your store) you’ve already lost your customer.  Over and over again I have seen comments like this one:

Don’t let that be you!

CUSTOMIZATION.  People love the feeling of exclusivity.  If you can give it to them, do!  Nike has a mobile app that lets users design and customize their own shoes.  A Marc Jacobs apps lets users create and personalize their own purses.  Who wouldn’t want that?

Recommendations

Go where people are.  Extend your business onto a mobile platform.  Keep your apps lightweight and direct, focusing on the user experience and their take-away.  If you can adopt this mentality, I have no doubt that you’ll have a hit of an app on your hands.

The great thing about Android is also the same thing that annoys developers – the ability to run on multiple devices. When it comes to developing games or apps you need to think of how to incorporate the multiple screen resolutions so that it is compatible across the widest range of devices.

Tackling this problem it was, at first, the most confusing part of Android development. Even with a very thorough article on the development website (Multiple Screen Support), I still found it confusing. Let me walk you through how to setup your manifest and Eclipse workspace to achieve the desired results.

As mentioned in Part 1 of this article series, the way Android classifies different screen sizes are by pixel density. Once you’ve decided what your target hardware is, have a look again at the multiple screen guide.  Make sure to pay attention to the differences between “px,” “dp,” and “sp.”

Now a higher screen density means you can display more information, or pixels, in a smaller space. For example, if you just develop your game or app for a HVGA screen, when you try and run in on a WVGA screen it will appear smaller. In order to correct this you must make 3 different sizes for each PNG image you use.

In your Android Project in Eclipse, under the “res” folder, you will find the “drawable” folder. In order for Android to tell which folder contains the correct density images you will need to use qualifiers. To do this, delete the drawable folder and recreate 3 new ones named “drawable-hdpi”, “drawable-mdpi”, and “drawable-ldpi”. These will contain your different sized images and the naming will tell Android which folder to use depending on which device is running your application.

If you develop your app or game using the HVGA screen size as recommended, to adjust your images you need to increase the image size by 1.5 times to get an HDPI image, and shrink it by 0.75 times to get a LDPI image. An example is the MDPI launcher icon. It is a 48×48 PNG file. Times the resolution by 1.5 to get 72×72, the size needed for a HDPI screen to display the icon at relatively the same size. And to get a LDPI image times the resolution by 0.75 to get 36×36. Once you have converted all of your graphics to the appropriate size, you need to modify the Android Manifest.

To tell Android how to handle multiple screens you need to go to the “Android Manifest” -> “Manifest extras” -> then add the “Support Screens” option. Under the attributes for “Support Screens” you have small screen, normal screens, large screens, resizable and any density. My recommendation is for you to focus on the majority of Android devices.  20 out of 22 Android devices have normal screens.  It is up to you if you want to build for small or large screens.

Resizable basically means fit to screen. So if there is a resolution that is out of the norm for Android, devices like 640×480, then it will stretch the game to fit the screen. Otherwise it will just leave a black border.

If Any Density is false, then Android will only take resources from the “drawable-mdpi” and if the app is being run on a HDPI screen, it will auto convert the PNG up to the correct pixel density. I do not recommend doing this since it is not guaranteed to produce the desired results. Plus you want full control over your app and since we have already designated HDPI, MDPI, and LDPI folders we put Any Density to true meaning we can handling any density ourselves.

These are the setting that I usually use:

Small screens: false

Normal Screens: true

Large Screens: false

Resizable: true

Any Density: true

<supports-screens>

The first step to proactively supporting screen sizes is to add the <supports-screens> element to your AndroidManifest.xml file. This specifies which screen sizes you explicitly support and which you do not.

Here is a manifest containing a <supports-screens> element:

Three of these attributes are almost self- explanatory: android:smallScreens, android:normalScreens, and android:largeScreens. Each take a boolean value indicating whether your application explicitly supports those screens (true) or requires “compatibility mode” assistance (false).

The android:anyDensity attribute indicates whether you are taking density into account in your calculations (true) or not (false). If false, Android will pretend as though all of your dimensions (e.g., 4px) are for a normal-density (160dpi) screen. If your application is running on a screen with lower or higher density, Android will scale your dimensions accordingly. If you indicate that android:anyDensity = “true”, you are telling Android not to do that, putting the onus on you to use density-independent units, such as dip, mm, or in.

Finding Your Size

If you need to take different actions in your Java code based on screen size or density, you have a few options. If there is something distinctive in your resource sets, you can “sniff” on that and branch accordingly in your code. For example, as will be seen in the code sample at the end of this chapter, you can have extra widgets in some layouts (e.g., res/layout-large/main.xml) — simply seeing if an extra widget exists will tell you if you are running a “large” screen or not.

You can also find out your screen size class via a Configuration object, typically obtained by an Activityvia getResources().getConfiguration().

A Configuration object has a public field named screenLayout that is a bitmask indicating the type of screen the application is running on. You can test to see if your screen is small, normal, or large, or if it is “long” or not (where “long” indicates a 16:9 or similar aspect ratio, compared to 4:3). For example, here we test to see if we are running on a large screen:

There appears to be no easy way to find out your screen density. If you absolutely need to know that, a “hack” would be to add a strings.xml file to res/values-ldpi/, res/values-mdpi/, and res/values-hdpi/ directories in your project. Put a string resource in strings.xml that has a common name across all three resource sets and has a distinctive value (e.g., name it ‘density’, with values of ldpi, mdpi, and hdpi, respectively). Then, test the value of the string resource at runtime. This is inelegant but should work.

To test out that this is working, make 3 Android Virtual Devices (AVD’s) and run your app. A WVGA or FWVGA, HVGA and QVGA should be good. I recommend making a specific PNG image in each density a different color, so you can tell if the right folder is being used.

If you read the article by Google linked at the beginning of this article it goes into more detail. Hope this makes sense and it helps you!

Everyone is trying to come up with the next winning mobile marketing strategy, but has anyone hit the jackpot yet?  Companies and businesses seem to come up with new mobile strategies that get scrapped as fast as ice cream melts.  I have heard this over and over again as I meet and talk to people who are struggling with what to do with mobile.  They know they gotta get in the game, but the big question is HOW!

Let’s focus on mobile apps.  Many companies feel compelled to come up with ONE mobile app, which they deem their mobile strategy, that will carry their company for years to come, kind of like their website.  The thought is, “If I’m going to invest $50K into building an app it BETTER last a while and encompass everything my company has to offer.”

Let me ask you a question.  What, do you think, is the life expectancy of the average app?  In this day and age the amount of time an app is useful, usable and desirable is getting shorter and shorter.  In no time at all another app will pop up debunking last week’s BEST APP OF THE DAY!  What are you expectations around the life expectancy of your mobile apps?

Next question.  What, do you think, is the life expectancy of the average app on your phone?  I hazard to guess that some apps, the ones that you use all the time or the ones that add value to your life, live on your phone for quite a some time while the apps that don’t offer value get deleted after one or two uses.  Have you thought about how your mobile apps will fare on someone’s phone?

Think about these questions as you develop your mobile strategy.  The answers to these questions should drive your decisions on what kinds of apps you make, how long you expect these apps to be effective and how much you spend on app creation.

Tune in next week when I talk about what mobile strategies and apps I have seen that work really well.

Unlike iPhones, Android devices do not have the same company developing both the software and hardware. This leads to different combinations of screen sizes, resolutions and DPIs creating quite a challenge when designing and developing for these devices.  While the iPhone 3G/S and iPhone 4 have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio.  Therefore, an image can be created to fit the iPhone 4’s specifications and be nicely scaled down to the iPhone 3G/S.

For some reason, the fragmented manufacturers of Androids do not give us that same luxury.  This leaves businesses with two choices – choose not to develop for Android, and willfully miss out on a quarter of the market, OR push forward and learn.  Sounds like a necessary evil, doesn’t it?  With my help, you will see that it’s not THAT bad.  There is common ground when designing and developing for the extremely versatile world of Android.

Diving into the problem

We can spend all day comparing “Apples to Androids”, but instead let’s jump right into what we’re dealing with here.

Popular Android Devices

Let me start by sharing a list of the most popular Android devices on the market today, with a few of their specifications.

Looking at this list, two things should jump out at you.  First, that Google’s Nexus One is highlighted with an ugly, pale red. This is because this phone has been discontinued.  However, even though it is no longer in production, there is still a hefty number of Nexus One owners out there.  Second, did you notice the inconsistencies between screen sizes and resolutions?  They’re not exactly following a perfect pattern.  Take special note of how our friends at Motorola throw us a curve ball by adding a few extra pixels in their Droid line.  Thanks guys.

Below is a diagram showing the comparison of screen resolutions on Android devices.

Because there are devices with different screen sizes that share the same resolution, we run into different densities (DPI/PPI).  Refer back to the popular device list and compare the HTC Evo and HTC Droid Incredible to see this difference.  The inconsistencies between the two aren’t so large that it’ll ruin the design one way or the other, but it does give you a good idea as to what DPI to choose when you begin designing.  So will the Android Developers Page.

Some of you are probably thinking, “This is old news.  We have been dealing with this issue on desktops and laptops for years.”  True, but the Android Platform gives us a few nifty tools to solve it this time.  Segue!

The Solution

The good news is that application developers can do most of the problem solving.  Not to delve too far into the technical side of things, which I will be covering in Part 2 of this series, the Android Platform provides the ability to use Density Independent Pixels (dip, as opposed to px) to define sizes of elements.  By using these units anything rendered through code will scale dynamically, ensuring a perfect fit no matter which screen is being used.  There are a few more suggestions on units like this.  Curious?  Check them out on the Supporting Multiple Screens documentation on the Android Developer’s page.

But what about pre-rendered assets, like images?  There are a few choices:

Nine-Patch Images

Nine-Patch is a tool that comes with the Android Development kit that allows us to specify which areas of our images are safe to stretch. The easiest way to understand this concept is through examples.  Here is an example of nine-patch in action.

The corners and logo stay intact as the rest of the image is stretched.  An important thing to remember is that you’re not limited to the perfect grid I used in the example; you can be creative with your nine-patching.  Nine patches can be as skewed as necessary to accommodate your design.  To learn more about Nine-Patch images, see the Draw 9-Patch documentation on the Android Developer’s page.

I’m not going to get into tiling images, since the point of this article is to give designers an understanding of things to keep in mind when designing for Android’s multiple screens, not a “How-To” guide.

Even though all of these solutions will work, I strongly discourage rendering images for every possible screen size unless there is no possible way to nine-patch or tile your images.  If you can somehow work around the design limitations of solutions #1 or #3, that would be utopia for developers and the clients who want their app(s) on as many screens as possible.  With that, happy Android App designing!

Over the course of developing Android apps you may encounter various speed bumps.  I certainly ran into my fair share of them.  I painstakingly worked through each and every one of the issues.  I wish someone would have told me about all these ups and downs before I started my Android app development.  I’m going to bequeath the things that I learned while tackling Android app development on to you. If you’re an Android app beginner, here are my top 10 tips for Android app development!

1. Use a Global Theme

Using a theme can save you from having to change styles for every Activity in your app.  Depending on the look and feel you want for your app, you should at least use the built-in Light or Dark themes. Tweak those styles in sub-activities if needed:

<application android:icon=”@drawable/app_icon” android:theme=”@android:style/Theme.Light”  android:label=”WordPress” android:name=”WordPress”>

2. Design Flexible Layouts

Android can run on multiple screen sizes. Make sure to use layout designs that stretch their content to fit the screen. Use “fill_parent” and “wrap_content” in the layout XML where appropriate to adapt the content of your application to the screen size automatically. Here’s an example from WordPress of different screen sizes:

Check out row.xml to see how the content is set up to expand in the comment view row.

3. runOnUiThread() is Your Friend

If you’re running threads in your application and need to display something to the user, you’ll discover that the application won’t actually display anything unless it is called from the main thread. You can use runOnUiThread() to ensure that your code is run in the UI.

4. Use Selectors as View Backgrounds, Not Images

A common mistake, when coming from the web world, is to set the background for buttons and lists with an image file. Since Android has multiple states for views, you should create a custom selector in XML that details what should display when the view is in different states:

xmlns:android=”http://schemas.android.com/apk/res/android”>     <item android:state_selected=”true”         android:drawable=”@drawable/menu_button_bg” />     <item android:state_pressed=”true” android:state_selected=”false”         android:drawable=”@drawable/menu_button_bg” />     <item android:state_selected=”false”         android:drawable=”@android:color/transparent” /> </selector>

5. Handling Device Rotation

If you do nothing in your activity to handle device rotation, Android will default to restarting your activity. This is especially annoying if you are running a ProgressDialog while the application is working on something. You can override onConfigurationChanged() to have your activity stay alive when the device is rotated:

@Override public void onConfigurationChanged(Configuration newConfig) {   //ignore orientation change   super.onConfigurationChanged(newConfig); }

and in your manifest XML:

<activity android:name=”selectCategories” android:configChanges=”orientation|keyboardHidden”></activity>

6. Test on all Compatible Android Versions

Have 5 emulators up at once to test each version the app can run on (currently 1.5, 1.6, 2.0, 2.1 and 2.2).

7. Optimize Your ListViews for Smooth Scrolling

Wrap your ListView rows in a container class for faster loading and scrolling.

StackOverflow has a good example.

8. Use DIP instead of PX

To ensure that your margins and padding appears the same on different screen sizes and resolutions, make sure to use ‘dip’ instead of ‘px’ so that Android adjusts accordingly for the device:

<button id=”@+id/example_button”              android:layout_width=”wrap_content”              android:layout_height=”wrap_content”              android:textSize=”20dip”              android:text=”Use Dips!”/>

9. Android is Already Fragmented

Because Android is so open, device manufacturers have had to change a lot of the Android core. This can cause oddities to occur in your application. For example, take a look at how the app appears on the Motoblur platform:

Agh, those black buttons! Motorola replaces the default Android buttons with black ones to fit their ‘dark’ theme for Motoblur. In order to correct this we have to create our own buttons for the app.

10. Use the Dev Tools Application

Google has created an excellent application that is installed by default in the emulators, but you can also install it on your device. My favorite tool in the app is the ‘Monitor CPU Usage’ option, which will put a few bars at the top of your device that show how much CPU your app is using in real-time! Learn more about the Dev Tools here.

There you go! Android is a great platform to develop for, and I hope this article will help you get started!