Developer Documentation

A mobile form submission includes the data for each and every control in the submitted form that can store a value. Even controls with the visible="false" attribute are accessible to an associated workflow script when the parent form is submitted.

The form variable in the script triggered by the mobile form stores the mobile form submission as a hierarchy of map objects with a map object for each each of the controls in the submitted form. Each control map object has the same fields:

The map objects for controls that can store values also have the value field, which is the string representation, if applicable, of the single submitted value of the control.

To access mobile form submission data in your workflow script, use the dot operator to retrieve the fields of the nested map objects in form. The mobile form below includes one each of the simple controls available in mobile forms.

The following workflow script accesses and traces the values submitted in the controls of the form above:

Scalar values submitted in various control types are accessible as the value field of the map object that corresponds to the given control in the submission object. The value field of a control map object is the string representation of one of their attributes. The table below displays the attribute that is submitted for simple controls.

Complex mobile form controls are ones whose input is submitted to the Mobilengine Cloud not as a string but as structured data. To reliably access their generated and user-entered data, you need to be aware of the unique structure that they are mapped to in a workflow script.

A dynamic list control is accessible as a list of map objects, one map for each of the generated rows of the dynamic list control. Each of these maps has a generated zero-based index appended to their nid field in angle brackets (e.g. dynamicListCherry<2>). The actual controls generated in the dynamic list control are accessible as nested maps themselves inside the indexed map objects.

The dynamicListCherry dynamic list control below generates a labelDates label and a dpickerElderberry datepicker control for each row returned by the query in its generator attribute.

The fruit reference table that determines how many instances of the template in the dynamicListCherry dynamic list control will be generated currently has three rows. This means that the dynamicListCherry map object in the varSampleMobile submission will be a list with three maps indexed from 0 to 2. The format of the first of these indexed maps is displayed in the screean area below.

dynamicListCherry:
[
  {
    parent:<<recursion>>,
    type:"panel",
    nid:"dynamicListCherry<0>",
    npth:"varSampleMobile/root/dynamicListCherry/dynamicListCherry<0>",
    labelDates:
    {
      parent:<<recursion>>,
      type:"label",
      nid:"labelDates",
      npth:"varSampleMobile/root/dynamicListCherry/dynamicListCherry<0>/labelDates",
      value:"Mangos get yellow at "
    },
    dpickerElderberry:
    {
      parent:<<recursion>>,
      type:"textbox",
      nid:"dpickerElderberry",
      npth:"varSampleMobile/root/dynamicListCherry/dynamicListCherry<0>/dpickerElderberry",
      value: "2015-08"
    }
  },
...
]

To access the control values in a generated map inside the list that represents the dynamic list control in a workflow script, you could use the indexing operator to target a specific generated map object. The following workflow script statement accesses and prints the date value in the first of the datepickers generated in dynamicListCherry above:

A more realistic use case with dynamic list controls is to iterate over all the items in the dynamic list using a foreach statement:

The script above will trace the input in the datepicker controls generetaed in the dynamicListCherry dynamic list control.

"2015-08"
"2010-06"
"1999-12"

A location control, a hidden control that adds geoposition data to the submission object, is represented in workflow scripts as a map object, with its data accessible via a map-type value property.

value: {
  raw_gps: {
    valid:validity
    dtuTimestamp:gps-dtu
    dtlTimestamp:gps-dtl
    latitude:gps-latitude
    longitude:gps-longitude
    altitude:gps-altitude
    accuracy:accuracy
    provider:provider
  }
  raw_cell: {
    mcc:mcc
    mnc:mnc
    lac:lac
    cid:cid
    dtuTimestamp:cell-dtu
    dtlTimestamp:cell-dtl
  }
  latitude:final-lat
  longitude:final-long
  altitude:final-alt
}

The locationNectarine control above would be traced to the console in a workflow script in the following structure:

locationNectarine:
{
...
  value:
    {
      raw_gps:
        {
          valid: true,
          dtuTimestamp: 2015.08.31. 8:19:04 (Dtu),
          dtlTimestamp: 2015.08.31. 10:19:04 (Dtl),
          latitude: 47.5076177,
          longitude: 19.0125684,
          altitude: 0.0,
          accuracy: 30.0,
          provider: "network"
        },
      raw_cell:
        {
          mcc: 0,
          mnc: 0,
          lac: 1200,
          cid: 13805588,
          dtuTimestamp: 2015.08.31. 8:19:05 (Dtu),
          dtlTimestamp: 2015.08.31. 10:19:05 (Dtl)
        },
      latitude: 47.5076177,
      longitude: 19.0125684,
      altitude: 0.0
    
}

The value map object that represents the data submitted to the Mobilengine Cloud in a location control has a nested map object for the raw GPS location data and the raw cell location data, and one float value for the final latitude, longitude and altitude, calculated using the two sets of acquired data.

A photo control is represented as a list of map objects in a workflow script, one map for each image submitted with the photo control. The data submitted to the Mobilengine Cloud in each image accessible via its nested value map.

value: {
  mediaid:mediaid
  summary:summary
  dtuShoot:dtuShoot
  dtlShoot:dtlShoot
  location:location-map
}

Each image submitted using the photoOlives photo control above would be traced to the console in a workflow script in the following structure:

photoOlives:
[
  {
    ...
    value:
      {
        mediaid: {83120c6b-9a2a-42ee-bdf6-967ad0167fee},
        summary: "",
        dtuShoot: 2015.08.28. 14:26:17 (Dtu),
        dtlShoot: 2015.08.28. 16:26:17 (Dtl),
        location:
          {
            ...
          }
      }
  }
...
]

Each and every successful mobile form submission contains metadata. The submission metadata values are accessible as direct children of the form variable, outside the root map.

This is the metadata portion of the sample submission used in this chapter, traced to the console:

{
  ...
  controlSubmit: <<null>>,
  dtuSubmit: 2015.08.15. 12:59:35 (Dtu),
  dtlSubmit: 2015.08.15. 14:59:35 (Dtl),
  user: {id: 31, name: "petar.hoyt@gmail.com"}
}