Understanding OutSystems mobile internals

Preface : Build a ToDo App using OutSystems

Colin Hobday
4 min readMar 25, 2019

I followed the guide in the OutSystems documentation for ‘Developing Mobile Apps’ (https://www.outsystems.com/learn/courses/115/developing-mobile-apps-outsystems-11/). I stopped at Mobile UI development 2.

This app allows a user to create, update, list and view ToDo items. The data is stored in a remote database in an OutSystems environment.

Screen Flow of the ToDo App

Outsystems and Apache Cordova

It’s important to understand how Cordova works, because OutSystems uses the Cordova framework to handle interactions with the mobile device. Apache Cordova is an open-source mobile development framework that allows mobile development using standard web technologies. Cordova applications execute within wrappers targeted to each platform.

Cordova Application Architecture

High-level structure of the mobile app

Let’s discuss the structure I found when decompiled the .apk file of the app using ApkTools.

Most of the media files can be found in the /res folder. The most important file here is in res/xml/config.xml. It is the main configuration file that Cordova uses to configure an application and customize project project. There are application configurations for

  • name, description, author, alternative versions for IOS and Android, etc
  • starting page configuration, which interestingly points to an external address , e.g. https://pilot-colin.outsystemscloud.com/ToDo_ch/
  • splash screens and icons
  • configuration of plugins, mostly from OutSystems and Cordova
  • platform preferences
  • access and what type of URLs are allowed
  • hooks that respond to events

The assets /www folder seems to contain all the web artifacts, such as html, css, images, and js files, including the Javascript files for the plugins. However, it does not contain the platform build elements. Most of the code is not very readable, being typical of generated code.

The /smali folder contains the compiled android code. However, this is probably not as important as it is only android code to load the webview. We can look at this in smali/com/outsystemscloud/pilotcolin/ToDoch2/MainActivity.smali

JavaScript files

Under assets/www/scripts, there are many Javascript files (.js) They follow the classic Model-View-Controller (MVC) pattern. If you need an explanation of this pattern, please refer to https://hackernoon.com/from-mvc-to-modern-web-frameworks-8067ec9dee65

The Javascript files contain definitions for Javascript modules (not the same as OS modules). The files ending with .model.js describe Models, while those ending with .controller.js describe Controllers. Those ending with .mvc.js have descriptions for Models, Views and Controllers, and there is one for each screen in each flow. Those specific to my application are prefixed with my application name, e.g. ToDo_ch.model.js, while those general to OutSystems are prefixed with OutSystems, e.g. OutSystemsUIMobile.controller.js

Example of start of Javascript module definition

The module definition for the View describes UI components. Each UI component configures an OutSystems Widget (which extends a React.js element). It also defines the CSS dependencies in View.getCssDependencies — e.g. css/ToDo_ch.ToDo_ch.css

Example of UI Code describing an OS Widget

The module definition for the Controller contains code that will trigger server and data actions. It’s good to see that these are called asynchronously and wrapped in exception handling.

Example of controller code triggering a data aggregate

The Javascript module definition for the Model contains descriptions for objects used in this screen. However, it accesses definitions which are mostly held in the model file for the OutSystems module, e.g. ToDo_ch.model.js

Next time? Rebuild using Cordova

Random Thoughts

OutSystems offers a complete, low-code application delivery platform to develop and deliver a mobile app, both front-end and back-end. It claims to offer a standard architecture with no lock-in. However, I would argue that it would be more locked in than apps developed in-house, since users are not normally able to access the generated codes (but seem to be able to do it on stopping a subscription). Furthermore, the generated codes make extensive use of Outsystems components. The MVC pattern also relies on the web application server which resides in OutSystems. It uses an SQL Server database (if a license is purchased), so data can be migrated.

Conclusion

It’s quite clear the structure of an OutSystems mobile app builds on the basic structure of a Cordova app. Javascript code is probably generated for each UI component, each data model, and to link the screens and actions together. This code is more flexible than readable, as one would expect of generated code. It also builds on highly optimized OutSystems codes for standardized UI components, styles, icons and designs.

References

I create a cordova app following https://cordova.apache.org/docs/en/latest/guide/cli/index.html

Can get the css, html, js from apk using apitools

Cordova Directory Structure — https://cordova.apache.org/docs/en/latest/reference/cordova-cli/index.html#directory-structure

Cordova config.xml description — https://cordova.apache.org/docs/en/8.x/config_ref/index.html

Running Android emulator from command line — https://developer.android.com/studio/run/emulator-commandline

--

--