真的, 這真的很簡單, 只要兩個步驟
首先, 你要有兩個工具:
步驟1: 拿dex2jar把apk或是dex轉成jar (裡面包含從dex轉譯過來的class file)
command > ./dex2jar.sh ~/SKeyTest.apk
version:0.0.7.8-SNAPSHOT
5 [main] INFO pxb.android.dex2jar.v3.Main - dex2jar /Users/julianshen/SKeyTest.apk -> /Users/julianshen/SKeyTest.apk.dex2jar.jar
Done.
步驟2: 拿JD-GUI開啟/Users/julianshen/SKeyTest.apk.dex2jar.jar (轉出的檔名即是原始檔SKeyTest.apk加上dex2jar.jar)
結果就像這樣:
今天早上, Honeycomb preview SDK已經出來了, 當然包含了模擬器, 不過真的是慢到嚇死人的不能用, 在我的MBP上動不了
剛剛注意到, 預設的Ram size只有256MB(小氣!!!), 所以就把它調大來試看看, 果然勉強可以動一下下 (我MBP只有2G RAM, 所以我設768MB給它用):
不過螢幕方向, 這實在很難看
Ctrl-F12 一下就可以不用擺頭看了, 但不管怎轉還是Portrait mode, 但還是Landscape比較有fu吧!
不過這只要去Settings->Screen 把Auto rotation關了就好, 這下有Landscape囉!
實在太慢了, 看不了幾項, Recent used application的呈現方式有WebOS的fu, 還不錯:
Browser….好熟悉呀…簡直就是Chrome嘛…
實機應該比較好(廢話)
Android上有個很煩人的就是(尤其是某公司的手機), 如果畫面上有可以輸入的框, 預設會focus在那上面, 某些手機(或說某些公司的手機), 預設變成只要那邊取得focus, 就會跳出軟體鍵盤, 這對很多User來說, 會有點煩(要看場合啦)…..
要在code裡面把SIP預先藏起來的話, 要用這段code:
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN);
Visual UI design的工具在很多平台跟語言其實都有, 當然有好有壞啦, Android ADT也是有的, 所以並不稀奇, 不過Android有的是更好用的 - hierarchyviewer
一般WYSIWYG UI editor著重的是在開發時期拉UI layout的部份, 但更進階的通常就沒著墨了, ADT上的UI builder並不是很強, 真正要能夠調出複雜而且是自己想要的UI光靠那個也並不容易, 還是得對一堆layout有相當程度的了解才能比較得心應手, hierarchyviewer是屬於更進一步的工具, 他可以檢查做出來的成品的UI layout (當然也可以想辦法偷人家的看 :P), 由於Android上的layout設計是階層式的, 所以可以攤成樹狀, 由hierarchyviewer就可以很明顯看出各layout從屬關係, 並且可以從screen shot部分的對應看出某一段layout成果的長像是如何
此外還有一些更強的功能, hierarchyviewer可以幫你把整個畫面輸出成PSD 檔(Photoshop的檔案), 這不是只是簡單的輸出平面的screenshot, 而是利用PSD檔可以有層次(layer), 把畫面上不同的元件分作為不同的layer疊起來, 這樣從Photoshop就可以一目了然的看出是不是有哪些沒秀出來的原因是被另一個蓋到的
個人覺得最棒的是那個紅綠燈, 設計不良的UI的效能自然是很差, 這個紅綠燈就是幫助你把效能不好的地方抓出來, 分作三部分, layout, measure, draw, 可以由這三部分分析去進一步改善整體UI的效能
今天晚上的GTUG請來了Tony Chan講GB的新features, 不過, 這些內容其實大部分都已經在Android網站上看過很多次了, 提起不了啥興趣, 雖然是對StorageManager有點興趣, 但卻不在這次講的內容, 可見這東西真的並不是個完成品, 不足以拿出來推
唯一讓我有點感興趣的是Google Analytics for Android, 所以回來的時候在車上稍微研究了一下
目前這東西, 說起來有點陽春, 把user行為的tracking定義成兩個分類 - pageview和event
pageview這觀念感覺就是從Web上來的, 但mobile application其實也沒啥page, 硬要分的話, 可以拿Activity來當做一個page吧, 不過有很多user interaction是在同一個Activity發生, 所以這分類應該是拿來應用在追蹤使用者使用某大功能的頻率
既然pageview不能夠表示in-activity的互動行為, 其實還可以拿"event"來用, 可以把button click, gesture之類的當做event來記錄分析
不過, 對於pageview和event其實沒有很明確的分野, developer可以在任何時候任何地方使用這兩者記錄, 並沒有特別強制性(比如說只能在activity用pageview或是pageview只能每個activity記錄一次之類的), 所以要胡搞也可以啦 (不過那就失去意義了)
比較恐怖的功能是可以允許developer自定變數, 如果把使用者個人資訊一起送上去, 就不妙囉
這整個功能上還稍嫌陽春, 如果要tracking使用者的使用流程, 這樣的東西並沒辦法做到
這部份有被問了幾個問題, 回來後我稍微查了一下:
1. 使用權限問題: 要不要使用者先同意收集才可以使用? 很不幸的, 這一點似乎是developer自由心證了, 並沒有任何強制步驟是使用者同意後才可以使用, 雖然使用這lib必須在manifest加上兩個uses-permission:
<uses-permission android:name=“android.permission.INTERNET” />
<uses-permission android:name=“android.permission.ACCESS_NETWORK_STATE” />
但這兩個, 一個是存取Internet, 一個是存取網路狀態的, 完全跟Privacy無關
2. Tony提到, 在沒有網路的時候會先keep在local的database等有網路時在上傳資料, 我當時提的問題是, 是否會有background service來做這件事, 還是AP launch之後才會真正去檢查網路並重送, 是只會有一個background service來做這件事? 還是每個AP獨立, 我會想到這問題有兩點, 第一點是資料庫問題, 如果每個AP負責自己的, 那每個AP會有各自獨立的資料庫, 而不會統一管理, 第二個是background processes數量問題
在會中時沒得到啥答案, 所以我只好自己簡單的追了一下, 基本上, 這設計沒我想的複雜, 簡單很多, 沒任何background service, 只有一個AnalysticsReceiver但看起來是來處理com.android.vending.INSTALL_REFERRER而非Connectivity change
所以這問題的答案就是, 它其實只是一個AP內的thread來處理而已(應該是NetworkDispatcher的dispatcherThread)
而且tacking code是存於各個AP的data目錄下一個叫google_analytics.db資料庫內, 所以只要取得這資料庫就可以取得了
整個設計上應該可以再加強, 尤其是保護User privacy這部份, 不然有可能被告吧? 我認為比較好一點的設計應該是在Market那隻AP裡面放個service來負責上傳analytics的資料, 只要提供API給AP去呼叫這隻service就好, 這樣第一步可以透過Android permission的機制先卡第一關, 而且可以比較容易統一設計一個end user agreement的dialog, 當AP第一次使用的時候跳出來取得user同意, 此外, 亦可以自動在網路狀態從無到有時自動把未送出的資料送出, 而非一定要AP正在使用的時候