Pages

Friday, January 28, 2011

User research lite version for your mobile app development

這是一個輕量版的使用者測試的程序,如果拿來練習,或者導入第一次使用非常適合。原來這份程序資料出自我參加互動設計讀書會的前輩悠識數位首席架構師 Richard Tsai,同樣是 User research,希望藉此也能套用在我們 Mobile app 開發上。

每一個活動可以參考如下的程序來進行,依序為找人、訪談、觀察、記錄、分析與解釋。

找人要考量到受訪者本身的條件,不是越內行越好,而要找非 Mobile 相關工作的人 (例如手機介面設計、手機程式開發、市場調查、研究人員等) ,該位不曾在市調、公關、手機開發公司工作、最近沒有參與過類似的研究。但是要有使用 mobile app 的相關經驗,例如擁有 Android 或者 iPhone 等等智慧型手機經驗,而且會有可能下載用我們軟體的人。因為這些人就是我們的目標使用者。

訪談前要做好說明,讓使用者可以有安心預期的心裡準備。受訪者通常會緊張、不知道我們要做什麼,研究後會把資料怎麼用,而且怕被考到說不會用智慧型手機。所以我們要清楚說明訪談的目的 (測試的目標不是要考使用者會不會用我們開發的軟體),而是要扮演過程使用的角色,可以提問題,但是觀察者不會教導如何操作。訪談過程會如何進行,人事時地物和抄下來筆記會如何整理都要一一說明清楚。

訪談開始前,可以先做些問卷調查性的問題,當作暖場所用。經常用哪些 Mobile app?每天什麼時間點會使用?喜歡哪些有名的 Mobile app?會希望有哪些 app 裝在自己手機上呢?最近購買付費的 app 又分別是哪些呢?印象好的不好有哪些?

可以讓使用者盡量的聊購買那些 App 的動機和原因,過程會怎麼進行,整體的體驗是好是壞都可以說明。

請使用者開始使用我們的 mobile app,這 app 可以是 prototyping 、可以是完成 10%、20%、30%、或者只有介面沒有後端程式都沒關係。可以給與使用者特定的任務,例如今天的手機程式可以是購買汽車、租售屋、電子書閱讀看開發的產品是什麼都行,出相關的情境題目,請使用者開始操作,觀察者開始觀察。

過程中我們要注意多聆聽,不要操控使用者與提示。別太主觀評斷使用者使用行為。對使用者要有友善,不能評斷對錯。為了避免下結論的問髮,所以不要問認為這產品好不好,喜不喜歡,寫的棒不棒。最重要的觀察者不要插嘴干擾。

如果在提問時候要問開放式的問題,例如對於這介面有什麼想法,這個功能對你而言會如何幫助等等的方式,而不要問喜不喜歡、滿意與否會造成使用者下個人主觀意見的答案。

觀察與紀錄是整個過程最重要一環,要紀錄使用者背景及能力、過去購買使用 App 的經驗、使用者購買動機、如何使用、怎麼在該 App 上面操作來達到目的,而且是否跟該 Mobile App 的主要功能相符。如果經過使用者同意,有錄影或者錄音會更適合,這樣是後可以讓整理資料時候對照用。

當我們事後蒐集了以上這些資料,我們要試著來解釋。使用者背景是怎麼樣,有使用過哪些應用程式的經驗,對於操作我們開發的應用程式遭遇了哪些問題,這些問題可以分成哪些類型 (功能改善、功能建議、介面動向、文字表達等等),列入我們開發上的 issues,這樣作為下個階段到來前,一個很大實質幫助的助力。

以上這是一個輕量版的使用者測試觀察程序,相信經過這樣的活動結束,對於自己開發上很多的困惑與猶豫不決的議題,都可以獲得很好的第三方公正的解答。別忘了,這些協助受測的使用者,代表著我們未來產品上市的使用者對象。

Saturday, January 22, 2011

