僕らのデータ同期プラクティス #DroidKaigi

こんにちは。モバイルチームの中川[twitter:@Nkzn]です。

droidkaigi.github.io

Androidエンジニアのためのカンファレンス「DroidKaigi」に登壇する機会をいただきまして、サイバーエージェントのセミナールームでお話してきました。

本エントリは、発表原稿としてスライドの元にした文章です。技術的には同一の内容になっています。

スライド

僕らのデータ同期プラクティス from Yukiya Nakagawa

www.slideshare.net

はじめに

ユーザーがどんな場所にアプリを持っていこうと、私達はそれを制止できません。自分たちのWebサービスを携帯網もWi-Fiもない場所でも使ってほしいと思ったとき、私たち開発者には何ができるでしょうか。

GmailアプリやEvernoteアプリのように、オフライン時に閲覧・作成・編集されたデータをサーバーと同期させるための仕組みが、Androidには用意されています。

ただ、サーバーと同期する際のアルゴリズムについては開発者任せです。

本エントリでは、データ同期を実装するにあたって参考にしたものや気にしたことを紹介していきます。

自社アプリにオフライン機能を実装しよう

弊社サービスについて

• アグリノート
  • http://www.agri-note.jp
• 農業生産者向けの農作業管理システム
• 費用は4万円/年
• Webブラウザ版、Androidアプリで提供
  iOS版は開発準備中
• 農業版Redmineに近づいてる

業務システムにはよくある話ですが、マスタデータとトランザクションデータの組み合わせにより農作業記録のデータ構造が作られています。

オフライン機能への要望の高まり

2012年3月にAndroidアプリのファーストバージョンをリリースしました。この頃は、画面を表示する時点でデータをfetchしてくる方式でしたが、しばらくすると、似たような要望が散見されるようになりました。そう、「圏外の地域でも利用したい」という要望です。

近年では人が住んでいる場所がエリア外ということは減ってきているようですが、山の中だったり、広大な北の大地のど真ん中に行けば、容易に圏外になるそうです。

「現場で使うアプリ」を標榜しているのに、現場で使えないというのも辛いところです。この問題は、長いこと課題として残っていました。

また、アグリノートの導入を機に法人契約で社員にスマホを持たせている法人農家で、通信費のほうが高く付いている事例も聞こえるようになったことも気になっていました。オフライン動作ができる分には、Wi-Fi接続のみのタブレットという選択肢が生まれるので、これもまた大きなモチベーションになりました。

現場では電波が無くてもデータの保存ができて、電波がある場所に戻ってきたときにデータを同期できる。2013年の終わり頃からアプリの全面リニューアルを始めたタイミングで、そんなオフライン機能の検討を始めました。

気合で同期機能を実装する

さて、自動同期の機能を実現しようとしたら、何が必要でしょうか。

• 定期的に、または何らかのキックにより
• バックグラウンドで通信を行い
• アプリ内のDBを更新する

こんなところですね。

実は2013年にも仕事で同期機能を持ったAndroidアプリを作成したことがありました。当時の私がなんとか知恵を絞って考えたのが下記の構成です。

• android.app.AlarmManager で定期的にインテントを発行
• android.app.IntentService でバックグラウンドプロセスを作成
• ORMLiteでDB処理

実際にこの方針で実装していく中で、色んな問題が発生しました。

• AlarmManagerがときどき消える
• IntentServiceが連続で走って止まらない
• 画面からの更新も混じえてマルチスレッドでDB叩く状態に突入
• synchronized祭り
• ネットワーク有無の検知のために割と頻繁に起動

並行処理プログラミングに強くない人間が首を突っ込んではいけない領域に足を突っ込んでいたような感じでした。

ちなみに同期アルゴリズムとしては、朝イチでログインさせてそのときに前回データを全部消して、それから最近のデータを丸々引っ張ってくるという感じだったので、同期というかただのダウンロードでした。

Androidが提供するデータ同期機能

まずはAndroid側が用意してくれている仕組みの概要や経緯についてお話します。

Android 2.0（API Level 5）で、アカウント管理の機能が導入されると同時に、データ同期のためのAPIが提供されました。

Developers can create sync adapters that provide synchronization with additional data sources.

