Infinito Nirone 7

白羽の矢を刺すスタイル

怠惰なる勤勉とエンジニア

この記事は Re:ゼロから始める Advent Calendar 2016 - Adventar 10日目の記事です。若干のネタバレ要素を含んでいますのでご注意ください。

怠惰ですね…

https://i.ytimg.com/vi/owyvwT0paiQ/maxresdefault.jpg

「あなた…怠惰…ですね……」といえば、ペテルギウス・ロマネコンティのセリフで、かなりの頻度で口にしています。 ペテルギウスについての詳しい考察は脳が震える(仮) - BlueberryStreamにありますが、このペテルギウス、怠惰怠惰と言う一方で勤勉さも持ち合わせています。 「愛にぃ…愛に報いなければぁ…」というセリフが象徴的ですが、魔女教信徒としての勤勉さは、彼の言動全てにおいて感じられることでしょう。

プログラマの美徳

http://tama-yura.jp/animetory/img/entries/7d22f228e7f4b94da61097c418823bcb121cdf69/578c4666a75c4/pc/2.jpg

ところで、怠惰といえば七つの大罪のひとつとしてよく知られていますが、プログラマの美徳のうちのひとつでもあります。 プログラマの美徳には三つあり、それぞれ「怠惰」「傲慢」「短気」です。

このうちの「怠惰」とはまさしく、ペテルギウスの「怠惰」と「勤勉」の二律背反な性質のことを言うのだと(個人的に)思います。 プログラマやエンジニアと言った職種は、技術をもって製品やサービスといったものを作ります。 その過程において、何度も同じ作業を繰り返し行う無駄の排除や、誰もが同じ作業を滞りなく実行できるフレームワークの構築といった効率化は非常に重要です。 つまり、怠惰な姿勢とは、繰り返しの無駄にかかる労力を減らすことであり、その労力を減らすための仕組みやフレームワークを作ることに心血を注ぐことが怠惰ゆえの勤勉さと言えます。

翻ってペテルギウスの言動を見てみると、怠惰担当ではあるものの、魔女教信徒を束ねる上では一切の不純も許さない姿勢や抜かりなさは勤勉そのものです。 一切の不純も許さず、良くない兆候を見逃さずその場で解決(殴打)する短気さも、勤勉さに拍車をかけているようにも思います。

おわりに

あまりペテルギウス本人の考察はできませんでしたが、自分自身がエンジニアであるがゆえ、怠惰というとどうしても思い浮かべるプログラマの美徳についてサッと書いてみました。 ペテルギウスの怠惰や勤勉さは、単なる狂気ではないし、むしろ正気にこそ彼のような怠惰や勤勉さが必要なのではないかとすら思いました。

DroidKaigi 2017 のプロポーザルを出した話

今年も DroidKaigi 2017 Call for Speakers の季節がやってきました。 初回から運営に携わってきていますが、プロポーザルの方もやっていくぞ!という強い気持ちで案を出してみました。

何を話そうとしているのか

Android Auto にまつわる話をベースとして、プロセス間通信をする上で大事なことを話したいと思っています。Android Auto と言うとニッチな話ですが、仕組みを理解すると意外に身近な技術で作られていることが分かります。その身近な技術を使いこなすために必要なことをまとめられればと思います。

何を聞いてみたいのか

個人的には、「このフレームワークAPI・ライブラリを組み合わせてこんな面白いことが出来た!」みたいな、ハックな話を聞いてみたいと思っています。 アーキテクチャやプロセスの実践的な話も勿論聞いてみたいし、大事なことだと思っているのですが、こんなことも出来るんだ!というワクワク感のある話も聞いてみたいな、ということを思っています。

いつまでなのか

公式でのアナウンスの通り、11月1日に締め切りが設定されています。もう一週間しか無いぞ!

dex.fm: Hacks in Drivemode というお題でポッドキャストにゲスト参加しました

dex.fm という Android をテーマにしたポッドキャストにゲスト参加し、会社のプロダクトで培われている技術について話をしました。

http://dex.fm/post/151298631133/10-hacks-in-drivemode
dex.fm

今回の話題は、WindowManager に View を書くということと、それに関連したアプリケーションのフレームワーク、省メモリ・省電力、プロセス間通信や複雑なモデルの構成、状態遷移についてです。

いくつか、補足として書いておきたいことがあったのでブログの記事にしておきます。

TransactionTooLargeException

