Working for many clients in different scenarios made me realize all the benefits of following the best practices. Something that I always keep in mind when developing a mobile application.
In this article, I will share those benefits and explain why the Best Practices of Mobile Development for OutSystems are essential to follow.
The first question about best practices is always why they are important?
To answer this question, first, we should understand what the OutSystems platform is and how it works behind the scenes.
OutSystems is a low-code platform which means that it provides us a way to develop applications without needing to write it in the “standard” programming languages (such as .NET or Java). In the platform, we are able to develop applications in a visual way of working with workflows. Basically, what OutSystems does is generating a piece of code for each action that you take in the platform. This comes with some advantages, and those advantages are one of the reasons that we need to focus on and understand the best practices. OutSystems is the one that generates the code and can do a lot of optimizations, which requires much more work and knowledge if developers want to do it in the “standard” languages.
That said and following the same way of thinking OutSystems also provide us with a huge analysis of impact during the development. This analysis can tell everything that might cause an issue; issues that could happen in the runtime, or suggestion/warning to improve the code and avoid future/performance problems.
Some time ago, I got a request from a client who wanted to improve an application that was slow. I encountered the following scenario there:
I knew that the main reason for the slowness could be something specific, but those warnings, undoubtedly, were also part of the problem. We could take this conclusion without any further investigation. I started to work on the project and solved all the performance issues/warnings. And after a month I got to the following scenario:
So, all the warnings/suggestions were fixed and we did not encounter anything else that could be causing the slowness of the application. When we did test it, everything was running smoothly as it should be.
This experience has triggered me to share the most important advice that I can give about OutSystems mobile development, you should follow and apply the warnings/suggestions always unless you have a particular requirement which is not possible to work around it following the best practices.
Followings are other important OutSystems mobile best practices to pay attention:
- Design an Empty State for Content Being Fetched:
This is part of the end-user usability to avoid showing empty elements on the screen. You can create an empty state while your data/content is being fetched, in aggregates or data actions. You always will find the property IsDataFetched which you can use to handle this empty state.
- Design a Lightweight Local Storage
This is something that OutSystems will also try to help you. When you are trying to copy the same structure as you have in a server entity to a local storage OutSystems will warn you that you should not do that. Local storage does not need to have the same structure as you have on the server-side. You should try to denormalize the local storage and keep as minimal as possible to avoid complex queries and also to avoid a lot of JOINs. Of course, high-end devices can handle more data and have more process power, but the low-end devices will probably struggle if the developer does not care about the way that the local storage is built. The local storage should be a lightweight version of the server database.
If you have worked with OutSystems mobile you know that troubleshooting could be tricky when it is not thought beforehand. Before you have a stable version of your application it is good to have a way to see your local storage data.
To work around this situation you can create a simple list and detail screens, that would help you to have a better visualization of what is happening behind your app. This is needed because it is not possible to see the local storage while debugging in OutSystems.
Another tip is to create a client-side logging system to have a better overview when troubleshooting.
Nothing that I have mentioned in this article is a secret, you can find this and more best practices in the OutSystems Documentation.