http://developer.android.com/about/versions/android-2.0-highlights.html

もちろん、この機能は現在でも利用できます。

バックグラウンドでデータの送受信を行いたい場合、スレッドの管理や、ネットワーク有無の検知などを自分で管理するのは手間ですが、このSyncAdapterを利用することでAndroid側にそういった管理を任せられるようになるのです。

導入が面倒

便利には便利なのですが、このSyncAdapterという仕組み、なかなか導入が面倒です。結構な数のファイルを作って適切に配置・設定してあげないと、動き出してくれません。

雰囲気としては、AndroidManifest.xmlを起点として、下記のように各機能を繋いであげる必要があります。

それぞれの役割としては下記のような感じです。

• AccountAuthenticatorで認証情報を管理する処理を行う
  • バックグラウンドで動かすためのServiceも実装する
• SyncAdapterで同期処理を実装する
  • バックグラウンドで動かすためのServiceも実装する
• ContentProviderでデータを管理する
• それぞれの処理をAndroidManifest.xmlで繋ぐ
  • Authority文字列やAccountType文字列を揃える

非常に面倒ですね。とはいえ、サンプルがあれば充分に把握可能なものだと思います。

しかし・・・？

ドキュメンテッドになったのが割と最近

GmailやGoogleカレンダーなどはSyncAdapterの便利さを享受していると思われますが、デベロッパーの間での利用が増えてきたのは割と最近のように思われます。

調べてみると、2009年にAndroid 2.0が出てから約4年後、2013年のGoogle I/Oくらいの時期まで、リファレンスの方には断片的に使い方が書いてあったものの、使い方の全体像になる公式ドキュメントが存在しなかったらしいことが見えてきました。

Transferring Data Using Sync Adapters をインターネットアーカイブサービスで調べてみると、初出が2013年7月13日ということになっています。

http://web.archive.org/web/20130601000000*/https://developer.android.com/training/sync-adapters/index.html

また、同年のやんざむ氏のGoogle I/Oレポを覗いてみると、SyncAdapterが紹介されているのが伺えます。

前述のとおり、それなりに複雑な設定をしないと動かないものですので、公式ドキュメントの登場により、ようやくデベロッパーが「どんなものか試してみようか」と取り組める下地ができたのではないでしょうか。

補足

[twitter:@vvakame]氏もやんざむ氏の記事と同じことを言ってるので、I/Oのときにそういう話があったのは確かみたいです。

2013年のGoogle IOのAndroid Protips: Making Apps Work Like MagicというセッションでSyncAdapterについて言及されたと俺のログには記録されているな。 #DroidKaigi #DroidKaigiB

— わかめ@毎日猫がいる (@vvakame) 2015年4月25日

2013〜2014にかけての資料の充実

Google I/Oでの言及や公式ドキュメントの整備を皮切りに、少しずつまとまった資料が増えてきたように思います。

時期を同じくして、2013年6月に出版された「50 Android Hacks」の中でも、SyncAdapterの使い方が紹介されました。この書籍は江川さんらにより翻訳され、2013年11月に日本語版が出版されています。

tatsu-zine.com

この後、2014年の初めにmixi-inc/AndroidTrainingの中で基礎編の中に組み込まれたりしたのを初め、Web上での情報が増えていったような気がします。

補足

AndroidTrainingのSyncAdapter項を書いた [twitter:@KeithYokoma] さんによると、社内の知見をかき集めて何とかしていたようです。

あの当時 SyncAdapter の知見はすべて社内から引っ張り出してきていたの思い出した #DroidKaigi

— KeithYokoma (@KeithYokoma) 2015年4月25日

同期アルゴリズムの検討

50 Android Hacksのお陰でSyncAdapterを導入すること自体には大きな問題はありませんでしたが、その一方で、どんなアルゴリズムで同期を実現するかという思想的な部分では悩まされました。

結果的に、参考にした資料は下記の２つです。

• 50 Android Hacksのサンプルコード
• Evernote Synchronization via EDAM

50 Android Hacks

github.com

SyncAdapterはHack 23として紹介されています。紙面では要点を押さえた感じで紹介されていますが、サンプルコードに入っているTODOアプリがかなりしっかりしており、基本を掴むための助けになりました。

