Date: Fri, 29 Mar 2024 15:37:33 +0000 (UTC) Message-ID: <772552866.11121.1711726653867@911f0a1bad02> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_11120_1140791791.1711726653867" ------=_Part_11120_1140791791.1711726653867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A records dataproviders should be accessed through the record itself=
, which means first a record object needs to be retrieved before the datapr=
oviders from such a record should be accessed.
Example:
var rec = =3D foundset.getSelectedRecord(); if (rec.phone_direct) plugins.mobile.call(rec.phone_direct);=20
So try to avoid direct access of those variables, so use 'record.c= olumn' instead of just 'column' for the selected record in a form method.= p>
new records pks always become UUID's values, while UUID are not requ=
ired for pks for any data delivered by the server, the service solution wou=
ld need to translate UUID's to local ids upon retrieval of new records.
=
When using "push" from the mobile plugin, the service solution must return,=
for the newly created records, the server side pk; that means,
the ws_c=
reate must return the pk as an object with uuid as key, pk as value, or if =
a bulk update is used in the service solution, ws_update must return the ob=
ject that performSync returns, that is an object with all uuid,pk mapping r=
eturned by ws_create methods;
only single pk are supported on entities. (no compound pk support)= p>
no SQL support, everything has to happen via relations/foundset navi= gation from the provided root foundset by the service solution.
only custom valuelists are supported, but application.setValueListIt= ems is present
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 variable= s named 'status' or 'document' these names must be avoided because they col= lide with the window.xxx object of the browser.
Within these limitations at form design and API level all business logic= should work.
A mobile client works offline, so the first time it must do a synchroniz= ation with the server, this will be automatically called when the client st= arts up.It will then also ask for credentials first if the solution require= s authentications.
With Servoy 7.4 this automatic initial synchronization can be avoided if= the first form doesn't have a datasource, so it doesn't need data. This wa= y you can control the sync and login completely in your solution. Be aware = no initial login will be shown either, if you want to make sure a login for= m is always presented you have to make your own (without datasource) and sh= ow this as first form, calling security.authenticate with the result for fu= ture use.
Servoy mobile assumes the same user is using the same or his own device.=
If this is not the case, i.e. any user can use any device, you will hav=
e to make sure your own login form is present and shown each time the appli=
cation opens.This is possible by making it the first form (without datasour=
ce), you might also want to clear the local storage to make sure no one see=
s other people data.