SmartTrainingでPebble対応してみました

はじめに

去年Kickstarterで勢いのあったPebble。即Backerになりました。
発売されたのは2013年1月くらいでしたが、なんだかんだで発送が遅れて入手できたのが2013年5月。とりあえず使ってみて、今まで使ってきたLiveViewやSmartWatch MN2と違った面でイイ感じだったのでSmartTraining対応してみました。

Androidアプリ
WatchApp


忘れても思い出せるようにメモしときます。

ユーザ的観点


抜群のバッテリーの持ちの良さ

今まで使ってきたsmart watchに比べると電池の持ち時間が圧倒的に長いです。
LiveViewとかMN2だと静かになるべく使わないようにしてギリ二日とかだったのが、PebbleだとGmailの通知1日50件くらい発行しても1週間経ってようやくバッテリー警告が出る感じ。警告出てから1日経っても干上がりませんでした。その後は試してないですが。とにかくバッテリー面の運用が楽です。

実用的な液晶

IS03に使われていたメモリ液晶と似たような雰囲気です。白黒しか表現できません。パッと見地味ですが、明るい場所で全く見えないMN2と比べると、直射日光下でもちゃんと見えるので実用的です。暗い場所ではバックライトONで見えるようになります。

不快なリストバンド

他のsmart watchと同様、通気性ゼロのゴム性のバンドです。梅雨時期に付けていると不快感100%です。しかも交換は不可。なんでこういうバンドにしちゃうんでしょうね。まぁ、耐久性は抜群なんだと思いますが。きっとHQのあるカリフォルニアの気候だとこういうバンドでも問題ないんでしょうね。

文字化けするビルトインアプリケーション

Phoneからの通知は全体的に豆腐に文字化けします。あとたまに生HTMLが表示されたりします。日本語を含むGmail通知はまともに読めた試しがありません。

開発者的観点


C言語

C言語（C++ではなく）にPebble独自のフレームワークを乗せた感じです。フレームワーク自体はサンプルが少ないながらもリファレンスは充実しているので使いやすいと感じました。また、標準的なC言語ライブラリが全て利用できるわけではありません。例えばmalloc、free、sprintf、mutexなどいくつかの機能が削られています。まぁ、利用可能なリソースが限られているので、シンプルに、軽いフットプリントで動くものを作れ、ということなんだと思います。

効率の悪い開発環境

開発環境はわりと貧弱です。エミュレータ/シミュレータがないため、実行するにはBluetooth経由で実機にアプリを転送後、実行する必要があります。開発環境に直接接続してブレークポイントを張ってデバッグといった贅沢なことはできません。また標準出力も利用できないので、私はデバッグログの代わりにバイブレート関数を呼んでバイブのパターンで期待する条件を通っているか確認しました。ちょっと複雑なものを作ろうと思うと大変そうです。
IDE的にはCloudPebble.netあたりを使うといい感じかもしれません。が、個人的にはやっぱりソースコードは手元に欲しかったので本格的には使いませんでした。


遅延のあるPhone〜Pebble間通信

Phone〜Pebble間の通信の遅延がわりとあります。かつ、遅延の大小が安定しません。数百ms〜数秒と結構バラバラです。リアルタイム性の高い通信をやろうと思ってもたぶん実現できません。送受信するデータサイズを小さくすると若干改善します。あと、予め用意した通信バッファを超えるとアプリが落ちます。頻繁（1秒間隔とか）に通信させるのは現実的ではないかもしれません。


悩ましいフォント

デフォルトで利用可能なフォントだと選択肢が少ないのでフリーのフォントを使ってみました。解像度が低いので、フォントによっては荒く見えてしまいます。とりあえず、SF square head condensedというフォントを使ってみましたが、満足はしていません。最終的にはフォント自作しかないかな、と考えています。

その他

書いたコードがどこで動くかがわかりやすいです。何を言いたいのかというと、NM2ではAndroid上で動くコードとSmartWatch上で動くコードがシームレスなため、書いたコードがどこで動くのかが判然としません。そのため、例えば何を書くと通信が使われ、結果的にバッテリーを消費するのかということを意識するのが難しいです。Pebbleだと、書いたコードはPebble上で動作し、通信するときはapp_message_out_send()する、といった感じで何をやったらバッテリー消費しやすいかの意識をしやすいため、より低消費電力なアプリケーションを作り易いのではないかと思います。

全体的に

今の技術レベルで無理をしていない実用的な良い製品だと思います。日本の夏を乗り越えられたら使えると思います。

ソースコード

