(4) URIs for Mobile Resources

• URIs identify resources for interactions
• Perfect URIs are independent of the actual representation
  • more an ideal than something that is often done in practice
• URIs should be the entry point to interactions
  • identifiers that can be published, shared, reused, …
  • there should only be one entry point

(5) One Web URIs

• Ideally, all interactions go through the same set of URIs
• In practice, Web sites can be structured/designed very differently
  • mobile applications are based on different use cases and usages
  • mobile sites may have a different URI structure from the regular site
• Different approaches for handling One Web URIs
  • perfect: serve content that may be specific to the request
  • good: redirect to content that is specific to the request
  • sometimes good: allow users to switch between different representations
• Different representations often are developed by different teams
  • not necessarily a one-to-one correspondence between all resource
  • try to provide mappings between the most important resource URIs

(6) Mobile Web URIs

• Most mobile sites use specific URIs for mobile content
  • different TLD: http://berkeley.mobi/
  • different domain: http://m.berkeley.edu/
  • different path: http://berkeley.edu/mobile
• .mobi has not seen much adoption
  • there is no reason why mobile content should have one specific TLD
• Different subdomains make it easy to set up separate servers
  • convenient for entirely different mobile applications
  • high risk of fragmentation and partial reuse becomes brittle
• Different paths are creating as little separation as possible
  • all content is available through the same server
  • setting up and maintaining redirects can be handled more easily

(8) Mobile Platform Overview

(9) The Legacy of J2ME

• J2ME was a disaster in usability and stability
• Instead of selling implementations, it was a licensed spec
  • there were no conformance requirements and no conformance testing
  • anything that was labeled as J2ME could be shipped
• Installation procedures were/are not user-friendly
  • phone-specific ways of how to download/install applications
  • often no easy way to find and manage installed applications
• Developing J2ME applications became surprisingly device-specific
  • writing code to address/circumvent properties of devices
  • far from Java's original Write Once, Run Anywhere vision

(10) Tightly Controlled Platforms

• iPhone development works well because there is only one device
  • 3GS supports video and has a compass but those are all differences
• iPad development makes development considerably harder
  • much larger differences in device capabilities
  • maybe a completely different UX/UI approach is required
• Tightly controlled platforms allow better tool chains
  • SDK and other tools are under control by one vendor
