2019年10月を振り返る

今年も残り12.1%

師走はすぐそこですね。。!

11月も半ばを過ぎてしまいましたが、あんまり気にせず、、10月をざーーーーーーっくり振り返ります。

振り返り

「天気の子」展に行った

銀座の松屋で行っているという新海誠さんのツイートを見て、暇だったので急遽行ってみることに。かなり久しぶりの銀座でした。

「天気の子」展自体はわりと人がいてさささーっと見てきました。一番盛り上がるシーンの映像とかが音楽付きで流れていたりして勝手に盛り上がりました。楽しかったですね。

f:id:shaunkawano:20191118002712p:plain

函館に行った

友人の結婚式&出張が重なり、ついでに観光も重ねようということで、お休みもいただき観光してきました。

友人のスピーチで特に感動して最高の結婚式だったし、ご飯とかも言わずもがな最高でした。また行きたい。ラッピはめちゃくちゃ行きました。もちろんおしゅしも食べました。

f:id:shaunkawano:20191118002638p:plain

実家に帰った

年末年始などシーズンを避けて帰ることもあるんですけど、今回は家族会議的なものがあり帰っていました。ちょっとでも手伝いができてよかったです。かっこいい兄にもしびれました。

f:id:shaunkawano:20191118003831p:plain

その他

久しぶりのことをしようということで、ボーリングやパズルとかやりました。

f:id:shaunkawano:20191118002701p:plain

f:id:shaunkawano:20191118002654p:plain

パズルは完成まで3日くらいかかりましたw雲の部分が特に難しかったですw

以上!すぐ11月の振り返りも書きますん。

Androidブログ枠でpotatotips#66に参加してきた

Androidブログ枠として参加

2019/11/11のポッキーの日にpotatotipsがあり、参加してきました!今回のpotatotipsの会場提供はyappliさんでした!ありがとうございました! Androidブログ枠として参加したので、ざっくりAndroidやクロスプラットフォーム関連の発表の振り返りを雑に行います。

potatotips.connpass.com

当日のpotatotipsのイベントページは↑です。

写真

f:id:shaunkawano:20191114105329p:plain

キレイなオフィス!

f:id:shaunkawano:20191114105320p:plain

ポテチもたくさん!

内容

以下は、内容を軽く振り返り感想や雑メモなどです。

プラットフォームにおけるビルド 〜ビルドの仕組みとその改善について by @lai2580

speakerdeck.com

プラットフォームにおけるビルドの話でした。今までは、アプリ1つ1つにたいして1プロジェクト作成し、それをエンジニア自らビルドマシンでビルドしていたところから、もともとサーバーサイドのほうで採用されていたCircle CIを導入してスピード改善を行ったとのことでした。CI等のツールの知見は、プラットフォームにおけるビルドとなるとなかなか世の中にもあまりなかったりするのかな、と、自分は今まで一般的なアプリ開発しか経験がないので、つらみのスケールも違いそうだなと感じました。

Android エンジニアが Flutterに入門して驚いたこと3点 by @numatch2552

speakerdeck.com

Androidエンジニア目線でのFlutter入門の話でした。Flutter Doctorで最初はめちゃ怒られるけど怖くない(1つつずつ解決していける)こと。Pluginが入れやすい、使いやすく、「Flutterはプラグインで進化する」とのこと。Platformの機能に依存していないものも多いらしいです。Firfebaseを連携する際にも、ドキュメント充実しているから心配ない、とのことです!(Flutterあんまりさわれていない👼)

Edge-to-edge with Insetter by @_rmakiyama

speakerdeck.com

Android Qにて新しいジェスチャーナビゲーションが導入され、より没入感あるUXを実装するために、画面いっぱいにUIを広げて配置するEdge-to-edgeの実装が推奨されました。実装方法としてInsetterというChris Banesさんのライブラリが紹介されていました。楽に実装できそうですね。スライドにもありますが、このライブラリは後々Android Jetpack内部に移行するかもという記載がGitHubにあります。

The contents of this library may eventually be moved into Android Jetpack at a later date.

github.com

Firebase A/B Testing Targeting Tips by @mukky620

speakerdeck.com

