Download - 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?