John.Wiley.and.Sons.Rapid.Mobile.Enterprise.Development.for.Symbian.OS.An.Introduction.to.OPL.Application.Design.and.Programming.May.2005.eBook-LinG (779881), страница 9
Текст из файла (страница 9)
the Contacts application storesnames and addresses), but how they react to the system and the user asthey open, as they are running, and as they are closed.So our Event Core program needs to be able to accommodate all thesecore functions of a responsible program:• react to messages from the processor (for example, exiting the programwhen the system asks it to)• save the state of the program when we exit the program• load these preferences back in when the program is opened again• be able to display and react to a menu• be able to recognize and act on a pen tap• be able to recognize and act on a key press.We’ll work through these elements in this chapter, and by the end of ityou’ll have a complete foundation for all your future programs.3.1.3 Recognizing Different PlatformsAt the time of writing, Symbian OS has three major platforms that have aworking version of the OPL Runtime.
It is possible for your OPL programsto be written so that the object code can be run on any of the threeplatforms. There are a few things we need to consider while writing theEvent Core, so that this multi-platform support will be inherent in all yourprograms:UIQSeries 60Series 80Screen(Full)Screen(with Furniture)TouchScreenKeyboard208×320176×208640×200208×234176×144640×180YesNoNoNoNoYesSpecial KeysCBA1, CBA2, CBA3, CBA4, Menu, Enter, Clear. See Figures 3.1, 3.2and 3.3.Our Event Core will have to be able to cope with these different keylayouts so that when you come to write your program using the EventCore, you won’t need to worry about them.EVENT CORE? WHAT IS IT GOOD FOR?Figure 3.1Series 80Figure 3.2Series 60Figure 3.3UIQ3536EVENT CORE3.2 Planning the Event Core, Init:3.2.1 Planning the Event CoreThere are some people who can sit down with a blank file and typesource code with only a rough idea of what they are planning to do.
Theysee everything, the structure, the variables and all the windows, and cantype them straight in.Most people (including myself) will need to do some planning. We’vealready bullet pointed out what we want the program to do. We need tobreak this down into a list of procedures, and work out in what order wemove through them. It’s also best to add in the basic loops we will use.So here’s our first procedure, in plain English rather than OPL code:PROC Main:Set up all the GLOBAL and LOCAL variablesLoad any saved settingsCheck all the things we need to check when starting a programSet up program-specific thingsCheck for a key pressDo something if one is pressedKeep doing this until we need to exit the programDo the things we need to do when exiting a programENDPNow some of these lines can be procedure calls, and some can be loops.So let’s do a re-write and put this plain English into something very closeto OPL:PROC Main:GLOBAL rem We’ll fill these in as we plan the programLOCAL rem We’ll fill these in as we plan the programInit:InitApp:DOrem Get a key press (an event)rem Act on this key pressUNTIL rem we need to exit the programExit:ENDP3.2.2The Init: (Initialize) ProcedureAgain, let’s break down what we want to do in this procedure:• set up paths, determine what disk the program is stored onPLANNING THE EVENT CORE, Init:37• load INI file, determine if this is the first time the program has been run• sort out screen sizes• set up windows and load graphics.We’ll look at each of these sections in turn, showing the relevant code,and explaining principles and commands as we come across them.A Little ReminderBefore all that, we’ll just remind the user what program they are running,who wrote it, and what version they are using in a small on-screenmessage.
The command:GIPRINT KAppName$+", "+KAuthorName$+", ver "+KAppVer$is all we need (although note I’ll be using GIPRINT with a capital ‘G,’even if it is a graphics command), and it uses the following constants:CONST KAuthorName$="Ewan Spence"CONST KAppVer$=”1.00”CONST KAppName$="Event Core"All of these we’ll need to define at the start of our program. GIPRINTshows an on-screen Graphical Information Printed message for a fewseconds, and is great for short bursts of information like this. Its syntax issimilar to the PRINT statement we used previously.One good use of GIPRINT is that when debugging programs, you canadd in aGIPRINT CheckValue$GIPRINT NUM$(VariableToShow%,3).
. .to check the value of a variable at that point in a program.Set Up PathsYour OPL program is going to need to be able to load information from(and save information to) the phone’s storage devices. Graphics are theobvious items here, but no matter what they are, it is important to findout where these stored files are held.It is a convention of Symbian OS that every program has its own directory to store libraries, graphics, and other information. This directory is:AnyDrive:\System\Apps\AppName\38EVENT COREIn addition, every major program will have this folder on C:\ (the internaldisk that is always present) to store its INI file. INI files are only everstored on the C:\, so we must search for another file to determine whereour program is running from. On the assumption that every program willhave some graphics, we search for this file to discover what directory theuser installed our program and all other supporting files to.Again, Symbian OS convention is to search for the directory a file isinstalled on in a specific order.
That order starts with the Y:\ drive, thenmoves back through the alphabet to reach A:\, and finally it checks Z:\(which is always the ‘ROM’ of the phone where Symbian OS itself is stored).While there are no Symbian OS phones with more than one externaldrive (at the moment), you should always consider the fact that these mayget released. Take this into consideration now and you will not need tore-write your code.So here’s what we can do:MbmFile$=KAppNameShort$+".mbm" : Data$="\System\Apps\"+KAppNameShort$Foo%=ASC("y")DODrive$=UPPER$(CHR$(Foo%))IF EXIST(Drive$+":"+Data$+MbmFile$)Path$=Drive$+":"+Data$BREAKENDIFFoo%=Foo%-1UNTIL CHR$(Foo%)="Y"IF Path$=""ALERT("Support mbm file not found","Please re-install"+KAppName$)STOPENDIFWe have four global variables used here, a constant, and one localvariable.
This is how they were declared:CONST KAppNameShort$="Core"GLOBAL Path$(255),Drive$(2),Data$(255),MbmFile$(16)Data$ will hold the directory where the program stores its information.We use the constant for this short name so when you come to edit theEvent Core into your own program, you don’t need to search through allthe code for the program name, you can just change the constant at thestart of the code.Drive$ will let us know what drive the information is being stored on(e.g. "C:" – thus it only needs to be two characters long at most).Path$ holds the full directory name for the data, and is made up ofDrive$+Path$.LOCAL Foo%PLANNING THE EVENT CORE, Init:39Foo% is used in the DO...UNTIL loop to keep track of the numeric valuethat represents the letter (of the drive) that we are checking for.
When weleave the procedure, the memory space reserved for Foo% is reclaimedas free memory.Inside the loop, firstly we make sure we are searching for Y: and not y:when we decide what to make Drive$ equal to for this loop iteration,by converting the character into uppercase (using the built-in UPPER$function). If it is already an uppercase letter (which will only be true inthis example when we loop back to Z:) then UPPER$ will have no effect.This exploits how letters are stored on most computers; each letter hasa corresponding numerical access code, and capital letters come beforelowercase ones. In our code, we start with ‘y’ and move down a letteruntil ‘a’, then roll down one more number which will take us to ‘Z’,achieving our aim of searching Y: to A: and then Z:.The EXIST command is a binary check.
It returns a 1 if the statementis true, and a 0 if it is false. As you read before, an IF statement is assimple as checking IF something is TRUE, so we can happily write ‘‘ifthis file exists, then do something’’. Which in OPL corresponds to:IF EXIST(Drive$+":"+Data$+MbmFile$)This will be true when we find our .mbm file. When we do, we can setthe path and break out of the loop – we don’t need to check any further.Path$=Drive$+":"+Data$BREAKOf course we may loop all the way through the letters (Y: to A:, then Z:,then back to Y:). If this happens, then we can’t find the .mbm file, thePath$ will not be given a value, and we must assume the program isnot installed correctly.
So we show an error message (using the ALERTcommand) and STOP the program.IF Path$=""ALERT("Support mbm file not found","Please re-install"+KAppName$)STOPENDIFThe ALERT command is another type of PRINT statement. It puts theinformation in a box similar to the alert boxes of the Symbian OS phonewe are running on. Note that each line of text is separated by a comma,and that we can still add together terms, or just display a given stringinside "quotation marks").40EVENT COREThe INI File Procedures (LoadIniFile% and SaveIniFile%)Imagine if you had a program where you could set the screen color toyour favorite color. Now whenever you run the program you’d expect theprogram to remember your choice.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