実務でFirebaseを使う上でのハマったポイントなどについての話でした。Targetingにおいて、アプリバージョンを指定する場合、Androidの場合はversionNameを、iOSの場合は、versionではなくbundleVersionを利用するとのこと。iOSの場合、versionを指定するとコンソール上では対象者が表示されるのですが、こちらは間違いでbundleVersionを指定すると正しくターゲティングできるとのことで、ドキュメントにそのように記載があるのでコンソールの表示に関して不具合が起きているのではないかということでした。他にもAudienceとUserPropetyの違いなどが紹介されています。

How to test Coroutines in ViewModel by @hkusu_

speakerdeck.com

ViewModel内で定義されているsuspend関数のテストを行う方法についてです。通常のUnit Testの記述方法だと、ViewModelの関数の実行が完了するまでテスト自体が待機できず、完了前にテストが終了してしまい失敗します。この問題を解決する手段として、関数の戻り値をJobにしてテストコードで利用する方法、ViewModel生成時にCoroutineScopeを渡すようにし、テスト時にCoroutineScopeを差し替える方法、そしてViewModel作成時にDispatcherを渡すようにし、テスト時にはTestCoroutineDispatcherを利用する方法が紹介されていました。

Kotlin Multiplatform Projectで社内APIクライアントをつくる by @fusuma0325

speakerdeck.com

Kotlin Mutliplatformを用いて社内APIを用いたクライアントアプリを作る(特にPlatform別の実装周りについての)話でした。expectでいわゆるinterfaceのようなものを定義し、各プラットフォームでexpectに対応するロジックなどをactualを用いて実装する。Kotlin側でsuspend functionを定義する場合、iOS(Swift)側で利用するframeworkが生成されないため、Swift用にDeferred型を返す関数を用意したがクライアント側の実装詳細を知りすぎるため最終的にはラッパーなどを用意したとのことでした。(Kotlin Multiplatformあんまりさわれていない👼)

In-app updates on Android - Overview & Fitfalls by @kurun_pan

speakerdeck.com

In-App Updatesの概要と隠れた罠についての話でした。In-App Updates APIは基本的にGoogle Play Storeとの通信用APIと考えて問題ないとのことです。com.google.android.play:coreパッケージにあるとのこと。Google Play StoreのUI上でアプリ更新が利用できるかどうかで、このAPIもアップデート可能かどうかを判定しているという話が個人的には面白かったです。ただ、更新検知アルゴリズムがブラックボックスでアプリのアップデートリリース反映タイミングと異なるという点はなるほど難しいと思いした。サンプルコードなども用意されています。

github.com

まとめ

久しぶりにpotatotips参加しました。とても楽しかったです!思ったより時間がかかってしまったので、次はブログ枠以外で参加しようと思います!

#AskAndroid at Android Dev Summit 2019 - Jetpack Composeの内容をざっくりメモした

全部の内容は記載できていないです。もし間違いなどがありましたらご指摘いただけたら嬉しいです。

動画は下記です:

www.youtube.com

Q. いつalphaかbetaになるか?

来年Betaになる

Q. RecyclerViewのようなRecycling Logicなどはあるか?(静的なViewのみの利用を想定しているか?)

静的なViewというよりは動的なViewのために用意している。現状のPreviewにはRecycling Logicはないが、いずれくる予定。

Q. アプリを作成する上で、XMLではなくJetpack Composeのみの利用も想定しているか?

  • 0からアプリを作る段階でJetpack Composeを利用できる
  • 既存のXMLをCompose関数内部で利用したりその逆の方法などについても紹介している
  • 既存のコードと互換性のある形にしたいと考えている

参考:

www.youtube.com

Q. Jetpack Composeのパフォーマンスについて?

  • 現在はExperimental Compilerに頼り切っている状態
  • 現在は、アプリがかくついたりすることもある(現在は小さなことにもallocationなどをしていたりしている)
  • 既存のサンプルアプリはいい感じになっているはず
  • 今後よくなっていくはず

Q. LiveDataやDatabindingを使うよりもより良い・きれいな選択肢か?

  • LiveDataにかんしてはComposeを利用できる
  • Databinding似関してはアプローチが違う
    • DatabindingはViewを用いる
    • Composeは自動で再構成される

Q. 今後のXMLなどの既存コードからの置き換えについて?

  • 今の開発者たちはandroid.widgetにたいして親しみがある
  • 既存とはまったく違うやり方のものがある
    • 既存のシステムと1-1で対にならないものもある
      • JavaからKotlinへの変換のように簡単にはならなそう
  • 既存のViewコードの置き換えは、見た目の観点と、ロジックの観点などにおいて混合している
    • 機械翻訳のようなことが必要。取り組むには面白そうではあるが、現時点では目標としていることではない

