未処分利益

日記 メモ 映画 小説 感想 読書 Android iOS

トップ > android > potatotips #56 参加報告 (Android)

potatotips #56 参加報告 (Android)

android メモ 日記 勉強会

potatotips #56にAndroidブログ枠として参加させていただきましたので、Androidの発表内容をまとめました。

https://github.com/potatotips/potatotips/wiki/potatotips-56

開催場所はスマートニュース株式会社 さんです。

Android8.0のPush受信時のサービス挙動

発表者は @hideo さん

SmartNewsのAndroidアプリ開発で遭遇したバグについての話。 具体的には、Push受信時にNotificationへの表示用途画像をダウンロードするServiceを起動した際、たまにクラッシュしてしまうという不具合。 （ちなみに、SmartNewsのiOSの発表者の方も遭遇した面白いバグの話をされていた）

発表資料

Android 8.0 (以降 Oreo)から UX向上のために、アプリがバックグラウンドで実行される場合の動作に対して厳格なリソース制限(?)を課すようになってしまった。それによりバックグラウンドServiceの作成が許可されない状況下でOreo以降を対象とするアプリが startService() を実行すると問答無用で強制終了になってしまう。

個人的にも、かつてその変更に気づかず下記のExceptionがポツポツと日々のクラッシュレポートに上がってきて「？！」と目を見張った記憶があるので、今回のLTには凄い共感を伴って聴けた。

Caused by: java.lang.IllegalStateException: Not allowed to start service Intent

フォアグラウンド状態が終了して60秒以内であれば一応バッググランド処理の実行は可能なことから、 画像のダウンロード自体はその猶予内で十分可能だろうと考え、Service#startService()が完遂できないで失敗した時のことを考慮するという方針で切り抜けたとのこと。

一応、Android OS側 でも以下に挙げる処理についてはバッググランドサービス可能なホワイトリストタスクとして数分間の処理時間を提供してくれてはいるが、それらに該当しない場合は「JobSchedulerで頑張ろう！」という認識になっている。

  • 高い優先度の Firebase Cloud Messaging（FCM）メッセージの処理
  • SMS/MMS メッセージなどのブロードキャストの受信
  • 通知からの PendingIntent の実行

ただJobSchedulerは条件設定等で生じるBackoff（条件が合致せず時間を置いて再実行する）遅延などを考慮しなければならないので、個人的には複雑性が増して頑張る勇気は中々持てない。 （対応したい処理の規模によるけれど）

How to contribute GPUImage-android

発表者は @kettsun0123 さん

https://github.com/cats-oss/android-gpuimage

上記のAndroid版GPUImageへのコントリュビュートの方法を解説。 手っ取り早く参加できる方法としては、GPUImage2(iOS)を参考にAndroid版に無いFIlterを作っていくのが良いとのこと。 GPUImage-Androidを盛り上げていこう！

5分でわかるKotlinコルーチン

発表者は @yshogo87 さん

厳密なKotlinでのCoroutineの位置付け・意味合いについては語られるコンテキストによって未だ確固とした像を掴むのが難しい。 そこで最初は様々な非同期処理を管理するものというイメージをスタート地点として触ると理解が進むだろうという話。 Rxjavaの代替えでは無いという点を強調されていた。

発表資料

個人的にはGoogle Developer Expert の方々の資料等を見ながら使い方のベストプラクティスを模索しつつプロダクトコードへ混入させている。今の所 CoroutineScope を作ってsuspendな非同期処理をDispatchers.IOで実行してDispatchers.Mainで待つという、この一連の流れからコールバック的な記述を排除できるようになったことには地味に感動。

そういえば、この前のAndroidDevSummit で ViewModelとWorkManager から Kotlin coroutine が直に使えるようになるという発表があったのだけれどその行方が気になるところ。

OSS開発のリテラシー / Android編

発表者は @gfx さん

OSSを作る上でのベストプラクティス（エチケット）についてMUST事項とSHOULD事項を分類して網羅的に解説。

発表資料

https://github.com/gfx/android-oss-best-practices https://paper.dropbox.com/doc/OSS-Android-3Zp3zkvV2mJFF8gcpNyO5

MUST事項として特に重要なOSSライセンスの掲出有無や、歴史や経緯を辿る為のtag付の徹底、メンテナーの学習コスト（開発環境・ビルド方法）削減を意図したCI設定や、OSS運営で詰まないためにbintray成果物公開時のorg作成必須化等、まさにOSS開発・運営の経験に基づいた気づきの数々で説得力があった。

もっと！ Alternative Resources

発表者は @takasfz さん

「グローバル展開するアプリにおいては、国に適応したUXへ対応することは重要」という件から始まり、Alternative Resourcesを利用することでそれが簡単に実現できてしまうよという話。

発表資料

layout-ja で実際に日本とそれ以外の国で異なるUIを1apkで出し分けができるのは凄い便利。 利用可能なconfig_qualifierの特定もポチポチとGUIで選ぶだけだから簡単。 Alternative Resourcesを使いこなすことで結構な量のコードの削減が見込めそうだ。

Dynamic Links 知られざる？Firebaseの秘技

発表者は @affinity_robots さん

Firebaseが提供するDynamic Linksの有用性について解説した発表。 Dynamic Linksは一言で言うならば「アプリに対するすごいリダイレクトリンク」 1つの短縮URLで各プラットフォームごとにリダイレクトが可能で、しかも未インストールの場合は、ストアからのインストールを経由してからでもディープリンク判定ができてしまう。 そして何よりデバッグが簡単。

発表資料

AndroidとiOSどっちが早く作れるか-今夜くらべてみました

発表者は @kboy_silvergym さん

iOSアプリエンジニアの方が実際にAndroidアプリ開発をしてみてどちらの方が開発し易いのかを分析した話。

題材のアプリは下記。 https://github.com/kboy-silvergym/Kinniku.kt-iOS https://github.com/kboy-silvergym/Kinniku.kt-Android

UIStackViewに慣れていると、性質的に近いLinearLayoutに親しみが湧くというのは凄く理解できた。 Android Studioならばdependenciesを追加するだけでSyncを促してくれたり、言われるがままにしていればFirebase連携も容易にできてしまうという開発者フレンドリーな環境目線で比較すると「ジョブズが通りやすいXcode」に対してASの方に軍配は上がり、結果Androidアプリ開発が楽という印象に収束するのか（笑）

ただ、最近はMigrate to AndroidX問題や公式で提供されるdependenciesの数が多すぎて何が必要なのか取捨選択に頭を悩ます場面もままあるので個人的には何とも言えないところ。

@kboy_silvergym さんが携わっている 筋肉.kt 面白そう https://kinniku-swift.connpass.com/event/99895/

Kotlin Android でMVIアークテクチャを採用する

発表者は @itometeam さん

MVI Architectureでのアプリ開発についてアーキテクチャーの概要紹介とアーキ採用に伴うメリット・デメリットについての解説

発表資料

ViewModelの中で Intent -> Action -> Result -> State と処理を進めてデータを変換しながら状態を変えていく単方向データフローなパターン。

メリット

  • コードの書き方に制約があるためチーム開発に適している
  • テストが容易にかける
  • Rxのエラーハンドリングをそのまま使える

デメリット

  • 1回きりのイベントを伝えるのが難しい
  • 複雑なレイアウトではViewStateの更新が重くなる
  • コードが冗長になる（登場人物がやや多い）

アーキ採用判断についてはチームの規模と状態を考慮するのが肝要とのこと。