Symbian OS Communications (779884), страница 45
Текст из файла (страница 45)
This allows you to placeoutgoing calls from your application – for example if you are providingsome sort of directory application, such as Yellow Pages, and wantedto allow users to place a call to a company directly from their listing. This is particularly effective in cases where the calls are madeon an outgoing basis only, as no integration with the built-in contactsdatabase is necessary. It also has the benefit of allowing many numbersto be stored in an application’s own local database rather than cluttering up the user’s main contacts database. However, in the case wherean incoming call is received, this solution won’t be as user friendlybecause the phone number-to-name matching takes place against theuser’s main contacts database, so will not match entries in the application’s local database.
The UI does not need to handle the call if theapplication does not run in the foreground the native phone app willhandle it.The second main area of interest is detecting incoming calls. Theremay be a several motivations for this – we’ll cover just two. If we arecreating an application that uses audible output, it is useful to detectincoming calls so that we can suppress our audio output whilst the useris on a call. It is also useful to detect when the call has been terminatedto allow us to re-enable our audio output. The other reason for detectingincoming calls is to allow us to implement such applications as videoringtone engines, where we may wish to play a video clip when anincoming call is detected.Other interesting things that can be done using the ETel ISV APIinclude:• Monitoring the current cell ID, for example to use as a location ingames – some games could require you to return to a specific locationin order to complete a task – bringing some element of real-life spaceinto the game.• Checking whether the user is roaming or not, and modifying certainaspects of application behavior – for example, reducing the rate atwhich scheduled information retrieval is performed using the networkto reduce costs to the user.• Using the IMEI or IMSI to create a very basic ‘locking’ schemefor your application to prevent casual copying – we discuss this insection 7.2.2.208TELEPHONY IN SYMBIAN OS7.2.1 Example ApplicationThe functionality of the ETel ISV API is exposed through CTelephony.
Among other functionality, this provides access to the followinginformation:• The Subscriber ID, also known as IMSI, which uniquely identifies yourICC (aka SIM card).• The Phone ID, which comprises the manufacturer, model and a serialnumber (a.k.a. IMEI).• The network registration status.The example application will retrieve all this information, and alsorequests to be notified of changes to the network registration status.ImplementationAs is traditional in Symbian OS development, the application has beensplit in two – an engine and a UI, to allow reuse of the engine withmultiple UIs. Figure 7.2 shows the high level design of the application.The engine is a container for the active objects that are used to calland wait for the completion of the CTelephony asynchronous methods.CGetter retrieves information from the phone using the getter methods on CTelephony. We use two of them: one for the subscriber IDcontained in the CTelephony::TSubscriberIdV1 package; and onefor the IMEI contained in the CTelephony::TPhoneIdV1 package.When started, they will place a request on CTelephony.
Their RunL()notifies the engine of the completion.Their functionality has also been extended to create CObservers,which also notify the application of the change in this information – ourapplication uses one of these to retrieve the network registration status.Dial will also take a TCallparamV1 argument, which specifies whetherthe caller identity (your telephone number) should be sent to the remoteuser.MNotifyCAppView1...1CActiveCPhoneEngine1…*1…*1...1CInformerCGetterCDialerCTelephony*CTelephony*CTelephony*Figure 7.2 High-level design of the telephony applicationUSING THE ETEL ISV API209Please note that on UIQ you can use DNL (Direct Navigational Link),which will call into the phone app to dial a call. I would recommendthis solution to using CTelephony because of its simplicity and its goodintegration with the phone application.The requests are made by calling the member functions of the application’s CPhoneEngine , which dispatches the request to the appropriateactive object.
It is also the engine’s responsibility to handle the processingof the data such as the matching of the unlock code coming from the UIto the unlock code generated using the IMEI of the device. Not only doesit make it safe but it reduces the need to make UI variants modifications.The UI takes commands from the user and displays their results.The notifications from the engine are made via an abstract classMNotify that the UI implements.class MNotify //interface to the UI{public:virtual void DialCompleteL(TInt aError)=0;virtual void VerifyIMSICompleteL(TInt aError, TDesC& aIMSI)=0;virtual void VerifyIMEICompleteL(TInt aError, TDesC& aIMSI)=0;virtual void UpdateNetworkRegistrationStatusL(TInt aError,TDesC& aNetworkRegistrationStatus)=0;}As with many Symbian OS services, this engine requires the threadusing it to have an active scheduler installed and running.It is possible to have several client applications running at the sametime.
Each application should instantiate a CTelephony object – theMultimode ETel API deals with having several clients making requests, aswell as completing notifications to several clients.NotificationsThe telephony subsystem has been designed to cope with multiplenotifications completing to several clients. However, events can occurwhilst a client is processing a previous notification. In order to avoidmissing such events, any processing performed in one of the MNotifycallback methods should be kept as short as possible, to allow theengine to make the next request for notification.This can often be achieved very easily by simply taking a copy of theinformation, storing it in an CActive-derived class that you’ve designedfor this purpose, then immediately completing that active object.7.2.2 Using IMSI or IMEI to Provide Simple Application LockingTo prevent casual copying of your application, you may want to implement a basic scheme in order to ‘lock’ your application to a singlehandset or ICC (aka SIM card).
This can be done by using the IMEI (or210TELEPHONY IN SYMBIAN OSIMSI) number of the handset (or ICC), in conjunction with some form ofhashing scheme to generate ‘unlock codes’ for specific handsets.Note that this only provides a basic level of protection to your application.
Determined attackers can still modify your application to bypass thechecking code. If you are intending to market a high-value application,or have a specific requirement to prevent copying, then we suggest youtake a look at more advanced technologies, such as DRM-protected SISfiles, for distribution.To implement a locking scheme, you will need to get the user’s IMEIor IMSI, perform some form of hashing function on it, then send them thehash to enter into the application on their phone.Here’s a more detailed suggestion on how to do this:(a) Ask the user who purchased the product to provide you with its IMEIor IMSI number.
You can do this automatically, if the application is alreadyinstalled on the phone by using CTelephony::GetPhoneId() toretrieve the IMEI and CTelephony::GetSubscriberId() to retrievethe IMSI.Alternately, if the application is not already on the phone (perhapsyou’re generating the unlock code as part of selling the application froma website) then you’ll need to use the manual process. The IMEI numbercan be retrieved by entering *#06# into the telephony application.
Thesequence to dial for the IMSI differs for each network – you may haveto refer users to their network operator to obtain this information, orprovided instructions for popular networks.(b) Generate an unlock code and send it to the user. You need to createyour algorithm to do this. It needs to be implemented in your applicationfor the verifying process and also on another machine so that you cangenerate the unlock code.The algorithm could be a very simple function – for the purposes ofthis example, let’s just add the IMEI number to a ‘secret’ number togenerate an unlock code – obviously this isn’t very secure so you shoulduse a better algorithm in practice!So we do: < IMEI > +132456789 =< unlock code >. Now we havegenerated an unlock code, we need to send it to the user.(c) User starts the application and enters the unlock code.
How theuser enters the unlock code depends again on how the application isbeing sold – we could display it on a web page and get the user to enter itmanually, or we could combine it with the example for silently receivingSMS messages from Chapter 8 to automatically unlock the application onthe user’s device (obviously we’d need some method for sending SMSmessages, and their phone number in this case!).When the application starts, it can retrieve the IMEI or IMSI usingCTelephony, internally generate the unlock code and verify if it matchesthe unlock code entered by the user. If the two unlock codes match thenthe application can run normally.RESTRICTIONS AND CONSIDERATIONS211Public key encrypted IMSIs or IMEIs can also be used in the authentication process of a connection to a remote service.7.3 Restrictions and Considerations7.3.1 Access to Telephony FunctionalityThe Symbian MultiMode ETel APIs offer full access to the TSY andtherefore the baseband, and represent a very powerful set of APIs.They offer the ability to control voice and data calls, GPRS and 3 Gdata connections, as well as information stored on the device or onthe network.
Because of the sensitivity of the information exposed,and the potential to prevent the device operating correctly, these APIswere not made available to developers before v9.1, as there was nomethod for policing access to them.In order to offer generally available APIs for telephony services anew interface was created, designed with an easy-to-use format, toallow access to a controlled subset of the MultiMode ETel APIs. Thiswas released in Symbian OS v7.0 and was originally named ETel 3rdParty. It concentrated mainly on data call functionality.A newer version was released in Symbian OS v8.0, renamed ETelISV, and offered voice call support and access to more informationabout the current state of telephony on the device.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
