GeneXus for Smart Devices course - Architecture of Smart Device Applications The problem to solve is the construction of a backend for a real estate office, with a web section and another section for smart devices, to be used by the real estate agents in their external work. For this purpose, we create a KB, the Property transaction to record the real estate properties on sale or for lease, and we also define that the backend web will be generated in ruby, in the cloud.
To implement the smart device section, we apply the WorkWith pattern for Smart Devices to the Property transaction and we create a Dashboard object as the access point. To start with, we decide to generate the default platform only in Android. To think of the underlying architecture in smart device solutions with GeneXus, we should start with what we know about: web applications. We have a server and a customer. On the server we have the web application and in the customer we have a browser. We execute the web application starting with a URL, for instance the one in the home page, the web panel, or by way of example- that of the transaction for entering real estate properties. It is probable that the object required will have to query the database. Then it returns the information to customer, for the browser to set up the layout (HTML) that will be presented to the user as a reply to his/her request.
One possibility is to execute the application on the smart device as a web mobile application, through the device s browser. But if we want the application to be native, interactive with the device s functionalities (like the contact list, the calendar or the GPS), with a look & feel similar to the device s other native applications, then we will have to find a different solution. In order to achieve such solution we will have to go the other way around. Let s suppose we want some of the application s objects that process and return structured data (that is: transactions, procedures and data providers) to have the possibility of being consumed by other different programs. A good choice for this, if we want a light exchange, is to think them as resources (in which case we will be within the Rest design architecture), and expose them as Rest Web Services Rest.
Knowing the URL of any of them, any program will be able to invoke them through the http protocol (with the GET, POST, PUT and DELETE methods as applicable). The service will be executed on the server, with access to the database and returning, as reply to the customer, a file with a representation of the resource (in JSON format). The customer must be able to decode that JSON in order to undertake the actions desired. For instance, if the element invoked was a data provider that in the json returns a list of real estate properties, it is to be displayed on the smart device s screen. So, the recovery and handling of data in the devices will be done through Rest services. --------------------------------------------------- Demo We must remember that when the WorkWith pattern was applied to a transaction the business component was automatically created, exposing it as Rest service. Also, data providers will be automatically created for recovering data from the List node, and from the Detail and each Section in it as well, all of which will also be exposed as rest services. Now, since it s not a browser, what is the application invoking these rest services from the device? Is it capable to decode the json received for designing the screen that is displayed for the user? And, where is the layout design data for deploying the information obtained from the json on screen, following that design?
We have two options: executing a kind of special browser created by Artech, known as KBN, or installing the compiled application. We will analyze both alternatives. In either case a metadata will maintain the information on the objects that make up the application for smart devices, their layouts, URIs (Urls) of rest services that must be invoked to collect data, etc. In sum, the information from WorkWith patterns, and from the dashboards and panels for smart devices will be encapsulated in that metadata. Let s start by the first option mentioned: using the KBN (Knowledge Base Navigator) It is a light interpreter installed in the device, that may be downloaded from the market place corresponding to each platform. It includes the logic for: Reading the metadata, and the images of the application (which with this solution will be on the web server) using Rest architecture (through the corresponding http requests) and executing the rest web services necessary, to obtain the Json files with the replies including the data. And from the metadata read and the data returned, the interface may be set up in the device. Also interpreting certain actions triggered by users when operating the application (by tapping, or selecting an option from the menu) and producing new requests to the server in order to cover the needs expressed by users.
So, the KBN allows users to browse through the smart device applications created with GeneXus. This is because it is similar to a browser, displaying the URLs corresponding to main objects in the application and enabling access to the metadata (present in the server) and work with the entities and relations involved. For instance, it is capable of reading from the metadata the dashboard information of the URL selected (the images to be used - in this case one, corresponding to the only option -, the text in the option, and the invocations to be made by tapping on it), and based on that it sets up and deploys the interface on the device. When the customer taps on the option in the metadata, along with all the design information comes the URI to execute the resource: the data provider corresponding to the List of properties. So, the KBN executes it through Http rest and the reply is a JSON, with the list of properties, set up within the interface whose design was taken from the metadata in the first place. --------------------------------------------------- Demo Because we have a single object for smart devices main the RealEstate dashboard that we created-, then upon pressing F5, the Knowledge Base Navigator will open up in the emulator with a single URL to select: the one corresponding to that dashboard. If we tap on it we can see that the dashboard is loaded with the only configured option that it had.
The other alternative, which can be used when we want to start production, is to encapsulate the URL corresponding to the access point of the application (like the dashboard), along with the whole logic of the KBN and the metadata, into a compilation file in the language of the device and then download and install this compilation. This means that the KBN will not be necessary and we will only need to access the server in order to execute the Rest web services that handle the data (since the metadata will be included in the compiled package that is installed in the device itself). Each smart device platform has its own language and thus its own extension for the compiled file. Now, how do we obtain the compiled file? By indicating the startup object in the properties of the smart device generator. When we do this, the following F5 will cause GeneXus to understand that the application has to be compiled. For ios specifically, a Mac connected online with the development PC will be necessary. But we will be considering this in another video. --------------------------------------------------- Demo So, then, we configure the startup object desired for the smart device generator. That is: the RealEstate dashboard. F5 Since we are prototyping in the Android cloud, when the Developer Menu Web opens up, besides showing the links to execute the web application as usual, we will see the QR Code that encapsulates the URL of this compilation. Therefore, if we have an Android device, it is possible to read, download and install it on the device itself through the program for reading QR codes that is there.
Additionally, as we can see, the startup object selected opens up automatically in the emulator, namely, the RealEstate dashboard. Due to the architecture that we have just presented, by using objects as rest services, and particularly the transactions exposed as business components, with which we are re-using all the business rules, we are also using the full power that the servers offers. In videos to come we will be dealing with the details of prototyping, publication and production rollout To be continued