名前の変わってしまう LDR で今日もフィード消化してたら、ヤギの人が何か面白そげな事をしてらっしゃる。
スマートウォッチの類にはあまり食指が動いてなかったのだけど、この記事を見て「軽さ」「安さ」「開発し易そうな感じ」「電池持ちがいい」辺りが気になって注文してしまった。
ぐっとくるでしょ?
ぐっときたわ。
ハッカソンには距離的な問題もあって参加は出来なさそうだけど、開発コストが低そうなので せっかくだしちょっと触ってみようって気になるよね。
とりあえず注文前に開発でどんな事が出来るのかさらっとググったり本家見てみたので、さらっとまとめてみる。
自分に関係なさそう、興味なさそうな部分は飛ばしたので ここに書いてないから出来ないって訳でもないからね。
あと何か 実装してみた事じゃなくて調べた感じなので、捕捉が必要な所あったら指摘してほしい。
開発環境の準備が不要
一応 Mac, Windows, Linux 向けの開発環境は出ているんだけど、そっちはなんか準備が面倒くさそう。
で何で不要かっつーとクラウド環境が用意されていて、ブラウザ上での開発ができる。
ブラウザ上で開発っつーと、どっちかと言うと「えー」ってなる側の人間なのだが、何かゴテゴテのヘビーなもの開発するなともかく、元々出来る事に制限ある端末だから書くコード量なんて知れてるしええやんってなった。
本体届く前に登録して色々触れるのでちょっと弄ってみたけど、十分そうな感じ。
デプロイも楽そう。
言語は二種類、 C か JavaScript
C で書くか JavaScript で書くか の二択。
って話しだったんだけど、JS の方はそれ用のエミュレータアプリ上で走らせるってスタイルだった。
dropbox とか github やら http アクセス可能な空間にソース置くだけで利用できる気軽さがあるし、ハードウェア的な部分も一通り API が用意されてて 簡単なもの作るには十分そう。
元々使われてたっぽい Simply.js ってのは、描画周りはほぼ何も触れない感じで、「title,subtitle,body」の3サイズの文字が表示できるだけなんだけど、
今サポートされてる、後継の Pebble.js ってのには、UI 周りの API が充実してるように見えるので色々弄れそうかな?
使えそうな記事を検索してみると、だいたい Simply.js のしかヒットしないので、最新のものを使うように気をつけたい。
JS は嫌だしネイティブで書きたいってのなら、C を選ぶ事になる。
リッチな言語に慣れた今になって C++ ですらなく C を書くのはちょっと辛いんだけど、これも開発規模とやる事の範囲考えたらそんなに辛くもないかな?
C+JS で組み込み JS 使って開発みたいなのも出来るみたいだけど、まだ詳しく見てない。
pebble のアーキテクチャ
図とか使って分かり易く解説してるサイトがあったらいいんだけど、それっぽいのが見当たらない。
あまり組み込み系の環境触った事ないので、そーゆー方面として当たり前だったりするのかもだけど、とりあえず今は WEB しかやってない人間としてトピックになりそうな部分を洗ってみた。
シングルウィンドウのスタック型
pebble では1画面に表示されているウィンドウは1つだけ。
新しいウィンドウを開くとどんどんスタックされていき、常に最上位のウィンドウだけが表示される。
ポップすれば前画面に戻る。
公式で示されている pebble のナビゲーションモデルとしては水平スタックとの事なので、ちょっと WP のアプリ開発を彷彿とさせる。
各シーンで描画対象となるウィンドウは1つで済むし、WEB サイトの遷移のような形になるので、WEB 屋が考え易い実装になってると思う。
(配置済みのウィンドウをリソースとして持てないんだろうか?)
ハンドラーに登録していくイベントドリブンな実装
基本的にクリックや通知などのイベントに対して対応する、イベントドリブンな実装になっている。
昔 C 言語で Windows ソフトを作成していた頃は、プロシージャに投げこんで switch-case でイベント処理したものだけど、pebble はちゃんとモダンな実装になっているので、イベントループになる部分は。
int main(void) { app_event_loop(); }
といった風に専用のメソッドを呼べば処理してくれる。
我々は window_single_click_subscribe,
window_load といったメソッドを呼出して、ハンドラーとなるメソッドを登録するだけでいい。
あれ、ほぼ WEB じゃね?
もちろんこれはイベントドリブンなアプリを作る為に提供されている構造なので、ゲームとかリアルタイム処理をするアプリを作りたかったら、ループ部分は自分で書かないといけなさそう。
UI オブジェクトは全てレイヤー上に配置される入れ子構造
ここがちょっと面倒くさい。
基本的に全てのUIオブジェクトは TextLayer だとか MenuLayer だとか BitmapLayer だとか、レイヤーに所属している。
このレイヤーは階層構造になっていて、共通のroot レイヤーを持つ一群の木みたいな形になる。
これらのレイヤーはイラストレーターソフトなどで使われる重なった全体を覆う面というわけではなく、レイヤー1つ1つが矩形のサイズを持っている。
そして、子レイヤー上のオブジェクトは親レイヤーからはみ出して描画する事は出来ず、もし親レイヤーよりも広く描画していた場合はクリッピングされて表示される。
時には階層構造からはみ出して配置・描画される WEB とは違った所なのでちょっと理解しづらいが、MDI型のウィンドウ構造と同じだと考えると良さそう。
このような構造になっている利点は、再レンダリングの処理にあるのかな?
無駄な部分を再描画しない為に、レイヤー単位で再レンダリングを行なうかを明示できる。(汚れをマークできる)
layer_mark_dirty(custom_text_layer->layer);
マークせずに再描画を行なうと既存画面がそのまま表示され、マークしていれば マークしたレイヤーより下層の範囲だけを再レンダリングしてから描画できるので無駄を省けるのだろう。
( E-Ink だから書き換え行なう必要がある場所を絞るようにこうなってんのかもだけど、ハードに絡む再描画の要/不要はメモリ比較して勝手にやってくれや と思うが、E-Inkがどんな構造になってるのかよくわからんしなぁ...)
効率的な描画ができるようにか、アニメーションを描画する為の手段とかも提供されているので、モノクロ低解像度とはいえ色々表現できる幅は広そう。
おわりに
とりあえずさらっと読んで気になったのはこんな感じ。
届くのが楽しみです。
ハッカソンまでまだ3週間あるし、注文すれば3~5日くらいで届くみたいだから、とりあえず気になった人はポチって参加してみればいいんじゃないかな。
しかし何か作るのが楽しそうな端末ではあるんだけど、あまり手首にある端末で出来ると楽しい事があまり浮かばなくて、未知のものに対する想像力が足りてない...
なんか複雑な操作を手首に持ってきて長々と操作するんだったら端末出しちゃうし、ほんとに簡単な事をしたい時に端末出さなくていい ってメリットを活かす為には何をアプリ化するのがいいんだろうなぁ。
まぁ既に提供されてるアプリストアのものを触りながら、自分にとってあると便利そうなものを考えていくかなぁ。
コメントする