ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

手のひらサイズ、少し未来のAndroid Botの作り方

Android

面白いOSSプロジェクトを見つけたので紹介します。コンセプトは手のひらに乗るBot。SiriやGoogle Nowのような対話型のインターフェイスを自分でも作れる面白さがあります。

Botとは

最近、hubotのようなBotが流行っていますが、Botはチャットを通じたメンションなどでコマンドを受け付け、コマンドの種類に応じた処理を実行して結果を返す単純な仕組みで動いています。

hubotに代表されるBotはプロダクトをビルドしたり、画像を探して来たりと簡単なお使いができるため、プロジェクトでもお馴染みの存在となりつつあります。

AndroidをBotにする"robota"プロジェクト

今回みつけたrobotaはhubotとは少し毛色が異なり、Androidシステム上にアプリやServiceとして動作する「手のひらに乗るBot」です。

ちょっとわかりにくいと思うので図にしてみました。

チャットを経由してAndroidと対話できるシステム


簡単にいうとIdobataというチャットシステムを経由してBot(Androidアプリケーションとして動作している)と対話が可能です。

echoしてみる

実際にチャットからみるとただのBotにしかみえません。Idobataからechoすると次の通り。

ちゃんと「私は羊だ」とechoが帰ってきてますね。いままではビルドサーバーなどでお守りをしていたBotがAndroidサイズに飛び出した、というわけです。

"robota"で何ができるの？

Android端末上でアプリケーションとして動作できるので、アプリで出来ることは何でも。今までのAndroidアプリの資産が沢山あるのでおおよそ思いつくことはすぐに実装できちゃいます。

  • 今の気温を確認する（端末のセンサを使ってもいいし、ADKでも）
    • 私の発言：@Nexus5 やぁ、ネクサス、今の気温は？
    • Botの返信：自宅の気温は 25度です。少々熱いですね
  • 部屋の写真を撮ってもらう（カメラを使って）
    • 私の発言：@Nexus5 ネクサス、飼っているインコの様子が知りたいな
    • Botの返信：少しお待ち下さい。良い表情が撮れるよう試してみますね
  • IR-Kitを使って。
    • 私の発言：@Nexus5 もうすぐ家に着くよ、エアコンをつけておいてくれないか？
    • Botの返信：わかりました。冷房を効かせておきます

監視系でもこれぐらいの用途はすぐに出てきます。自分の端末にBot住まわせておけばこんな使い方もできるでしょう。

  • お使いに
    • 友人の発言：@Nexus5 mhidakaにコーヒーを忘れないように買ってくきてほしい、と言づけてくれないか？
    • Botの返信：わかりました。通知バーに「コーヒーを買う」と固定しておきました。あとは神に祈りましょう。グーメン。

これなら買い忘れてもBotのせいにできるかも…？

robotaを触ろう。

robotaは本体とルール生成エンジンに分かれており、実装は非常に簡単です。なぜならIdobataとの通信や待ち受けなどルール部分以外はrobotaのcore部分が受け持っているため、開発者はルールを作ることに集中できるようになっているからです。

端末にインストールされたrobotaはIdobataのメンションを受けてブロードキャストを行います。自分が作ったアプリケーションで処理し、応答をrobotaに返信すると、Idobataへの投稿含めてrobotaが残りの処理を実施します。

もともとAndroidに備わったブロードキャストレシーバーを使ったわかりやすい実装と言えるでしょう。次はrobotaをインストールしてサンプルコードを動かすところまでを解説します。

インストール編

robotaのインストールはとても簡単ですが、いくつかUI上の注意点があります。順番に説明していきます。

robotaをインストールすると、電源ボタンが表示されます。初期状態はOFFなので、真っ暗です。

ちなみにタップするとすぐにONにできますが、Idobataとの連携が済んでないので、まだ意味がありません。OFFにもどして順番に作業しましょう。

Settingsを開くと、BotのToken追加と、インストール済みのルール、Aboutの3つがあります。

Botをタップしてひらいた画面ではIdobataで取得できるトークンを記入しましょう。ここは手打ち上等なのですが、エンジニアらしくコピペなりadb inputなりして手間を省いてください。

Settingsの"Installed engines"では、ルールがちゃんとインストールできているか確認できます（ただし権限の確認までは行われないため、後述するAndroidManifest.xmlに注意）。

IdobataでBotを追加する方法

Idobataでは部屋のROOM SETTINGSからBotを追加できます。設定画面内、Add Botを選択するとボットの作成画面に遷移します。

robota対応ルールの作り方[Hello! robota!]

