One option for ICEmobile-SX return value enhancement is to use JSON encoding rather than URL encoding. Unfortunately, JSON is characterized by an abundance of characters that must all be encoded in URLs (specifically braces, quotes, and commas).

URL encoding will be used as the base encoding for ICEmobile-SX return values. By default name=value pairs will be found in the document by id (name is not unique and would require a form to be specified) and their value will be set. If the id (with suffix "-hid" added) is not found, but is valid, a hidden field will be created to store the value. This case where the ID is "invalid" can be used by JavaScript invocations that rely on the callback alone for data transport. In this case the name passed to ICEmobile-SX invocation should be of the form "_result" since underscore is not an allowed character for HTML IDs.

[Possible future simplified ajax capability: If an element without a value is found (such as a div or text area) the value will be set to the innerHTML of the element.]

Name/value pairs of the form "!name=value" (where the name starts with "!") are reserved and are processed by the hashchange logic for flags and other data values used by the JavaScript API.

The safest data transport mechanism is to use the name=value form since this will function even if the browser completely loads the page (thereby losing any in-memory context for JavaScript callbacks).

Each native function is defined in the ice.mobi namespace, for instance:

ice.mobi.scan("myqr");

will result in the scanned value being stored in the field with name "myqr" and id "myqr-hid" adjacent to the element with id "myqr".

ice.mobi.scan("_myqr", mycallback);

will result in

mycallback(event)

where

event.command = "scan"
event.name = "_myqr"
event.value = "scanned text"
event.response = null
event.preview = null
event.status = "done"

ice.mobi.camera("_mycam", mycallback);

will result in

mycallback(event)

where

event.command = "camera"
event.name = "_mycam"
event.value = null
event.response = "handled by AuxUploadResourceHandler"
event.preview = "data:image/png;base64,iVBOR..."
event.status = "wait"
event.statusDetail = "offline"

For bulk upload types such as photo and video, ICEfaces does not return a useful value, but other approaches could use the return value from the upload to associate the upload with future HTTP requests (thereby supporting a sessionless interaction).

Values for status: "done", "wait", "fail". statusDetail contains the error message or description of the wait condition.

A more detailed variant of the API includes an options value:

ice.mobi.camera("_mycam", mycallback, {postURL="...",returnURL="...",parameters={name=value,...}}

Defined options are:

postURL: the URL to POST the captured data to; if omitted will use the action URL of the containing form
returnURL: the URL to display in the browser when complete; if omitted will be the current URL with #icemobilesx appended (no fragment will be appended if the URL currently has a fragment set)
parameters: JSON object of name/value pairs
JSESSIONID = session ID cookie
splashURL = the URL of a splash screen image

It may be possible to perform all uploads in the background and return a thumbnail immediately. Server push could be used to update the page. ICEmobile-SX will require a flag to indicate whether a given upload should be performed in the background.

The ice.mobi.camera still requires an absolute URL, but this is being computed:

onclick="ice.mobi.camera('_cam',handleCam,

);"

It would make sense for postURL to be processed for certain patterns: if starting with "." or "/", would be converted to host/URL or relative URL with all others being passed through unchanged. ICEmobile-SX could also work with a relative URL based on the other URLs passed to it, such as the return URL.

The invocation URL will be changed to "icemobile:" from "icemobile://" to conform to the URL spec and avoid complications with URL parsing on BB10. "When
authority is not present, the path cannot begin with two slash
characters ("//")." http://tools.ietf.org/html/rfc3986#section-3

There are four reserved values currently returned from an ICEmobile-SX interaction:

r: server response text
p: preview/thumbnail of captured content (data-url)
h: URL hash fragment to be restored
c: cloudPushId

(this is in addition to returned named parameters for the operation itself)

Missing checkin comment on revision 37744 due to premature enter key:

using self.receivedData for improved stability, allowing empty currentURL for future offline support, returning cloudPushId in local browser response (MOBI-827)

The bridgeit demo has been updated to make use of Cloud Push features, however a few aspects are not working:

• propagation of the Cloud Push ID requires the change to ICEmobile-SX; this is checked in but not available in ICEmobile-SX 1.3
• ice.push.notify(group, {subject:...,detail:...}

  ); is not yet available

• to demo cloud push requires either two machines or a delay. It may be possible to send the push when the browser is hidden, or we may want to add a delay parameter to ice.push.notify()