• The long story of Flash on the iPhone [http://daringfireball.net/2010/01/apple_adobe_flash]
  • Apple controls the complete code base running iPhone applications
  • Flash would introduce code controlled by a different vendor
  • stability/performance issue cannot be addressed by Apple

(11) Open and/or Licensed Platforms

• More open models mean platforms are reused for various devices
  • Android is open source and reaches beyond smartphones (nook [http://en.wikipedia.org/wiki/Barnes_&_Noble_Nook], netbooks)
  • Windows Mobile is licensed to a variety of device makers
• Device diversity can become a problem
  • diversity is good but also makes it harder to rely on device capabilities
  • until today, all Windows Mobile devices are required to have IR ports
• Android development is a different challenge from the iPhone
  • development for only one device?
  • if for multiple devices, what is the target class of devices?
  • development across classes faces the iPhone/iPad challenge

(12) Cross-Platform Development

(14) Web-Based Mobile Platform

(15) iPhone Platform

(16) Web as a Platform

• Code is delivered on demand using Web standards
  • HTML is the interface structure language (the windowing metaphor)
  • CSS is the layout language (layout controls for the windowing metaphor)
  • JavaScript is the programming language (runtime control of HTML/CSS)
  • HTTP is the communication method (JavaScript access to the Internet)
• Web technologies are migrating into the OS
  • a long time ago, Internet technologies were doing the same thing
  • HTTP support by the OS still is the exception and not the rule
  • more complete packages (rendering & scripting) are available (WebKit)
  • WebOS treats Web technologies as the native API
• ChromeOS is using the browser as a platform
  • browser = WebKit + user controls (a.k.a. chrome [http://en.wikipedia.org/wiki/User_interface_chrome])
  • ChromeOS and WebOS are not all that different (technically)

(17) Current Web Capabilities

• Web technology is rather limited in its device support
  • keyboard/mouse perspective is built into numerous technologies
  • output is visual and bitmapped (Aural CSS [http://www.w3.org/TR/CSS21/aural.html#aural-media-group] might still happen)
• Many Web pages rely on non-standardized technologies
  • Flash for rich media (mostly video playback)
  • Silverlight for Rich Internet Application (RIA) implementations
• Web technology is limited to online scenarios
  • Google tried changing this with Google Gears (offline support)
  • offline capabilities are now added in various places
  • most Web-based apps by their very nature are online-oriented

(18) HTML5 Capabilities

• HTML5 is a complicated and evolving set of technologies
  • turning HTML4 into something with more predictable browser behavior
  • adding some new features along the way
• Some HTML5 features were spun off into standalone specifications
  • Web Workers [http://www.w3.org/TR/workers/]
  • Web Storage [http://www.w3.org/TR/webstorage/] and Web SQL Database [http://www.w3.org/TR/webdatabase/]
  • Web Sockets API [http://www.w3.org/TR/websockets/]
  • Selectors API Level 1 [http://www.w3.org/TR/selectors-api/] and Selectors API Level 2 [http://www.w3.org/TR/selectors-api2/]
  • Server-Sent Events [http://www.w3.org/TR/eventsource/]
  • XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest/] and XMLHttpRequest Level 2 [http://www.w3.org/TR/XMLHttpRequest2/]
  • Geolocation API Specification [http://www.w3.org/TR/geolocation-API/]
• Not all documents at the W3C have the same support and maturity
  • Programmable HTTP Caching and Serving [http://www.w3.org/TR/DataCache/]
  • Contacts API [http://www.w3.org/TR/contacts-api/]
  • Indexed Database API [http://www.w3.org/TR/IndexedDB/] (competitor of Web Storage)
  • File API [http://www.w3.org/TR/FileAPI/]

(19) Missing Pieces

• Non-traditional interactions
  • (multi-)touch screen for pointing interactions
  • accelerometer for measuring device movement
  • vibration for giving tactile feedback
• Access to device hardware
  • camera, compass, …
• Access to additional information sources
  • phone API for phone calls and messaging
  • contacts, calendar, social networks, …
• Special graphics capabilities
  • essential for advanced rendering (gaming, 3D visualization)
  • non-traditional bitmapped displays such as e-ink

(21) Java Revisited

• Write Once, Run Anywhere
• Java's appeal of a virtual platform remains strong
  • Java's main success was for non-interactive applications
  • abstracting the traditional OS functions probably is easier to do
• Taking Java to the Web
  • Java Applets never really took off (too heavyweight and ugly)
  • Flash was much more lightweight and more Web-friendly
  • ActiveX was Microsoft's backdoor into native features
  • Silverlight is both for embedded and standalone applications
  • AIR is Adobe's standalone Flash

(22) Embedded in the Browser

• Plugin architectures of browsers allow browser extensions
  • applet [http://www.w3.org/TR/html401/struct/objects.html#h-13.4] specifically supports Applets only
  • object [http://www.w3.org/TR/html401/struct/objects.html#h-13.3] allows any object to be embedded
• Browsers must have the extension installed for content to work
  • plugin installation is complicated and security-sensitive
  • fallback can be implemented but often is too costly and not supported
• Browser plugins are not subject to the same security policies
  • they run as native code (the plugin is installed as an OS-level library)
  • vulnerabilities of the plugin turn into vulnerabilities of the browser
• More lightweight approaches may be required for mobile devices
  • Flash Light is a version of Flash for limited devices
  • JavaFX [http://www.sun.com/software/javafx/] and JavaFX Mobile [http://www.sun.com/software/javafx/mobile/] are intended to replace Applets/J2ME

(23) Browser/Flash Platform

(24) Standalone Runtimes

• Removing the limitations of the browser
  • essentially recreating Java's virtual machine approach
  • often more friendly to Wen technologies (built-in HTML/CSS/Scripting)
• Transitioning outside of a browser breaks the Web flow
  • standalone apps mean that there is no back button
  • it is harder to integrate these applications with others
• Most examples of standalone applications are black holes
  • they are not supposed to connect to the fabric of the Web
  • overcoming the black hole effect is easier in a browser

(25) Flash Standalone Platform (AIR)

(26) Compiled Runtimes

• Application and runtime compiled into a native application
  • less dependency on installation status of the client
  • only reasonable with a lightweight runtime
• PhoneGap [http://phonegap.com/] acts mostly as glue for native functionality
  • exposing currently unsupported functionality as JavaScript APIs
  • the actual functionality is supported/implemented in the OS
• PhoneGap focuses platforms that are sophisticated enough
  • currently supported are iPhone, Android, and Blackberry
  • support is planned for Windows Mobile, Nokia, and Palm

(27) PhoneGap on the iPhone