We know that there are some use cases where it makes sense to integrate your existing web experience into your native app, I’m Pete a developer advocate on the web team at Google. Let’s take a look at how you can do this today and what we’re doing to make your web development experience better today, you can do this either using a webview or a custom tab.
Well, each of these has their own benefits. They’re also drawbacks to each with web views. The content runs fullscreen and supports many of the PWA features. It has the ability to use post message to send messages back and forth between the webview and your native code, which makes it possible to invoke certain native functionality that isn’t available on the web. On a flip side, web views our sandbox completely from the user.
They don’t share the same cookie, store or storage and they don’t have access to the users, safe passwords and so on. The other challenge that comes up is that web views may be out of date. Web views on devices running pre, lollipop, aren’t updatable custom tabs also support content in full-screen mode and because they’re powered by the user’s default browser they share cookies, storage, passwords and more.
It’s always up-to-date and supports the full gamut of capabilities required for progressive web apps. But there is that name and address bar across the top. The user knows that they’re looking at web content, which isn’t always what you want. We’ve heard from you that you want an easier way to launch full-screen web content from a native app, but do it using the users preferred browser at the chrome dev summit.
Last year we announced a new type of activity that Android developers can use to embed trusted. First party web content trusted web activities provide a new way to integrate parts of your web experience into your native Android, app they’re powered by custom tabs, which means the content is rendered by the users up-to-date browser instead of an out-of-date webview. It shares the same cookies and storage within the browser.
It has access to AP ice that aren’t available in web views. This isn’t designed as a mechanism to simply wrap your site and dump it in the Play Store. A simple mistake can cause some drastic problems. For example, the user installs your app from the store hops on a plane and launches your app. The user is going to see the dinosaur because the app hasn’t installed the serviceworker yet trusted web activities are designed to make it possible for you to use the investment that you’ve made in your progressive web.
App within your Android, app, similar to chrome, custom, tabs trusted web activities run full screen. Each activity of your app is either completely provided by the web or an Android activity. There’s no way to combine them. For example, you can’t use Android components for navigation and content, rendering via the trusted web activity. Transitions between web and native content are between activities trusted web activities do have some constraints, you can’t just show any content, it must be yours, and you must be able to prove that it’s yours by adding a set of digital asset links, you must include an intent Filter for the opened URL in your Android manifest your app must pass the chrome, PWA install ability, checks which includes being served over HTTPS, registering a serviceworker and including a manifest and very important.
Your app must still meet all of the normal Play Store guidelines. Let’s take a look at what’s involved in adding a trusted web activity to your Android app. There are essentially two steps that we need to complete to embed or progressive web app in our Android app. First, we need to add a set of digital asset links. These links establish a relationship between our web content and the trusted web activity.
By establishing this relationship, our android app can verify that the content is served is ours and meets that first party requirement. Then we can add the activity to our Android app and show our web content and our manifest file. We need to tell it about an asset statement by adding this metadata attribute. Next, we need to update the strings.Xml file and our Android app and tell it about our web content where it lives and give it the permission that it needs oh yeah and all those quotes there.
Sorry they do need to be escaped like that. Now we need to create and deploy the assets link JSON file, using key tool on the certificate that we use to sign our Android app, we’ll get the sha-256 hash so that later Android can verify the certificate and that hash, then, in the asset, links JSON file. Will include that hash, our package name and a few other boilerplate pieces and deploy it to the dot well-known directory.
The file makes it possible for Android to verify the relationship between what’s being served and our Android app. We’ve set up the digital asset links we need now. We can create the activity. There’s a bunch of boilerplate code required to launch the activity that I’ve kind of glossed over here, but we’re working on adding that to the Android support library, so that you won’t have to deal with it in the future.
Once the boiler stuff is complete, you can create the new intent set, the URL and open the web content in your trusted web activity. Today, this is available on android and chrome 68, which is currently chrome, dev and we hope to see it land and stable sometime in q3 of 2018 to learn more check out gqo slash trusted web activities. There’s a great post there with everything you need to know to get started and a sample that you can use to try it yourself.
Thanks for reading
Jimmy's Internet Marketing Business Blog 