Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Genero Mobile - Pool Doctors Demo  (Read 9088 times)
Tim B.
Posts: 67

« on: January 23, 2017, 03:52:41 pm »


We're just starting out on GM and I'm looking at the Pool Doctors demo which seems to be the sort of thing we are aiming at developing.  I'm going through the videos now.

Of most interest to me is the back-end web services which we need to send & receive data.  The Pool doctors PDF contains links to the program ( and a web service (, but both of these return 'Application not found'.  Is it available any more?

Additional, regarding web services, we were wondering which route to take (SOAP or JSON), as we don't want to go down the wrong one.  Are there any general recommendations on which one we should choose for this sort of app?  I've not used JSON in 4Js before, but have in PHP apps.  Likewise I have created and consumed SOAP services in 4Js in the (distant) past.  Our app will be for a driver delivering & collecting supplies on a route.  Each drop on an route would have have one or more items to supply, collect or service.

Any advice to get us on the right path much appreciated.


Sebastien F.
Four Js
Posts: 465

« Reply #1 on: January 23, 2017, 04:05:07 pm »

Hi Tim,

I let Reuben comment about the very nice Pool Doctors demo...

If you are interested in mobile/server database synchronization based on Web Services, you can have a look at the Genero "Contacts" demo:

It uses RESTful Web Services, with JSON or XML serialization...

Leo S.
Four Js
Posts: 102

« Reply #2 on: January 23, 2017, 04:08:09 pm »

Hi Tim, regarding a recommendation about writing a web service with JSON vs SOAP/XML I'd always recommend JSON because of the simplicity.
The VM run time has build in support for reading a JSON string directly into a 4GL record (util.JSON.parse) and can directly emit a JSON string from a 4GL record (util.JSON.stringify):
define your 4GL record structure for your data exchange and its automagically converted to the right JSON with a single code line.
This is very powerful and keeps the numbers of required code lines small.
I'd only go the SOAP route if I would have to, if there is an existing web service emitting SOAP and mandatory to work with.
Kind Regards, Leo
Tim B.
Posts: 67

« Reply #3 on: January 23, 2017, 04:20:14 pm »

Thank you both for your quick and helpful responses.
Reuben B.
Four Js
Posts: 834

« Reply #4 on: January 24, 2017, 01:14:59 am »

Hi Tim,

Latest Pool Doctors sources are available for download from our GitHub page is for the Web Services supporting it a quick enquiry program to view data on the back-end the mobile app

re: the Urls returns data
and the Enquiry program should be

I suggest editing your code to point to your own instance and then you aren't affected by system admins doing things to that server.  (a while back they deleted it, I suspect the PDF was not updated when it was put back with slightly differently URL's hence why you can't find it.).  We should probably just point at the GitHub page rather than having .zip available for download on the Genero Mobile site.

My advise is get web services side running first and use this to sync the mobile app.  Then when you look at the mobile program, in Studio look at the dependency diagram with the filters set so you don't see the libraries.  This will give you a mental picture that relates to the screen navigation.  Secondly note the patterns I repeat, the *list 4gl/per that show rows of data, and the *grid 4gl/per that show or edit one row of data. 

With 3.0 I modified it to use STACK where possible.  If and when I get time I'd like to sub in a different web component (this one to capture signatures as that web component has a mean to view the signature as in image, and also alter the way the web services sync the large photo files.

Re: SOAP or JSON, it is really a SOAP vs REST decision, and then within REST supporting XML and/or JSON and/or other decision. My advise is to look around at public facing API's and note the worldwide trend.  Also consider what happens with the passage of time, ask yourself what would happen if you need to include an extra field in the sync, how do you manage that, do you need multiple versions of the sync running  to support clients using v1 and other clients using v2 etc, or can one version of the sync process run that supports multiple versions of the client.


Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of
Contributor to
Tim B.
Posts: 67

« Reply #5 on: January 24, 2017, 12:28:00 pm »

Thanks very much Reuben.

We would be very interested in using a different signature capture component too.  We are current looking at Signature Pad ( which we use in PHP and works very well.  It outputs the signature as a base64 string (PNG), which we should be able to decode.  I'm hoping it will work, but we're pretty new to GM and web components at the moment, so we're still working out the basics.  We'll look at wc_signature too.
Pages: [1]
  Reply  |  Print  
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines