Introduction

Checking a developed Rich Media Application behaviour, optimizing user experience and resources consumption, and investigating detected issues are key tasks to obtain the most reliable application for devices.

Basically such tasks can be divided in 2 phases:

• application debugging while in development phase; this step consists for the developer in checking the application behaves as expected, validating its implementation
• application debugging once deployed; this step consists for the developer in investigating and solving detected issues, eventually reported by end-users

In all cases, debugging in Workbench Developer environment and eventually on device(s) will be necessary.

Emulating in Workbench Developer

Although due to devices fragmentation (heterogeneousness in terms of screen size, inputs, capabilities..) on-device testing - for all devices intended to be supported by the application - will always remain necessary, a significant part of work can be accomplished prior to this, thanks to the emulator provided within Workbench Developer.

The emulator is the corner place for Rich Media Applications debugging, where many tools are granted to reproduce and investigate issues.

Local vs distant emulation

Emulation offers 2 modes:

• Local emulation (Service > Emulate Service): Workbench Developer will act both as a device (Rich Media Client emulator) and a server (Rich Media Server emulator, being actually a real Rich Media Server instance hosted on local machine); this mode will be very frequently used during the development phase in order to check the implementation progress and conformance with the requirements.
• Distant emulation (Service > Run Service): Workbench Developer will act only as a device (Rich Media Client emulator) and will request a remotely hosted Rich Media Server instance; this mode will usually be used after a publication on this Rich Media Server instance, in order to check the deployed application is ok.

Emulation configuration

Emulation can be configured to get as close as possible to what would be experimented on a given device and communicating through mobile network:

• General: device brand and model can be specified so as to make the integrated emulator act as the specified device

• Options: simulated network bandwidth, proxy configuration (if applicable) and initial screen orientation management can be specified (i.e. simulate how application would be displayed according to device current orientation - applicable only if the target device supports screen orientation changes and if such changes are handled by the developed application)

• Output: generated rich media content (in XML form) can be dumped as configured if needed, this can be helpful to check the processed Rich Media Streamezzo Pages (RSP) give the expected result once processed (especially when containing Java scriptlets)

• Customization: HTTP headers, supported languages and URL parameters can be specified here in order to simulate respectively the extra HTTP headers a gateway may add to requests from client to server, the multiple languages (if any) the application is supposed to support and extra URL parameters that should be passed in request from client to server

The most usually used configuration parameters among those are:

• General / Device specification: systematically used for all devices supposed to be supported by the application, in order to address as many issues as possible prior to on-device testing
• Options / Network bandwidth: usually configured in accordance to targeted network(s) - see applicable bandwidths here
• Output / XML dump: usually used to investigate some observed inconsistencies in the application display and/or behaviour

Once the emulation configured and launched, the client-side scenes are processed then the emulation perspective is displayed as below:

Emulation tools

Emulation comes with many facilities intending to help investigating faced issues. Once the emulation has been launched, Workbench Developer will automatically switch in the corresponding perspective, displaying multiple views, each presenting a different set of information focused on a specific subject.

• Device emulator (top central view): simulates the device screen and inputs; here you can observe how the application is displayed and interact with it (with the keyboard and/or the mouse pointer for simulating device keyboard and/or touchscreen)

• Rich Media Client (top left corner): displays information about the specified emulated device; here you will also be able to zoom the display of the Device emulator (see above), activate the visualized of refreshed regions on the Device Emulator (described above) and adjust the rendering framerate in order to check the end-user experience in case of low performance by decrease the default fps

• Logs (midde left): displays the InstantScript Virtual Machine logs (see VM.log() in InstantScript Javadoc included in Workbench Developer Help), as specified in the RSP code; note these logs can also be displayed directly in scenes, so on the Device emulator, outputing them in a Text node (see VM.setLogOutput() in InstantScript Javadoc included in Workbench Developer Help); such logs are especially useful to investigate execution issues related to InstantScript coding

• Compilation Console (bottom tab): displays the logs generated while processing client-side RSP; you will find here potential compilation errors for such scenes and the logs you have specified in your RSP code (see
• Runtime Console (bottom tab): displays the logs generated while processing server-side RSP; you will find here potential compilation errors for such scenes

• Stored cache (bottom tab): lists the current entries stored in client cache
• Cache queue (bottom tab): lists the current entries waiting to be downloaded then stored in client cache

• Scene graph (right corner): allows taking a snapshot (in XML form + the associated visual representation + some usage states related to complexity) of the code as currently interpreted by Rich Media Client; this is especially useful to oberved what is currently in memory (non expected or missing elements) and in which state (activity...)

Device capabilities emulation

In order to perform on-device testing at the latest, Workbench Developer emulator grants the ability to simulate some features specific to a device, like accessing device data (contacts, messages, filesystem...), launching device applications (phone call, camera...) and retrieving device metrics (network level, battery level...). Find more information on device capabilities in the dedicated section.

Such feature are usually access in RSP coding through commands (cmd://). You will find the list of emulated commands in Workbench Developer Preferences (Window > Preferences > Workbench Developer > Emulation > Client Emulation > Commands).

Concerning access to (fake) device data, this data can be specified within a XML file and when you will access it in your application in the emulator you will get some specific logs tracked in the Logs view. This will allow checking access to such data can be properly performed when applicable in your application.

The same goes for device applications launch: you will also get a specific log in the Logs view that will allow checking application is properly launche when applicable.

This will lead to the validation of the implemented code, but remember such features exploitation is part of the key tests to be performed on all addressed devices in the end.

Note some of those commands are especially relevant for on-device investigation purpose, like cmd://linkNodeToLevel, for monitoring the memory and cache occupation.

Controlling the server runtime

Mostly you may need to investigate the following points on Rich Media Server side:

• Server-side RSP processing, which includes access to any data source (media servers, databases, back-ends, Content Management Systems...)
  • setting logs in the Java Scriptlets of your RSP code, with the appropriate log level, will be very useful (see StzRequest.getLogger() Javadoc in Workbench Developer Help); such logs can be consulted on Rich Media Server admin console (web)
  • additionally as goes in Workbench Developer emulation Output configuration, it is possible to output the generated scenes (in XML form) and access them from Rich Media Server admin console (web)
• Server-side cached content, i.e. checking cache entries are properly stored and accessed
  • level 1 cache: processed RSP content stored in server cache for immediate sending on same client request
  • level 2 cache: remote resources stored in server cache for immediate access to those resources

Testing on device

Ultimately, after a strong validation of the implemented application relying on all facilities provided by Workbench Developer integrated emulator as stated above, on-device testing will always remain necessary to ensure the application displays and behaves properly:

• An on-device testing campaign shall be performed prior to deployment, for each of the device models supposed to be supported
• Once a defect is detected on the application for a given device, if emulation doesn't allow reproducing the issue, it is probably related to a device specificity and will have to be reproduced and investigated on the device itself

Client side and server side logs will be especially useful to investigate any issue.

Note that device analysis reports provided by Streamezzo (for already qualified devices or on-demand device qualifications) are useful to identify device limitations preventively (i.e. checking if the requested device is applicable against the required features to be exploited by the application) but also when a given issue specific to this device is met (i.e. identifying the reason why a given issue is met on that precise device, in what extent it is limited (feature not supported or with limited support) and adapt the application for this device appropriately).