Script to App, the Somusar way

Published by Steve Litchfield at 19:54 GMT, March 16th 2006

Somusar's Francesco Aliverti-Piuri takes up the challenge of producing an application in a weekend, armed only with some sample content from myself and his Software Production Machine (SoProMach) system. His account of the weekend, and notes on how he created the other sample application here, Barcelona, should give you a good idea of the scope of SoProMach.

Parts of Francesco's article read a little like we're giving him free advertising, but any system that allows people to get their ideas onto Symbian OS without having to learn C++ is a good thing as far as we're concerned. I have to say, as someone used to OPL and Python, SoProMach doesn't seem that much easier to get to grips with, but each RAD system has its strengths and weaknesses. In this case, there's a learning curve to climb, but once climbed, applications should be quite quick to 'produce'. You should also note that the system also requires you to have installed the official C++ SDK as well, as a background tool.

by Francesco Aliverti-Piuri   

Introduction

"Teddy Bears" is a new S60 freeware native application available for download here. It is an interactive, multimedia parade of Steve Litchfield (and daughter)'s Teddy Bears collection, made with Somusar's software production technology.

 

Figure 1 A teddy bear

Figure 2 Its description

Figure 3 Short history of teddy bears

One week ago this application had not yet been conceived of. Its origin has been an email exchange between Steve Litchfield and Francesco Aliverti-Piuri, co-founder and Managing Partner at Somusar. Steve and Francesco were discussing another S60 application (Barcelona, see Addendum at the end of the article) developed according to a software production process described in an article published by SymbianOne, titled "Somusar: Instant S60 development".

This software production process allows the user to rapidly develop freeware and commercial native applications (SIS files) for S60 devices. The process can produce SIS files that request a registration code specific for the IMEI code of individual devices, thus allowing content and application developers to produce either freeware or commercial applications, such as Teddy Bears or "The Harpsichord Riddle".

The process significantly reduces development costs for such S60 native multimedia applications, that can subsequently be branded as "Symbian Signed" and "Designed for S60 devices". Overall, the process enables the industrial production of SIS files for S60 devices.

The email exchange between Steve and Francesco led to the idea of testing SoProMach with some real data. Steve kindly agreed to play the role of the customer (a content provider, in this case), and suggested using his material on Teddy Bears for a sample application. This suggestion happened on Saturday, 11th March at about 1:00 pm CET. On Sunday, 12th March at 11:10 pm CET the application was ready.

Read on to find out how this happened in detail, and how you and your company can make it happen, too, for numerous different S60 applications: navigable multimedia shows like Teddy Bears, or travel guides, soap operas, comics, product guides, repair manuals, quizzes, games, and questionnaires.

Weekend diary: Francesco's activity log

The unplanned-for project was developed in several steps, interwoven with regular weekend activities with the family. The most relevant development steps are marked in bold in the log below, and described in detail in the next paragraph.

Saturday, 1:00 - 2:00 pm	Email exchange with Steve, basic agreement on sample app contents. Initial analysis of Teddy Bears contents.
2:00 - 6:30 pm	Off to watch a movie with the family, then played badminton with the kids. Kept a background brain thread active on how to structure app content.
6:30 - 6:50 pm	Downloaded all Teddy Bears contents from 3-Lib. More accurate analysis.
6:50 - 7:50 pm	Searched the web for appropriate MIDI files. Found and selected interesting pieces at www.midiworld.com/bach.htm.
7:50 - 10:00 pm	Dinner, played games with the children.
10:00 - 11:00 pm	Standardised pictures of teddies, produced 24 x 2 (full-screen and half-screen) BMP files.
Sunday, 8:30 - 9:00 am	Created a new project, copying and cleaning up an existing project.
9:00 - 9:40 am	Added 24 "rooms" (described later) to the new project, one for each full-screen teddy picture panel.
9:40 am - 12 noon	Out to a park with family and a friend. Played football with son. Brain threads on app navigation scheme and implementation options.
12 noon - 1:00 pm	Email exchange with Steve: agreed on app specification and implementation options.
1:00 - 3:30 pm	Lunch with family and friend. Helped son with piano lesson.
3:30 - 4:30 pm	Added 24 rooms to project, one for each teddy description panel.
4:30 - 7:30 pm	Out to visit parents, played cards, met nephew.
7:30 - 9:30 pm	Dinner, then convinced kids that it's time to sleep.
9:30 - 10:50 pm	Added 3 rooms (History, Made for cuddling, Special guest) and sounds. Went through four cycles of generate-build-test (emulator only).
10:50 - 11:10 pm	Tested on real devices. Two more gen-build-test cycles. Sent app to Steve.

