How many times have you heard this or similar: “Hey, can’t we just build a ‘wrapper’ app around our mobile web site or web app? We just need to be present in the Play Store with anything, really”? Then you start to explain to people why that is a good or bad idea and how their mobile web app might be completely wrongly architected for such an endeavour. At this point the topic of Phonegap usually pops up and “that it should just take a couple of minutes to get that all done, right”. The story goes on and on from here.
But in all seriousness, Android’s WebView has its place. It’s a reasonably versatile and more or less well designed component Android developers can use to embed browser-based elements into their app. And yes - it can also be used to drive a complete mobile web app inside of your actual Android app. But it is clearly its own beast and it can create a lot of havoc in the heart of your app, too. Starting with having to deal with performance problems, having to implement support for older implementations of the Android WebView in your Markup, CSS and JS code, up to inadvertently opening up potential security holes.
This talk comprises multiple parts. After an introduction of the WebView as a concept and the current fragmented WebView implementation landscape we’re going to have a look at the APIs involved. From there we’ll talk about how to get a basic implementation of a properly secured and well-working WebView component setup in your App. That alone can contain a variety of rather unexpected challenges. If you haven’t had enough at this stage, it’s gonna get really interesting. How can you deal with what we’ve coined lovingly “OAS” - short for Old Android Support - in your WebView? And how to find out which of all the modern web API stuff you’d probably happily use in a modern version of Chrome? Can it actually be used in your WebView-based Android-App and at what cost?