Instagram是一個我一直蠻喜歡的service, 主要是簡單, 加上有一些濾鏡可以豐富我隨手拍的照片, 當然, 重要的是, 高價賣給了Facebook而一炮而紅

上星期, 參加了AT&T Palo Alto Hackthon, 拿到大獎的團隊用了一個lib叫 caman.js 的, 這東西讓我有點小小驚艷, 它光用javascript (其實是Coffee script)就實作出了許多影像處理的功能, 這讓我興起想用這個來試著做出類似Instagram的東西, 當然是純用HTML+Javascript

首先面臨的一個問題是, 實作Camera的部份, HTML5支援media capture的方式有三種(請參考Reference 3) : Input tag, device tag, WebRTC (getUserMedia)

但很不幸, 除了Input tag以外, 大部分手機上的browser,如Android browser, Firefox, Chrome, 可以說幾乎全部都不支援, 這可真是有點令人傷心的消息, 因為用Input tag, 會離開browser跳到另一個程式, 這樣就無法結合自己的UI了

不過, 其實也沒那麼絕望, Android上的Opera Mini, 就支援getUserMedia (參考Reference 1)

因此就可以實作出像這樣的東西:

WebRTC(getUserMedia)的原理是把media stream導到video tag去播放(理應就這樣做), 但這樣出來的比例是camera的比例, Instagram的照片都是方形的, 要實現這點, 其實也不難, 就另外把內容畫到另一個方形canvas, 在video play的時候開始每隔40ms畫一次, 把video畫到canvas的方式也不難, 就把他當image看待就行了

不過當第一次使用時, 瀏覽器會跳出詢問是否允許使用相機的對話窗:

因為偷懶, 拍照的部份沒沿用原本的canvas, 另起一個Canvas, 並把可用的濾鏡放在下面:

接下來就是神奇的CamanJS的工作了, CamanJS是一個以CoffeeScript實作出來的影像處理的lib, 還真的蠻厲害的, 害我都有點想研究一下CoffeeScript了

使用方式非常的簡單, 像以下面的程式:

Caman(“path/to/image.jpg”, “#canvas-id”, function () {

    // manipulate image here

    this.brightness(5).render();

});

就可以提高影像的亮度了,

此外還有許多預設的濾鏡, 我也偷懶直接採用, 這就是做出來的效果:

Source codes分享於此: https://github.com/julianshen/instagramlikecam

References: 

1. http://dev.opera.com/articles/view/playing-with-html5-video-and-getusermedia-support/
2. http://people.opera.com/danield/webapps/instant-camera/
3. http://www.html5rocks.com/en/tutorials/getusermedia/intro/
4. http://camanjs.com/

B2G並未一定要開發者把應用程式發表到一個特別的app store, 網站也可以自行加一個install按鍵, 讓使用者把你的網站當應用程式裝到手機內

首先, 你必須要先有個manifest, 目前manifest並沒強制的檔名, 但文件裡建議叫 xxxx.webapp, 以下是範例內容:

{ "name": "MyTestApp", "description": "test app", "launch_path": "/", "icons": { "128": "/img/icon.png" }, "developer": { "name": "Julian Shen" } }

 

然後在網頁內加上檢查是否安裝, 以及安裝的程式碼, 範例如下:

var manifestUrl = 'http://localhost:3000/manifest.webapp'; var app = navigator.mozApps;  function checkInstalled() { var request = app.getSelf(); request.onsuccess = function() { if(request.result) { //installed console.log('installed'); document.getElementById('installmsg').style.display='none'; } else { //not installed console.log('not installed'); } }; }  function install(cb) { var request = app.install(manifestUrl); request.onsuccess = function() { alert('installed'); };  request. function() { alert('Not installed'); } }

這邊要注意的是manifestUrl必須是full path而不是只有相對位置, 寫相對位置, 它還是讀的到, 但會出parse error, 之前害我搞半天一直以為是格式問題, trace了一下Webapps.js, 發現可能是判斷install origin有問題

目前安裝介面很醜:

安裝完就可以在Home screen看到它的存在了:

看來script injection也不算是啥旁門左道了, 在Android 4.0 ICS上的WebView也使用了同樣的技巧了(在Gingerbread上並未看到這樣的codes)

在ICS的Setting裡面"Accessiblity"裡有個設定叫"Install web script", 其實這東西應該沒使用者看的懂, 其實蠻怪的, 不過既然放了就有它的作用

ICS的WebView裡面有這樣一段codes:

int axsParameterValue = getAxsUrlParameterValue(url);

        if (axsParameterValue == ACCESSIBILITY_SCRIPT_INJECTION_UNDEFINED) {

            boolean onDeviceScriptInjectionEnabled = (Settings.Secure.getInt(mContext

                    .getContentResolver(), Settings.Secure.ACCESSIBILITY_SCRIPT_INJECTION, 0) == 1);

            if (onDeviceScriptInjectionEnabled) {

                ensureAccessibilityScriptInjectorInstance(false);

                // neither script injected nor script injection opted out => we inject

                loadUrl(ACCESSIBILITY_SCRIPT_CHOOSER_JAVASCRIPT);

                // TODO: Set this flag after successfull script injection. Maybe upon injection

                // the chooser should update the meta tag and we check it to declare success

                mAccessibilityScriptInjected = true;

            } else {

                // injection disabled so we fallback to the basic built-in support

                ensureAccessibilityScriptInjectorInstance(true);

            }

        } else if (axsParameterValue == ACCESSIBILITY_SCRIPT_INJECTION_OPTED_OUT) {

            // injection opted out so we fallback to the basic buil-in support

            ensureAccessibilityScriptInjectorInstance(true);

        } else if (axsParameterValue == ACCESSIBILITY_SCRIPT_INJECTION_PROVIDED) {

            ensureAccessibilityScriptInjectorInstance(false);

            // the URL provides accessibility but we still need to add our generic script

            loadUrl(ACCESSIBILITY_SCRIPT_CHOOSER_JAVASCRIPT);

        } else {

            Log.e(LOGTAG, “Unknown URL value for the "axs" URL parameter: ” + axsParameterValue);

        }

 loadUrl(ACCESSIBILITY_SCRIPT_CHOOSER_JAVASCRIPT);

這邊並不是強制去載入一個新的URL, 其實他做的就是script injection, ACCESSIBILITY_SCRIPT_CHOOSER_JAVASCRIPT的內容就是:

    // JavaScript to inject the script chooser which will

    // pick the right script for the current URL

    private static final String ACCESSIBILITY_SCRIPT_CHOOSER_JAVASCRIPT =

        “javascript:(function() {” +

        “    var chooser = document.createElement(‘script’);” +

        “    chooser.type = 'text/javascript’;” +

        “    chooser.src = 'https://ssl.gstatic.com/accessibility/javascript/android/AndroidScriptChooser.user.js’;” +

        “    document.getElementsByTagName('head’)[0].appendChild(chooser);” +

        “  })();”;

它就是在最後把https://ssl.gstatic.com/accessibility/javascript/android/AndroidScriptChooser.user.js給inject到page

還沒去仔細看js裡面的內容, 似乎都是一些基本的東西的樣子, 還不太知道他的用意, 不過應該跟加速(?) Google本身的頁面有關係, 不然其他web site應該也沒用到這些東西

上次寫了一篇"startActivityForResult and callback in WebView“, 本篇則是上次這篇的延伸應用, 這是有人問我如何inject一整個javascript file到一個web page內(剛剛回顧了一下自己這篇, 發現我把它叫做javascript injection)

其實原理是一樣的, 在載入完原本的web page之後, 一樣透過URL來插入script:

mWebView.loadUrl("javascript:var js = document.createElement(‘script’);js.type = 'text/javascript’;js.src = ’http://my_host/1.js’;document.getElementsByTagName('head’)[0].appendChild(js);”);

一樣是透過“javascript:”來inject, 不一樣的只是, 這次我要插入的是一整個js檔, 所以這串javascript的目的就是要建立一個新的script element, 並將它插入head裡, 這樣任務就達成了

但這方法的缺點是, 來源必須是一個url, 也就是要把script file放在server才可以, 如果script是來自應用程式本身, 比如說放在應用程式apk裡面, 或是放在data partition就不行了

在Honeycomb之前的版本, 我還沒想到一個比較好的解法, 但Honeycomb (API level 11, 含11)之後就有一個比較簡單的解法了

作法就是overwrite WebViewClient的shouldInterceptRequest,這似乎就是為了類似的用途而生的呀~~

這邊我將來自於apk asset目錄裡的檔案的url定義成"asset://“, 因此, 想當然耳, 要導向的url就是這種, 作法也很簡單, 將asset的input stream包裝成WebResourceResponse就可以了, 這樣只要"js.src="後面的url是"asset://xxx.js”, 這js的來源就是apk裡的asset

缺點是, 這方法只適用API level 11之後

延伸應用? 其實應該可以利用這個API做出一個lightweight版本的client side serlvet (這樣叫好像也不是很貼切, 反正就是不需要透過http去存取), 不過因為資訊只有url可以使用, 因此不能implement “POST”…

題外話, 這個我是在Ice cream sandwich的emulator上測試的, 不過真的要小抱怨一下, 開個emulator要開很久, 看篇漫畫結束後還沒跑完, 如果叫developer完全用emulator開發, 真的會抓狂吧….這樣開發者的開發意願也會降低吧…. = =“

JQuery mobile跟Sencha touch都是蠻完整的mobile web framework, 兩者各有擅長, 比較起來以開發的角度我比較喜歡JQuery所標榜的"Write less, Do more"的哲學下的架構, 而不喜歡Sencha touch把一堆html寫到code裡面去, 但Sencha touch又有比較好的UI look and feel

以tab panel為例,

Sencha touch:

這兩個作法大異其趣 

Sencha 的HTML 內容

裡面除了script以外根本就是空的, UI的創建放在app.js(以這範例而言)裡如下:

https://gist.github.com/1301828.js?file=gistfile1

Tabs的內容在哪? items裡分別就是兩個tab, html直接以字串的形態寫在裡面, 老實說, 我覺得這很醜, 也容易出問題, 如果頁面的內容是相當複雜的, 這樣並不是很好

再看看jQuery Mobile的作法:

這份source code有點偷懶, 剪剪貼貼過來的, 不過其實就這麼一個html, 並不需要寫額外的javascript code, 乾淨多了  

如果也可以用類似的寫法寫Sencha touch的UI似乎應該會比較好一點, 像是這樣寫:

做了個實驗, 剛寫下這段code把上面那段轉成跟第一個範例一樣的畫面:

https://gist.github.com/1301855.js?file=gistfile1

看來如果再多層包裝其實也不用醜醜的通通把UI hard code到js codes裡面去