genexus for smart devices course - events in smart devices
Post on 04-Jan-2022
6 Views
Preview:
TRANSCRIPT
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…
top related