The following icemobile functionality should likely be added to icepush.js:

window.addEventListener("pagehide", function () {
if (ice.push)

}, false);

window.addEventListener("pageshow", function () {
if (ice.push)

}, false);

For example, the following return URL sets the value of scanBtn to "My art ... keeps me sane.", restores the # hash fragment to _scan:

http://tetra.ice:8080/bridgeit/mobile.html#icemobilesx_scanBtn=My%20art...%20keeps%20me%20sane.&!h=%23_scan

Example camera response:

http://tetra.ice:8080/bridgeit/mobile.html#icemobilesx_!r=%5B%22icemobile-store/a86016c5-6c06-4b5a-ae4e-75557c5c0dac%22%5D&!p=data:image/jpg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/4QBYRXhpZgAATU0AKgAAAAgAAgESAAMAAAABAAEAAIdpAAQAAAABAAAAJgAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAQKADAAQAAAABAAAAQAAAAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCABAAEADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwC3aH/R4v8AcH8qtoao2h/0eL/cH8qtI1USWkNWENU0NWIzTAuxmrMZqjGatRmmIuoaso1UozVhDVIDz+0P+jxf7g/lVpGqjat+4i/3B/KrCtWQ2XEarEbVSRqsRtTEX42qzGaoxtVqJqYi8hqdDVRGqdGqkM8+tW/cRf7o/lVlWqlan9xF/uj+VWFNZDZbRqsxtVJDViNqYi9GatxmqEbVajamKxejNWENUo2qyhqkVY8+tj+4i/3R/KrCGqdsf3Ef

Sample Augmented Reality response:

http://tetra.ice:8080/bridgeit/mobile.html#icemobilesx_!r=%7B%22_loc%22:%5B%22Aug312%22%5D%7D&!h=%23_ar

Issue filed with iUI and change checked in locallyL

http://code.google.com/p/iui/issues/detail?id=355

— samples/html5/bridgeit/src/main/webapp/iui/iui.js (revision 37818)
+++ samples/html5/bridgeit/src/main/webapp/iui/iui.js (working copy)
@@ -172,7 +172,10 @@
nodeId = view;
node = $(nodeId);
}

• if (!node) log("gotoView: node is null");
  + if (!node) { + log("gotoView: node is null"); + return false; + }

  if (!iui.busy)
  {
  iui.busy = true;

This appears to fix navigation within the BridgeIt demo, but may have other side effects.

Android Chrome loads the device return URL as a new document rather than a #fragment navigation within the existing document (iOS behaviour). This means that JavaScript callbacks registered with the deviceCommand invocation are lost when the page is reloaded.

Alternatives:

global callback function that switches based on name of input field.

bridgeit.addEventListener("load", callback)

where callback is constructed each time the page is loaded will work in many cases, but may be unpredictable due to missing data from user input or other cases. Ultimately we want to encourage a stateless programming model that makes use of local storage.

iUI was causing some complication on android: during the page load process, iUI will replace the hashcode after a delay. The variability of this delay could interrupt the processing of the deviceCommand #fragment response.

Android protocol changes complete. snv 38239.

Cloud registration returned on any call to sx, provided that the credentials are available.

The CloudPushId is now maintained in local storage so that it is preserved on a page reload. This should be considered for an ICEpush feature rather than being implemented in bridgeit.js.

To support error code returns the URI syntax will be extended to include the following addition reserve words.

!s=done|fail|wait
!sd=status detail message

It will be necessary for the JavaScript layer to process these additional parameters.

Android now supports the return status !s= and !sd= parameters. svn 35848.

Summary of current protocol parameters in the URL:

Request from the browser to BridgeIt:

c: command name with parameters
u: URL to POST command data
r: URL to return to in the browser
p: parameters for POST to server
o: options affecting overall request processing
s: splash screen parameters
h: echo value

Response from BridgeIt to the browser:

<id> : result of command associated with id
!r: server response text
!p: preview/thumbnail of captured content (data-url)
!h: echo value of h request parameter
!c: cloud push ID
!s: status code
!sd: status detail

If request options contains enc=base64, the entire response URL should be encoded as #icemobilesx_<data> where <data> is in Base64 format with "." in place of "/" and "~" in place of "=".

Enhancements are complete.