Architecture Componentで追加されたRoomを実際に使ってみた。
なんかややこしそうと思って敬遠していたのだけど、やってみると意外とそうでもないなという感じで「あれ、これだけ？」っていう感じで実装できた。実装できたと言っても、適当なサンプルだから簡単だっただけなんだけども。
https://github.com/gen0083/SampleArchitectureComponent
RoomではDatabaseとDaoとEntityの3種類を用意してやると、AnnotationProcessorによるコード生成が行われてSQLiteを簡単に利用できるというライブラリ。
LiveDataを返すようにDAOで定義することができ、この場合Databaseが更新されるとその変更がLiveDataを通じて受け取れる。いわゆるいいねボタン問題を解決する一つの解決策と言える。
LiveDataを返すようにDAOで定義を行うと、その処理はバックグラウンドで実行されるようなコードが生成される。逆にそれ以外の処理は自分で実行スレッドを考慮しないといけない。デフォルトだとRoomで生成されたコードをメインスレッドで実行すると例外が吐かれる。
LiveDataを返すようにする場合は注意しなければいけないことがある。
https://github.com/gen0083/SampleArchitectureComponent/blob/master/app/src/androidTest/java/jp/gcreate/sample/samplearchitecturecomponent/data/repository/TestRepositoryByRoomTest.kt#L66
このコードのようにsut.watch().valueとLiveDataのvalueを取得しても、その時点ではvalueはnullである。該当のテーブルのデータ全件取得と変更通知を兼ねてLiveDataを使おうとすると想定通りに動かない。実際にデータが取れるまでは時間がかかる。
LiveData<List<TestData>>としておけば、変更通知も受け取れる、データ全件取得もできる、便利じゃんと思ったけど、そうそううまくはいかなかった。といっても、RecyclerViewに表示する目的であれば、LiveDataを使うとすごい楽ちんであった。同じくSupport LibraryのListAdapterと組み合わせるとすごい楽。
ちなみにこのLiveDataを返すメソッドのユニットテストを行う場合、android.arch.core:core-testing:$architecture_version"を追加して、@get:Rule var executorRule = InstantTaskExecutorRule()とJunitTestRuleを適用してやるとうまいことテストができる。このルールを適用しないとバックグラウンドでの処理を待たずにテストメソッドが終了してしまい、LiveDataからデータを受け取ることなくテストが終了してしまう。
Google Playにアプリをアップロードする際、versionCodeを常に増やしていく必要がある。
Gradleを使ってこのversionCodeを自動的に生成する（versionNameと一緒に）ときに、versionCodeには最大値が存在するということは覚えておかないとならない。
https://developer.android.com/studio/publish/versioning.html
Google Playでは2.1Mが最大値となっているらしい。
versionCodeを生成するスクリプトを書く際は、APKを作成してそのAPKのversionCodeを確認するところまで気を配ろう。スクリプトでversionCodeが生成できていることだけ確認して、Google PlayにAPKをアップロードしたら最大値にひっかかって更新できなくなった、なんてことになったら悲しすぎる。
ちなみにこの問題にでくわしたのは、versionCodeをメジャーバージョン3桁、マイナーバージョン3桁、パッチバージョン3桁、ビルド番号3桁、MultiAPK識別用の符号1桁でversionCodeを生成したときである。
Google PlayにAPKをアップロードする前に気づけて良かった。
去年に引き続き、今年もDroidkaigiアプリにコントリビュートすることができた。
去年は1行書き換える程度の細かいPR中心だったが、今年は機能の追加なんかもできて個人的に成長が感じられてうれしい。
Droidkaigiアプリは後から他の人が出したPRを見て「こういうやり方があるのか」と知見を得たり、知らないやり方を知れたりとそれだけで勉強になる。しかし私にとっては、リアルタイムで参加することこそ意義がある。
なぜなら、普段ソロで勉強・開発をしているので、コードに対するフィードバックが得られる機会がないからだ。PR送ればそんな貴重なフィードバックがいただける可能性があるのである。このチャンスを逃す手はない。万年ソロのせいでGit力すらないのだが、PRを送ることがGit力を鍛えるチャンスにもなってよい。
今回は、私のように独学でAndroid勉強しているというような人に向けて、この貴重なチャンスを最大限活用しようぜというスタンスで記事を書いてみようと思う。
準備 コントリビュートする前段階、準備に関しては公式情報が詳しいので参考にされたし。
DroidKaigi 2018 アプリをGitHubで公開しました
Issueを立てる コードを書いてPRを送るのはハードルが高い、という人はまずはissueを立てることで貢献するのがいい。アプリを手元で実行してみて、ここの挙動がおかしくないだろうかなど、気づいたことを書けば良い。
日本語OKと言われても、みんな英語でやりとりしている中自分だけ日本語で書くのもなぁなんて思うかもしれないが、そこで躊躇するのはもったいないと思う。
例えばIssueを立てるのも勉強になるのである。こういう挙動がおかしいという問題提起に対して、誰かがそれを解決するPRを送ってくる。そうすると、この問題の原因はここにあって、こう対処すれば良かったのかと学びになる。
他の人が立てたIssueでも同じように学びになるが、やはり自分で立てたIssueの方が身につくと思う。
Issueを立てるときやPRの説明などに、動画をつけるのが親切でいいと思う。
私はAndroid Studioを使って端末の動画を撮影（Logcatのタブのところに動画撮影ボタンがある）、撮影したMP4のファイルをこのサイトを使ってアニメーションGIFに変換し、それをGithubに添付している。
Issueの原因を探る すでに立っているIssueに対して、なぜそのような問題が起こっているのかの原因を探る。
今年は探る前に「このIssueに取り組みます」と手を挙げてassignしてもらうといい。やってみて無理そうならその旨を伝えればいいということなので、気軽に挑戦するといいと思う。
とは言え手を挙げてやっぱり無理でしたというのは恥ずかしいというのも真理。まずは立っているIssueの原因探求をやってみるところから始めてもいいかもしれない。
おそらくではあるが、すでに立っているIssueに対して追加情報を書き加えるのも立派なコントリビュートであると思う（コントリビューターには名前が載らないだろうが）。
原因がわかれば、対策を自分でできそうならassignしてもらえばよいし、原因は分かったが対処法が思いつかないというのであれば、他の人のPRを待って学びを得る機会が手に入ったと思えば良い。どちらにしろよい勉強になる。
PRを送る ちなみに私はIssueを立てることなくいくつかPRを送っている。私の場合、Issueを一つ立てるのも時間がかかるので（主に英語力のせい）、コード書いてPR送ったほうが早い場合が多いからである。
Issueに取り組もうとして別の問題に気づいてそこに対処していたらPRの形になった、というパターンが多いだけであるが。
正直コードを書いているより、動作を確認したりIssueやPRの説明を英語で書くのに四苦八苦している時間のほうが長い。
コードに関しては、こんなコードで大丈夫だろうかとか、微妙なコードでレビュアーに負担を与えはしまいかとか、明確にだめとは言えないけど良くもなくて中途半端だなとか思われないだろうかとか、いろんな不安でいっぱいである。
しかしだからといって、せっかく書いたコードを送らないのは成長のチャンスを棒に振るうようなもの。エイヤとPR送るようにしている。先にも書いたとおり、私はずっとボッチ開発をしてきているので、誰かと一緒に作業していくという機会自体がめちゃめちゃ貴重なのである。
正直なところ、コードを書いてPR送ることこそ何よりも勉強になるので、特に私と同じような一人で開発しているとか勉強しているという人ほど、こういう機会を利用しない手はない。
PR送る上で気をつけていること 大したことではないのだけど、コミットする前にReformat codeを実行するようにするのは気をつけている。Macだとcmd + option + Lで実行されるやつ。
DroidkaigiアプリではcodeStyleが共有されているので、これを実行しておけばPRを送った後でスペースが足りないとかの機械的な指摘がぐっと減るので、PR画面が見やすくなると思う。
手作業でやると絶対忘れるので（去年の私はそうだった）、Android Studioでコミットする画面のBefore commitの部分のチェック項目にあるReformat Codeとかにチェックを入れておくのをおすすめする。
これにチェックを入れておけば、コミットする前に自動的にReformat codeが行われるので、PR送信後に機械的な指摘が減るはずである。
また、Save Actionsというプラグインを使うのもおすすめである。アプリをローカルで実行した際にReformat codeが走るようにできる便利プラグインである。Android Studioから検索してインストールできるので、気になる人は使ってみてほしい。
後はコミットの履歴をきれいにしたりというのも気をつけているつもりであるが、あんまり神経質になる必要はないと思う。
成長のチャンス チームで開発する機会がない私にとっては、Droidkaigiアプリの開発はとてもよい成長チャンスである。PRを送っている時点ですでに非日常なのだ。
PRでもIssueでも、これ大丈夫かな、クソコードって思われないかな、迷惑になってないかなと不安が渦巻いてしょうがない。しかしそんな心配しても、ダメなところはダメって言ってくれるだろうし、言われないとしても誰かが直すだろうし、あれこれ悩む前に送ってしまえでいいと思う。
やらかして恥ずかしい思いをしても、それは独学では得ることのできない貴重な体験である。そもそも参加しやすい雰囲気作りしてくださっているので、恥をかくなんてことを心配する必要はないのだけど。本当にスタッフの皆さんやレビュアーの方々には頭が上がらない。
せっかくの成長機会が目の前に転がっているのである。これを利用しない手はない。尻込みするくらいなら、どんどん飛び込んでいけばいいと思う。私はそう考えて突撃している。
幸いなことに、ちょうど今急ぎの用件が他にない。そのおかげでこのイベントにがっつり時間をとることができている。今後も最新技術のキャッチアップとあわせて、レビュアー・スタッフの方々に感謝しつつ、私にとっては大変貴重なこの機会を最大限利用しようと思う。
Adaptive IconをFigmaを使って作ってみた。
Adaptive Iconは、開発者側はアプリのアイコンとなる前景画像と背景画像の2種類だけを用意して、後のアイコンの形はOS（デバイス側）にまかせてしまうという仕組み（という理解を私はしている）。
今まではランチャーアイコンとして四角いやつと丸いやつの2種類を別途用意していたけども、これからは2種類の画像（前景と背景）さえ用意しとけば後はOS側（正確にはホームアプリ？）がアイコンの形をよしなに表示してくれる。
といってもAPI26からの機能なので、現実的には依然として普通のランチャーアイコンは用意しなければならない。
とはいえ今回Figmaを使ってアイコンを作ってみたが、25以下のための画像データを用意するのはそこまで手間だとは感じなかった。108dpでアイコンデータを作っているので、その画像をAndroid Asset Studioに持っていってランチャーアイコンを生成するだけだったので。
Figmaを使ってアイコンデータ作成 今回はFigmaを使ってアイコンデータを作成した。ちなみにベクターデータである。
作成したforeground画像とbackground画像を、Adaptive Iconとして表示した場合にどうなるかは、このツールを使ってシュミレーションしながら確認した。
Adaptive Icon非対応の端末用の既存のランチャーアイコンは、Figmaから書き出した画像データをAndroid Asset Studioを使って生成した。
こんな感じで作成。
これは重ね合わせた状態だが、前景と背景別々に作ってある。
どちらの画像も108dp四方になるように、108dpの矩形を別途用意した上で、その上にアイコン要素を描画するようにしている。そうしないとエクスポートした際に108dpの画像として出力できないからである。
作成した画像はforegroundとbackgroundそれぞれをSVGでエクスポートして、そのSVGファイルをVector Drawableに変換してAndroid Studioへ持っていった。
Vector Drawableへの変換はこのツールを利用した。
複雑な形状だとうまく変換できないこともあるので、適宜調整が必要だろう。Vector Drawableとしてうまく変換できたとしても、パスデータが複雑すぎるという警告が出ることもある。あまり複雑すぎるのも考えものである。
ちなみにFigma用のAdaptive Iconのテンプレートがあったので、こちら から利用させていただいた。
テンプレートのサイズはFigma上では432になっている。Adaptive Iconは108dpで作成するものだ。FigmaとかSVGの仕様とかに疎いのでよくわからないのだが、432のサイズでアイコンを作成してSVGでエクスポートしても問題ないのだろうか？
私はよくわからなかったので、アイコンサイズを108の大きさで作成した。
ちなみに432とか単位をつけずに書いているのは、Figma上での単位が分からなかったからである。432のままSVGエクスポートしてVector Drawableに変換すると432dpになってしまい、そこからXMLの数値を108dpに書き換えるだけで問題ないのかよくわからなかったので、最初からFigmaの段階で108のサイズで作成したというわけ。
ちなみにテンプレートは一旦フラット化してベクター情報に変換し、サイズを108に縮小してアイコン画像の位置調整のガイドとして利用させてもらった。
Adaptive Iconの対応状況 こうして作成したAdaptive Iconだが、これが表示できるかどうか使っているランチャー次第のようだ。
私の場合、実機Nexus6P（Android 8.1.0）に作ったAdaptive Iconのアプリをインストールしても、固定されたアイコンとしては表示されるものの、アニメーション（ぷるぷる動くような視覚効果）はしなかった。
Pixel Launcherだとぷるぷるするらしい。
Pixel2のLauncherでアイコン長押ししてふったりすると動いたりします — takahirom (@new_runnable) 2018年1月12日
私の使っているランチャーはGoogle Nowランチャーなので、Adaptive Iconにきちんと対応しているわけではないようだ。アイコンとして表示することはできるが、アイコンのシェイプを変えたり、アニメーションしたりしない。
試しに他のランチャーをインストールして試してみたところ、Adaptive Iconへの対応を謳っているランチャーであればAdaptive Iconがぷるぷるすることを確認した（私が試したのはNova Launcher）。
参考 3分で分かる？Android OのAdaptive Iconに対応しよう
Adaptive Iconのシミュレーションツール（Web）
Designing Adaptive Icons（各ツールにおけるテンプレートへのリンクあり）
SvgToVectorDrawableConverter.Web（SVGをVector Drawableに変換するツール）
Instant-Appを試してみた。FlexibleTimerというアプリを作って、Instant-Appに対応させてみたのである。
https://play.google.com/store/apps/details?id=jp.gcreate.product.flexibletimer
Instant-Appというのは、アプリをインストールすることなく使えるようにする仕組みで、今回作ったアプリはhttps://app.gcreate.jp/flexibletimer/にアクセスすれば試すことができる。（Androidからアクセスすれば実行できるはず）
Instant-Appを実行できる環境 今のところAndroid6.0以上の端末であれば動くらしい。
Android6.0（API23）以上の端末であれば、おそらく設定 > Googleの中にInstant Appsという項目があると思う。それを有効にすればInstant-Appが実行できる。将来的にはAPI21以上もサポートされるらしいが、今は23以上が要件。
1つ注意点があって、Instant-Appはどうもどれか1つのアカウントでしか有効にできないみたい。私は2つのアカウントを1つの端末で使っていて、片方のアカウントでInstant-Appを有効にすると、もう片方は無効になってしまう。
このことで何を注意しなければならないかというと、Chromeにログインしているアカウントと、Instant-Appを有効にするアカウントは揃えておけということである。揃えていないとChromeからInstant-Appを提供しているURLにアクセスしても、Instant-Appが実行されないからである。揃えていなくても、例えばSlackで共有されたURLを開けばInstant-Appが実行されるし、Google Playからサイトに移動しても起動するので、Instant-App自体が使えないわけではない。
用意したURL（これはアプリを作成する際にAndroidManifest.xmlに定義する）にアクセスすれば、Instant-App用のAPKをGoogle Playからロードしてきて、インストールすることなくアプリが実行される。
URLは実際にアクセス可能でなければならない。つまり、Webサイトを所有していない場合には使えないということになる。所有していない場合はFirebase Hostingを利用してねというQAがある。（Stackoverflow）
Instant-Appへの対応の仕方 今のところAndroid Studio3.0を使わなければInstant-App対応は不可能である。理由としては、3.0でなければInstant-Appを作成するために使うcom.android.featureプラグインが認識できないからだ。
まだ3.0は正式バージョンではないので、急いで対応しないとならないというものではないと思う。
既存のアプリをInstant-Appへ対応させるのは、そんなに難しい手順が必要なわけではない。たぶん、3.0でビルドできなくなったとか、gradleプラグインが対応してなくて動かないとか、そういった種類のトラブルに対応するほうがはるかに大変なだけだと思う。
細かいやり方はドキュメントを見てもらえばそんなに難しくはないと思う。
ちなみにcodelabで既存のアプリをInstant-App対応させる方法が一通り学べる。
はまったポイント foreground serviceが動かない Instant-AppではLong-running background serviceはサポートされていないが、foreground serviceは使うことができる。ことになっているが、現時点ではまだ対応されていないらしい。
Stackoverflow
Architecture Componentが動かない 私の場合LiveDataを使おうとしていたのだが、Instant-Appでは使えなかった。エラーは起きないが、LiveDataの変更が受け取れなかった。
https://issuetracker.google.com/issues/38493434
Content Providerの仕組みで初期化してるから、Content Providerが使えないInstant-Appでは動かないのではないのかということらしい。
しょうがないので、RxJava2のBehaviorSubjectに置き換えて対応した。
App Linksの設定 私はApp Linksにこれまで対応したことがなかったので、Android StudioのApp Links Assistant任せでやっていたのだが、App Linksについて、仕組みとか対応の仕方とかをちゃんと調べてからやったほうがハマりが少ないのではないかと思う。
特にAndroidManifest.xmlの記述に関してはちゃんとドキュメントに書いてあるので、App Links Assistantに任せるのではなく、ドキュメントを見ながら設定するように。ビルドすること自体は問題なくできるが、Google PlayにAPKをアップロードしたときにはじめて弾かれるので、設定ミスに気づくのが遅くなってしまった。
https://developer.android.com/topic/instant-apps/prepare.html#default-url
私の場合、1つのintent-filterにhttpsとhttpの両方を設定すること、<meta-data>タグでdefault-urlの設定をすることが漏れていて、無駄な時間を過ごしてしまった。
サイト側の設定 私の場合はhttps://app.gcreate.jp/flexibletimer/というURLの、Webサイト側の設定をどうするかという話である。
必須なのはhttps対応することと、有効なドメインを持つこと、後は該当サイトにアクセスできるようにWebサーバを用意することだ。
Instant-AppのためにはApp Linksの対応が必要なので、https://developer.android.com/training/app-links/index.htmlを確認しながら設定すると良い。
Instant-AppのAPKはGoogle Playに置くだけであり、サイト側ではドメイン直下に.well-known/assetlinks.jsonファイルを配置するだけである。
ただこのApp Linksの設定は、Instant-Appの実行に関してはあまり意味は無いのだと思う。これはあくまでApp Linksの設定だから、インストールしたアプリがある状態で、指定したURLにアクセスしたときにアプリが起動するようにするための設定だと思うので。
しかしそうすると、なぜ指定したURLにアクセスするとInstant-App用のAPKがGoogle Playから読み込まれるのかがよくわからない。
仕組みがよくわからないので、どう設定したらどう動くのかが知りたくて、今回試してみたわけである。
とりあえず、用意したURLにアクセスすればGoogle PlayにアップロードしたInstant-AppのAPKが読み込まれてアプリが実行されるという仕組みのようで、Webサイト側は特別な設定は必要なかった（App Links用のjsonファイルを用意するくらい）。
現状ではcanaryバージョンのAndroid Studio3.0を使うので、Instant-Appがどうのというより、Android Studioのバグに振り回されることのほうが多かった気がする。
Instant-Appは利用者同士がコンテンツを共有するようなタイプのアプリの場合、特に効果的だと思う。むしろ今回私が作ったような、アプリ単体で完結してしまうようなアプリの場合、Instant-Appである意味はあんまりないと思った。アプリ内でやり取りされるコンテンツを、アプリをインストールしていないユーザに対して簡単にアクセスできるようにするのがInstant-Appの強みだと思う。
とりあえず軽く触ってみた。
codelab
Google IOの動画はとりあえず2つ見てみた。
最初のやつは「こんなん作ったでー」という話で、2つ目がその中身を説明っていう感じなので、時間がないなら2つ目だけ見ればいいんじゃないかなと思う。全部英語なので、私の英語力では雰囲気しかわからず時間対効果はあまり良くなかった気がしている。
3つ目もあるのだけど、これはまだ見れていない。タイトルから見るとRoomについての説明なのだろうか。
個人的にArchitecture Componentで気になっていたのは、いかにActivityのライフサイクルに振り回されなくてすむようにできるかという部分だ。つまり、LifecycleOwnerとLiveDataとViewModelについてである。とりあえずその観点で言うと、最初にあげたcodelabを触れば、雰囲気はわかった。2つ目の動画でだいたいスタンスがわかったような気がしている。
たぶん2つ目の動画で話していたと思うのだけど、このArchitecture Componentはすでに個々の開発者がそれぞれの工夫でActivityなどのライフサイクルによる呪縛を回避している手段を置き換えるためのものではないという話が、個人的にはしっくり来た。すでにライフサイクルとの付き合い方がうまくできている人は、別にそれでいいと。
ただ、Androidをこれから学ぼうとする人にとっては、Android特有のライフサイクルにまつわるあれこれは、学習していく上でつまづきやすいポイントで、さらにそれを回避するためのライブラリの使い方を学ぼうとすると余計にややこしくなってしまう。そこで、これからAndroidを学んでいく人にとって、とっつきやすいシンプルな仕組みを用意したよ、というのがArchitecture Componentということらしい。
私は最近ではDaggerやRxJavaを使って、Activityにはデータを持たせない、単に表示するだけのものとして扱うようにしてアプリを作るようにしている。そういった方法ですでにうまいこと回せているなら、無理して移行する必要はないのだろう。すでにうまいことやっている人にとっては、ちょっと触れば雰囲気がつかめるだろうから、とりあえずcodelabだけ触って雰囲気を掴んでおいて、1.0が出るのを待つくらいのスタンスでいいんじゃないかなと思う。
以下は触ってみた感想。
LifecycleOwnerとは ざっくりした理解で言うと、ActivityとかFragmentとかServiceとか、Android特有のライフサイクルをもってるオブジェクトのことという認識でいる。
LiveDataの購読を行う際に引数に指定してやったり、ViewModelの生成・取得を行う際に引数に渡したりするのに出てくる。
LiveDataの購読に関しては、LifecycleOwner（Activityとか）のライフサイクルにあわせて自動的に購読解除してくれるらしい。つまり、いちいち自分でunsubscribe/disposeとかしたりしなくていいっていうこと。
またActivity等のライフサイクルにあわせた処理を行うのに利用したりできるっぽい。（codelabではLocationManagerから位置情報を受け取るクラスを作って、Activityのライフサイクルにあわせてセンサーの登録と解除を行うのに使っていた）
LiveData UIに表示したりする実際のデータ。DataBindingでいうObservable<Hoge>みたいなものだし、RxJavaでいうObservable<Hoge>みたいなもの。
その実態は最新の値を保持してよしなに通知してくれるデータホルダー。RxJavaみたいなストリームではないよということだ。またスレッドの概念も持ってないので、バックグラウンドで処理してメインスレッドで通知みたいなことはしない。
LiveDataの更新はメインスレッドでないとできないみたいで、別スレッドからLiveData.setValue()したら落ちた。別スレッドから値を更新したい場合は、postValue()を使うらしい。
ActivityなどのViewは、このLiveDataを購読して、変更を受け取ったらUIを更新することだけ考えるような作りにするのが良いのだろう。
RxJavaでいうBehaviorSubjectみたいな動きをするなぁという印象を持った。
ViewModel 画面回転してもライフサイクルが継続してくれるもの。これが最初からあればAndroidアプリ開発はもっと楽になっていただろうと思う。
今までActivityにもたせていた状態やロジックを、全部こっちに持ってくればうまいことできると思う。
Activity.finish()を呼び出したらViewModelのライフサイクルも終了する（ViewModel::onCleard()が呼び出される）。
画面を回転させた場合はそのまま以前の状態を引き継いだものが、再生成されたActivityに渡ってくる。ただ、あくまでonConfigurationChangeで破棄されないだけなので、ホーム画面に一度移動した後にOSによって終了されたりした場合（Activityを保持しないが有効になってたりした場合）はViewModelのライフサイクルも終了してしまう。
データの永続化は別途考えないといけない。
軽く触ってみて RxJavaなどの知識を持っているからか、割りとすんなり使えそうな気がしている。
それを抜きにしてもそんなにややこしくないと思うので、Androidをこれから学ぼうという人はとりあえずArchitecture Componentの使い方を学ぶと、シュッと入門できていいんじゃないだろうか。
触る前は「なんかいろいろあってややこしそうだな」とか思っていたのだが、触ってみると思いの外それぞれ独立していて、使いたいコンポーネントだけ利用すればいいという意味がよくわかった。
私個人としては、ViewModelはすぐにでも使いたい。Daggerを使って似たようなことをやっていたけれども、ViewModelを使うほうが楽だ。LiveDataはもうちょっと調べて、DataBindingとの組み合わせ方を掴んだら置き換えるかもしれない。
RecyclerViewを使うときに必ず実装するであろうRecyclerAdapter。List<Hoge>をRecyclerViewに表示するのに使う。
単にリストを表示するだけならあまり迷わないのだが、プラスアルファの処理を行う必要が出てきたときに私はよく悩む。例えば、現在進行形でもにょっているのが、リストのアイテムををスワイプしたらそのアイテムを削除したいというケース。とりあえず実装して動いてはいるのだが、削除に関するコントロール処理をどこに書くのが適切なのだろうかという疑問に対する明快な解を持ち合わせていない。
最近触っていないけど、FilteredHatebuというアプリでは削除に関する処理をPresenterに担わせた。Adapterは単にList<Hoge>とRecyclerViewの橋渡しをするだけというシンプルな作りだ。
一方で、現在作っているアプリではAdapterで削除に関する処理を行っている。この2つの違いがなぜ生まれたかというと、AdapterがList<Hoge>を持っているかどうかという問題に行き着く気がする。
RecyclerViewやListViewを使うとき、ネットで見かけるコードではAdapterにList<Hoge>を持たせるものをよく見かける。コンストラクタを使って渡すなり、セッターを使うなりして、AdapterにList<Hoge>をセットしてやる手法だ。単に表示するだけならこれで問題はないのだが、削除に関する処理を行おうとすると混乱し始める。
削除処理はList<Hoge>のアイテムを削除する処理を内包する。RecyclerViewの2番めのアイテムがスワイプされたら、List<Hoge>の2番めのHogeを削除しないといけない。ではその削除を実行するのは、AdapterなのかそれともActivityなのか、それとももっと他のもの（例えばPresenter）なのかがよくわからない。
List<Hoge>の操作が必要なのだから、List<Hoge>を管理しているものが削除すれば良い。となったときに、AdapterがList<Hoge>を持っていることが多いので、そのままAdapterに削除処理を実装することが多いのである。
削除可能なRecyclerViewの実装について、ベストプラクティスが知りたい。そして知りたいと思ったときに、ふと「そもそもAdapterにList<Hoge>を持たせるのはどうなんだろうか」と疑問に感じたのである。
私の理解では、AdapterはList<Hoge>とRecyclerViewの橋渡しをするもの、つまりHogeクラスを表示するためのViewに変換するのがその責務という認識だ。その認識からすると、AdapterにList<Hoge>をもたせて削除に関する処理が加わっている今作っているAdapterは、AdapterではなくてControllerになってる気がする。
そんなことを考えていると、そもそもRecyclerViewでアイテムをスワイプして削除させるのが間違っているのではないかという気分にもなってくる。別にAdapterにどれだけの責務をもたせるかは、開発者のさじ加減であって、個人の好きなようにしたらいいのかもしれない。
そんな堂々巡りのはて、まあ動けばいいかという結論に落ち着く。削除可能なRecyclerViewの実装、みんなはどうやっているのだろう。
こっちのブログで書くか、別のブログで書くか迷ったのだが、プログラミングの話だしこっちに書こうかなと思う。
書こうと思ったきっかけは、Androidプログラミングを教える仕事を受けたこと。まあ個人的に、私などが人様に何かを教えるなどおこがましいという思いはあったものの、まあ何事もやってみなければわからないということでやってみた。
Android特有の、ライフサイクル周りの話だとかは、まあ知っていないと辛いよねっていうことではあるんだけど、それよりもっと基礎的な、プログラミングを学ぶ姿勢とでも言おうか、今回書きたいのはそこについてだ。Androidプログラミングとタイトルにしているのは、私がAndroidしか知らないから限定しているだけで、たぶん他の言語でも同じなんじゃないかなと思う。
私はずっと一人でAndroidのプログラミングをやってきた。ほぼ独学である。書籍とネットの情報を頼りに黙々とやってきた1。そんなやつが人様にプログラミングを教えるのもおこがましい気がするものの、3ヶ月間教えてみて大事だなと思ったことが3つある。
1つ目は言ってしまえばコミュニケーション能力である。いきなりプログラミング関係ないじゃないかと思われるかもしれないが、これはとても大事である。別に話を弾ませたり、相手の気持ちを慮ったりする能力が必要だというわけではなく2、自分の考えを相手に伝えようと努力できることって、プログラミング関係なしに大事だなと思ったのである。具体的なシチュエーションとしてはエラーを伝える場面でよくそう思った。なんだかよくわからないけれどもこういうエラーが出たんですと、わからないなりに説明しようとする人とそうでない人がいる。エラーの確認の仕方は知っているかどうかの問題なので、初心者だから見込みがないとかそういう話ではない。しかし、わからないなりに説明をしようとする人に、私は伸び代を感じたのである。
2つ目はチャレンジ精神である。とりあえずやってみることが大事だということ。こう書いたら動いた、だったらこう書けば違う動きになるのではないかと仮説を立てて、挑戦してみる姿勢が大事だ。知らなければどうしようもない部分もあるので、教えてもらうことも大事ではあるが、教えてもらうのを待つだけではなく、自ら挑戦する姿勢もまた大事なのであると言いたい。
3つ目は自分で調べる力である。Androidは特にソースコードがすべて公開されているので、なぜそう動くのかはコードを読めば分かる3。ソースコードを読むのでなくても、公式のドキュメントを読んで調べることなら誰でもできるはず4。Androidのプログラムを書いていると、便利なライブラリのお世話になることがとても多いが、そういったライブラリの使い方を、ライブラリのドキュメントやソースコードから調べることは重要だ。
以上3つ。プログラミングを教えているのに、プログラミングの知識、変数がどうのとかJavaがどうのとかとかよりも、もっと基礎的なことの方が大事に思えたことが意外に感じられた。
最後に、これからプログラミングを勉強しようと思っている人は、できるだけ効率的に学びたいなと思っていることだろう。きっと、いい師匠（先生）を見つけるのが効率的なんだろうけれど、どうやって探すのかは私が知りたい。だからそんな効率的に学ぶ方法を探す前に、さっさと何かプログラミングしてみる方が早いと私は思っている。
Androidプログラミングで言えば、とりあえず市販の本でもネットの情報でもなんでいいので、とりあえず書いてあるとおりにやってみるのがよいと思う。書いてある通りにやってうまくいかなければ、誰かに聞くのがいいだろう。
実は、そういう「書いてあるとおりにやってみたけど動かない」という状況は、スキルアップにちょうどいいシチュエーション5なのだけど、初心者はただ辛いだけなので、誰かに聞くのが手っ取り早い。Twitterでつぶやいてみるとか、teratailとかStackoverflowとかで質問してみるとか6。学校の先生がいるなら、先生に質問するのがいいだろう。聞ける人がいるということはとても恵まれたことなので7、そんな環境にいる人は今のうちに有効活用するべきだと思う。
大事だと思った3つのこと。コミュニケーション能力、チャレンジ精神、自分で調べる力。何にでも言えることじゃないかと思うけど、何にでも言えるからこそ大事なんじゃなかろうか。実際、教えていてこの人はプログラムに向いている・向いていないと感じることが何回かあった。それはなぜそう思うのかと考えてみたら、プログラミングの知識よりも本人の姿勢によるところが大きいと思ったのだ。
ネットで公開される知見に頼るところが大きいのでとてもありがたく拝見している ↩ あるにこしたことはないが ↩ 理解できるかはともかく ↩ 理解できるかはともかく ↩ 原因を調べて解決することは、プログラミングをしていく上で何度も通る道であり、そういうハマりを経て人は成長していくのである ↩ 質問する敷居の高さは、teratailの方が低いとは思うが、思い出してほしい。コミュニケーション能力が大切だということを。インターネット上の人々はあなたの状況を理解しているエスパーではないので、聞き方が悪いと答えは返ってこないどころか、逆に傷つくことになるかもしれない。 ↩ 学生という立場は学生という立場を失ってはじめてそのありがたみが分かるのだ ↩
Firebase Crash Reportingを使ってみた。今まではCrashlyticsを使っていたのだが、最近はFirebaseをアプリに組み込むことが多いので、クラッシュレポートもFirebaseでやってみようかなというのがことの始まり。
導入手順的に考えると、Firebase Crash Reportingはとても簡単。Firebaseを使うプロジェクトであれば、dependenciesに'com.google.firebase:firebase-crash:<VERSION>'を追加するだけで終わり。これだけでアプリがクラッシュしたら勝手にレポートをあげてくれる。
Firebaseを使う設定に関しても、Android Studioに組み込まれているFirebaseのツール（？）を使えばいとも簡単に使えるようになるので、導入の敷居はCrashlyticsに比べるととても楽である。
一方で、Crashlyticsと比較すると面倒くさいポイントもいくつかあって、単純に乗り換えればいいやという話でもなさそうなのが悩ましい。
mapping.txtのアップロード ProGuardをかける場合に難読化されたスタックトレースを解読するため、mapping.txtのアップロードが必要になる。Crashlyticsの場合、設定が必要だが自動的にアップロードを行ってくれる。
一方でFirebase Crash Reportingは自分でFirebase Consoleにアップロードしなければならない。gradleタスクでアップロードするための方法が用意されてはいるが、Crashlyticsと比較すると「自動アップロード」とはいえない。初期導入が簡単な反面、ProGuardのmapping.txtをアップロードする設定を行う手間がある。
https://firebase.google.com/docs/crash/android
ルートのbuild.gradleのclasspassに`'com.google.firebase:firebase-plugins:1.0.5'`を追加 app/build.gradleに`apply plugin: 'com.google.firebase.firebase-crash'`を追加 Firebase Consoleからプロジェクトの設定→サービスアカウント→クラッシュレポートから、新しい秘密鍵の生成を行いダウンロードする（jsonファイル） ダウンロードしたファイルへのパスを`FirebaseServiceAccountFilePath`というプロパティに記述する1 `./gradlew :app:firebaseUploadReleaseProguardMapping`を実行してアップロード（buildVariantなどによってタスク名は変わる） `firebaseUploadXXX`というタスクを実行しないといけないので、そのままだと確実に忘れそう。`assembleRelease`を実行したらこのタスクも実行するように指定できたらなぁと思ったのだけど、やり方がわからなかった。 そして依存させるなら、assembleReleaseよりもapkをGoogle Playにアップロードするタスク（自動化しているなら）に依存させるのが良さそうではある。
debugビルドでアップロードしてほしくない問題 Firebase Crashは特に何もしなくとも、アプリがクラッシュすればスタックトレースをアップロードしてくれる。カスタムApplicationクラスに初期化処理を書いて・・・なんてことすら必要ない。ContentProviderの初期化の仕組みを使ってライブラリ側で勝手に初期化しているとかなんとか見た気がする。ある意味便利ではあるが、一方で不便なところもある。それは、クラッシュレポートを送信させない手段が存在していないところである（たぶんない）。
CrashlyticsはカスタムApplicationで初期化をする必要があり、ここで例えばデバッグビルド中は送信しないようにしたり設定できる。Firebase Crashにはそういうのはないっぽい。そもそも自分で初期化しないし、送信を停止するようなメソッドも見当たらない。
これはFirebase CrashをreleaseCompileで組み込めば一応回避は可能である。
一方で、プライバシーポリシーの問題というか、ユーザの許可を得ずにクラッシュ情報を収集してよいのかという問題があると思う。このあたりの法的問題に、他の開発者さんはどう対処しているのか私は知らないが、個人を特定する情報は含まれていないとしても、例えばユーザにクラッシュレポートを送信しないような選択肢を提供したいときに、Firebase Crashではそれができないということになる。クラッシュレポートについてオプトアウトできるようにしてあるアプリがあるのかと言われるとよくわからないけれども。まあもし対処する必要が出てきたとしたら、きっとしれっと無効にできるようにアップデートされるのかもしれない。
logとreport Firebase Crashは基本的には組み込めばそれで終わりな感じで、後は任意のタイミングでFirebaseCrash.log()とかFirebaseCrash.report()などを使ってクラッシュ時の情報を付け加えるくらいしかやることはない。
log()はクラッシュレポートにイベントとして情報を追加することができるものである。
report()は例えばtry~catchでcatchした例外のスタックトレースを送信するのに使う。
私はどちらもうまいこと使いこなせる自信がない。今までもクラッシュレポート見ても、一体どういう状況で発生しているのかよく分からなくて対応ができなかったことがよくある。log()を使えば原因を特定するのに有効な情報を付け足せるのだろうが、どういう情報を付け足せば原因把握に役立つのかはいまいち分からない。
gradle.propertiesなどで指定すれば良い。プロジェクトルートに秘密鍵のファイルを配置したのであれば、`FirebaseServiceAccountFilePath=../＜秘密鍵のファイル名＞`という感じ。 ↩
コードから動的にViewを生成したい時がある。そしてそのとき見た目をカスタマイズしたいなんてときがある。もちろんsetBackground()とかsetPadding()を呼び出して設定することは可能であるが、どうせならXMLでやるときのようにstyleを適用したい、なんて場面があるだろう。・・・私にはあった。
さてそんなときに、どうやったらJavaのコードでnewしたTextViewにstyleを適用できるのだろうか、という話。2つ方法があって、どちらもコンストラクタでstyleを指定する。
1つはViewのコンストラクタに引数を4つとるものを使う方法。new TextView(context, null, 0, R.style.some_style);という感じでTextViewを生成する。ただし引数4つのコンストラクタはAPI21からしか存在しないので注意1。
もう1つはContextThemeWrapperを使う方法。new TextView(new ContextThemeWrapper(context, R.style.some_style));という感じで生成する。こちらも同じくJavaコードから生成したViewに、styleを適用することができる2。droidkaigiのアプリにコントリビュートしたら学べた方法3。
ただし、どっちの方法でstyleを適用しようとも、LayoutParamsに関する設定だけは無視されることに気をつけたい。私はstyleにandroid:layout_marginを指定していたのだが、Javaのコードから生成した場合、marginが無視された。
レイアウトXMLでstyleを適用した場合は、marginも含めてstyleが適用される。しかしコードからだと適用されない。これはコードからstyleを適用した場合、コンストラクタでViewを生成した時点ではViewがLayoutParamsを持たないからだと思われる。
そもそもLayoutParamsはView自身が使う情報ではなく、そのViewを配置するViewGroupが利用する情報になる。コードから生成した場合、このLayoutParamsは親レイアウトにaddView()を行った時点で設定される。もちろんsetLayoutParams()を呼び出すことで事前に設定することも可能だが、コンストラクタを呼び出しただけでは生成されないことがポイント。つまり、View自身に関わるpaddingなどの情報はstyleの適用で設定されるけれども、LayoutParamsに関する情報は設定されないということである。
コンストラクタでLayoutParamsも持たせればいいのにと思うかもしれないが（私も思ったが）、どのViewGroupに配置されるのかがわからないので、コンストラクタの時点でLayoutParamsを設定することは無駄なのだと思う。プログラマが事前にどのViewGroupに配置するか決めているのであれば、setLayoutParams()を使えということなのだろう。
そもそもstyleにLayoutParamsに関する情報をもたせることが間違いなのかもしれない。今まで特に気にせずにstyleでLayoutParamsに関する情報を持たせていたが、実は推奨されないやり方だったのだろうか。
ちなみに、今回の出来事ではじめて知ったのだが、XMLでandroid:layout_xxxとなるのがLayoutParamsらしい。どれがLayoutParamsなのかわからないじゃないかとか思ったけど、自明だった。
ちなみにViewクラスにはsetStyle()みたいなメソッドは存在しない。よく考えてみると、XMLファイルでstyleを適用する際に、なぜかstyleだけはnamespaceがつかない。基本的にViewに要素を書くときは、android:xxxだったりapp:xxxといった感じで頭に必ずnamespaceをつけるのに、直接style="xxx"と書く。つまりstyleの適用だけは特殊な扱いなのだろう。
setContentView()からだとstyleに書いたLayoutParamsが有効になるが、addView()だと無視されることも、このあたりが関係しているのかもしれない。
ちなみに引数3つのコンストラクタの第3引数はdefStyleAttrで、`R.styleable.xxx`を指定するためのものであり、styleを渡したところで適用されない。 ↩ LayoutInflaterがViewをinflateするときにこの方法でinflateしている。 ↩ https://github.com/DroidKaigi/conference-app-2017/pull/401/commits/1812e77a4e3cb598e94714cf12cd83b01d716c79#diff-13d7c85c29370a83d0d27462c1d57f2aR76 ↩
Page 2 of 7