ここからはrobotaに対応したアプリケーションの作り方を紹介します。メンションを受け取ったらどんなことにも"Hello!"と元気よく挨拶するルールを追加してみましょう。非常に簡単な構造ですので安心して読み進めてください。

Android Studioで依存関係を解消する

まずはrobotaを使うためのライブラリを選択します。Gradleで

  • compile "com.uphyca.robota:robota-engine-core:${robotaVersion}"

と設定してください。
例えばv0.9.1を指定するのであれば次の通りです。

dependencies {
    compile 'com.android.support:appcompat-v7:+'
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile "com.uphyca.robota:robota-engine-core:0.9.1"
}
HelloEngine.java

ルールを記述してみましょう。com.uphyca.robota.engine.EngineBaseクラスを継承してEngineを生成します。
このEngineBaseクラスはブロードキャストレシーバーが元になっており、Botとして利用可能な要素に加工した状態で引き渡してくれます。

public class HelloEngine extends EngineBase {

    @Override
    protected String onMessageReceived(Context context, Bot bot, TextMessage textMessage) {
       return "Hello!";
    }
}

botインスタンスにはBot情報が、textMassageインスタンスには発言者情報が格納されています。このHelloEngineでは、一切のメッセージを無視して"Hello!"と返信します。
シンプルですね。なお、発言者のメッセージを加工する方法はEngine-bundleのEchoEngineなどがわかりやすいです。

AndroidManifest.xml ブロードキャストレシーバーの登録

最後にブロードキャストレシーバーの登録です。このあたりは普通のAnroidアプリケーションと変わりません。インテントフィルター名が固有なので、ここだけ間違えないように注意してください。

    <uses-permission android:name="com.uphyca.robota.permission.RECEIVE_MESSAGE_CREATED"/>

    <application>
    ...省略...
        <receiver
            android:name="org.techbooster.sample.robota.helloworld.HelloEngine"
            android:label="@string/label_hello"
            android:description="@string/description_hello">
            <intent-filter>
                <action android:name="com.uphyca.robota.action.MESSAGE_CREATED"/>
            </intent-filter>
        </receiver>
    </application>

uses-permission要素を忘れるとブロードキャストレシーバーを受け取れません。


またlabelとdescriptionについてはCDATAセクションです。たとえば次のようにString.xmlに記述します。

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <string name="app_name">Robota</string>
    <string name="hello_world">Hello world!</string>
    <string name="action_settings">Settings</string>

    <string name="label_hello"><![CDATA[${bot_name} hello ]]></string>
    <string name="description_hello"><![CDATA[Reply back with hello]]></string>
</resources>
動作確認


great good! :)

Botの将来

hubotをみていて思ったことはビルドやプロジェクト管理に便利なのはもちろん、hubotとの会話を楽しめる、ということです。まるでチームに友人が増えたかのような賑やかな雰囲気に変わる、しかもhubotがビルドエラーしちゃったら「まぁしょうがないよね」と人ではなく「何がビルドエラーの原因か」という問題と向き合えるようになります。
たとえばデスマをしていれば人間同士ではミスを許しあうことも難しいかもしれません。「〜さんのコミットでビルドが壊れた！」なんて脳裏を過ると、精神衛生上良くありません。

今回紹介したrobotaのようなプロダクトはAndroidなど手のひらの機械に一種の人格を与えることができる、面白い試みだと思います。SiriやGoogle Nowなどを見てもわかるように、コンピュータにもサジェスト機能がどんどんと盛り込まれています（古くはiコンシェルのようなものもあるので発想自体が新しいわけではないでしょうが)。

手のひら大のコンピュータを自分に合ったかたちにカスタマイズする、という試みはコンピュータとの付き合い方を面白く変えるキッカケになりそうですね。

C86注目の技術書サークル一覧

Android

既存の情報からコミケ3日目(8/17)、同人ソフトでソフトウェア技術書という観点で注目のサークルをまとめました。抜け漏れありそうだけど自分用のメモ、ということで。随時追加していきますが、Twitterでメンションしてもらえればメンテします。

TechBoosterの参加告知（日曜日 西か46b）

サークル「TechBooster」もコミケに参加します。日曜日 西か46b に配置されました。
頒布予定は以下3冊を予定してます。搬入の都合上、部数は少な目な気がします。よろしくおねがいします。


  • Android初心者本(仮)
    • 教科書本。なベストプラクティス総まとめ的内容にしたいなー、できるかなー、というところです
  • FirefoxOS本(仮)
    • FirefoxOSの最新情報をまとめつつ、既存の本ではフォローアップできてない最新版でのアプリ作成方法など
  • Android上級者本(仮)
    • 書きたいことだけ書きました！的、面白本。多分、Android 5.0的ネタもこっち。興味あるなー、という分野を容赦なく紹介していきます。

