App Dev 101

101 www.pcworldme.net/appdev101

APP DEV

Supplement to

App Dev 101 | www.pcworldme.net/appdev101 | 1

2 | www.pcworldme.net/appdev101 | App Dev 101

© Copyright 2011 CPI. All rights reserved. While the publishers have made every effort to ensure the accuracy of all information in this magazine, they will not be held responsible for any errors therein.

Publisher Dominic De Sousa COO Nadeem Hood Editorial Director Dave Reeder dave@cpidubai.com +971 (0) 4 440 9100 Group Editor Magnus Nystedt magnus@cpidubai.com @mnystedt +971 (0) 55 883 2009 ADVERTISING Sales Manager Crystal Nystedt crystal@cpidubai.com @cnystedt +971 (0) 55 2020 227 CIRCULATION Database and Circulation Manager Rajeesh M rajeesh@cpidubai.com +971 (0) 4 440 9147 PRODUCTION AND DESIGN Production Manager James P Tharian james@cpidubai.com +971 (0) 4 440 9146 DIGITAL www.cpilive.net www.cpidubai.com Webmaster Tristan Troy Maagma troy@cpidubai.com Web Designer Erik Briones erik@cpidubai.com Jerus King jerus@cpidubai.com

Published by 1013 Centre Road, New Castle County, Wilmington, Delaware, USA Head Office PO Box 13700 Dubai, UAE Tel: +971 (0) 4 440 9100 Fax: +971 (0) 4 447 2409 Printed by Printwell Printing Press LLC © Copyright 2011 CPI All rights reserved While the publisher have made every effort to ensure the accuracy of all information in this magazine, they will not be held responsible for any errors therein.

Apps-a-plenty

T

here’s no denying how important mobile devices have become in our everyday lives in a very short period of time. Most of us carry smartphones- at least one- and even featurephones are becoming more capable. The lines are blurry between what is what but one thing is pretty clear, that it’s the apps that make a smartphone “smart.”

Apple, I think, realized this before anyone else and of course its iTunes AppStore has been a tremendous success. With an estimated 350,000 available apps and several billion downloads, Cupertino is laughing all the way to the bank. But even though Apple’s iOS platform is so clearly in the lead right now, that doesn’t mean there isn’t room for others.

But the others are facing problems not just in terms of the quantity of apps available; customers being able to purchase apps is also a sore spot. Now that Android Market finally is available on devices in the UAE, we still face the issue of not being able to purchase apps with our local credit cards. That’s something that has to change. RIM’s AppWorld for its Blackberry devices hasn’t officially arrived here yet so that’s not really much of an option either. What saves the RIM platform, however, is that apps can easily be installed in other ways, like a simple download from a web page.

Samsung is of course very active with Android but it’s also playing with its own app store and operating system, Bada.

In all of this, Nokia emerges as a good example of the importance of apps. OVI Store sees five million downloads per day, claims the company, and that is no small change. With operator billing and developer evangelization efforst spreading in the region, Nokia is a company to keep an eye out.

So what platform should you develop for, what kind of app should you develop, and what should you think about when designing and building your masterpiece app? Those are some of the questions we want to offer you some help with in this supplement.

Magnus Nystedt Group Editor

App Dev 101 | www.pcworldme.net/appdev101 | 3

Contents

6........................ 10 steps to a killer mobile app in MENA 9........................ How to make money as a mobile app developer 14...................... Smartphone market grow by 90% in third quarter 15...................... 7 web UI mistakes to avoid for smartphones and tablets 18...................... How to make your website mobile today 24..................... The 7 deadly sins of software (and web) development 28.................. Nokia developer’s guide 50.................. Android 51...................... Who’s in charge of Android development: Google or developers?

53..................... Android resources 54.................. Apple iOS 56..................... Apple’s mobile developer momentum open to challenge 57...................... Five qualities of a great iPhone app 59..................... Apple iOS resources 60.................. Blackberry 62..................... RIM pushes WebWorks for BlackBerry, Playbook development 63..................... RIM: Smartphone app builders must know audience 64..................... BlackBerry app developers must make key choices 65..................... BlackBerry resources 66..................... Tablets expected to clobber PC sales in 2011 67...................... The back page: Standard plug

4 | www.pcworldme.net/appdev101 | App Dev 101

App Dev 101 | www.pcworldme.net/appdev101 | 5

10 STEPS TO A

KILLER

MOBILE APP IN MENA

by David Ashford ONE OF THE MOST SUCCESSFUL APPS OF ALL TIME IS ANGRY BIRDS WHICH COSTS $1 TO DOWNLOAD AND IT HAS RECENTLY INTRODUCED IN-APP PURCHASES AS AN ADDITIONAL REVENUE STREAM.

6 | www.pcworldme.net/appdev101 | App Dev 101

T

he growth in smartphones within MENA and the population size and structure presents a very interesting opportunity.

There is a huge demand for smartphone apps that is not being met. So what does it take to become an app entrepreneur and how do you succeed? Here is my simple 10-step plan.

1. What value will you provide?

The most important thing of all is to consider the basic concept of supply and demand. A common mistake is to build what you want without considering what the users actually want. If you are going to generate revenue from your app then you have to provide value to the user, it’s that simple. It could be a utility app, a reference app, a game app or even a gimmicky app that is just a bit of fun.

2. Keep it simple Building apps is very different from building enterprise software. It is far better to have a clearly defined scope for the first phase which proves your concept while minimizing the risks and costs and put all your other great ideas on a product roadmap for future consideration based on consumer reaction to your app.

Besides, the best apps actually do something simple very well. The secret is to keep the scope simple and clearly defined. In other words do not over-engineer anything.

3. Who are you targeting What kind of user will want your app and get most value from it? This is very important because only then can you consider which is the right platform, the size of the market, the right content and the right way to tell them about your app. For example, users of iOS devices tend to be university educated and aspire to western values so they often prefer content in English language while Nokia has by far the largest market and therefore offers the greatest commercial opportunities.

4. Select your platform Once you’ve considered who will want your app, what phones they have, etc. you also need to consider the suitability of the platform. Is there an effective distribution channel (app store) so that you can actually deliver

your app to your target market and collect revenue? From a purely commercial point of view, both BlackBerry and Android don’t make much sense because the BlackBerry App World and the Android Market are not available throughout MENA. Apple does offer local app stores but consumers cannot make payments in local currency. Nokia not only offers local app stores in every MENA country but it also offers flexible pricing in local currencies as well as plenty of local support when it comes to promoting your app and is also the most likely to offer integration with the carrier (i.e. the possibility to collect revenues without the consumer needing to make payments with a credit or debit card).

5. Consider all revenue streams, pricing, forecast As well as selling your app for a one-off download fee, you could also consider in-app subscriptions, in-app purchases, in-app advertising and sponsorship. The trick is to find the right balance where consumers are happy and which suitable revenues are achieved. You need to do your research to work out the best price; don’t be greedy or you won’t get many downloads. It is possible to add new revenue streams over time - one of the most successful apps of all time is Angry Birds which costs $1 to download and it has recently introduced in-app purchases as an additional revenue stream for its most loyal consumers who want additional functionality. Once you know how you will generate revenue from your app you need to prepare a week-by-week revenue forecast. Challenge yourself in terms of how realistic this is by doing some research and considering what other apps have achieved.

6. Understand the costs and risks While it is a lot of fun and it is possible to achieve commercial success, it’s not easy to make money from apps. You need to properly understand the costs (time, design, development, testing, maintenance, updates, etc.) and the risks (what happens if your target market doesn’t actually want to pay for your app?)

AppsArabia will invest in the best commercial app ideas by covering the up-front cost of development (with payback coming from

App Dev 101 | www.pcworldme.net/appdev101 | 7

1. What value will you provide?

2. Keep it simple 3. Who are you targeting 4. Select your platform 5. Consider all revenue streams, pricing, forecast 6. Understand the costs and risks 7. Choose the right development partner 8. Quality, quality, quality 9. Plan the promotion 10. Launch, learn and evolve revenue generated by the app), thereby taking on all the risk. If your revenue forecast is realistic and sufficient to cover the development costs within three to six months then your app idea is likely to be commercially viable so you should join up at www.appsarabia.com and submit an application for investment.

7. Choose the right development partner You should choose your developer with care - ensure they have suitable design and engineering skills, and that they can manage the project diligently. You have to like them, respect them and trust them. The developer should produce a simple project plan which allows you to monitor progress and test/approve components along the way. AppsArabia selects only the best developers to work with and pays them a fair bit for high quality work; we do not engage with developers on a profit share basis (profit share is only offered to the originator of the idea). You’ll need to brief them well and be comfortable that they understand the brief quickly and clearly. Good quality developers should bring new ideas and make strong recommendations about the technical architecture of the app.

8. Quality, quality, quality A successful app must be intuitive from a user experience (UX) point of view, stunningly beautiful from a design point of view (UI) and rock solid from an engineering point of view.

8 | www.pcworldme.net/appdev101 | App Dev 101

There’s nothing worse than a poorly executed app - users hate it and these apps never make money. AppsArabia is the publisher of all apps that it invests in so we demand exceptional quality.

9. Plan the promotion It’s important to plan how you’ll promote the app well in advance of it being ready to launch.

A basic supporting web site, a simple video “trailer,” media coverage and social media must all be considered. It’s not easy to “go viral” but it helps if your app integrates with social media so that your users can easily tell their Facebook friends or Twitter followers when they’ve downloaded your app or been using it.

10. Launch, learn and evolve Once you’ve officially launched your app, you should monitor the demand for it and how it is used. A good developer will help you to integrate code so that you can monitor these metrics. You should be obsessively learning about what you’ve done right and what you can do better and then evolve your app, perhaps by prioritizing and rolling out some of the ideas on your product roadmap.

David Ashford is the General Manager for Apps Arabia, a part of TwoFour54 in Abu Dhabi. Becoming an app entrepreneur is exciting, fun and can be very rewarding. AppsArabia offers an unprecedented support network and incubator facility. Its aim is to create a high quality app development industry throughout MENA and this will only be sustainable if it helps app entrepreneurs to be commercially successful. Join up for free at www.appsarabia.com and follow @AppsArabia on Twitter.

How to make money as a mobile app developer Billions of apps have been downloaded to iPhones and Androids -- how do you get a piece of the action?

T

o many companies and independent developers -- not just software publishers -- mobile apps represent something even more powerful and important than a brand-new platform to deploy apps on. It’s a new and dynamic source of revenue, one with a lot of room to grow. And given how tough it can be to make money selling software at all, especially in this world of open-source and free Web apps, any proven way to make money in that field can become a magnet.

Just like there’s more than one way to deliver software in general, there’s more than one way to monetize mobile applications. The various strategies aren’t conflicting, but complementary. Each app can use the business model -- or models -- best suited to it.

The line at the register With mobile apps, the purchasing process varies wildly, depending on which operating system you’re dealing with. On the iPhone, everything’s done through one interface: the App Store in iTunes. Windows Phone 7 supports direct payment via credit cards and third-party billing of the customer’s service provider. Purchasing through a service provider is convenient, but I imagine people might still opt for credit cards to avoid the possibility of spurious charges on their phone bills.

But with Android, the dreaded “F” word -- fragmentation -- comes into the picture.

The main way to pay for apps through the Android Market is via Google Checkout, widely criticized for its bad end-user experiences.

You can also pay the app merchant directly and there are a number of other merchant

App Dev 101 | www.pcworldme.net/appdev101 | 9

mechanisms ... all different.

(PayPal has also recently been added to the mix.)

What’s most lacking in Android right now is a single, consistent interface for payments. The most seamless solution would be an API that allows app purchases to be added to the carrier’s bill (with user consent, of course), which would make the process of purchasing an application all but frictionless.

This hasn’t happened yet, but Patrick Mork, vice president of marketing for GetJar, a cross-platform mobile app store, claims that it is “right around the corner” and that Google has made no secret of its negotiations with the various carriers to make this possible. Integration with PayPal is also a step in the right direction, even if not everyone uses it.

Less clear is whether such a sea change will require a new version of Android -- meaning those stuck on older handsets that aren’t being updated to newer editions of the OS would be left behind. Because Apple and Microsoft both have ecosystems where the purchasing system is already pretty seamless, Android runs the risk of falling behind unless the vast majority of its existing installed base can be brought up to speed when new merchant mechanisms arrive. And because of the way Android is delivered to the end user -- by the handset maker rather than by Google alone, and with any number of gratuitous changes -- a good chunk of the existing generation of Android phones might remain stuck on the old-school merchant systems.

The need to make app purchasing as convenient as possible will only become more important over time, to both the people buying and selling them. Smartphones have become increasingly prevalent among consumers as

10 | www.pcworldme.net/appdev101 | App Dev 101

well as business people; many new users have no experience with buying an app and don’t want the experience to be more complex than a click or two. “Many apps are currently purchased on an impulse,” says Ric Ferraro, founder of mobile start-up GeoMe. “People crave apps in the same way [as candy bars], and the longer it takes to buy the app, the less likely it is that the purchase will be completed.”

Mork puts it another way: “The best purchasing experience is probably the one where you never have to leave the app.”

Standing out from the crowd Along with ease of purchase, discoverability -- how easily you can find a given app and pick it out from its competition -- will also become increasingly important. I’ve read more than a few comments to the effect that one drawback of the Android app stores is a proliferation of me-too apps that duplicate functionality to the point of redundancy.

From this comes the argument that an app store with a more carefully curated selection of products is more genuinely useful -- like the iTunes app store, for instance. But it’s also possible to make an argument that the size of the store is not as important as the interface used to query it. Few people complain about the size of Amazon.com’s catalog, in part because it’s relatively easy to drill down and narrow the scope of a search.

Another possible solution would be a universal

app catalog -- “a single store or a single set of standards which can be accessed independent of the type of mobile device or OS it is running,” as Ferraro describes it. “Some initiatives are being set up to attempt this -- for example, the Wholesale Applications Community initiative sponsored by the GSM Association could go a long way in setting unified standards and creating a single platform.”

That wouldn’t make things much easier for developers, who would still have to produce and test variations of a given app for different platforms -- but the app market is driven by consumers and not developers alone, and where the consumers go, the developers inevitably must follow.

The cost of selling One other major factor that comes into play when selling an app is the cost of making the app available in the first place. Apple’s iTunes store splits revenue 70-30, with Apple getting the 30 percent. Windows Phone 7’s app store has a similar 70-30 split, but a portion of Microsoft’s 30 percent is distributed back to the network operators. Both also have application requirements and yearly membership fees -- $99 for Microsoft, and from $99 to $299 for Apple, depending on whether you get the Standard or Enterprise iPhone software development kit.

The Android Market also features a 70-30 revenue split, but the 30 percent is distributed between the payment processor and the carrier. The registration fee for developers is also only $25, but an unlocked developer phone, either the Android Dev Phone or the Google Nexus One, can cost upwards of $500. These phones are not required, but they provide some major power-developer features: They can work with any GSM network, and the Android Dev phone also lets you install any custom Android system image.

