Chapter 9: Using Mobile Patterns for Fast Mobile UI Development

The OutSystems platform was so well thought out that the development paradigm is shared between reactive web and mobile.

By this, we mean that the implementation follows the same principles and forms in the development of web and mobile applications. For this reason, OutSystems changed its standard of certifications so that mobile has become a reactive specialization.

In this chapter, we will learn how to develop our screens based on pre-built patterns, templates, and widgets, and what considerations we should have for the mobile concept. This knowledge is useful for us to be able to adapt our applications to devices such as mobile phones and tablets, where the resolution and screen size are smaller compared to computers.

The main differences between web and mobile applications relate to the types of applications and their uses, as they fulfill different goals.

In this chapter, we will highlight the particular features of mobile and why it exists, including the following:

• Patterns, templates, and widgets
• Mobile design considerations
• Mobile plugins
• Native app generation
• Exercise 5 – Creating mobile app screens

By the end, we should be able to build our screens for mobile applications in a simple and understandable way, considering the type of device on which they will run.

Technical requirements

Check out the following video to see the code in action: https://bit.ly/3xirZQR.

Patterns, templates, and widgets

Patterns, templates, and widgets work in the same way both on mobile and reactive web (the code generation is a little bit different, but that's abstracted by the platform). The differences are based more on the type of each patterns or widget that we should use after consideration of the devices on which the applications will run.

The OutSystems platform knows that, when we create a phone or tablet-type module, it must adapt the patterns and templates to the selected type, thereby facilitating the developer's selection of which ones should be used, as we can see in Figure 9.1:

Figure 9.1 – Screen templates for a phone or tablet

Basically, smartphones and tablets usually have smaller screens, lower resolutions, and, in terms of usability, the fingers are usually used to navigate the applications.

In light of this, we must pay attention to how the pages are presented in order to have a coherent appearance and the components that provide functionalities (buttons, and links, among others) must be easily manipulated by our fingers (a mouse pointer is significantly smaller, so the way the features are made available must be thought of differently).

In short, it all comes down to the considerations that we must take into account when developing mobile applications, which is what we will see now!

Mobile design considerations

What are mobile design considerations? Basically, these are points to be considered when we develop applications that will run on smaller devices, with different architecture and operating systems than our computers. Furthermore, we must understand that they are applications that are installed on devices and that do not run on browsers.

Process and concept

The first considerations to bear in mind in the development of mobile applications are related to the process and the concept. There is a set of guidelines and principles that we must consider, as follows:

• A mobile app should focus only on a business concept: The app must have important functionality, save time or money, entertain, or clarify. In other words, the success of mobile apps lies in delivering useful benefits to the user. The general rule of thumb is that not everything on the web needs to be available on a mobile app. So, don't build an app until you have a solid idea.
• Focus on something and do it well: This is the most important recommendation. Brainstorming is very good. But when you're through the process, limit the best ideas to one or two.
• Test: Developing applications is not just about writing code, but also testing it, which is essential for internal and business-to-business (B2B) use. Assess whether you have enough time and staff to test and bug the software, especially when developing for multiple platforms.

We must always remember that this step is extremely relevant to the future success of our applications, therefore, we must never accelerate or neglect this phase.

Target audience

Another very important consideration is the target audience. We should always assess whether it will pay to develop a mobile application. Often, we are faced with a scenario in which we only satisfy a small portion of the public, thereby justifying the studying of other approaches or types of application that may correspond to the expectations of the highest possible percentage of the audience.

Design

Something we should always keep in mind is that mobile devices don't have the same features as computers. Usually, the screens are smaller, with lower resolution, and we use our fingers to navigate the applications.

For these reasons, we always have to be careful of the way we design the components we show on the screen. We have to think carefully about how to meet the expectations of end users to avoid frustration. We must always bear in mind that everything must be clearly visible, understandable, and usable.

Security

Mobile devices are generally unsafe.

They store a lot of personal information, are often used on public networks, are hackable, and can easily be lost or stolen.

For these reasons, we must be very careful when developing applications of this type. We must always follow security standards at the highest level, store as little sensitive data as possible (and encrypt what we have to always maintain a calculated trade-off with performance), use development practices that guarantee non-violation, and, above all else, always bear in mind that tomorrow, someone could find a way to break through all our barriers.

From the Forge, we can obtain and install very useful components in terms of security improvement, including the following:

• CryptoAPI: Cryptographic tools to protect your data (formerly known as ardoCrypto).
• AppShield: A component that automatically adds additional layers of security during deployment to make applications more resistant to intrusion, tampering, and reverse engineering. (You'll need a license to activate AppShield. If you don't have one yet, contact OutSystems to get more information on pricing and obtain a valid license.)

We must never forget that a small security breach can become catastrophic at any time, so we must always consider any security-related issue.

Performance

The technology that supports mobile devices, the norm, is not as powerful as that of laptops or personal computers (where we usually run our web applications). This means that processing and response times are often longer than end users expect.

For these reasons, when developing mobile applications, we must consider all aspects that can impact performance, such as the volume of data to be transferred and the components (page complexity) to be rendered on screen.

Often, in order to reduce the time taken to obtain data, we can use a feature that OutSystems makes available, Local Storage (this topic will be discussed in more detail in Chapter 11, Local Storage and Data Synchronization). This feature allows you to have data stored on the device itself, making the process of obtaining data faster, as there is no longer the need to make a web connection to a server to obtain it (we must always pay attention to security, as we talked about in the Security sub-section).

If we follow these considerations, we can sometimes change the approach of developing a reactive web responsive application to developing a mobile application, to be followed as this ensures that we are making our decision to develop a mobile application much more precise, since mobile applications manage to have a much more pleasant and objective behavior when it comes to mobile devices such as tablets or smartphones.

However, we must never forget that mobile devices have a considerable amount of hardware that allows us to power our applications. But for that, we have to be able to communicate with that hardware. How? By using mobile plugins!

Mobile plugins

Plugins allow us to take advantage of our mobile devices' features, such as cameras, geolocation, or notifications.

We always have to check the compatibility of plugins with the distribution modes, and the types of distribution vary between Android, iOS, and Progressive Web Apps (PWAs).

To get the plugins, we must install them from the Forge (the OutSystems repository).

The plugins supported by OutSystems are shown in Figure 9.2:

Figure 9.2 – Table of the supported mobile plugins

When using plugins, we must pay attention to the following:

• Which platform the plugins will run on, since between iOS and Android, there are certain differences and there may not be compatibility for both or there might be configuration differences between them.
• Every time we change, add, or remove a plugin from our applications, we must regenerate a new build and distribute it so that users can install it.

This extensibility of our applications allows us to get much more out of mobile devices than reactive web applications. When evaluating what kind of application we want to develop, the theme of plugins and their capabilities must be taken into account.

Adding plugins to our applications

Plugins are available in the Forge. To use them, we download them, install them in the environment, and then add their functionalities to our applications.

Figure 9.3 – Forge screen to install or download a camera plugin

Now we need to reference the plugin features in the mobile modules where we want to use them.

For this, we open the mobile module, open the Manage Dependencies window, select the producer module (in this example, CameraPlugin), and, in the left window, we select the desired functionalities. At the end, we click on Apply.

Figure 9.4 – Adding dependencies from CameraPlugin to our mobile module

However, the OutSystems platform, when generating a mobile application, uses the following built-in plugins for housekeeping and infrastructure tasks:

Figure 9.5 – Built-in mobile plugins

Note that of all the built-in plugins, only Mobile AppFeedback is configurable, but is only available if we enable the App Feedback feature.

Tip

If we want, we can also create our own plugins, existing on Apache Cordova. If you are curious, you can see the official documentation on plugins here: https://success.outsystems.com/Documentation/11/Extensibility_and_Integration/Mobile_Plugins/Using_Cordova_Plugins.

Thanks to plugins, we can make the most of our mobile applications' potential by using the existing resources of mobile devices.

We must pay attention to the type of distribution to be used, as this can differ for certain plugins between iOS and Android.

Also, if our application is to be distributed as a PWA, we should always check whether the plugin is available for this type of app.

At this point, you might be asking how this distribution works. Let's study this now!

Native app generation

Mobile applications can be generated for different types of distribution and for different purposes.

We can generate them for iOS and Android. Furthermore, they can be generated for testing purposes, for small groups of users, or on a massive scale. This gives us an interesting set of scenarios and possible alternatives for generating our applications.

In addition, we can distribute mobile applications as PWAs without the need for them to be generated. They are distributed by a URL or QR code and opened on our devices.

PWAs also allow these 'mobile applications' to be opened in web browsers and 'installed' locally on computers as apps.

Note: On iOS devices, this is only possible via the Safari browser.

Tip

You can see the official documentation on PWA distribution here: https://success.outsystems.com/Documentation/11/Delivering_Mobile_Apps/Distribute_as_a_progressive_web_app.

To configure and generate mobile app packages, in Service Studio, we must navigate to the detail screen of our mobile application and click on the Distribute tab, as shown in Figure 9.6:

Figure 9.6 – Service Studio's Distribute tab on the mobile app detail screen

In this tab, we can generate the Android and iOS versions of our apps, and we must fill in the required fields in each of the options.

In the case of Android applications, we must fill in the Build Type field (Debug, Release, or Google Play), the App Identifier field (a unique identifier that identifies our application in stores and devices), and the Keystore details (optional) field.

We can see an overview of these configurations in Figure 9.7:

Figure 9.7 – Service Studio's Generate Android app section

Note that for Android versions, we generate an apk file and can install it directly on devices without going through stores (unlike iOS apps).

For iOS versions, of our apps we must also fill in a set of attributes necessary for the correct generation of our application.

First, we must fill in the Build Type field (Ad-Hoc, Development, App Store, or In-House), followed by the App Identifier field (a unique identifier used to identify the application in stores and devices), and then we must upload the certificate used in Apple's iOS developer program, the respective certificate password, and also upload the provisioning profile that matches the certificate.

We can see an overview of these configurations in Figure 9.8:

Figure 9.8 – Service Studio's Generate iOS app section

The, generation and distribution of iOS versions are more complex than for Android versions due to the rules and protocols used by Apple.

Another alternative for distributing our mobile applications is as PWAs.

We must consider the scenario and context of the application (and for which devices) in order to verify that this distribution mode meets our requirements.

However, it is a simpler and faster way to make our mobile applications available to end customers.

We can see an overview of these configurations in Figure 9.9:

Figure 9.9 – Service Studio's Progressive Web App section

Distributing an app as a PWA is more efficient, using only a link or a QR code. The user just needs to open the link on their device and it will be suggested to add it to the main screen.

The same happens if, instead of opening the link, the user chooses to read the QR code.

Tip

If you are curious, you can see the official documentation on generation and distribution here: https://success.outsystems.com/Documentation/11/Delivering_Mobile_Apps/Generate_and_Distribute_Your_Mobile_App.

We can do all these operations and much more through Service Center since it provides a view and a package of features more oriented toward managing the generation of the various existing versions of our mobile applications; that is, more DevOps-friendly.

In short, the OutSystems platform enables the generation and distribution of our mobile applications for Android, iOS, and as PWAs, being fully configurable for the requirements of any platform.

Note that, in the case of PWAs, the pros and cons must be weighed, since we gain simplicity and speed in delivery but lose compatibility with several plugins. Your choice!

Joining all this to a uniform paradigm of web and mobile development, we have everything we need to triumph in solving our customers' problems in a very efficient way.

To show that the mobile development paradigm is extremely similar to reactive web, Exercise 5 – Creating mobile app screens will be the replication of the previous exercise from Chapter 8, Reactive UI Development.

Exercise 5 – Creating mobile app screens

Now, let's apply what we've seen in this chapter in this exercise. For this, we will create the necessary screens, for the Help Desk Mobile application using templates and scaffolding. By the end, we will better understand how fast and easy it is to build the frontend of an application using the accelerators provided by OutSystems.

So, let's start the exercise by following these steps:

1. Create a Phone App with the Help Desk Mobile name:
   • To do this, open Service Studio, click on the New Application button, and then select Phone App.

Figure 9.10 – Selecting the type of application in Service Studio

• Now, we set the name as Help Desk Mobile, fill in a brief description of the application's purpose, select the main color of the theme in the color picker, and click Create App.

Figure 9.11 – Filling in the details for a new application in Service Studio

2. Create a Phone App module and name it HelpDeskMobile:
   • To do this, we open our Help Desk application, click on the Add module button, name it HelpDeskMobile, and select Phone App as the module type. Then, click on the Create Module button.

Figure 9.12 – Creating a Phone App module for the frontend

• Next, we click on the green Publish button so that the module is published in our environment.

Figure 9.13 – Published frontend module

3. Create the home page from a template:
   • First, we have to get the necessary dependencies on Entities and Actions. We click on the Manage dependencies button, select the HelpDesk_CS module, and choose all Entities and Actions related to tickets. Finally, we click on the Apply button.

Figure 9.14 – The Manage Dependencies popup with all dependencies selected from HelpDesk_CS

• Next, click on the Interface tab and right-click on MainFlow, selecting the Add screen option. Then click on Dashboards in the left column and select the Dashboard template.

Figure 9.15 – Template selection popup with the Dashboard screen selected

• Finally, we click on the Create Screen button. The screen now exists inside MainFlow.

Figure 9.16 – Dashboard screen in MainFlow

• Now we have to replace the sample data with the real data. To do this, click on the Data tab and drag and drop the Ticket entity to the top of the list on the left until the Replace data option appears. Then we do the same for the graph on the right. It should look something like this:

Figure 9.17 – Dashboard screen with real data

• Now we can click on the green Publish button. Upon publishing, the button changes to blue, informing us that we can open it in the browser, using a simulator. Let's do this to see the result.

Figure 9.18 – Dashboard screen in the device simulator

Challenge

As a challenge, adjust the card data at the top of the dashboard page to show real data!

This page has a different feature from the others we are going to create. Notice that it shows the symbol of a house in Service Studio. That means it's our home page.

Tip

If we want to define another page as the home page, just right-click on it and select Mark as default screen.

4. Create list and detail screens for tickets:
   • For this purpose, we select the Interface tab and double-click on MainFlow to open the canvas. We then drag and drop the Ticket entity from the Data tab to the canvas.

Figure 9.19 – MainFlow canvas with the Tickets and TicketDetail screens created with drag and drop

• Now, we open the TicketDetail screen by double-clicking on it in the Interface tab and clicking on the Widget Tree subtab so that we have the HTML component tree view visible.

Figure 9.20 – Widget tree view for the HTML components on the TicketDetail screen

• We select the containers that group the Created By, Created On, Updated By, and Updated On attributes, right-click on them, and select the Delete option.

Figure 9.21 – Delete frontend attribute components from the TicketDetail screen

Note

These fields that we eliminated are automatically filled by the Action that we created in the HelpDesk_CS module and we are going to use them in the Action related to the functionality of creating or updating a ticket.

5. Associate the create ticket Action with the functionality of the Save button:
   • To have functionality on the Save button on the TicketDetail screen, let's open the SaveDetail Client Action on the screen, expand the HelpDesk_CS module, and drag the Ticket_CreateOrUpdate Server Action to the If True branch.

Figure 9.22 – Ticket_CreateOrUpdate Server Action added to the SaveDetail Client Action

• Let's add the existing record on the screen to the Action server input. The input value must be GetTicketById.List.current.Ticket (it is the record that is mapped on the screen through the aggregate that was called).

Figure 9.23 – Mapped input record to the Server Action

• Now, we add an If after the Server Action to check whether it returned success. For this, the verifying condition of this If (that will return to the True branch) must be the verification of the OutputStatusHasSuccess output of the Action.

Figure 9.24 – Verifying the returned status from the Server Action with If

• On the True branch, we insert a success message followed by a redirect to the listing page. In the False branch, we put an error message, map the Server Action error (OutputStatus.Message), and end up in an End node.

Figure 9.25 – Definitions of If branches in verifying Server Action success

6. Finalize the last details:
   • Eliminate the GetUsers fetch data aggregate (since we have eliminated the dropdowns on the screen for CreatedBy and UpdatedBy, we no longer need the data to populate those fields so this aggregate is no longer accurate). Expand the TicketDetail screen, right-click on GetUsers, and select the Delete option.

Figure 9.26 – Deleting the GetUsers aggregate from the fetch data screen

• Link the Add container from the Dashboard page to the TicketDetail page. Open the Dashboard page, select the Add container, and then, in the Properties section, set the On Click event as the redirect to the TicketDetail page. Set TicketId to NullIdentifier(). We can delete the Not Implemented Action from the Dashboard screen.

Figure 9.27 – Defining the Add container link to the TicketDetail screen

• Now we can publish the application. Click on the green Publish button and it becomes available to browse.

Figure 9.28 – Published app ready to use

With these developments, we have a good basis for creating an attractive solution for our customers.

In Chapter 11, Local Storage and Data Synchronization, we will learn ways to optimize our mobile applications using local storage and server data synchronization, thus improving performance.

Then it's all about choosing the most suitable distribution mode for our application in order to reach our customers quickly and easily.

Summary

In this chapter, we saw how the development paradigm for mobile applications is identical to the reactive web development paradigm, which makes the learning curve much easier. The application and use of patterns, templates, and widgets is similar on both types, and in the mobile version, they are adjusted to the devices on which they will be shown.

We also realized that in the case of mobile, we have several considerations, both in the development and in the choice of solutions, in order to deliver the best possible product to our customers.

Something we discovered is the fact that we can take advantage of the capabilities and functionality of the devices on which the applications will be used by implementing plugins.

In addition, we verified that the OutSystems platform offers a good variety of distribution solutions, facilitating our work in delivering our applications to our end customers.

Now we need to figure out how we can improve our functionality through client-side code. This code has a different responsibility than server-side code. How can we do that? Let's see in the next chapter, entitled Client-Side Logic!