Hybrid Application Development at Telefónica - Part 2: Technical Aspects
In the
previous article, we discussed our motivation at Telefónica to create a framework on top of Android’s to
maximize performance and provide the
best user experience in a hybrid application.
Now, we will delve into the technical aspects and capabilities of our framework, which have been developed to fully leverage the capabilities of the operative system.
As we mentioned, our framework intercepts any URL before it is loaded in the webview. This feature gives the ability to control how a URL interacts with the native app, allowing us to manipulate the interface or triggering business logic flows.
To do this, our framework has the capability to use URL query parameters or a configuration file that is downloaded when the application starts.
During this process, there are some points that we care about:
Now, we will delve into the technical aspects and capabilities of our framework, which have been developed to fully leverage the capabilities of the operative system.
As we mentioned, our framework intercepts any URL before it is loaded in the webview. This feature gives the ability to control how a URL interacts with the native app, allowing us to manipulate the interface or triggering business logic flows.
To do this, our framework has the capability to use URL query parameters or a configuration file that is downloaded when the application starts.
During this process, there are some points that we care about:
Where the URL will be loaded
We consider this point to be one of the most important, as we do not want all URLs to be loaded in the current webview. Among the options considered are:
For example, if we want to keep the user within the app, it may be appropriate to load the URL in the current webview or create a new one. On the other hand, if we want to take the user to a third-party website, it may be more appropriate to open the URL in the device’s browser.
- Stay mode: Loads the URL in the current webview.
- Internal mode: Creates a new webview and loads the URL there. Simulating a native screen.
- Browser mode: Like internal mode, but with slight UI changes for user awareness in a webview.
- External mode: Opens the URL in the device’s browser.
For example, if we want to keep the user within the app, it may be appropriate to load the URL in the current webview or create a new one. On the other hand, if we want to take the user to a third-party website, it may be more appropriate to open the URL in the device’s browser.
Animation showing a webview using external mode
In any case, it is important to carefully
consider the trade-offs of each option and choose the one that best meets the needs of the app and the user. For example, using
custom tabs allows us to maintain a consistent look and feel with the rest of the app, but it may not offer the same level of control as a fully custom webview. On the other hand,
using a custom webview gives us full control over the user experience, but it may require more development resources.
How the webview will be presented
This only
applies when the navigation mode is Internal, as in the other three modes, we do not have the ability to modify the style of presentation. In this case, we have two presentation modes:
Flow or Modal.
For example, if we want to display a webview as a standalone feature, it may be appropriate to use the Modal mode. On the other hand, if we want to display a webview as part of a larger workflow, it may be more appropriate to use the Flow mode.
- Flow: will make a right-to-left transition and its top bar button will be a back arrow.
- Modal: will display a webview with an transition from bottom to top and an X button to close the webview.
For example, if we want to display a webview as a standalone feature, it may be appropriate to use the Modal mode. On the other hand, if we want to display a webview as part of a larger workflow, it may be more appropriate to use the Flow mode.
What visual components need to be modified
Similar to the previous point, this only
applies when the navigation mode is set to Internal.
We can make certain visual modifications to the interface to enhance the user experience.
We can make certain visual modifications to the interface to enhance the user experience.
- topBar [boolean]: Allows us to show or hide the top bar.
- blockUntilLoaded [boolean]: Determines when to hide the native loading spinner from the webview. If set to true, the device will wait for all resources to be loaded before removing the spinner. If set to false, the spinner will be removed as soon as the page DOM is ready.
- fixedTitle [string]: Allows us to display a fixed title for the page loaded, which will remain even if new URLs are loaded in the same webview.
- keepTitle [boolean]: Allows us to maintain the current page title for subsequent URLs opened in the same webview.
What logic can be triggered
Finally, these parameters will only be
interpreted if the navigation mode is set to Stay or Internal. The following list of parameters can trigger specific business logic flows:
In summary, our framework allows us to intercept URLs before they are loaded in the webview, enabling us to control how the URL interacts with the native app and customize the behavior of their application. The framework can use URL query parameters or a configuration file to achieve this.
Also offers options for deciding where the URL will be loaded, such as in the current webview or in a new webview. Additionally, allows user experience modifications or triggering specific business logic flows.
That wraps it up. We hope you enjoyed this second piece. If you found this article helpful, please give it a clap and share it with your friends!
This article is part of a series. If you haven’t read the first of them yet, it’s a good starting point to understand a little more about our journey and motivations.
[Part 1 — Tips and best practices]
In the final post, we will cover how we easily debug our integrations.
[Part 3 — Debugging]
- renewSession [boolean]: Force to renew the session information, reloading any currently open windows with new credentials after the session is renegotiated.
- refreshOnClose [boolean]: Refreshes the previously loaded URL. If a user navigates from one URL to another URL and the navigation mode for the second URL is set to refreshOnClose, then when the user closes the webview with URL B, the webview with URL A will be reloaded.
- dismissOnBack [boolean]: Dismiss the webview when back button is pressed. This can be useful in web flows where it is desired to return to the starting point instead going back.
- cleanCookiesBeforeLoad [boolean]: All cookies will be cleaned before the URL is loaded.
In summary, our framework allows us to intercept URLs before they are loaded in the webview, enabling us to control how the URL interacts with the native app and customize the behavior of their application. The framework can use URL query parameters or a configuration file to achieve this.
Also offers options for deciding where the URL will be loaded, such as in the current webview or in a new webview. Additionally, allows user experience modifications or triggering specific business logic flows.
That wraps it up. We hope you enjoyed this second piece. If you found this article helpful, please give it a clap and share it with your friends!
This article is part of a series. If you haven’t read the first of them yet, it’s a good starting point to understand a little more about our journey and motivations.
[Part 1 — Tips and best practices]
In the final post, we will cover how we easily debug our integrations.
[Part 3 — Debugging]