Alternative places to obtain apps are also starting to become available. For example, Verizon is planning to open its Android V Cast apps store sometime in November, for which it will be offering a 70-30 revenue split. GetJar, an independent site, takes a varying fee for each app download, using a bidding system that starts at one cent per download.

“The best purchasing experience is probably the one where you never have to leave the app.”

Making a living at apps All that being said, there are a number of different strategies that developers are using to earn money with their apps -- most outside the traditional pay-for-product model.

The freemium model. The first and most basic approach to monetizing a mobile app is to just sell the application itself. But even a method this elementary is fraught with complexities.

After all, how much will people be willing to pay for a given mobile app? Set the price too low and you can’t cover development costs; set it too high and nobody will touch it.

One quick way to resolve that problem is to adopt an approach that’s been used in the PC world for decades: Give away a minimally functional version of the application -- sometimes ad-supported, sometimes just outfitted with nag boxes -- and encourage the user to buy the full version. The missing feature or features don’t have to be significant but should be worth paying for. Another way to put this would be: Give away the app, sell the functionality.

The word freemium has been coined to describe this approach, and it has quickly become an essential means of bringing a mobile app to market. Ferraro described the freemium model in his blog as “a classic marketing tool available to mobile app developers to maintain the perception of a free service, while attempting to lock-in customers into some type of charging mechanism.”

The key word here is “perception”: As long as people feel as if they’re getting something for free, they don’t mind as much if they have to pay down the line -- even if they have to pay again and again. What matters is the sense that they’re getting something for their investment.

Online games have developed this to the level

App Dev 101 | www.pcworldme.net/appdev101 | 11

of an art form. As subscription-based games lose favor and “freemium” gaming comes to the fore, the game makers have come up with any number of ways to scare up revenue that don’t depend on selling the game itself.

Ferraro concurred on this point in an e-mail interview: “App publishers can monetize free by capitalizing on the audience they obtained, and promoting upgrades. This is particularly visible in mobile games, where more advanced gaming levels are only available at a premium.”

That said, reluctance on the part of app makers has been one obstacle to use of the freemium model. “Publishers of well-known brands didn’t want to be perceived as giving

Ad-supported apps come with all the controversies associated with using advertising as a revenue model, plus a few new ones. things away or devaluing the brand,” says GetJar’s Mork. “But this has changed in the past couple of years.” Electronic Arts, for instance, has been moving toward a freemium model for its online games -- something enhanced all the more by its purchase of game publisher Chillingo, creator of the hit game Angry Birds.

Chillingo’s game-development SDK includes technology to easily create freemium applications, something useful to any company that wants to push out such applications across 12 | www.pcworldme.net/appdev101 | App Dev 101

multiple mobile platforms.

Microsoft sensed, quite correctly, the need for developers to create freemium apps. The Windows Phone 7 SDK has direct provisions for this. The free and full versions of an app created with the SDK can be the same binary; all that’s needed is an unlock code. No new download is required. This takes the work out of building a separate trial version -- and gives app developers that many fewer excuses not to offer both options.

The service-and-subscription model. A major business model for mobile apps is to sell access to a service and give away an application that’s just a convenient front-end for that service. The biggest question is: What service is worth paying for?

It’s not just a question of the service being useful. It’s about the integrity of the data provided by that service as well. Consider Zagat, the venerable dining and entertainment guide, which has a subscription version of its review service accessible through its mobile apps for $24.95 a year. Zagat’s main competition is from crowd-sourced services like Yelp, but Zagat’s business model is based on the idea that its information has such a known pedigree, it’s worth paying for. Yelp’s database may be contributed to by a broader range of people, but it’s arguably much messier and more inconsistent.

Another method for selling data involves creating applications that offer a repository of locally stored data. For example, let’s say you worked for a company that is known for publishing foreign-language dictionaries, and you wanted to sell mobile versions of its books. You could give away the app itself, with a minimal version of the dictionary data thrown in on top of that (say, 2,000 words), then sell the full-blown version of the diction-

ary, either all at once or in a regularly updated, periodic-subscription version. This wouldn’t stop amateur competitors from creating their own apps and data sets, but a free dictionary that’s not very accurate would have less appeal to a serious language student than a modestly priced one that has a brand-name pedigree behind it.

The ad-funded model. A third way to generate revenue from mobile apps is a method ported directly over from the Web at large: advertising. But be aware: Ad-supported apps come with all the controversies associated with using advertising as a revenue model, plus a few new ones.

Ad-supported apps can serve as a way to hook people into buying a full version of a program without the ads. For example, the MixZing Music Player for Android has a free, ad-supported version; pay $6.99 for the full version, and you not only remove the ads (which are at least unobtrusive), but unlock a slew of extra features, like an MP3 tag editor.

The problem with ads in a mobile application is -- for lack of a better word -- acreage. On an ad-supported Web page, ads can run in banner or skyscraper elements confined to the edges of the page and don’t have to be as intrusive.

With a mobile app, the small screen means any ad is going to eat into the UI, and a badly integrated ad will turn people off. Ads placed too near controls, for instance, may mistakenly intercept button-press actions.

Another small drawback to advertising in mobile apps: The ad system is all but useless if the user doesn’t have an active data connection.

This will become less of an obstacle as more mobile devices are sold with some form of data plan included and as municipal Wi-Fi becomes more pervasive. (Also, an ad can still be effective, even if it clicking on it doesn’t work due to a lack of networking. As long as it raises some awareness in the mind of the viewer, it’s still doing its job.)

Another method of monetizing through advertising is using revenue generated through a search engine. This has been Mozilla’s model with Firefox and could just as easily be applied to mobile apps as well. Whenever a user executes a Web search via Firefox’s native

search box, a certain percentage of ad revenue generated from the search goes back to Mozilla through an affiliate program.

The downside to this approach is that it lends itself only to applications that have some search component -- such as a mobile browser -- which make up a very small segment of the existing app mix. That said, it’s entirely possible that creative methods of integrating search with mobile apps will make search-engine revenue that much more viable a choice.

Conclusions Because the current incarnation of the mobile apps market is still so new and only just now experiencing a flowering of cross-platform competition and innovation, the ways apps can be monetized and sold are likely to enjoy as much of a period of experimentation as the apps themselves.

What’s clearest is that the processes of selling and monetizing apps have to be as convenient as possible, for customers and developers alike. “To reach as wide an audience as possible, you have to be able to go crossplatform,” says Mork. “You need some sort of business model where you can reach different audiences depending on whether or not they have data plans or smartphones.” This goes double for apps that spread virally, by wordof-mouth or by direct exposure: If your friend has it on his iPhone, you’re going to want it on your Android as well.

To that end, those who can make the monetization process as seamless as possible are set to reap rewards of their own -- along with those who write apps that are worth monetizing, of course.

App Dev 101 | www.pcworldme.net/appdev101 | 13

Smartphone market grow by 90% in third quarter

T

he global smartphone market grew nearly 90% in the third quarter, with enormous gains by Samsung and HTC, market research firm IDC reported Thursday.

Vendors shipped 81 million smartphones, up 89.5% from the 42.8 million units shipped in the third quarter of 2009. For the first three quarters, vendors shipped 200.6 million smartphones, an increase of 67% over the 119.6 million shipped for the first three quarters in 2009.

Smartphone growth outpaces growth in overall mobile phones by six times, as customers

14 | www.pcworldme.net/appdev101 | App Dev 101

seek browsing and multimedia functions on their mobile devices and as carriers expand the range of smartphone brands, IDC said.

“Smartphone makers have the wind behind their sales,” said Kevin Restivo, an IDC analyst.

He said the transition to smartphones appears unabated.

Nokia still leads the pack, with a 32.7% share of the market and 26.5 million smartphones shipped in the third quarter. Even with 61.6% year-over-year growth, Nokia’s market share is shrinking amid new competition. Nokia launched the C7 and its first Symbian 3 device, the N8, and has plans for a device using the MeeGo operating system in 2011.

Apple ‘s iPhone boosted its rank to second place, with a 17.4% market share and 14.1 million phones shipped, a 90% increase from the prior year. A well-publicized problem with the iPhone 4 antenna didn’t dampen demand, since the company swiftly fixed the problem , IDC said.

BlackBerry maker Research in Motion was third, with a 15.3% share and 12.4 million smartphones shipped, an increase of 45.9%.

The number of shipments reached a record high, but RIM still fell from second place amid the competition. Most notably, RIM released a BlackBerry 6.0 operating system on the BlackBerry Torch 9800 with both a touchscreen and a physical keyboard.

Samsung came in fourth but posted the highest growth compared with a year ago of 453.8% with 7.2 million smartphones shipped.

It launched the Galaxy S smartphone line , running Android , and will be one of he first to release a Windows Phone 7 device.

HTC was in fifth place with 176% growth and 5.8 million units shipped. It also sells Android smartphones globally and plans to ship five different WP7 phones this quarter.

Android-based phones outsold iPhones in the U.S. by nearly 2 to 1 in the third quarter, NPD Group reported earlier this week.

7 Web UI mistakes to avoid for smartphones and tablets Your website might be gorgeous, but is it really cross-platform?

Don’t be so sure

C

lients say the darnedest things. The other day, one scoffed, “Anyone who’s looking at our website on a stupid little phone screen probably isn’t our customer anyway.”

I was taken aback. “Really?” I replied. “What if they’re at a business lunch and they want to show their boss the specs of one of your products?” A pause. “What if they’re just trying to find your phone number?”

Too often, clients underestimate how rapidly smartphones, tablets, and other mobile devices are changing the way customers access the Web. Worse, few Web developers seem willing

to educate their clients about these modern realities. Graphic designers still see their Apple Cinema Display monitors as canvases and paint their sites accordingly, disregarding the fact that the end product will often be viewed on considerably smaller screens. And coders implement those designs blindly, even when they, of all people, should understand the intricacies and limitations of HTML and CSS. As an outcome, too many websites still exhibit commonplace UI mistakes that effectively cripple them for users of smartphones and tablets. Here are just a few examples:

App Dev 101 | www.pcworldme.net/appdev101 | 15

Web UI mistake 1: Using rollovers Somewhere along the way, Web developers fell in love with the idea of highlighting controls and popping up content when the user mouses over some part of the screen. The problem for smartphones and tablets should be obvious: When there’s no mouse cursor, there’s no way to mouse over controls.

That doesn’t mean you should do away with rollover effects altogether. But for every hover event, there should be an equivalent click event that does essentially the same thing for users with touchscreens. Smartphone users shouldn’t be penalized with a page refresh for every level of navigation because you designed your menus for use with only a mouse.

Web UI mistake 2: Using custom widgets and controls Designers love to lend a unique look and feel to their buttons and other widgets. But UI standards differ from platform to platform, and when controls aren’t readily identifiable and accessible on every device, usability suffers.

Custom scrollbars are a particularly egregious example. Occasionally designers will want to override the default controls with JavaScript, replacing them with sleek, skinny, and more visually appealing widgets. The problem for tablet users is twofold: Not only are tiny widgets harder to hit with your finger, but tablet users don’t scroll using scrollbars anyway; they swipe the screen. Forcing them to use custom controls only hobbles your UI. Similarly, don’t take any input devices for granted. Pop-up dialog boxes, for example, should always have visually identifiable close controls. Smartphones and tablets might technically have keyboards, but they seldom have Esc keys.

Web UI mistake 3: Having too many scrollable areas Viewing websites on a small touchscreen often means scrolling around to see the whole page. As I mentioned before, however, remember that tablet users scroll by swiping

16 | www.pcworldme.net/appdev101 | App Dev 101

the screen, not by activating controls. When you divide the page into multiple panes, each of which contains scrollable content, your UI can quickly become an interactivity minefield.

One part of the content might scroll with one swipe and another part might scroll with the next, depending on where the user’s finger lands on the screen. Best to keep the layout as simple as possible, or at the very least, make sure there are good-sized margins to allow the user to choose whether to scroll one pane or the whole page.

Web UI mistake 4: Having an inflexible text layout I can’t tell you how many graphic designers have explained their website layouts to me in terms of precise pixel measurements and the rules of Swiss typography. While this has never been good practice for the Web -where users can adjust the browser window and even font sizes at will -- it’s an especially bad idea if you want your site to be viewable on smartphones.

The Android browser, for example, defaults to a mode where it will attempt to compress the width of a column of text to fit the width of the device’s screen, regardless of the page’s CSS specifications. If you fail to take that into account and expect all the design elements to line up exactly the way they do on a desktop browser, you can end up leaving smartphone users with big areas of whitespace that can effectively hide controls and obscure the UI.

Web UI mistake 5: Making assumptions about screen format One Web designer gloated to me that he likes to stay on the forefront of technology, which is why he designs his sites to look best on modern, widescreen LCDs. But even if you disregard folks who have older monitors, you can’t stay on the forefront of technology if you ignore mobile device users.

Most smartphones can automatically pivot between portrait (vertical) and landscape (horizontal) modes, depending on how the user is holding the device. What’s more, some

users hate the autopivot function and disable it -- in which case, you’d better hope they picked the same mode your site is designed for. Making assumptions about the page format works fine in the print world, but it’s a lousy idea on the Web, where you don’t know the size of the paper.

Web UI mistake 6: Preloading too many images Pity the poor smartphone users: Not only is their Internet access not as fast as terrestrial connectivity, but increasingly cellular carriers are putting caps on data usage and imposing overage fees. Smartphones might have limited RAM, too. While it might make sense to use JavaScript to preload a sequence of slideshow images for desktop browsers, it’s a little rude to users of mobile devices, even more so if the images are designed to appear when the user mouses over a certain control -- which, of course, tablet users can’t do anyway.

Web UI mistake 7: Using Flash I hate to say it, but Adobe Flash still has no place on mobile devices. Famously, Apple’s iOS devices don’t support Flash content at all, but even those Android handsets that do support Flash offer only lackluster performance.

Worse, Flash applications exhibit the UI issues I’ve outlined above even more frequently than ordinary HTML sites. Sorry, Adobe fans: With the advent of HTML5, the days of Flash on the Web are numbered.

Of course, there are other ways around these UI problems. You could build a separate, custom version of your site specifically for mobile devices. You could even build a custom app.

But these alternatives have their problems: They’re too device-specific, and they’re hardly future-proof. Don’t discount the power of HTML for building truly cross-platform, crossdevice online applications. Just be sure you know what you’re doing.

App Dev 101 | www.pcworldme.net/appdev101 | 17

How to make your website mobile today You’ve long held off, but it’s now time -- even past time: You need to make your website mobile. Between what you see in the news and what your site logs reveal, it’s clear that the number of people surfing the Web from their mobile devices is growing by the day.

Here are a few tips to help your site (and you) get up to speed in this new mobile world.

18 | www.pcworldme.net/appdev101 | App Dev 101