サンプルにはPython製のサーバーやブラウザ版クライアントも同梱されており、データ同期をより実践的な形で体験できます。

Evernote Synchronization via EDAM

• https://dev.evernote.com/intl/jp/doc/articles/synchronization.php

Evernoteのクライアント・サーバー間データ授受のプロトコル "Evernote Data Access and Management" の仕様書PDFです。全15ページ。

サーバー、クライアントにそれぞれどんな要素を持たせることで "state based replication" を実現しているのかが解説されています。サーバー側にも手を入れるリソースがあれば、この資料の内容をそのまま模倣するのもアリだと思います。

なお、運営の [twitter:@ninjinkun] さんが日本語訳を用意してくれていたりするので、こちらを読んだほうが楽かもしれません。（発表前日に見つけました）

github.com

採用した仕組み

前述の資料を参考にしながら、仕組みとして取り入れたのが、下記の要素です。

• Full Sync, Incremental Sync
• StatusFlag("dirty" flag)

Full Sync, Incremental Sync

Evernoteからもらってきた考え方です。

Full Syncは完全同期と訳せそうです。その時手に入る情報を全部落としてきてしまう種類の同期です。差分について考えなくてもいい代わりに、データ量が多くなりがちです。

一方、Incremental Syncは逐次同期とでも訳せばよいでしょうか。クライアントがどの時点までのデータを持っているのかをサーバーに伝えることで、それ以降の差分となるデータだけを請求できます。一度の同期に関わるデータの量は少なくなりますので、定期的に同期する際にはこちらの方法のほうが有効です。

差分をもらうためのパラメータ

アグリノートでは、最終同期時刻 last_fetched をアプリ内に持っています。API呼び出しのパラメータにこの時刻を載せることで、それ以降に変更のあったデータのみを受け取ることができるのです。

サーバー側の仕組みとしては、各APIに対応するテーブルのmodified_at列を見に行って、パラメータに指定した時刻以降の変更を返すようにしてもらっています。

StatusFlag ("dirty" flag)

Full SyncやIncremental Syncはどちらかというと取得するデータに主眼を置いた仕組みでしたが、こちらは送信するデータに主眼を置いています。

50 Android HacksではStatusFlag、Evernoteでは "dirty" flagと呼ばれていましたが、未同期のクライアント環境でデータに変更があったことを表すフラグという点では同じ性質のものです。

私達は50 Android Hacksに倣い、CLEAN, ADD, MOD, DELETEの4つのステータスを持つフラグを切り替えることで、各データの状態を表すことにしました。

status_flag	意味
CLEAN	サーバーから受け取ったままの状態
ADD	新規に作成された, まだクライアント側にしかない
MOD	サーバーから受け取ったものに変更を施した
DELETE	サーバーから受け取ったものを削除した

同期の流れ

それでは実際に同期の流れを見て行きましょう。基本的には50 Android Hacksでの流れを踏襲しました。

1. データのダウンロードを行う
   • 端末内に last_fetched が保存されていないとき ＝ 初めて同期するときはFull Syncを行う
   • 端末内に last_fetched が保存されている時 ＝ 既に前回データがある場合はIncremental Syncを行う
2. サーバーで削除されていたデータをクライアントでも削除する
3. サーバーで更新されていたデータをクライアントでも更新する
4. クライアント側で作成(ADD)・更新(MOD)・削除(DELETE)されたデータをサーバへ送信する
5. 送信が済んだデータのStatusFlagをCLEANにする
6. last_fetched に1の時刻を保存する

これで同期が成立しているはずです。

競合問題

同期の理屈はできましたが、もう一つ考えないといけないことがあります。サーバーが行なったデータ操作と"dirty"なデータの間で競合があった場合です。

具体的には、以下の２つの段階で問題になります。

２. サーバーで削除されていたデータをクライアントでも削除する
３. サーバーで更新されていたデータをクライアントでも更新する

クライアント側のデータが変更されていて、なおかつサーバーからもデータを貰ってしまったとき、取れる選択肢は限られそうです。

• 常にサーバー側が勝つ（送信しない）
• 常にクライアント側が勝つ（サーバーからのデータを捨てる）
• クライアント側でマージしてからサーバーへ送る（なんとか全部生かす）

