titanium url cheme設定

SDK 2.0.1 GA2下
Titanium 會自動設定url scheme
預設是application id最後單字
例如 com.demo.theappname
url scheme就是theappname

不過有一各小例外
當使用 us.adison.TheAppName時
url scheme是Theappname（只有首字大寫）
如果還是有問題，打開builer下的檔案檢查看看
iPhone: builder/iphone/info.list
        <key>CFBundleURLName</key>
                        <string>com.demo.theappname</string>
                        <key>CFBundleURLSchemes</key>
                        <array>
                                <string>看這邊</string>

android
builder/android/AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.demo.theappname 這邊" android:versionCode="1"
        android:versionName="1">

使用url scheme的方式可以參考
http://developer.appcelerator.com/question/120393/custom-url-scheme---iphone--android

// Save initial launch command line arguments
Ti.App.launchURL = '';
Ti.App.pauseURL = '';
var cmd = Ti.App.getArguments();
if ( (getTypeOf(cmd) == 'object') && cmd.hasOwnProperty('url') ) {
Ti.App.launchURL = cmd.url;
Ti.API.info( 'Launched with url = ' + Ti.App.launchURL );
}

// Save launch URL at the time last paused
Ti.App.addEventListener( 'pause', function(e) {
Ti.App.pauseURL = Ti.App.launchURL;
});

// After app is fully resumed, recheck if launch arguments
// have changed and ignore duplicate schemes.
Ti.App.addEventListener( 'resumed', function(e) {
Ti.App.launchURL = '';
cmd = Ti.App.getArguments();
if ( (getTypeOf(cmd) == 'object') && cmd.hasOwnProperty('url') ) {
if ( cmd.url != Ti.App.pauseURL ) {
Ti.App.launchURL = cmd.url;
Ti.API.info( 'Resumed with url = ' + Ti.App.launchURL );
}
}
});

titanium visible, show, hide

Though hide() & show() are handled appropriately in views, the state of the property 'visible' is never changed. If you pass visible: false in the createXXX() method, it will be respected and used (the view will be hidden), but the value of .visible never changes again even after calling show().

這句話的意思大概是當使用hide/show()時
元件的visible屬性並沒有變化
例如建立一個 xxx {visible:false}後，使用xxxx.show()
這時去檢查visible也依然是false
所以別用visible檢查元件是否為可視狀態
要檢查可視狀態的話，另外設定一個bool值處理（好像有看過人這麼建議？）

是說Titanium好歹也提供一個toggle指令吧..

Titanium ios/android同專案開發心得

這篇算是一個階段性的總結
先說一下專案過程，這是一個LBS型態專案
其中使用了一些比較fancy的UI/UX
也使用到了一些分享功能（簡訊、email之類、fb）
一開始是從ios版本做起
之前有一個lite的iOS版本，也是用Titanium開發的

這次開發pro版本時
由於繼承了lite版本的不少程式碼（約一半）
基本上開發速度蠻快的
Titanium在某些方面是有它的優勢存在的
包括
可以使用JS語法處理：
無論是iOS或android，要搞懂他們的語法和架構多少都需要一些時間，甚至是不少時間
而Titan提供用JS語法進行開發的功能，這點對於許多了解JS語法的開發者而言，一定是一個利多
但是由於不是原生語法，如果專案中要用到一些比較底層的功能，就會很麻煩
如果是Titan沒有提供支援的功能，也會很麻煩

整合了一些常見/常用的元件和方法
Titan在網路傳輸這塊整合的不錯，此外還包括FB、資料庫的語法整合也很方便
不過這三個領域在andoird或ios上都有一些不錯的整合元件
真的要說的話，大概只有fb的整合算是比較獨特和省時間

一開始寫ios版本時
大部分的時間都花在調整UI/UX上面
好的UI/UX是一個app一定要有的元素
UI/UX也許不用很獨特、很絢麗
但至少要是一個讓使用者可以很快速了解、使用的介面設計

