今天家裡多了部 Electrolux UltraSliencer, 這是我們家第二部Electrolux的吸塵器, 前一支是手持立式的
本來先是去大遠百的專櫃看, 不過價錢比起老婆在網路上看到的還貴很多, 也沒附塵蟎吸頭, 加上專櫃小姐解釋半天, 我還是搞不懂, 三萬多的吸塵器跟一萬多的到底差哪裡, 買東西還是要買實用, 總不能說貴的就好
後來跑去老婆在網路上看到的, 竹北簡單生活館(在經國路上), 價位跟百貨公司的還差真多, 多了一支價值五千的塵蟎吸頭的價錢還跟百貨公司沒附的一樣價錢, 贈品還一堆, 老闆親切, 而且解說詳細, 讓我們覺得買這隻就很夠用了, 不過買到三萬多那麼頂級的, 加上這個是為了容易過敏的小遠, 這台就已經滿足該有的功能了(靜音, 吸力強, HEPA 12濾網)
先看看贈品:
塵蟎吸頭, 多送的HEPA 13濾網, 膳魔師保溫瓶, 集塵袋…還頗夠誠意的
外包裝盒
第一層
第二層, 本體出現
外觀 & 集塵袋
HEPA濾網
塵蟎吸頭
來張全身照
跟iRobot Roomba合拍一張吧!
聲音似乎好像還蠻小的, 跟一般吸塵器比起來, 比起Roomba似乎還安靜一點
Sencha Touch 2.0在OO的包裝上做的還算不錯, 把MVC的角色切分的還蠻清楚的, 以List為例, 大概就像這樣:
但如果是要用Facebook Java script SDK去存取Facebook Graph API這類, 似乎就不知道怎歸類了, 如果直接用JSONP去存取Graph API, 則碰到Authentication error.. orz
那…就只好寫一個Proxy了, 像這樣:
https://gist.github.com/1341345.js?file=gistfile1
以下是一個使用這範例存取使用者自己的Facebook Group的範例:
上次寫了一篇"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開發, 真的會抓狂吧….這樣開發者的開發意願也會降低吧…. = =“
Android 4.0 Ice Cream Sandwich 有一個新功能是, 使用者可以停用(Disable)系統上預載的應用程式, 以往系統預載的應用程式是不能被刪除的, 現在, 新的版本多了一個按鈕讓你可以停用它:
這是中國人所謂的…“眼不見為淨"嗎?
被Disable掉的應用程式基本上並沒被移除, 它還是在你手機裡面, 並不會因此多出一些可使用空間, 只是你看他不爽, 以後就可以不用再看到他了….(呃, 不爽用就不要用不就好了)
這是新功能嗎? 對這介面上來說…這按鈕…是新的
PackageManager裡面有個叫做setApplicationEnabledSetting , 這用途就是用來作這種事的, 所以做這樣一個功能到底多複雜呢?
PackageManager pm = getPackageManager(); pm.setApplicationEnabledSetting("com.geekyouup.paug.awesomepager”, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, 0);
就差不多上面那樣
當然啦, 是沒辦法隨便寫一個軟體去disable人家的應用程式的, 如果可以, 不就天下大亂了, 這API只能用在跟你的應用程式相同的uid的package
不過對於系統應用程式來說, 就沒這限制了吧
至於這API啥時有的? Since API level “1”
Ok, So…..
We got a new feature……….
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裡面去