quick_recipes (779892), страница 60
Текст из файла (страница 60)
You will also find usability much easier to determine, andsome code will only work on hardware anyway, such as that using theaccelerometer or camera APIs. Make sure you test on a range of devicesfrom each UI platform you are targeting. For example, if you create anS60 application, be sure to test it on both Nokia and Samsung devices.Static AnalysisThe Professional and OEM Editions of Carbide.c++ v1.3 ship with a toolcall CodeScanner, which is a static code analysis tool. While you cannotautomate a code review entirely, you can use static code analysis torun through code to detect areas where potential problems may lurk, forexample:• Methods that may leave but are not named with a trailing ‘L’.• Descriptor parameters passed by value rather than passed by reference.• ‘Worrying comments’ such as the words ‘hack’ or ‘to do’.The automated source code analysis company Coverity announced inlate 2007 that it will also be adding support for Symbian C++ to its PreventSQS static code analysis tool.
The Symbian C++ checker is expected tobe available soon, and more information about Prevent is available atwww.coverity.com/html/prod prevent.html.6.1.3 Optimize It!Before releasing your code, it is worth taking some time to considerwhether it is as efficient as it could possibly be. For example, Carbide.c++Professional and OEM Editions ship with Performance Investigator, whichis a profiling tool for analyzing the performance of applications runningon S60 3rd Edition devices. The tool runs as the application executes andit can be used to determine which sections of code should be optimizedto improve performance, memory, CPU usage or power consumption.You can find out more about Performance Investigator, and the other toolsthat Carbide.c++ ships with, from the product page on Forum Nokia, atwww.forum.nokia.com/main/resources/tools and sdks/carbide cpp.Sometimes there are a few simple adjustments that can make adifference to its performance.
A number of these are summarizedin the free Performance Tips booklet published by Symbian Press atdeveloper.symbian.com/main/learning/press/books/pdf/PerformanceTips.pdf, which examines a few performance killers (such as inefficientheap usage, repeated code within loops and over-enthusiastic ‘futureproofing’ of code) in detail, and summarizes a number of other quick tips.334RELEASING YOUR APPLICATIONIt is important to understand the basics of the compiler you areusing. Modern compilers contain a number of optimization phases whichproduce smaller or faster code, depending on the chosen settings. It isimportant to understand the consequences of some of the settings andhow they affect the code produced.
If you understand how the code isgenerated by your chosen compiler, you can avoid working against it. Forexample, you can avoid writing code that is too prescriptive and forcesthe compiler to generate code in a particular way, rather than allowing itto optimize it.When writing application code for Symbian v9 platforms, you can usethe free GCC-E compiler, supplied with your chosen SDK, to build codethat runs on a phone. More information about the compiler is availableat gcc.gnu.org/onlinedocs/gcc.The RVCT CompilerWhile the free GCC-E compiler produces EABI-compatible binaries thatcan be used for Symbian OS v9 application development, it cannot beused when developing code that runs kernel-side (such as device drivers).Developers working within Symbian, and in Symbian’s licensee or partnercompanies, opt instead to use the Real View Compilation Tools (RVCT),available, at a charge, from ARM.In fact, if you want optimal code, when compared to GCC-E, theRVCT compiler binaries give better performance and smaller binaries.
See www.arm.com/products/DevTools/RealViewDevSuite.html formore information about RVCT, the versions used to build Symbianprojects and how to acquire a license. RVCT is available to Symbian’sPartners at a special discount – partnering with Symbian is discussed inmore detail later in this chapter.6.1.4 Protect It!Protecting your IP, to prevent your application from being resold, is acomplex problem and there is no single or instant solution to it. Differentapproaches are appropriate for different applications and business models.Sometimes the effort required to fully protect your software may not beworth it, and it is better to just release your software and rely on people’shonesty. However, if you really do feel the need to prevent your softwarefrom being freely copied, then there are a few ways of going about it. Inall of them, the important thing is to make purchasing an application assimple as possible for the user.SMS ActivationOne popular way to protect smartphone software is to use an activationSMS.
The user sends a one-off SMS to a particular SMS number, and anWHAT TO DO BEFORE YOU RELEASE YOUR APPLICATION335SMS is sent in reply to activate the software. This can also be a handyway of letting the user pay for the use of the software, by setting up apremium SMS number.It has the advantage that if the user changes phones, then they canresend the activation SMS to the server, which can detect that the phone’snumber is already in its database and reactivate the application withoutrecharging the user.However, although this is a useful approach, it does have somedisadvantages:• You need to pay to set up an SMS gateway.• By setting up an SMS gateway, you may be restricting the number ofcountries from which a user can register.• If the user changes phones and phone numbers, the reactivation willnot work and the user will have to purchase a new copy of theapplication.Using an Authorization ServerAnother way of protecting a smartphone application is to require itto connect to a server, either from code within the application, or bylaunching the phone’s web browser with a URI, on the first use.
You canthen download a token associated with the phone’s IMEI that authorizesthe application for use.The problem with this is that you need to set up a server with adatabase that can store a list of IMEIs and record the fact that they areregistered. 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 serveragain, since it will consider the new phone (with its different IMEI) tobelong to a new customer.Selling the Application Over the InternetAnother approach is to require users to use a PC to log on to a website topurchase the application. This poses a difficulty in that you need to find away 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 is not very user friendlyto expect them to type in this long, arcane number, ascertained by firsttyping in the *#06# code as they would a phone number. Furthermore, itcannot be guaranteed that the user will know how to download and installa SIS installation file from their PC once they have it, and it also restrictshow you distribute, and how the user purchases, your application.336RELEASING YOUR APPLICATIONUnfortunately, each of the methods described has drawbacks, and it isup to you to choose the method that best fits your software.6.1.5 Sign It!Signing is the process of encoding a tamper-proof digital certificate into anapplication.
The certificate identifies the application’s origin, and grantsaccess to those APIs that are protected by Symbian OS platform securitycapabilities. Protected APIs are those that allow sensitive operations, suchas those that may potentially:• access the end users’ private data, thus breaching their privacy;• create billable events, thus costing the end user money;• access the mobile phone network, which may affect its operation;• access handset functions that can affect the normal behavior of thephone;• impact the performance of other applications running on the phone.If you don’t use any protected APIs, you may find it possible to avoidthe signing process altogether. Approximately 60 % of Symbian OS APIsrequire no capability to use them, so it may be possible to take thisapproach if you are creating a fairly simple application.Alternatively, where certain capabilities are required, you may be ableto rely on the user to grant permission to the application at install-time(called ‘blanket’ permission), or at runtime (‘single-shot’ permission).For example, the user can accept a request to send a message whenthe application needs to do so.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