A

ddressing the device proliferation challenge If you start off by panicking about all the cell phones you (and your family and your friends and your coworkers) have had over the years, and then ask yourself how you’re going to support all those mobile OSes and models, rest easy.

The truth is that while mobile browsing is growing by the minute, virtually all that growth is from just a few devices -- mainly those running Apple’s iOS (iPhone, iPod Touch, and iPad) and Google’s Android (used by HTC, Motorola, Samsung, and others in a bunch of models).

Here’s the proof: Quantcast’s August data showed iPhone and iPod Touch together claim 56 percent, Android devices 23 percent, and RIM BlackBerrys 10 percent. AdMob, which focuses on sites with ads, found similar results in its May survey [PDF]: iPhones accounted for 54 percent of usage (it doesn’t track iPod Touches or iPads), Android devices for 33 per-

cent, and BlackBerrys for just 7 percent.

The good news: The popular Apple and Android devices’ browsers run on WebKit, the open source rendering engine, as do the less-popular WebOS-based Palm Pre and Pixi and the new RIM BlackBerry Torch.

The bad news: These devices come in all sorts of screen dimensions. The really bad news: Although all of these browsers run on WebKit, all of them run WebKit just a little differently. Peter-Paul Koch of QuirksMode ran 19 WebKit-based browsers through 27 tests and described the results as “thinly veiled chaos.”

So let’s try to bring some order to that chaos, first by being a little picky, and then by using a touch of HTML, CSS, and JavaScript to handle the remaining issues.

Yes, there are a lot of devices, but you don’t have to support them all. Do so by eliminating the outliers: * Sorry, RIM. Sorry, Microsoft. You had your day in the mobile market (well, RIM did; App Dev 101 | www.pcworldme.net/appdev101 | 19

Microsoft never did quite figure out a solution to Windows + mobile device + usable), but it’s over. There may still be plenty of these devices, but research has shown that they aren’t used to surf [PDF]. * Sorry, small screens. Unfortunately, a 240by-320 surface is just too small for a good browsing experience. The Pixi’s 320-by-400 screen is almost twice as large, yet barely made the cut. * Sorry, third parties. Every device you should care about ships with its own Web browser.

If you have an Android, you have a choice of browsers, including Opera Mini and Mobile Firefox. But you have to draw the line somewhere, and unless you have a fully funded lab, it’s unlikely you’ll be able to test your site on every permutation of browser and screen size. So stick with the browser that the device maker included.

Anything else you’re thinking about dropping? This is where your server logs come in handy. Keep in mind, though, that while you may have few mobile visitors now, it might be solely because they don’t (yet!) find your site welcoming.

20 | www.pcworldme.net/appdev101 | App Dev 101

The nitty-gritty of making your site over Let’s say you have a fairly normal website: It has content, a menu bar, a header, and footer.

You know it’s built to standards, so you assume it’s going to work just fine without any changes. And then you look at it on an iPhone 3G S or a Nexus One. And you remember you thought that navigation bar was so snazzy when you got it working, but now realize mobile devices don’t support hover effects. And you start trying to figure out which would be easier: redesigning the entire site or creating a duplicate mobile version?

Thankfully, those aren’t the only two options.

I’ll take this site (you can see the live version on your mobile or desktop browser) and show you how to add a little more markup, style, and code. Then we’ll be done -- no redesign or duplication needed.

The viewport. You start off with the viewport --a concept invented by the W3C, but one that garnered little attention until the iPhone came along. In the chart on the first page in this article, you’ll notice that before the iPad and iPhone 4, Apple’s devices were all 320 pixels wide. However, on those devices, Mobile

Safari thought that it had a width of 960 pixels. That meant that internally, your site was compressed to a third the width, and then put out on the screen. Want to change that equation? That’s the viewport. <meta name = “viewport” content = “width = device-width” />

That line goes into the head section of your HTML and tells mobile browsers that you may think your width is 960, but I think you should be satisfied with 320 pixels across -- or whatever the device-width happens to be.

At least that’s the way Apple described how it should work; in practice, I’ve had better luck giving the viewport a fixed width: <meta name = “viewport” content = “width = 560” />

This is one of those gray areas where there’s no one right answer that fits all sites on all devices; you need to play with it to find what width works best for your site.

Media queries. Next up is a little bit of custom CSS geared toward the mobile crowd. <link rel=”stylesheet” href=”mobile.css” type=”text/css” media=”only screen and (max-device-width:1024px)” />

The first part of the link tag looks like a straightforward style sheet, up until the end.

The media attribute is how you can identify not just mobile browsers in general, but which mobile browsers in particular. The only screen keywords are the voodoo that tells mobile browsers that this is just for them. After that, you can get picky about which browsers, but here you’re looking for all mobile devices that have a maximum device width of 1,024 pixels -- that is, everything up to and including an iPad. Because of this line, every mobile device will load mobile.css.

Now, you can get a little more particular: <link rel=”stylesheet” href=”mobile2.css” type=”text/css” media=”only screen and (-webkit-min-device-pixel-ratio:2)” />

dia query, but then looks at the minimum pixel ratio of the device. If it isn’t 2 or higher, you aren’t interested. Right now, the only browser fitting that description is the iPhone 4 with its Retina display. This line lets you tweak details a little for Apple’s latest toy, which gets to use mobile2.css.

For the next line, it helps to remember that these devices can be in horizontal or vertical orientation when your page loads. You can’t just say you want all devices that are at least 480 pixels across; if the device is in landscape orientation, you may get a false positive. <link rel=”stylesheet” href=”mobile2.css” type=”text/css” media=”only screen and (min-device-width:768px) and (min-deviceheight:768px)” />

This line brings in the same style sheet, but for different device: one with both a minimum height and minimum width of at least 768 pixels. That’s the iPad, and it’s going to get the same special style sheet as the iPhone 4.

Style your site. To understand what’s going on in mobile.css, you first have to know a little about how the site is put together. The middle section, #container, is only 80 percent of the page. And while it looks nice on a big display to have all that room on the sides, it’s a waste of space on a mobile device. So start off by making the content fill the entire width: #container { width: 100%; }

Something you may have noticed while looking at sites with one of your own devices: Bold fonts aren’t attractive. They take up too much room and don’t display well. Let’s stop that for the site’s normally bold navigation: #navbar { font-weight: normal; }

Next up, it’s time to tweak your fonts. Each device comes with certain fonts, and I wasn’t able to find any one font on all devices (but then, you can’t even necessarily find out what Web fonts ship with a given device -- I’m looking at you, Android). But here’s what’s worked for me:

This starts off similar to the earlier broad meApp Dev 101 | www.pcworldme.net/appdev101 | 21

h1, h2, h3, h4, h5, h6 { font-family: Albany, Georgia, “Times New Roman”, “Droid Serif”, serif; }

Albany is a serif font found on the Palm devices, Droid Serif on all Android devices, and Georgia and Times New Roman are on the iPhone and iPad. If you’re supporting BlackBerry as well, add “BB Alpha Serif”.

If you prefer sans serif fonts, try: h1, h2, h3, h4, h5, h6 { font-family: Prelude, Verdana, Arial, “Droid Sans”, sans-serif; }

Prelude is a sans serif font found on the Palm devices, Droid Sans on all Android devices, and Verdana and Arial are on the iPhone and iPad. If you’re supporting BlackBerry as well, add “BB Alpha Sans”.

If you’ve used one of the higher-end mobile browsers and swapped orientation, you may have found it, well, a little disorienting.

You’re looking at a page where the fonts are a certain size, but then you go from portrait to landscape and the font size suddenly makes you feel like you’re in a funhouse. So let’s add a little styling to handle that: .landscape { font-size: .5em; } .portrait { font-size: .8em; }

I’ll show you the JavaScript later that provides

22 | www.pcworldme.net/appdev101 | App Dev 101

the functionality behind this, but suffice it to say for now that when the page has its class attribute set to landscape, your fonts are at half-size; when it’s in portrait orientation, the fonts are at 80 percent.

The lucky iPhone 4 and iPad have some special styles of their own: .portrait #header img { width: 50em; } .landscape #header img { width: 75em; }

The header graphic is larger than will fit properly in most mobile browsers. The others will cut it off, and that’s fine.

A little bit of script. My sample page is already using an external JavaScript file to handle its navigation menu, so only a little more code is necessary: addEventListener( ‘load’, function() { resetPage(); androidSS(); }, false ); addEventListener( ‘orientationchange’, function() { resetPage(); }, false );

These lines set up two event handlers: one to trigger when the page loads, and the other to trigger on orientationchange -- which is just what it sounds like. Both of them call the resetPage function:

function resetPage() { var classVal = (Math.abs(window.orientation)==90) ? “landscape” : “portrait”; document.getElementById(“container”). setAttribute(“class”, classVal); setTimeout(scrollTo, 0, 0, 1); }

This function only has three lines, but it accomplishes a lot. The first line checks the window orientation; if it’s +90 or --90, it sets classVal to landscape; otherwise, classVal is set to portrait. The second line tells container that it has a new class attribute, classVal. The two together are what let you know if the device is horizontal or vertical. The last line does a little bit of useful trickery, much of the screen real estate is taken up by the address bar. Here, this last line tells the browser to window to scroll a tiny amount, which is enough to move the address bar out of the way.

That darn Droid. Did you notice the one bit of code I skipped in the onload handler? It was the call to the function androidSS: function androidSS() { if (navigator.userAgent.match(/Android/i)) { var fileref = document. createElement(“link”); fileref.setAttribute(“rel”,”stylesheet”); fileref.setAttribute(“type”,”text/css”); fileref.setAttribute(“href”,”mobile3.css”); document.getElementsByTagName(“head”)[0]. appendChild(fileref); } }

It looks to see if the browser is an Android device by checking if its userAgent contains the string Android. If it does, this function appends another style sheet, mobile3.css. There’s no way to reliably use media queries to target all (and only) Android devices; instead, you should use JavaScript.

The result: Appropriate -- not identical -- displays across devices. While testing devices, I found a number of websites that documented how the Android should handle various situations. I tested sites with the Android emulator in addition to, of course, using an actual Android smartphone. I found that only on rare

occasions did the docs match either of the displays, and that was still considerably more common than the emulator matching the phone’s output. To get somewhat dependable results, I ended up duplicating several of the styles from mobile.css. Here’s what’s different: h1, h2, h3, h4, h5, h6 { font-family: “Droid Serif”, Georgia, “Times New Roman”, serif; } .landscape { font-size: 16px; } .portrait { font-size: 24px; }

The heading tags are set to fonts supported by the Android, as there’s no need for iOS, WebOS, or BlackBerry support here. I also set the fonts for landscape and portrait to fixed pixel sizes to improve the chances of getting the desired results.

Don’t get me wrong: The Palm and Apple devices had their share of fun quirks as well.

Happily, there are free emulators for them, which you can get from the Palm Developer Center and Apple’s iPhone Developer Program, respectively.

The end results aren’t identical; with screen sizes that vary as much as these devices do, they shouldn’t be. But they’re all clear and readable, and that’s what matters when you’re on the move.

With some simple Web technologies, it’s not difficult to make your site feel friendly to even the smallest among us. Hopefully, you’ve seen that you can get a start without a whole lot of effort.

After you’ve become comfortable with these techniques, you can take the next step and work with the user agent detection method I described for Android. From there, you can detect other devices and load specific style sheets for each to invoke more layout-oriented CSS functions. For example, you may end up showing and hiding divs, placing divs in different locations, or actually changing the layout of a Web page based on the mobile device accessing it -- but that’s for another day.

App Dev 101 | www.pcworldme.net/appdev101 | 23

7 The

deadly sins of and b e w software development Recognize the worst traits of programmers everywhere and save yourself from developer hell

B

eing a good developer takes a lifetime of training and practice. But without proper discipline, even the best programmers risk falling prey to their worse natures. Some bad habits are so insidious that they crop up again and again, even among the most experienced developers. I speak of nothing less than the seven deadly sins of software development. Read on to hear how lust, gluttony, greed, sloth, wrath, envy, and pride may be undermining your latest programming project as we speak.

24 | www.pcworldme.net/appdev101 | App Dev 101

First deadly sin of software development: Lust (overengineering) Modern programming languages tend to add features as they mature. They pile on layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability -- provided you take the time to learn how to use them properly.

At the same time, the discipline of programming has changed over the years. Today you

have giant tomes of design patterns to pore over, and every few months someone comes up with a new development methodology that they swear will transform you into a god among programmers.

But what looks good on paper doesn’t always work in practice, and just because you can do something doesn’t mean you should. As programming guru Joel Spolsky puts it, “Shipping is a feature. A really important feature. Your product must have it.” Programmers who fetishize their tools inevitably lose sight of this, and even the seemingly simplest of projects can end up mired in development hell. Resist your baser impulses and stick to what works.

Second deadly sin of software development: Gluttony (failing to refactor)

planning the next iteration. What new features should it have? What didn’t we have time to implement the first go-round?

It’s easy to forget that code seldom leaves the door in perfect shape. Then, as features accumulate with successive rounds of development, programmers tend to compound mistakes of the past, resulting in a bloated, fragile code base that’s too tangled to maintain effectively.

Instead of gobbling up plate after plate of new features, restrain yourself. Evaluate your existing code for quality and maintainability.

Make code refactoring a line item on your budget for each new round of development.

Clients may see only the new features in each release, but over the long term, they’ll thank you for keeping off the fat.

Nothing is more gratifying than shipping software. Once you have a working product out in the wild, the temptation is strong to begin App Dev 101 | www.pcworldme.net/appdev101 | 25

Third deadly sin of software development: Greed (competing across teams) The excessive desire for wealth and power -how else to explain the motives of programmers who compete with their own coworkers?

It starts when other teams are left off email lists, then proceeds to closed-door meetings.

Next thing you know, one team has written a library that reimplements more than half of the functionality already coded by another team.

Programming teams seldom reinvent the wheel out of malice, but lacking clearly defined objectives, they can easily latch onto responsibilities much broader than are strictly necessary. The result is a redundant, unmanageable code base, to say nothing of the budget lost to duplicated efforts. One of the top priorities of managing a development project should be to make sure each hand knows what the other is doing, and that all the teams are working toward a common goal. Share and share alike should be your motto.

Fourth deadly sin of software development: Sloth (not validating inputs) The list of basic programming mistakes is long, but the sin of failing to validate input is so pernicious that it bears special consideration.

Why this seemingly amateur error still crops up in code written by experienced programmers is baffling. And yet, many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it for correct formatting.

Modern programming languages provide many tools to help coders keep this from happening, but they have to be used properly. Remember, a Web form that uses JavaScript to validate its inputs can be easily sidestepped by disabling JavaScript in the browser or not using a browser to access it at all. Input validation should be baked into the core of your application, not sprinkled onto the UI. Anything less is simple laziness.

26 | www.pcworldme.net/appdev101 | App Dev 101