Weekend diary: details on Francesco's development activity

The most relevant activities of the project are described in detail in the following paragraphs. These tasks are common to other projects aimed at producing this type of navigatable multimedia show, as well as travel guides, soap operas, comics, product guides, repair manuals, quizzes, games, and questionnaires.

In summary, common high-level tasks are:

• Define content navigation scheme
• Standardise contents
• Create project
• Add contents to project
• Generate software
• Build application
• Test application

By no means should you expect this process to be strictly sequential: in fact, even for Teddy Bears, the navigation scheme was changed during one of the last gen-build-test cycles, to have the "Back" button from the teddies descriptions lead back to the corresponding full-screen teddy, rather than the main panel. Luckily, each gen-build cycle is fast enough (about one minute) that it is easy to change or extend the project and immediately verify the impact on the application.

Standardised pictures of teddies, produced 24 x 2 (full-screen and half-screen) BMP files.

As described in the aforementioned SymbianOne article, this type of application requires some standardisation of contents, before starting to actually produce S60 software. In the case of Teddy Bears, Steve's texts were ready for copy-pasting, and audio MIDI files required no processing, except for file renaming. One audio file in MP3 format was custom-made for the Special Guest panel. So the only content in need of standardisation was the set of teddies images.

As shown in figures 1 and 2, in the case of S60 devices with a screen resolution of 176 x 208, the standard sizes for pictures are 176 x 190 pixels (full screen) and 176 x 110 (half screen). This step thus required rescaling and then selecting the relevant part of picture from Steve's images (such as this). This was done twice (once for each size) for each teddy image, leading to 48 pictures in BMP format.

Created a new project, copying and cleaning up an existing project.

The nickname for this class of projects is currently PAT: Pictures, Audio, Texts. As an aside, recent tests have successfully integrated video clips, so the nickname might change to VPAT. The software generator producing the S60 application is thus called "PATgen". A PATgen project is a folder containing some text files, and two subfolders, "pics" and "sounds". The most important text file is "story_board.txt" and contains the navigation scheme for the application.

Creating a new project requires therefore to create such a folder. In the case of Teddy Bears a new folder, "story.teddies", was created as a copy of folder "story.tguide", containing the application described in Addendum. The contents specific to that application (pictures, audio, texts) were removed from the copy, and the navigation scheme was reduced to the minimum possible size, which includes:

• a splashscreen
• a main panel
• a "Help" panel
• an "About" panel
• a hidden switchboard panel, used to manage special cases of navigation

When a new project is ready, a quick run of PATgen will detect potential inconsistencies in the cleaned-up navigation scheme. It is also possible, for training purposes, to produce a SIS file of a skeleton application.

Added 24 "rooms" (described later) to the new project, one for each full-screen teddy picture panel.

Once the basic navigation scheme is ready, it is possible to add what would best be defined as nodes of the app navigation graph. In PATgen terminology, these nodes are called rooms: rooms are the concept behind application panels like those of figures 1, 2, and 3. In other words, a PATgen room is a textual description of an application panel. This of course also applies to the panels listed above, namely, splashscreen, main, help, about and switchboard panels.

Rooms can be of three types, as shown by figures 1, 2 and 3:

1. full-screen picture
2. half-screen picture and text
3. full-screen text

