GeneXus for Smart Devices course - Events in Smart Devices

We can have events with codes executed on the server, and events whose code is executed in

Client (that is: on the device).

We will now consider the type of actions that may be written within a user event.

Let’s imagine that this is the code of the event in Client. Then we also have the web server and

the database. So, what can we do at this point?

Call the server’s rest services, as data providers or procedures to search in the database and

return the information we will then load on a variable. They must necessarily be shown as rest

services. We cannot call an internal procedure from the device. For example, it corresponds to

having written in the Event:

In an event, we may also want to enter a new record in the database without having to

request the user for information. This may be done as in any other GeneXus object, with the

BC’s methods and properties, except for the fact that, here, since we are invoking from the

device, it will also have to be shown as rest service. It is the case of batch updates.

In sum: we may invoke rest services: Data Providers, Procedures and Business Components.

As we have seen, we may also call the WorkWith’s Detail screen for inserting, updating or

deleting. Through the screen invoked, the data is requested from the user to then perform the

corresponding action (which, internally, will mean an invocation to the rest BC).

We are thus invoking the Detail of a WorkWith, to be used internally by the rest BC whose data

is requested from the user through the Edit screen.

We could also want to simply call the List or the Detail in view mode.

Or even objects called Panels for Smart Devices, which are screens with somewhat more

freedom than the WorkWiths we have seen.

… Or we could resort to some of the functionalities provided by the apis, such as displaying a

message on screen, requesting the user’s confirmation to continue, returning to the caller,

refreshing the screen, and adding a contact to the address book, among other possibilities.

Note that from the examples mentioned, except for the refresh, all the actions may be solved

without having to go execute anything on the server.

It is also possible to invoke a web panel, that is, a panel of the web application, which displays

and allows the entry of data for that type of applications (just like the Panel for Smart Devices

in the case of smart device applications).

For instance: here we invoke the web panel called AskDate(). It will be opened in the device’s

browser (with a hidden frame so that it appears more like the rest of the application). In which

other way could we execute a web object, other than through a web browser?

So far we have seen all possible invocations:

To rest services (Data providers, Procedures and Business Components)

To Detail screens of the WorkWith in Edit mode, for Inserting, Updating or Deleting

interactively.

To the WorkWith’s screens to view information (both List and Detail in View mode)

To panels for smart devices, which we will be seeing in a separate video.

To any of the apis for smart devices provided by GeneXus, and through its methods.

And to web panels (this is the only case with server object, not invoked as rest service. The

reason for this is simple: actually, in this case a browser is executed in a transparent manner).

But apart from the invoking commands we have just seen, there are also other ones that allow

for:

The possibility for making a screen control either visible or not.

The possibility of changing the class of a screen control.

The possibility, in all lines of a grid, to go only through those selected by the user prior to

executing the Event.

The possibility of assigning values to variables of simple data types.

And to variables of compound data types (structured or business components).

Lastly, we have the Composite command. What do we need it for?

In GeneXus web applications, when an object called returns an error within an event that is

being executed, the execution is not interrupted and continues with the following sentence.

The developer must handle errors and program the actions necessary in the event´s code.

If we want the execution to stop upon an error in a sequence of calls, in order for errors to be

handled automatically, by displaying them on screen without the need to write any

programming, then we will need a special command to specify this. This is possible with the

Composite command.

It is implemented only in smart devices, where it is mandatory, every time that more than one

invocation is made within the same event.

In this example, we can see a series of commands, some of which are invocations.

When the first invocation fails, due to duplicated key for example, then the error message is

displayed as we see here, and the execution stops (the following invocation is not executed,

nor is the procedure or anything following ahead).

When this is not the case, then the invocation will indeed take place. If, in the procedure, we

specify as the output parameter a variable of the Message data type (the predefined SDT

which, as we saw, is what a BC automatically returns when we execute its GetMessages

method) and load it in the procedure with the convenient error messages or warnings, this

variable will be automatically inspected upon the return of the procedure’s execution. In the

case of error, the execution stops and the messages are displayed on screen.

Otherwise, the following invocation is executed, and so on.

We have just gone through the events whose code is executed on the device. Now is the turn

of the events executed on the server.

They are the system´s events: Start, Refresh and Load.

To introduce them, let´s take the following example:

On the list of real estate properties, we want to show a check box, checked for the most visited

properties, and an image indicating that the property was recently entered in the system.

{demo}

For this purpose, we have added a Boolean variable on the List of the Property´s WorkWith…

And on the Layout we have inserted it…

Along with an image control that we have named Image1 in order to reference it later on.

We created a procedure that receives the property´s identifier as parameter and returns a

Boolean value that is the result of assessing whether the number of visits scheduled for that

property is greater than 2. Here we would indicate the value that we determined would make

the difference between “most visited” and otherwise. In order to make the testing easier we

set a low value for this, so with over 2 visits the True value will be loaded on the variable, and

otherwise the value will be False.

Having done this, what remains is to program so that, when a query is made to the table of

real estate properties to recover each line that will be loaded on the grid, the value of the

variable {point at it} is also loaded with the result of the procedure, in addition to marking

whether the image indicating that the property is new must be shown or not.

But, where do we place this code? In the Load event of the system, the one that queries the

database recovering the records to be loaded as grid lines.

Here we can see all the events defined so far for the List.

They include the three events of the system that have been mentioned.

We choose Load. {do it}

And write:

We press F5.

And we see that Dream is indicated as having over 2 visits on schedule. If we check this we see

that I has … 3. Also, the date of entry in the system is 28 March 2012. If we know that today is

the 29th and that it is considered new when it was entered in the past two days, then … the

image will come up.

Green Tree was entered last year on September 12th, and it appears as having one visit, so it

was not frequently visited … nor is it new.

Magnolia if from last June 26th and it has no visits scheduled, so …

And lastly, Utopia is indicated as most visited. Therefore, we will have to find over 2 visits, and

its date of entry in the system must be prior to 27 March 2012…

Which, as we see, is the case…

In conclusion, when we have a grid with attributes on a screen, what we are implicitly saying is

that the table of the database corresponding to those attributes (and occasionally its extended

table) must be accessed, and of all records fulfilling the conditions, return to the device a

collection with the values requested.

A Data Provider Rest, implicitly created and generated by GeneXus in a way transparent to us,

is in charge of recovering the data and sending it to the device.

This Data Provider executes the code of the Load event for each record in the table recovered

to be included in the collection returned. This is how it loads, for each real estate property, the

values True or False, of both the mostVisited variable as well as of the Visible property of the

Image control.

Therefore, this code is executed on the server, so we can use the commands we usually apply

in the case of web applications. For example, let´s note that here we are invoking a procedure,

IsMostVisited, which is internal.

The Start will also be executed on the server, but only when the screen is executed for the first

time. That is to say, the first time that this WorkWith screen is opened.

Instead, the Refresh will be executed every time that the screen has to be refreshed. The Load

(the grid´s load) will be executed immediately following the Refresh.

This about covers all the aspects we wanted to cover regarding events in the various screens of

a WorkWith for Smart Devices. Everything we saw also applies to the events of Panels for

Smart Devices.

Would you like to implement panels to allow for data requests from the user, to show data not

necessarily originating in one or several tables of the database and to make your screens more

flexible?

To be continued…