Fifth deadly sin of software development: Wrath (not commenting code) What act could be more hostile to your fellow programmers than failing to comment your code? I know, I know: Well-written code is its own best documentation. Well, guess what?

Those methods you wrote at two in the morning last Thursday weren’t exactly well-written code. (And if you’re a Perl hacker, you owe me nine Hail Marys.)

It’s easy for programmers to forget that the code they write today may live on long after they’ve left the job. To the programmers who replace them falls the unenviable task of figuring out what each snippet of code actually means. So have mercy, and leave them a few hints.

But remember, unintelligible comments or commenting too much can be as bad as not commenting at all. Comments like “this is

broken” or “don’t touch this ever” aren’t much help to anybody. Neither are redundant comments explaining simple operations, such as variable initializations. Code is its own best documentation of what it does; comments should be there to explain the why.

Sixth deadly sin of software development: Envy (not using version control) It’s hard to believe there are still software projects in 2011 that exist as a directory tree on a file server, jealously guarded by one “master maintainer.” Scattered around the office are duplicates of this tree on individual developers’ workstations, each slightly different -though no one knows exactly how.

Maybe you have reasons for not implementing version control on your projects. Maybe

it started small and just got out of hand. But powerful, effective version control systemsare readily available today for free. Service providers are even available to host code for distributed projects for minimal cost. There is no reason why you shouldn’t make starting a code repository one of the first steps in any project, even small ones -- unless, that is, you can’t stand to see anyone commit code changes but yourself.

Seventh deadly sin of software development: Pride (not unit testing) It’s often tempting to pat yourself on the back for a programming job well done. But how do you know it’s well done? What are your metrics?

Unless you’ve validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of defects. But all too many developers fail to produce unit tests for their code. They claim time spent testing is time not spent implementing features. In fact, some developers fail to even write QA testing into their project budgets.

What can I say, except that pride goeth before a fall? By the time defective code arrives in the client’s hands, it’s too late to undo the mistake.

The more you plan for unit testing before your code ships, the more damage control you can avoid later.

App Dev 101 | www.pcworldme.net/appdev101 | 27

Nokia Developerâ&#x20AC;&#x2122;s Guide An introduction to developing apps for Nokia devices

28 | www.pcworldme.net/appdev101 | App Dev 101

App Dev 101 | www.pcworldme.net/appdev101 | 29

1. Introduction

Nokia is the world’s largest manufacturer of mobile phones. This means Nokia offers something unique to developers: reach.

Whether it’s connecting with an affluent uptown banker in the developed world or a remote subsistence farmer in an emerging economy, it’s likely that they own a Nokia phone. More than that, they don’t just own a Nokia phone, they trust it; as Nokia has been ranked the most trusted and recognised brand in many surveys in Europe and Asia.

Nokia supports developers through Forum Nokia (forum.nokia.com). The site focuses around the three key steps in the mobile application lifecycle: design, development, and distribution. This section follows the website structure and will show you how Nokia helps you delivery apps onto the phones of millions of customers worldwide.

While Nokia is working to make things easy for developers it’s almost certain that challenges will be encountered during development, so this section concludes by providing an introduction to the many Forum Nokia resources available that offer additional information and support.

vices that can be added to your applications, such as Ovi Maps.

2.1 The platforms The Series 40 platform provides for the widest range of markets, with full and lite versions.

The lite versions power budget mobile phones.

However, these low-end devices still offer features such as music and video players, and web browsing along with the ubiquitous PIM applications. Phones based on the full version of the platform offer a wider range of built-in applications, more sophisticated browsing, and larger screens. The latest iteration of the Series 40 brings touch to this phone platform, see Figure 1 (below).

2. Not so much a phone – more a mobile computer

Before looking at the developer tools and channels offered by Nokia, it’s worth understanding a little about Nokia’s mobile devices and the platforms these devices are based upon.

Nokia phones span the entire market, from the inexpensive to the high-end. Nokia even has a subsidiary, Vertu, that will encrust a phone with diamonds or clad it in carbon fibre.

This broad portfolio of devices employs three platforms: Series 40, Symbian, and MeeGo. In the near future Nokia will start shipping devices based on Microsoft Windows Mobile too.

Using these platforms Nokia is able to meet the requirements of any market segment and this approach is a key component of the company’s success.

In addition to the device platforms, Nokia provides Ovi. Primarily a platform for extended services — such as contacts backup as well as application and music sales — Ovi offers ser30 | www.pcworldme.net/appdev101 | App Dev 101

The Touch and Type UI provides a unique combination of touch screen and ITU keypad.

This best-of-both-worlds solution offers the many phone users who prefer a phone with a keypad the convenience of touch interaction with the phone’s UI. Nokia was one of the early adopters of the Symbian OS, launching devices with its own branded UIs: Series 80 and Series 60, which was subsequently renamed S60. Nokia acquired Symbian Limited in 2009. Symbian devices offer users computer like capabilities, full web browsing, and advanced features such as multimedia, mobile mapping, and navigation.

While Symbian is expected to be phased out and replaced with devices based on Microsoft Windows Phone, Nokia is forecasting future

App Dev 101 | www.pcworldme.net/appdev101 | 31

sales approaching 150 million devices, so the platform still has much to offer developers.

The third current platform is MeeGo. Linux based MeeGo has grown out of Maemo, a platform originally used for a range of internet tablet devices without voice capability. The platform was then extended to enable phone calls over mobile networks and this version powers the Nokia N900 mobile computer.

Maemo has been merged with Moblin (a Linux based platform from Intel) to create MeeGo. Nokia intends to utilise MeeGo as a way to explore disruptive technology and services, and is therefore primarily designed for tech savvy early adopters.

