cm i padwebdev_lunch_learn

© 2010 Critical Mass, Inc. All Rights Reserved

iPad Web Development

A magical and revolutionary presentationDecember 13, 2010 By Abraham Velazquez &Alex Zelenskiy

Native App vs. Web App

Objective C + APIs/Backend Higher Cost ≈ 3-5x Native does more, it's faster/smoother

App Store Promotion Update require apple approval

Native sits on the device

Native is best when you need to cache/store a lot of content that does not change. Access to all iOS APIs

HTML5/CSS3/JS + Backend Considerably lower costbecause they are more common languages

Instant updates Native does more, is faster/smoother Deployed online and viewed via safari or pulled into application wrapper

No internet, no app. There are some caching options, but limited. Access to Limited APIs

Web Apps on iPad vs. iPhone vs. Android

iPad 1024x768APIs: Location, Orientation, Accelerometer, Tap Targets and swipes Video, Local Storage CSS3 Fonts

iPhone320x480640x960

APIs: Location, Orientation, Accelerometer, Tap Targets and swipes Video, Local Storage CSS3 Fonts

Android240x640360x640320x480480x800600x1024 (Tab) APIs: Location, Orientation, Accelerometer, Camera Video, Local Storage

Flash! (Kinda)

Poor Font Support

All 3 use webkit... but!

iDevices: stop worrying about this stuff!

Reliable Layouts (IE6 is dead)

Great CSS3 Support because it's the almighty WebKit

Flash mobile is dead (Kinda)

Mobile Video is standard and reliable

Hover events, there is no hover for touch.

Start worrying about this, though.

1. Animation/transition performanceTransitions are possible, but use wisely.To many will cause poor performance

2. Slow Internet speedDon't overload with high-res images or non-optimized video.Use progressive downloading

3. No fixed positioningNo toolbars at top of pages, unless you use a library

4. Need to pay attention how content is being servedWeb view and mobile safari do not fire the same events, for example.

6. Two screen orientationsDesign for landscape and portraitHow will content re-flow based on position.Headers shrink down, Sidebars become footers

Best Practices: Design

Your finger is 30 pixels wide! (60pixels on iPhone 4)

Give tappable elements in your app a target area of at least 44 x 44 pixels.

Keep 12ish pixels between navigation elements (double on iPhone 4).

Stick to native styles where ever possible

Keep it simple! What are the bare essentials?

Test both, in Simulator and load JPG on Device

Best Practices 3: UI

Keep in mind where users hands are going to be: iPhone uses a bottom nav

iPad uses split view

Examples

Side Navigation

Best Practices: Development

Keep requests down (5-10 per page)

No Faux CSS Elements :before or :after

Anything that causes dom redraws is bad

Use classes for everything(Turn then on/off when you need them)

CSS3 is good, but go easy on it

Optimize all your images

Use CSS/Image sprites, wisely

Canvas and SVG elements are pretty good

HTML 5

Video tags are good.

Some of the new HTML form attributes will trigger the alternate screen keyboards on mobile devices. This is really handy.

CSS3

background-color: rgba(180, 180, 144, 0.6);

opacity: .5; text-shadow: 1px 1px 3px #888; background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #444444),color-stop(1, #999999)); -webkit-border-radius: 12px; -webkit-box-shadow: 0px 0px 4px #ffffff;-webkit-transition: all 1s ease-in-out;-webkit-transition-property: opacity, left;-webkit-transition-duration: 2s, 4s; transform:skew(35deg); transform:scale(1,0.5); transform:rotate(45deg);transform:translate(10px, 20px);

CSS3

You can do this...

but don'!

Font Support - Use it!

iosfonts.com list of native fonts on iPad and iPhoneTypekit works on everythingGoogle font directory now works on everything. Use something like fontsquirrel.com to generate fonts in the correct formats. Check font licenses before including them. Older iOS versions are at a (50%) risk of crashing when you bind different @font-face weights to the same typeface.

Mobile Webkit vs. Webkit

Mobile webkit is a lot like desktop webkit, except it runs on slower hardware, tries to scale everything to a tiny screen*, and does not remember what position:fixed is.

*unless you tell it not to through the use of meta tags:

<meta name="viewport" content="width=device-width, initial-scale=1.0; maximum-scale=1.0;">

Tricks

There are some undocumented features of webkit that produce desired effects. For example, translate3d can be exploited for smoother rendering:-webkit-transform: translate3d(0,0,0) Unfortunately, stuff like this is not a feature and could be "fixed" by apple at any time.

CSS Media Queries

<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">

<link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">

@media only screen and (max-device-width: 1024px) and (orientation:portrait) {

}@media only screen and (max-device-width: 1024px) and (orientation:landscape) {

}

Meta Viewport Tag

Javascript

Mobile browsers have device-specific javascript events that you are able to hook into:

device rotationtouch (different from click)

Caveat: these are not consistent between mobile safari and webview in iOS apps.

window.addEventListener('orientationchange' in window ? 'orientationchange' : 'resize', foo, false);

document.body.className = orientation % 180 == 0 ? 'vertical' : 'horizontal';

Javascript

Don't use JS libraries, unless you really need to.Standard JS is reliable.iScroll JS if you have to to use custom scrollingRapahelJS for SVG and graphics Mobile browsers have device-specific JavaScript events that you are able to hook into:

device rotationtouch (different from click)

Backend / AJAX

The back end is going to be pretty much identical.

All of the dynamic data, whether you have a web or native app, is likely going to be piped over http.

DEPLOY!

Questions?