せっかく手元で作ったデータですから、送信したいですよね。サーバーに勝たれるのは困ります。クライアント側のデータをそのまま送るか、サーバーから貰ったデータとなんとかマージしてから送るか、といったところになりそうです。

アグリノートアプリではクライアントが勝つことにしてあります。マージといってもどこからどこまでマージしたものか検討するコストが高そうだったからです。

なお、Evernoteで以前試したときには、マージしてから送信する方法を取っていました。EDAMにもそう書かれています。

まあそもそも、ブラウザ対ブラウザでも画面の表示タイミングや保存を押すタイミングによっては起こることですし、そのときには後勝ちになる場合が多いと思うので、この件もクライアント側が勝つのが自然なんじゃないかと思うのです。

同期パターンの確認

さて、流石にそろそろ話がごちゃごちゃしてきたので、頭の中を整理するために同期のパターンを表にまとめてみました。

• 元々のstatus_flagはADD, MOD, DELETE, CLEANのどれだったか
• 更新されたものが降ってきたのか、削除されたものが降ってきたのか、何も降ってこなかったのか
• 結果としてクライアント側のデータがどう更新され、サーバーにはどのデータが送られるのか

このへんについてまとめられています。チーム内での認識合わせに役立ちました。

まとめ

同期が必要になるような要件が出てきたら、この話を思い出してください。

• mixi-inc/AndroidTrainingでSyncAdapterを勉強して
• 50AHでSyncAdapterのサンプルを知って
• EDAMの理屈を参考にして同期の仕組みを考える

こんな流れで乗り越えられる山があるはずです。

最後に

ウォーターセル株式会社では、地球人口100億の時代に見合う食料生産のための農業革命を一緒に引っ張っていってくれるAndroid/iOSエンジニアを探しています。

弊社事業に興味のある方は、是非ご連絡ください。

おまけ：50AHの注意点

50 Android Hacksのサンプルは読み応えがあり良い資料なので是非読むべきですし、本の内容も概ね良いのですが、SyncAdapter章に致命的な誤訳があるので気をつけましょう。

• 誤　：23.2.2 サーバの中でデータベースを扱う
• 原著：23.2.2 Hitting a database instead of the server
• 直訳：23.2.2 サーバーの代わりにデータベースを叩く

原著がサンプルとして公開されているので、英語版と読み比べながら読むくらいでちょうどいいかもしれませんね。（Sample chapter5に該当の章があります）

正誤表が見つからなかったので、この場を借りて紹介しました。もし正誤表のページがあれば教えていただければ幸甚です。

Android 5.0からSVG準拠のdrawableが書けるようになりました

こんにちは、Androidチームの中川@Nkznです。

Android Studio 0.8.14のリリースノートを見ていて知ったのですが、LollipopのAPI Level 21では<vector>などのdrawable系タグが拡充されたのですね。

名前的にベクターイメージが書けそうですが、実際何ができるのだろうと思って調べてみました。

• Working with Drawables | Android Developers

Vector images are represented in Android as VectorDrawable objects. For more information about the pathData syntax, see the SVG Path reference.

<vector>の中に書く<path>タグのpathDataの記法が、SVG準拠のようです。サンプルコードがこちら。

 <path android:fillColor="#8fff"
     android:pathData="M20.5,9.5
                       c-1.955,0,-3.83,1.268,-4.5,3
                       c-0.67,-1.732,-2.547,-3,-4.5,-3
                       C8.957,9.5,7,11.432,7,14
                       c0,3.53,3.793,6.257,9,11.5
                       c5.207,-5.242,9,-7.97,9,-11.5
                       C25,11.432,23.043,9.5,20.5,9.5z" />

なるほどとてもSVGでした。

何が嬉しいのか

http://developer.android.com/design/style/iconography.html

SVGをはじめとしたベクターイメージの強みの１つとしてよく云われるのは、拡縮しても綺麗さが変わらないという点です。

Androidでは（最近ではiOSも）対象端末の解像度ごとに別々の大きさの画像を用意するのがそれなりに手間です。また、同じアイコンでもアプリ内で使う場所（左上用、ボタン用、見出し用など）が変われば、それぞれに別々のサイズを用意しなければいけません。

