Date: Thu, 28 Mar 2024 21:27:28 +0000 (UTC) Message-ID: <1440930975.10791.1711661248758@911f0a1bad02> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10790_1526675854.1711661248758" ------=_Part_10790_1526675854.1711661248758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
From Servoy 7.3 onwards a Servoy developer can do a remote searc= h for a specific foundset being in find mode and has findstates applied.
This allows to work with live data on the server, like foundsets with a = million records.
The Servoy find/search concept is extended to start with a local find an= d utilize a server side search.
In the mobile solution you set a foundset into find mode and then add so= me criteria then instead of calling search() on the foundset, call remoteSe= arch on the mobile plugin:
if (founds= et.find()) { =09foundset.anumbervalue =3D ">10"; =09plugins.mobile.remoteSearch(foundset,successCallback,errorCallback); }=20
The successCallback and errorCallback params are functions that are call= ed when this remoteSearch is done because this call is an a-synchronize cal= l to the server.
On success the retrieved foundset as argument is not the same foundset s= tarted the find() on, but a new one similar to the one from databaseManager= .getFoundSet().
This new foundset should be loaded into the UI by the success function a= s shown below. Note: returning a new foundset is intentionally to prevent r= emote search result to touch the UI.
The success and error callbacks have the following signature:
/** * @param {JSFoundSet} the foundset that was given to remoteSearch */ function successCallback(foundset) { if (foundset.getSize() >0) { // something found on the server show it in the current form =09controller.showRecords(foundset); } } /** * @param {Number} statusCode The http status code=20 * @param {String} message The message of the error * @param {JSFoundSet} foundset The foundset that was passed to remoteSearc= h */ function errorCallback(statusCode, message, foundset) { =09//do what ever is needed, like showing alert }=20
The plugins.mobile.remoteSearch() will call the service solutions 'offli= ne_data' form 'ws_create()' method with the following signature:
/** * @param data The data that the client send over in the body=20 * @param version The version number of this request * @param method What kind of create must be done=20 * @param authenticateResult Object that is created in the ws_authenticate = method. */ function ws_create(data,version,method,authenticateResult) { =09// Test if it is a remoteSearch call =09if (method =3D=3D "search") { =09=09// Create the FoundSet from the data that is send over from the mobil= e client =09=09var fs =3D plugins.mobileservice.createRemoteSearchFoundSet(data); =09=09// This FoundSet is in find mode, more stuff could be added to it if = you want to filter even more. Then call search() =09=09fs.search(); =09=09// Create the OfflineDataDescription that will be returned for this r= emoteSearch =09=09var retval =3D plugins.mobileservice.createOfflineDataDescription('da= ta_'); =09=09if (fs.getDataSource() =3D=3D "db:/server/test") { =09=09=09// if this was a foundset on the test table, traverse only the rel= ation of "test_to_test2".=20 =09=09=09var traverse =3D new Array(); =09=09=09traverse[0] =3D "test_to_test2"; =09=09=09retval.addFoundSet(fs,traverse); =09=09} =09=09else { =09=09=09// for all other datasources just call addFoundSet which will trav= erse over all relations found in the mobile shared module when encountered = in the records of this foundset. =09=09=09retval.addFoundSet(fs); =09=09} =09=09return retval; =09} }=20
This method is called by the rem= oteSearch call from the client and the OfflineDataDescription object that is returned will be merg= ed into the current synced set the mobile client already has.
For all the pk's that are return= ed the service solution will be ask for to get the latest data for the Reco= rd.
If that record is changed on the= client, the record data that the client had will be kept, to not delete ch= anges the client made to it. If that is not the case then the local storage= is updated with the new record data.
The foundset passed to remote se= arch will go out of find mode and the remote filtered foundset will be give= n to the successCallback function.
All other global/shared foundsets will have all the new records and the = existing records loaded, related foundset will be exactly the pk set that t= he server did return for it. E= xcept new records on the client side, those will be inserted back in.
This does result in that the set of data in the mobile client does grow = with every remoteSearch() call that gets new records, so calling clearData(= ), loadData() or doing a full sync() at certain times is recommended.<= /p>