DECIDE: A framework to guide evaluation

D E C I D E: A framework to guide evaluation
1. Determine the goals
2. Explore the questions
3. Choose the evaluation paradigm and techniques
4. Identify the practical issues
5. Decide how to deal with the ethical issues
6.Evaluate, interpret, and present the data

為了擁有詳細的計畫評估,我們要由明確的目的及合適的問題所引導的 (Basili et al., 1994),為了引導我們評估,可以使用 DECIDE 架構,它提供了這些檢核項目幫助我們來評估。

確定目標 - 評估所注重的整體目標,評估說目標為何?誰會需要用它?原因為何?一個有助於區分使用者需求的評估方式據有評估上不同的目標。更明確的解釋是確認評估者了解使用者的需要。確認隱喻以作為設計的基礎、確認並檢查最終的產品介面具有一致性、調查科技影響工作實務的程度、確認現有產品界面如何加強以促進使用性。

探索問題 - 為了讓目標可以操作,必須讓問題能得到滿意的答覆是有必要確定的。一個問題也會區分為許多次問題,以讓評估更為精確。

選擇評估的範本及技巧 - 評估範例決定所使用的技巧種類,這邊在取資料上有很多種可以搭配使用,多種技巧結合可以獲取不同的觀點,每一種形式的資料都會從不同的角度對事情做描述。

確認實際的議題 - 把使用者、功能及設備、時間表、預算及評估者的經驗都需要列入考梁。在進行評估開始前就要把他們列出來。評估核心概念是要讓合適的使用者參與。使用者需要加以尋找及篩選過,確定他們符合產品的目標使用族群。另外必須考量到如何讓使用者進行參與,時間多長,過短過長要注意,且測試過程當使用者犯錯時候,要謙虛有禮貌的對待他們。向使用者解釋是測的是系統而不是他們,並策劃一些活動使他們在測試前能夠熟悉系統可讓使用者感到放鬆。設備與裝備都要考量,例如操作工具系統,和多少攝影機,如何擺設。時間表和預算表也要明確的定義出來並且在有限的資源和時間情形下做好工作。

決定如何處理道德議題 - 人們同意參與評估研究後,就會付出時間和信任感,兩者都要尊重的。並且要提供協議書讓雙方可以同意,包含告訴參與者研究的目的,讓他們知道一旦參與了評估會遇到哪些狀況。整個流程、需要花費的時間和所蒐集的時間、蒐集資料的形式等等。最終報告的形式也要讓他們知道。必須說明使用者透露的資料會都是機密性的,必須使用編碼過來儲存,後續公開也要用匿名方式。確定使用者如果參與到一半可以自由的停止評估。儘可能給與使用者酬勞,因為這可以創造相互承諾的正式關係及責任感。進行評估普遍的規則就是『己所不欲,勿施於人』。

評估、解釋及呈現資料 - 所蒐集的資料種類有一些選擇性,這些資料是否要統計分析?如果蒐集到的質化資料應該如何的被分析和呈現?一般性的問題以什麼方式衡量?結果是否據有整合性,範圍如何?信度 (Reliability)、效度 (Validity)、偏見 (Biases)、範圍 (Scope) 等等。

最後,在一項評估的測試計畫中,進入正式研究前先做前導性研究室值得的。前導性研究是研究的一個小小的流程測試,目的是確認真正的研究開始前計畫的可實施性。許多的評估者都會執行幾的前導性的研究。正如反覆的設計一樣,他們從中得到回饋並且修正程序,隨後不斷的測試直到他們認為他們已經有良好的研究方式了。如果尋找使用者有困難或是限制,可徵詢同事和朋友的意見。從朋友那裡取得的建議是種快速而不昂貴的方式,其後也可以解決許多困難。前導性測試有助於確保此研究經過良好的設計比較容易成功。


以上完整可以參考 互動設計(二版) - aNobii Ch11 評估架構。From: Preece, J., Rogers, Y., Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, New York: Wiley