SVGで画像リソースを作成できるようになれば、１種類のリソースで様々なサイズの要求に応えることができるようになりますので、嬉しい事になりそうです。

余談：公式Material Designアイコン

そういえば先日、Googleがマテリアルデザイン向けのシステムアイコンをリリースしたことが話題になっていました。

• google/material-design-icons
• Release Material Design Icons · google/material-design-icons

このニュースを見た時には「SVGが用意されていても、どうせWebでしか使えない」と考えていたのですが、Lollipop以降のバージョンでは<vector>によってSVG（っぽいもの）が利用できますので、転用の可能性が広がります。

試してみた

実際にSVGはどのように表示されるのでしょうか。前述のマテリアルデザインアイコンから下記のic_add_to_photos_48px.svgを拝借して、表示してみたいと思います。

SVGから変換（手作業）

• ic_add_to_photos_48px.svg

<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" viewBox="0 0 48 48">
    <path d="M0 0h48v48h-48z" fill="none"/>
    <path d="M8 12h-4v28c0 2.21 1.79 4 4 4h28v-4h-28v-28zm32-8h-24c-2.21 0-4 1.79-4 4v24c0 2.21 1.79 4 4 4h24c2.21 0 4-1.79 4-4v-24c0-2.21-1.79-4-4-4zm-2 18h-8v8h-4v-8h-8v-4h8v-8h4v8h8v4z"/>
</svg>

• drawable/ic_add_to_photos_48px.xml

<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:height="256dp"
    android:width="256dp"
    android:viewportWidth="48"
    android:viewportHeight="48">
    <path
        android:fillColor="#000000"
        android:pathData="M8 12h-4v28c0 2.21 1.79 4 4 4h28v-4h-28v-28zm32-8h-24c-2.21 0-4 1.79-4 4v24c0 2.21 1.79 4 4 4h24c2.21 0 4-1.79 4-4v-24c0-2.21-1.79-4-4-4zm-2 18h-8v8h-4v-8h-8v-4h8v-8h4v8h8v4z"/>
</vector>

それっぽく似たような雰囲気にしてみました。width, height周りは適当です。

この時点で、レイアウトエディタがプレビューをしてくれるようになりました。

数値を適当に弄ってみるとちゃんと反映されます。

画面に組み込む

一度drawableリソースとして取り込んでしまえば、使い方としてはいつもの<shape>と似たようなものです。

• activity_main.xml

<!-- 略 -->
<FrameLayout
    android:layout_width="24dp"
    android:layout_height="24dp"
    android:background="@drawable/ic_add_to_photos_48px" />
<!-- 略 -->

上記のようなFrameLayoutを何サイズか並べてみたものがこちらになります。

一手間かければSVGアイコンがAndroidでも使えるようになったことがお分かりいただけたかと思います。

まとめ/雑感

ということで、長らくAndroidアプリ開発者を悩ませてきた画面の断片化問題が１つ解決するのではないかという期待が持てる機能を紹介しました。

最後に少しだけネガティブなことを言うと、パフォーマンスとか大丈夫なのかなーと思ったりはしました。それから、

@nkzn それだ！というか、ここまでやっておいてなぜsvgをそのままつかえるようにしてくれないんでしょうかね？

— ウズキアオバ (@uzuki_aoba) 2014年10月30日

これは思いました。わざわざ直すのは面倒です。drawableフォルダにSVGファイルそのまま置かせてもらえると一番嬉しいのですが・・・しばらくは動的にSVGをVectorDrawableに変換するような手法を使うのが現実的でしょうか。

まあ、日本でLollipopが十分に普及するまではまだしばらくかかると思いますので、周辺環境が整うのを見守りたいと思います。（support-v7あたりに取り込まれないかなと）

それでは今回はこのへんで。

宣伝

ウォーターセル株式会社では、農業生産者に嬉しい情報の扱い方を一緒に考えてくれるWebフロントエンドエンジニア、Railsエンジニア、Androidアプリエンジニアを探しています。

興味のある方は、是非一度新潟まで遊びに来てみてください。

GCMのUser Notificationsの使い方

こんにちは、Androidチームの中川@Nkznです。