Q. 既存のView構造に取り入れることはできるか?たとえばWebViewをComposeで表示するなど

  • 既存のComposeのRepositoryではComposeのWrapper上でWebViewを表示するようなことをしている

Q. 現時点でComposeを学ぶために一番適している場所?

Android Studio Canary 4.0が必要

Q. LinearLayoutの代わりにConstraintLayoutを用いた動的なViewの構成をサポートするか?

  • ConstraintLayoutはまだ
    • 将来的にはサポート予定
  • LinearLayoutについてはRowとColumnがそれにあたる

Q. フィードバックを送信するには?

Slack group

Stackoverflow

https://stackoverflow.com/questions/tagged/android-jetpack-compose

Issue Tracker

https://issuetracker.google.com/issues?q=jetpack%20compose

Bug報告

https://issuetracker.google.com/issues/new?component=612128&template=1253476

フィードバックはほしい。フィードバックと共に開発をしていく

Q. 「UI構築するにはJetpack Composeのほうが良くなる」というのは正式な回答か?

  • 新しいUI構築のための手段
  • 新しいUI構築の手段として開発者に提案しているものの一つ

Q. 違うスクリーンサイズの対応はどのように行われる?

  • Jetpack Composeでは簡単に対応できるようになるはず
    • 簡潔なコードで対応可能
    • ツールが手助けしてくれる
      • プレビューで簡単に確認できる

Q. Navigation Componentは利用できるか?

※ここはわからなかったです。(多分Fragmentのサポートは難しそう?) - Navigation Componentで利用できるのはFragmentだけではない

Q. ComposeとApply Changesは関係あるか?

  • あまり関係ない
  • 開発者はスムーズに開発がしたい
    • ComposeにおいてはPreviewがある

Q. Composeを使う場合、Layoutはどこでどのように描画されているのか?またこれらの方法は変わるのか?

  • XMLレイアウトを互換性のある形で利用する場合
    • 既存とあまり変わらない
  • Composeのみを利用する場合
    • ランタイムに初期化
  • 完全に既存の描画方法とは別

Notes - An Opinionated Guide to Dependency Injection on Android (Android Dev Summit '19)

f:id:shaunkawano:20191026000524p:plain

※Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたら気軽にご連絡いただけると嬉しいです!m(__)m)

