• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
openMIC barcamp 11.02.2010

openMIC barcamp 11.02.2010






Total Views
Views on SlideShare
Embed Views



2 Embeds 7

http://my.opera.com 4
http://www.slideshare.net 3



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    openMIC barcamp 11.02.2010 openMIC barcamp 11.02.2010 Presentation Transcript

    • Mobile application smackdown NATIVE APPLICATIONS vs WEB APPLICATIONS vs WIDGETS Patrick H. Lauke / openMIC / Bath / 11 February 2010
    • Web Evangelist at Opera
    • 1. native applications 2. web applications 3. widgets
    • Not an expert – musings…
    • 1. native applications 2. web applications 3. widgets
    • native applications – advantages ● direct access to all phone features ● fast processing and graphics ● native controls ● can run standalone – all resources loaded
    • native applications – disadvantages ● coded specifically to each platform ● maintenance/development cost of multi- platform porting ● app stores for distribution?
    • 1. native applications 2. web applications 3. widgets
    • new technologies you can start using today
    • HTML5 <!DOCTYPE html>
    • HTML5 does not replace HTML 4.01
    • HTML5 has more bling!
    • “...extending the language to better support Web applications, since that is one of the directions the Web is going in and is one of the areas least well served by HTML so far. This puts HTML in direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight.” Ian Hickson, Editor of HTML5 http://lists.w3.org/Archives/Public/public-html/2009Jan/0215.html
    • HTML5 is umbrella term: markup elements and JavaScript APIs
    • new elements for more accurate semantics
    • HTML5 elements for a typical blog
    • HTML5 – unambiguous and machine readable
    • current and old browsers “support” these new elements (although some need a little extra help)
    • webforms – more powerful form elements
    • standardise commonly-used rich form elements – without JavaScript
    • built-in validation (of course you should still validate on the server) Demonstration of webforms
    • <canvas>
    • canvas = “scriptable images”
    • canvas has standard API methods for drawing ctx = canvas.getContext("2d"); ctx.fillRect(x, y, width, height); ctx.beginPath(); ctx.moveTo(x, y); ctx.lineTo(x, y); ctx.bezierCurveTo(x1, y1, x2, y2, c1, c2);
    • canvas mixing things up with external graphics ctx = canvas.drawImage(…) Demonstration of canvas
    • <video>
    • <object width="425" height="344"> <param name="movie" value="http://www.youtube.com/v/9sEI1AUFJKw&hl=en &fs=1&"></param> <param name="allowFullScreen" value="true"></param> <param name="allowscriptaccess" value="always"></param> <embed src="http://www.youtube.com/v/9sEI1AUFJKw&hl=en&f s=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed> </object>
    • <video src="video.ogv" controls autoplay poster="poster.jpg" width="320" height="240"> <a href="video.ogv">Download movie</a> </video>
    • video as native object...why is it important? ● “play nice” with rest of the page ● keyboard accessibility built-in ● API for controls Demonstration of video
    • video format debates – MP4 vs OGG Theora <video controls autoplay poster="…" width="…" height="…"> <source src="movie.ogv" type="video/ogg" /> <source src="movie.mp4" type="video/mp4" /> <!-- fallback content --> </video> still include fallback for old browsers http://camendesign.com/code/video_for_everybody
    • video and canvas on any device without plugins (Java / Flash / Silverlight not ubiquitous)
    • offline support
    • detect if a browsers goes offline window.addEventListener('online', function(){ … }, true); window.addEventListener('offline', function(){ … }, true);
    • storage
    • localStorage/sessionStorage like cookies... document.cookie = 'key=value; expires=Thu, 11 Feb 2010 23:59:59 UTC; path=/' …
    • localStorage/sessionStorage like cookies...on steroids! localStorage.setItem(key, value); localStorage.getItem(key); localStorage.clear(); localStorage.key = value; if (localStorage.key == '…') { … } …
    • Web Database – full relational DB / SQL var db = openDatabase(dbName, version, displayName, expectedSize); db.transaction(function(tx) { tx.executeSql(sqlStatement, [], function (tx, result) { /* do something with the results */ }); });
    • application cache
    • cache UI/resource files for offline use <html manifest=”blah.manifest”> CACHE MANIFEST # send this with correct text/cache-manifest MIME images/sprites.png scripts/common.js scripts/jquery.js styles/global.css
    • and many more... (geolocation, drag and drop, web workers)
    • Approaches to cross-device development: ● do nothing – use standards, defensive design ● separate site (m.mysite.com, mysite.mobi) ● single site, but optimised for cross-device
    • CSS 2.1 Media Types: ● print, screen, handheld, projection, tv, … ● partially supported ● lump all devices into single categories http://www.w3.org/TR/CSS21/media.html
    • CSS 2.1 Media Types: <link rel="stylesheet" ... media="print" href="..."> @import url("...") print; @media print { // insert CSS rules here }
    • CSS 3 Media Queries: ● build and extend CSS 2.1 Media Types ● more granular control of capabilities ● width, height, orientation, color, resolution, … http://www.w3.org/TR/css3-mediaqueries/
    • CSS 3 Media Queries: @media screen and (max-device-width: 480px) { // insert CSS rules here } Demonstration of Media Queries
    • CSS 3 Media Queries and SVG: ● SVG already resolution independent ● ideal for device interfaces, maps, graphs, … ● combination with CSS 3 Media Queries Demonstration of Media Queries + SVG
    • web applications – advantages ● work on all phones with modern browser ● write once (with graceful degradation / progressive enhancement) deploy anywhere ● no app store rules and regulations ● offline support / storage make them almost standalone
    • web applications – disadvantages ● but it runs inside the browser ● controls don't look native ● no direct access to device features (and rightly so in most cases) ● not suited to graphics / processing intensive ● no app store … so what?
    • 1. native applications 2. web applications 3. widgets
    • Widgets are nothing new Yahoo! Widgets (aka Konfabulator), OS X Dashboard, Windows Sidebar, Adobe Air, iPhone Apps, Android Apps, …
    • “…the browser run-time is perfect…you’re out of writing for Windows Mobile, Android, S60, each of which require testing...we want to abstract that. All the cool innovation is happening inside the browser – you don’t need to write to the native operating system anymore.” Mobile Entertainment Market , June, 2009
    • W3C Widgets – application development filled with web standards goodness, using browser engine as platform
    • Widgets on desktop, mobile, TV … fridge?
    • Anatomy of a widget index.html + config.xml
    • Configuration file <widget> <widgetname>MyFirstWidget</widgetname> <description>A demo widget</description> <icon>images/widget.png</icon> <width>320</width> <height>240</height> </widget> Demonstration of basic widget
    • Opera had widget capability for a long time … 10.20 alpha first widgets as standalone apps dev.opera.com/articles/view/widgets-as-standalone-applications
    • Standardised JavaScript APIs to access device-specific capabilities (JIL / BONDI / W3C Devices API)
    • widget – advantages ● work on all phones with widget manager ● write once (with graceful degradation / progressive enhancement) deploy anywhere ● distribution – ad-hoc, website or store ● standalone – all resources wrapped and downloaded together ● depending on widget manager engine, all the goodness of new web standards for free
    • widget – disadvantages ● not all widget managers are the same ● current device access confusion (JIL/BONDI/DAP) ● not suited to graphics / processing intensive
    • 1. native applications 2. web applications 3. widgets who would win in a fight?
    • native applications good for graphics / processor intensive stuff web applications if doesn't require device integration, good solution for most common tasks (provided browsers all support features like offline / storage) widgets the future(?) combines best of both worlds
    • www.opera.com/developer people.opera.com/patrickl/presentations/openMIC_11.02.2010/openMIC_11.02.2010.pdf patrick.lauke@opera.com