Thursday, January 20, 2011

Learning Flyweight pattern by using MKAnnotationView

在 iPhone app 上面如果我們要使用地圖,在地圖上面希望插著紅色針頭,針頭要很可愛的從上方往下掉下來的效果之外,也希望可以按下它之後彈出一個浮出視窗,小浮出視窗希望可以稍微客製化,顯示自己要呈現的訊息等等,而且因為希望插滿各種不同座標的針頭,且要可以一口氣顯示在畫面上,這樣子我們做的到嗎?這需求很合理阿,例如如果今天是開發一個導航系統、同學住家通訊錄搭配地圖顯示等等都會有這樣需求。我們來解析一下這該如何辦到,另外從中學習 Flyweight pattern。

如果我們使用預設的 MKMapView ,並且使用 addAnnotations 將座標物件們當作陣列這樣加進來,會發現僅能做到基本預設的紅色針頭,上面顯現 title 和 sub title,而且它不會有從空飛下的效果,也沒有圖片或者右邊 Disclosure 的按鈕做進一步瀏覽,如此一來還無法滿足上面一段的故事。

在 MKMapViewDelegate Protocol 裡面有一個 optional 的 method 是 mapView:viewForAnnotation: 它可以回傳一個特定的 specified annotation object。文件上說傳入 map view ( 它 request annotation view 的) 和傳入物件 annotation (該次要來顯示的,而且這邊可以來客製化),且最後這個 method 會回傳 MKAnnotationView 加工過的針頭。

另外注意到開發文件上很貼心的說到,與其每次呼叫都建立一個新的 View,我們應該使用 dequeueReusableAnnotationViewWithIdentifier: 來辨識這個是否已經建立了。如果已經建立過一個,只要更新資料舊好就可以把客製化的 annotation 回傳回去。如果這個類別不存在,我們再建立它,客製化成我們要,再回傳。另外也可以從這邊辨別傳進來的座標是不是 user 當前座標,如果是可以另外設定成跟地圖上其他針頭做區別。如果不想客製化,只回傳 nil,那麼就還是基本款而已。

看到以上這段說明,我們看到了 Flyweight pattern 蹤影了。
Flyweight pattern 定義:Use sharing to support large numbers of fine-grained objects efficiently.

Flyweight 是要用來分享物件可以被大量重複使用的,僅是物件外殼重複使用,但是內容還是可以依賴於各個內容值。Flyweight 不知道內容且誰來使用它,僅負責該內部做的事情,如果該物件不存在就建立出來分享,如果存在就直接共享。

Friday, January 14, 2011

Improving the design of existing code

Designers 設計師常常把 Refactor 用在錯意,跟它本身的含意有差距。在 37signals 有一篇介紹 "Refactoring for designers" 這樣心得感想。設計師可能一再聽到程式設計師講這詞彙,但是沒有真正瞭解它的意思。所以這篇文章即是在解釋這詞彙的好處與含意讓設計師可以了解。

設計師怎麼樣誤解呢?他們會想成『重新安排新設計』、『小調整而沒有完整大思考』等等模式。Refactoring 實際上是別的意思,它意思是改變設計的方式,而卻不改變它外面看到的部份。在簡單說即是,今天做完了 Refactor,使用者是不知道的,但是對於設計面而言,將後面做的更有彈性、更乾淨清楚,讓未來加上新功能可以更加的順利等等目的。

程式設計方面有這本書叫做 Refactoring,Improving the Design of Existing Code。這本書裡面除了解釋什麼是 Refactoring 意義之外,包含了兩個最重要概念以及些程式設計上的技巧與試用時機。

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

