發佈日期:

Git版本控管學習筆記(1)

我過去一直都是使用SVN來做專案的版本控管的工作,
最近突然很頻繁的聽到圈內的人都用git這個東西,強調他分散式適合分散式開發等等的優點。
再加上最近有看到保哥的30天精通Git版本控管的教學文,
就決定好好的來學習一下這個新的版本控管系統。

在過去,較有名的檔案管理系統有SVNCVSVisual SourceSafeVSTS
不過,這些版本管理系統大都採用集中式控制,
也就是一定要連上Server才可以commit資料。

而Git則強調分散式管理,他可以在本機就先commit資料,當連到網路之後,才去與server上的系統做合併
這樣有一個很大的好處,就是即使今天人在國外,無法連上網路而需要繼續工作,
或公司的svn是使用區網去連接,但我們卻無法連接至公司網路時,
也可以commit程式的變更,這個特性在分散式的開發上十分的方便。

決定要學GIT後,第一個就是要選擇工具

CloudHsu推薦下面兩款:

  1. mac系統上使用SourceTree
  2. 在windows上使用gitextensions

上面這兩款都是圖形化GUI介面的操作軟體。

不過保哥在文章裡面有提到,最終在使用上,因為操作方便性以及使用方便性,還是會選擇使用GUI介面的操作工具。
但是,在剛開始學習時,由於對整個GIT概念的了解,他還是建議從下指令碼開始學習,以下是節錄他的學習建議:

* 先擁有 Git 基礎觀念,透過下指令的方式學習是最快的方式,不要跳過這一段
* 找多一點人跟你一起學 Git 版本控管,最好能直接用在實務的開發工作上
* 團隊中最好要有幾個先遣部隊,可以多學一點 Git 觀念,好分享給其他人,或有人卡關時,能適時提供協助
* 了解 Git 屬於「分散式版本控管」,每個人都有一份完整的儲存庫(Repository),所以必須經常合併檔案
* 使用 Git 的時候,分支與合併是常態,但只要有合併,就會有衝突,要學會如何解決衝突

因此我還是先裝Git for Windows,在保哥的系列文章的第二篇,有很詳細的解說
請看在Windows平台必裝的三套Git工具,一定要先裝Git for Windows才能裝GitHub for Windows
他一樣很大推SourceTree,這一套CloudHsu也說很好用!

首次使用如果有成功登入 GitHub 帳戶,GitHub for Windows 會自動建立一組 SSH Key-Pair

GitHub for Windows 幫你產生的 SSH Key 預設路徑如下:
"C:\Users\<username>\.ssh\github_rsa"
"C:\Users\<username>\.ssh\github_rsa.pub"

這樣以後可以不用每次登入GitHub都要輸入帳號密碼。

而預設的工作目錄則是在
C:\Users\<username>\Documents\GitHub

在登入github網站後,點選右上的Account settings,然後點選SSH Keys
可以看到現在連接到你gitHub帳號的電腦所使用的SSH key。

2013-11-11_180939
然後這是安裝好的GitHub for Windows介面的樣子
2013-11-11_183846

今天學的三個指令
<詳細教學文請見此>

  1. 建立本地儲存庫
    mkdir demo
    cd demo
    git init
  2. 建立本地共用儲存庫
    mkdir demo
    cd demo
    git init --bare
  3. 從遠端取出儲存庫
    (2) 先在此取得儲存庫的網址
    2013-11-11_182141
    (2) git clone [REPOSITORY_URI]

相關資料:

  1. 30天精通Git版本控管
  2. Git Magic
  3. Git教學
發佈日期:

iOS app security - 分析和防範

講者 :Hokila
mail:hokila.jan@splashtop.com
blog:josihokila.blogspot.com
FB:fb.me/hokilaj

這是10/17分享的第一個講者,在分享有關app的安全上攻防的相關議題
因為這是我第一次參加cocoahead聚會,誤信了google map而迷路,遲了半小時入場,因此有部份內容沒有聽完整>”<
幸好後來找到Hokila很好心的預錄了當天的內容,在投影片最後一頁的QR code裡(有列在參考資料裡)。

