blog.Ring.idv.tw

HTML5

Web Application for iOS

隨著iOS6開始支援更多的HTML5 related APIs和相關規格,如:requestAnimationFrameWeb Audio APIWebSocket (RFC 6455),下述是一些針對iOS平台開發Web Application可參考的相關組態設定:

Viewport Meta Tag

Viewport組態設定可以說是Mobile Web Application最重要的設定之一,因為它是直接用來控制瀏覽器是如何呈現你的網頁內容:

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

width=device-width: 表示用來適應各個不同裝置的寬度大小

initial-scale: 1.0 用以初始化的scale

maximum-scale: 1.0 由於初始化的scale為1.0,所以此行等同於讓使用者無法縮放

詳細的設定細節與圖文說明可參考:Configuring the Viewport

Full-Screen Mode

設定Web Application是否採用full-screen mode來運作

<meta name="apple-mobile-web-app-capable" content="yes" />

另一方面,開發者也可以使用JavaScript去取得「window.navigator.standalone」property來判斷目前是否運作在full-screen mode。

Status Bar Appearance

設定狀態列的樣式,分別有「default」、「block」和「black-translucent」可以使用,若採用full-screen mode運作可以採用「black-translucent」

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent"/>

Format Detection

由於Safari預設會自動偵測可能的電話格式字串並主動加入連結,所以下述設定可以將此功能關閉

<meta name="format-detection" content="telephone=no">

Webpage Icon for Web Clip

此設定為當Web Application加入主畫面螢幕之後,在螢幕上要呈現的圖示:

<!-- iPhone/iPod -->
<link rel="apple-touch-icon" href="images/touch-icon-iphone.png"/>
<!-- iPad -->
<link rel="apple-touch-icon" sizes="72x72" href="images/touch-icon-ipad.png"/>
<!-- iPhone/iPod Retina -->
<link rel="apple-touch-icon" sizes="114x114" href="images/touch-icon-iphone-retina.png"/>
<!-- iPad Retina -->
<link rel="apple-touch-icon" sizes="144x144" href="images/touch-icon-ipad-retina.png"/>

Startup Image

Web Application啟動後要顯示的初始畫面,預設為320x460 (20px保留狀態列使用)

<link rel="apple-touch-startup-image" href="img/splash-screen-320x460.png">
<!-- iPad Landscape -->
<link rel="apple-touch-startup-image" sizes="1024x748" href="img/splash-screen-1024x748.png" />
<!-- iPad Portrait -->
<link rel="apple-touch-startup-image" sizes="768x1004" href="img/splash-screen-768x1004.png" />
<!-- iPhone Landscape Retina -->
<link rel="apple-touch-startup-image" sizes="960x600" href="img/splash-screen-960x600.png" /> 
<!-- iPhone Portrait Retina -->
<link rel="apple-touch-startup-image" sizes="600x960" href="img/splash-screen-600x960.png" /> 

Add to Home Screen

上圖是iPhone瀏覽Yahoo!行動版首頁所出現的「Add to Home Screen」提示,原本想說自己來寫一個好了~ 後來想想這東西應該有早已有人作出來了,找了一下發現網路上有位Matteo Spinelli作者開發了ADD TO HOME SCREEN元件,有興趣的話可以參考它的作法。

Cancelling Default Touchmove Event

防止使用者移動頁面,直接通知Browser不要執行預設的touchmove事件。

window.onload = function()
{
	document.addEventListener("touchmove", function(e){
		e.preventDefault();
	}, false);
}

參考資源

iPhone 4 Retina “apple-touch-startup-image” for Web-apps

Supported Meta Tags

Configuring Web Applications

2012-06-18 16:42:37 | Add Comment

探討requestAnimationFrame

(圖片來源:source)

#2012-06-12  iOS 6 開始支援requestAnimationFrame

理論上「requestAnimationFrame」函式是用來處理動畫更新較好的作法,但一般來說在Canvas上要控制動畫更新的方式,大多數常用的方法不外乎透過JavaScript函式「setInterval」或「setTimeout」,基本上透過這兩個函式去控制動畫更新並不會有啥大問題,但問題是這兩個函式本質上並不是為控制動畫更新所專門設計的,我們只是藉由「setInterval」和「setTimeout」的特性將它應用在動畫更新上,所以我們需要有一個新的作法,而它就是「requestAnimationFrame」函式。所以重點就在於,為何控制動畫更新需要有「requestAnimationFrame」函式來取代「setInterval」和「setTimeout」?