第一個概念是想要做 Refactoring 之前,先寫好單元測試。單元測試通常是測試程式一對一方式來測試我們寫的每一個單一獨立的主程式,此目的是確保今天寫的程式是對的、自己瞭解要開發哪些功能,與開發前過程中可以對功能範圍一定程度上的瞭解。如果程式是盾,那麼測試程式就是矛,由矛來攻擊盾,確保盾 (程式) 是穩固的。好,單元測試寫完可以當作程式的資產,它可以搭配自動化測試 Auto-testing 來輔助瞭解自己開發上是否有在正軌上。而這麼大的資產用在 Refactoring 上,可以做到如果程式的翻動,是否可以撐的住矛的攻擊,因為功能不變照道理說測試程式是可以繼續跑的。而在將程式碼翻修整理、拆解 Class、合併 Method 等等技巧的一路上,都能確保程式依然是穩定的。我們當然不希望改東邊壞西邊、改西邊壞南邊的狀況發生,而測試程式即是這時候的幫助,也是程式開發人員平日要投資的。

第二個概念是兩頂帽子,當決定要 Refactoring 導入開發時候,要把時間切分成兩部份,而且一次只能戴一頂。第一個部份是加上新功能新程式碼,第二個部份是 Refactoring,為既有的功能做結構改造 Restructure。採用這樣習慣,如此一來才能確保自己的程式碼可以穩定的前進,開發上開發人員自己也不會一團亂,穩健的前進同時隨時都可以交付出穩健的程式版本。

Refactoring 是一個很好的設計工具,他可以幫忙協助我們的程式碼將內部行為改造,讓未來可以更好維護與增進。以上如果是介面設計師想要瞭解更多可以參考 37signals 部落格文章 Refactoring for designers Ryan Jan 12,或者是程式設計師我推薦 Refactoring - Improving the Design of Existing Code 這本書。

Thursday, January 13, 2011

Using UIActionSheet design to alert users

我們在 iPhone 上使用 Facebook app,當點選到自己朋友的個人頁面,如果想要跟他做更進一步事情,我們知道說右上角有個按鈕可以選擇,按下它之後,畫面下方即會出現一排選單讓使用者可以做進一步的選擇,例如:傳送訊息、poke 一下。

另外一個經驗,例如今天
搭乘大眾交通工具路上編寫很長的一段文字,手指頭辛辛苦苦打到一半,如果不小心按到取消,而系統沒設計好就真的回到上一層,資料也消失了,這樣是不是很想摔手機,但是也只能氣到內傷。所以有些設計良好介面的 iPhone app 會彈出詢問,是否真的要取消的選單。這樣重要設計方式在 iPhone 上是如何做出來呢?

UIAcitonSheet 是一個可以提供系列的選單給使用者做選擇的 class。我們也可以使用 action sheets 來彈出提醒使用者些潛在風險的狀況。Action sheet 提供了標題選單和一到多的按鈕,每一個按鈕都有不同的 action 可以接收。

使用這個 class 可以設定它的 properties 調整 action sheet 的訊息、style 和按鈕等等。在使用這個同時,也要記得指派 delegate 到我們的 action sheet。這個 delegate object 會負責提供 action 對應到當被按下去相關的按鈕要處理的行為,確定給 UIActionSheetDelegate 這個 protocol。

我們可以從 toolbar 來帶出這效果、tab bar、或者按鈕按下去時候等等時機點。以 iPhone 和 iPod touch devices 來說, Action sheet 會典型地從底下往上滑出,然後呈現在畫面的最上層顯示,並且讓背景變成深色,讓使用者做選擇。我們來看看怎麼寫。

我拿先前介紹文章過 PushPop 展示 Navigation 的 project 來加上此功能的介紹。這次主要在最後一頁的上方 tab bar 加上按鈕,按下去可以做出 Action sheet 效果,而且將這版用版本控管機制 commit 且 push 到 github 上,我們可以從 程式碼差異頁面 來做分析,學習只要改什麼 code 即可達到目的。

Sunday, January 9, 2011

Using Singleton Pattern in Objective-C