ps:報名網頁的地址『台北市大安區敦化南路一段205號6樓600室』,打入google map會出現在忠孝復興站@@
說到這,當天我到會場時,有另一個漂亮女生也遲到,我就和她打招呼,結果她問我:妳也是用google map嗎?
嗚哇~所以不只我一個人這樣阿!(握手

今天Hokila講的內容大致如下:

  1. iOS app 資料結構
    在一個APP裡面大概會有幾個資料夾
    2013-10-29_105710
    MyApp.app裡面會存放一些APP會用到的照片、XAB、貼圖(PVR)或素材PNG、JPG等檔案(裡面的值無法修改)。
    Documents是建議存放永久性資料的地方,我們可以在裡面創建、修改、刪除要永久存放的檔案,如DB工具、抓影片放裡面,好處是只要plist裡宣告可以file share的話,他會可以用iTune打開來。PS: 這個資料夾會被iCloud自動備份。
    Library則是較為複雜的資料夾裡面一般會有下面這些資料夾

    1. Application Support:也是放一些設定檔的地方,它不會不見
    2. Cache:不會備份,存放可以再次從網路上下載的資料(每隔一段時間會清掉,何時清也不確定)
    3. Cookie:存放webView的Cookie,要注意的是這個cookie和safari瀏覽器的並不一樣。
    4. Preferences:放使用者相關設定檔的地方(NSUserDefault)

    tmp這個地方,重要的東西千萬不要放在裡面,因為只要每一次NSTemporaryDirectory重新restart時都會清掉,一般講者都是放download到一半的檔案,下次app開啟時再繼續download。

  2. 這邊也有提到可以去觀察對方的plist檔案來看他們的設定(如url schemes、document types )
  3. Console log:可以到此下載(http://support.apple.com/kb/DL1465)這個軟體。
    剛剛隨意的載下來玩了一下,這邊有使用說明(請按此
    感覺蠻好玩的,可以用它來看到app沒有埋好的log、framework⾃自⼰己帶的log、system notification、memory warming
    螢幕快照 2013-10-29 下午9.16.41
    因此,在用framework時或是寫code時,要注意是不是有丟出什麼log訊息。
    或是播影片時,把影片暫停、改全螢幕等等,有些會吐一些log出來,所以有時如果不知道別人怎麼做的,可以去觀察那個APP的log紀錄,把關鍵字丟到google查,或許可以查到一些端倪。
    另外在這邊也可以看到memory leak,不過只能知道有沒有memory leak的狀況,而無法知道是為什麼造成的。
  4. 接下來是資料儲存的部份,很多時候,我們會將資料儲存在Library>Preferences,但若我們打開資料夾,會可以看到plist檔,並且key和value值都是明碼,這是非常危險的。(例如fb會在裡面有使用者的資料)
    螢幕快照 2013-10-30 上午12.50.31
  5. 把資料放到keychain裡面,某app存的資料,另一個app也可以拿出來,並且有經過加密。(不過講者說可用keychain_dump解出裡面的table來)
  6. 另外可以使用charles來觀察網路狀況,這個工具我在開發flash也時常用到,非常好用。個人推薦map local和一個可以控制流量的功能
    螢幕快照 2013-10-30 上午12.55.33 用本機檔案去替代伺服器上的檔案
    螢幕快照 2013-10-30 上午12.55.51 控制下載流量
    那要如何讓CHARLES可以偵測到IOS上APP的HTTP request呢?
    首先我們要設定proxy,然後在iphone上設定代理伺服器
    2013-10-30_1114272013-10-30_111443
    在這邊講者也列出了其他類似的工具:
    ZAP (Mac Windows) Free:一個open source的工具
    Fiddler (Windows) Free
    Wire Shark (Mac Windows) Free:比較老牌的,講者覺得有點難用
  7. 因此我們在分析一個APP的時候,至少要分析下面幾個項目
    ● device screen
    ● console log
    ● plist、db裡面的狀況,一般會放在document裡面
    ● API request/response(送什麼出去、送什麼回來)
  8. 接下來是這次的講者們都很推薦的class-dump(在此下載)
    這個東西可以dump app的class,看看裡面宣告了什麼東西。
    但首先機子要先jb才可以連進去,用遠端登入的方式連進手機的位置
    螢幕快照 2013-10-30 上午1.16.42
    在手機上將專案抓下來
    螢幕快照 2013-10-30 上午1.18.41
    把它解壓縮
    螢幕快照 2013-10-30 上午1.20.07
    拿取版本,把它copy到
    螢幕快照 2013-10-30 上午1.22.40
    接下來就把app的資料拿出來看
    螢幕快照 2013-10-30 上午1.24.15
    便可以看到一些.h的檔案
    螢幕快照 2013-10-30 上午1.27.24
    如上圖,這時後大多的app都會有保護而導致dump失敗,這時候可以去一些ipa破解網站去下載app,通常從那些地方下載的都是已被破解,沒有保護的。否則就得自己去修改iap。
  9. IAP Free和LocalAppStore
    iGameGardin/八門神器=>搜尋記憶體位置,把該資料鎖定住,像是可以鎖值,像是血量什麼都不會變。
    FLEX:最可怕的一項功能,鎖定function回傳值,例如說-(BOOL)isTransactionSucess 一定回傳YES
  10. 在這邊講者提供了十項資安要注意的議題
    螢幕快照 2013-10-30 上午1.33.32
  11. 應對方法:
    • model的值和view的值不要一樣
    • 當model和server互相傳值時,不要太過相信彼此傳來的值,應還是要再做驗證
    • 加密的話,不要用hash

    範例:首先,不要使用get,如GET http://xxx.yyy/getUserData.php改成POST http://xxx.yyy/public
    讓所有的api有一個共通接口,然後用(string)call_file_name來判別要呼叫那個api,用(string)token來認證使用者的身份(此token會在幾分鐘後失效),然後設定數字編號來代表不同的status
    接下來就是使用ssl來傳遞資料,這樣就會有加密了
    或這樣還不放心,可以把傳的值的結構改成struct

  12. 在買東西時做double check。例:買東西時把剩的錢和數量回傳,用的時候可再確認是否有該產品,較好的時機點是在使用者有做任何互動時,再去檢查資料是否正確,而不要每隔幾分鐘就去檢查一次。
    存回db時做hash(不要直接把值原封不動存進去,因為很容易被搜尋修改)
  13. 加密方式選擇:md5、sha1已被破解
    AES-128和AES-256是最潮的(他加解密是同一個key),現在還無法被破解。
  14. public data可以不用加密,像折價券之類。但是private data一定要加密,例如密碼、交易記錄,就非常需要加密
  15. 不要只顧app端而已,要想到更多有關於server的東西,這樣才不會漏洞百出,更重要的是兩者的交互過程也要去思考,這樣整體的設計才會更完美。

參考資料:

  1. IAP攻防戰
  2. IAP攻防戰影片
  3. iOS app security
  4. 當天的影片
發佈日期:

Marty Cagan談產品系列影片心得

影片連結在此:  http://v.youku.com/v_show/id_XMzAyNTg0MDEy.html

Marty Cagan是eBey前副總裁,本篇文章截錄部份影片重點,若有興趣者請直接看原始影片喔!
(PS: 右邊有集數可以選擇)

產品的兩周理論

Marty Cagan認為一個產品負責人和設計者,應該在兩周之內,給使用者一個創意原型
但大多數的產品經理不會喜歡這樣做,
原因很簡單,因為他們總是認為此時提出的原型會不夠完善、有缺陷,
會希望將產品做到位之後再公開他們的產品。

但是Marty Cagan提到,只有將產品的設計公開出來給使用者看,才能夠做到心裡有數,
很多設計者或產品負責人很容易愛上自己的產品,
但愛情是盲目的,這很容易讓設計者忽略實際情況和使用者的反饋。

因此他認為應該在兩周之內提出一個產品原型,
他推薦使用high fidelity prototypes、user prototypes、live-data prototypes,
若時間來不及,也可以單就提出產品的設計圖如Balsamiq Mockups之類的,
很多時候,這樣才能夠最快檢驗出產品是否易於被接受。
即使此時的原形與最後產品產出可能會有極大的差異,但是及早搜集使用者意見,對產品的設計與開發是最安全的

克服心理障礙,將產品原型盡早提出給使用者看,
是產品團隊的一項重要技能。

什麼是基本產品

基本產品是所有軟體的基本核心概念,一個基本產品應要滿足下列條件:

  1. 客戶會願意購買該產品:最重要,也最難達成
  2. 使用者能夠很簡單的了解該怎麼使用,而不會一直要去理解”怎麼用”
  3. 有能力把產品開發出來

也就是說,一個基本產品應該要滿足:有價值、可用、可行的基本條件
但是要確定自己的產品是一個基本產品,則需要用prototypes和user testing來做測試。
我們可以用各種不同的原型模式(例如prototypes、live data prototypes、使用者面對面測試、以及sprint testing)去交叉比對、檢驗自己的產品是否符合上面的三項條件。

基本產品和最小化產品是有差異的,一般來說最小化產品指的是只具備基本功能的產品,
缺少可用性及外觀設計。
要記得客戶是不會花錢去購買半成品的,他們可能會試用,但不會購買。

產品探索團隊

這樣的團隊有三個重要角色

  1. 產品經理:定義產品功能
  2. 介面設計師:負責產品的易用性
  3. 程式設計師:最終決定這個構想是否可被實現

上面這三個角色應要一起合作、去定義一個基本產品:一款客戶願意購買、並能明白怎麼使用、也做的出來的產品

尤其是產品經理與介面設計師應該要密切的合作,一般我們會認為一個產品的計畫是由產品經理以及介面設計師一起共同構思。但有一個大秘密是:通常好點子都是程式設計師提出來的。因為程式設計師更了解怎樣的點子是可行的,他可以做到怎樣的功能。因此,雖然這些角色的功能不同,但每一項工作大家都必需參與,共同打造出基本產品。

也建議這三個角色在辦公室的設計上應該要放在一起,即使有職等上的不同,產品經理及介面設計師還是應該要讓他們能夠坐在附近以方便溝通。

用戶測試的類型

用戶測試是產品經理最重要的工作。

用戶測試分為兩部份:

  1. 使用者是否知道如何使用產品(可用性測試):做這個測試時,產品經理、程式設計師、介面設計師都應該在場。這個測試簡單、效果明顯,可以很快了解問題所在。
  2. 若用戶知道怎麼使用產品,那用戶願不願意使用產品,如果不願意,怎樣才能說服他們購買產品(價值測試):一般人會問你是否會願意購買此產品,但因為禮貌上,大部份的人都不會回答真實的想法。
    因此,Marty Cagan通常會問受測者:【你是否願意把這個產品推薦給同事?】,並用0~10的分數去代表非常不願意=>非常願意。除非他們給9~10分,否則都應該只是出於禮貌的敷衍你。在了解為什麼使用者不願意購買產品之前,不能停止用戶測試。
    在做價值測試時,當他們回答的結論是NO時,我們可能會發現這是因為受測者不是我們的目標客戶,還有其他人會需要。
    或者產品解決的問題不是他們需要的,這時就要改進產品,讓這個產品真正的可以解決使用者的問題,這會讓產品更有價值,通常這是解決方案出錯了,需要其他方式去解決問題。
    或者是營利模式錯誤。多留意這些關鍵點,他們往往是成功的關鍵。

測試方式的類型

  1. 使用者原型測試:快速製作prototypes,這個prototypes不能正常使用、也不能顯示正確數據,但只需要一兩天便可出爐。這可以快速的表達產品的想法給使用者並且觀察他們的反應,快速找到價值所在。這個工作由設計師就可以勝任,不需要程式人員。僅管是主觀的測試但效果明顯。
  2. 真實數據原型測試:可以得到真實的數據,會花到大把時間由程式人員撰寫,但是有些地方用戶原型測試是測不出的,因此這個步驟還是必需的。通常會同時採用對比測試,監控使用者瀏覽原型網站和舊有網站的流量,分為兩份數據,去做對比比對。

上述的兩種測試模型可以交叉使用,目的在花小錢辦大事,以避免製作出一個沒人想使用的產品。通常要做出一個完整的產品,會需要真實數據原型測試。但是想要快速的了解使用者感受或想法,使用者原型測試是最快速有效的。

定義產品經理

首先要了解,產品推廣並不是產品經理。定義市場需求、分析商業案例、搜集客戶需求是產品推廣的工作,很多人會認為直接把客戶需求丟給程式設計師開發就是產品經理,但其實這也不是。產品經理應要定義待開發任務,並定義任務優先權,然後開發團隊來完成這個任務。產品探索,就是要定義出基本產品。要做出好產品要有三個條件:

  1. 熟悉技術:只有了解技術、快速學習新技術,才能和技術團隊有良好的溝通。
  2. 熟悉UX(使用者介面設計):UX是好產品的必要條件
  3. 熟悉用戶和客戶:要做到這點,必需花大量的時間與使用者溝通及面對面的交流。
  4. 熟悉行業和市場

做到以上幾點,一個產品經理才有可能規劃出一個好的產品。

發佈日期:

XSpect簡介(一個AOP觀念實作的框架)

講者資料:小
投影片:XSpect
專案github位置:在此

這是10/17在cocoaHead聚會裡由講者所分享的一個他自己所寫的framework
因為他是在今日議程的最後一個講者,有些部份講的較為快速、簡短
有很多投影片也跳過去未說,在當下聽時只能大略聽到一個概念。

較引起我注意的地方,是他所提到的AOP的觀念與應用
也因為對他所說的AOP的觀念以及相關應對、程式設計方式感到蠻有趣的
這部份在會議結束後也花蠻多時間在研究該講者的code以及相關概念的研究

這是講者對AOP的解釋:

如果我要敘述 AOP 在幹嘛,或是說他的目的的話。我會說 AOP 是在用另一種方式去封裝變化,達到原本 OOP 做不到的事。這個變化就是 crosscutting concerns。
crosscutting concerns 就是為了一個邏輯,而散布在四處的程式碼。
AOP 就是要把他們全部包裝在一起。

下面的是其他網頁對於AOP的解釋

AOP全名Aspect-Oriented Programming,我們先來看看XXX-Oriented的意義,通常翻譯「XXX導向」,也就是以XXX為中心,例如中文中「客戶導向」就是以客 戶為中心,而「物件導向」(OOP:Object-Oriented Programming)就是以物件為中心的程式設計。

自然的,Aspect-Oriented Programming,就是「Aspect導向程式設計」,也就是以Aspect為中心的程式設計,但什麼是Aspect?中文直譯通常是「方面」,但這個名詞容易使人混淆。

牛津字典中的英英解釋對Aspect是:particular part or feature of sth being considerd.

所以Aspect在英文中不只有「方面」的意思,還有部份(part)的意思。中文中稱「就這個方面來說」,通常指的是「就這個角度來說」或 「就這個方向來說」,這個解釋不適用於AOP中的Aspect。如果英文中說from this aspect of sth,除了可以翻譯為上面兩句的意義之外,還可以翻作「就這個部份來說」。

以我們的前一個主題中的記錄(log)動作插入至HelloSpeaker物件的hello()中為例,我們說「就記錄這個部份」是不屬於 HelloSpeaker職責的,它被硬生生切入HelloSpeaker中,英文中我們可以說:The logging aspect of the “hello” method doesn’t belong to the job of HelloSpeaker.

所以以整個方法的執行流程來說,如果執行流程是縱向的,則記錄這個動作硬生生的「橫切」入其中,這個橫切入的部份我們就稱之為Aspect,它 是橫切關注點(crosscutting concern,一個concern可以像是權限檢查、事務等等)的模組化,將那些散落在物件中各處的程式碼聚集起來。

所以Aspect要用中文表達的話,適切一些的名詞該是「橫切面」或「切面」。AOP關注於Aspect,將這些Aspect視作中心進行設 計,使其中從職責被混淆的物件中分離出來,除了使原物件的職責更清楚之外,被分離出來的Aspect也可以設計的通用化,可運用於不同的場合。

然後這個是XSpect框架的架構圖
2013-10-28_135639

簡單來說,使用AOP的框架主要是為了把 crosscutting concerns 封裝在一起,提高程式模組化的程度。
以上圖來看,左邊的部份是原本的程式寫法,假如是一個儲存資料的函數如下,以原本的寫法來看,或許檢查值是否符合格式這部份的程式碼,在許多地方都可以用到,AOP主要便是去關心多個相似的流程的衡切面裡共通的部份,橫著去”跨越”多個程序裡使用的相同的功能。

log是一個標準的crosscutting concern範例,因為log的策略會牽動整個系統的每一個必需記錄的部份。
從橫向去記錄和登記所有classes和methods。

假如今天我們一個送交表單的程式碼,長的像是這樣:

function saveForm(){
...檢查欄位是否為空。
...檢查輸入的值是否符合格式。
[真正的儲存工作]
...後續相關操作(存LOG、紀錄操作等...)
...顯示儲存結果

}

我們可以看到,在這個函數裡面,只有[真正的儲存工作]是函數真正要做的事情,
剩的部份都是要處理商業需求的商業邏輯而寫的功能。這樣的程式碼撰寫方式,會造成寫出的程式只能專門用在單一工作,降低程式碼的重用性以及可維護性。

例如我們今天在程式的多個地方都需要使用LOG來紀錄所有的商務操作,
若今天這一項業務邏輯需要做修改或是移除,
那麼整個專案裡有加入這個LOG功能的部份,都需要同時去更新,這將會增加整個維護的成本。

因此,這個AOP的框架就是為了要將這些和業務相關的程式碼與原本的程式碼分開,
(商務邏輯,稱為Aspect,具體實作這些商務邏輯的程式碼則稱為Advice)
利用程式切入點Joinpoint(在應用程式執行時加入商務流程的點或時機稱之為Joinpoint),
並設定那些Aspect要用在那些Joinpoint裡,這個設定的定義稱為PointCut。

這邊的文章有AOP相關專有名詞的解釋:AOP觀念與術語,下圖則是講者大大的相關說明圖
2013-10-28_143641

這個框架可以讓商業邏輯獨立出物件之外,只需要設定Joinpoint便可以將之插入程式邏輯中。
如果對這個講者個框架有興趣的話,可至他的GITHUB上有更完整的使用手冊及範例: XSpect Tutorial

PS: 在當場講解時,有在場的大大提供了另一個很完整、並且功能與這一套框架相似的框架
叫作ReactiveCocoa,若對AOP有興趣者,也可以到這個網站去看看另一種方式的實作
https://github.com/ReactiveCocoa/ReactiveCocoa

 

相關資料

  1. XSpect, a lightweight library to make your code reusable and maintainable
  2. XSpect Tutorial
  3. AOP入門
  4. AOP觀念與術語
發佈日期:

AIR記憶體監控工具 – Scout

記憶體監控相關工具

Scout是一款針對用以監控記憶體狀態的程式,它不但可以監控電腦上面的swf的記憶體狀況,也可以監看使用air開發,運行在手機上的app的記憶體和gpu使用狀況。
在Scout之前,了解swf的記憶體使用狀況有幾個方式

  1. 內建的Profile功能
    2013-10-11_161104
    Profile可以監控現有的FLASH裡每一個CLASS占的記憶體比例,預設的設定會忽略AS內建的類別。如果要打開的話,可以選擇選單列裡的Window=>Preferences=>Flash Builder=>Profiler=>Exclusion Filter或是Inclusion Filters去排除或增加要觀察的class種類。
    這個工具若是用按2013-10-11_171747的方式執行,則只能針對FLEX本身的專案來做觀察。如果專案架構是外部的SWF檔案,則可以先切換到Profile工作模式(如圖:2013-10-11_171854),然後選擇上方選單列的Profile=>Profile External Application=>New,去選擇要觀察的SWF檔案。
    有關這個工具的介紹請見: Flex記憶體監控程式-Profile
  2. windows的工作管理員
    監控執行緒的執行狀況,缺點是無法仔細的了解是那一個Class造成memory leak。
  3. Hi-ReS-Stats  (https://github.com/mrdoob/Hi-ReS-Stats)
    很常被見到的一個外掛程式碼,可以簡單的使用

    addChild( new Stats() );

    來觀察FPS的運行速度、記憶體的使用狀況是否正常。嵌入後會在畫面上多出如下圖這樣的資訊欄位
    hires_stats

  4. Scout  (http://gaming.adobe.com/technologies/scout/)
    最後就是今天要介紹的Adobe Scout工具,Adobe開發這個,主要是為了當開發者在使用Adobe AIR開發手機APP時,能夠更精準的掌握SWF運行的狀況以及GPU的狀況。因此Adobe官方便提供了這一項免費工具,讓APP開發者可以更仔細的監控效能的狀況。

Scout的優點

上面介紹了這麼多的工具,那麼Scout的優勢為何呢?

  1. 仔細(Details)
    Scout可以提供詳細、階層性的資訊,讓開發者一目了然自己的程式的GPU資訊及記憶體使用狀況。
    除了Profile的記憶體監控功能外,Scout還可以提供GPU運算的相關數字及報表。
    在上面所列的其他三項工具,只有Hi-ReS-Stats有顯示FPS,可以讓開發者了解FPS速度是否正常,可觀察何時影格速度會變慢,並檢查是否有什麼動畫讓畫面停住了。其餘的都只能單純的監控程式使用的記憶體狀況,而無法了解到動畫處理的記憶體使用狀況。
    在flash裡,動畫的運算、圖形處理等,在很多時候其實是造成畫面Lag的主要元兇,因此,或許很多時後我們會發現動畫不知為何播放速度變慢了,但是觀察Profile,記憶體的使用狀況卻很正常,這時很可能便是GPU Memory不足。
    有關要如何做才能提高動畫的效能,相關議題可以參考下面這篇文章:
    http://claire-chang.com/1063-提升Flash效能的幾個注意事項
  2. 可擴展性(Extensible)
    Adobe有提供相關的API,當原本Scout提供的資訊無法滿足需求時,開發者可以在ActionScript裡面寫程式,去自行丟出想觀察的額外資訊,並且只要幾行程式碼就可以做到。(請參見Telemetry類別)
  3. 跨平台(Cross-platform)
    可在Mac及Windows上運行,並能讓開發者開發Andriod及iOS APP時更容易觀察其效能狀況。
  4. 輕量化(Lightweight)
    Scout只有12MB,很輕並且運行的很快,並且可以運行於一般的Flash Player,不用使用Debug版本也可以。

 開始使用Scout

  1.  開啟SWFs的telemetry功能:將Enable detailed telemetry選項勾起來
    2013-10-11_181303
    PS: 此時大家可能會發現,咦~不對呀!我的Flex專案怎麼沒這個選項?
    是的,這個功能只有在AIR專案上才會有,非AIR專案是沒有這個選項的。
    所以,那一般Flash檔案要如何使用Scout呢?
    這時後就需要透過工具去開啟swf的Telemetry功能,詳細方法請見下面的文章:
    Enable Advanced Telemetry on Flex or old SWFs with SWF Scout Enabler
    簡單來說,便是下載SWF Scout Enabler,然後選取要觀察的SWF檔案,把它的Telemetry打開。
  2. 執行Scout,要觀察一個swf,可觀察遠端或在本機的檔案。是用Scout去監控運作在其他台電腦或是手機上的APP上的資訊會需要較多的設定。
    要執行Scout的電腦需要有

    • Flash Player 11.4 (plugin or standalone) or Adobe AIR 3.4.
    • The Adobe Scout desktop application.

    [觀察目標]
    (一) 本機檔案
    只要將Scout打開,就可以看到現在在電腦中正在運行的SWF檔案的相關資訊了。
    (二) 其他台電腦上檔案
    如果要去觀察在其他台電腦上運作的SWF檔案的效能狀況,可以經由.telemetry.cfg檔案的設定去做到(但需要同網域)。
    檔案位置如下:

    • MacOS: ~/.telemetry.cfg
    • Windows: %HOMEDRIVE%%HOMEPATH%\.telemetry.cfg

    在修改之後,.telemetry.cfg可能會長的像這樣
    TelemetryAddress=192.168.1.20:7934
    SamplerEnabled = true
    CPUCapture = true
    DisplayObjectCapture = false
    Stage3DCapture = false
    (三) 手機或移動裝置上的APP

    1. 確定手機與執行Scout的電腦在弄一個WIFI網路下
    2. 手機下載Adobe Scout檔案(iPhone在此下載Android在此下載)
    3. 打開手機上的Scout應用程式,這時他會搜尋同WIFI下的電腦,選擇我們執行Scout的電腦,然後按連線
    4. 到電腦裡選擇自己想看到的數據資料
    5. 運行有開啟Telemetry的手機APP應用程式
      adobe-scout-getting-started-fig04

    先介紹到這邊,下一篇會再介紹該如何去使用或設定Scout的相關功能。

參考資料:

  1. Getting started with Adobe Scout
  2. Enable Advanced Telemetry on Flex or old SWFs with SWF Scout Enabler
  3. Telemetry – AS3
  4. Adobe Scout
發佈日期:

iOS 7 轉換指南

參考資料:   iOS 7 UI Transition Guide關於iOS7,設計師需要瞭解的十件事
PDF檔下載:  TransitionGuide

IOS7的設計要點

  1. 依從:UI應要能很幫助使用者了解如何去操作、與內容互動,但不能搶走內容的鋒頭。它著重強調了怎樣使設計更好地支持內容,而不是反過來壓制內容。
  2. 清楚:字體在各種大小下都應清晰易讀,並應巧妙的利用圖示及裝飾,去突顯重點。
  3. 深度:巧妙運用手勢及視覺階層以利使用者了解、快速操作。

可以看看蘋果是怎樣在iOS7內置的日曆應用當中貫徹這一點的。新的日曆應用在界面上極大的簡化了,去除了一切不必要的設計元素,並使用了乾乾淨淨的白色背景,完全以內容為中心。
4196_130812093347_1

根據「依從」原則,apple建議開發者不要使用擬真。介面的設計應該是圍繞著內容而存在,不應奪走內容的光芒。因此,官方建議盡量避免使用3D質感的按鈕、漸變、光暈、陰影等擬物化的設計,因為他們認為這樣的設計會奪去使用者對內容的焦點。但雖然圖示要輕量化,最小點擊區域44px的規則依然不變,因為用戶不能點擊小於44px的界面元素。
關於移除擬物化風格的設計方式,可以參考iOS7內置的Game Center、日曆和Podcast應用。
4196_130812093503_1
另外,關於深度,iOS7最吸引人的設計之一就是系統界面當中由加速計驅動的3D效果。隨著設備在物理空間當中的移動,圖標與背景圖片會展示出視差效應。這是iOS7三大設計主題當中的第三點的典型示例:

深度:視覺外觀的層次以及逼真的動畫效果可以傳達出界面的活力,使界面更容易被理解,並提升用戶的愉悅度。
自然,蘋果也希望應用設計師們採用相同的方式,通過半透明及動畫效果來展示界面和元素之間的層級關係。這是應用設計理念的一次重大飛躍,而且隨著iOS7的發布和普及,這些效果很快就會成為用戶期望當中的一部分。
4196_130812093514_1
在iOS7設計規範當中,蘋果建議,在iOS7框架下重新設計應用的最佳方式,就是剝離你已有的界面,將應用的核心功能呈現出來,重新確認它們之間的相關性。
一旦你確認好功能方面的核心要素,就需要通過iOS7的設計主題將界面和交互模式重新構建起來。舉個簡單的例子,蘋果的指南針應用採用了最小化和功能優先的設計方式,通過重新設計過的、更注重細節的形式來展示關鍵信息。
4196_130812093524_1
iOS7的應用界面通過大量的呼吸空間來確保可讀性和易用性。在官方的設計規範中,蘋果明確指出,他們希望設計師們通過留白傳達出平靜和穩定的感覺,使應用看上去更加專注和高效。

檢視現在的APP

在升級APP至iOS7之前,先檢查幾個項目:

  1. 是否有開啟AutoLayout功能
    因為IOS7裡的文字大小可讓使用者任意調整,所以IOS7是一個好時機去開啟使用AutoLayout,因為這可以幫助開發者自動去調整物件的相對位置。也可以更容易的讓APP同時可支援IOS6及IOS7
  2. 是否也要支援IOS6?
    使用者往往喜歡很快的更新到最新版本。若是因為其他商業因素需要同時支援IOS6及IOS7,則需要做更多的調校
  3. 分辨自己的API是屬於那一種類型
    (1) 完全使用內建的UI介面:確認新的視覺效果是否是自己想要呈現給使用者的,並確定一些手勢等操作可正確運作
    (2) 完全使用自己的UI介面:檢查原有的設計是否可以滿足ios7的使用者要求,如果可以,那便可只改很少的東西。如果不行,則需要整個重新去思考、調整,來適應現有的架構。
    (3) 混合使用:是否需要做大改變取決於過去自定義元素是如何與原有元素結合,應確保功能及外表皆良好,並可與新的內建介面完美整合。

確定項目範圍

  • 必做

    1. 更新ICON:在IOS7裡iphone和ipod需要120*120的圖示、ipad則需要152*152的。在IOS7的ICON在設計上不應使用光圈及陰影。Icon的size需求如下表
      20130916210212734
    2. 讓APP的背景包含狀態列的地方
    3. 支援Retina以及調整APP設計讓他符合iphone5的設計及規範
  • 應做

    1. IOS7建議的畫面要是全螢幕的,因此要確認像狀態欄、導覽列等元素應要是半透明的。
    2. 對於ICON設計的規範有改變,希望是更簡單、並且風格與舊有的有顯著差異,應檢查bar button的圖示是否有符合新的規範
    3. 重新評估所有的按鈕是否真的需要邊框,盡可能的以佈局來讓使用者了解它是按鈕,而不是靠按鈕框
    4. 調整APP的佈局方式,要可以被動態相對位置調整。IOS7建議使用autoLayout,而不要直接用程式去設定物件的位置。某些佈局是應重新衡量及設定。
    5. 因很多物件的預設ui改變,檢查因預設ui改變而影響到的整體外觀。例如switches變窄、Progress Viewe更細、grouped tables分界方式改變。
      2013-10-07_181420
      grouped tables表現方式改變
      2013-10-07_181912
      switches變窄、選日期的元件樣式改變

      這邊有其他相關元件改變的一覽表:http://blogs.innovationm.com/ios6-to-ios7-user-interface-changes/

    6. [重要] IOS7的使用者可以自行設定要顯示的字體大小,應用程式應要可以因應使用者所選的字型大小去調整版型,如下圖:
      2013-10-07_183052
    7. 要預期使用者會開啟IOS7的從底部往上以及從上往下的中央控制功能,因此在APP裡要盡量避免這兩種操作模式(swipe up及top down)
    8. 重新考量一些陰影、漸層的使用:IOS7重視乾淨的介面(smooth)及以深度去強調內容(layered),更勝於一些擬真的設計,因此在設計上應重新考量這部份。
    9. 如果需要,將程式更新至IOS6版本以上,以確保可以使用autoLayout及storyboard。

讓程式支援IOS6

  1. 開啟assistant editor.
  2. 打開assistant editor的上面的選單列
  3. 上面的選單選擇要檢視的XIB或是storyboard
    2013-10-07_184024
  4. 然後選擇要預覽的版本
    2013-10-07_184443
發佈日期:

Flat Design 座談會筆記

講師介紹

Amy Megumi Kuo
http://happyux.hpx.tw/conf/ch/ux-usa-tibco-amy-kuo/
從政大畢業之後就到美國工作。原本是在做汽車面版設計,後來轉到手機和軟體的介面設計。
因為開發裝置的不同,在開發限制上會有所不同。
例如汽車的裝置在設計上,由於許多的按鍵仍然會是實體按鍵,但是手機與軟體則是完全要設計在畫面上。
會造成在設計方針上很大的不同

Flat design 的基本原則

首先要先介紹Flat這個詞
flat (N) 平面
skeuomorphism 擬真,在過去而言,對user來說還不熟悉,所以會用擬真的設計,希望讓使用者第一次接觸就知道如何使用。

flat design較有名的是microsoft和apple還有google。

在這邊比較了一下google的設計與ios的設計上的差異

google的原則

  1. icon盡量簡單
  2. 每個icon都需面向前面,不可有角度
  3. 陰影簡單且同光源方向(左上)
  4. 推薦使用的顏色
  5. 不可用太多效果

apple的iOS human interface guide line

  1. 所有的事情都要以content為主
  2. 所有以清楚展現text為主
  3. 深度的意思是透過不同的層級讓使用者了解要表達的內容

從ios6到7要注意的設計要點,最大差別是『把所有的東西都以展現內容為主

  1. content要全螢幕,東西要做成透明的,讓user可以看的到背景內容
  2. 要redesign使用者的介面,用深度去表達不同的內容種類
  3. 所有的button要沒有border
  4. 在ios7裡,font size可以調大小(大中小)、也可調字距。因此在設計app時要有一個基準大小,然後要考慮到使用者把字變大變小時該如何去條適整體的大小,因此不可以給定一個固定的背景大小,因為有時若是文字變大時字體會超過<重要>
  5. 如果在舊的設計裡面icon有發光、陰影、漸層,apple要求我們將這些design的元素拿掉

因此,在做flat design時,主要是要考量要做出來的感覺。apple和google在flat design上的考量是不一樣的。這是在說明,Flat Design其實並沒有一定的規範或是準則,而是以使用者經驗、或是產品想要給使用者的主要速求為考量做為出發點,維持一定的設計模式,而不需要一味的去盲從。

Flat design 對ux的影響

因為手機現在已更為普及,當操作方式更多元,過場的視窗縮放效果、畫面堆疊等等效果多了,在很多畫面切換中,icon的辨識就變得重要了。好不好辨識不再是”逼真”與否的問題,而是眼睛是否可以快速地辨識icon的輪廓與資訊。於是去掉細節,突顯關鍵形狀與顏色,就成了解決之道

「flat design的好與壞」
好:潮流 、簡單(讓人一看就能明瞭、對設計師程式師都簡單,但要能夠更能表現出精神的)
壞:較難突出(大家的設計都很像,要怎樣去吸引使用者會成為更難的議題)

flat design的三大要素為:顏色、字體、icon

因為設計平面化,使用者對操作的理解來自於操作習慣以及介面呈現,因此在使用者設計上,會有一些不同的注意要點

  1. flat design大部份是用顏色,顏色這件事是很能夠展現出概念或想法,是要專業、開心或是…。在icon設計上的顏色亦十分重要,不能有發光陰影
  2. <<<字體>>>很重要!在挑選字體上面要多花一點心力,要依app內容來挑選適合的字型。沒有最好的字型,只有最適合。每個字型都有他的個性,能與app本身的性質做搭配,就是好的字型選擇。
    若是中英文並用的app也是會在融合上比較困難,需要花心思去調整
  3. 假設今天裡面沒有很多文字時,會看起來太簡單,所以若是在ios7時文字若小,可以多用圖片,更可以讓人印象深刻,不論讀起來或使用起來都會較突顯
  4. 按鈕設計:當按鈕不再仿真,設計者要怎麼讓使用者知道那是按鈕?符合視覺動線的擺放位置和大小、形狀、圖樣、顏色等等都是關鍵。
  5. 當畫面變簡單,UX就更顯重要了。操作手勢(滑動、長按、點、下拉等等)、每個動作得到的回饋(微微顫動、變暗、噗啾一聲…)種種細節都能讓app更豐富。當然,得在使用者熟悉的操作模式下,設法讓app的UX發揮到淋漓盡致。
  6. flat design不鼓勵太無聊的裝飾

Flat design 的挑戰與突破

在Flat design的時代裡,設計者的角色會更加重要。

visual designer要更常去討論這個設計是否能表達出產品的感覺,了解產品特性及想表達給使用者的感受,並且要能夠更精準的使用顏色、字體等元件去表達想表達的。這時後,是否可以做出簡單而能表達出產品特性的icon,便挑戰著設計者的功力。
要如何評斷好的設計呢?在設計時,還是得回歸a b test,訴諸實際數據,然後找出最能讓使用者接受的介面。

當產品要使用Flat Design,在做的工上會能夠減少,因為不需要一直去仿真、繪製很多效果。但是設計者會需要更高強的功力,精準的去以手勢、顏色、字體等元素,來強調出產品的特色。

發佈日期:

IOS6與IOS7的不同處整理

1. View會和狀態列重疊(壓在其之下)

2. 按鈕沒有邊框

3. tab bar變為半透明

螢幕快照 2013-10-06 下午7.18.46

4. 狀態列的顏色不會與導覽列分開

5. tintColor的影響顏色範圍改變,導覽列與tab bar的顏色不會受到tint Color的影響
ps:經測試,在ios7對於Segmented Control的tintColor,如果使用Global tint,一開始時的框線顏色不會變,但點過後顏色會改變。此時必須去各別設定該元件的tint color才會完整變更顏色

6. tab bar的圖示有按下狀態及非按下狀態螢幕快照 2013-10-06 下午7.24.37

7. 文字樣式明顯不同(即使是相同的設定)

8. 預設會是全螢幕畫面

9. 狀態列的高度不再會影響到整體畫面高度(整體畫面會在狀態列之下)

10. NSBundle Class改變Chia-Hsin分享
ios7的pathForResource (NSBundle Class)方法有調整過,
例,Local/iphone/page/01/01.jpg,
ios7之前用:
folder = Local
fileName = iphone/page/01/01.jpg

參數帶入function裡面是OK的~

但現在ios7要改成:
folder = Local/iphone/page/01
fileName = 01.jpg

11. iOS 7 的UITextField會預先給值,iOS 6 不會
if(![username.text isKindOfClass:[NSString Class]]){
NSLog(@”你沒有輸入帳號”);
}
因此這邊在ios7,若使用者沒有輸入任何文字,還是會成立。

12. viewdidload執行順序改變(建議:直接用@property帶值過去,然後在viewWillAppear裡去執行動作)
IOS6的code
ViewController *view1;
[[self navigationController] pushViewController:view1animated:TRUE];
[view1 method];

iOS7以前, 順序為view1被push出來以後會先執行viewdidload候才會執行[view1 method]
而iOS7後變成會先執行[view1 method]才執行viewdidload
目前在push前加viewController.view.hidden = NO;可以解決我現在的問題

Micheal老師建議:本來就是在 View Controller 裡面,去判斷的,不是在你寫的 pushViewController 那段程式碼。你寫的這段的地方,view controller 的 view還沒呈現,所以 view 也沒有值。之前會有值,只是剛好。我們不能決定什麼時候 ViewController 產生 view 的值,我們只知道,在 viewDidLoad 會有 view 的物件,在 viewDidAppear,view 的 frame 會被決定(如果是 storyboard 上的 view 的話)。 再來收到 delegate 回傳值要反應的 view 是 ViewController 的 view 為什不把接收者,設定為 ViewController。

附註:狀態列改變的相關議題

(一)讓上方留狀態列的位置

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
if ([[[UIDevice currentDevice] systemVersion] floatValue] &gt;= 7) {
[application setStatusBarStyle:UIStatusBarStyleLightContent];
self.window.clipsToBounds =YES;
self.window.frame =  CGRectMake(0,20,self.window.frame.size.width,self.window.frame.size.height-20);</code></strong>
<strong><code>
self.window.bounds = CGRectMake(0, 20, self.window.frame.size.width, self.window.frame.size.height);
}
return YES;
}

(二)座標計算不將狀態列的地方算入

if([[[UIDevice currentDevice] systemVersion] floatValue] &gt;= 7.0)
{
self.edgesForExtendedLayout = UIRectEdgeNone;
self.extendedLayoutIncludesOpaqueBars = NO;
self.modalPresentationCapturesStatusBarAppearance = NO;

self.navigationController.navigationBar.translucent = NO;
self.tabBarController.tabBar.translucent = NO;

self.navigationController.navigationBar.barTintColor =[UIColor grayColor];
self.tabBarController.tabBar.barTintColor =[UIColor grayColor];
}

(三)不顯示狀態列

  1. 至project setting=>General=>Deployment Info的地方勾選Hide during application launch
  2. 在ViewController加上
    -(BOOL) prefersStatusBarHidden{
    return YES;
    }

(四)改變狀態列顯示樣子(將字體顯示為白色)
-(UIStatusBarStyle)preferredStatusBarStyle{
return UIStatusBarStyleLightContent;
}

相關資料來源:

發佈日期:

UIWebView練習作業

作業目標:http://www.youtube.com/watch?v=azplcMbuoQ4&feature=youtu.be
練習檔案:homework0831

先介紹一下UIWebView

UIWebView的資料來源主要有三者:

  1. 本機上的HTML字串
  2. 本機上的資料 + MIME type
  3. 遠端的URL

這邊有中文的介紹:http://www.inside.com.tw/2010/03/14/cs193p-lecture-12

作業練習開始

首先我先拉出storyboard
螢幕快照 2013-09-04 下午11.30.34

然後我練習使用程式去產生UINavigationController,這是在AppDelegate.m裡

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{

UINavigationController * navi = [UINavigationController new];
UIStoryboard * storyboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil];
UIViewController * controller = [storyboard instantiateViewControllerWithIdentifier:@"pink"];
[navi pushViewController:controller animated:YES];
self.window.rootViewController = navi;
return YES;
}

然後ViewController.h裡在viewDidLoad時初始化一些頁面數值

- (void)viewDidLoad
{
[super viewDidLoad];
[self.inputURL setAdjustsFontSizeToFitWidth:YES];//設定下方網址列的大小會自動resize
self.title = @"填入網址";
self.inputURL.text = @"http://www.apple.com";
}

實作按鈕按下時的動作

- (IBAction)goWeb:(id)sender {
//取出webview的view
UIStoryboard * storyboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil];
WebViewController * webView = [storyboard instantiateViewControllerWithIdentifier:@"webView"];
webView.urlString = self.inputURL.text;
webView.delegate = self;
[self.inputURL resignFirstResponder];//收起鍵盤
[self.navigationController pushViewController:webView animated:YES];
}

接下來做WebViewController.m裡的內容,
在這邊我弄了一個下載進度的物件叫作UIActivityIndicatorView
這部份首先要先在- (void)viewDidLoad裡初始化載入效果

//加入載入特效
aciv = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleGray]; colorView=[[UIView alloc]initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, self.view.frame.size.height)];

