Ask Reuben
Single Threaded
I want to start something in the background and have my Genero application respond when it is finished.
Can I send a message to the running Genero applications?
A common request is for a Genero application to start something in the background and react when that background process has finished. That might be something like running a batch process in the background and display a message to the user when it has finished. There are many variations on this request but the common element is to have the Genero application respond “straight away” based on some event.
The key to understanding why you can’t code what you are trying to code, and the key to understanding how to implement something that will achieve the business requirement, is to note that the Genero fglrun process is single threaded. It is only ever doing one thing at a time.
This concept of the Genero process being single threaded has many benefits. At any point in time you can examine a running Genero application and say at this precise point of time it is executing this line of code.
- When using the debugger you can step through each of these lines of code one at a time. This is true even when form and combobox initialisers are called that are not direct descendants of a MAIN.
- You can setup your code editor to jump to function definitions and navigate the code just like the runner does.
- When performing data entry at the user interface, you can determine the line of code that has the dialog e.g. INPUT / MENU / DISPLAY ARRAY etc statement that is waiting for the user response.
- When an SQL statement is executing on the database, you can determine the line of code that is doing the SQL and waiting for a response.
- When fglrun is waiting for a RUN (without using WITHOUT WAITING), you can determine the line of code with the RUN statement.
- When waiting for the front-end to respond with a front-call result, you can determine the line of code that has the front-call.
- When making a web service call and waiting for the response, you can determine the line of code that is making the request.
Note that these examples have Genero waiting for a response. If the Genero application was to respond “straight away” when some other event occurs, what should happen on the line of code that Genero was waiting for a response from? If the user is in the middle of typing a sentence, they don’t want the Genero program to go off and do something else because some other process has finished.
I gave the example earlier of “running a batch process in the background and display a message to the user when it has finished”. When the user is in the middle of typing a sentence, they don’t want to have to suddenly respond to a dialog that says the batch process they started earlier has finished.
The key is to change your mindset from respond “straight away” to responding when the program is ready to respond. Think of the appropriate action being like when your partner asks you to do something and you respond I will finish what I am doing first!
A Potential Solution
I think the solution to these types of problems is to create a messaging system. Create a database table that has the following …
| Name | Description |
|---|---|
| Id | A unique identiifer |
| To | Who is the message to. Potential data values could include process id, user name, program name |
| From | Who is the message from. Potential data values could include process id, user name, program name |
| Sent When | Date and Time message is sent |
| Read When | Date and Time message is read |
| Message | The content of the message |
Other potential columns might include a type or code of the message, an expiry for the message.
Decide on the convention you are going to use for the from and to columns. You could have multiple columns indicating different types of recipients or senders (process id, user name, program name etc) and you could have wild-cards.
Decide on the convention you will use to indicate if a message has been read. Do you delete the message after it has been read, or do you update a read time and archive and purge later.
To write a message is easy, INSERT a row or rows into this database table.
To read a message is equally easy, when you are ready to receive a message, SELECT a single row from this database where you are the intended recipient (based on the to column(s)). You are not ready when a SQL statement is executing, when a blocking RUN statement is running, when a front-call is running, when waiting for a web service response you are not ready etc. When a dialog statement that involves typing you can indicate that you are ready if there has been no activity by using the ON IDLE block. In a MENU you can also potentially use the ON TIMER block.
With the parameter for the ON IDLE or ON TIMER block select a value that is a compromise between checking too often and potentially clogging up the network versus being able to respond timely. I’d suggest 15 seconds as a starting point, others may suggest longer or shorter values based on their experiences.
Update the received time or delete the message to indicate it has been read.
Implement a periodic tidy-up process to handle unread messages and/or to archive or delete successful messages.
You could implement the INSERT and SELECT behind web service calls in order to prevent the programs having direct access to the messages database table.
Decide if a registration process is necessary. Registering allows messages to be sent to all registered users. This is how you would send messages such as “Please logout by 5pm so some system administration can take place” to all users.
Mobile Push Notifications
A mobile developer might be aware of the Push Notifications facility within Genero Mobile. This is a form of messaging system. The Genero Mobile app must register to receive notifications and when a notification is received by the mobile device the special predefined action ON ACTION notificationpushed is triggered. With this implementation be careful of using the notificationpushed action in an INPUT / CONSTRUCT / DISPLAY ARRAY where you might be typing. By discipling yourself and restricting its use to MENU and DISPLAY ARRAY then you eliminate the possibility of a users typing being interrupted by this action.
A future potential enhancement of Genero is to provide a means to trigger the notificationpushed predefined action rom outside a Genero application so that non mobile applications can also receive push notifications. A similar potential enhancement might be to display the equivalent of badge numbers in the Chrome Bar or Application List.
Summary
Our tag line says “The Power of Simplicity“. Being single threaded aids in the effectiveness of which applications can be developer in Genero. That simplicity might mean not being able to implement certain things as you would initially like when you first draw it up. However you can normally meet the business requirement by stepping back and asking yourself, what is it I am trying to achieve?. These requests to have the Genero application respond “straight away” can normally be met by changing the requirement to have the Genero application respond when it is “ready to respond”.