理由

1. 當瀏覽器的頁面是處於最小化,或是隱藏在分頁/背景中的狀態,此時瀏覽器可能仍在執行動畫更新的動作,如此便會浪費CPU資源(demo)。

2. 大多數客戶端的螢幕更新頻率多設為60Hz,意指為平均每間隔約「16.7ms」的時間會更新一次螢幕畫面,然而重點就在於我們並不曉得客戶端的螢幕更新頻率為多少?所以若欲透過「setInterval」或「setTimeout」函式來控制,我們也無法得知理想上的動畫更新間隔時間該設為多少?而此時就可以交由「requestAnimationFrame」函式來幫我們處理,以達到同步動畫更新和螢幕更新頻率。

「requestAnimationFrame」函式被規範在「Timing control for script-based animations」標準之下,該標準最初的Working Draft是在去年六月份由Web Performance Working Group所發佈的。

參考資源

IEBLOG: USING PC HARDWARE MORE EFFICIENTLY IN HTML5, PART 1

What the requestAnimationFrame API Should Have Looked Like

requestAnimationFrame API: now with sub-millisecond precision

2012-05-14 14:58:06 | Add Comment

目前的Web Audio API

#2012-06-12 update - iOS6支援Web Audio API

Web Audio API是一個提供你方便處理或合成聲音的JavaScript API,它是最近這一年內才逐漸開始發展的標準,主要負責推動此標準的是W3C Audio Working Group,該組識是在去年3月25日才成立的,根據他們預期的規劃來看~ 2011年第2季會發佈初步的工作草案(Working Draft),並預計在2012年第3季成為正式標準,不過直到去年2011年12月15日該組識才發佈初步的Web Audio API - Working Draft,談到這邊.. 那為何需要有此標準呢?HTML5不是已經定義好<audio>標籤了嗎?我想應該這麼說~ HTML5 <audio> Tag的主要目的是用於Media Playback,所以它允許你可以將聲音檔放在網路上,並透過瀏覽器直接播放而不需要仰賴其它的Plugin(如:Flash Player),但...如果我們想動態製造些混音或聲音特效時該怎麼處理?為何當初Angry Birds Chrome的聲音功能還需要仰賴Flash呢?而這也就是為何需要有Web Audio API存在的原因。

P.S. Angry Birds Chrome開發人員使用Web Audio API後的心得

玩玩看吧! 改一下下述程式你也能很快的做出一些混音或聲音特效。

var audioContext;
var audioBuffer;

window.addEventListener('load', init, false);
function init() 
{
	try 
	{
		audioContext = new webkitAudioContext();	
		loadSound("music.mp3");
	}	
	catch(e) {
		alert(e);
	}
}
function loadSound(url)
{
	var xhr = new XMLHttpRequest();
	xhr.open("GET", url, true);
	xhr.responseType = "arraybuffer";
	xhr.onload = function() 
	{
		audioContext.decodeAudioData(xhr.response, function(buffer) 
			{
				audioBuffer = buffer;
				playSound();
			}, function(e){alert(e);}
		);
	};
	xhr.send();
}
function playSound()
{
	var source = audioContext.createBufferSource();
	var gainNode = audioContext.createGainNode();
	var filter = audioContext.createBiquadFilter();
	source.connect(filter);
	source.buffer = audioBuffer;
	
	filter.connect(gainNode);
	filter.type = 0; // Low-pass filter. See BiquadFilterNode docs
	filter.frequency.value = 500; // Set cutoff to 500 HZ
	
	gainNode.gain.value = 1.0;
	gainNode.connect(audioContext.destination);		
	source.noteOn(0);
}

相關資源

GETTING STARTED WITH WEB AUDIO API

DEVELOPING GAME AUDIO WITH THE WEB AUDIO API

2012-04-24 16:29:36 | Add Comment

聊聊目前的WebSocket技術

#2012-06-12 update - iOS6支援RFC 6455