According to Strategy Analytics (http://bit.ly/ g2LUhy), Nokia shipped 450 million phones in 2010 of which 100 million were smartphones.

2.2 Any application — any platform While Nokia currently employs three different platforms for its devices, the company wants you to be able to deliver applications broadly across its range of current devices. To achieve this Nokia has been focusing on cross-platform development technologies.

This has resulted in Nokia offering three primary technologies for application development: the Qt development framework, web technology, and Java technology.

Adobe Flash can be used to create standalone applications for Nokia devices. However, Flash offers the most benefit when used to provide rich visual content in mobile optimised websites. As Flash is well supported through the Adobe website, it’s not discussed further in this booklet.

dependability are vital to the success of any mobile application.

3.1 What the people want There are already thousands of applications for Nokia phones. Understanding what applications are in the marketplace and ensuring a new app offers something to grab the attention of potential users is important. Ask questions such as: Who will use this application?

What other similar applications are available?

What companies create competing products?

The key is to find out how to differentiate your application.

Considering how the application will fit into a user’s mobile lifestyle is a key to success.

Mobile phones may be used for activities similar to those undertaken on a PC: browsing the web, playing a game, or watching a movie.

However, a significant proportion of mobile phone use is made up of short sessions, with the user seeking specific information; performing their daily tasks or occupying a few idle minutes. It may be a mistake to assume that a successful PC application will automatically become a successful mobile one; the app will almost certainly need to be tuned for mobile use.

3.2 Looking good: Working well

3. Design

Great mobile apps start with great design.

Mobile apps have come a long way from those on the early mobile phones that offered simple, built-in contacts applications and games such as Snake. Today mobile phone users want more than something functional, applications have to be easy to use, responsive, and look good.

Recent research by Mob4Hire (bit.ly/chYHY9) suggests that 83% of users would download only software with a store rating of 4 stars or better. So, a compelling user experience and

32 | www.pcworldme.net/appdev101 | App Dev 101

Figure 2 (above): Designers need to consider features such as the navi keys While usage patterns may guide an overall design, when it gets down to the detail it’s the physical and native UI aspects of a mobile device that need most consideration. In terms of physical characteristics, there are

some obvious differences compared to a PC: mobile phones have small screens, either a full keyboard or ITU-T keypad for text input, and — rather than a mouse — offer a touch screen or navi keys for UI navigation, as shown in Figure 2. There are uniquely mobile considerations also, such as battery life or the effect of different lighting conditions on screen readability.

The UI’s on mobile devices from Nokia offer many of the components found on desktop applications: menus, buttons, lists, and such like. However, factors such as the available input methods and small screen size mean that their use should be carefully considered.

For example, menu structures should be kept simple so that users can easily find the application’s functions. Similarly, where the application could be run on touch and nontouch devices, thought has to be given to how navigation with a four-way navi key will work.

3.3 Prototyping with Flowella

Figure 3 (above): Flowella enables the rapid creation of prototypes from mocked-up screen images.

To address these challenges, the best advice is to prototype app ideas and start early. To assist with prototyping Nokia provides Flowella. Flowella uses images of the application’s screens — anything from simple hand drawn sketches through to fully realistic screens created with tools such as the S60 Concepting and Presentation Stencils (bit.ly/6IwxGP) — then interaction areas and the flows triggered by these areas to other screens are defined, as shown in Figure 3. The result can be export to a WRT widget or Flash Lite application and run it on a Nokia phone or the prototype exercised on a PC. Prototyping is an excellent way to determine if an application will “work” and can

be done before a line of code is written.

3.4 Learn from others There are many good examples of well designed mobile applications for Nokia devices, and developer would do well by learning from them.

One of the many excellent examples is AccuWeather.com, shown in Figure 4. This WRT widget offers an engaging user experience with a rich graphical interface that clearly and informatively displays weather information.

Figure 4 (left): The AccuWeather.com widget combines weather at a glance with comprehensive forecast and current situation details.

The AccuWeather.com widget does a great job of combining usage patterns. The widget offers a quick, clear view of the forecast, while user’s who want more weather information can browse maps and graphs or explore the weather in other locations.

Many more examples of the best in mobile design can be found in the Forum Nokia Design Gallery (bit.ly/cVMmzI) which is part of the Design section on the Forum Nokia website (forum.nokia.com/Design). For those new to mobile, exploring the showcased applications could help identify ideas for their own applications. Each showcased application or website is provided with a download link, so it can be experienced on a device.

3.5 Getting an expert view The Design section of Forum Nokia (forum. nokia.com/Design) is a repository of information built on the years of experience Nokia has in mobile application design. For those new to development the Introduction to User Experience (forum.nokia.com/ux) provides a useful primer to good UI design.

Forum Nokia also offers a couple of really use-

App Dev 101 | www.pcworldme.net/appdev101 | 33

ful user experience services (bit.ly/9ce9mk).

Developers with serious mobile development ambitions should consider the User Experience Evaluation. This is a charged service that provides an independent assessment of an applicationâ&#x20AC;&#x2122;s user experience, undertaken by a user experience expert. The review delivers a report that can be used in guiding future development. No other manufacturer offers a similar service.

An alternative or complementary approach is end user feedback, where Forum Nokia has partnered with Mob4Hire (mob4hire.com).

This company connects developers with users, from up to 150 countries. These users are interested in testing and providing feedback on new or existing apps. Such testing needs to be well planned to gain the most benefit, a starting point for such planning is provided in the Forum Nokia User Experience Test Plan for End User Feedback (bit.ly/aMqBKR).

Crafting and testing a great design for an application is critical to its success. If users cannot use the application or, more importantly, gain pleasure from its use there is no shortage of other developers ready to show how it can be done better. The key is to keep things simple, keep the user informed, make it look good, and test the design.

3.6 Obtaining user feedback to improve the offering Figure 5 (right): Ovi store offers a user rating for each app For applications distributed through Ovi Store user are able to provide feedback by way of product reviews and by providing a star rating for applications. Monitoring this feature is useful to gauge user reaction to an app and collecting feedback that can be used to improve the offering.

While this mechanism may provide specific feedback on applications features, it does not

34 | www.pcworldme.net/appdev101 | App Dev 101

tell the developer how users are using the app or, for example, which features are most popular. Currently obtaining this type of information would necessitate developers instrumenting their apps and creating a mechanism to collect the resulting usage data. However, as a result of acquiring in-app analytics company Motally, Nokia will be introducing a tool to track user behaviour in the near future.

3.7 Think about the revenue model While a well designed application is a great step on the road to success, most developer will want to generating revenue from their apps. So thought need to be given to the revenue model during the design process.

However, generating revenue may not be about how much to charge users to buy an application, perhaps the first decision is whether to charge them at all.

Nokia is in the process of rolling out a number of services that will give developers flexibility in how they charge for apps. These services are in-app advertising and in-app payments.

Inâ&#x20AC;&#x201C;App advertising will enable applications to be delivery free-of-cost to users. In-App advertising will make available over forty advertising networks via a mediation layer. This mediation layer will optimise fill rate and eCPM, while centralising reporting and payments.

However, advertising wonâ&#x20AC;&#x2122;t work for all applications: users may not tolerate advertising or the nature of the application makes adverting too intrusive. In this case consideration needs to be given to how users may want to purchase the app.

Today, Ovi Store offers a simple pay-toinstall mechanism, so to offer a trial version a separate, time or feature limited version is needed. However, In-App purchase will enable developers to offer, for example, users the ability to purchase a full version of an app from within a trial, purchase game levels, subscribe to renewed content, or buy virtual possessions without having to visit Ovi Store. These In-App purchases will offer users the same payment options as Ovi Store: Purchase with credit card and via operator billing.

When it comes to setting a price development costs are not the only consideration, the prices being charged for similar applications

needs to be considered. In addition, regional or country specific pricing may be appropriate, as a cheap application in the US may look expensive to someone in Poland.

4. Develop

Once the app has been designed, it’s time to figure out what technology to use to implement the app. As already mentioned, Nokia provides three core development technologies: the Qt framework, web apps, and Java technology. This chapter looks at each technology, provides a guide to getting started, and pointers to which technology might be right one to use. Finally the services to assist with application testing are reviewed.

4.1 Qt Qt (pronounced “cute”) is an application framework originally created by Trolltech. For many Qt is synonymous with Linux, from the days when KDE was the leading Linux desktop — as KDE is based on Qt. However, Qt is far more than a Linux UI, it’s a cross-platform framework for applications development and has been used widely to create applications for many environments, applications such as Google Earth and Skype.

It was the cross-platform capabilities of Qt that interested Nokia, resulting in Nokia’s acquisition of Trolltech in 2008. Since then Qt has been enhanced to offer the framework on Symbian and Maemo as well as Windows Mobile, Windows, Linux, and Mac. Qt is the native development framework for MeeGo and can be used for application running on Symbian S60 3rd Edition, S60 5th Edition, and Symbian^3 devices.

4.1.1 Qt in mobile devices The Qt framework has been engineered to sit within the native environment in Symbian and MeeGo devices.

As it offers APIs that can be used on multiple platforms, it might be assumed that Qt apps are run using a virtual machine, but it’s not. Qt is a framework. Unlike Java, which does use a virtual machine to execute a Java application, a Qt application is compiled into what is effectively a native application and run by the platform’s operating system at a low level.

This gives Qt the same performance as native applications, without all the tedious mucking around in platform specific APIs. Qt fixes many of the complications of coding in native C/C++, particularly on Symbian. Mobile phone platforms often employ C++ paradigms that are unfamiliar to developers of desktop applications. This is a legacy of the resource constrained hardware platforms that, for example, Symbian was originally designed to run on. With Qt, you learn the Qt paradigms once and can then use them to create applications that run on many platforms. Another advantage of Qt is that it makes extensive use of C++ macros, essentially a shortcut that adds C++ code to an application as it’s compiled, which helps reduce the amount and complexity of the code the you need to write.

Many Symbian developers are reporting a reduction of up to 50% in the time required to code an app in Qt compared to native Symbian C++.

Figure 6 (left): A Flickr viewer app created using Qt Quick Qt further simplifies the creation of applications with Qt Quick enabling rich dynamic UIs, see Figure 6. Qt Quick is a collection of technologies that enable developers and designer to define application interfaces using QML, a JavaScript-like declarative language. Qt Quick not only describes how a UI looks, but its behaviour also. Application logic can then be added using Qt C++ or JavaScript code.

4.1.2 Device and platform support Qt provides its framework for Symbian devices based on S60 3rd Edition, S60 5th Edition, and Symbian^3 as well as Maemo 5 and MeeG0. To install a Qt application on Symbian devices, the Qt framework needs to be included in the application’s installation file or Smart Installer (bit.ly/9YZLZQ) used to install the framework. The Qt framework is built into Maemo 5 and the MeeGo platform, largely

App Dev 101 | www.pcworldme.net/appdev101 | 35

eliminating the need to install the framework on these devices.

4.1.3 Qt SDK What is cross-platform development without a cross platform tool? Enter Qt SDK (bit.ly/ dCGigL), a tool that make it possible to create Qt applications on Windows, Apple Mac, and Linux computers without the need for Symbian, Maemo, or MeeGo SDKs. Qt SDK incorporates Qt Creator, tools for compiling applications, and Qt Simulator (see Figure 7), enabling applications to be built, compiled, and tested in one place. The SDK has a simple one-step installation process and no configuration is required. Compared to develop applications using the Symbian or MeeGo SDKs, the Qt SDK is almost child’s play, although learning the Qt APIs will still require some knowledge of C/C++ development.

Figure 7 (above): An application running in the Qt simulator is shown.

4.1.4 Keeping it cross-platform The Qt Mobility APIs (bit.ly/aJyPzV) offer a range of features such as the ability to use a device’s camera, access contacts, use location information, and obtain device sensor data.

Future plans for the APIs are known, with support for use of Near Field Communication (NFC), Bluetooth connectivity, and a messaging API with IM support. Beyond that there are tentative discussions for APIs to support augmented reality, a voice framework, face

36 | www.pcworldme.net/appdev101 | App Dev 101

recognition, and presence.

As with Qt in general, working with the mobility APIs is quite straightforward. The code in Example 1 shows that only a few lines are needed to access a device’s current location. void positionUpdated(const QGeoPositionInfo &gpsPos) { latitude = gpsPos.coordinate(). latitude(); longitude = gpsPos.coordinate(). longitude(); }

Example 1: Accessing a device’s location using Qt code.

4.1.5 Getting Qt For developers already familiar with C++ development on the desktop, creating Qt applications for Symbian or MeeGo will be straightforward. Once the Qt macros and APIs have been mastered, developers should find they can code much faster and with fewer of the usual C++ frustrations than usual. Qt offers a number of exciting features, such as integrated WebKit support — that enables the integration of web content into Qt apps — and scripting — that can be used to add functionality quickly or change runtime functionality. These features can further accelerate development, while delivering applications that offer the performance and usability previously the domain of hardcore native applications.

Then, when an application is finished, there is no porting mountain to climb.

But, perhaps even more significantly, Qt apps can be made available to hundreds of millions of Symbian and Maemo device owners, who will soon be joined by a new community of MeeGo device users.

4.1.6 Going beyond Qt For most applications the Qt APIs will be the only ones needed. However, for more ambitious projects it may still be necessary to use the APIs offered by the core Symbian, Maemo, or MeeGo platforms. The good news is that the Qt APIs can be easily mixed with native platform APIs where required. More information on this approach can be found on the Forum Nokia website.

4.2 Web apps Web apps are built using standard web technologies (HTML, the JavaScript™ language, and CSS). But unlike website, they can perform device side processing. This means that web apps make mobile application development practical for anyone with web development skills. Nokia offers two web app technologies: Series 40 web apps and Symbian Web Runtime widgets. (You can use your web development skills to create Qt based applications too, thanks to the integration of WebKit technology into Qt.) 4.2.1 The web app options While you can use your web skills to create both types of Nokia supported web app, they offer quite different capabilities and address different markets. You therefore need to know what your goals are before choosing the one that is right for your project.

4.2.1.1 Series 40 web apps Series 40 web apps run within the Ovi Browser proxy architecture. Most proxybased browsers offer users a very limited experience, because such browsers typically do nothing more than paint content provided by the proxy. The Ovi Browser client works differently; it’s able to execute APIs from Mobile Web Library on the device. These APIs enable you to create interactive user interfaces and graphical transitions to deliver users experiences usually available from high-end web browsers (if at all).

Series 40 web apps, as you may have expected, run on Series 40 device that support Ovi Browser. These devices span a range from low-cost devices upwards. As such they appeal to budget conscious user the world over.

4.2.1.2 Symbian WRT widgets Symbian Web Runtime (WRT) widgets are applications that run locally on a device. This aspect of their technology is put to advantage through a number of APIs that can access device information, such as contact records, device location, and sensor information, such as accelerometer data. This enables Symbian widgets to offer features that extend far beyond the browsing of information from the

web, accelerometer control games or apps that store events in the device calendar are possible.

Symbian WRT widgets run on S60 3rd Edition, S60 5th Edition, and Symbian^3 devices.

4.2.2 Tools Regardless of the web app type you decide to develop, you need one tool only: Nokia Web Tools (). The two key components of Nokia Web Tools are Web Developer Environment, for web app coding and packaging, and Web App Simulator, which enables web apps to be previewed on a computer. As with the Qt tools, Nokia Web Tools are available for Microsoft Windows, Ubuntu Linix, and Apple Mac computers.

In addition to Nokia Web Tools, you will need a graphics package to create the widget’s icon and graphics.

Figure 8 (above): A Series 40 web app in Web App Simulator.

The key features of the tool are: •

• • •

web app project creation — with options to create empty web app projects, projects based on working templates, and the importation of the content from a web app’s package. code editing— with support from code completion and pop-up API help. preview — the ability to see how a web app will behave using Web App Simulator, see Figure 8. code validation — that highlights issues

App Dev 101 | www.pcworldme.net/appdev101 | 37

• •

with code and web app configuration files. web app packaging — automatically creates a widget package ready for deployment. web app deployment —can deploy a widget to a device over a Bluetooth connection.

4.2.3 Anatomy of a widget WRT widgets can be thought of as small websites. These miniature websites contain HTML, JavaScript code, CSS, and images; basically all the usual website stuff, see Error! Reference source not found.. The files are then packed into a ZIP file, along a configuration file and an icon to use in the phone’s menu.

Figure 9 (left): The content of a typical Symbian WRT widget project is shown.

4.2.4 Making the most of Symbian WRT widgets Symbian WRT widgets can be used simply to offer a better browsing experience for your website through to offering functionality which would normally be considered the domain of traditional C++ or Java applications. Covering all the capabilities is beyond the scope of this booklet, but two are worth introducing: home screen views and device integration.

4.2.4.1 Building a home screen view Figure 10 (right): The AccuWeather widget’s home screen view.

Home screen views, such as the one for the AccuWeather widget shown in Figure 10, are used to provide a summary of widget

38 | www.pcworldme.net/appdev101 | App Dev 101

content on Symbian^3 devices as well as the Nokia N97 mobile computer and Nokia N97 mini. As users spend a lot of time in their home screen, these views are very useful.

Home screen views are simple to create. Step one is to create a view that fits a 82 x 312 pixel home screen “slot”. Then add logic to the JavaScript onload, onshow, and onresize events to determine the size of the active screen and display the mini view when the screen in use is the home screen. Several example widgets include suitable routines – such as the FNReader widget (bit.ly/dA5Rf3) which can be found in the Code Examples (bit. ly/dtCsS0) section of the Web, Develop page on Forum Nokia.

4.2.4.2 Adding device integration WRT widgets really come alive when they combine information from a website with user data, such as contacts or device information.

Take a website that provides event lists. When someone visits the website it has no way of knowing where the user is are, so the user has to select a location and the website can then provide a list of events nearby. A WRT widget can obtain the devices GPS location and then list events sorted by distance from the user’s location automatically.

The easiest way to add device integration is with Nokia Platform Services 2.0 (bit. ly/1asacE). This API provides straightforward JavaScript APIs as part of the nokia.device object, which can access information and data using just one or two lines of code.

Using the Platform Services 2.0 APIs you are able to access and in some cases manipulate contacts records, calendar records, device communication logs, location information, landmarks, media files, messages, sensor data, and device status as well as make use of the device’s camera to capture still images.

Platform Services 2.0 is shipped in the firmware of all Symbian^3 devices and the two Nokia N97 models, but can still be used on any Nokia device with WRT 1.1 support (bit.ly/ bU9VHW) by adding the platformservices.js file to a WRT widget. At 97Kb this is a bearable overhead.

To illustrate the simplicity of the API, Example 2 shows the code that enables a widget to

read the device’s location (albeit omitting vital error checking): serviceObj = nokia.device. load(“geolocation”); serviceObj.getCurrentPosition(success_ callback, error_callback, positionOpts); … function success_callback(result){ Lat = result.coords.latitude; Long = result.coords.longitude; } }

Example 2: Code that enables a widget to read the device’s location.

4.2.5 Ovi Maps for web developers An additional opportunity for web developers, not those creating widgets alone, is provided by the APIs that leverage the services offered

by Ovi. Ovi Map Rendering API (bit.ly/h78zbz) enables web developers to obtain rendered tiles of map information for any location worldwide.

Combined with the ability to obtain a device’s location, Ovi Map Rendering API enables fully featured location based widgets.

