Recognizers and Executable on the ROM
 Lessons learned about my software while working with a device manufacturer

11/10/07

8 September 2004 - 24 September 2004

Recently I was tasked by my current employer, Action Engine, to fly (14 hours) to Sweden to work with Sony Ericsson on an integration issue regarding our product and the P910 ROM.  Due to the nature of the trip there are many specifics that I can not discuss, but I list here some general findings that I hope give developers some insight when developing recognizers and executables, especially when they may launched on a device's ROM image.

When a device is first started, either when the device is flashed or after a master reset, it has to initialize an array of device settings.  Here is a small list of items that are initialized on the first run:

• IMEI & IMSI numbers are retrieved by the OS from the device and SIM and written to files.
• MTMs are first initialized
• User file directories are created
• Contacts database is initialized (this is device specific, the contacts database may already be initialized on the ROM and just need to be written the RAM.

As I said, this is just a small list of things that are first initialized that developers may take for granted when developing recognizers or executables for these devices.  There could be many more items that are first initialized at startup, and as developers we need to diligent in checking our data for these error conditions especially in executables that run in the background.

Each of these devices when they are first initialized from a flash or master reset experiences a significant slowness during this initialization, some devices more than others.  This initial slowness is a constant complaint from many operators and end-users.  If your recognizer launches your executable, and the executable does not account for this initial period of slowness, then your executable will also add to this period of slowness.  As the device increases in slowness at first startup the possibility increases that the device will become unresponsive.  If an application is not able to draw itself to the screen in a certain amount of time, the App Server will panic the device when the app server times out attempting to draw to the screen.

Recognizers are ran very early on in the startup process on the Symbian OS, within a second to two seconds after initial boot up.  If your recognizer is designed to startup your executable, then you executable is also running a second or two into the startup process.  As you can see, if you do not consider how your executable acts during the initialization process you may also add to the slowness.

My opinion on things to consider when creating recognizers that launch executables on a Symbian device:

• Create an initial delay the first time your executable is run.  You may consider persisting a Boolean flag somewhere that you can retrieve when you run your executable again, informing you that you have already waited your initial delay.  The time delay is up to you and is dependant on the device.  I would recommend doing some investigation on the device to determine when the device suddenly becomes more responsive.  This should actually be fairly noticeable by trying to start several applications at once when your device first starts up.  If you have a flip (P800/P900/P910), open and close it, this causes a significant load on the device as it tries to redraw the applications.  You will notice a point when the redrawing becomes considerably more responsive.  When you get to that point, you have found a good amount of time to delay before you start the main processing of your executable.
• You will want to insure that your executable waited the full delay time before you set the flag that you been ran once and waited the delay time.  This is due to the fact that the user may power the device off before the delay has waited.  This will definitely occur if the user chooses a language at startup that requires the device reboot.  For example, the device still needs to reboot and start the initialization process.  If you set your "delay flag" prematurely, you will be executing your code during the initial startup.

Other things to consider with recognizers and executables in general:

• You may still consider a small delay if your executable relies on information from the device.  Information such as IMSI number may take a few seconds to get updated to the OS (usually by the OS writing to the IMSI.txt file).  During the initial master reset/flash sequence, the IMSI & IMEI may come back as NULL or a dummy number.  However this can also occur after the first boot if you switch SIM cards on your device.
• Be careful of the amount of file access during your daemon process.  File accesses can be expensive especially if you are reading and writing to a file inside your daemon once a second or even minute.  Consider designing your executable to minimize repeated file accesses and caching information from those file reads into your executables memory.
• Use Active Objects to do the bulk of your work inside of your process.  This will enable your executable to share the CPU appropriately with other threads.
• Unit Testing!  Symbian OS Unit - shareware Symbian unit testing.  I can not stress enough about how unit testing is mandatory for every executable you develop to be run on the device.  Due to the silent nature of these daemon processes, testers testing your executable will only be able to detect if the executable works or doesn't work. 
  But they may not be able to detect:
  • if your executable uses resources ineffectively
  • what happens during error conditions such as no/low memory
  • what happens when the device has no network
  • and many more error conditions... 

That's it for now, I will continue to revise this article as I find more information.  It is my hope that you will find this information insightful and helpful during your development.  Please feel free to contact me if you have any questions regarding this article.