Singleton 是一個 Class 設計為確保只有單一 instance,然後提供讓整個 application 都可以 access 進來存取。Singleton pattern 有多個設計好處:

  • Controlled access to sole instance - 因為 Singleton class 封裝了單一 instance,他可以限制控制 client (呼叫者) 如何和怎麼存取。
  • Reduced name space - 對於全域變數而言,Singleton 可以提升強化。將命名部份統一在單一 Instance。
  • Permits refinement of operations and representation - 在 Run-time 時候可以透過這 instance 來控制設定 application。
程式規劃為:

  • 建立 Public class
  • 建立 private static 的 instance
  • 建立 Method 讓外部可以呼叫使用
  • 檢查目前 Instance,如果不存在回傳一份新的,如果已經存在回傳已經建立好的。

Saturday, January 8, 2011

HutchWorld 個案研究

HutchWorld 是一個分佈式的虛擬社會,由微軟的虛擬世界研發團隊及 Fred Hutchinson 癌症研究中心的圖書館人員、診所醫師共同研發而成。這套系統能讓癌症患者、病患照料者、他們的家庭及朋友彼此交談、訴說他們的故事、討論他們的經驗、對抗病魔的策略和以此得到情感上及實際上的支持。

對於這樣一套使用性高、效率高、容易使用及令使用者滿意其使用環境的系統,必須提供必要的隱私,並且讓參與者彼此間信任。對於這樣大型專案,一開始先由一連串非正式的研究開始。詢問小群使用者對於系統早期原型的建議,其後才會進行更正式的使用性研究及實地調查技巧使用。

團隊如何開始運作早期的設計想法
設計團隊必須研究病人在該中心的相關經驗。典型的醫療程序?有哪些資源已經有提供?不同使用者群有不同的需求?去瞭解他們的背景。團隊會閱讀最新的研究報告與專家和病患討論、參觀研究設備、系統網頁任何能調查的都不放過。

現在他們知道了這是一個值得開發的系統,但是要怎麼進行呢?他們藉由真實世界的隱喻,利用真實世界的知識運用到虛擬世界裡面。再來用哪種方式溝通,同步非同步?

當原型做出來後,在測試能夠開始前發現有兩個關鍵問題:一、誰能夠衛受測者提供訓練並且幫助病患?二、有多少系統需要進行測試。很快的團隊學習訂定較為真實的期望,藉由醫院活動同步,接受使用者可能使用不適應造成非預期的專案 Delay。

如何完成使用者測試?

測試一,團隊學觀察到使用者比較喜歡非同步的方式對話,因為社群較小,大家無法足夠量參與,造成對話無法立即反應,使用上失望。另外觀察到需要多硬性的功能整合,讓使用者可以溝通、資訊傳遞、娛樂間操作。經過這樣後團隊重新設計了軟體,做了再設計。

測試二,挑選使用者告知他們會使用這套軟體,用給病人家屬提供協助。每位受測者有五分鐘可以瀏覽此系統,彼此分開來進行測試,必須在瀏覽其間說出看到事務,他們想要得到什麼,卻看到什麼。口述過程都要被錄影設備紀錄下來。當五分鐘結束了,開始進行一連串安排的任務,用任務來測試使用介面的功能特色。研究其間,開發團隊成員會扮演參與者,讓參與者能夠有人互動。結束後也讓他們填寫問卷:你覺得本系統優點為何?缺點為何?有無碰到困難或是困惑之處?你有何改進之處?

此過程團隊蒐集了大量資料可以來分析,例如畫面上的文字使用造成使用者迷惑、哪些操作是可以哪些要列入改進空間的。團隊開始會列下 issues,區分為議題、重要優先程度、議題內容、改進建議。重要性一定要有高低之差,選擇高的優先解決。可以再早期開發階段找到關鍵問題,許多不同使用性問題也可以實際在開發程序進行中獲得解決。

是否再次測試?
這次讓多人同時操作測試,將所有使用者同一時間進行測試,以確定系統可以支援眾多使用者互動的情況。團隊觀察改進再修正。

停止特定任務的使用性測試,開始改由真正的癌症病人和照料者成為焦點團體 Focus group,對於該套系統最終版本提供意見。

當開始上線使用後,團隊未來會把研究計畫放在成效上面,考慮這系統對使用者影響?哪種方式最有利?哪種情形被使用?是否有其他系統也這樣提供社會協助?對於使用者如何才會樂於使用這項產品等等。

你我可能會好奇何時要停止使用者測試?系統已經完善了嘛?我們無法假設系統有完美的一天,從來沒有一套系統是完美的,一般的時間及預算會決定應該何時停止測試,所以 Joseph Dumas 和 Ginny Redish 兩位著名的使用性顧問提出,若要讓反覆性使用者測試成功進行,就要必須儘可能的花費較少的時間,如此可以取得有用資料同時,也不會造成團隊運作上的困擾。

以上完整可以參考 互動設計(二版) - aNobii Ch10 評估簡介,和網路上 HutchWorld: clinical study of computer-mediated social support for cancer patients and their caregivers 的 PDF 個案研究。

RSSFeedReader on github

如果講到 RSS Reader 你會想到什麼,一份一份自己非常有興趣的訂閱新聞來源,然後有任何最新消息馬上抓取閱讀,且自己看過沒看過都清楚知道,尤其抓取部落格好文章是更棒事情。這方面出了很多很好的資訊軟體或是網站服務。好,我們把功能再縮小再縮小再縮小,就從一個初版的 RSS Reader 自己動手開始開發,之後再根據新功能一一加上去茁壯的方式起頭吧。

這是一個 iPhone app,一個 iPhone app 隨時瞭解最新 Edward in Action 的文章,並且簡單瀏覽。題目非常簡單,把功能範圍縮小到可以做好初版,之後能夠慢慢擴充。

所以首先準備部落格的 RSSFeed,用瀏覽器打開是 RSS style 的 XML,這是我們跟部落格要訂閱來源,抓這即可掌握最新資訊。那麼我們剩下的 iPhone app 就把焦點放在,抓取下來如何解析做出讓使用者操作順手的 App。

介面規劃打算做三層頁面。首頁用表格的形式來顯示由最新到稍候的文章標題排序,旁邊有時間資訊。當點選標題,可以導到第二頁做手機版界面詳細閱讀。如果第二頁就是本文有任何超連結,我們讓它可以導到第三頁開網頁版看原貌。

起頭規劃選擇用 Three20 open source 來加入我的 Framework,上 Three20.info 網站可以看到基本教學,如何引用到 iPhone project 到它可以呈現哪些強大功能,都有一一列出來,甚至下載 source code 去跑裡面的 Sample,可以看到功能展示,這邊就不再多描述,未來有機會再多介紹。

You are not your user

使用者想法跟我們想的不同。我們知道我們產品從裡到外,當我們在餐巾紙上話草稿開始,我們已經參與每個形式和週期性開發循環。我們的行為決定了產品每一塊蹤跡。然而很多使用者是第一次首次來到我們的產品上使用,大部份使用者在使用產品時候會在腦海中設下目標,期望這個產品可以完成他們的目標。有些人只是來逛逛而已,或者有些先前他們其他相關使用起來困惑和不如意等經驗。大家來的心情都不盡相同。

"Knowing how people will use something is essential."—Donald Norman

了解使用者是很重要不可或缺的,不是由個人主觀去分析,而是從客觀角度去瞭解使用者需要。這個過程也可以透露出設計上基本卻沒被發現的破綻,而且給與獨特見解,可以做出更有樂趣更符合使用者需要。有些研究方法技巧可以採用來更瞭解使用者和他們行為。這些方法在這篇文章有介紹,在互動設計書本也有提過。

使用者訪談:跟淺在的使用者對談,讓我們瞭解他們的喜好和反應。