The WebSocket Protocol在去年12月已經被IETF(Internet Engineering Task Force)提出作為正式標準了(The WebSocket Protocol {RFC 6455}),另外由W3C(World Wide Web Consortium)所主導的The WebSocket API標準也在同個月份從Working Draft改為Candidate Recommendation狀態,所以如果您有需求想開發HTML5相關的多人互動遊戲或應用程式,其實可以開始善用這個技術了! 因為在一個禮拜前Apache也釋出Tomcat 7.0.27版本,該版本也開始支援WebSocket的技術,雖然比Jetty晚了許久... Orz 不過有一點值得注意的是,在今年的2月份由Oracle的Danny Coward所領導的JSR 356: JavaTM API for WebSocket規格也正式被提出了,不過該規格目前仍尚未定案,所以現階段你採用Tomcat所寫的WebSocket服務如果想移植到Jetty的話,仍需要作部份的改寫。

另外針對Mobile Devices的支援而言,根據mobilehtml5.org所整理的資訊來看,以目前兩大行動裝置平台iOS和Android來說,iOS從4.2版即開始支援WebSocket技術,不過根據筆者測試的結果~ iOS 5.1目前仍尚未支援正式標準的WebSocket Protocol,不過這不打緊~ 下一個版本更新也許就會改善了~ 另一方面Android 4.0內建的Browser雖然也尚未支援WebSocket技術,但是Google所發表的Chrome Beta Browser已經開始支援了,這意味著下一個Android版本的Browser很快就會完整支援WebSocket技術了! (筆者猜測)

倘若從應用的角度上來看,大約兩個禮拜前Mozilla也發表了一個結合WebSocket和Canvas技術的多人線上遊戲實驗BrowserQuest,所以想要開發多人線上即時體驗的應用可以不需要依賴Flash了,不過仍然值得注意的是先前筆者曾在「PhoneGap 1.0.0 for Android」一文所提到的一致性與相容性的問題,畢竟採用Flash技術不太需要去擔心這方面的問題,而現階段每個Browser支援HTML5的程度不一,所以這是需要被考慮的。

相關資源

WebSockets: A Guide

2012-04-13 14:09:19 | Add Comment

近期熱門的Gesture-based Apps

將近快兩個月沒有更新Blog了... Orz 來寫一下近期看到的東西~

大約在二月中旬時,有一個以Gesture-based的Task Management App創造了不少話題,它叫「Clear」,顧名思義它的操作方式就如同它的名字一樣「簡潔」,它允許你可以透過「Pull」、「Swipe」和「Pinch」等手勢方式來操作待辦清單的管理,透過這樣的方式來節省操作時間,同時也提高使用者的使用體驗~

另外在三月中旬時,也有一個以Gesture-based的Calculator App發佈,它叫「Rechner Calculator」,它的概念和一般傳統的計算機最大的不同在於,它只提供「數字鍵」!其餘的加減乘除完全都仰賴手勢的方式操作~ 所以它的介面相對來說也非常的「簡潔」! 從視覺上看起來也來的舒服些~

從這兩個例子都可以知道一個好的使用者操作介面有多麼重要! 尤其是開發視窗系統的時候,多一個按鈕或對話框,從工程開發的角度而言或許很正常,但從使用者的操作體驗而言,這個按鈕或對話框可能每天就要多點上百次!

還記得去年七月寫的一篇「jQuery Mobile - Adding a swipe to delete button to a listview component」文章,裡頭提到了用jQuery Mobile所支援的Touch Event: Swipe來實作一些功能,那它是如何實作的呢?

其實從上圖這四個參數就可以猜得到它是如何定義Swipe這個手勢事件的判斷:

1. scrollSupressionThreshold: 10

水平滑動超過10px位移則呼叫「event.preventDefault()」來防止Scrolling的動作。

2. durationThreshold: 1000

在1秒的時間內完成這個動作,否則它就不是Swipe

3. horizontalDistanceThreshold: 30

水平滑動的位移至少要超過30px

4. verticalDistanceThreshold: 75

垂直位移必須小於75px

只要同時滿足上述四個條件即觸發Swipe事件,不過更令我感到好奇的是,不曉得Apple的「UISwipeGestureRecognizer」是如何定義上述這些參數來決定Swipe事件?

有興趣的朋友可以參考jQM的原始碼:jquery.mobile-1.0.1.js

2012-03-30 18:45:28 | Add Comment

Next Posts~:::~Previous Posts
Copyright (C) Ching-Shen Chen. All rights reserved.

::: 搜尋 :::

::: 分類 :::

::: Ads :::

::: 最新文章 :::

::: 最新回應 :::

::: 訂閱 :::

Atom feed
Atom Comment

::: 人氣指數 :::

今日人氣:498

累積人氣:3006780


::: 線上人數 :::

counter