iCould其實感覺好像還不錯, 雖然說Google有Google的Backup manager, 但像是自動拍照就自動備份到自己的stream這東西, 就沒有了

以雲端儲存來說, DropBox算是相當不錯了, 所以其實也可以利用它呀, 想到兩種方式:

Photo_11-6-11_9_58_55
Dropbox as a fake SD

Android很多功能, 像是相機, 沒了SD card就好像廢物一樣, 實在很討厭

如果把Dropbox功能implement成一個Fake SD card, 在有網路時自動掛載, 沒網路時卸載, 在沒SD卡時也可以把他當SD來用, 應該會蠻實用的吧

這應該可以透過FUSE, 改vold等方法來達成, 找到一個dropbox on fuse的implementation: Dropfuse 

不過這方法應該只是用於rooted rom或是自己build的rom

Auto backup to Dropbox

這方法應該是比較容易實現的, 利用Android上FileObserver來實做一個SD monitor (監視SD或是其他的external storage), 在有改變時就自動同步到dropbox去, 如Camera拍了張照片

FileObserver的使用方法很簡單, 如下:

這API不需要一個特定的thread一直去polling, 但由於這個instance如果被GC掉時, 就不會有任何event送達, 所以應該是要在一個Service內來實做這樣一個功能

有點寫(畫)上癮了

基本上, 越來越天馬行空了, 所以算是寫好玩的吧, 現在根本沒時間去做那麼多

新功能 - 問題發問: 

Photo_11-6-11_10_02_22
傳統簡報方式, 可能會碰到, 講到一半, 聽眾突然舉手發問, 有問題是很好, 不過這樣就稍稍會被中斷了

如果在簡報的同時, 螢幕上也同時顯示一個QR Code, 聽眾只要事先用手機掃描這QR Code並帶他到一個可以問問題的URL去, 聽眾在一面聽的過程可以透過手機發問問題, 在Q&A投影片時自動列出所有的問題

Photo_11-6-11_10_02_29
嗯, 這好像也不是很好的idea.. :P

自從看了Google I/O上Reto Meier用兩台Xoom做簡報, 就一直很想這樣做, 光靠手機和tablet做簡報, 而不是靠笨重的電腦, 上次去大陸出差, 用iPad+Keynote當場做投影片當場簡報, 這樣做還蠻爽的, 只是好像離我理想中(通常都過大)還差很遠, Reto Meier有說要放出Source, 但我等好久了….Source咧…. orz

今天跟人又討論起這東西, 回家路上, 順便把我想要的function design隨便塗鴉出來:

Photo_6_09_1_24_04_
我想要的是, 手機當remote control還可以看小抄, tablet負責投影還有錄音錄影(用後面的攝影機錄觀眾, 或是用前置攝影機錄自己), 還有錄投影片的timeline (以後可以合成教學影片)….最好是可以拿手機當雷射筆(不知道光靠內建的Sensor夠不夠當指向裝置)

哇哈哈…這聽起來好像好難…我好像太挑剔了… XD

最近為了想實現device 2 device的auto discovery/communication ,特別去研究了bonjour/mdns,今天跑去GTUG時,試著想利用mdns從我的mbp找我的手機時一直不成功,起初還以為我程式有問題,抓了封包,卻找不到mdns的封包,後來才發現到,原來我手機連上的wireless ap跟mbp連上的是不同一台,雖然同屬同一家咖啡廳,但卻是不同的subnet,當然就收不到multicast的封包

有了這樣一個經驗後,當下就開始思考(哈,台上講的我老早就沒認真聽了),利用multicast做這樣的應用到底實不實用,雖然說不管是mdns也好,還是upnp用的ssdp,都還蠻適合這類應用的,而且它們都是以udp multicast來實作,但對mobile device而言,特色是不會固定attach在同一個network,ip也隨時在變,利用multicast的方式大概只有在同一個wifi網路之下比較適用,要做真正 decentralized device 2 device discovery好像有點難度

因此後來我又轉往另一個想法,geographical peer to peer,剛剛想了幾個簡單的想法,先寫下來

Why peer 2 peer?

其實只是很單純的想讓在同一區域的mobile devices可以不用透過某一個central server來交換資料,或是通訊,甚至達到類似c2dm的功效,所以想是個可以處理peer 2 peer communication的service,支援的application只需要跟它註冊服務資訊,收到的request就以broadcast intent的方式交給相關服務處理。

大部分的P2P network像是BitTorrent, Napster, Gnutella, eDonkey, Tor都是為了分享而存在, 也有像是Skype是為了通訊, 由於我最初的想法是想達到zero configuration的通訊跟分享, 所以第一方面就往這方向的機制去想, 當然也不是為了做一個像BitTorrent這樣規模的東西

Why geographical?

最早的想法是local share, 也就是在同一個區域, 比如說同一個房間, 同一間會議室裡的mobile device之間的相互分享溝通, 所以最早想到的是Bonjour類型(基於mDNS), 不過如前述, 問題就存在於這些裝置未必在同一個sub net, 甚至是有些未必是用wifi, 也有可能是3G

想到的作法是: 借用BUMP的作法來建立一個虛擬的區域網路, 這"區域"是實際地理位置上的區域, 而非一般的LAN, 現在的mobile device, 大多都有定位系統, 取得地理位置資訊並不難, BUMP的作法是將地理相關的資訊例如IP, GPS座標等等資訊傳送到Server, 藉以判定是哪兩台做互碰的動作, 我想同一個原理應該可以用來協助建立一個地理上的local network, BUMP是用於兩台不同device之間, 但同一個原理也應該適用來建立一個這樣的network

How?

剛在回家路上把想法畫了一個簡單的架構圖

Cameraroll-1307545188
分為幾個步驟:
  1. Check in: Device用目前的位置資訊如IP, GPS座標等等向Registry註冊
  2. Seeding: Registry server利用device傳回來的位置資訊找出實際地理範圍內最近註冊的幾個裝置(時間也是必要元素), 並回傳給device
  3. Discover: Device根據回傳的seed名單, 一個個訪問所有的Seed, 並取得他們所支援的services, 以及他們的鄰居, 並持續這動作直到network到一定大小或是沒任何的新鄰居
  4. Connect and communicate: 建立服務連線並取用服務

這是一個大體上的架構, 應該還有很多細節, 比如說像是notification when join network等等

應用?

想到的應用像是file/data sharing, gaming network, data sync between different devices, chat room等等…

 

這只是一個簡單的想法而已, 還沒去想得很完整, 也還沒想到是不是有啥缺陷

Media_httpimagesinsta_gjbzs

Taken at 挪威森林