App Tethering, threading, REST, automated test and more...

Posted by on in Blogs

Last week we had a very good meeting at the danish users group with almost 30 attendees.
A lot of new people were there, and certainly some people I've known for 20 odd years. 

As always with our one day meetings we had an agenda with speakers from within the group. On the agenda this time I was up first showing and telling how to use App Tethering, in a system that actually could be used in a real life scenario, so in stead of the usual "Hello World" kind of application I built a complete system.

In a traditional standard client/server kind of way, you would have multiple clients connecting to a database server, and when a client updates the data in the database, none of the other clients would know about this until the poll the database.
To show what I meant I built an archery system where a client could enter points for a given archer (this client could run on a mobile phone), and another client was the result list. Needless to say, whenever a client entered points, the result list had to do a refresh.

I expanded this typical scenario. By adding the App Tethering components TAppTetheringManager and TAppTetherProfile to both the projects (point-entering project and result list project), I now had a way to communicate between the two. So the first step was to from the point project tell the result list project, that I have entered points for a given archer. This was done by calling RunRemoteAction, where I specified to the result list "go fetch". Basically this did exactly the same as when a user pressed the "refresh" button, but now we didn't need the person pressing the button.
The next expansion was a bit more involving:
The result list was built in a manner, that after retrieving data from the database, it kept the data in internal memory, and let go of the database. Keeping data in internal memory, involves making some sort of structure. I chose to use generic lists of TObjectList<TArcher> which would allow me to keep the data in memory.
Now on the point program I removed the call to RunRemoteAction, and replaced it with a call to SendString. By formatting the point value and archerID into a very simple protocol consisting of one string, I now sent the value of the point and the ID of the archer to the result list program.
The result list program would receive the information, find in the ArchersList the correct archer, add the point value and sort the resultlist due to changes of the archers positions in the list. This without having to connect to the database for retrieving any data.

The next presentation was also by me. 
In Delphi we had a TAniIndicator component that basically is just a piece of graphics showing the user that something is going on. Very much like the good old screen.cursor := crHourGlass;
Now the problem is, the aniindicator spins very nicely in the main thread.
So if you start the animator it will spin, but if you retrieve data from a database it will stop spinning, as retrieving data is blocking the UI from updating. So the answer is to put this in a thread.
Especially on mobile platforms you see this very nice looking thing, where the entire screen is kind of grayed out, with the spinning wheel in the middle showing that something is going on. 
So I built a screen using rectangles, TShadowEffects, rounded corners and lots of other stuff to produce the end result, and calling the GetData method (connecting to database, firing SQL..) within a TTASK I was able to get the nice effect seen here.

 Spinner

 

The meeting went on, and after my two sessions Thomas Vedel had a session on FireBird 3 and what the differences are between version 2,5 and 3. This was a good session where Thomas went through the differences made in the installer, and the different other stuff that was in FireBird 3. Among the differences there is now a boolean datatype, and a field can be marked as an Identity Field with auto increment scheme. Most likely using an internal trigger and generator.

Thomas then went on with showing how to make a RESTServer using the built in wizards, as well as making a client to talk to the server. This session was an eye-opener for some of the attendees on how easy it is.

Time flies when you are in good company, so Thomas' last session was cut a bit short. This session was about automated GUI testing where Thomas very quickly took us through how to use Test Complete, which was very good for VCL projects, but Thomas didn't think too much of it for FireMonkey projects.

Thanks for all attendees making it fun to present, asking good questions, discussing stuff and for being good friends.

And also a big thanks to www.devart.com for providing the group with a license for Devart EntityDAC to raffle off.

The lucky winner was Palle Jensen, who received the certificate for the license.

Palle Jensen

Blog posted from Gamborgvej 33, 5500 Middelfart, Denmark View larger map


Comments

Check out more tips and tricks in this development video: