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的效能

剛看了一下Mac App Store上的排名:

從前幾名看來, Productivity 分類是最熱門的, 所以這表示大部分的Mac都是拿來工作的? 不過其實Game也不少啦 :P

買這台的起因是老婆是想要買一台好一點的相機取代她現用的那台Panasonic F-100

本來中意的是Panasonic GF-2, 我本來用GF-1就用的還蠻滿意的, 所以對GF-2也就還蠻放心的, 但昨天去台北逛了一圈, GF-2還真是有夠的熱銷, 隨便跑任一家店都可以看到正在交GF-2的貨, 一問之下, 大多公司貨都要先預定, 水貨也不是太好買又沒保固, 好不容易問到一家"可能"有現貨, 考慮了一個多小時後又回去問, 一查, 當天進的貨馬上被訂走, 老闆幫我調半天還是不確定下週會不會有貨, 回到新竹, 到新竹Nova問, 有家店家就說, 預定的連第一批都還沒完全拿到, 現在訂已經是第三批了, 運氣不好的話可能要到三月才有貨拿 orz

後來在一家叫做北極光的(店員服務真不錯)看到GF-2紅色水貨跟Olympus E-PL2的紅色機(公司貨), 但因為GF-2水貨沒保固也沒比公司貨便宜多少(公司貨保三年), 加上E-PL2外型也還不醜啦(是沒GF-2有型, 但紅色的看起來也不錯, 白色的看起來就太糟糕了), 而且又是M4/3, 鏡頭可以跟我的GF-1共用, 價格又差不多, 所以最後就決定買這台, 過年出去玩還可以拿來用, 不用苦等GF-2

這一箱….包裝的還蠻樸實的, 我買的是E-PL2+14-42mm單鏡的組合

紅色的機身看起來還不錯看

正面:

背面

不像GF-2是採觸控的方式操作, 而是採傳統轉盤跟按鈕的方式, 或許習慣了, 我覺得這也還OK, 而且我也不覺得觸控會比較好用, 觸控的話有時需要單手操作的場合反而就不方便了

機身, 比GF-2略重, 但跟GF-1差不多(GF-2果然有進步), 體積也略大, 但這樣我反而覺得雙手持起來比較順手, 把手的設計也比較好拿, 不易滑手, 優於GF-1, GF-2

Olympus M Zuiko Digtal 14-42 F3.5-5.6 ED

這顆鏡頭, 相當相當的輕, 剛拿在手上時還有點不太敢相信, 這樣也讓它被裝到機身後整體重量並不會比GF-2+餅乾鏡重太多

整體上來看, 做工感覺有點廉價, 不過是kit, 應該也是成本導向吧, 口徑只有37mm, 居然比Panasonic kit跟餅乾鏡用的都還要來的小, 應該只有DV是用這size吧?!

至於表現上, 還沒真的實拍, 還不知道真的品質如何

以下是簡單的交叉比對

E-PL2 + 14-42mm (@14mm F3.5) JPEG

E-PL2 + Panasonic 20mm F1.7 (@F1.8) JPEG 

GF-1 + 14-42 (@14mm) RAW 

比較起來, Olympus色調偏暖, Panasonic則明顯偏冷, 差異還蠻明顯的, 但E-PL2明顯優於GF-1則是在高ISO的表現, GF-1我從不敢開超過ISO 800拍, 800之後就真的很慘了, 但上面這三張照片, 前兩張Olympus的是開1600, GF-1是800, Olympus在1600的表現似乎還比GF-1在800的表現還要乾淨, 據說GF-2的可用ISO也可以到1600, 不過不知道比較起來表現有沒這麼好

下次等真的有實拍的時候再來仔細比較好了

以前總想說, 用閃燈場合不太多, 而且想說打了燈, 打不好就變死白了, 就一直沒買閃燈, 想說光靠大光圈加高ISO可以撐一下就好, 不過直到今年尾牙, 拍回來的照片怎看都非常的不滿意:

實在是…有夠糟糕….後來動到內閃…唉… 拍的還是很爛

所以就想要買隻閃燈

Survey了好久, 本來考慮了Panasonic PE-36S, DMW-FL360, Olympus FL-36R, FL-50R, 以及本文主角 Nissin Di466

跟Ruey借了FL-36R和FL-50R, 本來很滿意FL-36R, 大小不會太過大(雖然略重), 支援TTL, 離閃, 而且可以上下左右擺頭, 的確蠻理想的, 但後來去查了價錢, 台灣賣的價錢根本就跟搶劫沒兩樣, 購物網站賣快12000, 但我到米國的阿馬龍查, 呃…折合台幣不到七千, 根本就只有半價, 而且東查西查, 好像還真不好買, 就打消這念頭, 至於他的兄弟FL360(明明就同一支), 價格合理點(好像也得八九千), 但也好像不好買

所以, 最後…跑了一趟台北….在新竹買了Nissin Di466… (呃, 那我幹嗎跑台北去問)

這隻因為跟老婆的E-PL2一起買的, 小殺了點價, 以3300買到, 但在台北問到的價格…居然想賣我4300…多貴一千!!!

支援TTL, 但如圖所見, 只能上下擺頭, 正常拿打跳燈應該還足夠:

有支援TTL應該比較方便, 不用手動調來調去, 不過對我來說大概很多時候還是得手動吧, 我大部分的鏡頭都是手動鏡呀, 不能左右擺頭是個缺點, 不過便宜啦, 可以接受

家裡沒充電電池, 拿金頂先來頂著吧…之後再來買…測試了幾張:

90度跳燈 (周圍是木頭, 所以打起來就偏暖一點囉):

直打

這麼近直打還蠻容易過曝的, 不過加個擴散片好一點, 不過還是得減一點點光比較正常一點

大體上還算滿意, 而且便宜, CP值算不差啦….

今天晚上的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正在使用的時候