00:00:15.240
Hey everyone, I am Jay Ohms. I work at 37signals and lead the mobile team.
00:00:21.720
Before we get into Strada, there's an important question I know some of you are asking, so let's just get it out of the way right now: Did you seriously tease Strada and Hotwire's launch years ago to get my hopes up, only to take a really long time to finally launch? I've had to wonder what it is, how it works, and if I should care for a long time now.
00:00:36.600
Yes, and now that we have that out of the way, I'd love to tell you more about it. I'll start with a high-level overview before we dive into the details.
00:01:07.439
As you all know, the web is really great at many things. It’s broadly accessible, allows fast development, and is excellent at displaying server-driven UI. Changes can be deployed quickly and easily. However, if any of you are mobile developers, you are likely familiar with the long and slow review processes, which can be a painful part of the job.
00:01:25.119
Native apps are optimized for small screens, providing high-fidelity experiences. They also allow developers to take advantage of platform APIs and conventions. Apple and Google have done a great job providing excellent platform APIs that we can use, and you also get to use UI components for free.
00:01:36.600
At 37signals, our apps are hybrid, built on Turbo Native libraries. We have two types of screens: native screens that render UI from JSON endpoints and web view screens driven by Turbo, which display web content within a rectangle on the screen.
00:02:00.240
While we can decorate the web view with some native chrome around it, there exists a problem: there is a disconnect between the web view on the screen and the native shell features of your application. There is no easy way for the native app to know what is happening in the web view.
00:02:21.599
For a long time, we built our apps on Turbo libraries—primarily Basecamp and Hay—and recognized the need for a way to communicate between the web view and the native app, and vice versa. We went through several approaches and mistakes along the way.
00:02:34.280
One issue we encountered was packaging app-specific JavaScript within our native apps to manipulate and query the web view DOM. This was a very fragile approach that would break whenever we updated the web app.
00:02:54.079
This became a major problem since the only way to fix the bug was to ship a new app update and wait through the usual review times. Native apps also do not know when there are state changes in the web view DOM.
00:03:06.040
At 37signals, we have a web team consisting of web programmers and designers, and a mobile team with mobile programmers and designers. While we work together, we also function independently. It was tricky for the web designers and programmers to know when changes to the web app could negatively impact the native apps.
00:03:16.679
We realized we needed a long-term solution to this issue. We had a method in Basecamp that worked to some extent but was not ideal. Therefore, we set out to create a framework that could solve these problems.
00:03:42.280
We aimed to establish a bridge between our web code and our native app code, making it a component-based framework. This would allow us to scale alongside both the web app and the native apps effectively.
00:04:01.679
We formulated some rules to guide our solution. One was that the apps must not rely on documentation markup present on the page. The knowledge that the native app holds should be entirely divorced from the actual DOM in the web view.
00:04:22.140
The native app cannot package any app-specific JavaScript, meaning our communication between native and web apps would occur using JSON. The web app should be able to send state changes from the web view to the native app to inform it.
00:04:50.160
The native app should also be capable of responding to state changes back to the web. Another important aspect is that if you possess a Turbo Native app, you might want to deploy a new feature quickly on the web.
00:05:10.040
However, it could take a week to push your app update. During this transition, we need a way to bridge old clients to new clients, and Strada uses an opt-in component system where behaviors change based on what is supported by the native apps.
00:05:28.760
We also aimed to bridge web UI to native UI cleverly. We already had some interactions developed on the Basecamp side, and were eager to build more sophisticated native features driven by the web app.
00:05:48.760
After spending considerable time, we developed Strada, which has been implemented in Hey since its launch in 2020. It consists of libraries across all platforms, enabling native control in hybrid mobile apps driven by the web.
00:06:06.320
What do I mean by driven by the web? It means your web app determines when and where native controls show up in your native applications. The native apps don't decide; instead, your web app controls that.
00:06:32.120
Moreover, Strada leverages Stimulus directly, giving you the same power in your web components as you are familiar with using Stimulus.
00:06:56.760
Let's look at an example. Here’s a screen in Hey, which is a screen to edit your profile. If you notice at the bottom, there’s a save button shown in the web view.
00:07:14.440
In mobile apps, it’s quite common to have your submit buttons, save buttons, or next buttons in the top-right toolbar area. This setup is convenient for several reasons.
00:07:33.680
For example, when the virtual keyboard is open, you can no longer see the save changes button. The user would then have to scroll to access it, creating a less than ideal user experience.
00:07:52.560
To address this, we can move the submit button to the top-right of the app bar and hide the submit button in the web view. The native app will notify the web app when the native submit button is tapped.
00:08:11.240
The web submit button will process as if the user tapped the web view button directly. The goal is to hook up this submit functionality to Strada.
00:08:30.440
Let’s start by adding a data-controller attribute similar to how it's done in Stimulus. This ties to a bridge form component, and we will also designate the submit button as a target for the component.
00:08:47.440
To create a web component for Strada, extend the bridge component class which itself is an extension of a Stimulus controller. You will inherit all the features of a Stimulus controller while additionally receiving Strada-specific functionality.
00:09:04.440
Importantly, you need to name your component. This is a plain text identifier that both the web and native apps will agree on, used for communication between the two.
00:09:23.560
When the submit button is connected on the page, we'll wrap the submit button target in a bridge element, allowing it to inherit Strada-specific behaviors.
00:09:46.560
You can set up titles for your elements easily with Strada. For example, if the web app button says 'Save Changes', and you wanted it just to say 'Save', that would be straightforward to implement.
00:10:03.240
Now, let’s send a message to the native app. Each message will contain an event name, which your web component and native component will agree upon for compatibility.
00:10:22.760
The data sent will be in JSON format, including the submit title to the native app. Additionally, a callback is provided that will be triggered upon receiving a response from the native component.
00:10:41.840
When the native component replies, it will trigger the submit button on the form. This maintains the existing workings of the form without changing validation or submission process.
00:10:59.440
Let’s explore the bridge message sent if your native app supports the form component. It includes an ID, a name indicating it's a form component, the event name, and the data including the submit title.
00:11:14.560
On the native side, we will extend the bridge component class, which is in Kotlin. Here, we will implement the onReceive function to handle incoming messages.
00:11:31.360
When we receive the connect message event, we will process the incoming data, deserialize the JSON, and create the native toolbar button.
00:11:47.920
While I won’t display the entire code here for brevity, you can find the complete code in our Turbo Native demo apps. The crucial step is placing the button in the toolbar and setting the text based on the incoming data.
00:12:06.560
Once the user taps the button, we will reply back to the last received connect event message. While optional, we can pass additional data during the reply, but it’s not necessary in this instance.
00:12:23.360
Connecting the dots requires some initial setup on the native side. You will need to initialize the bridge with the web view instance, update the web view user agent, and delegate Turbo lifecycle events.
00:12:43.520
When the native app and web app declare the components they support, it will influence how these components communicate effectively.
00:13:02.279
Strada automatically updates the document element in your web app to reflect the platform and supported components, ensuring your backend is informed.
00:13:24.599
Returning to the example, the button in the top-right corner will trigger a reply to the message, enabling the web to trigger the submit button and submit the form as expected.
00:13:37.919
There is an easy way to address the intuitive problem of having both buttons visible. By employing the registered bridge component, we can utilize scoped CSS to hide the submit button in the web view once the native component is supported.
00:13:54.719
The mechanism allows a seamless experience where any submit buttons inside of a Bridge Form controller are hidden whenever the form component is supported in the native app.
00:14:14.960
This setup maintains both backward and forward compatibility. If a new feature is launched with a web form and the native app hasn’t yet been updated to support the form component, the web button remains visible.
00:14:29.520
Conversely, once the native app updates to support the component, it shows the native button instead.
00:14:52.159
What you see is that the flow of events is straightforward. When a bridge component activates on the page, the event is communicated through the bridge and reaches your bridge component.
00:15:16.079
When the native side replies to the original message, the process reverses through the bridge back to the web bridge component. This creates a nice example of progressive enhancement.
00:15:34.520
You can begin with a fully web-driven experience in your web view, layering native features as needed. The beauty here is that your web component and native component are cleanly separated from your app features.
00:15:50.320
Thus, for any form in your web app, you simply add your bridge form controller attribute along with the submit target, and it works seamlessly across the entire app.
00:16:10.360
Let’s examine a more advanced example. This is a screen in Hay where a menu is fully driven by the web. The purple menu here is unaware of the features it displays.
00:16:26.040
It simply displays a list of items driven by the web, passing along icon URLs generated from the web as well.
00:16:46.420
To build this menu as a Strada component, we begin with a simple `div` and apply a data controller attribute, which initializes both a menu controller for web functionality and a bridge menu controller for the bridge component.
00:17:06.280
Whenever a button in the web menu is clicked, it should call the appropriate show function on the bridge component, giving it a chance to display if the native app supports it.
00:17:24.520
By setting a title for the menu, the title can be passed easily along with any other data required when menu items are clicked.
00:17:41.160
The process involves sending a display event message to the native app with the title and items data. We also implement a callback function for when a menu item is selected.
00:17:53.920
Following this, we extract the index of the selected item from the reply message which the native component returns, and then we trigger the click event on the corresponding button.
00:18:08.920
Now, let’s shift focus to building a native component. On the iOS side, we extend the bridge component class, implementing the onReceive function to handle incoming messages.
00:18:30.520
This will allow us to process the display event message received from the web and trigger the appropriate UI, such as showing an alert sheet.
00:18:50.520
While the complete code isn't presented here, the demo app contains code examples demonstrating the implementation of alert sheets and their interactions.
00:19:09.760
Once a menu item is tapped, the onItemSelected function is called, and we reply back to the display event message with the selected index of the item.
00:19:27.520
This message returns to the web component, which will then utilize the index to simulate a button click on the corresponding item.
00:19:42.720
Throughout the Hay app, we've implemented various components to enhance functionality. For instance, we’ve built a floating action bar for emails that can show menus.
00:20:00.240
We also enable users to highlight text and create clips of content displayed through native UI, seamlessly integrating web and native experiences.
00:20:16.560
There’s a flash message component that transforms web flash messages into native UI, taking advantage of platform conventions.
00:20:31.760
Additionally, we have a nav button component that lets us show small icons in the app bar and an overflow menu for less common actions.
00:20:48.640
The page component connects on every single page within the web app, providing features such as styled page titles, and animating title transitions during scrolling.
00:21:04.920
Our print component also addresses limitations in web view APIs by allowing users to print emails driven directly by the web app.
00:21:26.680
Finally, we’ve developed a tricks component allowing for the establishment of toolbars with native UI, showcasing our commitment to building a robust library.
00:21:44.840
We continue to add more examples and enhance the library, and that concludes my presentation. Thank you for your attention.
00:22:26.240
Thank you very much.