Transcript LecSept11x
How was the LAB!?!?
• Did you get your 4%?
• Are you ready for your next
“challenge”?
• You have ROCKED those posts!!!
– Thanks, I learned a LOT!
– Hit the polls for browsers and platforms
• NEXT Post (part of next 4%)
– Devices: the facts!!!
Brief History
• The idea of "the internet" - linking every
computer in the world together on the same
network - goes all the way back to 1963!
• This idea went through many iterations,
beginning with ARPANET in 1969.
• In North America, the last of these iterations,
NSFNET, was founded in 1985.
• Commercialization of the internet began in the
early ninties and was completed in 1995, when
the NSFNET Backbone Service was shut down.
The World Wide Web
• Originates from a 1989 proposal by Tim
Berners-Lee and Robert Cailliau
• Their basic idea was to create a system
which would use hypertext to help
researchers find and access various files
• The term "hypertext" - coined in 1963,
though the idea existed long before then refers to text displayed on an electronic
device which includes a reference to other
text which the user can immediately
access
Thanks Logan!
• HTML: content—information and data is
to be shown
• CSS: style and appearance—colours,
fonts, layouts are used
• JavaScript: The behaviour—what
happens when a user interacts with a
web page/application, whether it be
calls to the server to retrieve data or
toggling the display of a web element
HTML
• HTML is the file format devised for the
pages of the WorldWideWeb project
• Stands for Hyper-Text Markup
Language
• Derived from SGML (Standard
Generalized Markup Language).
• Supported by all browsers
Tags
• Tags are the basic building blocks of
HTML.
• A tag starts with a "<" character and ends
with a ">" character.
• Within the tag is the element, which tells
the browser what type of tag it is: <h1>
• Most tags occur in pairs, where the second
tag starts with a "/" before the element:
<h1> ... </h1>
• When a tag is self-contained, the "/"
appears at the end of the tag: <br />
Tags
• The HTML specification includes many
elements.
• To get started, we can build a basic web
page with just four elements: <html>,
<head>, <title>, and <body>.
• Note that between tags, whitespace
(spaces, line breaks, tabs) doesn't really
matter.
“view source”
<html>
<head>
<title>Hello there</title>
</head>
<body>Hello,
there!</body>
</html>
Cascading Style Sheets (CSS)
• A stylesheet is effectively a list of rules.
• Each rule starts with a selector, followed
by a property list inside a set of curly
braces {}.
• The selector tells the browser which tags
the following property list applies to.
• The property list is a set of property-value
pairs, each ending with a semicolon.
Background-color
•
•
•
•
•
•
background-color: #EEEEDD;
“bytes” for Red Green Blue
In hexadecimal!
Each value represents 4 bits (a “nibble”)
A bit (binary digit) can be 1 or 0
Let’s count!
Bits? Bytes? why?
• Pick a computing device (any device!
Doesn’t even have to be mobile!)
• List it’s characteristics in terms of
– Processor(s)
– Networking/Communication
– Memory
– Storage
– I/O…
Technology advances
Networking
Processors
Memory
Storage
I/O
Technology advances
Networking: options?
Processors: options?
Memory: options?
Storage: options?
I/O: options?
BUT THAT IS NOT ALL!
• Software is changing rapidly too
– Browsers have developed…
– HTML5, CSS 3…
– frameworks for hybrids: PhoneGap
• go to the browser poll on Piazza and vote!
• the browser is an environment for
– viewing webpages
– running web apps
• real game changer!
Bottom Line…
• Freaking incredible progress!
• Between MY starting out and YOUR
starting out…
– Things got better, smaller AND cheaper!
– And we’re not done yet!
• Crazy—transformative!
• Opportunities!
NOW…
• We have a great survey of apps!
• Some of you produce apps too (already!)
• Let’s start from square one…
– The anatomy of computing devices
• Processor, Memory, Storage, Networking, I/O
• The great debate
– HTML5 versus Native
• Hybrid?
The great debate…
• We will have this as an ongoing theme!
• An opening bid!
• HTML5 VS NATIVE: THE MOBILE APP
DEBATE
• By Michael Mahemoff
• Published June 3, 2011
• http://www.html5rocks.com/en/mobile/nat
ivedebate/
HTML5 VS NATIVE: THE
MOBILE APP DEBATE
• mobile apps and HTML5
– plenty of overlap!
• web apps run in mobile browsers and can also be repackaged as native apps on the various mobile
platforms
• wide range of platforms to support!
• is HTML5 a "write one, run many" solution?
• compelling reasons to go native
FEATURE RICHNESS
POINT: NATIVE CAN DO MORE
• the experience of the app itself, and
the way it hooks into the device's
ecosystem
– swipe events, mutlitouch, GPS and camera
– access to the operating system
• full storage system
• full range of access to camera, battery levels,
etc…
FEATURE RICHNESS
COUNTERPOINT: HYBRIDS, AND THE WEB IS CATCHING UP
• HTML5 app is stuck in a sandbox with a limited API, limited
access to device specific features
– WHY?!
• frameworks for building hybrids (e.g., PhoneGap)
– exposes native features as web services,
– in a hybrid app can hook into platform
– adds complexity though!
• web standards are evolving
– modern mobile browsers are keeping pace with standards
– offline storage, geolocation, canvas graphics, and video/audio
playback, device orientation detection…
PERFORMANCE
POINT: NATIVE RUNS FASTER
• native apps don't have the web runtime
barrier to deal with
– this not a trivial topic!
• run close to the metal and can take
advantage of performance boosters like
GPU acceleration and multithreading
– this is REALLY not a trivial topic!
PERFORMANCE
COUNTERPOINT: WEB RUNTIMES GETTING
FASTER, AND MOST APPS DON'T NEED THE
SPEED ANYWAY
• graphic rendering engines have also sped up the
web
• multithreading is a possibility
• the majority of mobile apps aren't bleedingedge 3D games
• but, for those that are… WebGL
– WebGL (Web Graphics Library) is a JavaSript API
for 3D graphics that works with web browsers
DEVELOPER EXPERIENCE
POINT: NATIVE IS EASIER TO
DEVELOP
• native apps use programming languages
such as Java, Objective C, C++,…
• you KNOW your target device
• development faces a huge diversity
– no guarantee feature X will be available
when you do a port
DEVELOPER EXPERIENCE
COUNTERPOINT: WEB IS EASIER, AND TARGETS
MULTIPLE DEVICES
• develop an Android app in Java, and you're faced with a
full port to Objective C to support iOS
• develop a web app once and it will run in Android and iOS,
not to mention BlackBerry, Windows Mobile and ...
– well, that's the theory anyway!
• "fragmentation" has always been this way on the web, and
there are some well-known techniques to deal with it
• the principle of progressive enhancement
– target a basic device first, and add layers of platformspecific awesomeness where it's available.
LOOK-AND-FEEL
POINT: NATIVE FITS PLATFORM
• controls presented consistently and
manipulated in the same way
• platforms have standard idioms for such
things, and you can't satisfy them all
with a single HTML5 app
• a lot of the expected look-and-feel "for
free" just by using the native toolkit
LOOK-AND-FEEL
COUNTERPOINT: THE WEB HAS ITS
OWN LOOK-AND-FEEL
• write a basic "one size fits all" version, and
then progressively enhance it
• target those platforms you care about
– "browser detection”
• many apps don't care
– games
– twitter clients
DISCOVERABILITY
POINT: NATIVE APPS ARE EASIER TO
DISCOVER
• App distribution mechanisms, like Android's
Market and Apple's App Store, are popular!
• Any developer can submit their native app to
the marketplace
• users discover it through a combination of
browsing, searching, and getting
recommendations.
• if you've done your job right, glowing ratings
DISCOVERABILITY
COUNTERPOINT: ACTUALLY, WEB APPS
ARE EASIER TO DISCOVER
• search engines
• any individual can share web apps with
their friends
• just click on the link and launch the app in
their device's browser
• users can rate and comment on apps, but
that's changing too
MONETIZATION
POINT: NATIVE CAN BE MONETIZED
• "6 year-old makes app during lunch hour, sells a
zillion copies at $3 each".
• mobile platforms offer several avenues for
developers to directly charge for their apps
– one-time payment, to unlock the app for all
eternity
– subscriptions
• allow developers to convert a smash-hit app into a longterm revenue stream.
• also monetize with traditional web models
– advertising and sponsorship
MONETIZATION
COUNTERPOINT: THE OPPORTUNITIES ARE GROWING
• subscription-based "software as a service”
• create a native "wrapper app" - for each platform you want to
target,
– create an empty native app that simply contains a web view
– submit these apps to the various marketplaces (and hopefully watch
the money roll in!)
• web services like PhoneGap Build and Apparatio
– point these websites to your code repository
– out pops an Android app, an iOS app, and so on...ready for you to
submit to the respective stores
– No installing native SDKs on your machine; all you needed to build all
these native apps was a a code editor and a web browser.
• Web store?
– Google introduced the Chrome Web Store last year for desktops
Winner?
• some apps are best suited for native
and some are best suited for the web
• both are progressing at an amazing rate!
• hybrid apps
– web view where it's possible and platformspecific native components where it's not
• want to target the multitudes of
devices and operating systems around?
Phonegap
• Easily create apps with the only free
open source framework that supports 7
mobile platforms.
• Wrap your app with PhoneGap
• Deploy to multiple platforms!