HTML5 / NATIVE / HYBRID Ryan Paul Developer Evangelist @ Xamarin
NATIVE VERSUS HTML5?
REFRAMING THE DEBATE It s not a battle to the death. It s a choice: what solution will work best for your application?
FACTORS TO CONSIDER Quality of the user experience Access to underlying device capabilities Ease of development Conduciveness to code reuse Leveraging existing skills and expertise Reaching a large enough audience
SUSTAINABLE DEVELOPMENT Will your approach scale as your requirements evolve?
THE WEB IS AWESOME Lots of exciting innovation is happening around HTML
POWER AND FLEXIBILITY Express high-level design concepts with declarative markup Tons of control over presentation: gradients, shadows, transparency, animation, rich text Vendor-neutral open standards enable widespread support and broad portability Easy to learn and use. Lots of talented Web developers are available for hire Ease of rapid prototyping lets you get stuff working quickly
RAPID EVOLUTION The HTML standards process is moving faster than it has in the past Browser vendors are adopting new features very quickly and delivering them faster due to shorter product cycles Performance and instrumentation are improving New standards are emerging that are starting to address mobile needs An increasingly robust ecosystem furnishes developers with lots of great libraries & frameworks
FULL OF WIN
THE MOBILE WEB STILL KIND OF SUCKS Don t mistake momentum for maturity!
FRAGMENTATION Inconsistent standards support between HTML renderers Lots of features aren t ubiquitously available yet Unpredictable update cycles: it s not clear when new features will be available
FRAGMENTATION Missing features in Android 2.3: SVG, File API, crossorigin resource sharing, contenteditable, orientation, CSS 3D Transforms (That s 50% of Android devices!) Features still missing in Android 4.1: IndexedDB, Web Workers, Web Sockets, Server-Sent Events Chrome for Android fixes a lot of this, but Chrome for Android isn t the default rendering engine for the platform Feature data taken from http://caniuse.com
FRAGMENTATION Behavior can even differ between Android devices running the same version of the OS: The WebKit builds are often quite bad! This came to light again when a project I am working on was able to easily core dump the Android browser on a few devices. [...] As I went through the myriad of devices to test things, I started to cry as I thought about the amount of effort it would take to get massively broad coverage that doesn t crash some users. Dion Almaer (FunctionSource.com)
FRAGMENTATION On ios, the high-speed Nitro JS engine isn t enabled for thirdparty apps that embed the platform s HTML rendering engine Third-party developers can ship their own HTML rendering engine on Android but not ios Offline storage: deprecated WebSQL is widely available, but new IndexedDB isn t
PERFORMANCE JavaScript performance doesn t yet rival that of a compiled, statically-typed language, but it s pretty good Native code gives you a lot more room for optimization and parallelization HTML app performance is about a LOT more than just JavaScript
PERFORMANCE An HTML rendering engine is an enormously complex abstraction layer trades performance for flexibility It s unreasonable to expect HTML to give you the same performance as native user interface controls Native controls supplied by the platform are tailored for ideal performance and benefit from platform-level optimizations and hardware acceleration
PERFORMANCE Some rendering engine behaviors are opaque and difficult to instrument: Given the size of our content, it's not uncommon for our application to exhaust the hardware capabilities of the device, causing crashes. Unfortunately, it's difficult for us to understand exactly what's causing these issues. GPU buffer exhaustion? Reaching resource limits? Something else? hard to say. Tobie Langel, Facebook, in a message on W3C mailing list
PERFORMANCE It s really important to evaluate performance holistically look at basic responsiveness and how it impacts the user experience Focusing solely on JavaScript benchmarks can be misleading and will fail to illuminate the bigger picture Always test on multiple devices across the performance spectrum performance will vary on different hardware
LIMITED FUNCTIONALITY Limited access to underlying platform and device capabilities No native controls means that you can t match the platform s look and feel Browsers and Web runtimes confine you to a lowestcommon-denominator user experience
LIMITED FUNCTIONALITY Web standards currently expose an extremely small subset of the features that are accessible through native platform APIs This will get better in the future! Geolocation standard illustrates how device capabilities can be exposed to the Web Standards in progress: camera, vibration, battery status, ambient light sensor, proximity sensor It s going to take time for these things to mature and be adopted by mobile platform vendors. Web standards will probably always lag behind native APIs.
LIMITED FUNCTIONALITY Sometimes the standards aren t very good... media.canplaytype(type) Returns the empty string (a negative response), maybe, or probably based on how confident the user agent is that it can play media resources of the given type. W3C Media Elements Specification Hey, I just met you, and this is crazy, But here s my media format, can you play it maybe?
THREE HTML APP MODELS Browser Don t have to deal with an App Store Low barrier to entry for new users Easy to deploy updates Runtime App Store discoverability Less intrusive security model More access to underlying device Hybrid Unfettered access to underlying device Ability to use native widgets for parts Full control over native/html communication
HYBRID ADVANTAGES Use native APIs to access any functionality available on the platform Decide which parts of your app should be HTML or native Get optimal flexibility and recoverability by building your own native/html foundation
XAMARIN FOR HYBRIDS Use the same programming language across platforms and share more underlying code Full access to platform-specific APIs and native user interface controls Easy to transition to fully native application if you reach the limits of HTML
BUILDING A HYBRID Expose a native function to JavaScript: <div onclick="foo.bar('this is a test!')" class="button">test</div> class Foo : Java.Lang.Object {...!! [Export ("bar")]! public void Bar (Java.Lang.String message)! {!! Toast.MakeText (context, "Message called from JavaScript: " + message, ToastLength.Short).Show ();! } }... WebView web = FindViewById<WebView> (Resource.Id.myWeb); web.settings.javascriptenabled = true; web.addjavascriptinterface (new Foo (this), "Foo"); web.loadurl("file:///android_asset/main.html");
BUILDING A HYBRID Intercept a link handler: <a href="message:this is a test!">test</a> private class CustomWebViewClient : WebViewClient { public override bool ShouldOverrideUrlLoading (WebView view, string url)! {! if (url.startswith ("message:")) {!! var message = Uri.UnescapeDataString(url.Split(new char[] { ':' }, 2)[1]);!!! Toast.MakeText (view.context, "Message called from JavaScript: " + message, ToastLength.Short).Show ();!!! return true;!! } else return false;! } }... WebView web = FindViewById<WebView> (Resource.Id.myWeb); web.setwebviewclient (new CustomWebViewClient ()); web.settings.javascriptenabled = true; web.loadurl("file:///android_asset/main.html");
BUILDING A HYBRID Call JavaScript from native code: WebView web = FindViewById<WebView> (Resource.Id.myWeb); web.settings.javascriptenabled = true; web.loadurl("file:///android_asset/main.html"); Button button = FindViewById<Button> (Resource.Id.button1); button.click += (object sender, EventArgs e) => { web.loadurl("javascript:document.getelementbyid('button').innerhtml = 'blah'"); };
XAMARIN IS HIRING Join a great team at one of the fastest-growing mobile startups Over 200,000 active developers are using Xamarin after only 18 months! Interested? Send an e-mail to jobs@xamarin.com
RYAN PAUL E-Mail: ryan@xamarin.com Twitter: @segphault Visit us at booth 501 Thanks for listening!