本記事は、An Opinionated Guide to Dependency Injection on Android (Android Dev Summit '19)の記事です。

Dependency Injection

Car needs engine to work = Engine is a dependency of car = Car depends on engine

  • With dependency injection, those dependencies are provided to a class instead of the class creating them itself.
  • You should always apply dependency injection principle to your app
    • sets fundamentals of testable and scalable app
    • Reusability of code
    • Good balance of loosely-coupled dependencies
    • Ease of refactoring

Dagger

Recommendation

  • Does not use reflection
  • Recommended tool
  • Dagger is used on Gmail, Google Photos, Youtube

Steep learning curve..

  • Started providing a common guidance, which is a set of documentation from the basics to the complex topics
  • Codelab for Dagger

dagger-android?

  • Google is stopping its development
  • Adding no more feature
  • Trying to reduce the amount of code you have to write

Better Dagger code with Kotlin

Dagger + Kotlin = ♡

  • No more JvmStatic
  • Qualifier Annotations
  • Kotlin wildcards

Future versions

  • Some more improvements are coming
    • e.g. for companion object

Simple DI Approach in Android

  • still under construction
  • how it will look like
    • Focus on binding declarations

Bindings

The time you spend working on DI should really go to what you keep working on to scale your app.

Injection

  • Not just using @Inject, you should do some more extra work, for example to set up app component
  • Add @EntryPoint for Android component class
    • Tells that you want this Android component to be a entry point into the graph
  • Support and provide easy hookups for lifecycle related components like ViewModel

Components

  • Predefined Components
    • SingletonComponent
    • ActivityComponent
    • ServiceComponent
    • FragmentComponent

Jetpack DI Initiative

  • Integrated with Dagger
  • Jetpack Extensions
    • Fragments
    • ViewModel
    • WorkManager

Takeaways

  • Use DI
  • Use Dagger
  • Check out the guidance
  • We're improving DI in Android, so stay tuned!

所感・まとめ・個人的に印象に残ったことなど

  • 共通ガイドを作った
    • 基礎的なところから複雑なトピックまで扱ってるからみてほしい
  • Kotlinとの相性をもっと良くしていきたい
    • 今後のリリースでCompanion Objectに関連したリリースなども行う予定?
  • dagger-androidの開発今はやめてる
    • もっとよくできると思っているから
  • セットアップコスト、学習コストを下げていきたい
    • ActivityなどのAndroidのEntryPointとなるFrameworkに対して@EntryPointを付与することで、そのクラスを起因にグラフを作る、つまり今までのonCreate内でのComponentクラスのセットアップまわりの処理などを自動でやってくれるような仕組みとか
    • 他のLifecycleに関するAACのクラスなどをより簡単にDIできるようにする仕組みとか
    • 独自に定義しなくてもある程度一般的なComponentを用意しておくとか

DIはいいぞ、Daggerもいいぞ、どんどん良くしていくからぜひ使ってくれよな!感が伝わりました

以上です!

Notes - Fragments: Past, Present, and Future (Android Dev Summit '19)

f:id:shaunkawano:20191025202341p:plain

※Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたら気軽にご連絡いただけると嬉しいです!m(__)m)

本記事は、Fragments: Past, Present, and Future (Android Dev Summit '19)の記事です。

Fragment Past

Android API 11

Fragments were really designed from the beginning to the kind of Micro Activities.

  • First step to move things from fat Activities to smaller fragments
    • this also meant that Fragments inherited a lot of APIs that Activity had
      • ActionBar Menus
    • this also meant that there became a lot custom hooks
      • Things activity got received needed to be received on Fragments as well
        • onActivityResult
        • Permissions
        • Multi Window
        • Picture in Picture

Present

  • Restructuring the goal of Fragments
    • focused API surfaces
      • core, simple, predictable no-surprise apis
      • without breaking changes
        • deprecating old apis with new better APIs
  • Providing testable APIs
    • Fragment testing artifact
      • Fragment Scenario
        • moveToState(), recreate()
        • launchFragmentInContainer
      • Working together with AndroidX team
  • Instantiating Fragments
    • Recreation after config change
    • FragmentTransaction add / replace
    • FragmentScenario
    • FragmentFactory
      • Support constructor injection
      • No requirement for no arg constructor
  • One container for Fragments
    • FragmentContainerView
      • Use it instead of FrameLayout
      • Replace the tag
      • does use FragmentManager under the hood
        • Fix issue of replacing fragment later
      • Fix the Z-ordering animation issue
  • System back
    • OnBackPressedDispatcher
      • Arch Components
  • ViewModels
    • by viewModels()
    • by navGraphViewModels(R.id.main)
    • by activityViewModels()
  • Lifecycle
    • ?

Future

  • Subject to change

  • multiple back stack

    • single stack: existing legacy on Android
    • allow saving and restoring a whole stack of fragments without losing state
    • Bottom nav made easy
  • returning results
    • how do I talk between fragments?
    • fragment API right now is not great
    • create a better API for startActivityForResult() and for passing a result to another Fragment
      • building and hopefully sharing in a few months
  • lifecycle
    • fragment has two lifecycles
      • fragment itself
      • fragment's view has totally different lifecycle
        • view may get destroyed, but fragment still exists
    • what if, these two lifecycles are the same?
      • bringing these things together, we can solve a lot of complexity. => maybe this kind of opt-in APIs will be available in FragmentActivity level.

所感・まとめ・個人的に印象に残ったことなど

  • FragmentFactory、FragmentScenarioを使うことでFragmentの生成やテストがしやすくなったよ
    • Factoryを使うことでconstructor injectionも可能になったよ
  • FragmentをViewに内包する場合にはFragmentContainerViewを使う(FrameLayoutは使わない)
    • 内部ではFragmentManagerが利用されている
  • Googleとしては、将来的にももっともっと良くしていきたいFragment APIが沢山ある
    • 複数のバックスタックを可能にする(BottomNavの切替時とかの管理を簡単にしたい)
    • Fragment-Fragment間の値の受け渡しとかをより簡単にできたら(FragmnetActivityあたりへのAPI変更が数ヶ月以内にあるかも?)
    • Fragment自体のLifecycleとViewLifecycleを1つにできるとしたら...???

FramgentのAPIはより使いやすく、直感的なものになっていきそうですね。

以上です!

2019年9月を振り返る

9月を振り返ります。今年は残り24%くらいらしい。

入籍した

秋分の日に入籍をしました。同棲をはじめて半年以上だったこともあり、特に入籍後になにか変わった!ということはないですが、これからも二人で穏やかに、楽しく暮らしたいと思っています。

指輪は鎌倉彫金工房というところで、自分たちで叩いたりして形作りしました。

f:id:shaunkawano:20191005163541p:plain

↑これがこうなりました↓

f:id:shaunkawano:20191005164739p:plain

Bit Valley 2019に参加した

f:id:shaunkawano:20191005163549p:plain

bit-valley.jp

「ITトップが考えるモノづくり対談」の回が一番聞いてて楽しかった。

以下はメモしてたところから特に印象的だったことの抜粋

  • 一度合理的かと思われることに対して、再考するようにしている
    • 「無邪気に言うと」、「極論すると」という言い方で別の視点から考えるようにしていく
    • ユーザーニーズがすべて。テクノロジードリブンとか、レベニュードリブンではまったくない
    • ユーザーが純粋に「おっ、すげっ」って体験して思ってくれるかどうか

技術書典に参加した

f:id:shaunkawano:20191005163555p:plain

今まで2回、サークルとして、本を出す側として参加したことがあったのですが、今回は見て回ったり買う専で参加しました。 列がすごくて断念しそうになったけど耐えてなんとか戦利品ゲットした。 奥さんも初めて参加だったけど、興味深いものがいっぱいあってお祭りみたいで楽しかったようで、一緒にいけてよかった。

さらりとですが、以上です。

Notes - Firebase offline: What works, what doesn't, and what you need to know (Firebase Summit 2019)

f:id:shaunkawano:20191005165929p:plain

※Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたら気軽にご連絡いただけると嬉しいです!m(__)m)

本記事は、Firebase offline: What works, what doesn't, and what you need to know (Firebase Summit 2019)の記事です。

Should we care about offline anyway?

  • Yes! Users may..

    • be in crowded place
    • go underground
  • Firebase is not an offline-first platform, but offline-tolerant

What works

  • It (mostly) works
    • Caching things locally
    • Exponential back-off and retry

Firebase Auth

  • you only have the access to the user object
  • you can't login

Gotchas

  • Login
  • Auth Persistence
    • Tells how long you stay logged in
    • Trade-off between offline-experience and security

Cloud Firestore

How large is that cache, anyway?

  • For mobile - 100MB
  • For web - 40MB
  • on-device cache is not indexed right now
    • unpack and scan every document you are searching
    • if your cache is too big or too many writes this can be quite slowly
  • Maybe not pre-loading your cache too much is better than overloading cache data
  • Adjust your cache size by configuring Firestore

Cloud Storage

  • you can save large object to the cloud
  • specifying a reference like a path to upload and download the content

All The Measurement Libraries

  • On Android, all this uploading is done by Google Play Services
    • That is why if your app were crashed on Android, you can see that crashed data and upload it for you
    • if offline, exponential back-off retry
  • Performance Monitoring
    • 10MB of data, shared across all apps (Android)
    • 10MB of data, per app (iOS)
    • Oldest data usually gets eliminated
  • Analytics
    • About 100,000 events
    • Most recent data gets eliminated
  • Crashlytics
    • 9 crashes(up to 150k each)

Conclusion

  • If you're offline, things mostly just work
  • Designed for occasional offline moments, but not offline-first
    • if you need complete offline experience, maybe not the right tool
  • Measurement tools don't trust data that too old
    • Mostly 72 hours old?

所感・まとめ・個人的に印象に残ったことなど

  • Androidでは、Firebase AnalyticsやFirebase CrashlyticsはGoogle Play Services経由でログを送信している
    • そのため、アプリのタスクがキルされている状態でも動作する
  • Firebaseはオフラインファーストのサービスではないが、通常利用によるオフライン状態(地下鉄や混雑時)などには想定されており、2つの方法を用いてオフライン対応をしている
    • Local cache
    • Exponential backoff and retry
  • オフライン時にもオンラインと同等のサービス提供が必須なアプリには適切なツールではないかもしれない

以上です!