AIDL などプロセス間通信を多用する際にはお目にかかる場面も出てくる例外です。その Javadoc によると、プロセス間通信で使用できるメモリは 1Mb と定められているようです。 この 1Mb というのは、一回の通信で使用できるメモリの上限ではなく、アプリケーションのプロセス全体に割り当てられる、全プロセス間通信で使用できるメモリの上限ということがポイントで、一回のプロセス間通信で巨大なデータをやり取りした場合だけでなく、小さなデータをやり取りする複数のプロセス間通信をドカッと一気にやったりした場合でも、小さなデータの総量が 1Mb を超えたら例外が飛んできます。

プロセス間通信でデータの交換に使う仕組みといえば Parcel です。Intent や Bundle のような、特段プロセス間通信ということを意識しない場所でも使われる Parcel ですので、Intent や Bundle に巨大なデータを詰めて他のアプリに送りつけるということをした場合でもやはり、TransactionTooLargeException が飛びますし、PackageManager でいろんなデータをクエリするときにもやはりデータ量が多すぎると例外が飛んでくるので、アプリの機能がそこそこ豊富になってくると見かけるようになると思います。

このような背景があるため、特に画像データの交換に関しては、出来得る限り Uri など文字情報になおして提供することが推奨となるわけです。

ちなみに、ポッドキャストでは Cursor にも言及しましたが、Cursor に関しては CursorWindowAllocationException というのが別にあるようで、TransactionTooLargeException とは違うものでした。いずれにせよ、あまり巨大なデータを持たせることはお行儀が良くないので、クエリの方法を変えるなどの対策が必要です。

Android Auto

音楽系のアプリがシステムと連携して、ロックスクリーンに再生コントロールを表示したり、アルバムアートを表示したり…ということを実現する API は、Android Auto の登場で随分スッキリと整理され、かつシステムとの連携だけにとどまらない汎用的なフレームワークになりました。どんな API になっているかについては、TechBooster から出ている「アンドロイドアカデミア」に詳しく書いてありますが、Android Auto に至るまでにもいくらかの変遷があります。

もともとは、ICS で導入された RemoteControlClient が最初に登場した音楽系アプリ向けの API です。実態としては、AIDL に基づいてロックスクリーンと音楽系アプリが連携するためにしくみになっています。音楽系アプリが RemoteControlClient を使って再生コントロールの状況や楽曲情報をロックスクリーンに渡すと、ロックスクリーンがいい感じに表示を更新してくれます。

その後 RemoteController という別のクラスが Kitkat で導入されました。これを使うのはシステムや音楽系アプリと連携したい他のアプリです。このクラスが登場するまでは、 RemoteControlClient が内部でやり取りしていた AIDL をパクって借りて来る必要があったのですが(ちなみにこの AIDL を借りてくる話は TechBooster から出ている「AZ異本」に詳しく書きました)、RemoteController を使えばそれをすることなく簡単に音楽系アプリと連携が取れるようになります。ただし少し癖があり、NotificationListenerService で使わないと動かないようです。

簡単にできるといいつつも微妙に使いづらかったり、Android Auto の仕組み上 Android システムではないアプリとの連携が必要な点(Android Auto は "Android Auto" という名前のアプリが中心になっている)があったりした上で、Android Auto の音楽系アプリ向けの API は整備されたんだなぁということが伺えます。 ポッドキャストでも言及したとおり、サポートライブラリにバックポートされているので、使おうと思えばこの仕組を ICS や JB などでも使うことができます。もちろん、音楽系アプリと連携したいアプリの両方が対応しないとダメなんですが。

ちなみに、NotificationListenerService が動いている最中に例外をはいて死ぬと、NotificationListenerService が復活しなくて(==システムの再バインドが走らなくなって)次に端末を再起動するまで通知が受け取れない、という事が稀によくあります。

#C90 アンドロイドアカデミア

技術書典に続き、夏コミでも TechBooster さんから新刊「アンドロイドアカデミア」に記事を書きました。

techbooster.github.io

Android Auto の API のうち、オーディオ周りの部分を紹介する記事ですが、単に Android Auto の API の使い方を紹介するだけではなく、Android Auto がどうやって動いているかも合わせて紹介しています。仕組みとしてはシンプルですが興味深いところも多々あるので、是非お手にとっていただければと思います。

はじめての同人誌即売会、はじめての技術系同人誌 #技術書典

それ早く言えよ!というツッコミもあるかとは思いますが、TechBoosterさんの技術系同人誌「AZ異本(アツい本)」でAIDLに関する「そんな使い方するの…」的な記事を担当しました。

techbookfest.github.io