Ovi Maps API (http://bit.ly/fyexRn) is available also for use on desktop browsers. This API enables developer to control the Ovi Maps plug-in, a full vector-based map rendering feature for desktop browsers.

4.2.6 Web apps or website — which is best?

WRT widgets enable websites that run on a user’s phone to be created. Using JavaScript — and remember many free and commercial JavaScript libraries can be used also — developers can make WRT widgets more like an application than a website. Bear in mind, however, that widget code can easily be copied, so a WRT widget may not be the best approach for applications that rely heavily on code running on the device. If the value is in the apps device side code, Qt or Java may be a better implementation option. (If the app’s code is complex, Qt and Java will almost certainly run it more efficiently too.)

Alternatively, developers may decide that a widget is unjustifiable in terms of target audience and that optimising their website for a wide range of Nokia devices would be a better strategy. If this is the case then Nokia has

tools for this job too.

The web templates, mentioned earlier, are also supplied in versions for mid-range and lowend phones (bit.ly/9F6GLB). These templates may help simplify the optimisation of your website for mobile browsing. If you use either the Joomla! or phpBB content management systems then there are also plug-ins (bit. ly/cc6Esb) available that will automatically reformat content for the browser on Nokia Symbian devices.

4.3 Java 4.3.1 Why use Java?

The Java language is undoubtedly the most widely used language for mobile development, with support provided in almost every type of mobile device. It’s this wide availability that is the attraction of Java technology and the fact that it enables developers to build everything from simple games to sophisticated, secure enterprise applications.

Developing Java applications for mobile devices has been haunted by one very frightening word, fragmentation. There are legion tales of developers who have ended up creating many different versions of an app, to address variations in the implementation of Java technology on different mobile devices.

The good news with Nokia devices is that they offer a very consistent set of Java API implementations in the Series 40 platform as well as Symbian. This means that well designed apps can be porting to run on several hundreds of millions of Nokia devices with minimal effort.

4.3.2 Java for Nokia devices Java technology is offered in Series 40 and Symbian devices. Although the available APIs differ between platform and platform versions, each API has a common implementation greatly reducing fragmentation issues. The smallest set of APIs is available on Series 40 lite devices, the largest on high-end Series 40 and Symbian devices.

While Nokia has been careful to ensure it provides common implementations of Java APIs, it has implemented Mobile Service Architecture (MSA) (JSR-248). MSA provides for a uniform implementation of several APIs

App Dev 101 | www.pcworldme.net/appdev101 | 39

covering PIM access, Bluetooth connectivity, media playing, 3D graphics, messaging (SMS and MMS), and 2D graphics. Using MSA APIs means applications should run unchanged on any device that implements MSA, regardless of manufacturer.

In addition to the APIs provided by MSA, various Nokia devices also include JSRs for web services, security and trust, location information, SIP, content handling, advanced multimedia function, and use of device sensors such as accelerometers. There are Nokia specific APIs, such as those that enable developers to take advantage of the features of the Series 40 Touch and Type UI, which will be discussed later.

If you are new to Java development the Java Tutorials on the Oracle website (bit.ly/bMeHu3) are a good place to start, as are the many Java development books. For developer who know Java already, but have not yet coded a mobile application, the tutorials from Forum Nokia (bit.ly/9EpUmT) will be of great help.

4.3.3 Tools Nokia doesn’t provide a Java IDE, as there is already a wide range of commercial and free IDEs to choose from. Rather, Nokia contributes to the NetBeans (netbeans.org) and Eclipse (eclipse.org) IDEs to ensure these two popular, free IDEs can be used to create applications for Nokia devices easily.

To either of these IDEs developers add one or more of the Series 40 (bit.ly/4c5FEy) or S60/ Symbian (bit.ly/HMGSN) SDKs. To find out which platform, edition, and feature pack any device is based upon, visit the device section (bit.ly/9vsPK3) on Forum Nokia. Once the SDKs are installed, the developer’s chose IDE is configured to use them.

Figure 11 (right): An example Touch and Type application running in the emulator Each IDE can then be used to create Java code in the usual way, with the API support information being provided by the SDK. Once coding is

40 | www.pcworldme.net/appdev101 | App Dev 101

complete the application can be run in the SDK’s emulator, see Figure 11. In addition to being able to run the app on a computer the simulators provide diagnostic features and, in the latest versions, a route simulator for testing location-based applications. Application debugging can be undertaken on the code running in the emulator also.

4.3.4 Coding considerations The diversity of devices from Nokia that can run Java applications is great, from low-end devices such as the Nokia 2220 Slide, with a 128 x 160 pixel screen, maximum heap size (memory available to the program) of 1 MB, and maximum JAR size of 512 KB, to the Nokia N8 multimedia computer with a 640 x 380 pixel screen and heap and JAR size limited only by the device’s physical memory.

It’s therefore very likely that a Java application that takes full advantage of the Nokia N8’s screen and memory probably won’t work on the more humble Nokia 2220 Slide.

The available APIs need to be considered also.

The Nokia 2220 Slide offers additional APIs from four JSRs (for file, PIM, media, secure communications, and messaging) while the Nokia N8 offers APIs from twelve JSRs plus two additional Symbian specific APIs. These APIs on the Nokia N8 offer advanced features such as location and 2D and 3D graphics.

There is a simple solution: build for the device with the lowest specification the app will run on. The application will then run on any Nokia device with a higher specification. The disadvantage of this approach is that, while an application may run, it may not be as appealing: The graphics for a game written to run on the Nokia 2220 probably won’t look good on the screen of a Nokia N8 that has almost twelve times as many pixels.

This approach also means that apps can’t make the most of the

extra features available by using the full range of JSRs on the Nokia N8. For example, on the Nokia N8 an application could make use of the device’s accelerometers to control game play.

It’s all a question of balance, what is the audience, what phones are they are most likely to own, and what features do they want delivered?

4.3.5 Working with JSRs Mobile devices store a wealth of user information, such as contacts, calendar events, and media files. The devices can also supply information desktop computers cannot, such as location and orientation.

The APIs provided by JSRs enable apps to interact with user data and take advantage of the additional information available from mobile devices. Take location again.

Using the APIs provided by Location API for J2ME™ (JSR-179) obtaining a location is easy. The app uses LocationProvider. getInstance() to obtain an instance of LocationProvider, as shown in Example 3. try { locationProvider = LocationProvider.getInstance(criteria); } catch (LocationException e) { // Handle location exception here. return; }

Example 3: The Java code to obtain a device’s location. criteria enables a definition of the accuracy and extent of information to be provided.

LocationProvider represents a location-providing module that generates Locations (from the device’s GPS receiver). Now the current latitude and longitude can be retrieved with the LocationProvider.getLocation() method as shown in Example 4. try { location = locationProvider. getLocation(60); } catch (Exception e) { // Handle exception here. return; }

coordinates = location.getQualifiedCoordinates(); if (coordinates != null) { // Use coordinate information double lat = coordinates.getLatitude();

double lon = coordinates.get-

Longitude();

string = “\nLatitude : “ + lat + “\nLongitude : “ + lon; } else { string = “Location API failed”; }

Example 4: The Java code to obtain a current latitude and longitude 4.3.6 Adding the dimension of touch Figure 12 (left): Gestures add a new dimension to Java apps In general, Java applications designed for devices using the navi key will work on Nokia’s touch devices without any changes. However, it’s worth mentioning that Series 40 devices using the Touch and Type UI provide extra APIs that enable apps to provide a more optimised touch experience to users.

These APIs are the Gesture API, to capture taps, long presses, repeated long presses, dragging, dropping, and flicking gestures, and the FrameAnimator API that calculates motion for kinetic scrolling and linear animations.

More information on these APIs can be found in the Java Developer’s Library (bit. ly/9RfxWA).

These touch APIs are part of the Nokia API, which provides an enhanced TextEditor API. This is a floating text editing component that is used on top of the LCDUI Canvas. Unlike the standard text editor this API enables the client application to define the colours for the editor and draw additional UI enhancements.

4.4 Making the right development choice Having the three technologies for application creation is great, but which one should be used? Choosing the right development language will involve a unique set of decisions: What development experience does the developer have? How important is application App Dev 101 | www.pcworldme.net/appdev101 | 41

performance? Does the app need to access features of the device or the user’s data?

Obviously, if the developer knows C/C++, web languages, or Java already then the choice may be a simple one. When starting from scratch and the choice of development environment is open then the following factors should be considered: • Speed of development: In general WRT widgets will be the fastest to develop, Java next, and implementing in Qt will probably take the longest.

• Application performance: In general a Qt app will give you the best on-device performance, Java the next best, and a WRT widget the least performance.

Clearly the nature of the application will affect the choice. If the app is leveraging web based information a WRT widget could be the right choice, for a fast passed 3D action game Qt may be the best option. Regardless of the app’s functionality, the choice of development tools Nokia offers means developers can find the right one that balances development cost and time with the user’s experience on their device.

4.5 Test, test, and test again Testing is a task most commonly conducted once an application has been designed and coded. But testing can, and should, be considered in a broader context: something that permeates the entire development process, from the first UI sketches through the final build to delivery and marketing. Some of the other aspects of testing have already been alluded to in the chapter on design and others will be covered in the chapter on distribution, so this section will focus on functional application testing.

Nokia provides a range of tools that can be used to facilitate application testing. These tools are in three groups: emulators, on-device debugging tools, and remote device access services.

Emulators enable developers to test applications on a computer, rather than having to package and deploy them to a device each time a test is run. Most of these tools have been mentioned in the chapter on development. Emulators are however not a complete

42 | www.pcworldme.net/appdev101 | App Dev 101

testing solution, they have their limitations.

Because the application is running on a computer, features such as network connections are created through the computer’s hardware and may not provide an accurate picture of how the application will run on a device.

As a result on-device debugging can be necessary, particularly when more advanced use is being made of device features. To enable on-device debugging of Qt applications, Forum Nokia supplies AppTRK for Symbian devices while for Maemo devices a number of tools are available, such as ESBOX. On device debugging can also be undertaken for Java apps on Series 40 and Symbian devices.

Figure 13 (above): Accessing a Nokia E7-00 device using the Remote Device Access service.

When it comes to addressing the limitations of the emulators in functional and user testing, Forum Nokia provides three services (forum. nokia.com/rda) that enable developer to use to a battery of devices over the internet.

Remote Device Access (RDA), see Figure 13, is a free service that provides access to a set of Symbian and Maemo devices, while Virtual Developer Lab (VDL) and Nokia Handset Cloud Service are charged services run by Device Anywhere and Perfecto Mobile respectively for Forum Nokia. Unlike RDA, the other services provide access to Series 40 devices and more sophisticated testing tools, with features such as the ability to record and play back test scripts and, in Nokia Handset Cloud Service, test flows for Symbian Signed and Java Verified™.

App Dev 101 | www.pcworldme.net/appdev101 | 43

4.5.1 Do the right testing While almost every PC application testing process applies to mobile applications, mobile applications have their own unique set of test criteria. Fortunately, many of these test criteria are already documented. For example, the test criteria for Symbian Signed or Java Verified (discussed in the chapter on distribution) provide an excellent foundation on which to build application test criteria. More stringent testing criteria are provided by the Nokia Test Criteria for Symbian C++ Applications (bit. ly/hZZI8) and Nokia Test Criteria for Java™ ME Applications (bit.ly/jHt1d). These criteria are used to test applications that will be shipped on devices as they leave the factory.

Guidelines for specific application types, such as games, are provided in the various Forum Nokia developer libraries (library.forum.nokia. com).

Ultimately apps should be tested on a device available to the developer. Some of the reasons why this is necessary have already mentioned, but a device is the only way to ultimately confirm that the application behaves as expected and offers the required usability.

Another option is to go directly to end users and run a beta program to gather as much feedback as possible on the widest range of devices. Developers can run these programs themselves or use the services of organisations, such as the previously mentioned Mob4Hire, to find testers. For functional testing, it should be remember to include a guide to the features users should test and advice on how to provide feedback when the app doesn’t work as expected.

5. Distribution

So the application has been built, it offers users great functionality, it looks good, and works reliably, but one thing is missing, no one is using it.

Figure 14 (right): The Ovi Store client enables Nokia device users to browse and buying apps easily.

To get access to millions of Nokia device owners, Ovi Store, see

44 | www.pcworldme.net/appdev101 | App Dev 101

Figure 14, is the best choice. Ovi Store is now the third largest application store globally and around 70% of its four million daily downloads are for games and apps.

5.1 Becoming an Ovi Store Publisher To distribute through Ovi Store developer need to register (bit.ly/9lpktC). Registration is open to all developers, whether they operate as a business or not — although only business can register to distribute items such as audio, video, and personalisation content. The process of registration is done online and involves the payment a one-off €50 registration fee.

Once registered as an Ovi Publisher, applications can be submitted to the store.

5.2 Submitting your application Submitting applications to Ovi Store is an online process and quite straightforward, with a little preparation.

First you check that an application is ready to be submitted, the key criteria are: • It’s packaged correctly, for example a Qt app for Symbian is in a SIS file that includes Smart Installer.

• Symbian and Java apps have passed the appropriate Symbian Signed or Java Verified tests.

• The app complies with the Ovi Store content guidelines.

Next, the information that will be used to present your app in the Ovi Store needs to be prepared: • The images, text (localised as necessary), category items, and keywords that will be used to describe the app in Ovi Store.

• A list of the devices the app is known to or should work on.

• The countries and languages the app will to distribute the app to, bearing in mind that some content (such as gambling apps and those containing risqué content) may not be acceptable or legal in some countries.

• The price to be change for the app in each country it will be to distribute to.

• Whether customers can purchase the application with a credit card only or also by operator billing.

App Dev 101 | www.pcworldme.net/appdev101 | 45

46 | www.pcworldme.net/appdev101 | App Dev 101

Once all this information is ready the app can be submitted contents. More details on how to prepare an application and the information needed it to submit to the Ovi Store are provided in the Ovi Publishers Guide (bit.ly/ ae3rdh).

5.3 The QA All content submitted to Ovi Store is subject to QA checks by Nokia. These encompass legal and technical verification and test, once these are successfully completed Symbian and Java app are signed and all content made ready to publish in Ovi Store. It’s important to note that there are no arbitrary restrictions placed on the applications that can be submitted (as long as the application is actually legal). Applications won’t be rejected because they compete with or are better than those created by Nokia.

5.3.1 Signing Not all apps for Nokia mobile phones need to be signed. Web apps, Flash Lite applications for Series 40, and Qt applications for Maemo have no signing requirements. These apps are simply package and are then ready to install on a phone.

However, Qt and Flash Lite apps for Symbian devices and Java apps need to be signed.

The good news is that signing of Symbian and Java apps is provided as part of the Ovi Store intake process and involves no additional cost to you. However, just because Ovi Store signs these apps, you still need to ensure that their apps have been tested and will pass the testing required by Express Signed (for Symbian) or Java Verified.

The test criteria for Symbian Signed are available in the Forum Nokia wiki and those for Java Verified from the Java Verified website as a PDF (bit.ly/9TA31M).

If an app fails the QA process, it will be returned to have the problems rectified and will need to resubmit it to Ovi Store — a delay easily avoided by good design, careful coding, and appropriate testing.

generated from 70% of billing from credit card transactions and 60% of billing from operator billing, after taxes and administration items, such as refunds. The difference in splits is due to the differences in underlying transaction cost. While credit card transactions incur a small transaction fee, operator billing charges can absorb anything up to 90% of the amount paid by the consumer. Rather than leave you with the uncertainty of what revenue per will be received from operator billing, Nokia chose to provide a fixed 60% split.

It may seem that credit card billing offers the best opportunity for revenue generation, as a higher percentage of the application price is returned. However, it needs to be remembered that not every phone owner has a credit card, but they do have an operator, and operator billing is simple and trusted.

As a result, revenues from operator billing can exceed those from credit cards by a factor of ten; for every dollar earned on credit card sales, ten could come from operator billing.

Operator billing is available for 109 operators in 34 markets.

5.5 Generating consumer awareness Simply because an application is in Ovi store, you should ignore promotion: Ovi store will increasingly use recommendations, generated by user feedback, as the principle guide for promoting applications but does offer banner and spotlight promotions to selected content items. While building a relationship with the local Nokia or Forum Nokia support team or joining Forum Nokia Launchpad (bit.ly/bDMd6Y) can help gain an application exposure, it’s worth thinking outside the box. One of the most effective approaches can be to give an application away to websites and blogs dedicated to the platforms or devices the application runs on. There are no guarantees, but if the right community members like an app the publicity could be a very effective way to generate sales and user recommendations.

5.4 Payments Once an application is published in Ovi Store you will receive payments each time your monthly balance exceeds €100. Revenue is

App Dev 101 | www.pcworldme.net/appdev101 | 47

Figure 15 (right): The Ovi Marketing Tool enables the creation of customised web banners in seven easy steps.

To assist with promotion outside Ovi Store, developers can create web banners that link to the apps store page using the Ovi Marketing Tool (promotions.ovi.com/omt/), see Figure 15. With support for eight languages, custom colours, messages, and icons, the Ovi Marketing tool is an easy and powerful tool for those developers who don’t have access to a graphic design team.

A key point about marketing, much in the same vein as testing, is that it should not be something thought about after an application is completed. An application’s marketing mix needs to be considered throughout its development, after all there is little point in starting if it is not possible to identify that someone (hopefully somemany) will want the app.

6. Getting extra help

The chances are that at some point during an app project a technical or marketing challenge will arise that the developer cannot resolve alone. The good news is that Forum Nokia has a wealth of resources to help find answers to development challenges.

6.1 Library Definitive information on design and development for Nokia devices is made available in the Library section of Forum Nokia (forum.nokia. com/Library/). This section provides: • The Developer’s libraries (library.forum. nokia.com). These provide references on Qt, Java, and Web development as well as design and user experience.

• Documentation. A range of in depth papers on various aspects of design, development, and technology supported

by Nokia.

• Learning materials. A wealth of selfpaced tutorials and training courses.

• Code Examples. Example applications illustrating how to use many of the Qt, Java and WRT widget APIs.

48 | www.pcworldme.net/appdev101 | App Dev 101

6.2 Community One of the best sources of information is the Forum Nokia Community (forum.nokia.com/ Community). In this section developers share information on all aspects of mobile apps development.

6.2.1 Wiki Now with over 8000 articles, the Forum Nokia wiki (wiki.forum.nokia.com) is a repository of the experience of Forum Nokia develops as well as housing the Knowledge base, information from answers provides to support questions by the Technical Support service.

6.2.2 Discussion Boards Split into various sections based on technologies, the Forum Nokia Discussion Boards (discussion.forum.nokia.com) are a way to tap into the experience and knowledge of the Forum Nokia community interactively.

Before posting a topic, it’s recommended that developers search the boards to see if their issue has already been discussed and a solution provided.

6.2.3 Projects While primarily designed as a resource to enable developer to collaborate on open source project, Forum Nokia Projects (projects.forum. nokia.com) can be an excellent source of code examples, ideas and solutions to coding challenges.

6.3 Technical Support If all else fails, the Technical Support service (forum.nokia.com/Support/) is available to help solve specific problems or answer focused technical questions, on a case-by-case basis. Support is provided on ‘tickets’, which are purchased individually or at a discount for a block of five.

Note that support for Ovi Publishers is provided within the Ovi publishing system.

6.4 Launchpad Part of the Developer Programs offered by Forum Nokia, Launchpad (bit.ly/bDMd6Y) provides developers with a number of additional benefits that can help with app projects.

7. Conclusion — the time to get started is now

accelerated and purchasing applications has become a mainstream consumer activity.

While many application stores now boast catalogues offering thousands of applications, there is still plenty of opportunity for new or better applications. The key for developers is to identify what they are good at and capitalise on that.

Nokia’s range of development technologies means that developers don’t necessarily need a degree in computer science to get started.

Some basic training from resources on the internet and a logical mind can get almost anyone started with a WRT widget in a matter of days. Equally, for developers with a good knowledge of programming, mastering Java ME or Qt should be interesting without being impossibly challenging.

Once an application is ready to distribute, Ovi Store provides a convenient way to take it to market. The availability of operator billing maximises the likelihood that consumers will purchase an app and for free applications Ovi Stores global coverage ensures the widest possible uptake.

Whatever the starting point Forum Nokia provides tools and information that can help with almost every aspect of design, development, and distribution. Importantly, most of the resources are also free of cost.

The opportunities for making a success of mobile applications has never been greater, so there has never been a better time to get started.

8. References

[1] Statistics on payment and settlement systems in the CPSS countries - Figures for 2009 - Preliminary release, CPSS Publications No 93, December 2010, Bank for International Settlements, http://www.bis.org/publ/ cpss93.htm

The market for third party software on mobile phones has been an integral part of their appeal from the launch of the first Java enabled phones. From that point on the third-party software market has grown steadily, offering many developers a lucrative business opportunity. In the last few years that growth has App Dev 101 | www.pcworldme.net/appdev101 | 49

Android

50 | www.pcworldme.net/appdev101 | App Dev 101

Who’s in charge of Android development: Google or developers?

Google says Android is an open development process, but partners say the company is running the show to ensure Android’s commercial viability

O

nlookers say that Google is in charge of Android development, despite pitching the software as a community project.

But experts say that could be the only way Google can ensure that the software is actually released.

The Android development process may reflect a reality in the open-source environment, as some groups forego the community in an effort to speed commercialization.

When Google first introduced Android, it called it a joint project by the Open Handset Alliance, a group of companies supporting the OS. “Together we have developed Android,” the OHA site reads.

But in reality, the software is developed in-house at Google, partners say. “Android is open source innovation driven by Google,” said Bill Maggs, head of developer and partner content and services at Sony Ericsson.

“Google is largely at this point definitely driv-

ing the framework.”

Motorola also acknowledged that Android is not developed in the open. “We would love a world where the development itself is closer to open,” said Christy Wyatt, vice president of software applications and ecosystems at Motorola, speaking at a press event at the recent CTIA conference.

“It’s absolutely Google-controlled and managed,” agreed Avi Greengart, an analyst with Current Analysis.

Eric Chu, group manager of Android mobile platform at Google, said that Android has always been and continues to be an open source project, and that it’s not accurate to characterize it as an initiative completely controlled by Google.

However, he acknowledged that Google faces a challenge of working with partners that want to contribute to Android while also meeting other partners’ demands for comApp Dev 101 | www.pcworldme.net/appdev101 | 51

“We think it’s very important for Android to have

a strong commercial focus. There are a lot of open mercial products.

It’s a constant source projects out there, but what the world cares struggle to balabout is open source projects that will result in comance how often mercial products.”

Google releases different early is a strong base of non-Google contributions access versions of the software while working because the software is built on Linux, which on finishing versions that can ship commeris developed by the community. In addition, cially, he said. typically in open-source projects there is a “We think it’s very important for Android to small group of core developers that maintain have a strong commercial focus. There are a the distribution, surrounded by a group of delot of open source projects out there, but what velopers that build modules that are not part the world cares about is open source projects of the base distribution. Android is essentially that will result in commercial products,” Chu following that same model, with Google servsaid. “That’s where we’re putting a lot of our ing as the core developer and handset makers energy.” like Motorola and HTC serving as the edge It’s not clear if Google intended to control developers, building their own extensions, development from the start or if it changed its Prentice said. plan when faced with the realities of developing in open source.

If Google has decided to drive Android devel“You don’t get work done if it’s totally open,” opment internally, that doesn’t explain why Greengart said. As an example, he points to it seems resistant to sharing its development LiMo, a mobile Linux project. “LiMo is 100 plans. After widespread criticism following the percent multisource. So much so that the initial release of Android over the mystery of first-generation devices are incompatible,” what might come next, Google posted a vague he said. road map online. However, it’s hardly been up“That’s where controlling the development dated since. The most recent item on the page process and having a developer with clout is for “beyond Q1 2009” and only includes both in terms of money and brand to say, ‘This support for additional types of displays. is the way we’re doing it, either live with it or Chu said they’re too busy to update the page. go away,’ is actually valuable,” he said. “To an “We have a lot of demand for additional extent, it ensures there’s something usable.” features for Android, so we decided rather Another analyst said Google’s Android experithan spending a lot of time updating the road ence reflects a trend. “It is representative of map and deliver something nine months from an evolution, or maturation of the opennow, we’ve just been delivering at a very rapid source model,” said Brian Prentice, an analyst pace,” he said. with Gartner. Projects like Linux were created That could be. Or, Google might not want to tip through broad and active community particioff competitors, Greengart said. Google could pation, he said. “But what we’re starting to see also be “playing politics,” meaning it may have is that a single dominant committer is just as decided that if it makes no promises then it viable a model for open source.” won’t be criticized for failing to deliver, he said.

Prentice also pointed out that while Google may control development of Android, there 52 | www.pcworldme.net/appdev101 | App Dev 101

Android Resources • •

• • • •

• •

•

The website with all the information you need is developer.android.com.

There are lots of videos of presentations and other sessions at developer. android.com/videos, which you should have a look at before starting your Android adventure.

From developer.android.com/sdk you get the SDK, currently available for Windows, Mac and Linux.

Eclipse (www.eclipse.org) is the preferred development environment for Android apps.

Google provides Android applications can be distributed as direct-download files on a website but you will want to look at Android Market, the official distribution channel for the platform.

Currently, in most of the Middle East, only the free apps in Android Market are available.

If you want to publish to Android Market, you have to register as a developer and pay a $25 registration fee at market.android.com/publish/signup.

With multiple versions of Android out in the market, check out the current distribution at developer.android.com/ resources/dashboard/platform-versions.html.

App Dev 101 | www.pcworldme.net/appdev101 | 53

Apple (iOS) 54 | www.pcworldme.net/appdev101 | App Dev 101

App Dev 101 | www.pcworldme.net/appdev101 | 55

Apple’s mobile developer momentum open to challenge Business application developers will be quick to embrace other mobile OS options to hedge their bets against Apple’s consumer focus, analysts say

W

hile Apple has major momentum in the mobile application developer space, there is room for other companies to steal Apple’s thunder, according to an analyst report released earlier this month.

In Forrester Research report entitled “The Feeding Frenzy over the Mobile Developer Channel,” Forrester analysts led by Tim Harmon note the pros and cons of Apple and other vendors. The report focuses on the smartphone and tablet space.

“Apple has so much developer momentum in the mobile market that it would take a major fiasco to derail it, particularly in the smartphone segment.” But Apple took a long time to support Microsoft Exchange, and its iPad tablet lacks important interfaces such as USB ports. “Business application developers will be quick to embrace a second and third mobile OS option in order to hedge their bets against Apple’s consumer market focus.”

But if the mobile OS war can be compared to the PC OS war, Apple is the only sure bet, Forrester said. Contenders in the developer ecosystem currently include Apple (iOS), Google (Android), HP/Palm (WebOS), Microsoft (Windows Phone 7), and RIM (BlackBerry 6 OS). There will be three winners, according to Forrester.

Google is attracting developers but suffers from its “experimental culture,” Forrester said.

“Largely because of the lack of a Wintel-like tax, Google’s open source Android OS has

56 | www.pcworldme.net/appdev101 | App Dev 101

caught on with developers. But Google takes a ‘throw the spaghetti at the wall and see what sticks’ approach to many of its software platform releases. And some of Google’s offerings do indeed not stick, e.g., Google Wave.”

Microsoft also faces a challenge. “Of the players in the smartphone/tablet space, Microsoft has, by far, the largest developer channel. But, after years of misfiring on Windows Mobile, Microsoft will have to prove to developers that Windows Phone 7 is worth their attention and effort once more.”

RIM’s plan to utilize a different OS in its tablet than on its smartphones also is an issue.

“Either continuing with two OSes or putting one out to pasture will create confusion in the developer community. If RIM is indeed going to sunset the BlackBerry OS, it needs to do so fast.” The RIM PlayBook tablet will use BlackBerry Tablet OS. With its acquisition of Palm, HP has all form factors covered from servers down to smartphones and tablets. But HP faces obstacles as well, according to Forrester. “Indeed, HP has done little to demonstrate or indicate how it will integrate WebOS with Windows. Moreover, HP, historically, has never really understood the developer channel culture. On the other hand, Palm has a very energetic developer channel. However, HP has a lot of work to do to prove that it can leverage Palm’s developer channel culture.”

Forrester also cited a murky picture on a “killer app” for enterprise smartphones. “While traditional business applications (e.g., email, field service) rank high on customers’ investment radars, mobile OS vendors are looking for that next killer app.”

Five qualities of a great iPhone app Business application developers will be quick to embrace other mobile OS options to hedge their bets against Apple’s consumer focus, analysts say

R

etailers spend a fortune each year promoting their brands in all sorts of venues, and now many are turning their sights to the creation of an iPhone app to bring brand awareness to the most popular smartphone in the world.

Clothing retailer Gap, for instance, is mulling an iPhone app to get people interested in its products. Gap teamed with Mobclix, an operator of a mobile ad exchange marketplace, to come up with a contest to find out what a good Gap-branded iPhone app might look like.

The contest attracted some 400 iPhone app developers—many from Mobclix’s network— who jumped at the opportunity to develop an app for a well-known brand, as well as have a shot at winning a $1,000 Gap certificate and $1,000 Mobclix advertising package. Developers, of course, also hoped that winning would lead to a little publicity and a chance to rise from the crowded iPhone app developer space.

After three months, Gap announced its winners earlier this week: Intuapp’s “Gap” app took the grand prize ($1,000 Gap certificate and $1,000 Mobclix ad package), while Mobiteris’ “Dance Off” app came in second place ($500 Gap gift card, an iPhone 3GS and a $500 Mobclix ad package).

Consumers were also allowed to vote in a People’s Choice portion of the contest, and they selected Infosys’ “GAP4Me” app (Gap jeans for a year, iPhone 3GS and a $500 Mobclix ad package).

The winning apps, however, are not available on the App Store—nor will they be anytime soon. “We do not have plans to use the winning app at this time,” Gap spokesperson

Olivia Doyne wrote in email. Contestants were allowed to develop iPhone apps under a special Apple program for a select few iPhones for judges. Youtube videos showing each app are below.

Nevertheless, we can learn a few things about what makes a winning app, as well as why apps miss the cut. Here are five best practices for building a great iPhone app.

1. Give ’em a reason

Many apps that didn’t get chosen made the mistake of being too narrowly focused, says Bill Westerman, principal and CTO of Create with Context, a design and research firm, and one of the judges in the Gap contest. They might have had shopping functionality or coupons or a store locator, but not a good combination of these features.

The bottom line is that they relied too heavily on consumer loyalty to the brand to draw people into an iPhone app, which leads to the question: For some retailers, should there even be an app for that? Other brands have shown success. “Some brands can leverage an iPhone app well,” says Krishna Subramanian, founder of Mobclix. “This year eBay made over $400 million off their iPhone app, and the app hasn’t even been out the entire year.”

Brand loyalty alone rarely drives people to download an iPhone app that clutters their screen and uses up memory. As you’ll see, the winning apps didn’t just peddle Gap products; rather, they provided a range of fun features and activities, from games to music videos to a virtual dressing room. The Gap brand almost seemed secondary.

App Dev 101 | www.pcworldme.net/appdev101 | 57

2. One of 100,000

Can you hear the dull buzz? It’s the din of 100,000 iPhone apps. Grand prize winner Intuapp’s Gap app broke from the crowd by turning up the music, Westerman says, “and had a good visual design that reflected the Gap brand.”

Gap’s television commercials and stores are filled with music, and so Intuapp’s Gap app greets users with streaming music, giving you the feeling that you’re in the store. The app also makes it easy to browse clothes and play fun games, including a guess-the-price game for clothes. A new coupon regularly pops up.

“It’s important for developers to remember that you have to make sure someone is going to come back to the app multiple times,” Westerman says.

guidelines but close enough that you didn’t have to sit there and try to figure it out.”

4. Make it about me

Consider the People’s Choice award winner, Infosys’ GAP4Me app, which provides a virtual dressing room. It uses a conventional UI feature of the iPod album cover flow. Instead of albums, though, users can easily slide through 30 or 40 shirts.

Best part about the app is that you can cut and paste clothes onto a picture of yourself (or anyone else) stored in the iPhone. You can try on different outfits, put clothes in a “trial pile,” and, later, select clothes to a cart and head to checkout.

“It’s a fun way of interacting with the clothes,” Westerman says. “It really touches on that basic human need of what this stuff looks like for me. It’s great to look at clothes online, but one of the things people always struggle with around e-commerce is figuring out how this particular product is relevant to me and my body or my lifestyle.”

5. What’s my reward?

3. Don’t go overboard

When creating an iPhone app, developers face a tough dilemma: how far to stray from Apple’s user-interface guidelines.

If you follow the UI guidelines precisely, you’ll end up with an app that every iPhone owner will know how to use although it will be a very generic app—a death knell in the crowded App Store. If you take the other extreme and move too far from the UI guidelines, then users will struggle with understanding how the app works.

Westerman says many apps in the Gap contest fell on both sides. “We saw a lot of conformity with the UI, while others were so far afield from the UI conventions,” he says. “The apps that really did well [in the contest] were the ones that weren’t exactly based on the

58 | www.pcworldme.net/appdev101 | App Dev 101

Another important element in a good retail iPhone app is a reward, usually in the form of a special discount, to give users for interacting with the app. A good rule of thumb: the greater the interaction, the greater the reward.

Second-place Mobiteris’ Dance Off app, for instance, asks a lot of its users. Gap television commercials are well-known for energetic people dancing and jumping around in Gap clothes. The message is that Gap is fun. Dance Off plays off of these commercials by letting users make videos of themselves dancing to similar music.

The Dance Off app lets users find the nearest Gap store to try on clothes at the store. The app enables the iPhone to shoot a video of the user in Gap clothing dancing to music, which can later be downloaded to Facebook. The app contains the best video of the week. “By seeing other people’s videos, it also gives you a reason to go back to the app,” Westerman says.

After you post a video, the app immediately gives you a coupon for effectively creating a little commercial for the Gap.

Apple iOS Resources •

•

• • • •

•

Xcode is the toolset you use to manage all aspects of your iOS app development process from editing and debugging source code, designing the UI, analyze performance and more. Xcode reqiures a Mac with an Intel processor. It’s a free download from developer.apple. com/xcode.

In Xcode you write your applications in a programming language called Objective-C. It’s an object-oriented programming language, defined as a small but powerful set of extensions to the standard ANSI C language. You can learn more about Objective-C at bit.ly/apple-objective-c.

You can also develop Web apps for iOS devices.

Find out more about that at bit.ly/ios-web-apps.

For some guidelines concerning how to design your iOS app’s user interface, head over to bit.ly/ ios-interface-guidelines.

You also need the iOS SDK, which you can download after a free registration at developer.apple. com/programs/register.

The only official distribution channel for iOS apps is Apple’s App Store. To be able to submit apps for distribution through App Store, you have to be a registered iOS developer, which costs $99/ year. You can register at developer.apple.com/ programs/ios.

You can read more about Apple’s App Store review guidelines at developer.apple.com/appstore/guidelines.html.

App Dev 101 | www.pcworldme.net/appdev101 | 59

60 | www.pcworldme.net/appdev101 | App Dev 101

Blackberry

App Dev 101 | www.pcworldme.net/appdev101 | 61

RIM pushes WebWorks for BlackBerry, PlayBook development The WebWorks platform lets developers use familiar Web tools to write apps that look native on BlackBerry smartphones and PlayBook tablets

R

esearch in Motion’s BlackBerry WebWorks Application Platform lets developers use standard Web tools to create applications that work like native programs on RIM’s smartphones and PlayBook tablets, company officials said Thursday.

WebWorks, a rebranded version of the BlackBerry Widgets development platform that now uses the WebKit Web rendering engine, was released last September at the BlackBerryDeveloper Conference in San Francisco. On Thursday, RIM returned to San Francisco to give more details about WebWorks, which has been made open source and is available through the open-source development site GitHub. WebWorks is RIM’s first application environment for both smartphones and the PlayBook tablet, which is scheduled to go on sale by the end of March. A beta version of the WebWorks SDK (Software Development Kit) for Tablet OS was introduced last month.

RIM rebranded Widgets to emphasize that it can be used to create entire applications instead of just the small on-screen tools usually associated with widget platforms, said Christopher Smith, senior director of research and development for the BlackBerry Development Platform.

“A WebWorks application is a complete application. It has full access to all the native methods on the device -- all of the data, all of the services,” Smith said. All the security tools and policies on the BlackBerry platform also apply to that app, he said.

“Under the hood, we are actually wrapping the Web engine in a native container,” Smith said.

For BlackBerry smartphones, that wrapper is Java, and for the upcoming PlayBook, it is based on Adobe Flash and Air, he said.

With WebWorks, developers can program in HTML5, CSS, and JavaScript and create applications that are far richer than typical

62 | www.pcworldme.net/appdev101 | App Dev 101

Web-based offerings, said Jeff Jackson, senior vice president of software at RIM. It’s hard to tell the difference between Web and native applications based on appearance or capability, Jackson said. At the event, RIM demonstrated multimedia applications on the PlayBook that were written with the standard Web tools, such as an animation program written entirely in CSS. The company offers WebWorks in addition to its native BlackBerry development environment because many mobile developers don’t want to learn new programming tools to write apps for each vendor’s platform, Smith said.

James Pearce, senior director of developer relations at framework vendor Sencha, agreed with that view and said Web-based tools are a good common denominator.

“The Web is a crazy thing to bet against,” Pearce said.

Using standard Web-based technologies is a smart strategy for RIM, which is unlikely to attract the kind of following that the iPhone and Android platforms have built up among developers, said IDC analyst Will Stofega. It lowers the hurdles to getting into BlackBerry development, which could encourage more developers to write for BlackBerry phones and the PlayBook, he said.

There are more than 19,000 applications in the BlackBerry App World store now, and about 35 million mobile users have downloaded apps so far, with a current rate of about 2 million downloads per day, Smith said. But that pales in comparison to Apple’s iPhone App Store, which has more than 300,000 apps available, and the Android Market, whichapp tracking company AndroLib has estimated at about 200,000. The iPhone App Store recently celebrated its 10 billionth download. AndroLib recently estimated the Android Market has had 2.5 billion downloads.

RIM: Smartphone app builders must know audience Fragmentation in the mobile space has made it imperative for developers to know who their customers are to effectively target them

G

iven the complexities of different smartphone platforms, software builders embarking on an enterprise application project for these systems must know their audience, an official with smartphone maker RIM said Tuesday.

Speaking about best practices in developing mobile applications, Rana Puri, senior wireless application consultant at RIM, cautioned that application developers must be aware of fragmentation in the mobile space, which has resulted in multiple screen sizes, OS versions, and API capabilities: “You need to know your audience. You need to know exactly who your end customer is going to be and this is because the smartphone ecosystem is diverse.” Without this knowledge, developers are guessing on how to proceed, Puri warned the audience at the Software & Information Industry Association’s All About Mobile conference in San Jose, Calif.

Also, Puri emphasized that less is more when it comes to smartphone application development. Knowing why a business process works in a particular manner is useful. A small application that does one thing perfectly is better than a Swiss Army knife-like program that performs seven or eight tasks at a subpar level, he said.

Usability is king, Puri advised: “If your application is difficult to use, people won’t use it.” Simplicity is not a bad thing, and usability includes responsiveness, Puri added.

Performance-tuning also was cited as a critical step that should be at the forefront of a development process. If this task is left till the end of a project, developers risk having to re-architect the application or limit its scope and usefulness, said Puri. They also might hear user complaints about battery drain.

Developers, he said, also must understand the server data and back-end repositories that

will link up with the handheld device. A proper security model also should be vetted prior to development.

Other tips offered by Puri included defining success up front and leveraging push technologies for an application. Deployment and support for applications also are vital. Developers need to ensure that users understand what an application does and how to use it, said Puri, and they need to promote an application.

App Dev 101 | www.pcworldme.net/appdev101 | 63

BlackBerry app developers must make key choices

F

or quite a while, Apple’s App Store for iOS has stood out as the sole example of a smartphone platform that’s more than a fancy way to take phone calls and look at headlines. It showed the promise of mobile devices as real computing platforms that could run some of the applications we run on our PCs, as well as a new class of mobile-savvy, location-aware programs that would redefine the mobile experience. And it provides a lot of entertainment, from fart-noise generators to mood lighting.

So it’s no surprise that every other major mobile device maker has announced its own application store. Research in Motion (RIM) has launched BlackBerry App World store, part of a multipronged battle plan to maximize the number of applications available for its very popular BlackBerry line of devices. (More than 50 million have been sold in a decade, though their capabilities beyond messaging vary widely.) RIM claims more than 140,000 registered BlackBerry developers (Apple’s iPhone had about 200,000 a year ago, at the same stage of the platform’s availability for third-party development), and RIM says that about half of BlackBerry applications are used for enterprise purposes and the other half for consumer applications.

The four options for BlackBerry app development

RIM’s multipronged plan gives developers something to ponder, leaving them with several choices to make on whether to use standardized technologies (such as Eclipse Pulsar, a planned platform for unified mobile app development) or more platform-specific RIM capabilities. RIM has four such methodologies for developers to consider: Using RIM’s proprietary APIs to develop Java applications for only the BlackBerry. The APIs include those to handle touch capabilities as well as device-shifting modes, in which

64 | www.pcworldme.net/appdev101 | App Dev 101

the unit can operate on its side, for example -- iPhone-pioneered capabilities finding themselves into some BlackBerrys.

Using MIDP (Mobile Information Device Profile) and CLDC (Connected Limited Device Configuration) libraries to build cross-platform Java applications. MIDP was not designed for any specific handheld, so developers have to abstract away parts of development, such as use of a trackball. (MIDP has no concept of a trackball, an essential interface element in most BlackBerrys.) But MIDP applications can be migrated to other platforms, says Mike Kirkup, manager of developer relations at RIM. Doing rapid application development using the familiar Visual Studio or Eclipse and leveraging Web services.

Developing Web-based apps for the BlackBerry using the tool of the developer’s choice.

A popular approach for iPhone developers as well, “the downside, of course, is that you have to operate within the existing browser environment,” Kirkup notes, and not use device-specific features.

Java-based applications offer developers the flexibility to configure what every pixel on the screen looks like and makes it easier to tend to networking and local data storage tasks, Kirkup adds. But he acknowledges it is harder to write a Java application than to develop Web or Web-services techniques.

“Anybody who builds any real sophisticated applications for BlackBerry uses the JDE [BlackBerry Java Development Environment].

It gives us a wide range of capabilities,” says Todd Christy, CTO at Pyxys, which builds BlackBerry enterprise applications for financial services and sales. The native application experience on BlackBerry offers the richest set of functionality, he adds.

The BlackBerry platform also offers security benefits for enterprises by leveraging BlackBerry Enterprise Server, through which many companies connect their users’ BlackBerrys to enterprise e-mail and networks, Christy

says: “BlackBerry gives you a secure tunnel into the corporate network.”

How hard is it to develop for BlackBerry?

Developers questioned by InfoWorld cite mostly positive experiences building for the BlackBerry, emphasizing their use of known technologies such as Java and Web services.

But not all.

For example, one mobile application development tools provider complained about the difficulty of developing BlackBerry apps: “It’s actually sort of a pain, not even in just writing the code but getting builds to work,” says Adam Blum, CEO of Rhomobile, which offers a platform for building BlackBerry apps that compete’s with RIM’s platform.

A programmer and consultant familiar with BlackBerry application development also has a mixed review of on how difficult the platform is: “It depends on what you want to develop,” says Peter Wayner. “It’s really pretty simple

to hack together a simple Web services call, something that probably helps many enterprise developers. If you want to go beyond that, it’s just like stringing together widgets and event listeners. It is just like any other Java dev project. The simulator is pretty nice, I’ve found.”

Wayner’s issue is not so much the development platform but the platform on which the apps run. RIM’s interface is not ideal for some of the most physical games, he notes. Some of that is a fact of life in the mobile environment, says Pyxys’ Christy, due to having a small screen to work with, cellular networks that do not always work, and limited battery and memory resources. “There are lots of challenges for any mobile platform, BlackBerry included,” he says.

The Eclipse Pulsar option -- for the future RIM also backs Eclipse Pulsar as a development platform for its mobile device.

Blackberry Resources • • • • • • •

The official distribution channel for BlackBerry apps is RIM’s App World.

BlackBerry apps can also be distributed direct to users as downloads on websites.

Java is the language used to build apps for App World: us.blackberry. com/developers/javaappdev/devtools.jsp.

Eclipse is the toolset that you use to manage your BlackBerry app during development.

You can learn more about Eclipse and download the BlackBerry Java plug-in for Eclipse at us.blackberry.com/developers/javaappdev/javaplugin.jsp For guidelines, downloads and tutorials on building your BlackBerry app look here us.blackberry.com/developers/javaappdev/learningresources To distribute your app through App World you have to register but there is no fee. You can find more information about App World at us.blackberry. com/developers/appworld/distribution.jsp

App Dev 101 | www.pcworldme.net/appdev101 | 65

Tablets expected to clobber PC sales in 2011

Motorola Xoom is one tablet set to arrive in the Middle East in 2011.

It has a 10-inch display and runs Android 3.0 Honeycomb.

M

ove over PC. The Apple iPad and other tablet devices are turning quite a few heads and chipping away at your business.

Gartner said it has cut its forecast for global PC shipments in 2011, largely due to growing popularity of tablets, like the popular iPad, which are diverting traditional PC sales.

Gartner is now projecting that 352.4 million PCs will ship this year, 14.3% more than 2009.

Gartner had previosuly projected that 2010 PC shipments would increase by 17.9%.

“These results reflect marked reductions in expected near-term unit growth based on expectations of weaker consumer demand, due in no small part to growing user interest

66 | www.pcworldme.net/appdev101 | App Dev 101

in media tablets such as the iPad,” said Ranjit Atwal, a Gartner research direct, in a statement. “Over the longer term, media tablets are expected to displace around 10% of PC units by 2014.”

And while George Shiffler, another research director at Gartner, said that PCs will remain a business necessity, market growth will continue to decline -- not only due to tablets.

With the economy still in flux, consumers and businesses remain hesitant to spend money.

Weak employment gains and a “cloudy economic outlook” are keeping purse strings pulled tight, Gartner said.

And with little money to spend on computing devices, consumers and enterprises are more likely to turn to a mobile alternative like tablets or smartphones rather than a traditional PC. “PC market growth will be impacted by devices that enable better on-the-go content consumption, such as media tablets and next-generation smartphones,” said Raphael Vasquez, a research analyst at Gartner, in a statement.

“These devices will be increasingly embraced as complements if not substitutes for PCs where voice and light data consumption are desired. It is likely that desk-based PCs will be adversely impacted over the long-term by the adoption of hosted virtual desktops, which can readily use other devices like thin clients,” he added.

Gartner’s predictions follow last month’s iSuppli projection that worldwide chip sales growth will slow in 2011.

According to iSuppli, lingering economic woes are expected to continue to curtail consumer and enterprise buying. iSuppli is predicting that global semiconductor revenue in 2011 should reach $317.4 billion, up a modest 5.1% from $302.0 billion projected for this year. That’s a dramatic drop from a 32% uptick this year.

THE BACK PAGE

STANDARD PLUG

As far as we’ve progressed in smartphone hardware we’ve moved very little in one particular aspect- plugs and chargers

A

s far as technology has advanced we’re still stuck in the dark ages in one respect and that is all the different chargers and cables we need for all our equipment. From a consumer’s point of view, wouldn’t it make sense to have one charger and plug for all portable computers and one charger and plug for all smartphones, MP3 players, etc?

Especially when I travel I think long and hard about what to bring. Concerning a portable computer it’s not so much of an issue as I usually only have one. But when it comes to smartphone and other smaller gear it gets more complicated.

Thank goodness that some companies and organizations are actually trying to make some sense out of this. Powermat is one company that produces a solution that would allow us to charge without cables - heaven! You just place your device on a particular surface and it charges. There are other companies too offering similar solutions but it’s still a technology under development and in search of a universal standard.

Government is also getting involved.

Not satisfied with deciding how curved a cucumber should really be to be called a cucumber, the European Commission says that standard mobile chargers are coming this year. It has had a project

going for some years now, bringing together major electronics companies like Apple, Motorola, Nokia, RIM, Samsung and Sony Ericsson. The standard it has chosen is Micro USB. This is good news, as it will mean fewer chargers to carry with you and less worry that you’ll have the right plug when you need it. Let’s face it, one good reason to have had a Nokia phone in the past was that there would always be a Nokia 2mm charger around if you had forgotten yours and the phone was dead.

A standardized charger that the major manufacturers agree to means less worry for me on my next trip and that’s good news. I would imagine that there are thousands of readers in exactly the same position.

App Dev 101 | www.pcworldme.net/appdev101 | 67

68 | www.pcworldme.net/appdev101 | App Dev 101