の3冊です。まだ影も形もありません。中身、ゲスト等は完成後に告知しますので続報は https://webcatalog-free.circle.ms/Circle/11316947 や techbooster.org でお待ちください。

注目の技術書サークル

サークルチェックの結果を怒涛の勢いで紹介！（毎度のように店番なので買えないのが悲しい）。今回は技術島は1つではなく、西ホールの「か」「き」島に分散配置されてるっぽい。紹介は「か」の後ろからぐるっとまわって「き」まで一周する順番。発行部数は各サークルさまごと違うので、買えなかった！などの苦情は受け付けません。欲しければ並ぶのだ、勇者よ！

くずかごのーと / 日曜日 西か46a
JCROM Project / 日曜日 西か44a
つ部 / 日曜日 西か43b
Tech-orz / 日曜日 西か41b
Applest / 日曜日 西か38b
COMFRK / 日曜日 西き38b
アトリエのどか / 日曜日 西き33b
日本Androidの会Unity部 / 日曜日 西き28b
YUGA / 日曜日 西き27b
参照透明な海を守る会
Metro Girl / 日曜日 西き26b
glenda9 / 日曜日 西き20b
AliceSystem / 日曜日 西き20a
低級はっかーズ / 日曜日 西き10b

Google+アプリに新しいデザインが来たのでGoogle I/O 2014で発表される新Androidバージョンでのデザインガイドラインを推測する遊びをしてみた

Android

2014年5月23日、G+アプリに更新があるというので試してみたら既存のデザインガイドラインに無いロックな挙動をしていたので紹介します。

1か月後にはGoogle I/O 2014を控えているこの時期の更新、ということで新しいAndroidバージョンに取り込まれるのだろうなー、とか推測しながら挙動を書き留めました（私自身、すぐ慣れてしまうので忘れないように）。
先にまとめておくと次の通りです。

まとめ

  • カードUIに最適化した一例としてG+アプリをみると良い
  • ActionBarの機能拡張、ブランドカラーの強化
  • ListView(カードUI)の上部にメニューをだす形が流行りそう
  • いままでもGoogleは自らデザインガイドラインを破ってきたし、時代に合わせて新しいガイドラインに更新している

今回に限らず、Google製アプリでは、アプリごと思想が微妙に違ってるケースがあります。Google+とGmail、Googleドライブなどアプリごと細かい部分での挙動を統一しきれないこと自体は珍しくないので、まぁそんなもんです。

想像力を膨らませながらデザインの新しそうなところをまとめたので（実際の意図は設計者に聞かないと分からないものですが）読んで気になったところ、デザインの意図とか、あーだこーだ周りの人と議論すると面白いと思います。

NavigationDrawerは、死んだ。

Android開発者なら、アプリを立ち上げて、いくつか気になる点があると思います。

ActionBarの高さが微妙にデカいこと、NavigationDrawerが廃止されていること、投稿ボタンを下に置いてあること。

ActionBarのブランドカラーやサイズ感などでしっくりこないかもしれませんが、ActionBarには「更新しています…」など状態表示も含まれるようになっています。

今回、特に注目したいのは、NavigationDrawerでのメニュー表示を廃止してしまったことです。
実際のメニューはどのように表示されるかというと

新しいメニュー

Google+では、このようにListView(カードUI)の上にメニューをもってきてます。ListViewの上部にメニューを表示する手法は、わりと最近に見かけるようになってます。流行に乗っかってる感じがしてますね。

従来のデザイン

ちなみに現在のガイドラインに沿うなら次のようなデザインが一般的です。

こちらはNavigationDrawerを採用したタイプで現在位置をTabで表示して左右スワイプでカテゴリを移動するスタンダードなタイプです。

デザイン変更の理由は？

もともとG+の旧アプリも、このようなをNavigationDrawerを持ってましたが今回の更新でバッサリ変更となりました。理由としては

  • カードUIとしての操作性の統一

がありそうです。最近のモバイルアプリでは、左スワイプを別の動作にあてることがあります。たとえばGmailアプリではスワイプはアーカイブにあたり、Google Nowではスワイプはカードの非表示です。

左右スワイプの使われ方が、カテゴリを移動する、から派生して、いろんな操作を意味することになった点が大きいかも。
これらの操作と混同することを防ぐためにはNavigationDrawer以外のほうがよいのかもしれません。

NavigationDrawerは消え去るのか？