這部份加入前後的修改，和一些思考及功能上的調整，大約花費一個多月左右完成
這期間使用Titanium處理iOS時，有碰到一些問題，但沒有多少bug出現
比較特殊的大概是Titanium還不支援ios上的簡訊功能
所以有引用SMS模組，但是SMS模組在使用上有一些問題
由於之後設計變更，沒有繼續使用，所以現在不確定是因為SMS模組的問題
還是因為把SMS模組套用到scrollview中的按鈕上的問題
（這部份之後會提到，Titnaium中並非所有元件都能配合無誤，目前為止，很多元件放在scrollview中常會出現一些不可理解的行為，或稱為bug…

在決定使用同一套程式碼進行android開發時，才真正陷入bug地獄..
首先，我要說明一下，以下提到的情況未必都是titanium的問題
android的版本之多、硬體組成之複雜從來不是新聞
即使使用原生android程式碼，也很少有人能保證不會碰到問題
其中尤其以影音相關功能最為複雜
但是在Titanium上，影音相關的問題我這次碰到的情況並不多
最主要的大概只有使用相機拍攝照片並上傳時，會一次記錄兩張照片的功能而已..
喔，使用相片膠卷挑選照片上傳好像也會讓照片自我複製一次…

還是先從ios/andorid的基本元件設計開始談起好了..
iOS和andoird的基本畫面設計本身是不同的
最簡單的就是andorid沒有上方的navbar設計
這種設計當然是可以模擬出來的
但是對應的navigation group功能就不是簡單的模擬可以做到的了
這就是同一套程式碼要對應android和ios時要碰到的第一個問題
這問題會很煩，但不是無解
只是要多花費一些心力去處理畫面進出時的設計
不過由於有了本來的ti for ios程式碼，加入這設計時可能會讓程式看起來有一點雜亂

接下來我碰到的問題在於ios獨特的元件設計
例如toolbar, systembutton
android在這方面非常欠缺
最簡單的例子是刪除用的垃圾桶圖示
在titnaium中，可以使用iphone.systembutton.delete這樣的簡單語法提取iOS的垃圾桶圖示作為按鈕
（雖然只能放在toolbar或navbar上）
但是在android(2.2)中並沒有（Titanium官方只宣告支援2.2，其他的版本多少有相容性，但是個人建議別去踩那地雷..你之後還有很多地雷可以踩個夠..）
在android上少了這設計就表示你需要自己弄一個按鈕，自己標明"刪除鈕"
如果想要精美的垃圾桶圖示，請找美設人員討論..
平心而論，這不是大問題
就算是在iOS上，由於toolbar的限制，這種系統icon也不是隨時都可以使用的
而且這是ios/android 在基本架構上的不同，與titanium本身優劣並無干係
當一套app要在這兩個不同平台上開發時，這本來就是必須花的功夫之一
不過加入前面說的ti for ios程式碼後，會讓整個程式碼結構看起來更雜亂了一點
不過這部份和程式流程/UI結構關係並不大，其實還可以接受
修改起來也不是太麻煩
處理這部份問題時，我主要的工作都在於搜尋ios元件，然後替換成對應的android可使用元件

修改這部份後，原始專案終於可以在android平台上測試了
這時候android解析度不統一的問題就出來了
ios上由於有自動判斷解析度加入@2x而且長寬比不變的設計，在iphone 3gs/4/4s上只需要注意某些硬體元件是否存在就可以（雖然這三種機型的硬體元件只有規格差別而沒有是否存在的差異）
但是android上面的螢幕長寬比、解析度差異很大，在這部份就要特別小心
這部份我們所採用的是懶人作法：強制使用預設長寬比設計
主要是在tiapp.xml中加入一個簡單的設定

接下來才是正式的測試
首先碰到的是android平台在GPS定位上的速度比ios慢，慢很多..
所以需要修改原本的單線流程，改成使用callback方式，讓機器抓到GPS訊號後才執行對應程式碼
這部份ios可以通用（說實話這是比較好的作法）

