A big project is approaching and you need an application as soon as possible. Does this situation sound familiar? We have all encountered this scenario, where developing a product within a tight deadline can often feel impossible. Unsurprisingly, the application in the store is profitable, but before that, it is primarily a cost. This is why time to market is crucial for businesses. How can we speed up the development process without compromising the project's scope? Sometimes, building a fully functional application may require several features that cannot be developed within the estimated time frame. In such cases, strategic decisions must be made to handle the situation effectively. Let's explore the Allegro Lokalnie Case Study.
Choose the Lesser of Two Evils
As you can probably guess by now, our idea was to use web views shared between Android and iOS. But how could we present web views in the native application without affecting user immersion? The answer is simple. You can't. But you can carefully select places where such an arrangement will bring more benefits than losses to user experience. You can't have your cake and eat it, but you can slice off a piece and swap it with some cream so no one notices a piece is missing. But to the point: how did we do it?
Photo by Daria Nepriakhina 🇺🇦 on Unsplash
How Do We Choose an Area for WebViews?
In addition to the evident domains such as terms and agreements, our selection of areas for web views is guided by several critical criteria, ensuring a strategic and user-friendly application of this technology:
- Static Views First: We lean towards areas related mostly to presenting static information and don’t ask for too much back-and-forth with a user. A good example is a product details view where a user is more of an observer than an active participant.
- Optimizing Existing Strengths: We also examined the areas that performed well on the mobile web. Conducting a benchmark using available tools (e.g. Chromium) would be an ideal approach, but this method requires additional time, if it is not already implemented. We took a more informal approach, subjectively assessing which views functioned and loaded sufficiently well, not only with super-fast internet but also under less favorable conditions.
- Saving Development Effort: We also eye those areas that would be a hefty chunk of development work, which we might not be ready to dive into just yet (think payments or chat). Especially when they’re already up and running in the mobile web version, it’s a smart move to utilize webViews and save our energy.
- Backstage Areas: Lastly, we consider areas that aren’t front and center in the app’s current life stage, like account settings. They can comfortably exist in a web view without disrupting a user’s journey through the app’s key features.
By sticking to these criteria, we ensure we’re channeling our development efforts effectively, deploying webViews, where they can do the most good without muddling the user experience. It’s all about smartly navigating development to deliver a seamless user journey.
Photo by Choong Deng Xiang on Unsplash
We Choose Areas. What’s Next?
After skimming through the previous section, it seems pretty straightforward, right? Sure, we could take the easy street: roll out a webView and then cheekily slide into a coffee break, but we still need to answer a few questions before eagerly moving users to the web.
What About Authorization?
The last thing we want is for a user to log in whenever they open a web view, so we need to pass the session somehow. It may seem obvious, but it's easy to forget when designing the flow. This task is not particularly challenging, but it requires acquiring a web session initially, which is different from the session used in the app. In our case, this involved setting up an endpoint to exchange sessions. We could then inject the exchanged session into the webView. However, it can lead to unexpected scenarios, if the session is not invalidated after logout, such as logging into two separate accounts in webView and the application.
Photo by Dan Nelson on Unsplash
What If the User Wanders Too Far into the Internet?
The answer is not so evident here. Because WebView within the application usually operates on a particular domain, more stubborn users can go outside the intended flow and wander to different places, causing errors that are very difficult to predict and cannot be tested. Therefore, it is worth hiding buttons such as links to the homepage on web screens served within the mobile application.
What If the User Taps the Back Button?
We must also remember that users rarely know whether they are on a web page or a native page. This can lead to misleading situations when a user taps the back button, and instead of going one page back in the webView, they dismiss the whole page. It's not a big deal, if it happens when they are browsing through the terms and conditions, but it's worse, when it occurs on the payment screen, where they want to double-check if they entered the correct delivery address, and with this simple gesture, they end up aborting the entire flow. How to solve this? Unfortunately, there is no one good solution here. We can show navigation buttons on web views to let users know that it is a web view, but in that case, we strip away the illusion of presenting a native view.
What if the App State is Tied to Actions in the WebView?
WebView can feel like a black box when navigating the mobile app code. Sure, we can tinker with the website code from here, but that’s playing with fire - it’s a pretty aggressive and risky strategy. It’s all too easy to throw a wrench in the works.
We're in a delicate dance when the app state leans on actions within the WebView. We aim to keep a smooth user experience, ensuring actions within the WebView create coherent changes within the app, all while treading lightly to avoid disrupting the WebView and, subsequently, user experience.
We Devised Two Solutions
- The Straightforward Approach: Intercept all actions executed inside the WebView and determine the subsequent course of action: allow it to proceed, perform a background action, or pass it without interception. While this might sound simple, crafting the precise regex is crucial to avoid inadvertently capturing too much. Coordination with the web team is also vital to ensure awareness of which links are being monitored. After all, we wouldn’t want an accidental URL change to disrupt an essential flow within the application.
- Big Guns for Unique Situations: To bridge the gap between the native app code and the content within WebView, we employed advanced techniques to ensure seamless and efficient collaboration between these two environments.
Leveraging WebView Hooks:
Android and iOS platforms come equipped with specialized WebView classes. These classes serve as gateways, allowing us to seamlessly interact with the JavaScript (JS) embedded within the WebView. By presenting native objects to the JS realm, we've paved the way for web interactions to initiate actions in the app's native code.
Unified Event Format:
To ensure smooth communication, we designed a standardized event format. This, in order to ensure a smooth communication format, allows the JS to send signals our app can easily interpret, ensuring that the appropriate native modules respond to specific event triggers.
Two-Way Communication:
But it's not just about listening. To facilitate a two-way conversation, we've constructed a "bridge" that channels information from the native code back to the JS in the WebView. This bridge acts as a mediator, ensuring that the web content can process events from the app and vice versa.
Executing JS in the Web Context:
With the tools provided by Android and iOS, we can directly guide the performance of JS within the WebView. This direct influence allows us to make on-the-fly adjustments to the web content, ensuring it aligns perfectly with the app's broader narrative.
What If WebView Is Too Slow?
To enhance user experience, we crafted a web view for product displays to provide rich and interactive content. However, we quickly noticed a hiccup: the loading time for product images was taking a toll, affecting the app's smoothness and responsiveness. The solution emerged as a hybrid approach: we natively fetch and display the product image gallery, ensuring swift and smooth scrolling, while the content beneath - product details, descriptions, reviews - is loaded as a web view. This amalgamation allowed us to harness the strengths of both realms, offering rapid image loading and rich, interactive web content, all while minimizing load times and optimizing the overall user experience.
Conclusion
Developing a mobile app doesn't always require native coding for every element. Sometimes, thinking unconventionally is necessary to meet client demands and ensure user satisfaction. But what happens next? If you're interested, stay tuned for the next part of the Allegro Lokalnie case study, which will delve into the gradual reduction of technical debt accumulated using webViews.