死んだ、と言ってしまいましたが実際はそんなことはないです。NavigationDrawerのメリットは画面端からのスワイプで、いつでもメニューにアクセスできる点ですし、複雑な操作を一手に引き受けてくれます（メニューの出し方がわかりにくくチュートリアルが必要だったり沢山あるメニューから正確なアイテムを取り出せるか、など議論の余地はありますが）。
現状、すぐになくなってしまうデザインパターンとは言いにくい状況です（つまり、まだ主流）。今後のトレンドをみつつ採否を考えていけばいいかと。

Google+で、NavigationDrawerを廃止した理由は、画面ごとに何をすればよいか、という分かりやすさがほしかったからかもしれません。利用シーンにあわせてメニュー（またはコンテンツ）を表示すると、何ができるかわかりやすく伝えらえると考えたのかも。

右側から出てくる通知領域

NavigationDrawerは左側からでてきましたが、Google+の通知領域は右からでてきます。
（13:58 追記：今回のアプデではなく以前からこの挙動のようです）

これは驚いた。定着するかはちょっとわかりませんが、右スワイプが余ってる（※左スワイプはカードの削除や非表示に割り当てられている）ので何か使ってみたかったのでは…。ちなみに通知領域が画面右側に寄って出ること自体はウェブ（Googleのウェブページでは右上にアイテムが集中してるので）でよく見るので普通の発想かなー、と思います。

そういえばFacebookアプリも以前は右側をスワイプするとアクティブな人リストがでてきてましたね（FBのほうは新デザイン移行に伴い、でなくなっちゃいましたが）

邪推すると…

Webと同じ操作系にしてくるってことは、やっぱりAndroid 5.0ではChromeとAndroidが統合されるのだなー、とか考えると夢が広がります（反論をあげておくと、モバイルでWebと似たような操作系を採用すること自体は、珍しくはないという気もしますね）。

ブランドカラーの扱い方

ActionBarはアプリのブランドカラー（Google+なら赤）がはいります。また今までよりActionBarは背が高くなっており、存在感が増しています。かわりにメニューなどはListView(カードUI)をスクロールさせれば非表示になるなど画面を有効に使う工夫がされています。

個人情報のページではブランドカラーが個人のカバー画像で入れ替わるように工夫されてます。一方、画面左上の「

下ボタンUIが復活しそうな気配がある

どうも画面下部の扱いが見直されている気がします。
というの画面下に投稿ボタンが置かれてるからです。G+のアプリ画面を見ると投稿ボタンが下に移動しています。

いつもなら画面上部に置くはずのボタンが下にあります。さらに投稿画面をみてみると、やっぱり投稿ボタンが下に移動しています（下図）。

現在、一般的なアプリだと画面右上に投稿ボタンを配置しています（図の右）。しかし新G+アプリでは画面右上が空いてるにも関わらず画面右下に統一しています。明確な意思が感じられるなー、と。あとデフォルトでキーボードを非表示にしているあたりもポイント高いですね。

かわりに画像やカメラ（しかもプレビュー付）での写真を選びやすくしています。これはSNS（とくにGoogle+）が画像中心になっている現状を踏まえて、優先度を文字から写真にスイッチしたのでしょう。

デザインガイドラインは変化するもの。

以前、Googleはこういっていたと記憶してます。「画面下はホームボタンやバックボタンとかあるから下タブとかやめていこう！」しかし、日は流れ、スマートフォンのサイズが4インチを超え、5インチ超も当たり前となりつつあります。
ぶっちゃけ画面上だともう指が届かないので下に持ってくることを是としたと思います。

投稿ボタンも画面下、ホームボタンのすぐそばにおかず、少し上部に離して配置していることからも、ユーザーへの誤クリック防止の配慮がみてとれます。

デザインガイドラインを守るのも大事ですがユーザーの立場にたって考えることも重要ですね、みたいな話なのですがGoogleはわりと自分でデザインガイドラインを破ってきます。

日々ガイドラインを守れ守れと言っておきながらなので手のひら返しにみえますが、
「ユーザーにとって何が一番いいか」という試行錯誤は個人の開発者ではやりにくいのも事実です。今回の変更も新ガイドライン化されるかもしれないし、ユーザーの受けが悪ければ、何事もなかったかのように消えるだけかもしれません。

まとめ

ガイドラインは時代や流行りと共に変わる点に留意しておくこと。ただし、基本はガイドラインに準じるとデザインの観点からもコストパフォーマンスが良いはず。やはりユーザーが操作に迷わないというのは強い。

あとこの新ガイドラインを推測する遊びは多分こういう意図だろうなー、と思ったことをざっくり書いただけです。次のデザインガイドラインはこれだー！とか信用せず、Google I/O 2014を楽しみに待ちましょう。