情境調查:參與使用者使用的情境,去觀察他們工作情境與環境,發現他們想要解決的問題和他們相關的偏好。

問卷調查:透過明確系列問題來給廣泛的使用者來取得有幫助的資料。

Card sorting:透過使用者小組分配主題,大家討論分類,排程一列後訂出同類別,找出模式來。

Usability testing:一個程序性的測試產品,找出淺在使用上的問題,找出解決方案,在解決這些問題。

花些時間來瞭解使用者,就能降低做出不被喜愛的使用者經驗,而讓我們可以有機會做出好的成果。原文了解更多可參考 52 week of UX: You are not your user 以及本 Blog 相關 label:互動設計 文章。

Monday, January 3, 2011

Finding your way with Core Location

當使用 iPhone,其中一個強大功能是可以知道現在位置在哪裡。這是透過 Core Location Framework 使用來取得資訊。有三種方式可以計算出地理位置:

第一種、GPS,GPS 讀取來自多個衛星的微電波訊號來辨別現在位置。這是最精準的計算方式,但是在第一代 iPhone 沒有此功能。

第二種、Cell tower triangulation 透過多個電信塔台的位置來找出手機範圍在哪個位置。當 Cell tower 塔台分布密度高的都市裡面,計算位置就可以很精確,但是在遠離郊外地方,距離塔台相隔都遠,計算出來的值比較差了。

第三種、WPS 這是 iPhone 的 Wi-Fi 連線網路,透過 IP address 參考大型資料庫由知名 service providers 資訊來猜出當下的位置。WPS 是不精確而且可以計算出來誤差會差的非常遠。

不論使用哪一種方式使用,都相當耗費 iPhone 的電力,所以要記得使用 Core Location,當有必要要抓地理位置時候再啓動。而且使用 Core Location 可以給與抓取準確度的選項,這也要給與適當的準確層度,不然還是會耗電力。

抓取 Location 資訊採用的技術方式在 Core Location 是隱藏起來的,所以我們不是告知 Core Location 要使用 GPS, triangulation 或者 WPS。我們紙告知要抓的準確度要多少,而它會寄算出最適合的需求來截取地理資訊。

透過 Where Am I 這隻簡單的 iPhone application 我們可以抓出現在當下地理的資訊,我們透過關鍵的 WhereAmIViewController.m 來解析一下。

設定想要的準確度。記得使用越精準的地理位置會越耗電力,而 Core Location 提供了可以查詢最佳精準、最近 10 碼、100 碼、1 公里和 3 公里。我們將這個值設定給 Location Manager 的 desiredAccuracy。


設定當距離改變多少告知要 delegate 。而告知移動了多少碼時候要 delegeate 這個值設定在 Locaiton Manager 的 distanceFilter。

啓動和停用。當開始使用抓取資料透過 Location Manager 的 starUpdatingLocation,當不用地理座標時候,呼叫 Location Manager 的 stopUpdatingLocation。

當開始取得地理座標,會傳進來 locationManager 和上一個位置以及現在位置,如此一來我們可以做資料取得和一些距離計算等功能。當取得 CLLocation 資料後可以使用 NSLog 可以紀錄這樣內容:<+25.05209773, +121.53646565> +/- 79.00m (speed -1.00 mps / course -1.00) @ 1/9/11 5:56:19 PM Taipei Standard Time


當取不到地理位置或者使用者從彈出畫面按下拒絕提供地理資訊,會進入此 method。這邊即可程式上規劃要如何等等。


抓地理位置看起來技術上頗複雜,不過 Apple 提供了簡單的 Interface 介面來蓋住這些複雜度,讓要加上任何關於地理的功能在 applicaitons 上變簡單,可以告知使用者在哪里和辨識他們如何移動等等。

想瞭解更多可以參考
Beginning iPhone 3 Development 章節 Where Am I?,或者上 github 看 source code edwardinubuntu / WhereAmI