Google Cloud Messaging for Androidの勉強をしていたところ、User Notificationsのドキュメントに分かりづらい部分があってハマったので、備忘録として書き残しておこうと思います。

というわけで、User Notificationsがどんな機能なのかは説明しません。知りたい方は、ドキュメントをお読みください。

User Notificationsを使わずにpush配信する

まずは、普通のpush配信のやり方。公式資料でも丁寧に紹介されていますし、日本語記事も多くあります。

• GCM HTTP Connection Server | Android Developers
• [改訂版]Google Cloud Messaging (GCM) でプッシュ配信する[Android] ｜ Developers.IO

curl \
--header "Authorization: key=<API_KEY>" \
--header Content-Type:"application/json" \
https://android.googleapis.com/gcm/send \
-d "{\"registration_ids\":[\"<REGID>\"],\"data\":{\"message\":\"Hello\"}}"

registration_idsをJSON配列として列挙すれば、IDに紐付いた端末に{"message":"Hello"}というデータが配信されます。

User Notificationsを使ってpush配信する

同じユーザーが持っている複数の端末に対してPush通知を送りたい場合は、registration_idsを列挙するよりも、User Notificationsを使ったほうが便利そうです。

• User Notifications | Android Developers

シンプルな流れとしては、下記の手順になります。

1. 複数のregistration_idをまとめたnotification_keyを発行する
2. notification_keyを使ってpush通知を行う

notification_keyを発行する

まずはnotification_keyを発行しましょう。各種ID, KEYを適切に配置していけば、特に難しいことはありません。

Request

curl \
--header "project_id: <PROJECT_NUMBER>" \
--header "Authorization: key=<API_KEY>" \
--header Content-Type:"application/json" \
https://android.googleapis.com/gcm/notification \
-d "{\"operation\": \"create\",\"notification_key_name\": \"appUser-Hogehoge\",\"registration_ids\":[\"<REGID>\",\"<REGID>\",\"<REGID>\"]}"

Response

{"notification_key":"<NOTIFICATION_KEY>"}

上記のようなリクエストを送ることで、無事にnotification_keyを取得できました。

push通知を行う（仮）

それでは、notification_keyを使って実際にpush通知を行ってみます。

• Implementing GCM Server | Android Developers

registration_idsの説明を見ると、必須項目についての話題がありました。

A request must include a recipient—this can be either a registration ID, an array of registration IDs, or a notification_key. Required.

registration_idsかnotification_keyのどちらかを必須で含めればよいようです。ということはregistration_idsを使ったパターンをそのまま差し替えればいけるはず。

Request

curl \
--header "Authorization: key=<API_KEY>" \
--header Content-Type:"application/json" \
https://android.googleapis.com/gcm/send \
-d "{\"notification_key\":\"<NOTIFICATION_KEY>\",\"data\":{\"message\":\"Hello\"}}"

Response

Missing "registration_ids" field

・・・あれっ？

困ったときのStackOverflow

StackOverflowを探してみると同じ悩みを持った人が見つかりました。

• android - GCM User Notifications: Missing "registration_ids" field - Stack Overflow

ベストアンサーがこちらになります。

The documentation is buggy, you have to use this request:

// 略
{ 
   "to": "<NOTIFICATION-ID>",
   "data": {},
}

notification_keyの記述にはtoを使うそうです。

この回答者の方はドキュメントのバグと言ってますが、現在のドキュメントを改めて見てみたところ、notification_keyの行の端にこんな記述がありました。

HTTP. This feature is supported in CCS, but you use it by specifying a notification key in the "to" field.

• Message Parameters

なるほど、notification_keyフィールドがサポートされているのはCCS方式でリクエストするときだけで、あとの場合はtoに入れてねということでしょうか。

しかしこの書き方だと、結局サポート先がHTTPなのかCCSなのか分かりづらいですね。また、当のtoの行を見ると、CCSのみのサポートでHTTPはサポートしていないことになっているので、なるほどこれはbuggyと言われても仕方がない感じがします。

push通知を行う（真）

そんなわけで、最終的にnotification_keyを付与したリクエストは、下記の形になりました。

curl \
--header "Authorization: key=<API_KEY>" \
--header Content-Type:"application/json" \
https://android.googleapis.com/gcm/send \
-d "{\"to\":\"<NOTIFICATION_KEY>\",\"data\":{\"message\":\"Send with User Notification\"}}"

