Porting JetQRCode from Jetpack to Google Chrome

(將 Jetpack 套件移植到 Google Chrome — JetQRCode 篇, 點我直接看中文版)

As you may know, Google Chrome browser announced their extension gallery a few days ago. The Google Technology User Group in Taipei hosted a Chrome Hackathon today, I was there and did something insteresting: porting extension between Google Chrome and Jetpack. MozTW is all for "open" (standards, source…) and not for a single product, at least that's the way I doing things.

So here it is, JetQRCode for Google Chrome 0.4, a demo about porting Mozilla Labs Jetpack scripts to Google Chrome.

I've learned a few about the difference between the two:

1. You have to break everything in Jetpack script, which is in a single file, to several parts, like manifest.json, content_script.js / background.html, options.html, to make things work in Google Chrome.
2. Jetpack is highly related to jQuery. To make life easier, you may want to insert jQuery as content script.
3. HttpRequest to different domain is not allowed in content script, do it in background html, and pass the result to content if needed.
4. You have to create a HTML page for user to set preferences, and storage the values in LocalStorage. (But you can't get the setting values in content script, pass them from background html if needed.) Also, there's only one data type in LocalStorage: string. Be careful if you're trying to use boolean or integer in it.
5. There's no APIs for context menu in Google Chrome yet, you might need to do the same behaviors in different way.

IMO, since Jetpack is still in early stage, extension APIs in Google Chrome is more complete (though more complex) in many way than Jetpack. Porting things between the two framework is not as easy as I thought before, and need creativity to conquer the difference.

If you are a not-so-good web developer like me, I think Jetpack is easiar to create extensions to solve problems in daily life. But anyway, creating an extension in either Google Chrome or Jetpack is much simpler then in Firefox (without Jetpack), which results more productivity.

(To correct my poor English, drop me a line with patches, thank you. :)

---

因為我懶得把一樣的話重寫一次了，所以這篇的中英文版大概只有重點一樣、內文會差很多 XD

我原先以為讓 Jetpack 與 Google Chrome 互通套件不算很難，但今天參加 Taipei GTUG 的 Google Chrome Hackathon 時實作一下稍稍有點改觀 —— 的確不難，但是有些東西是比想像中麻煩些。所幸最後仍有斬獲，所以各位親愛的 Google Chrome 使用者、這裡是 JetQRCode for Google Chrome！

拜雙方都遵循網頁標準所賜，其實原理跟很大一部份的程式碼依然相同 (是說我大多都用 jQuery 就是了… 懶惰鬼！)。有些經驗我想還是蠻值得跟大家分享一下，但中文版我想首先講結論：結論是…

1. Jetpack 真的比較好寫 (XD)，對於像我這種沒有很精的人來說可以輕鬆愉快地達到效果，相對來說 Google Chrome extension 就要考慮比較多架構上的問題 —— 或許是因為得拆成數個檔案吧？有些事情要在哪裡做，得先就權限等問題考量一下。
2. 無論你喜歡哪個，兩個都比原來 Firefox 的套件實作方式輕鬆許多，當然也大勝 Internet Explorer。 (Opera 跟 Safari 沒研究)

好，那麼柏強在這次的遊戲中學到什麼呢？

1. Google Chrome 的套件，要完成一件事情就算程式碼再簡單也會需要兩個以上的檔案，例如 manifest.json、content_script.js / background.html、options.html 啥的，所以單一檔案的 Jetpack 要移植過去就要好好想一下該怎麼拆程式。
2. Jetpack 內建 jQuery，很多事情也跟 jQuery 息息相關，所以移植到 Chrome 時、方便起見先把 jQuery 塞進 content script 比較好。
3. 在 Google Chrome 的 content script 裡不能做跨網域 HttpRequest，不過background html 沒問題，所以如果需要的話就在背景做、然後把資訊傳到內容去。
4. 兩者設計哲學中大不同的地方之一是偏好設定，在 Google Chrome 裡你必須自己寫整個 Option 頁面，也要自己把設定值存進 LocalStorage —— 相對自由當然也相對麻煩 (而且從 content page 裡目前還沒辦法直接拿設定值喔！記得從 background html 裡傳。) 這邊我撞到的其中一堵牆是對 LocalStorage 不熟，不知道它什麼都是用字串存，如果要用布林值還是數字的麻煩注意一下。
5. 目前 Google Chrome 裡還沒有調整快捷選單的 API，所以有些效果可能要重新想想使用者可以運用的方法。

以上心得供大家參考，也希望網頁設計師們都可以來玩玩看這兩種比較簡單的套件寫作方式，發揮創意製作出一些好玩的套件。日後有機會再來試試把 Google Chrome 的套件移植回 Jetpack…