Audio (MP3, WAV, MIDI, AMR) and video (.3gp) can also be optionally associated with rooms.

A room description is basically a set of property definitions. Basic properties include text (for rooms of types 2 and 3), a label, a set of navigation links to other rooms accessible from the room being described, and a backward link to another room, or to exit -- to be associated with the "Back" or "Exit" softkey. The following figure shows the descriptions of the splashscreen and main panels in file "story_board.txt". A void back link leads to the exit.

 

Figure 4 Sample room descriptions

Other properties are derived implicitly by PATgen. For example, if "story_board.txt" defines a room "special_guest", at generation time PATgen will check folder "pics" and folder "sounds". If it finds, for instance, file "pics\special_guest.bmp", then PATgen associates that picture with that room, and generates the software required to manage that association. The same scheme applies for audio files.

Getting back to the 24 full-screen teddies, adding them to the project required:

• copying the corresponding BMP files into subfolder "pics"
• creating 24 homogeneous room descriptions with an empty text property

It is worthwhile to note that the software generator is programmable, therefore it is possible to avoid a tedious and error-prone copy-paste action repeated 24 times. In fact, it is possible to instruct PATgen to generate 24 homogeneous panels by means of one generic parametrical room description, and embed this generic description in a "for" loop that scans the list of Steve's teddies.

In summary, adding 24 full-screen panels was accomplished by copying 24 standardised BMP files into the right place, and by writing a dozen lines of scripting code for the generator.

Added 24 rooms to project, one for each teddy description panel.

This step was very similar to the previous one, with one difference: the 24 rooms were homogeneous, but their individual texts were different. Therefore the texts were assigned to 24 variables (remember that the generator is programmable!) named after the teddies. The "for" loop was augmented with another generic room description: on encountering that loop, the generator would thus produce 2 different panels (one full-screen, one with image and text) for each one of the 24 teddies.

The following illustration shows the comparatively complex fragment of scripting code from "story_board.txt" with the two generic room descriptions.

Figure 5 Generic descriptions of teddy rooms

It is important to note that the software generator can natively read HTML, XML and CSV (comma-separated value) files, that provide a friendlier and more standard way of describing rooms. HTML, XML, or CSV inputs to the generator could come from standard enterprise documents, written with Microsoft Word or Excel, defining contents and navigation schemes of navigable multimedia shows, as well as travel guides, soap operas, comics, product guides, repair manuals, quizzes, games, and questionnaires.

Added 3 rooms (History, Made for cuddling, Special guest) and sounds. Went through four cycles of generate-build-test (emulator only).

Adding 3 more panels, as you know by now, required me to add 3 new room descriptions. No special trick here, as the rooms were all different. Adding one MIDI file per teddy panel was accomplished by renaming each MIDI file to the corresponding teddy ("simon.mid", "scarlet.mid", and so on), and copying them into the "sounds" subfolder.

During the previous steps, PATgen had been run to check that "story_board.txt" did not contain any inconsistency. In one occasion a build was performed, to check that the generated software was in good shape, even though the SIS file was still incomplete. Now it was time to start testing the app on the S60 emulator.

One gen-build-test cycle was necessary to fix one navigation issue: as mentioned before, "Back" from a teddy description would take to the main panel and not to the full-screen teddy panel. Three more cycles allowed to fix minor look inconsistencies, such as colour scheme in full-screen panels.

Gen-build cycles are fully automatic jobs performed as a single command line in a Windows command prompt, as shown in the following picture. The "patgen" script instructs the SoProMach generator to apply the S60 project software stamps to the specified PAT project. The "patbuild" script is a thin batch file that runs the standard S60 SDK commands.

Figure 6 Generating and building

 

Tested on real devices. Two more gen-build-test cycles. Sent app to Steve.

