This action might not be possible to undo. Are you sure you want to continue?
Accredited Symbian Developer is an industrystandard qualification for smartphone software developers
The Accredited Symbian Developer examination assesses the capabilities of candidates against a curriculum of core knowledge. The curriculum includes both theoretical and practical topics, assessing both the understanding and application of Symbian C++. Each examination consists of an examinee being asked a subset from a pool of contemporary questions. The questions are weighted and each examinee will be asked questions tailored to the level of ability that they exhibit whilst sitting the examination. Individuals that pass the examination acquire the industry-recognised title ‘Accredited Symbian Developer’. For more information visit www.symbian.com/developer/academy and www.majinate.com
Getting to Market
Getting to Market
part of the Using Symbian OS series
1st edition, 04/08
Published by: Symbian Software Limited 2-6 Boundary Row Southwark London SE1 8HP UK www.symbian.com
Trademarks, copyright, disclaimer ‘Symbian’, ‘Symbian OS’ and other associated Symbian marks are all trademarks of Symbian Software Ltd. Symbian acknowledges the trademark rights of all third parties referred to in this material. © Copyright Symbian Software Ltd 2008. All rights reserved. No part of this material may be reproduced without the express written permission of Symbian Software Ltd. Symbian Software Ltd makes no warranty or guarantee about the suitability or accuracy of the information contained in this document. The information contained in this document is for general information purposes only and should not be used or relied upon for any other purpose whatsoever.
Compiled by: Colin Ward Managing Editor: Ashlee Godwin
Reviewed by: Roderick Burns Antony Edwards Freddie Gjertsen Tanzim Husain Phil Spencer Jo Stichbury Rupert Whitehead
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Commercial-Grade Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Automated and Manual Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Code Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Symbian Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Protecting Your IP: How to Prevent Your Application Being Resold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Internationalizing your Application . . . . . . . . . . . . . . . . . . . . . . . . . .15 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Channels to Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Network Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Building an Application for a Handset Manufacturer . . .19 Independent Software Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Your Own Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Content Aggregators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Freeware, Shareware, and Open Source Software . . . . . .27 Making a Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Internet Access Points (IAPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Promoting your Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Working Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Symbian Partner Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 The Symbian OS Developer Community . . . . . . . . . . . . . . . . . .34 Developer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
So, you’ve worked hard for months and have written the best ever Symbian OS application - let’s face it, we all think our own software is the best ever! Now it’s time to release it. Even if it’s feature complete and the defect tracking system has been emptied of bugs and feature requests, there’s still work to be done. It’s got to be tough and crash proof. It’s got to be fast. It’s probably got to be Symbian Signed. It’s got to have support infrastructure. And most importantly of all, it’s got to reach the widest audience possible. In this booklet, we address these important postdevelopment issues, to help get your application solid, signed, and out to the world.
The cumulative total number of applications for Symbian OS released since Q1 2007
Automated and Manual Testing
On any platform, including Symbian OS, the three most important properties of any piece of software are that it never crashes, it performs well, and is responsive. But how do you achieve this? Due to the nature of a smartphone as a small handheld device with very specific input mechanisms, it’s not always possible to fully stress test an application automatically. Generally speaking, crashes and undefined behavior are more likely to happen when something goes wrong than in the course of the daily successful use of an application. So while it is important to test the most common daily use cases, it is also important to try and think of ways of creating real life problem scenarios and to ensure that the application can handle them without problems. For instance, if the application requires network connectivity, what happens if that connectivity is temporarily lost? Will the application gracefully handle the loss of connectivity and recover, or will it crash or behave in an odd manner? There are two ways of trying to cover these eventualities: • automated testing • good old-fashioned manual system testing. Automated tests can be classified into unit testing and system testing.
3 Unit testing This form of testing splits your application code into discrete, standalone components. The components may be a single class, for example, or a group of interrelated classes with a defined set of very specific functionality. As you write each component, you also create accompanying test code that acts as a client to the component. You can find an example of how to create a basic test harness on the wiki page for this booklet, at developer.symbian.com/getting_to_market_wikipage. Testing should typically be performed as a series of small checks to ensure that various functions provided by the component can be called successfully. It should also try to call these functions in such a way that will actually fail. For instance, to test a component that provides access to data files you could purposely pass in invalid filenames, call Close() without calling Open(), try to read records that don’t exist, and so on. Automated unit tests also have the advantage that if you add more code to the component at a later date, you can run the tests again to ensure that your new code has not inadvertently broken something, which is known as regression testing. System testing As the name may suggest, system testing is about testing all of the components working together. Just because the unit tests pass doesn’t mean that there will not be defects caused by unexpected interactions between components.
4 Unfortunately, automated system testing is not as easily defined as unit testing. You may be able to write an application that pulls in a number of components and tests them working together. This is a great way of testing the interactions between the components and, like unit testing, it can be used to test for regressions when you change your code. However, it may be that writing system tests is as much work as writing the original application, or even more! It boils down to the size and complexity of the application, the number of people on the team, and the amount of time available. For small applications, some unit tests and manual end user testing is enough. For larger applications, the time involved in writing automated system tests will pay off. Manual testing Whatever level of tests are written for automatic testing, on a platform as user centric as a smartphone, old fashioned manual application testing by real people is ultimately the most important of all. There is software available such as TestQuest Pro from TestQuest (www.testquest.com) that can simulate this manual testing by injecting events into the input stream. This can be very helpful, but it suffers the drawback that human beings do the most unexpected things when using an application. You could write the most comprehensive automated tests and extensively test the application yourself manually, but as soon as you put the smartphone in the hands of an uninitiated user, they will immediately do something completely unexpected. For instance, they could open a file, accidentally hit the
5 application launcher button, and then, while trying to get back to your application, accidentally launch another application. Suddenly your code crashes and you are left bewildered because you were convinced it was solid. Since crashes are most likely to happen when something goes wrong, create test cases that make bad things happen. The Symbian OS emulator has a facility for emulating out-of-memory situations; its interface can be accessed by hitting Ctrl+Alt+Shift+P on the PC while the emulator is running. From this dialog, you can make the emulator fail heap allocation attempts in the currently running program. This can be deterministic (i.e., every nth attempted allocation) or random, and can be useful for finding allocation failures that are not handled properly. However, it’s not just memory allocations that can fail, and so this is only one type of test. Attempts to connect to servers, to send messages, to open files, to load resources, and so on, can all fail and/or leave. If they do, how do you know that your class – and indeed the entire application – is going to handle that situation properly? The answer: you don’t! Whenever you finish implementing a class, and it has passed the various automatic tests that have been written for it and is working on the phone, try conducting ‘forced failure testing.’ This can be a fair bit of manual work, but the results are well worth it. ‘Forced failure testing’ analyzes the class that has just been written and then, in any function that can leave, adds some temporary code to force it to leave (i.e., by making a call to User::Leave()). You can compile the temporary code, put it on the device, and run it. If a
6 particular function can leave in three places, test the application’s behavior when it does so at each of those three points in the code. You should do this because it is all too easy to misuse the cleanup stack, to forget to reset variables, or to overlook the paths the code logic takes when an error occurs, and so on. Unfortunately, we sometimes consider the leave mechanism to be something magical that resolves everything and handles failures automatically. However, forced failure testing is necessary to explore how the application will act in the ‘real world’ when a leave occurs.
If you have a budget to spend on tools for testing and improving the quality of your code and your application, then a code coverage tool is also worth consideration. The Bullseye Coverage tool is ideal for generating metrics that give you an idea of how much of your code has been tested. It allows you to focus your testing effort and to pinpoint areas that need review, for example, because the test code has not covered every line of code. More information is available at www.bullseye.com.
Another way to confirm the quality of your code is to perform static code analysis – otherwise known as a code review. You can do this manually, of course, either by checking it yourself or, preferably, by asking a colleague or team mate to review the code and to give you feedback. The Symbian Press Coding Standards booklet (at developer.symbian.com/booklets) can be used as a guideline when performing a code review.
7 If you prefer to automate static code analysis, there are also some tools available – for instance, the Professional and OEM Editions of Carbide.c++ v1.3 ship with a tool called CodeScanner. Running CodeScanner on a project generates a report of the areas where it considers there may be problems, for example: • methods that can leave but are not named with a trailing ‘L’ • descriptor parameters that use pass by value rather than pass by reference • ‘worrying comments’ such as the words ‘hack’ or ‘to do.’ CodeScanner is rather like the Lint tool for C++, but instead of checking for common C++ programming errors, it looks for more specific Symbian C++ ‘gotchas’. The automated source code analysis company Coverity announced in 2007 that it would also be adding support for Symbian C++ to its Prevent SQS static code analysis tool. More information about Prevent SQS is available at coverity.com/html/prod_prevent.html.
Carbide.c++ Professional and OEM Editions ship with Performance Investigator, which is a profiling tool for analyzing the performance of applications running on S60 3rd Edition devices. The tool runs as the application executes and determines which sections of code should be optimized to improve performance, memory, CPU usage, or power consumption. You can find out more about Performance Investigator, and the other tools that Carbide.c++ ships with, from the product page on Forum Nokia, at www.forum.nokia.com/main/resources/tools_and_sdks/carbide _cpp.
Make sure to put your application in the hands of other people for usability testing, especially those who are less technically inclined. The problem with having engineers test applications is that an engineer is more likely to understand how the application works, and to use the application in just the way it was meant to be used. This will not be the case with non-techies, so use them as a testing resource! It’s a fine balance between writing an application to do the right things and its usability – and you need lots of different perspectives to help you get it right.
9 An important thing to keep in mind when it comes to usability is that there are many different styles of phone, and you can’t assume anything about the form factor of the phone on which your application will run. The creators of the platform UIs running on Symbian OS (UIQ and S60) have thought long and hard about usability. Both interfaces address the issues associated with running on multiple devices with different screen sizes, input mechanisms, and key layouts. There is always a temptation to ignore the UI guidelines by thinking, ‘my application is special and the rules don’t apply to me. I’ll make my application look consistent across the platforms.’ Think very carefully before succumbing to this belief, even though the reasoning behind it is understandable. For some application types, such as games, this approach does make sense, but for other applications it is often more appropriate to follow the usage guidelines for the various GUI components that are supplied by the UI. You can find links to the S60 and UIQ guidelines on the wiki site for this booklet, at developer.symbian.com/getting_to_market_wikipage. By following the UI guidelines, you can ensure that your application fits in visually and conceptually with other applications on the device, and that it takes advantage of the research done by the UI vendor regarding device form factors, input methods, and general usability. Remember that both UIQ and S60 phones can work in portrait and landscape modes and that some phone models can dynamically switch between these modes. Symbian smartphones may be pen-based or keypadbased, or both, and you need a strategy for how your application will handle the differences. Make sure you
10 test on a range of devices from each UI platform you are targeting. For example, if you create an S60 application, be sure to test it on both Nokia and Samsung devices. Mobile games As I mentioned above, there is one type of application that is, by its very nature, going to be exempt from the rule of adaptation to the platform UI: the mobile game. Designing a 3D game to run on different devices is less problematic than for 2D games, because 3D graphics are scalable. Even so, handling portrait and landscape mode may still be a challenge because of their very different aspect ratios. 2D games by their nature are not scalable and are therefore more susceptible to device differences.
Screen resolution affects 3D projection and view angle, as shown for a portrait orientation (top) compared to the same graphics for landscape orientation (below). Game images from Snakes Subsonic, courtesy of Nokia, copyright 2008
11 Some larger games companies take the extreme measure of customizing the game for each target phone but this is untenable for smaller companies. Anecdotal evidence suggests that it is common for Java ME games to exist in 600 distinct variants or more, simply to take into account all the permutations of language, input capabilities, and screen sizes that are required to run on the different devices in the marketplace. All that is possible in this situation is to try and design a game from the outset so that it can display more or less of its playing area depending on the screen size, rather than assuming particular dimensions. A scrolling platform game, for instance, that works by displaying a tile-based map, can vary the number of tiles it displays vertically and horizontally without changing the game play dynamic. However, a game that relies on static fullscreen bitmapped backdrops is not going to scale well to different screen sizes. Another aspect to consider when creating your own system for a game is that, by avoiding the system’s input paradigms and mapping actions directly onto keys, you will have to be careful to ensure that those keys are actually present on the device. For example, some UIQ devices do not have four-way controllers, so you may need to map the controller’s actions onto different keys, such as 2 (up), 4 (left), 6 (right), and 8 (down), with 5 doubling as the central selection key. There can also be slight key code variations between manufacturers (and between the device and the emulator), so don’t assume that the input code for each key will be the same on all devices. Try to test on as
12 many models as possible, and on devices from as many manufacturers as possible, or provide the user with a way to set their own choice of input keys.
Signing your application with Symbian Signed is an important part of releasing software for Symbian phones. There are different levels of signing, and which you choose depends largely on the application itself. At the simplest level, if your application does not use any platform security capabilities, or only requires usergrantable capabilities, you may decide not to use Symbian Signed at all. Currently, user-grantable capabilities allow ‘self-signing,’ which means that using Symbian Signed is not essential for installation. However, as soon as you write code that accesses more privileged APIs, you’ll probably need platform security capabilities that require you to sign your application with Symbian Signed. There are several levels of signing available, and so signing an application can actually be quite an in depth subject, far beyond the scope of a small booklet such as this. Up-to-date information on Symbian Signed can be found at www.symbiansigned.com, or in ‘A guide to Symbian Signed,’ which can be downloaded from the Symbian Signed website.
Protecting Your IP: How to Prevent Your Application Being Resold
This is a complex problem, and there is no single or instant solution to it. Different approaches are appropriate for different applications and business models. Sometimes the effort required to protect your software may not be worth it, and it’s better just to release your software and rely on people’s honesty. Alternatively, try to come up with a business model where copying the application is actually a good thing. However, if you really do feel the need to prevent your software from being freely copied, then there are a few ways of going about it, but the important thing is to make purchasing an application as simple as possible for the user. SMS Activation One popular way to protect your software is to use an activation SMS. The user sends a one-off SMS to a particular SMS number, and an SMS is sent in reply to activate the software. This can also be a handy way of letting the user pay for the use of the software, by setting up a premium SMS number. It also has the advantage that if the user changes phones, then they can resend the activation SMS to the server, which can detect that the phone’s number is already in its database and re-activate the application without recharging the user. However, even though this is a useful approach, it does have some disadvantages: • you need an SMS gateway, which is going to cost money to set up
14 • by setting up an SMS gateway, you may be restricting the number of countries a user can register from • if the user changes phones and phone numbers, the re-activation will not work and the user will have to purchase a new copy of the application. Using an Authorization Server Another way of authorizing an application is to require it to connect to a server, either from code within the application, or by launching the phone’s web browser with a URI. You can then download a token associated with the phone’s IMEI that authorizes the application for use. The problem with this is that you need to set up a server with a database that can store a list of IMEIs and record the fact that they are registered. It also depends on the user’s phone having Internet access, which cannot be guaranteed. In addition, if the user gets a new phone, then he or she won’t be able to download the application from the server again, since it will consider the new phone (with its different IMEI) to belong to a new customer. Selling the Application Over the Internet This approach requires users to use a PC to log on to a website to purchase the application. This poses a difficulty in that you need to find a way of associating an application bought on a PC with a particular phone. A good way of doing this is by using the IMEI of the phone. However, users don’t necessarily know about IMEIs, and it’s not very user friendly to expect them to type in this long, arcane number, ascertained by first
15 typing in the *#06# code as they would a phone number. Furthermore, you cannot guarantee that the user will know how to install the SIS file from their PC once they have it. It also restricts how you distribute your application. Unfortunately, all methods of registering applications for mobile phones have their drawbacks, and it is up to you as an author to choose the method that best fits your software.
Internationalizing your Application
Internationalization is by no means mandatory, and if you target your application at just one country where just one language is spoken, then it might be unnecessary. However, when targeting multiple markets, Symbian OS has powerful support for internationalization. There is an easy method for creating SIS files that support multiple languages. One language (usually English) will be used as the default language, but other languages can be included in the SIS file in the form of resource files. Upon installation, if the phone is set to a language other than English then the appropriate nonEnglish resources will be installed and the application will operate in that language. If no resource file is found that matches the language that the phone is set to, then the default English resource file will be installed. Internationalization generates software variants in multiple languages from a single set of source files. Typically, you’ll aim to have a core of code that contains all the functionality of your application and doesn’t change regardless of the language. A second part
16 contains the changing content, such as text strings displayed in the UI. Not only do you need to consider the differences in language when you internationalize your application, but you’ll also have to consider variations in writing systems, regional differences (such as layout of numbers, time, or measurements), and specific customizations. Symbian OS provides support for the localization of dates, numbers, currency, and so on, with the useful TLocale class. You can find out more from the Symbian Developer Library of the SDK (look for the Locale Settings guide in the Base section of the Symbian OS Guide).
Channels to Market
Like so many things about smartphone programming, there are no firm rules for getting your application to market. As a developer, you need to think about the nature of your application, the end user of that application, and your customer, which may be the end user or it may be a network operator or another large company. Network Operators Using network operators as a channel is a good approach as they have a large customer base, often brand devices with their own signature applications, and also offer other applications for download from their portals. Working with the network operators does have its downsides though:
17 • Network operators are notorious for taking a long time to hammer out deals; expect 18 months from when you first approach them to when your application gets onto a portal, although this will vary depending on the operator. • Application signing and testing by an independent test house usually becomes mandatory, and this means additional work, which can be expensive, especially for small companies. • If you decide to use this method exclusively, then it means that you are limiting your audience, because if a user finds out about your application and isn’t with one of the network operators you have collaborated with, then they won’t be able to obtain it. • You will probably have to negotiate a deal with multiple operators, and may find that you have to renegotiate with the same operators in different countries. Ultimately, using operators is a good approach, but be prepared for lots of negotiating and the fact that you will be one of many companies trying to convince them that your application is the best. Network operators look for applications that meet their own propositions, and one key goal is to promote data consumption. If your application requires the user to download even small amounts of data on a regular basis, the network operators will find it far more interesting than one that never requires the user to make a data connection. You can find out more about the other 'hot' areas that operators are keen to promote by listening for key messages whenever the operators speak at developer events (more about these in The Symbian OS Developer
18 Community section later in this booklet), or when they issue press releases or other material to help analysts ‘sync up.’ Some network operators run specific events that provide the opportunity for you to promote your application to them. At such events you get to present your product to representatives of the company in a very short space of time, to explain why it should be made available as one of their signature applications, or for download from their portal. If you can’t get to such an event, it’s worth joining partnering programs, such as 3neXt from Hutchinson (next.three.com/suggest/developer.aspx), Orange Partner (www.orangepartner.com), or AT&T devCentral (developer.att.com). The operators research the market and if your applications are receiving good feedback from users, or the operators have access to download statistics and see that you have a popular product, you may be invited into a tendering process in order to be selected to supply applications to them. However you get noticed, once you have negotiated the deal with the network operator, you are probably guaranteed revenue from each copy of the application that is sold. The downside of this approach is that the operators will take a certain percentage of the revenue for themselves, although this amount will vary from operator to operator. Further details of application developer programs can be found on the wiki site for this booklet, at developer.symbian.com/getting_to_market_wikipage.
19 Building an Application for a Handset Manufacturer Like working with operators, this is another approach that can bring your application to the attention of a large number of people. Also like working with operators, it’s hard work. The ultimate prize here is having your application included in the ROM of a phone. This will mean that you have a potential audience of millions. However, it’s a tough thing to do because being embedded in ROM means using ROM space, and this means cost to the phone manufacturer. It also results in extremely high visibility on the phone, and so the application has to be exceptional. Unless you are a comparatively serious player in the industry, with a unique application, it is going to be hard to convince a manufacturer to put your code in their ROM. If you do manage to do this, this may lead to further time-consuming activities and problems: • The phone manufacturer will be very fussy about application quality, and you can expect to go to a lot of effort to ensure it. • You will often have to work with pre-production hardware which can be challenging, and which presents a number of logistical problems. For example, in the final stages of the project, you may have to spend a significant amount of time working on the manufacturer’s site. • You may have to send off builds of your code for the manufacturer to build into ROM and test, and all you get back is the results, which can make debugging very difficult.
20 • On top of all of this, the manufacturer will enforce extremely strict quality controls that mean you can spend an awful lot of time following processes pertaining to testing and documentation. A more realistic approach is to get included on the CDROM that is distributed with mobile phones. Because these applications are optional and are on a CD-ROM, they are less risk to the manufacturer and do not have the problems of using ROM space. Although it seems far less impressive to be on a separate, optional CD-ROM, it’s still quite a big win. Remember that smartphone users are often enthusiastic about what ‘freebies’ are on the CD-ROM that comes with their phone. You will still have to do the work to convince the manufacturer to take your application and, of course, application signing and testing by an independent testing house will be mandatory. Just as with negotiating a deal with network operators, the effort is worthwhile because it creates the potential to ship a very large number of copies of your application. This is a curious approach in a way because the number of copies of your application shipped will depend more on the popularity of the phone it is shipping with than the popularity of your application! It is important, therefore, to consider the phone with which the application will ship, its importance to the manufacturer, and therefore how well it will sell, as this will affect how you negotiate the license. You can either try to negotiate for a royalty per unit or for a one off payment. Both the popularity of the phone and the manufacturer you are dealing with will ultimately affect which option is chosen.
21 Symbian’s partner program, discussed later in this booklet, may be a good place to begin networking and to gain introductions and contacts within the network operators and phone manufacturers. Often, the manufacturers have their own partner programs, such as Forum Nokia Launchpad (pro.forum.nokia.com) or Motorola’s MOTODEV (developer.motorola.com). These are good places to promote yourself and to find out what others are working on. Independent Software Channels Some mobile application sales channels are independent of network operators. These channels sometimes have less traffic than the operator channels, but application developers still find they offer potential for application distribution. There are a number of channels that provide mobile applications; some do so as part of their wider offering, while others specialize in them. Examples include Cellmania, Handango, Handmark, MobiHand, Motricity, and SymbianWare. The channels may offer a mobile website for buyers to browse, allowing the purchase of applications by direct download over the air (OTA), with payment made by means of sending a premium-rate SMS or the more traditional credit card approach. Other vendors may offer an additional website for purchasing applications over the Internet (OTI) onto a PC and then transferring the application to the phone and installing it. However, some network operators may lock down their phones against what they call ‘side loading,’ which
22 means that applications cannot be installed except by direct download to the phone. The lock down ensures that the operator retains some profit from application installation, even when it is not purchased from one of their portals. (Some network operators go further still and prevent the phones they distribute from making purchases except from their portals.) Thankfully, this is not currently a widespread practice, though it is very common in Japan. Some phone manufacturers also provide sales channels, such as the Nokia Software Market. These channels are a way for manufacturers to make software available and encourage the uptake of their handsets. Rather than decide themselves what these sites provide, the channels often use the services of a content aggregator, such as Jamba! (also known as Jamster in English-speaking regions), to put together the content offered. The Nokia Software Market is available for users to buy applications OTI (www.softwaremarket.nokia.com) or directly on the phone using an application called Nokia Catalogs. The Catalogs application is a client on the Nokia Content Discoverer system and is available for S60 smartphones, allowing users to browse the applications available online using their phones, and to download and install them. The application supports both the downloading of demo applications and full commercial versions, and allows delivery of graphics, themes and ring tones, Java ME applications, native Symbian C++ applications, videos, music, and content developed using Flash technology. Similar concepts exist for UIQ phones, many involving the same channels as those used by the Nokia service.
Nokia Software Market: www.softwaremarket.nokia.com
Independent channels are usually the preferred route to market for application developers working alone or in small companies, because it is easier to place an application for sale with the channel than to forge a relationship with a network operator or content aggregator. The channel will take a percentage of each sale of the application, but this is typically less than a network operator or aggregator, and the channel will allow you to set the price of the application yourself. For example, the Nokia Software Market takes 40% of the sales price you set, with revenue paid every quarter. For more information about working with the Nokia Software Market and Catalogs application, please see www.forum.nokia.com/main/software_market, or consult the Nokia Sales Channels section on the main Forum Nokia developer site at www.forum.nokia.com.
24 The channels often re-skin their application catalogs for operators, so by distributing through the independent software channel, you can find your software gains more visibility by operators and may then be easily distributed in other re-branded channels. Your Own Channel This is an approach to distribution that can potentially be a lot of work. The main thing here is that you are going to have to set up the infrastructure for distribution. A website and download mechanism (preferably with two sets of web pages - one for use on a mobile phone and one for use on a PC) are easy enough, but setting up a credit card or another payment system will take some more work. Not only this, but if your company is small and not well known - and this is often the case in the world of Independent Software Vendors (ISVs) - then people are not necessarily going to trust you with their credit card details. In this case, it may be a good idea to outsource taking payments to a well-known and trustworthy company that specializes in this. Users will feel far more confident using a service such as PayPal than a small, unknown company. The big advantage of this approach is that you get to keep closer to 100% of the download price for yourself. Some good examples of mobile game companies who have set up their own channels include ZingMagic (www.zingmagic.com) and Astraware (www.astraware.com). You can find a link to a presentation from Astraware, about how to engage with your customer through your own online portal, on the wiki page for this booklet (developer.symbian.com/getting_to_market_wikipage).
25 Content Aggregators Content aggregators are specialists at gathering content, such as mobile applications, video, and ring tones. The content is acquired from suppliers such as games publishers or independent channels, and distributed by the content aggregators to their sales channels. Content aggregators provide an easy way for businesses to source downloadable material without having to seek it out and build a relationship with each supplier. Working with content aggregators is a good approach for smaller ISVs that do not have the budget for approaching operators and manufacturers. It has many advantages. Depending on the aggregator, they may not have the strict signing and testing requirements of the operators and manufacturers. They also won’t take so much convincing to promote your application. After all, the more applications they have available, the more money they stand to make! As specialists in application distribution, they have the required infrastructure and you can use this to your advantage. The ability for people to pay for and download your application is taken care of for you. There is also the advantage that your application has a large audience, even without any advertising. Enthusiastic smartphone users will surf to these sites to see what interesting applications have been launched recently.
Handango (www.handango.com) acts as a content aggregator as well as an independent software channel
The disadvantage of using a content aggregator is that, depending on your application, it may be lost in the crowd. A user will come to an aggregator and do a search for a particular type of application (for example, an email client) and as well as your application appearing in the search results, so do a number of applications created by your competitors. The user is likely to choose one at random. To make it stand out, you have to differentiate your application from its competitors, and I recommend the following approaches: • Give the user lots of information about the application. At the minimum, a website linked from the application download page on the aggregator is a must. • Have lots of screenshots to show that your application looks (and is) better than your competitors’.
27 • Use a name that clearly defines what your application does, rather than a more esoteric one, and use a clear description of your application that will ensure that a user finds it when searching. This approach is still somewhat hit-and-miss because the number of people that will download and buy your application is an unknown. Will people even be looking for your application? Will they know it exists? If it is innovative enough, you may be able to negotiate for it to be displayed on the front page of the aggregator’s site. Ultimately, the amount you will earn from this approach depends on the number of people who download and buy your application. The download price will usually be split between you and the aggregator. Forum Nokia publishes a comprehensive list of mobile content aggregators at www.forum.nokia.com/main/go_to_market/aggregators.html.
Freeware, Shareware, and Open Source Software
You can release freeware applications as self-signed SIS files if the capabilities your application requires are in the ‘User Grantable’ set or if your application does not use any capabilities at all (see wiki.forum.nokia.com/index.php/Capabilities for more information). However, those applications that require more advanced capabilities must be Symbian Signed. If you decide to distribute your freeware and need to get it Symbian Signed, you will need to purchase a Publisher ID and follow the Express Signed or Certified Signed route. Alternatively, you can distribute your application using
28 ‘test range’ UIDs and allow users to sign the file using Open Signed Online through the Symbian Signed website.
A breakdown by sales type of the applications for use on Symbian OS smartphones, from Q1 2007 to Q1 2008
Making a Demo
You may decide to make a demo of your application available, because some users may not want to buy an application that they have not tried. Preferably, the demo application should be unlocked with a code, to make it easier for users to purchase and run the full application. Otherwise, they would have to go to the effort of paying for it and then downloading the full version of the application, which may also incur an extra data charge if they do it OTA. How to limit the demo is up to personal preference and the type of application, and there are various options available. You can, for example:
29 • give it a time limit, either limiting its use to a certain number of minutes per use, or a certain number of days from installation • limit the number of times it can be executed • reduce the functionality of the application, for example, by preventing the player from saving the level they have reached in a game. Whichever method you choose, ensure that you give the user a decent taste of the application. If the demo is too restrictive and doesn’t give the user enough time to explore the application, it won’t hook them in and they won’t buy it. At the same time, if you give them too much time to use it, then it isn’t worth their time to buy the full version.
One thing that all of the distribution methods have in common is that you are going to have to set up some sort of support channel. If you are lucky and have a deal with a large company they may handle this, especially if they have licensed your application and branded it themselves. Even then, they will often insist that you have a support site. Again, this means infrastructure - a web server with some sort of forum software running on it is a good start, and definitely a firstname.lastname@example.org email address that is checked regularly and is responsive. Whatever your application, users are varied and have a wide range of skill levels. Some will download your application and won’t know how to get it onto their
30 phone. Others will find defects and will need to be able to tell someone in your company about them - and they will expect something to be done about them! This brings us to the next point - make sure that you have someone on hand with good communication skills that can monitor the forums or the support email address and ensure that users are helped out in a timely fashion. There is nothing more frustrating than posting a message on a company’s support forums and not getting an answer. You can benefit from this interaction with your users. When users report a defect and you fix it, your application benefits; it’s like having an enormous Q&A department at your disposal.
Internet Access Points (IAPs)
There is one particularly painful area of support that is specific to the smartphone industry and it is difficult to address it, although thankfully it doesn’t apply to all applications! It applies only to those that require access to the network, and it concerns IAPs. IAPs have been set up by the smartphone industry so that you can have WAP access points, where you can only access servers on port 80 (often through a WAP gateway), and generic TCP/IP access points, where you can access servers on any port. When a user gets a new phone, one, both, or neither of these IAPs will be set up. Each network operator will have a different mechanism for configuring them and, on top of that, they are often given names that do not necessarily reflect their purpose. Even an expert can have trouble setting up their IAPs, and an average user could well find it virtually impossible.
31 Even worse, as a company based in one country, you may get support emails from users in a completely different country who need help with their IAPs. Have you ever tried figuring out how to get working IAP details for TCP/IP in a northern Indian state, or a country in South America? It’s not easy! The support person will need to be someone with patience, and you can expect quite a few emails sent in either direction before the user’s IAP is up and running. Network operators are addressing these problems and often a phone will configure itself when you insert a new SIM card. However, you will almost inevitably encounter this problem at some point if your application needs to access the network.
Promoting your Application
This really is important - how will people use your application if they don’t know that it exists? Like many things in the mobile phone industry, there isn’t a hard and fast answer to this, and how you approach this will depend on a number of factors. How big is your company? Do you have partners? Do you have an advertising budget? Is the application complex or simple? Who is the target? Many ISVs developing for Symbian OS are smaller companies partnering with larger companies. This is a nice way of working because you can concentrate on the application and, once it is delivered to the partner company, they will take care of its promotion. Even when using this approach though, it’s good to write a
32 press release. Because the smartphone industry is young and exciting, news about an interesting software release will travel fast, and enthusiastic websites will do some of the hard work for you! Setting up an appropriately sized stall at an industry tradeshow such as Mobile World Congress or the Symbian Smartphone Show is another way of getting some attention for your application. People from all parts of the industry will come by, ask you questions, and play with your application. If it’s good, word will get out. Another way of using the industry’s enthusiasm is to send press releases to the various Symbian news sites, such as developer.symbian.com, www.allaboutsymbian.com, www.my-symbian.com, and www.symbianone.com. These sites are always looking for exciting new applications and news on Symbian to post on their front page and to promote in their newsletters. If you have an advertising budget, then taking out a banner ad on these sites or ads on Google is another approach.
Symbian Partner Network
Strong relationships can deliver strong results. The Symbian Partner Network comprises the top technology innovators across the world and provides exclusive access to the resources and tools necessary for the development, sales, and marketing of solutions on Symbian OS. The program is designed to deliver maximum success to both Symbian OS licensees and members of the Partner Network. Members of the program benefit from: • Symbian OS Binary Access Kit • access to SDN++ (our world-class developer portal) • exclusive use of the Symbian Partner logo
34 • their company profile made available on the Symbian Partner Network Directory • exclusive webcasts and roadmap information • exclusive events, for example, the annual Symbian Partner Event, regional showcases, and licenseefocused events • exclusive discounts, for example, for Symbian Press products and the Symbian Smartphone Show • access to demo codes • access to Symbian technical support services from the Symbian 1:1 team • co-marketing opportunities, where appropriate. The Symbian Partner Network provides all of the tools and resources to enable you to develop and market commercial applications using the BAK and Symbian OS APIs. Access to the Symbian OS Development Kit, which contains Symbian OS source code and advanced access to new features, is only available to Symbian Partner Network members. In addition, Symbian Partner Network members have exclusive access to Symbian’s technology validation program, Symbian Ready. For more information about partnering with Symbian visit: www.symbian.com/partner.
The Symbian OS Developer Community
Symbian OS Developer Community websites are a very important resource, both from a technical programming point of view and as a way of making your presence known in the developer community. Sign up for the Symbian Developer Network at developer.symbian.com
35 and - depending on your target smartphone platform register with the Forum Nokia, MOTODEV, Sony Ericsson Developer World, and UIQ Developer Community websites (you can find links to each of them on the Symbian Developer Network). Most of the developer communities have newsletters, so sign up for these as well to ensure that you are informed of upcoming trade shows and developer days - attending these is vital to getting known and involved within the community. They are a great way of meeting customers and your peers, and of getting contacts within manufacturers. If you are bright and enthusiastic then you will quickly find yourself meeting, and being noticed by, the right people. In the mobile industry, support comes from large companies in informal ways just as much as from the more formal approaches, so it pays to get yourself known. Trade shows and developer days can be a fun social event as well, often with free food and drink. After all, developers make a big contribution to the popularity of Symbian smartphones, so we want to woo them! If you need to solve a problem, there are community forums to post on and additional routes to finding out what you need by using direct technical support. The latter generally tends to cost money, and for a small business is often considered too expensive to use frequently. The biggest benefit to these is that they are great time savers. When you have a problem and post a message on a forum, then it is really luck as much as anything
36 whether you receive an answer. If you use paid technical support, there are guaranteed response times, and guaranteed answers. Your support engineer will be a specialist who has access to everyone within the organization, so no matter how difficult your problem, they will be able to ask the right questions of the right people and get you an answer.
Symbian Developer Network developer.symbian.com Symbian Developer Network newsletter developer.symbian.com/register Symbian OS Tools Providers developer.symbian.com/main/tools
Forum Nokia forum.nokia.com MOTODEV developer.motorola.com Sony Ericsson Developer World developer.sonyericsson.com Sun Microsystems Developer Services developer.java.sun.com UIQ Developer Community developer.uiq.com
New books from
Games on Symbian OS: A Handbook for Mobile Development
This book forms part of the Technology Series from Symbian Press. It describes the key aspects of the mobile games marketplace, with particular emphasis on creating games for smartphones based on Symbian OS v9.x.
Developing Software for Symbian OS, Second Edition
This second edition of Developing Software for Symbian OS helps software developers new to Symbian OS to create smartphone applications. The original book has been updated for Symbian OS v9 and now includes a new chapter on application signing and platform security, and updates throughout for Symbian OS v9 and changes to the development environment. Symbian Press: developer.symbian.com/press
New books from
Symbian OS Communications Programming, Second Edition
Targeting Symbian OS v9.1 and v9.2, Symbian OS Communications Programming - Second Edition will introduce you to the major communications functionality in Symbian OS and demonstrates how to perform common tasks in each area.
Symbian OS C++ for Mobile Phones, Volume 3
This book will help you to become an effective Symbian OS developer, and will give you a deep understanding of the fundamental principles upon which Symbian OS is based.
Symbian Press: developer.symbian.com/press
Books also from
The Symbian OS Architecture Sourcebook
This book conducts a rapid tour of the architecture of Symbian OS and provides an introduction to the key ideas of object orientation (OO) in software, with a detailed exploration of the architecture of Symbian OS.
Fully up to date for Symbian OS v9 and S60 3rd Edition, S60 Programming is an essential foundation to developing software for Symbian OS. This practical book is based on the authors’ experiences in developing and teaching an academic course on Symbian software development.
Symbian Press: developer.symbian.com/press
Books also from
For all Symbian C++ developers:
Symbian OS C++ for Mobile Phones – Volume 1 by Richard Harrison Symbian OS C++ for Mobile Phones – Volume 2 by Richard Harrison Symbian OS Explained by Jo Stichbury Symbian OS Internals by Jane Sales Symbian OS Platform Security by Craig Heath Smartphone Operating System Concepts with Symbian OS by Mike Jipping Accredited Symbian Developer Primer by Jo Stichbury & Mark Jacobs
Booklets also from
Coding Standards Coding Tips Performance Tips Getting Started Java ME on Symbian OS P.I.P.S Carbide.c++ v1.3 Data Sharing Tips Essential S60 - Developers' Guide Essential UIQ - Getting Started Ready for ROM
Translated booklets available in:
Chinese Japanese Korean Spanish Russian
Getting to Market
Why? What? Where? How?
In this booklet, we address the most important post-development issues (such as preparing your software for commercial release, distribution, and promoting your application) to help get your application solid, signed, and out to the world. Getting to Market is part of the Using Symbian OS series, designed to provide information in a handy format to Symbian OS developers.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.