Transcript Title, Number (Arial 40pt) 題目(SimHei 36pt)

Mobile Web (Hybrid) Apps Versus
Native Applications
Shatin 沙田
Native vs Mobile Web vs
Hybrid
• Native:
• Writing code with for specific platform
• Use all features provided by platforms
• One Programming Languages
• Code ONLY for that platforms
• Android – Java
• iOS – Objective C
• Windows Phone – C++/C#
• Mobile Web:
• Cross-platform
• Limited features
• Offline Problems
• Hybrid:
• Mobile + Native = Some native powers + Web flexibility
The Ubiquity Principle
• Why mobile web is the only long-term commercially?
• Fragmentation
(iOS,Android,WP, BB10, FFOS, TIZEN, Ubuntu OS)
• The Web
• Control
(HTML Syntax, Javascript)
• Consumer expectations
(Widely Used by Users on Desktop Computer)
The Ubiquity Principle Fragmentation
• No one vendor able to firmly claim
itself king
• Getting your application on one
platform is a snap
• Getting it on two is challenge
The Ubiquity Principle –
The Web
• Web is a highly vetted consumer
medium
• Web offer many pros and few cons
• Only medium for information,
applications and services
• As more mobile browsers add
services to detect location,
acceleration or use of the hardware,
the need for native applications will be
reduced
The Ubiquity Principle –
Control
• Control the mobile application
distribution
• Mobile application vendors always
have to rely on middlemen to get their
products to market
• The purpose of the product is to
service them
• Funding of creating mobile
applications will always remain a
small, high-risk investment
The Ubiquity Principle –
Consumer Expectations
• Consumer expect applications just
work and rightfully
• Fail to do this is not only a sale lost,
but also customer is lost for good
• Consumer spends money on device
and wants content to support it
• Cross-platform support is challenging
• Numerous visits occur when a
consumer has purchased a brand-new
device, but will drop off later
The Ubiquity Principle –
Ubiquity in the Mobile Web
• Mobile Web is the only platform that is
available and works across all mobile
devices
• Sharing the same set of standards
and protocols
• Mobile web is the easier platform to
learn and the cheapest to produce,
the most standardized, most available
and the easiest to distribute
• Level of complexity to adapt to the
fragmentation is lower
Key features to consider for
creating a native application
• Charging for it
• Creating a Game
• Using specific locations
• Using Cameras
• Using Accelerometers
• Accessing the Filesystems
• Offline Users
• Push Notification
• Background Task
Charging for it
• Charging for things on mobile devices
has come down to two obstacles:
• Enter a credit card number, need to
store the subscribers’ credit card
information on a secure website
• By the device maker, they will collect
the payment and cut and pass on the
rest of it to you. This means that you
must work within the rules and
regulations of their marketplace
Creating a Game
• Games are resource-intensive
• Almost always require the use of a
device or platform API
• When users launch a game, they have
some expectations of what it is going
to look and act like
• Some game porting house can help to
get your game onto multiple platform,
but it is costly
Using Specific locations
• Detect the users’ locations by GPS
• Traditionally, the only way to access
users’ locations is through native
application APIs
• Devices that run WebKit, like iPhone
or Android devices that runs the
Opera or Mozilla browsers can detect
user’s location
Using Cameras
• Traditionally, mobile MMS is used to handle mobile
photo interaction
• The MMS server somewhere does something with the
photo and sends an alert to you, which is complicated,
time consuming and fairly unreliable
• Native application developers can simplify the task to
just taking a photo from within an application
• Through HTTP connection to transfer photo
• Use for sharing snapshots or videos of friends
• Used to process bar codes and to redeem promotions
Using Accelerometers
• An simple application that measures
physical acceleration and gravity and
send data back to the device
• Detect the device physically rotated,
adjusting the display from vertical to
horizontal orientation
• Use the accelerometer to interact with
a device in a more natural way
Accessing the Filesystems
• Use the data store on the device
• Such as address book, photos, and
email message, or data from another
application
• Store information only in limited doses
• Never do anything with the users’ data
without their express permission
Offline Users
• Develop the native application when
the user is likely to be offline or out of
range of a mobile network
• Mobile games played on an airplane
• Mobile browsers that support HTML5
actually include the capability to create
offline apps
Notification & Background
• Receive Notification like instant
message
• Continuous update in background –
GPS Tracking, Update Stock Market
Data
Hybrid App to Fill the Gap
• Line up Native Power + Web Flexibility
• Wrap an WebApp (store offline) as
Native App
• Content Update by Ajax
• Communicate with JavaScript
between native code and web code
• PhoneGap project, an open source
effort that allows you to create native
applicaions for iPhone, Android and
BlackBerry devices
When to make a mobile Application
base on Web
• Long-term viable platform for mobile content,
services and applications
• Many device features like location and filesystem
access to your web app.
• The rate of innovation for creating mobile web
apps across every mobile device maker is at its
highest level in years
• Achieving same standards
WebApp is better option
when:
• We need to update our content frequently
• We don’t need any of the Apple/Play Store
features
• We don’t need especially fast graphic
performance
• We are not dependent on native functionality
• We are not dependent on running our app in the
background
•
We are not dependent on sending(push)
notifications
Pros of WebApp:
•
•
•
•
•
•
•
•
•
•
•
High-level Programming skills are not required
Apple development program subscription is not
required
Developing on a Mac running OSX is not required
Web standards skills are reusable in other
development areas
Development life cycle is fast
Bug fixing is in real time
An enterprise Web App doesn’t require an enterprise
license
A WebApps don’t require Download and Installation
WebApps are accessible to Apple and non-Apple
devices
WebApps will run on most device (mobile or desktop)
with a browser
WebApps are packable in native app with tools like
PhoneGap
Cons of WebApp:
• In some heavy contexts, WebApps are
slower than native apps
• Some sophisticated UI effects are difficult
to achieve
• Data stored in the file systems are not
accessible
• Some hardware features are not
accessible
• A personal payment system is required if
we want to charge for the app
• Push Notification
• Background Processing
Four different approaches
to a WebApp
• Level 1: Compatible
• Level 2: Optimized
• Level 3: Dedicated
• Level 4: Native-Like
WebApp and Native App:
What Makes the difference
for the user?
• User Interface (UI)
• Native – Close to the theme of system
• Web – More Flexibility
• User Experience (UX)
• Native – Usually Faster
• Web – Slower
• Human Computer Interaction (HCI)
• Native – Multitouch, Sensors, NFC
• Web – Usually Single Touch, less
sensors support