techbooster.github.io

AZ異本は技術書典という技術系同人誌オンリーの即売会で出まして、現在はBOOTH.PMでも取り扱っています。

techbooster.booth.pm

TechBoosterさんで世に出る何かを書く、というのは密かに憧れていたのですが、今回の技術書典でそれがかなってとても嬉しかったです。 技術書典当日も売り子としてブースで来場者の方々が手にとって買っていくのを生で見ていました。これまでは電子書籍の売れ行きやQiita上のストックがたまっていくところでしか実感できなかったことが、直接自分の目で見て体感できたのはとても貴重な体験でした。同人誌即売会というもの自体がはじめてだったので、会場の雰囲気も、来場者の方々、出店者の方々の熱気もアツくて、これはすごいところに来たんだな(小並感)と思いました(気がついたらお昼を食べるのも忘れていましたw)。

執筆に関しては、執筆前から一通り書き終えてからのレビュー、出版後の誤字等の指摘に至るまで手厚くフォローしていただけて、初心者にもとても優しくかつ丁寧に対応してくださいました。本当にありがとうございました。

次の機会があれば、また何か書いてみたいです!

potatotips #30 Android まとめ

potatotips #30 の Android まとめブログです。

potatotips.connpass.com

発表内容

1. ken0331 - CDD(コンポーネント駆動開発)

コンポーネント駆動開発ということで、共通で使えるコンポーネントを用意して再利用性を高める、というお話でした。 Fragment をコンポーネントとして、ドメインに近い部分は Activity がもっておき、コールバックでやり取りをするというのが大筋の方針のようです。 個人的には、クリーンアーキテクチャのような"プレゼンテーション"、"ドメイン"、"データ"の3層構造が分かりやすくてよいなと思っているのですが、プレゼンテーションの部分の作り方に関しては、それはそれで色々なパターンがあるようです。コンポーネント駆動開発、というのはそのうちのひとつとしてとらえたほうが良いかなと思いました。

2. hkusu - RxJavaを活用する3つのユースケース

www.slideshare.net

RxJava の活用法として、とくに Subject を使った pub/sub の構造の作り方にフォーカスしていました Otto や EventBus などもありますが、これを RxJava でも行う、というものです。まだまだ知らないオペレータがあって、なるほどそうやって実現するのか!という知見であふれていました。 やはり、関心の分離とデータの流れがシンプルになるという点がよいですね。

3. nekoe - プッシュ通知の「開封」を検知する方法

プッシュ通知の効果測定はとても気になっていた話題です。 個人的には、プッシュ通知を配信しても通知経由ではなく通常のランチャー経由でアプリを開く「みなし開封」の技術が面白かったです。

4. Fumihiko Shiroyama - Realm for Android Tips

最近正式リリースとなった Realm の Tips です。transient なフィールドのための @Ignore をはじめ、RealmObject が POJO を作る際にも使えるようになっていたりと、ドンドン進化しています。 RealmRecyclerViewAdapter はかなり便利にみえました。RxJava にも対応しているので、トレンドにも乗っていて使い勝手の良さが伺えます。

5. shaunkawano - Introduction to AutoValue

Google が出しているコードの自動生成プロジェクトです。 POJO なエンティティクラスのフィールドを用意しておいて、アノテーションを付けることで apt で必要なコードを自動生成します。Parcelable の実装はいつもボイラプレートになるので、非常に便利ですね。 Gson や Moshi などのシリアライズフレームワークとも相性が良いというのは重要ですね。

6. yamacraft - FirebaseのAuth機能

Firebase での Auth 機能の解説です。非常に強力なバックエンドとして進化を遂げた Firebase ですが、もちろんアカウント管理も強力です。確認メールまでおくれるのは流石だと言う感じでした。 メールアドレスとパスワードによる通常のサインアップのほか、SNS 等のアカウントシステムとの連携もとれるので、Firebase を使わない手はないですね。 ただし、Goole Play が使えないと Firebase も使えなくなるのはちょっとした弱点かなという気がします。

7. magiepooh - How to detect phone call

speakerdeck.com

音楽や動画などのコンテンツを扱うとき、アプリ外で何が起きているかを把握し適切にハンドリングすることはとても大切です。今回は、電話を例にとって、再生中に電話が来た時のハンドリングの仕方のお話でした。 TelephonyManager で判別することも出来ますが、再生コントロールとしては AudioManager も使うことが出来ます。AudioManager をつかった AudioFocus の管理をすると、電話以外にも使えて便利です。