[colorView setBackgroundColor:[UIColor colorWithRed:0.2 green:0.2 blue:0.2 alpha:0.4]];

然後加上下面兩段程式碼

//載入特效
- (void)addLoading{
aciv.activityIndicatorViewStyle=UIActivityIndicatorViewStyleWhite; aciv.center=CGPointMake(self.view.frame.size.width/2,self.view.frame.size.height/2-10);
[self.view addSubview:colorView];
[aciv startAnimating];
[self.view addSubview:aciv];
}

- (void)removeLoading{
[colorView removeFromSuperview];
[aciv stopAnimating];
[aciv removeFromSuperview];
}

然後在實做UIWebView的Delegate去設定載入畫面
[UIApplication sharedApplication].networkActivityIndicatorVisible這個是在上方指示列的圈圈圖示

- (void)webViewDidStartLoad:(UIWebView *)webView
{
[UIApplication sharedApplication].networkActivityIndicatorVisible = YES;
[self addLoading];
}

- (void)webViewDidFinishLoad:(UIWebView *)webView
{
[UIApplication sharedApplication].networkActivityIndicatorVisible = NO;
[self removeLoading];
}

遇到問題(高手幫忙看3Q)

然後其實接下來這一點問題我弄了非常久~ 就是,在從上一頁傳來網址時,
也會執行到
-(BOOL) webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
所以會必須去判斷現在是使用者點擊的link,或是是從上頁傳來的指令