When the emulator test was satisfactory, testing on real devices took place. This also went well, but showed one problem: the app would not install on N-Gage, the basic reference platform, because the app size was beyond the RAM available at installation time. The app size was reduced by associating a (smaller) audio file in AMR format with panel "Special Guest": now the app installed and worked properly even on N-Gage, but the sound quality of the Special Guest's voice was not good. Hence the MP3 file was put back in place, and - all is well that ends well - Teddies.SIS was delivered to Steve.

Addendum: Barcelona.SIS

A different application produced with the same process used for Teddy Bears is "Barcelona", a sample travel guide with contents from Wikipedia and WikiTravel. It is beyond the scope of this article to describe that application in detail, but you can download its SIS file from here and compare it with Teddy Bears.

Description

Barcelona is a technology demonstration produced for presenting the concept of self-contained multimedia mobile guides, suitable for both online and offline (i.e. in flight mode) browsing. Text, pictures, audio, maps and possibly video clips can be packaged together in one SIS file, providing travellers with an easy-to-install, compact digital version of traditional guidebooks for S60 devices.

While not a replacement for complete guidebooks, mobile guides can provide quick-access information, be frequently updated, and get distributed as thinner guides (e.g. individual regions instead of complete countries) that would be impractical for physical books.

 

Barcelona vs. Teddy Bears

The production process for Barcelona and Teddy Bears has been the same, although contents editing obviously required significantly more work in the case of Barcelona:

• Define content navigation scheme
• Standardise contents
• Create project
• Add contents to project
• Generate software
• Build application
• Test application

The similarity in the production process becomes apparent when comparing corresponding panels from the two applications, as in the following pictures, where TB stands for Teddy Bears, and B for Barcelona.

 

Figure 7 Main TB panel	Figure 8 Main B panel
Figure 9 Main TB panel choices	Figure 10 Main B panel choices
Figure 11 TB panel with image and text	Figure 12 B panel with image and text
Figure 13 TB panel with text	Figure 14 B panel with text
Figure 15 TB panel with image	Figure 16 B panel with image
Figure 17 TB help panel with text	Figure 18 B help panel with text

The two applications are built in the same way, yet their navigation schemes differ significantly. TB is highly symmetrical, featuring two rows of 24 rooms, with connections between each pair, while B's navigation scheme is much less symmetrical, with subtrees of panels of different depths: for example, from the main panel the user can access a "Data" panel that has no subpanels, as opposed to the "Hostels" panel, whose path is Main Panel -> Eat/Drink/Sleep -> Sleep -> Hostels.

Barcelona allows to better appreciate other features of applications produced with PATgen that are less visible in Teddy Bears. One such feature is the navigation via shortcuts represented by the numeric keys, in the style of a TV remote control: each panel can be accessed either via the so-called navigAction key, or via the corresponding numeric key (refer to figures 9 and 10 for examples).

Another feature is the navigation through sectors of images, shown below.

Figure 19 Metro map overview

Figure 20 Metro map sector choice

Figure 21 Metro map sector

This feature allows the user to directly access a given sector by pressing the corresponding numeric key, and then to access adjacent sectors using the navigation arrow keys or the numeric keys. Such a feature can be useful, for instance, for diagrams of machinery in repair manuals, to rapidly access a detailed view starting from a general view. Note that a sector can in turn be split into subsectors: using a 3 x 3 grid with 9 sectors, two numeric key clicks allow to access 9 x 9 = 81 sectors, and so forth.

Barcelona also includes one podcast in AMR format (Main Panel -> Language), providing a sample of integration of voice data. This can also be useful, for instance, in mobile repair manuals to help a repair engineer through his work, allowing him to visually focus on the machinery being repaired, while listening to the pre-recorded instructions.

More generally, pre-recorded voice data (and environment sound effects) can replace, or be coupled with, textual data: this is certainly useful in repair manuals and travel guides, but is also applicable to navigable multimedia shows, soap operas, comics, product guides, quizzes, games, and questionnaires.

For additional information please contact Francesco DOT Aliverti AT somusar DOT com.

Share This (Digg, del.icio.us, Facebook, etc.)

Categories: Develop
Platforms: Series 60, General