This article was sponsored by OutSystems. Thank you for supporting the partners who make SitePoint possible.
If you’ve never heard of low-code before, join the club. In July of 2016, OutSystems asked me to review a pre-release version of their low-code tool. I had no clue what low-code was or why these people were even talking to me.
Turns out that low-code platforms are essentially drag-and-drop IDEs. They’re designed to help developers breeze past a ton of boilerplate work and focus on the meat of their web products. And OutSystems was about to upgrade their offering to include mobile applications.
They reminded me that I was a native mobile developer, and that’s when it clicked. They wanted to know if their platform held up to snuff. Suffice it to say that while I enjoyed the speed of low-code, I found a lot of questionable omissions from their product as well as performance issues.
They worked their asses off to make improvements in time for the release, and sorted out a lot of my original concerns. I was, and still am impressed with the final product. And I wanted to show the SitePoint community how to accomplish common mobile patterns using a low-code platform like OutSystems.
While these techniques apply exclusively to OutSystems, competitors such as Mendix, AppGyver, and others offer similar features that loosely map to those you’re about to see.
Set Up a Local Database
If you’ve worked with Core Data on iOS, then the low-code approach to ORM should feel familiar. For those on Android, if you’re still writing SQL queries by hand, I’ve been there. I recommend trying ormlite, greenDAO, SugarORM, or something similar.
In low-code, your back-end and front-end merge into one editor, so they take care to delineate the boundary between cloud and local storage.
I created a database entity,
Book, and populated it with some attributes. OutSystems generated CRUD actions for me automatically:
The orange circle icons represent server-side actions, and you’ll see how they come into play later on. So, I have a
Book entity that exists in the cloud and it can represent a single work with a title, author, and ISBN.
If you’ve been around the client-side block long enough, you know that clients don’t replicate central databases. And they don’t always require a mirror image of each model, either. Some data can remain on the server to reduce response sizes.
In OutSystems, I can create a local entity based on an existing cloud entity in two clicks. When I did that, the IDE automated a few additional steps for me:
The IDE prepended
Local to the entity’s name. This nomenclature helps me keep track of which database I’m touching: server or client. The IDE also generated similar CRUD actions to those available on the server, except these white-orange icons indicate local actions.
I fleshed out my data model by adding an
Author entity and forming a relationship between
Author. Here’s the current map:
To use the data, the IDE lets me define custom actions to retrieve the data, cache it to the local database, then read those values into local variables. Here’s an example of a local action that fetches books from the central database, then caches them as local versions:
Their tool also enables developers to implement offline capabilities using an offline-sync paradigm. After time spent off the grid, the app will execute a custom local sync action when it detects the presence of an Internet connection.
Thankfully, we get to implement the syncing logic ourselves. But the approach may be as simple as refreshing the cache or as advanced as data merging with conflict resolution.
Handle Universal Layouts
As mobile developers, we have two approaches when it comes to supporting multiple screen sizes: separate apps for tablet and phone or a universal app. OutSystems handles both tactics:
In universal applications, the platform provides two client methods,
isPhone(). These permit us to navigate the user to an interface we’ve optimized for their device. Here’s how that logic looks in the starting template:
Neither a phone nor a tablet? Set your hair on fire.
Here’s a video of that logic in action:
Can’t see the video? View it on Dropbox.
Alternatively, we can avoid duplicating interface work by using conditional logic to hide elements on the device for which they aren’t appropriate. Let’s say I wanted to hide the logic diagram on tablets since the image deteriorates when stretched… and I was too lazy to bug the designer for a high-res alternate.
To do that, I needed to modify the
Visible property on the container (
div) that wrapped the image. By default,
Visible is set to
True, but I could edit the expression that defined the property:
After I clicked the x.y symbol, the IDE revealed the expression editor:
IsPhone(), which returns
When I deployed and ran the in-browser demo, the image was absent when simulating the iPad, as expected:
Access the Camera
Since OutSystems applications are web-based hybrid solutions, they rely on Apache Cordova for native integrations like Camera, GPS, and notifications. The IDE did not bundle any plugins by default when I created the application, so I had to add them myself.
There’s a lot of small steps in this part, but I promise it’s worth it because surprise, there’s a puppy at the end 🐕.
To add a camera integration, I browsed the Forge. This is OutSystems’ repository of Open Source plugins. Here’s what that looks like within the IDE:
It’s an embedded frame, so you can browse these on their website, too. I clicked on the Camera Plugin to discover that it’s an OutSystems wrapper around Apache Cordova’s base camera plugin. On the Forge, they provide a few more details like reviews, usage instructions, and occasionally screenshots:
I clicked INSTALL and it showed me a progress bar as the add-on downloaded to my local environment:
With the Camera Plugin installed, I needed to link it to my mobile application. I did this by modifying my application’s dependencies:
I checked the top-most box to include everything the plugin offered. It came with a mobile screen and two client actions. I needed the actions for sure, but could probably have left the license view behind. Ain’t no body got time for dat license reading.
The next thing I needed was a classic camera button. This button would initiate the photo-taking action. I dragged an Icon widget into the top-right action area, then filtered icons by query:
onhover, as well as some unique ones like
I created a new action to handle the click event, and populated it with the following logic:
To see the resulting photograph, I needed a UI element to present it on screen. I dragged an Image widget into the layout and assigned the local screen variable as the source of image data.
With everything in place, I was ready to test out the application. I couldn’t test this feature in the browser, so I’d have to run the app on my device. OutSystems provides two ways to accomplish this: I could generate a debug build and download the APK to my Android device, or I could run the app within their mobile companion, OutSystems Now.
Here’s what those options look like:
To speed up the process, and since I already had installed OutSystems Now, I launched the companion app and ran Sitepoint from my phone. The final result is captured in the adorable video below.
Can’t see the video? View it on Dropbox.
A Lot More
I don’t enjoy sounding like a sales guy, but there’s a lot more you can do with low-code that I haven’t detailed here. And what you’ve seen isn’t limited to OutSystems, either. Competitors offer similar features and workflows, too. However, these tools primarily target enterprise organizations.
If you want to try them out, you can do what I did and build an app using OutSystems’ free personal edition.
Do you think low-code is worth your time? Let me know in the comments.