初めて作ったコードなので質的にはどうかと思いますが、もっとPebbleが盛り上がってくれるといいなという期待を込めてソースコードを公開してみます。


コメント

コメントを投稿

このブログの人気の投稿

Execノードを使う

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はExecノードです。Execノードを使うと外部のコマンドを実行することができます。コマンドが出力した、標準出力や標準エラー出力などをノードから出力できます。 標準出力の内容を出力する 最初に確認するサンプルは「 flows > node-red > function > exec > 01 - Get standard output from external command 」です。 Execノードのプロパティを見ると以下の通りになっています。 実行コマンドは「 echo 」 msg.payload で受け取った値を引数として利用 出力モードは「 コマンド終了時 - execモード 」 コマンド終了時に結果を出力します Execノードには出力ポートが3つあります。 標準出力 標準エラー出力 返却コード 実行すると、標準出力には「 Hello World! 」、返却コードには「 {code : 0} 」が出力されます。この挙動は特に説明することはないかと思います。 標準エラー出力の内容を出力する 次に確認するサンプルは「 flows > node-red > function > exec > 02 - Get error output from external command 」です。外部コマンドのエラーをポートに出力します。中身は先程のサンプルフローとほぼ同じですが、Execノードで存在しないコマンドを実行しています。 実行すると、以下のログが出力されます。これも説明不要かと思います。 実行中に出力する 最後に確認するサンプルは「 flows > node-red > function > exec > 03 - Run external command in spawn mode 」です。出力がコマンド実行中に行われるのがこれまでのサンプルと違う点です。 コマンドはwhieループ内で2秒おきに「 Hello 」を標準出力に出力し続けます。Spawnモードで実行するとループ内でechoコマンドが実行されるたびにログが出力されます。サービスっぽい...
続きを読む

SendGridのX-SMTPAPIヘッダの使い方（Section Tags、Substitution Tags編）

イメージ
前回に引き続き SendGrid についてです。 今回は SMTP API を使ってみました。 SMTP APIについて SendGridのSMTP APIは基本的には普通のSMTPプロトコルに則ったものですが、X-SMTPAPIヘッダというカスタムヘッダを使うことで機能を拡張することができます。 X-SMTPAPIヘッダについて X-SMTPAPIヘッダはSMTPプロトコルの拡張ヘッダです。 X-SMTPAPI: { "category": "newuser" } みたいな感じでJSON形式でパラメータを与えることで機能を拡張します。 Section TagsとSubstitution Tagsについて 今回はSMTP APIで使える機能のうちSection TagsとSubstitution Tagsを使ってみました。 Section TagsとSubsitution Tagsは送信メールの内容を宛先毎に特定の文字列を置換するための機能です。toと合わせて使うことで機能します。 例えば、X-SMTPAPIヘッダの値を以下のような形にします。 { "to": ["test1@xxx.xxx", "test2@yyy.yyy"], "sub": { "-body-": [ "-bodyFemale-", "-bodyMale-" ], "-favorite-": [ "バナナ", "カツオ" ], " "-nickname-": [ "ミキ", "サブロー" ] }, "section": { " "-bodyFemale-": "-nickname-さん！女性向けの商品のご紹介です。", "-bodyMale": "-nickn...
続きを読む

Joinノードを使う（その4）

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はJoinノードの4回目です。終わらねぇ。 確認するサンプルは、 前回 に引き続き「 読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode 」です。 メッセージを結合してkey/valueオブジェクトにする 5段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。 DataノードでCSVデータを送信する CsvノードでCSVデータをJSONオブジェクトに変換する msg.payloadには以下のような値が指定されたメッセージ4つに分解される { name: "Apple", price: 100 } Changeノードでmsg.payload内の値を以下のプロパティに設定する msg.topic = "Apple"（msg.payload.nameの値） msg.payload = 100（msg.payload.priceの値） Joinノードで、2個の受信メッセージごとにmsg.topicの値をキーとしてkey/valueオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadにJSONオブジェクトが指定されていることを確認できます。 メッセージを結合して結合オブジェクトにする 先ほどは結合した値がkey/valueオブジェクトでしたが、6段目のフローでは単純にオブジェクト結合します。ざっくりとした流れは以下のとおりです。 DataノードでJSON配列を送信する nameをキーに持つオブジェクトとpriceをキーに持つオブジェクトを交互に含んでいます（実際、こんなに都合の良いデータが生成されることはあるんだろうか） Splitノードで配列データを個別のメッセージに分割します Joinノードで、2個の受信メッセージごとにオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadに2個ずつのオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。ちなみに、Joinノード...
続きを読む