Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

Requirements:

  1. The mobile solution needs to have the mobile solution type
  2. If the data shown in mobile app is user specific the mustAuthenticate property has to be enabled
  3. The mobile plugin has to be installed

Once the solution type is set to mobile the:

  1. solution explorer view will filter to show only the capabilites possible in mobile. (API wise)
  2. form designer/palette will change to place mobile interface elements utilizing a different layout manager.
  3. each form shown in the mobile client without passing a (related) foundset (like first form) will need a offlineDataDescription.addFoundSet call in the mobile service solution

Limitations:

  1. A records dataproviders should be accessed through the record itself, which means first a record object needs to be retrieved before the dataproviders from such a record should be accessed.
    example:
    var rec = foundset.getSelectedRecord();
    if (rec.phone_direct) plugins.mobile.call(rec.phone_direct);
    
    So try to avoid direct access of those variables, so use "record.column"  instead of just "column" for the selected record in a form method.
  2. new records pks always become UUID's values, while UUID are not required for pks for any data delivered by the server, the service solution would need to translate UUID's to local ids upon retrieval of new records.
  3. only single pk are supported on entities. (no compound pk support)
  4. no SQL support, everything has to happen via relations/foundset navigation from the provided root foundset by the service solution.
  5. no calculation support. (yet, is planned)
  6. only custom valuelists are supported, but application.setValueListItems is present
  7. Be careful with the Form variables or Global variables names, prefix or post fix them with an nice value so that you don't have global variables named "status" or "document" these names must be avoided because they collide with the window.xxx object of the browser.

Within these limitations at form design and API level all business logic should work.

Supported plugins:

  1. Mobile plugin (especially designed for using mobile device capabilities, like GPS and making calls)
  2. Dialog plugin .showWarningDialog function
Other pages
Unknown macro: {list-siblings}


  • No labels