但是接下來就是一堆地獄了..
說真的，現在想起來，我覺得titanium對於ios的支援程度好很多..
我並不真的確定原因..但是我覺得和ios的穩定性以及架構相對完整有很大關係
我們的專案由於有特地強調UI/UX，並加入一些作法減少使用者的等待時間
所以在物件架構上相對比較複雜，有2~4個物件常駐背景並等候呼叫和執行
這些物件在iOS上使用時，透過navigation group的push/pop方法就可以運用
但是在android上不行..在android上使用back或close時，物件就會被關閉
這問題的出現，一方面是因為我方原始的設計不夠成熟
但也不能忽略titanium在這方面的移植性設計不夠完善才導致這種令人騎虎難下的情況出現
由於時間壓力，這方面我們使用了簡單的show/hide方法繞過
使用這方法繞過的一個主要考量在於這些設計和程式行為有關
所以不再能像UI元件一樣使用簡單的if(iiOS them ooxx 方式來進行簡單的分支處理
可是這還沒結束…

titanium on android上，對於層層套疊的元件在編譯時很容易出問題
一個簡單的 xxx.hide指令
當xxx"直接"附屬於最底層的window時，是很正常的
但是當xxx放置在scollview，scrollview又放置在tablerow中時，hide指令就無效了..
在iOS上一開始也曾經出現類似問題，但是當時出現的問題主要在於效能方面（tableview先出現，一閃之後才會出現裡面的元件）
元件的基礎指令如hide 無效的問題並未被觀察到


另外，如同上上一段所說的，為了減少使用者等待時間，我們有一些物件是常駐背景處理的
因此無可避免的，我們有一些事件處理會呼叫這些背景物件執行，也會根據執行結果安排元件並顯示出來
但是在操作這些背景元件時，titanium對這些元件的處理方式有奇妙的不同
在iOS上，開啟一個window放置背景後，可以輕易的操控其中的元件屬性
並在操作完成後顯示window
但是在android上，這些元件未必是可操控的，這問題尤其容易發生在元件不直接附屬於window時
即使是在同一個active window中的元件，由於上一段所提及的因素，要操作其行為也未必可行
當元件是scroll開頭的scrollview或scrollableview時尤其明顯

另一個問題是，在android上，當在table row中加入一個圖片當按鈕
指定圖片點擊動作為開啟新的window，當window關閉時
android有可能出現z-order錯誤問題
這問題幾近無解
因為他牽涉到的是titanium編譯指令的方法和android的行為
唯一可信的解法是使用heavyweight方式開啟window，如 modal:true
不過這解法也並非100%完美..

整體而言，將這套在ios上完美的程式碼轉移到android平台時
只有和UI無關的傳值行為可以不用花心思處理
其他的諸如表格點擊之類動作都或多或少有一些相容性問題(ios上e.rowData可以用，android上可能就要測試e.source之類）

結論
如果將titanium定位在快速建立簡單的iphone app的話，titanium還蠻完美的
如果想用titanium開發簡單的android app，應該也不會碰到太大問題
但是想要用同一套程式碼同時覆蓋兩個平台的話，我會建議先行判斷你的app是否符合以下條件
畫面設計簡單：這方面說的不是功能上的簡單，而是UI架構上的簡單，建議最多不要超過二層
也就是頂多用到 base window/wrapper/ UI 這樣的設計就好
這條件並不表示你的畫面要維持素淨，只要在一層之內，你想加多少image其實都不是問題
如果可能的話，最好是只有一層如 window/lavel
程式架構簡單：盡量維持一次只有一個window，背景最好不要有其他元件
這條件可能會讓app在開啟新的畫面時多花費一些時間，但是可以有效的降低你處理背景物件時花費的時間。一些額外的好處則是可以節省app的記憶體空間
UX設計不要太複雜：一些動畫還是可以用的，但是別讓這些動畫擴及到active window以外的元件
盡量遵守MVC設計：程式歸程式，ui歸UI，資料歸資料，千萬別讓資料和ui卡在一起。
盡量使用callback：如果你不確定怎麼把app架構拆成MVC，起碼你可以使用callback方式來處理程式。當然兩者一起就更好了，這可以讓你的程式更好掌控和管理

最後一個問題，我會後悔學習Titanium或用它開發嗎？
我的回答是不會，Titanium在建立app上確實有它的優勢和特色，包括快速的學習曲線和快速的開發
但是它的應用範圍顯然沒有原生語言/IDE來的廣泛和深入（喔，Titanium沒有 xcode的interface builder之類拉畫面的附屬程式，不過反正android也沒有這種支援程式..應該沒有吧）
當然你可以自己建立Titanium module來擴展它的能力，不過走到那一步的話，你還能享受到多少快速/簡易特性？
titanium在原生UI元件的支援上未必100%支援（例如ios上的sms功能...）
不過一些簡單的元件如label, button之類，基本上都有支援

但是當ios上完美運作的程式卻在android上由於UI套疊後的存取/控制問題變成蟲族母巢後
我就開始後悔用它做這種開發了
記得，別給Titanium太大的發揮空間，能簡單就盡量簡單

補充幾點
Titanium的debug能力非常基本，除了簡單的語法錯誤和log方法之外，幾乎沒有其他debug作法
不過可以透過使用xcode/eclipse開啟編譯過專案的方式處理
和ios/android相比，Titanium api和開發資訊相對而言少很多
最後
Titanium用在iOS上比android穩定很多，如果只是用來顯示網頁資料的app，更是幾乎不會有任何問題

titanium android 下 ambiguous z order 問題

這篇文章給後來有碰到這問題的人當參考吧
SDK 2.0.1GA2
簡單結論：Titanium on android中，開啟new window時，
如果是tablerow ， click事件請使用row內的button 別用其他元件（包括row.click事件
或者是使用 modal: ture方法開啟


把app轉換到android時
Titanium一直出現 ambiguous-z-order 問題
根據http://engineering.rentgeek.com/titanium-ambiguous-z-order-android 的說法
使用row中的button 事件開啟新視窗時，就不會有這問題
而使用 row click事件就會有

他推測這是因為點擊tab group.tap1.table.row 時
開啟新window後，按下close按鈕時執行倒退動作時
系統會嘗試去取得原本focus的元件（row）
但是由於這元件在window.table.row中，APP定位不出來，就造成了z order問題

他用了image 元件當說明，可是image和他推論的button應該是同一級別元件..
結果他也不知道為什麼image會有這問題 orz

他的解法是加入modal true設定來避開
可是這解法對我而言不適用..


追加
http://ti.masuidrive.jp/topic.php?id=333
這篇是使用table + scrollview/scrollable view
也是有z-index問題

假如七八十歲的人還在創新，我們問題就大了

原文 http://forum.inside.com.tw/viewthread.php?tid=1492
節錄：
一個多月以前我去台灣，在一個餐桌上，有一批年紀很大的企業家，頭髮都很白了，每個人都大談創新，怎麼創新?邊上有個人跟我講，台灣有希望，我想這麼大年紀的人還在創新。後來我說台灣沒希望了。 假如七八十歲的人還在創新，我們問題就大了，他們不相信年輕人比他們更會創新，其實他們應該是盡全力去努力幫助年輕人去創新，建個平台扶持他們創新、幫助他們創新。 所以我們認為比年輕人更聰明，那災難就出現了。

延伸閱讀
十九世紀的製冰業，派人在結冰的湖面或河裡，將冰塊鋸下給顧客使用，他們的工作後來被製冰廠取代，製冰廠又被電冰箱取代，假如他們願意擁抱改變，而不是去抗拒改變，他們將有機會轉進到新的技術領域，而不是眼睜睜看著自己的心血被別人取代。

老人用他們的想法創新，不接受小一輩的真正創新。

這想法就和冰塊製造廠老闆一直想創新冰塊，卻不接受電冰箱這種東西的情況類似。
對冰塊業創新是一條路，但是當電冰箱出來後，大家都能做冰塊，還守著舊思維思考怎麼運送冰塊好讓他不融化，而不去思考是否到處建小廠做冰塊，那註定失敗。
因為這是一種典範轉移、破壞（革命）性創新，而破壞性創新是不可能從原本的基礎上改進而來
同樣的問題出現在出版業、快遞業、ooxx行業，只思考怎麼更好的賣東西，而不是思考他們在賣的是東西還是資訊時，那註定會被淘汰
十九世紀的製冰業，派人在結冰的湖面或河裡，將冰塊鋸下給顧客使用，他們的工作後來被製冰廠取代，製冰廠又被電冰箱取代
有多少製冰業的老闆講創新時是在想製冰廠？製冰廠老闆有多少在思考電冰箱？
那些七八十歲的製冰廠老闆講創新時，我們都在弄電冰箱了，你相信他們和我們想的會視同一件事情嗎？
馬雲這次的觀點未必正確，不過他想講的東西是正確的，那些該放手的人就放手吧。
換個角度，台灣現在一線演員你 看得到多少3x, 4x的人？製作人呢？我們只看得到/聽得到楊佩佩之類6x,7x的人，3x/4x的人跑哪去了？是不存在還是整個被那些努力工作一輩子的人給壓住了？
當然很多東西需要時間養成，名氣、演技、成就都是，但是當這一代整個不在名單上時，這不叫做沒人成功，這叫做一種警訊
長輩活到90歲，工作到90，然後留給6x/7x的人擔子，6x/7x又活到100。這樣的企業/環境，真正新穎的想法怎麼出頭？
真正新穎的想法是沒有前例可循的， 提出來時，長輩一句你有經驗嗎？我有！沒有想法是能通過這句話的檢驗和長輩經驗門檻的
然後就是只能依循前例，大家繼續想怎麼更有效率的從河裡挖冰而不是去思考電冰箱怎麼用比較好（攤手
到了這地步，真正的創新就不可能了 XD

Titanium 雙行動平台 textarea行為差異

keyboard:
android沒有toolbar這設定，我也不確定是否有辦法在keyboard上另外添加view
這會牽涉到done/cancel這兩個必須按鈕的配置
如果可以的話，盡量使用modal window處理
如果是單行，可以用enter判斷

使用 Titanium 開發 android和iphone app心得

隨著andoir的改版進度
我對titanium dev on android越來越灰心
這裡面當然多少牽涉到原本的程式架構有點複雜的因素
不過多半的問題在於iphone與android的基本差別
另一個問題是Titanium只確定支援android 2.2

這裡面會牽涉到一些問題
android 4.0或更高版本是否支援Ti創建的APP?
在Ti中，怎麼用一套程式碼走遍android SDK 2.x -4.x甚至更高？
如果不行，這之間的支援怎麼解決？

如果你也要使用titanium進行開發
請盡量確保你的程式使用的元件夠基本、流程不要太複雜
盡量一次只使用一個畫面，使用適當的global var儲存資料
window open時才建立對應畫面展現（我這次有一半因素栽在這邊）
如果考慮使用相同layout, 在建立window時，就要考慮上方的navbar要怎麼在android中展現
//我想過建立一個custom winnow覆蓋title元件，不過下次再說吧
資料傳輸只牽涉到OSI前三層

不過以上條件如果全都達成
那做出來的app大概也沒啥特殊看頭，大概只會是專案app而不會是產品 XD
所以最好的作法可能會是在Ti中使用很嚴格的MVC架構，這樣才可能確保完整的移植性
可是能做到這點的人中，其中大部分的人轉學android或iphone可能也不會多花太多時間（有興趣的話..

如果讓我說，Titanium的用法應該是用來快速創建單一平台app
如果考慮要覆蓋多重平台，至少要把資料操作部分程式完全抽離
這樣就可以讓多重平台app使用同一套資料操作app，但使用各自的ui/controller方法
如果堅持要用同一專案，那至少可以使用不同的UI/control方法
放在同一個js中，判斷if android, 然後計算width/height並不會讓日子好過多少

Titanium在資料操作部分的程式轉換做得不錯，也整合的不錯
然後在前端ui部分，也許可以說是因為ios和android本身就有很大差距
但是用起來就是非常的不順暢！
當很順暢（隨便）的建立了單一平台app，然後想轉換到另一平台時
這UI的不同與相應產生的工作壓力所帶來的挫折感在這時最為明顯（例如此時的我 orz

Titanium SDK 2.0.1GA android下talbeviewrow高度

雖然從sdk2開始，height/width : 'auto'作法被官方捨棄
不過在2.0.1Ga下，android環境中tableviewrow使用height : Ti.UI.SIZE是有問題的（iphone則OK
所以還是要用height : 'auto'寫法

等sdk改版後，這問題可能也許大概就會被修掉？

2012/5/26 上午11:18
sdk 2.0.1ga2
andr下，width要使用 'auto'，不支援Ti.UI.SIZE

android modal window無法出現兩次

根據
http://developer.appcelerator.com/question/123838/android-modal-window-wont-open-twice#215617

在android中，win1.open({modal: true})後
按下back鍵時，win1會被destroy
當win1是在事件程式碼外建立時，就會出錯

理論上應該有解決方法：win1中覆蓋android:back事件隱藏win1

不過由於使用modal方式開啟的window是heavyweight window, 不支援hide方法只支援close方法
而close方法也會destroy window reference… 等於是同一條路 orz
然後其他的方式如zIndex方法也無效..
簡單來說，就是使用modal方式開啟的window無法用close以外方式隱藏、關閉

雖然modal window可以支援android:back按鈕
不過使用modal window作為navigation group的替代方案是有問題的
還是乖乖使用tabgroup方式比較好

iOS UI設計27方針

來自 http://www.simonwhatley.co.uk/apples-27-guidelines-for-mobile-user-experience-design

The user experience of iOS-based devices revolves around streamlined interaction with content that people care about. Below are Apple’s 27 guidelines for mobile UX design:

我流翻譯開始
Focus on the Primary Task
（讓使用者）專注在主要工作上

Elevate the Content that People Care About
評估使用者真正想要的內容
這方針的問題在於通常我們都在評估老闆要的功能 :p

Think Top Down
從上到下思考（功能、UI設計）
其實我不是很懂這句（完全沒有前後文說明..），也可能是指content呈現上根據重要性從上到下排列

Give People a Logical Path to Follow
給予使用者一個有邏輯性的使用路徑
例如folder/catelog -> 內容或是start - edit -done 這樣的路徑，不要讓使用者一開始就在功能流程的中段而不知道從哪來、做什麼、往哪走

Make Usage Easy and Obvious
讓app的主要目標簡單且顯眼
別讓其他的次要目標和主要目標一樣顯眼，例如分享的icon..

Use User-Centric Terminology
用以使用者為中心的字彙
與其使用ID，不如使用account, 與其使用modify不如使用edit

Minimise the Effort Required for User Input
盡量減少使用者的輸入需求
包括建立合理的預設設定，想想看你開一份word結果要求你先輸入檔名、頁面、font, font size時你會多不爽

Downplay File-Handling Operations
盡量減低檔案處理動作在使用者眼中出現的次數（使用者需要的是處理內容而非處理檔案）
以照片編修軟體來說，別問要不要覆蓋，使用者存檔時就把照片存成新檔、建立不同版本或提示舊照片會不見

Enable Collaboration and Connectedness
提供協同合作和連接特性
app合適的話..而且這樣也能提高擴散可能性
不過這樣需付出的成本和單機app相比會提高很多..

De-emphasise Settings
盡量減少app設定的重要性
只有特別需要的東西才放到setting中
這和一般的想法有所相反：setting是放做得出來的功能但不確定最好選項的地方，例如頁面背景色之類 XD
其實這句話的基礎思維在於：別期望使用者會去使用setting, 把程式的預設選項做到最好，其他需要調整的東西盡量放在相關的頁面上，別放在那個和主要task完全搭不上邊的setting中

Brand Appropriately
使用合適的品牌/名稱（別用不相干的字眼或名稱作為app名稱或icon

Make Search Quick and Rewarding
搜尋功能應快速（使用、效率）且提供之前記錄
包括search功能應該隨時在畫面上
可以顯示之前的搜尋詞或結果
Entice and Inform with a Well-Written Description
通知/說明/placeholder/hint的說明要用心
包括簡潔、易懂、讓使用者知道這說明的目的，看完說明之後能了解要輸入什麼、做什麼、取得什麼結果

Be Succinct
簡潔
簡潔

Use UI Elements Consistently
UI元素要有一致性（風格）
這交給美術去傷腦筋 XD
PM只要記得問他們這些UI/版面的一致性在哪就可以了

Consider Adding Physicality and Realism
考慮加入物理/現實特性，讓使用者可以在其中找到和現實的關聯性
例如在書籤icon上使用現實中的書籤造型，edit使用紙筆icon

Delight People with Stunning Graphics
使用絢麗的圖像愉悅使用者（就是要炫…

Handle Orientation Changes
處理裝置轉向需求
就算只限定portrait也要開啟上下翻轉（何必呢…

Make Targets Fingertip-Size
別讓目標物件小於手指尺寸
apple建議44x44，不過他們自己的nab button就違反了 XD

Use Subtle Animation to Communicate
使用微動畫與使用者溝通
例如擺動圖標提醒使用者
這是因為人眼很容易受到移動的事物影響，就算不在主要視界中
不用開一個alert 視窗，一個小小搖動的icon或變色的icon就可以讓使用者注意到程式狀態的改變

Support Gestures Appropriately
適當的支援手勢功能
例如照片之類同樣性質但無法在同一頁顯示的內容就可以考慮加入手勢功能讓使用者直接切換
不過別為了手勢而手勢..（遙想當年..

Ask People to Save Only When Necessary
只在必要時請求使用者執行儲存
一般來說，使用者離開編輯畫面只有兩種情況，cancel與done
如果不是modal window，那可以考慮只出現cancel/reset按鈕，done由使用者離開當前編輯畫面事件觸發

Make Modal Tasks Occasional and Simple
減少modal window的出現，而且別讓modal window內的工作複雜
不要一直modal window! modal window中別讓使用者待超過30秒，走三層以上路徑

Start Instantly
立刻開始，別讓使用者等待
例如某些一定要等好幾秒的app logo畫面..

Always Be Prepared to Stop
在app的任何功能中都要考慮程式停止/離開時的處理
手機使用情況是隨時都有可能被關閉，確保程式在任何情況下離開都不會造成問題（以及可回復狀態

Don’t Quit Programmatically
別讓app無預警關閉（原文是別用程式處理app離開功能）
程式中任何會讓app關閉的按鈕都要讓使用者知道按下去後程式會關閉
以前看過的一個例子是遊戲過關後會顯示製作名單然後就離開遊戲
這種情況下，使用者就不知道是出問題或正常關閉

If Necessary, Display a License Agreement or Disclaimer
當有必要（使用者誤解導致被告可能性）時，顯示License Agreement 或 Disclaimer
明哲保身方針..反正大部分都只會按下確定 :p

titanium, tableview rowdata.click找不到e.rowData.xxxx資料

在titanium中
tableview下，同一段click事件中iPhone找得到row data.xxx資料，可是android不行..

tableview.addEventListener('click', function(e) {
                if(!e.rowData.xxxx) {
                        alert('no ios markerid');
                        return;
                }

這個問題非常古怪，古怪到我差點和夥伴翻臉討論是否要放棄titanium框架
不過解法異常簡單..
主要是塞row.xxxx的時機
使用以下方式設定資料即可
var row=Ti.ui.createtableviewrow({
xxx: 123,
yyy : 456
});
千萬別用
var row = Ti.ui.ceatetableviewrow({

});
row.xxx=123;
row.yyy=456;
這種用法在iphone正常
但是android（至少是google pai 2.2)下會有隨機性的資料遺失問題發生

2012/5/26 上午11:13更新
以上使用方法是正確的
不過當row是放在section中時
section1.add(row)

在android中，table.click事件
使用e.rowData會抓不到資料
目前確定這種情況下使用 e.row.xxx可以抓到資料
e.row在其他地方的適用性尚未測試

Titanium map annoyation點擊事件: android無法觸發

Titanium map annoyation點擊事件: android無法觸發
簡單來說，annotation點擊在

http://developer.appcelerator.com/question/117350/annotation-click-events-not-working-on-android

http://www.pastie.org/1756264

mapview.addEventListener('click', function(e) {
                        if(e.clicksource == "title" || e.clicksource == "subtitle") {
                                var win1 = Titanium.UI.createWindow({
                                        url:"club.js",
                                        club_id:e.annotation.myid,
                                        title:e.annotation.title
                                });
                                
                                Titanium.UI.currentTab.open(win1,{animated:true});
                        }
                });


//補充
http://developer.appcelerator.com/question/116634/map-annotation-not-showing-right-left-buttonview