前兩天心血來潮寫了一個小東西－ASCII Art 產生器（下載）。顧名思義，這個小東西就只有那麼一個功能－把圖片檔案轉換成以文字構成的 ASCII Art。
照理說應該 10.4 以上的麥金塔電腦就可以用（不過我現在手邊沒有安裝 10.4 的機器，所以我只能保證在 10.5 與 10.6 可以用）；程式碼都在 Github 上，如果想要自行編譯，您需要安裝 Xcode 3.0 以上版本（不過我現在用的不是 3.0，用的是 3.1.4…反正去找最新的 Xcode 來用就對了。）
要寫一套 iPhone 軟體，難免會在軟體中用到網路功能－畢竟 iPhone 就是一台讓你帶著走隨時隨地都可以連上網路的裝置；而既然在軟體中會用到網路，就必定需要檢查目前的網路狀態，在沒有網路連線的狀況下，至少要告訴使用者裝置有沒有連線之類的。
要檢查網路連線狀態似乎很簡單：反正總是要發個連線 request 到我們要連線的地方，有回應就是網路連得上，沒回應就是連不上嘛。
不過，因為蘋果一些貼心的考量，就把事情弄得有些複雜。蘋果說，你不但要檢查有沒有網路，你還要檢查使用者目前使用的是哪種－Wifi 無線網路或是 3G/EDGE 等電信商網路，如果你的軟體的功能是傳輸大量的檔案－比方說讓人家一個按鈕就下載幾十 MB 的音樂檔案之類的－就要提示使用者，如果使用電信商網路傳輸這麼多檔案，很可能月底電話費會暴增之類，最好還要做個什麼偏好設定，讓使用者決定要不要開啟電信商網路…云云。
從各種大眾媒體或是網路上，你看到了一些關於 iPhone 軟體產業的報導，你讀到許許多多透過 iPhone 軟體發了橫財賺進好幾百萬美元的消息，尤其是，這些讓人日進斗金的軟體，都是所謂的一元軟體－就算軟體功能多簡單，但是因為點子夠新穎，加上價格低廉，足以構成衝動性的消費，把卡就這麼刷了下去也沒有感覺，不管軟體售價多便宜，只要乘上個驚人的購買量，一樣是一筆可觀的收入。
於是你躍躍欲試，你看好這個平台，準備一展身手。你心想，既然是一元軟體，想來不需要什麼開發成本，至於銷售，只要能夠在 App Store 上上架，接下來蘋果就會搞定一切，幫你跟全世界收款，你只需要每個月等報表數字跟匯款。然後你開始打探有誰會寫 iPhone 程式，尋找廉價的外包，只要找齊了人，馬上將你想要做的一元程式付諸實現，接下來便水到渠成。
不過，抱歉，你這麼想，所有已經會寫 iPhone 程式的人，也全都這麼想。
如果想要在網頁中插入開啟新的瀏覽器視窗的語法，有兩種簡單的作法，一種是直接在連結語法中加入 target=”_blank”，例如 <a href="http://zonble.net/" target="_blank">，另外一種方法則是呼叫 Javascript 的 window.open() 函式。
而雖然這兩者的目的是開啟新的瀏覽器視窗，但是在當你在寫一個使用了 WebKit 的 Cocoa 應用程式的時候，對於這兩個事件，則需要分別給予不同的實作－在 WebView 物件中觸發前者時，WebView 會去呼叫 Policy Delegate 的 webView:decidePolicyForNewWindowAction:request:newFrameName:decisionListener: 這個 Method，但是後者－Javascript 的 window.open()－則會跳過 Policy Delegate，直接向 UI Delegate 呼叫 webView:createWebViewWithRequest:。
意思就是，在使用者在你的應用程式中的 WebView 中，點選了一個包含 target=”_black” 的連結的時候，WebView 首先會詢問你所指定的 Delegate Object，然後你可以根據狀況判斷，而做出對應的處理－應該開新視窗、開新的瀏覽器分頁（如果你寫的是一套具備分頁功能的瀏覽器應用程式）、或是使用系統預設的瀏覽器開啟。
但是遇到 window.open() 則不然，這個狀況是－事件發生的 WebView 已經決定要因此產生新的 WebView 物件，你需要在 webView:createWebViewWithRequest: 的實作中，回傳一個 WebView 物件，而這個 WebView 物件就會開始載入 window.open() 所傳入的、那個要開啟的 URL。而我們會在這個地方遇到一個問題－基本上我覺得應該算是蘋果的 Bug－在 webView:createWebViewWithRequest: method 中所傳入的那個 NSURLRequest 物件，居然是 NULL！
在蘋果宣布的 iPhone 3.0 的一堆功能中，In-App Commerce 可說是影響軟體交易模式最大的一項－簡單來說，目前想要（用官方管道）取得應用程式，就是透過 iTunes 或是 iPhone 上的 AppStore 軟體，在軟體商店中瀏覽，如果看說明覺得滿意，就輸入密碼刷卡下載；而加入了 In-App Commerce 之後，接下來在一套軟體中，還可以針對某一項另外收費。蘋果自己展示的用途，是接下來 iPhone 版本的《模擬市民》遊戲中，可以針對某項特殊的虛擬寶物收費（聽起來就像是之前 Idol Master在幹的事情）。
一年多前我寫了一個小工具，叫做 colorBy.colorPicker，這個工具的目的在於解決在開發 Cocoa 應用程式的時候，撰寫跟色彩有關的程式的麻煩－比方說，當你需要一個 NSColor 物件的時候，你都必須要花點時間，把你看到的一組顏色，換算成對應到 HSBA 或 RGBA 的小數。不過，今天回頭看這個程式，在設計上有幾個問題－
一、在這個程式寫出來到現在，這段時間裡，Mac Developer 又多了一種跟色彩有關的物件要處理，叫做 UIColor，因為 UIKit 出來了嘛…。
二、原本的程式是寫成 Mac OS X 的系統 Color Picker，之所以寫成 Color Picker，原本是以為這樣就可以在各種文書編輯軟體裡頭－BBEdit 啦、TextMate 啦還是 SubEthaEdit，都可以叫出這個工具，因為大概只有 Color Picker 與輸入法可以算是平台上所有應用程式都可以用的外掛工具（plugin）。
但經過一年多再回來看，這種考量其實完全沒有必要，所有的開發工作往往都是在 Xcode 完成，而麻煩的地方就在，Xcode 裡頭實在找不到什麼地方可以把系統 Color Picker 叫出來。
因為這兩個原因，前兩天決定把這個工具整個重寫一次。新版的名稱叫做 Bunt，專案放在 GitHub 上：http://wiki.github.com/zonble/bunt，您可以直接取得程式碼自行編譯。簡單來說，差別在於－
一、Bunt 現在是獨立的 Cocoa 應用程式，而不再是系統 Color Picker，在啟動之後，就會出現在畫面右上角，需要的時候，用切換應用程式的方式切換過去就可以了。
二、除了原本就支援的 NSColor、Quartz Drawing 的 ColorRef 外，加入了產生 UIColor 與 OpenGL 的顏色的功能。
歡迎取用。