為了這個需求,我用了幾個方式,但都有問題,包括現在的其實也有,但因為實在搞太久~
所以就先這樣@@等老師公布他的作法後再來補修正

我總用試了這些方式

  1. 使用一個BOOL去判別,只有第一次loading頁面時不做跳頁呼叫,然後當webViewDidFinishLoad時將BOOL改為NO
    問題點:有某些頁面會有js檔案,當頁面全部載入完成後,執行js後,就又會再第二次讀取網路資料,此時頁面就會莫名的突然回到第一頁然後顯示網址。(例如:我的部落格http://claire-chang.com)
  2. 使用NSConnection(http://stackoverflow.com/questions/9475768/loading-nsdata-into-a-uiwebview)
    這是一個異想天開(?)的想法,我想說,第一次loading時用NSConnection去讀html,然後用loadHTMLString:baseURL:來顯示在畫面上。結果html成功的載下來了,但是不知為何WebView呈現一片空白。
    在網路上查了一下,似乎是因為<scripe>標籤的關係(不確定)
  3. 現在版本的方式:偵測使用者點擊事件,當使用者點擊時,判斷現在是使用者點擊事件,下一次的網頁讀取便會跳頁。
    不過這種方式也有問題,同第一點,不過狀況會變成若頁面尚未載入完,使用者就點擊非link的地方時,js呼叫讀取網頁時,就會跳回第一頁,然後網址顯示為js呼叫的頁面網址= =

也是因為這樣子,我才會去製作下載畫面,想說在未loading完前不讓使用者按下WebView,
結果因為畫面會先loading完成、然後才自動因js而去呼叫另一個網址。
中間還是會有使用者可以點擊畫面的時間點。

我總覺得UIWebView應該有個東西是可以直接判別是否是使用者呼叫的,
觀察過dataDetectorTypes的值,卻似乎不是~orz
有知道的人麻煩幫解惑吧~3Q!
ps:若想試有js會在loading完成後再次loading的狀況,請把網址設為我的部落格http://claire-chang.com

因為我是用第三種方式,所以我對WebView增加了碰觸事件的偵聽
首先在- (void)viewDidLoad設定碰觸事件監聽

//設定碰觸事件
UILongPressGestureRecognizer *longPress = [[UILongPressGestureRecognizer alloc]initWithTarget:self action:@selector(handleTapFrom:)];
longPress.minimumPressDuration = .001;
longPress.delegate = self;
[self.web addGestureRecognizer:longPress];
[self.web addGestureRecognizer:test];

然後要實作UIGestureRecognizerDelegate

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
    return YES;
}

上面這個一定要加,這樣子handleTapFrom:才會被呼叫到
然後當按到時將bool值改成YES

-(void)handleTapFrom :(UITapGestureRecognizer *)sender{
    NSLog(@"handleTapFrom:%d",sender.state);
    isClick = YES;
}

當讀取網頁且isClick是YES時就跳回第一頁

-(BOOL) webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType{
    if(isClick){
        [self.delegate userClickWebLink:request.URL.absoluteString];
        return NO;
    }
    return YES;
}

這時再回去ViewController.m增加接收的方法

-(void) userClickWebLink: (NSString *) url{
    [self.navigationController popViewControllerAnimated:YES];
    self.title = @"點選網址";
    self.webUrl.text = url;
}
發佈日期:

hasEventListener()與willTrigger()區別

承上一篇介紹Event事件流的基本概念
AS3的事件傳遞機制(Event、dispatchEvent及addEventListener)
再來介紹相關的檢查函數。

hasEventListener()方法:
檢查 EventDispatcher 對象是否為有註冊這個事件的監聽器。
willTrigger()方法:
檢查是否用此 EventDispatcher 對象或其父容器是否有註冊這個事件的監聽器

hasEventListener() 與 willTrigger()的區別是:hasEventListener() 只檢查它所屬的對象
而 willTrigger() 檢查對象以及對象的父容器是否有註冊這個事件(不管capture的值)。

假如像下面這樣的物件階層來說

efAzj

今天我們對stage註冊事件

stage.addEventListener(MouseEvent.CLICK, stageClick);

則檢查box的willTrigger及hasEventListener

trace(box.willTrigger(MouseEvent.CLICK));
trace(box.hasEventListener(MouseEvent.CLICK));

的結果為
true
false

而若我們對box註冊事件

box.addEventListener(MouseEvent.CLICK, stageClick);

則檢查box的willTrigger及hasEventListener

trace(box.willTrigger(MouseEvent.CLICK));
trace(box.hasEventListener(MouseEvent.CLICK));

的結果為
true
true

而若我們對box註冊事件

box.addEventListener(MouseEvent.CLICK, stageClick);

則檢查stage的willTrigger及hasEventListener

trace(stage.willTrigger(MouseEvent.CLICK));
trace(stage.hasEventListener(MouseEvent.CLICK));

的結果為
false
false
代表box不在stage完整可能有的事件流的動線裡。