手元の端末が一斉に震える様は壮観でした。

まとめ

GCMを触り始めてみて、push通知が思ったより簡単に、そして無料でできることに驚いています。

ほしい情報をほしい時に通知する、という理想を実現するためには、push通知は大きな役割を果たしてくれます。Android Wearな腕時計型デバイスやGoogle Glassなど、アプリからの通知を受け取ってユーザーの見やすい場所に表示してくれる強力なツールも今後増えていくことでしょう。

通知周りはまたしばらく勉強していきたいと思います。

宣伝

ウォーターセル株式会社では、農業生産者に嬉しい情報の扱い方を一緒に考えてくれるWebフロントエンドエンジニア、Railsエンジニア、Androidアプリエンジニアを探しています。

興味のある方は、是非一度新潟まで遊びに来てみてください。

【注意】GitHubのrawファイル用URLが変わったようです

こんにちは。Androidチームの中川@Nkznです。

作ったまま放置していた技術者ブログをそろそろ動かして行きたいと思います。

変わったこと

GitHubでMarkdownなどのファイルを閲覧する際に、元々のプレーンテキストのファイルが見たくなると、「raw」というボタンにお世話になると思います。これ↓ですね。

さて、これまではrawでファイルを見た場合のURLは

https://raw.github.com/android/platform_packages_apps_settings/master/res/layout/display.xml

こんな感じでした。

それがこの度、こうなりました。

https://raw.githubusercontent.com/android/platform_packages_apps_settings/master/res/layout/display.xml

何のことはないドメイン変更なのですが、これによって一部の人が困る事案が発生しました。

問題の焦点

Gradle時代のAndroidアプリの構成管理においては、GitHubをMavenリポジトリとして扱う、という裏ワザじみたライブラリ管理手法が出てきています。

u1aryzの備忘録とか: githubをMavenリポジトリとしてAndroidライブラリプロジェクト(aar)をデプロイして使用する
http://u1aryz.blogspot.jp/2013/06/githubmavenandroidaar.html

上記のような手法で実際にGitHubをMavenリポジトリ化して配布しているものの一つが、@sys1yagiさんのindirect-injectorです。

実際には下記のように記述して導入していました（過去形）。

repositories {
    mavenCentral()
    maven { url 'https://raw.github.com/sys1yagi/indirect-injector/master/repository' }
}

dependencies {
    compile 'com.sys1yagi:indirect-injector:0.0.2'
}

ドメインの！！！フルパスで！！！！指定する！！！！！！

というわけで、本記事はドメイン変更の影響で起きた問題の備忘録です。

起こったこと

Gradleビルドが始まるまでに数分かかるようになった。

raw.github.comのドメインが無くなっているのに、ライブラリを請求しに行こうとして失敗することによって、時間がかかっていたようです。

ビルドが遅いなーと思ったら、 ./gradlew clean assembleDebug --info などで確認してみましょう。 Resource missing だらけの涙ぐましいログを見ることができるかもしれません。

解決策

raw.github.comと書いてあった部分をraw.githubusercontent.comに置き換えましょう。

手元の環境では5分かかっていたテストが2分になりました。もう少しチューニングしたいところですが、一番問題だったところを解決できたので万々歳です。

Hello, Hatena Blog!

中川です。

勢いで始めてみました。
いちおう開発者ブログのつもりで作ったので、一番大事なシンタックスハイライトを確認。

package jp.water_cell.android.HelloHatenaBlog;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloHatenaBlogActivity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        TextView tvHelloHatenaBlog = new TextView(this);
        tvHelloHatenaBlog.setText("Hello, HatenaBlog!");
        
        setContentView(tvHelloHatenaBlog);
    }
}

ついでにスーパーpre記法に書いてあるRubyコードも確認。

 class Foo
   def bar'baz' # return baz
   end
 end

まだ色は付かないようです(´・ω・｀)

Gist埋め込みはどうだろう。

Gistのシンタックスハイライト自体がちょっとアレですが、こちらは色付けされるみたいですね。
こんな調子でコードを貼っていけたらいいなあと思います。

Yukiya Nakagawa