|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.
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”.