Kotlin has become go-to language for Android developers all over the world and the language itself has a large number of feature sets. With greater acceptance of language, we look at how we can leverage power of Kotlin for meta-programming. Through the talk, we'll introduce what Meta-Programming is and how we do it on day to day basis. We'll see how using Kotlin's internal compiler API, we can parse kotlin files, pull data out of it and go through various applications of this data such as custom documentation for API code and much more. We'll also look at various approaches of source code generation for Kotlin files and how we can leverage them in projects.

Kotlinで関数型ProgrammingをするためのLibrary、ArrowというLibraryをご存知でしょうか？ 本セッションではそんなArrowについて興味のある人に Arrowがどのようなライブラリなのかを知ってもらうことを前提としたセッションになります。 具体的には * Arrowの代表的なDataType * 便利なTypeClassとKotlinでの表現力の限界、そしてArrowにおけるその突破方法 * Monadは難しいという思いの払拭 * Tagless Finalによる抽象化(※) * ArrowFxとCoroutines(※) といった、Arrowの代表的な機能の紹介やその利用方法を そして * そもそもArrowをAndroidに適応することに関して を具体的なコードを踏まえて紹介したいと思います。 ※は聴衆の人の事前知識で調整

Kotlin has many language features even though none of them are supported by JVM or Android ART. This talk will go through all the language features and understand how they work internally for JVM or ART compatibility. For example: 1. Do all know, how features like default arguments and default methods (in interface) works? 2. Do all know, that switch statement can only work with integers? Then how when expression works with almost all data types? 3. Do all know, how inline classes works? 4. And many more features. Many developers in kotlin community uses all these APIs without knowing how they work. After this talk, they will have a good understanding of how these features work internally which obviously make them a better programmer.

Kotlin Coroutinesが正式リリースされて1年が過ぎ、もはや私たちのAndroidアプリ開発には欠かせないものとなりました。 コルーチンはRxJavaのようなストリームやコールバック方式と比べて非同期的な処理を直感的に記述でき、これまでRxJavaを使っていたようなユースケースをある程度置き換えられるようになっています。 ​ ​ 私はこの1年と少しでKotlin Coroutinesを複数のアプリに導入し既存のパラダイムの置き換えを進めてきました。 Kotlin Coroutinesの導入を行ったことでAndroidアプリ開発が楽になりましたが、大変になったこともありました。 恐らくKotlin Coroutinesが難しく感じて導入をためらっている方もいるでしょう。 ​ このセッションでは、既存のAndroidアプリにKotlin Coroutinesを導入したことによってAndroidアプリ開発がどう変わったか、 Kotlin Coroutinesの導入を行ったことで困ったことをどう解決したかなどを紹介します。 皆様のKotlin Coroutinesの導入の参考になれば幸いです。 ​ - RxJavaを使って書かれたコードを置き換える - RxJavaを使った世界観にKotlin Coroutinesを混ぜる - Retrofitを用いたHTTP通信をKotlin Coroutinesに対応 - RoomをKotlin Coroutinesで利用する - Kotlin CoroutinesとView層との組み合わせ - Kotlin CoroutinesとLiveDataの使い分け - Kotlin CoroutinesをViewModelで活用する - Kotlin Coroutinesとテスト - 例外処理 - キャンセル可能に作る

Learning to write idiomatic Kotlin is a process, but guidance and insight can be found in Kotlin itself. By examining how language features are designed and implemented, we can perhaps better understand the thinking behind Kotlin and better answer "What is idiomatic Kotlin?" In this session, we'll examine conventions: a mechanism by which several Kotlin language features are accessed. We talk about what conventions are, run through live-coded examples of several of convention-based features, look at some underlying bytecode, and discuss how conventions reflect the principles and values of Kotlin and the Kotlin team. By understanding how and why conventions work as they do, we can better follow those underlying Kotlin principles when both using those features and when writing our own code and tools.

発表内容 - プラグインの開発環境について - デモプロジェクトの作成 - KotlinでHelloworldの実装 - 動作確認とデバック方法の説明 - リソースファイルの読み込みや成果物の出力方法について - その他よく使うGradleAPIの紹介 - Pluginの公開方法について - (時間があったら Android Gradle Pluginの実装の話を入れます) 話せないこと - build.gradle.kts についてのTips GradlePluginの作り方は情報が断片的であったり、ニッチな情報の多くがGroovyで説明されていたり、とっつきにくい印象を持たれやすいと思います。本セッションでは2020年らしくGradle Pluginの体系的な情報をKotlinを使ってご紹介します。

Operator overloading is awesome! Or was it terrible? It will definitely make your code more concise. Or was it that it makes it completely illegible? Either way, let's talk about operator overloading extension functions, and sealed classes! In this talk we'll look at how these work in Kotlin and explore what is happening under the hood. We'll consider best practices for each, as well as how we can dial everything up to 11 by using infix functions to create even more expressive domain specific languages. After this talk, you'll be able to apply what you've learned to find the "middle way" to apply these tools to create expressive, concise, and readable code.

Kotlinには委譲プロパティ（Delegetaed proprties）という仕組みがあります。 標準ライブラリのlazyや、AndroidXのActivityやFragmentに実装されているviewModelなどで普段からあまり意識せずに利用している方も多いと思います。 本セッションでは、標準ライブラリやAndroidXなどの著名ライブラリに含まれている委譲プロパティ、および拙作のライブラリであるKotprefなどの事例を交えながら、委譲プロパティの仕組み、Kotlinでの実現方法、活用事例や自作する際の方法などをお話します。 本セッションに含まれる内容 - KotlinのDelegated propertiesとは - Delegated propertiesの仕組み - 標準ライブラリで提供されるDelegated properties - 各種ライブラリでの事例 - Kotprefを題材に実際の実装方法について知る

FIDO（ファイド）はユーザーの認証はローカルで行うため、ユーザーの識別情報がネットワーク上でやりとりされないセキュアなプロトコルです。 ユーザーからのメリットとしてはパスワードを覚える必要がなくワンタップで簡単にログインできますが、実装に関する情報はまだまだ少ないのが現状です。 本トークではサードパーティ認証を使わず、メールとFIDOを使ったファーストパーティ認証としてどのようにAndroidアプリにFIDO2を実装し運用していくかについて紹介します。 デモにはFirebase AuthenticationとCloud Functionsを利用します。 サーバーサイドはNode.jsで実装を行います。 このトークで話すこと - なぜID/Passwordじゃダメなのか - FIDOとは - FIDO2 for Android - Firebase Authentication とCloud Functionsを使ってFIDO2の実装 - 実際にサービスに導入する上で検討すべきこと

Androidアプリケーションのセキュリティと聞かれて皆さんは何を思い浮かべるでしょうか？ データの暗号化・ProGuard/R8といったコード難読化・不正購入、はたまたAndroid本体のセキュリティなど様々な要素が挙がるでしょう。 今回はその中でも特に「脆弱性」にフォーカスしてみます。 Android OSやライブラリに含まれていることもありますが、何気なく書いたあなたのコードが原因になっているかもしれません。 ついつい書いてしまいがちなコードの中に脆弱性につながる書き方が潜んでいることは多々としてあります。 実際に、LINEのAndroidアプリでも書かれたコード上に脆弱性があり、脆弱性報奨金制度「LINE Security Bug Bounty Program」での報告や内部チェックで発見・修正をしてきました。 では、実際にどのような脆弱性がAndroidアプリに混入してしまったのでしょうか？ このセッションでは、LINEのAndroidアプリに含まれていた脆弱性の紹介を行います。また、それらの脆弱性に対してどのような対策を講じたか紹介を行います。

このセッションではgdb等のデバッガ、Frida等の動的解析ツールの技術の根幹部分であるptraceシステムコールについて扱います。 ptraceシステムコールを利用すると、他アプリケーションのプロセスメモリ空間やレジスタにアクセスが可能になり処理を解析することが可能となります。 正当に利用すれば便利なデバッガとして機能しますが、悪用するとゲームでの不正行為やアプリケーションのクラックにも利用できてしまいます。 今回は他アプリケーションのプロセスメモリを読み書きする方法の説明から始まり、ブレークポイントを設置しての簡易的なデバッガを実装します。 こういった原理的な考察を通じどのようにアプリケーションを解析から守るか、セキュアな状態に保つか考察していきます。 講演者の所属企業はゲームセキュリティを専門とする企業であり、業務としてソーシャルゲームのセキュリティ診断等を行っています。 講演では実演する解析される側の題材として、自作のゲームを用いて分かりやすく解説を行います。 本講演でのセキュリティの攻防戦から、セキュリティ対策の重要性や防御手法の知見を深めるきっかけとなれば幸いです。

マテリアルデザインを実現するためにAndroidにはmaterial-componentsというLibraryが用意されており、利用することでマテリアルデザインに準じたUIをより簡単に実装することができます。 さてみなさん、material-componentsは20数種のComponentを提供していますが、どんなものがあるか認識してるでしょうか？ Componentのガイドラインに目を通したことは？ 事前に用意されたスタイルにどんなものがあるか知っていますか？ BottomNavigationBarが簡単に実装できることは？Floatingボタンが伸び縮みできるようになったことは？9月にDatePickerが追加されたことは？？カタログアップをビルドしてみたことは？？... material-componentsには思ったよりも多くの機能があります。存在を知っていてもどんな機能が提供されているかを知らなければ使い所も分かりませんよね。 本発表では、マテリアルデザインの基本を抑えつつ、material-componentsに用意されている機能、コンポーネントの概要・使い所・気をつけるべきことをガイドラインと照らし合わせながら湯水のごとく浴びていきます。 本発表を聞くことでmaterial-componentsを使いこなし、素敵なマテリアルデザインをより簡単に実装することが出来るようになることでしょう。 #### 予定している内容 - material-componentsの導入 - Theming ColorTheming 　ShapeTheming 　Typography Theming - Components 実装方法 　GoodUseCase/BadUseCase - ダークテーマ

検索はユーザーが必要としているコンテンツへアプローチする重要な機能です。 膨大なコンテンツから効率よく情報を探せる機能はサービスのコアな体験にもなり、コンテンツを扱うサービスでは必須といっても過言ではありません。 優れた検索体験はユーザーのエンゲージメントを高めることができますが、よくない検索体験はユーザーがコンテンツにふれる機会を減らす可能性もあります。 しかし、スマートフォンはPCに比べ画面が小さく表示できる要素に制限があるため、PCと同じ体験を目指してはコミュニケーションを失敗することがあります。また、扱うデータやサービスの特性によっても異なります。つまりアプリで最適な検索体験を提供するには、デバイスの特性だけでなく扱うデータやサービスの特性も考慮する必要があります。 本セッションでは、テキストコンテンツのサービスを念頭に、アプリでの検索体験を向上させるためのUI/UXデザインについてお話致します。 まず、検索に必要な体験を考え、ユーザーが検索機能を使う目的について整理します。 次に、Material Design guidelinesを踏まえつつ、検索のUXについて説明します。 そして、様々なアプリで実装されている検索機能の事例を抽象化した上で分類していきます。あわせて、リッチな検索体験を実現するためのフィルターやクエリの機能について検討を行います。 最後に、テキストアプリを念頭に、どのような検索体験を実現できるか実装例を紹介致します。具体的な実装例を扱いつつお話することで、実践的な取り組みへとつながる発表ができればと考えております。 現在考えている発表内容の構成は次のとおりです。 ・検索の体験を考える 　・そもそも何故検索するのか？ 　・検索はサービス側とユーザーの橋渡し 　・検索は内容でチューニングが必要 　・ユーザーの目的を理解する 　・... ・Material Design guidelinesの簡単な基本概念 ・Search UXについて 　・サジェスト 　・提案 　・結果 ・音声 　・... ・Search UI/UXのパターン整理 ・モデルケースの紹介 ・まとめ

Android10でダークテーマが発表されました。夜間利用時に目に優しいこと、またバッテリーの持ちがよりよくなることから、今後より各アプリにダークテーマ対応が求められていくと思います。今回は、現在リリースされているアプリへダークテーマを導入していくために、どのような準備が必要で、デザイナーとどういったやりとりがあったか。また、実装をした際に起こった問題、注意していくポイント等を具体的にお話します。

Android には様々なアニメーション API があります。アプリにアニメーションを実装するとき、どの API を使えばいいか迷った経験はありませんか。適切な API を使い分ける判断基準が分からず何事も一つのやり方で済ませてしまってはいませんか。 Android には ObjectAnimator などの基本的な API から、それらの API に基づいて実装される Transition や ItemAnimator などの高度な API まで、数多くのアニメーション API が用意されています。中にはもはや忘れてしまって構わない API もあれば、場合によって使い分けていく API もあります。このセッションの前半で、まずそれらを整理します。 さらに、アニメーションに関係する View の性質を解説します。アプリごとに洗練されたアニメーションを作り込むためにはカスタムの実装が必要になることもあります。スムーズなアニメーションを作り込むためには基本を押さえておくことが大切です。 最後に、マテリアル デザインの Motion の章 (material.io/design/motion) にあるようなアニメーションの具体的なパターンを題材として、どの API をどのように使うべきか考えていきましょう。 - 様々なアニメーション API - もはや忘れて構わないアニメーション API - 2020 年に押さえておくべきアニメーション API - アニメーションを実装する上で押さえておきたい View の性質 - レイアウトについて - View の位置について - マテリアル デザインの動き - Dissolve と Fade through - リスト - Stagger - Oscillation - ナビゲーション - 共通要素 - コンテナーのアニメーション

昨今の Android では, ノッチ付きのデバイスによって Navigation Bar の幅が増えたり, Gesture Navigation によって Status Bar がほとんどなくなったことにより, より画面全体を活用したUI(Edge-to-Edge)が求められるようになりました. これは, 没入感を与えるという点でメリットがある一方で, それに対応するには WindowInsets への理解が欠かせません. 本セッションでは, WindowInsets の基本的な使い方と, 画面全体を活用したUI(Edge-to-Edge)の実践を重点的に解説したあと, さらに先へ行くための, Gesture Navigation の基礎や, 対応方法をかんたんに紹介します.

アクセシビリティ、という言葉を耳にした方は多いかと思います。 多くの方はアクセシビリティの機能は障害者向けである、自分のアプリには不要である、 と、特別な対応を行わないかもしれません。 しかし、アクセシビリティを考えない実装を行うことによって、 アクセシビリティが必要なユーザーにアプリを使ってもらえないどころか、 意図しない動作を引き起こす要因にもなりえます。 毎年Google I/Oではアクセシビリティに関するセッションが複数行われ、 私たちはいつでもアクセシビリティユーザーである、 situational disability(状況的障害)が起こる、という話があり、 正しくアクセシビリティが実装されると全ての人にメリットがあるものになります。 本セッションでは主にTalkBackなどのアクセシビリティの実装方法や、アクセシビリティが正しくされない場合のリスク、 実際のアクセシビリティ機能の使い方やAPIの説明やアクセシビリティの自動テストなど、 今までリーチしていなかったユーザーにリーチするようになるアプリを開発するためのTIPSを説明します。

端末の画面を最大限に活かし、より良い体験を提供するために、System UI（Status Bar、Navigation Bar）を考慮することは非常に重要です。 しかし、Android Q、Q以前などでのバージョンごとの差異、ノッチ対応、画面構成によっては、WindowInsetsを取得する必要があるなど、考慮しなければならない点が多くあります。 この発表では、最初にSystem UIをコントロールするために抑えておくべき要素を、実際の挙動を見ながら、1つ1つ理解していきます。 具体的には、次のことを説明します。 - fitsSystemWindowsの挙動について - ThemeからSystem UIの設定をする - Navigation Component（Single Activity）との兼ね合い - WindowInsetsを取り、動的にSystem UIを調整する - FloatingActionButtonとの兼ね合い - systemUiVisibilityについて - ノッチ端末（cutout）への対応 最後に、実践的な例として、Google I/OなどのアプリのSystem UIをどのようにすれば構築出来るかを説明します。 System UIの基礎 〜 実践までを理解することで、画面を最大限に生かした没入感のあるアプリを実装出来るようになることを目指します。

Androidアプリを開発する上でRecyclerViewは非常に便利なViewです。主に多量のアイテムを表示するために利用するViewですが、RecyclerViewは様々なコンポーネントから構成されており、そのコンポーネントをカスタマイズすることでただアイテムを並べるだけでなく様々な表現やパフォーマンスの向上が可能になっています。代表的なもので以下のようなコンポーネントがあります。 - RecyclerView.ItemDecoration - RecyclerView.LayoutManager - RecyclerView.ItemAnimator - RecyclerView.Adapter - RecyclerView.RecycledViewPool - SnapHelper - ItemTouchHelper - DiffUtil 例えば、RecyclerView.ItemDecorationをカスタマイズすればアイテム間にフレキシブルにマージンを付ける事が可能です。応用すればDroidKaigi 2019アプリのセッション一覧画面のようにアイテムの横に時間を表示することも可能です。RecyclerView.LayoutManagerをカスタマイズすれば同じくDroidKaigi 2019アプリのタイムテーブル画面のような複雑なレイアウトを実現することが可能です。 このように、RecyclerViewは非常に拡張性の高いViewです。いつか来るであろうデザイナーからの高い要求に「出来ます」と余裕の一言を返すために、本セッションで以下の2つを通してRecyclerViewの理解を深めましょう。 # RecyclerView.ItemDecorationでCanvas直書き装飾 前述したようにItemDecorationはアイテム間にマージンをつけるだけにとどまりません。RecyclerViewのCanvasにアクセスすることでRecyclerViewのアイテム間を縦横無尽に装飾する事が可能です。 # LinearLayoutManagerをミニマム再実装してRecyclerView.LayoutManagerの実装理解する RecyclerView随一の複雑かつ重要なコンポーネント、LayoutManagerの実装方法をLinearLayoutManagerのミニマム実装を通して理解しましょう。 * セッション時間に余裕があればRecyclerView.ItemAnimatorの実装方法も紹介するかもしれません。

Nearing the end of its lifespan, Android's UI framework is now chock-full of useful tools for building UIs. Sometimes it seems like there's a hundred ways to achieve something. Other times you have no idea where to even begin. This talk outlines when and when not to apply certain UI components. It discusses tips and tricks Android developers can apply when building their UIs, as well as outlines some of the common gotchas to avoid. Topics discussed will include: Animations and Transitions Layout hierarchies Not using ConstraintLayout for everything Drawables Custom Views/ViewGroups Threading and timing Themes and styles

2017年頃からアプリケーションのマルチモジュール化による利点が多く得られるようになった．特に「差分ビルドのビルド時間短縮化」「InstantAppやDynamicFeatureModuleの導入可能」「モジュール依存関係グラフのDAG化」といった利点が語られる．これらの利点は肥大化したアプリケーション上で高速に開発を行う上での助けになったり，ユーザ体験を向上させる手助けとなったりする． 一方で，これまで大部分をアプリケーションモジュール(:app)で開発されてきたアプリケーションを，容易にマルチモジュール化することは難しい．特にMVVMやFluxといったルールを明確化したアーキテクチャに乗っていない場合は問題が顕著だ．また，並行してマルチモジュール化とは本質的に無関係な機能改善を進めていく必要がある場合，問題はさらにややこしくなる． 本セッションでは上に挙げた実体験を基にどのようにしてマルチモジュール化を進めていったのかを時系列順に，そのハマりどころと解決方法を中心に紹介する． <アジェンダ(仮)> - マルチモジュールとは何で，導入するとどう嬉しいのか？ - はじめの一歩は:appから:legacyへ - ApplicationモジュールとLibraryモジュールの違いによって生じる問題 - Flavor，buildType，BuildConfigのマルチモジュールでの取り扱い - 共通リソースのモジュール化とそのハマりどころ - マルチモジュールとJetPack 〜どのようなライブラリの導入効果が高いのか〜 - 意味境界としてのモジュール分割 〜モジュール分割戦略〜 - 継続的な機能開発との共存法 - TBD

本講演では、ぼくの考える「2020年のAndroidアプリ開発入門」について発表します。 「移り変わる流行りのアーキテクチャ」 「鉄板と言われるライブラリ」 「今後来る（かもしれない）トレンド」 Androidアプリ開発のハードルは、日々上がっていると言われています。 この状況は特に、Androidアプリ開発の初心者にとって深刻です。 上がったハードルを（熟練の開発者がそうしているように）乗り越えようと過大な設計をしてしまったり、複雑なライブラリ依存の森に迷い込んでしまったり。 初心者が「Androidアプリ開発は難しい」と諦めてしまう一因になっています。 ぼくは、すべてのライブラリやアーキテクチャは、開発者が「楽」をするために存在する。開発が「楽」にならないのであれば、そのライブラリやアーキテクチャは採用するべきではないと考えています。 本講演では、高いハードルに怯まず、ライブラリやアーキテクチャを取捨選択する指針。ぼく自身が考えているアプリ開発に必要な知識のボトムライン。それらを身につけることで何が「楽」になるのかを解説します。 ・Overview ・それ、導入して「楽」になる？ ・メンテナンスコストが上がる（内的・外的）要因 ・高くなったハードルを 越える|くぐる 方法 ・初心開発者のためのAndroidアプリ開発入門

Android開発で最も基本となるデザインパターンはMVCパターンです。 MVCパターンではViewの操作をActivityが行うため、Activityのコードが煩雑になり保守性が下がる要因となっていました。 Data Bindingを使うとViewの振る舞いはView自身で決めるためActivityのコード量が減り保守性が上がります。 複雑になっていくUIの状態をより管理しやすくできるData Bindingを積極的に取り入れていきましょう。 本セッションではData Bindingの基礎から最新の機能まで、幅広く紹介します。 初心者歓迎です。 アジェンダ(仮) - Data Bindingの基礎 - Data Bindingのメリット - BaseObservable - LiveDataとData Binding - ViewModelとData Binding - Custom ViewとData Binding - 実践小技集 - Android Studio 3.6に追加されるView Bindingについて - (仮) Jetpack ComposeとData Binding

近年、DDDやClean Architectureといったアプリケーションのアーキテクチャについての関心が非常に高まっています。 Clean Architectureは、それらの著名なアーキテクチャの中でも特に有用で汎用性の高いアーキテクチャのひとつです。 しかし反面Clean Architectureは、その本質を誤解されいるケースも多いようです。 かの有名な同心円状のモデルは、けして「あの図に登場する要素の通りに作りましょう」という意味ではありません。 そこで本セッションではClean Architectureの「誤解されがちな二つのことと、真に理解すべき三つのこと」についてお話し、Clean Architectureの本質を理解いただこうと思います。 内容はこちらがベースとなりますが、今後ブラッシュアップの予定です。 https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 アジェンダ - 誤解されがちな二つとその解説 　- 「あの同心円状のモデルのレイヤーや要素の通り実装せよ」というわけではないこと 　- 「データや処理の流れを一方通行にせよ」というわけでもないこと - 真に理解すべき三つのこと 　- 依存性は、より上位レベルの方針にのみ向けよ 　- 制御の流れと依存方向は分離・コントロールせよ 　- 「上位レベルの方針」とはなにか - 上記を理解いただくためのサンプルの解説 　- あの同心円状のモデルの登場要素のままだがクリーンではない設計と実装 　-　上記をクリーンにリファクタリングした設計と実装

In recent Android application development, using DI framework has become commonplace. Dagger, Java's DI framework, is often used in Android application development, and is also used in the Google I/O official application and Android Architecture Components samples. In this session, I will explain the mechanism of Dagger from the very beginning for people who use Dagger for some reason and those who use Dagger for watching. If you listen to this session, you will understand Dagger completely. The content of this session is based on a book called “Master of Dagger” written by the speaker. Talking in this session - What is DI - binding, object graph, and Component - How to separate Modules - Cases where Subcomponent is required - How Scope can help - What the Dagger Android Support Library is doing etc

Dynamic Feature Moduleの基本的なことから実装時のTipsなどを紹介します。 Dynamic Feature Moduleの実装はハードルが高く難しい印象があると思いますが、実際に実装した経験を元に導入の助けになるような内容を話す予定です。 <予定内容> - Dynamic Feature Moduleの基本 - 実装時のTipsや注意点 - Dynamic Feature Module + Navigation - デバッグ方法

近年のAndroidアプリ開発では1つのアプリを複数のモジュールに分割しながら開発することが増えてきています。モジュールの分割はビルド時間の高速化やアーキテクチャ構造の強制化といった様々なメリットがあります。一方で、マルチモジュール構造が一般的になる以前から存在するアプリはモノリシックな構造で実装されていることが多く、機能開発と並行してマルチモジュール構造に移行していくのは容易ではありません。 本セッションでは、マルチモジュールの概要やメリット・デメリットからスタートして、レイヤー単位での分割や機能単位での分割といったモジュール分割の方法論や、機能同士の依存管理や機能横断の画面遷移といったマルチモジュール環境におけるいくつかのTips、そして、発表者が実務で扱ったモノリシック構造からマルチモジュール構造への移行方法を紹介します。 - マルチモジュールについて 　- マルチモジュールの概要 　- モジュール分割の方法論 　　- レイヤー単位での分割 　　- 機能単位での分割 　　- 共通コードの扱い方 　- マルチモジュール環境におけるTips 　　- ライブラリのバージョン管理 　　- 機能同士の依存管理 　　- 機能横断の画面遷移 　　- Daggerとの連携方法 - 大規模アプリでの導入方法 　- 全体の構造理解とモジュール構造の決定 　- 共通コードを配置するためのCoreモジュールの作成 　- 機能開発と並行してモジュール分割を進めるための方法論 　- 機能単位でモジュール分割を進める際の障害と回避策

弊社が展開しているタクシー配車サービスにおける乗務員様向けのシステムは今、大きな転換期を迎えています。 約半年に渡って進めてきた、大規模リファクタと開発対象デバイス刷新のプロジェクトがいよいよ陽の目を見るためです。 そんな新システム開発の裏で最低限のメンテしかされず、死にゆく運命にいる現行のシステムがあります。 とあることがきっかけで、今まで想定されていなかった多種多様なユースケースへの対応が必要となり、 現行のシステムにも新たに生まれ変わるチャンスが巡ってきました。 ただし、現在の実装の成熟具合から、現行のシステムを拡張する形での対応は難しく また大規模に改築するにしても、 平行開発している新システムとのコード的な共存(マルチモジュール)を意識して対応しなければならない状況です。 本セッションでは、上記対応を行った中で学んだ ・多種多様なタクシー乗務のユースケースへ対応するための状態変化に強いアプリアーキテクチャ ・対象端末が違う別のシステムと共存するためのノウハウ についてお話させて頂きます。 キーワード - Flux - MVVM - マルチモジュール - ステートマシン - システムアーキテクチャ

Firebaseには多くの機能があり、Firebaseを使用するとサーバレスのアプリをとても簡単に開発できます。 本セッションでは、実際のFirebaseコンソールとAndroidのアプリのロジックを照らし合わせながら、 あえてFirebaseにある機能だけを使用したアプリ開発の一連の流れをお話しします。 ＜主なトピック＞ - Firebaseのプロジェクトの作成から設定 - 認証とユーザ管理 - AuthenticationとFirestoreを使用した認証とユーザ管理をAndroidのアプリのロジックとFirebaseコンソールを照らし合わせながら作成します。 - クラウド データベースを使用したデータの取得と更新 - Firestoreを使用したデータの取得と登録/更新/削除についてAndroidのアプリのロジックとFirebaseコンソールを照らし合わせながら確認します。 - クラウド データベースのユーザデータの管理 - ユーザや、権限ごとのFirebaseクラウド データベース上のアクセス制御について確認します。 - Push通知の送信と受信 - アプリの特定の操作をトリガーとしたPush通知の送信とその受信についてアプリのロジックとFirebaseコンソールを照らし合わせながら確認します。 - それ以外にFirebase SDKを使用したアプリ開発のTips - Remote Configやみんな大好きなAnalytics、クラッシュ分析などの実例を見ながらのご紹介 - Firebaseだけでアプリ開発をする場合に困ったことの共有 - Firestoreへのグループ化したデータの取得の方法だったり、いくつかのナレッジを共有いたします。

昨年のGoogle I/OでAndroid Auto, Android Automotiveといった自動車向け環境のアップデートがありましたが, Android x 自動車のプラットフォームはそれ以外にも多く存在します. その中から, 本セッションでは最近日本国内でも名前を見かける様になってきたSDL(SmartDeviceLink)で動作するAndroidアプリ開発についての知見を共有します. 内容(予定) - SDLについて説明 - 車載デバイスとの接続を意識した設計 - 通常のAndroidアプリ開発との違い - つらいところとそれの乗り越え方 など

AndroidではMarshmallowでAndroid MIDI APIが追加され、MIDI機器と連携する音楽アプリが作れるようになりました。 しかし、iOSに比べてAndroid用の音楽アプリの数はそれほど増えていません。原因はなんでしょうか？ M5StackというマイコンでBLE MIDIコントローラを作りながら、Android用音楽アプリの可能性について探ってみました。 このセッションでは、BLE MIDIを使ったアプリの作り方やiOSとの違い、レイテンシー等の課題ついてお話します。 また、MIDIコントローラとしてM5Stackを使い実際に音を出しながら説明していきます。 対象者 - MIDIを使った音楽アプリを作ってみたい方 - AndroidとM5Stackを繋いで何か作ってみたい方 - オリジナルのMIDIコントローラーを作ってみたい方 お話する内容 - MIDIってなに? - BLE MIDI機器との接続方法と通信方法 - なぜAndroidでは音楽アプリが少ないのか - レイテンシーについて - Android 10で追加されたNative MIDI APIについて - M5Stackで作ったBLE MIDIコントローラを使った実演

Android development has come a long way since 1.0. How did we get here? And now that we're here, what do we do next? This talk will go over the landscape of Android development through the years and the releases, and talk about what Android platform priorities are now, and what that means for developers.

When Android Q Beta 1 was released, the main surprising change for developers was what Google calls “scoped storage”. The main two reasons for making this change: Security & to reduce leftover "app clutter". In brief, our ability to work with files and filesystems will get substantially curtailed, even for apps with a targetSdkVersion of 28 or lower. However in subsequent Android Q beta releases 4 & 5, it has now been finalised that Apps can either have normal or legacy storage. With legacy storage, everything behaves as it did in Android 4.4 through 9.0. Without legacy storage, apps still can use getExternalFilesDir() and similar directories without permissions. However, the rest of external storage appears to be inaccessible via filesystem APIs. As per documentation : “An app that has a filtered view always has read/write access to the files that it creates, both inside and outside its app-specific directory” The idea is that we should start adapting now. For some apps, switching to the Storage Access Framework (e.g. ACTION_OPEN_DOCUMENT) will be easy. For some apps, it will be painful. We must not wait until 2020, as mentioned in documentation. We should Start migrating our apps now to use the alternative approaches. Through this talk we will try to assess different approaches to be adopted for the changes coming via scoped storage and making sure that apps continue to work seamlessly.

Have you ever wanted to make your app stand out from the rest? Or has your UI designer presented a custom view to you and you have no idea how to go about making it? Don't panic, you can draw it yourself! In this talk, we will go back to the basics of how to draw onto a Canvas to create your own custom view. We will also cover some of the more advanced things you can do with the Canvas, such as using BitmapShaders and Matrices to achieve magical effects within your app. Lastly, we will look at different ways in which you can animate your own custom views with Canvas Drawing.

Androidアプリをビルドするとき、ソースファイル、リソースファイル、ライブラリがコンパイルされてDEXファイルが作られ、APKファイルが作られます。 これは公式ドキュメントにも記載がある内容です。 しかし実際に自分が指定している設定がどのように影響し、R8が何をどのようにコンパイルしてAPKファイルが作られるのかイメージはできているでしょうか。 このセッションではAPK作成の流れを追いながら、そのとき内部では何が行われているのか、図を用いたり適宜コードを参照することで理解を深めていければと思います。 点と点になっている知識を繋げ、ビルド周りの理解を深める一歩になれば幸いです。 発表内容の予定 ・.apk作成の流れの概要 ・.classが作られるまで ・.dexが作られるまで（R8まわり） ・.apkが作られるまで ・+a: .apkをインストールしたあと（バイトコード実行環境）

ユニットテストは、日々のAndroidアプリ開発を支える重要な手法です。 しかし、いざユニットテストのコードを書き始めようとすると、思うように書き進められないことがあります。 例えば、テストコードの書き方を調べるのに時間を取られてしまって実装タスクがなかなか完了しない、というようなことがあるかもしれません。 そんなときにテンプレートを用いてテストコードを生成できれば、ユニットテストを書き始める手助けになります。 本セッションでは、Android開発におけるユニットテストを、自動生成を用いてさくさくと実装する方法を紹介したいと思います。 セッションの中では下記の内容に触れる予定です。 ・スニペットを用いたテストコードの生成 ・KotlinPoetを用いたテストコードの生成 ・上記自動生成を用いたAndroid開発でのユニットテスト実装 ・テストコードテンプレートのカスタマイズ

何ヶ月もかけて開発したアプリを、いよいよGoogle Playに公開！リリース当初は話題になるものの、次々に新しいサービスが生まれる中徐々に埋もれていってしまいます。少しの間足掻いてみますが、その努力も虚しくとうとうサービスを終了する判断が下されます。Androidアプリのエンジニアとして所属するあなたは、アプリをクローズするタスクを任されることになりました。 公開したアプリをクローズすることはなかなか経験することのないタスクでありながら、一度きりで絶対に失敗できない重要なものでもあります。特に課金などお金に関わる部分で失敗すると、目も当てられない状況に陥ってしまいます。しかもアプリを公開することに関しては世の中に知見が溢れている一方で、閉じる事に関する知見はあまりありません。 本セッションではサービスを終了することが決まったアプリをクローズするにあたり、 - シナリオで考えるアプリの終了方法 - それぞれで取れる対策と行動 - アプリ終了に関する落とし穴とその回避方法 について取り上げる予定です。

一人で開発していると一番辛いことは、やはり相談する相手がいないことではないでしょうか。壁にぶち当たった時に、そもそも何を調べればいいのかすら分からないこともあります。 特定のエラーを解決する方法や、ワークアラウンドなどは他の開発者が記事として残してくれていることは多いですが、問題解決までのフローについては、経験則によるところが大きく解説記事などはあまり多くありません。 このセッションでは、そのような問題解決のフローにフォーカスして、一人開発での生産性向上をサポートする内容を紹介していきます。 主な処方箋 - ビルドが通らないときの処方箋 - アプリがクラッシュするときの処方箋 - アプリの評価が悪いときの処方箋 - などなど

iOSやJS界隈ではおなじみとなったビジュアルリグレッションテストが、 ライブラリの活用により最近Androidでも可能になってきました。 ビジュアルリグレッションテスト周りのAndroidライブラリ紹介や実際のテスト結果を紹介します。 予定アジェンダ - ビジュアルリグレッションテストとは - Androidテストでスナップショットを撮るライブラリ紹介 - Android X Test Runner, Composer, facebook/screenshot-test - 導入難易度について - 実際のテストコードについて - 長所・短所について - 差分画像を使ってデグレを検知する - 2019年10月からAndroidでもデグレ検知が可能になった話 - Firebase Test Labの活用について

Automated testing is a very important aspect of building any kind of software, including Android apps. There are many resources on the Internet on how to test our app and everybody has their own opinion on what is the most effective method. In Android, automated testing does not only mean unit tests, as there are different ways to automate the testing of our application. When building an app, setting up automated testing should be a culture, instead of an afterthought. However, there are still some teams who have very minimal tests and some don't even have any tests at all for their projects. In this talk, I will discuss the mindset for testing an Android application. A mental model that we can apply when writing and improving our automated testing. I will also explore the types of tests that are available in an Android project and then present some techniques and tools that can help us structure our tests, such as the testing pyramid, Project Nitrogen, and Firebase Robo Test. In addition, I will talk about testing conventions and how it can help us write cleaner, more readable, and more maintainable test code. Lastly, I will share my experience of migrating a legacy codebase to a new architecture that is more scalable and testable.

Espressoを使ったUIテストは、ユニットテストでは手の届かない動作確認にとても役立ちます。 そのような役立つ面がある一方で、UIテストには実行時間が長いという問題が付いてまわります。 たとえば、実行時間の長さ故に、Pull Requestの度にUIテストを実行するのは非現実的です。 そのような悩みを解決するために登場したのが、GoogleのProject Nitrogenの一環として実装が進んでいるRobolectric 4です。 Robolectric 4が採用しているアプローチは、Espressoを使ったUIテストを高速なローカルJVM上で(Local Testとして)実行するというものです。 ところが、いざUIテストをLocal Testとして動かそうとすると、次のようなトラブルに直面します。 ・サンプルレベルのUIテストコードは動くのに、いざ実プロダクトのテストを動かそうとすると動かない ・エラーメッセージを見ても何が問題なのか分からない 日々忙しい中でこれらのトラブルを自力で解決するのは大変ですが、予め動作する範囲が分かっていたらどうでしょうか？ 動作する範囲内でUIテストを書ければ、Robolectricのトラブルに巻き込まれなくなります。 日々のPull Requestの度にUIテストを実行することも夢ではありません！ 本セッションでは、Robolectricで動作するUIテストの範囲を明らかにすべく、以下のようなトピックを紹介します。 ・EspressoのUIテストをRobolectricで動かすための準備 ・Android Jetpack Componentsのうち、Robolectricで動く機能、動かない機能 ・Espresso APIのうち、Robolectricで動く機能、動かない機能 ・Robolectricで画面更新を待ち合わせる方法のベストプラクティス ・Robolectricで動かしたいオススメUIテスト

個人開発する上では何も意識しなくてよくても、チームで工夫やルールなどないまま開発をすると、本質的じゃないところに時間を使ってしまうことが多々あります。 例えば、「Lintをかけてないことから起こるスタイル崩れへの指摘およびその修正」や「テスターに対して都度ローカルでapkを作ってから配布」などがそれに当たります。 またこれらは時間を奪っていくだけでなく、気持ちよく開発する上で弊害になりチーム全体のモチベーションを下げることにも繋がります。 本セッションでは、チームメンバーが気持ちよく開発をするためにどういう環境を用意するべきなのかにフォーカスを当てます。 １つ１つは当たり前のようにやっていることでも、まとまった情報というのは滅多に見ることがありません。 どのチームでも使えるようなチェックシートを作り、実際にどう用意するのかについて説明します。 【アジェンダ（予定）】 * 無秩序なチーム開発で起こること * チェックリスト * チーム開発を始める時にまずやるべきこと * 方針を決める * テスト方針を決める * 設計方針を決める * コーディング規約を決める * 事前にツールを入れておく * lintを入れる * Dangerを入れる * CIの設定をする * DeployGateの設定をする * テンプレートを作っておく * プルリクテンプレート * イシューテンプレート * コミットメッセージテンプレート * 毎回作るものは、ライブラリやサンプルを作っておく * 強制アップデート * トラッキング * 認証 * APIとのつなぎ方も用意しておく * swaggerを使った方法 * etc

AndroidアプリやiOSアプリはアプリストアからユーザーの端末にインストールして使われます。 こうした配信の仕組み上、過去のコードによる生成物が常に世界のどこかに残ってしまいます。 そのためアプリ開発では通常よりもタイムスケールの大きなリリースやコードの寿命にも注意を払う必要があります。 このセッションではビルドしたアプリがユーザーに届くまでの話や、APIの破壊的変更やローカルデータベースのスキーマ変更など、アプリ開発につきまとう寿命や、未来にためにそうした寿命とどう向き合うかについてまとめます。 また、こうした状況に出くわしたときアプリエンジニアはチーム内でどう対応するべきか、チームに何を知っておいてもらわないといけないのか、といったことにもフォーカスします。 Androidアプリに限らずiOSアプリとの比較についても紹介します。 内容 - リリースとは、寿命とは - AndroidアプリやiOSアプリがユーザーに届くまで - Google Play StoreとAppStoreでの段階的リリースという概念の違い - APIのサポート - マイグレーションのサポート - OS/端末のサポート - 開発言語のアップデートや変更 - ユーザーへのアップデート訴求 (In-app Updates APIなど)

Android の歴史はすでに 10 年を超え、数多のアプリケーションがストアで公開されています。これらのアプリケーションの中には、何年も継続的にバージョンアップを重ねているものもたくさんあります。 このセッションでは、このような持続的なアプリケーション開発・リリースをうまく回す秘訣として DX という言葉をとらえ、アーキテクチャやテストのほか、日々の開発に関わるワークフローをメンテナンスするための考え方や手立てとして、モバイル CI や Android 向け各種ツールキットの導入と効率化、Gradle をベースにした独自タスク開発の方法などを紹介します。

It’s well known that as a team grows, communication overhead increases geometrically until it takes up most of the time of the members. Static analysis can help us reduce the time cost, streamline code review processes, as well as to keep big teams synchronized. This session will cover how to start writing custom Lint checks introducing new APIs and caveats. Also, some examples and ideas will be shown to improve code consistency by enforcing code conventions across the team using custom lint checks. Finally, some concrete examples on how custom Lint checks are helping LINE to keep code consistency, streamline reviews, etc will be shown.

Jetpackの登場でFragmentがより書きやすく、より安全になりました。このセッションでは、Jetpackを活用したFragment実装方法を解説します。 FragmentはUIの実装を再利用するためにAndroid 3.0で追加されました。ですが、かつてのFragmentは扱いの難しいコンポーネントでもありました。Activityとの連携によって生まれる複雑なライフサイクル、非同期のFragment Transaction、密結合しがちなFragment間のやり取り...。Fragmentがもたらす複雑さを避けるため、敢えてFragmentを利用しない開発者もいました。 しかしJetpackライブラリの登場で状況は変わりつつあります。ライフサイクル管理はLifecycleとLiveDataによって、Fragment TransactionはNavigationによって、Fragment間のやり取りはViewModelによって、それぞれコードを書くのがずっと安全に、簡単になりました。 Jetpackの時代にFragmentに入門し直すとしたら、どの処理をどんなライブラリでどのように書くべきか。このセッションでは、シンプルなTODOアプリを題材にして、Fragmentの各処理をJetpackの文脈で再解説します。 具体的には以下のトピックについて扱う予定です。 * Fragmentの生成とトランザクション -> Navigation * ライフサイクル管理 -> Lifecycle, LiveData * Fragment間のやり取り -> ViewModel * テスト -> fragment-testing このセッションを通じて、Fragmentにあまり触って来なかった方には「Fragment、これから使っていけそうだな」と、Fragmentを避けてきた方には「最近のFragment、結構いいやつじゃん」と感じていただけたら嬉しいです。

日本語: 我々Android TextチームはAndroid Qで開発者向けにいくつかの機能追加を行いました。日本語向けの改行アルゴリズムの設定、新しい絵文字の追加、フォントをもっとフレキシブルに使うためのAPIなどが新たに入りました。さらに、Androidチームは今年、Jetpack Composeと言う、シンプルで効率的なUI開発を可能とする、新しいAndroid向けUIライブラリを発表しました。このUIライブラリはKotlinを利用するリアクティブプログラミングモデルであり、より簡潔に分かりやすいUI構築を可能にします。 この発表では、Android Textの新機能と、Textという観点からJetpack Composeを解説していきたいと思います。 English: Android Q brings a set of updates to text aimed at improving different use cases for developers: from better Japanese line breaking, more emojis, to more flexibility when working with fonts and others. Moreover, Android team have announced Jetpack Compose which is a new toolkit designed to simplify and accelerate UI development on Android. It combines reactive programming with the conciseness and ease of use of Kotlin. In this talk, we’ll cover what’s new for Android Text and also describe Jetpack Compose from the perspective of Text. Related links: goo.gle/Android-Q-text developer.android.com/jetpack/compose

Material Components(MDC)は2018年のGoogle I/Oで発表されました。 Design Support Libraryの役割を引き継ぎ、FloatingActionButtonやBottomNavigationといったMaterial Designの実装に不可欠なコンポーネントを提供しています。 それだけではなく、Material Themingでの自由な表現を実現するために、各コンポーネントが高いカスタマイズ性を持っていることも特徴です。 アプリをMaterial Themingに対応させていくうえで、CustomViewを実装する必要性が高くなってきています。 ところが、いざ実装しようとした際には「機能を実現するために必要なAPIがわからない、どのAPIを使うのが最適か分からない」といった状況に陥りがちです。 このセッションでは、MDCの各コンポーネントの特徴的な機能がAndroid FrameworkのどのようなAPIを使って実装されているのかを解説します。 特に、同じ表現にも関わらず異なるAPIが使われているコンポーネントを対比し、何故そのような実装になっているかを解説します。 用途に合ったAPIを知り、効率的でメンテナンス性の高いViewを作れるようになりましょう。 ※ このセッションではAndroid向けのMDCだけを取り上げます セッション概要 - Drawableでの表現 　- カスタムDrawable実装の基礎 　- MaterialShapeDrawableで何ができるか、内部では何をしているか - Shadowの表現方法 　- FAB・Extended FAB 　- BottomAppBar - 文字サイズを変えるアニメーション 　- BottomNavigationのlabel 　- TextInputLayoutのhint - Viewのサイズを変える 　- Chip 　- Extended FAB

in-app updates（以下IAU）は、ストアにアプリの新バージョンが存在する際にアップデートを促し、Play Storeアプリを開かずにその場でアップデートができる機能です。 2018年11月ののAndroid Dev Summitでβ版が発表され、2019年5月のGoogle I/Oにて正式版がリリースになりました。 IAUが発表される以前にも各開発者が自前でアップデート訴求機能を実装することはありましたが、IAUによりそれがより手軽に実現出来るようになりました。 本セッションでは実プロダクトにIAUを実戦投入した結果に基づき、その導入方法、落とし穴だらけの検証方法や、運用してみて分かったTipsなどを赤裸々にお話します。 聴講後に参加者が一人でも多くIAUを試したくなっていることを本セッションのゴールとします。 お話すること（予定） ・in-app updatesについて ・導入方法 ・検証の方法と落とし穴 ・実装時の落とし穴 ・実践投入した成果と課題 ・現時点でのベストプラクティス

TextViewは最も基本的なwidgetですが、ほとんどの方にとってその中身はブラックボックスなのではないでしょうか？　実際、文字列がsetTextでセットされてから、最終的に画面に出るまでには非常に多くの処理がなされています。その一つ一つを見ていくと、とてもではないですが40分では終わりませんので、Android(Java)が公開しているAPIを元に、どの様に使うのか、何のためにあるのか、中でどの様な処理が行われているかを解説していきたいと思います。具体的には以下のトピックについて解説していきます。（時間が足りない場合は絞ります） - UnicodeのBiDirectional Algorithm - 複数のスタイルがついたテキストの描画 - システムのフォント選択アルゴリズム - 改行アルゴリズム などなど TextView is one of the most basic widgets but that would be a black-box for most developers. Actually, there are lots of processes from calling setText to the final graphical output on the screen. There are too many topics for this and unable to arrange all of them in 40min, so I will talk about the Android (or Java) APIs, especially how to use, how it works and why it is necessary. Here is the concrete topics: (I may drop some of them for meeting 40 min talk) - Unicode BiDirectional Algorithm - Multiple style text - Font selection algorithm - Line breaking algorithm etc

Android Architecture ComponentsのNavigation Componentは、Fragment間の遷移をよりシンプルに実装できるようにしたライブラリです。 既存のFragment遷移処理はFragmentManagerによるトランザクション処理を、バックスタックなども考慮しながらコード上で書いていました。Navigationはそれらのトランザクション処理をラップしているので、利用することでコードの簡略化が可能となります。それだけでなく、NavigationGraphと呼ばれるxmlによってFragmentの遷移図をグラフィカルに作成/表示することにより、画面遷移をよりわかりやすく実装することができる画期的なコンポーネントです。argumentsの型安全化(Safe Args)、ディープリンクによる遷移などの便利な機能も含まれています。 本セッションでは、スタディプラスアプリにおいてNavigation導入を行なった際に得られた知見と、それを基にプロジェクトに導入する際に考慮したいことなどを紹介します。また、内部実装をもとに、実際に内部でNavigationが行なっていることも紹介したいと思っております。本セッションが開発者の方々のNavigation導入のきっかけになれば幸いです。 内容としては以下のようなものを予定しております。 - 基本的な遷移の実装について - NavHostFragmentとFragmentContainerView - Fragmentの遷移とNavigator - DialogFragment/BottomSheetDialogFragmentの遷移とNavigator - BottomNavigationの連携 - ディープリンクに依る遷移 - NavigationGraphのネスト - 遷移アニメーションの指定と注意点 - Fragment間のデータ受け渡しについて - Safe Args機能 - ActivityViewModel、NavGraphViewModelに依るデータ受け渡し - Safe ArgsとNavGraphViewModelの併用時の注意点 - バックキー制御方法について - Fragment単位で制御する - Activity全体で制御する - 最初に表示されるFragmentの制御について - NavigationGraphごと分ける - NavigationGraphはそのままで開始Fragmentだけ変更する - 利用する上で起こりうるクラッシュの原因と対応方法について - CustomNavigatorの作成について - 導入時の設計パターンについて - アプリ全体を1Activityにまとめる場合 - 1機能ごとに1Activityにまとめる場合

AndroidのオーディオAPIには様々なものがありますが、いざ音声を扱うアプリケーションを作ろうとすると、APIの使い方に加えて一般的な音声処理の知識も要求され、なかなかとっつきにくいところがあります。 そこで本セッションでは、初学者向けに音声処理の基礎知識及びAndroid上で利用できる音声処理のAPIについて紹介した上で、通話アプリを題材に、音声処理のデータフローや実装上のハマりどころ等を解説していきます。 アジェンダとしては、次のようなものを予定しています。 * 音声処理の基礎 * PCM * サンプリングレート * チャンネル * Android上のオーディオAPI * SoundPool * AudioRecord/AudioTrack * OpenSL ES/AAudio/Oboe * 通話機能を作ってみる - 技術選定 * プロトコル * コーデック * ライブラリ * 構成とデータフロー * 実装 * 再生と録音 * エンコード/デコード * リサンプリング * ステレオ/モノラル変換 * Tips * 音声周りのデバッグ手法 * パフォーマンスチューニング

GoogleはGoogle I/O 2019にて、新しいPlay Billing Library 2.0と同時にPlay Billing Libraryの今後のロードマップを発表しました。 Play Billing Library 2.0では払い戻し機能であるacknowledgeと新しい支払い方法であるPending transactionsを新機能として導入しており、1.xから2.0にアップデートする際にはこれらの新機能に対応する必要があります。 またPlay Billing Libraryは今後、毎年開催されるGoogle I/Oにて新しいメジャーバージョンがリリースされます。 これまでアプリ内課金を実装するために利用してきたAIDLやPlay Billing Library 1.xは2021年のGoogle I/Oまでのサポートです。 サポート期間が終了したAIDLやPlay Billing LibraryはPlayストアへの新しいアプリの公開や更新ができなくなります。 つまり、Play Billing Library 2.0と同時にAIDLやPlay Billing Library 1.xのサポートが終了します。 現在Google Playの課金機能をつかってアプリ内課金を提供しているアプリは今後、2年に1回は必ずPlay Billing Libraryのアップデートを行う必要があります。 まだAIDLを利用して課金機能を提供している場合はPlay Billing Libraryに置き換えたり、Play Billing Library 1.xを使っている場合は2.0にアップデートする必要があります。 本セッションでは、AIDLからPlay Billing Libraryに置き換えたい人、Play Billing Library 2.0にアップデートしたい人、これからPlay Billing Libraryを新たに導入したい人に向けて、Play Billing Libraryの概要や今後のロードマップ、AACを利用した具体的な実装方法や検証方法まで、マネーフォワードでの実際のプロダクトへの導入事例を交えて詳しくお話します。 ■ 発表予定の内容 - Play Billing Libraryのロードマップ - Play Billing Library 2.0の新機能についての詳細 - AIDLからPlay Billing Libraryに置き換える - Play Billing Library 1.xから2.xにアップデートする - Android Architecture ComponentとPlay Billing Libraryを使って定期購入を実装する - アプリ内課金の検証について - マネーフォワード MEで年額課金を導入したときのハマりどころについてのノウハウ（新しいアイテムの追加、プラン変更時の注意点、検証方法など）

The Android Gradle plugin API is evolving to become more efficient and useful for app and plugin developers. In this talk, members of the Android Build team will show you how to best utilize this API surface to customize the build process for your project. Whether you're an app developer that wants to dynamically change variant properties between builds, or a plugin creator who wants to publish their custom build logic for others, this talk will provide actionable steps you can implement today.

アプリ開発には欠かせないデバッグ。バグ報告を受けて原因調査に使うこともあれば、アプリがどのような動作をするのか、どのような状態になっているのかをコードを見ながら追いかけるのに使うこともあります。 ログやブレークポイントを使った基本的なデバッグを使う機会はあれど、デバッガーを駆使した手法について少し知ることができるだけで、アプリの挙動、状態といったアプリの「なぜ？」を突き止めることぐっと近づくことができるはずです。 本セッションでは、初心者の方も対象として、実例を交えてAndroid Studioを使ったデバッグ手法を中心に、+1としてTimber、Stetho、Hyperion等のデバッグライブラリを使ったデバッグについても解説する予定です。 ＜アジェンダ＞ - Android Studioのデバッガー - Logcat - ブレークポイント - Android Profiler - etc... - +1：デバッグライブラリを用いたデバッグ - Timber - Stetho - Hyperion

Application Distribution (a.k.a application delivery, application deployment) is absolutely required for modern mobile development and collaborative development. A lot of people -- your co- mobile app engineers, server/api engineers, QA engineers, designers, directors, testers and etc. -- would like to easily try changes you've made in some way. We have currently several choices of distribution services and there are a lot of workflows that include such services. However, we cannot get much information about the distribution services and/or the workflows curiously. Because Application Distribution stuff is kinda tacit knowledge of each company and/or team. So we do not so often rethink and change currently using delivery flows, unfortunately. A delivery flow that you are currently using might be *stable* but it's not always *effective* in any other company. It doesn't mean less-useful, of course. Let's rethink and rebuild your mobile application delivery environment through this presentation to accelerate development. Points: - The overview of Application Distribution - The history of Application Distribution services - Pros/Cons of the currently available services - Examples of practical delivery flow

Debugging tools are essential to analyze application status during the development phase. By using them, developers can efficiently get enormous amounts of information about both the internal and external operations, for example, display information, output logs, database monitoring and internet connection status. However, how can developers more deeply understand debugging libraries? This session would address debugging libraries to dive deep into their implementation. Points: ・The overview of debugging libraries ・The explanation of internal implementation ・Development methodology and practical applications of debugging tools ---- アプリ開発で、デバッグライブラリはアプリの状態を分析するために必要不可欠です。デバッグライブラリにより、ログを出力する、DBや通信状態を見る、表示要素を分析するなど、アプリの現在の内部的・外部的状態を効率良く取得できます。 しかし、デバッグライブラリはどのようにアプリの状態を取得し、見やすい形で表示しているのでしょうか。 本セッションでは、デバッグライブラリの内部実装を探求し、アプリの状態を分析するための仕組みに迫ります。 現在考えているセッションの構成は次のとおりです。 ・デバッグライブラリについて 　・なぜデバッグをするのか 　・どんな情報を取得したいか 　・デバッグライブラリの紹介 　　・Stetho 　　・Flipper 　　・Hyperion-Android 　　・Chuck 　　・Timber / Log 　　・DebugDrawer 他 ・デバッグライブラリの内部実装 　・ログの取得 　・DBの値の取得 　・通信ログの取得 　・表示要素の分析 他 ・デバッグツールを実装する 　・デバッグ画面のデザイン 　・画面の呼び出し方法 他 デバッグライブラリについて概観した後、その内部実装をデバッグ情報ごとに丁寧に解説していきます。そして、得られたノウハウを自作デバッグツールの実装にどう活用できるかを紹介します。 セッションを通じ、デバッグツールに関する知見を詳しく紹介するとともに、内部実装を掘り下げるノウハウについても解説できればと思います。

In the last few releases of Android Studio, we added many new design tools, like navigation editor, resource manager and more. In this session, we will take a look at those new tools, covering how to use them to build your applications more efficiently. Specifically, we will cover the new resource manager, the layout editor & nav editor as well as the upcoming motion editor in Android Studio 3.6+ and how those can be used to develop Android applications faster.

Build scans provide some very useful information about Gradle Builds. Build time, configuration time, task execution time. Scans even show garbage collection time, time spent downloading dependencies, time spent in annotation processors? What can you do with all this data? In this talk I'll share how to surface actionable information from your Gradle build immediately to developers without using the build scan plugin or Gradle Enterprise. This talk will also show how to use the Gradle Doctor plugin and how it can help improve your build speeds: https://github.com/runningcode/gradle-doctor

Automated Testing is essential to making your apps production-ready and to prevent introducing bugs when you change something. Flutter is an interesting case for testing because it is cross-platform. You should be writing also just one test for all your platforms making it easier to maintain. Flutter offers three types of tests, unit, Widget, and integration tests. We will focus on widget and integration testing. Widget testing is new for Flutter, coming from Android and iOS. Integration testing is also something you want to make sure your app does not have issues running on iOS or Android. When you do tests, you mock your dependencies and the network responses and requests. We will discuss how to mock your dependencies and network requests to have a stable test suite. Also, sometimes you also use plugins for Flutter that are using platform-specific code. Examples for these are Firebase Authentication and Firebase Database. We'll discuss how to mock these plugins so you can write widget and integration tests. Of course, when doing automated tests, you also think about CI/CD. We will also discuss which services you can use to run your tests and how to set up your tests for CI/CD.

2018年にKotlin 1.3でFeatureとしてMPPが入り、また同年末にはFlutterがリリースされ、Android界隈で見ただけでもMPF(Multi-Platform)の実現方法が多様化しています。 そんな2018年下旬、私達のプロダクトはKotlin/MPPでの開発を採用し、現在オンプロダクトで稼働させることができました。 人的リソースは有限であり人材不足が叫ばれる昨今、省コストで素早く価値をデリバリーできるMPFは、プロダクト立ち上げ時に気になる領域です。 反して、MPFは概ね継続的な開発に問題を抱えることが多く、事業が継続した場合のメンテナビリティが課題になりがちで採用に二の足を踏む方も多いのではないでしょうか？ 今回私達は長期運用を目的とした既存アプリのリプレースという観点で開発手法の選定を行いましたが、Kotlin/MPPはその目的に十分足るものでした。 では、Kotlin/MPPは他のMPFとはどのような違った特徴を持っているのでしょうか？ ## 予定している内容 以上の経験を元に、この発表では以下のことについて話したいと思います。 * Kotlin/MPP採用に至った経緯 * Kotlin/MPPを採用することによるメリット・デメリット * デメリットに立ち向かうアプリケーション設計 * AtomicDesign、Flux、(Clean Architectureベースの)オニオンアーキテクチャ * MPPで使えるライブラリ使えないライブラリ * CoroutineとRxの共生 * 開発中に発生した問題とその対処 ## この発表で得られる予定の知見 * Kotlin/MPPが向いてること、向いてないこと * 実際にKotlin/MPPを使ってみた経験談 * Fluxによる大規模、ロングライフ向け設計

Flutter 1.0が2018年末にリリースされて以来、Flutter開発に関する話題を目にする事が日に日に増えているように感じます。 普段Androidアプリを開発しているエンジニアの中にも、そろそろFlutterを触ってみたい！と考えている方は多いのではないでしょうか。 しかしFlutterによるアプリ開発には、Androidアプリ開発と比べて勝手が違う部分が多々あります。 Androidでは出来てたコレ、Flutterではどうやるんだろう？ Androidでは面倒だったコレ、Flutterだったら簡単に出来たりしないかな？ このセッションでは皆さんのそんな疑問にお答えします。 予定している内容 * 開発環境・ツールの違いについて * 開発言語の違いについて * フレームワークの構造の違いについて * ライフサイクルの違いについて * Jetpack Architecture Componentsを使用して作成したAndroidアプリと、 Flutterの代表的なアーキテクチャで作成したアプリの違いについて * Androidでよく使われるUIコンポーネントはFlutterでどうなっているか * Android特有の機能を実装する際の違いについて * Androidアプリ開発とFlutterによるアプリ開発のコストの違いについての考察

Google謹製のクロスプラットフォームフレームワーク Flutter の1.0が公表されて早くも1年が経ちました。 Flutterは過去のDroidKaigiにおいても継続的に話題に上がっていましたが、今や知名度も高くなり、プロダクションでの使用事例も聞かれるようになりました。 プロダクションで使用する際には、アプリケーションアーキテクチャをしっかりと検討する必要があります。 Flutter開発においてよく見られるアーキテクチャを数例とりあげ、それぞれのメリット・デメリット、チームやプロダクトの特性に合わせた選び方について、実際にプロダクションでFlutterを採用した経験からお話をさせていただきます。 内容（予定） ・見通しの良いコードとは ・Flutterだからアーキテクチャを考えたい理由 　・Clean ArchitectureをFlutterで実現するには？ 　・宣言的UIこそが、ドメインロジックと表示ロジックを分離する切り札 ・状態管理に使用されるパターン 　・StatefulWidgetに状態を管理させる 　・ScopedModelパターン 　・BLoCパターン ・状態管理を支える技術 　・ProviderなどがDIを可能にする技術 　・Stream 　・ChangeNotifierとWidgetのbuildタイミング問題、その回避方法

多くのものが出てきたクロスプラットフォーム開発のツール。 現在ではXamarin, React Native や Flutter が知られており、近年はKotlin/Native も広く知られるようになりました。 そんな中、2017年から細々と開発が行われていたScadeをご存じでしょうか？ このセッションでは、そんな「Swift」を使ってクロスプラットフォーム開発のできる"Scade"の紹介をします。 目次案は以下のような内容を考えています - 既存のツールとの比較 - Swiftで開発できることのメリット - Scadeで出来ること/出来ないこと ..etc Many cross-platform development tools have appeared. Xamarin, React Native, and Flutter are currently known, but in recent years Kotlin / Native has become widely known. Did you know that Scade was developed since 2017? In this session, we will introduce “Scade” that can be used for cross-platform development using “Swift”. The draft table of contents considers the following: -Comparison with existing tools -Advantages of development using Swift -What you can / can't do with Scade ..etc

FlutterはWidgetをツリー構造に組み合わせて、UIレイアウトを構築します。 それでは、構築されたWidgetツリーはどのようにスクリーンにレンダリングされるのでしょうか。 重要な概念はElementとRenderObjectです。 RenderObjectはレンダリングの責務を担い、ElementはWidgetとRenderObjectの仲介役の責務を担っています。 ElementとRenderObjectは、重要な概念であるものの触れる機会が少ないため、開発者は普段あまり意識しないかもしれません。 しかし、WidgetとElementとRenderObjectの関係や、それぞれの働きを理解することで、品質やパフォーマンスについてより考慮した実装ができ、またカスタムしたレイアウトやUIエフェクトを実装する際の一助になるでしょう。 本セッションでは聴講者が、Widget,Element,RenderObjectを理解して、パフォーマンスを考慮した実装ができることをゴールとします。 また、RenderObjectWidget(RenderObjectを生成するメソッドを持つクラス)を直接用いて、 グラフィックを描画する方法についてもご紹介いたします。

A DroidKaigi staff original codelab. In this codelab, you will be tasked to split an existing app into multiple modules. For a more practical experience, we will use the GithubBrowserSample from the Android Architecture Components samples, which had its first commit three years ago. We have also used claat to prepare a more cleaner, Google Codelabs-style course material. Note that codelabs participation is on a first-come, first-served basis, but you can join/leave at any time! DroidKaigiスタッフオリジナルのCodelabsです。 今回は既存アプリのマルチモジュール化に取り組んで頂きます。 実践的なCodelabsを実現するため、最初のコミットからほぼ3年が経過しているAndroid Architecture Components samplesの一つ、GithubBrowserSampleをマルチモジュール化するお題としました。 チューターと一緒に、GithubBrowserSampleのモジュール分割をおこなっていきましょう。 今回はclaatを用い、Google Codelabs形式の資料をご用意しています。 なお、受付は先着順となります。入退場は自由ですので、ふるってご参加下さい！

Credit card data should be handled sensitively and securely. Kyash which is the fintech app provided by my company supports the registration, display, activation in the app. https://play.google.com/store/apps/details?id=co.kyash I'll talk about the tips to handle the creadit card data from my experience in Kyash. It would be helpful when you create the app which handles the credit card data like below. - Input (Form validations、EditText cursor、Card brand check) - Scan（Scan by camera、Contactless scan by NFC） - API (Certificate pinning、Encryption and decryption) - User's action (Copy&Paste、Screenshots alert) -------- クレジットカード情報はとても慎重に扱われるべき情報です。 私が業務で携わっているKyashでは、Androidアプリ上でクレジット/デビットカードの登録や表示、有効化を行います。 https://play.google.com/store/apps/details?id=co.kyash このセッションでは、私が業務で培った経験から、クレジットカード情報を扱うアプリを作成する際に知っておくべきことを説明します。以下の内容に触れる予定です。 - カード入力 (バリデーション、EditTextのカーソル制御、カードブランド判定) - カード読取（カメラでの読取、NFCによる非接触での読取） - API通信 (証明書ピン留め、暗号化と復号) - ユーザー操作 (コピー&ペーストの制御、スクリーンショット警告)

近年、Siriなどの音声アシスタントアプリやAmazon Echo、Google Home といったスマートスピーカーなど、「音声」領域のサービスが立て続けに登場し、注目を集めています。音声領域のサービスの肝になる技術の１つが、人間の声を人工的に作り上げ読み上げる技術、「音声合成(Text To Speech = TTS)」です。私たちが利用可能な音声合成技術は急速に精度を上げており、様々なサービスに質の高い「声」を組み込むことが可能になっています。 本セッションでは、Androidで音声合成を活用するための周辺知識から具体的な実装方法について紹介をします。実装方法の紹介では、基本的な音声合成の利用方法や音声とUIを連動させる方法、アプリのアクセシビリティを向上させるための利用方法などについて紹介する予定です。 【前半: 周辺知識編】 ・音声合成の概要 ・アプリで利用可能な音声合成の紹介 　　- Android標準の音声合成を利用する場合 　　- 外部サービスを利用した音声合成を利用する場合 　　- 独自で音声合成を利用する場合 ・導入事例の紹介 【後半: 実践編】 ・音声合成の実装方法の紹介 (予定) 　　- 音声合成の基本的な実装方法 　　- 音声合成とUIを連動させる方法 　　　...etc ・音声合成を利用したアプリのアクセシビリティ向上

How to maintain privacy of app users when developing machine learning & artificial intelligent solutions, including how to personalise the app experience with machine learning, develop performant and scalable machine learning on the cloud, and use that effectively on mobile devices without compromising the privacy of the app users. This also includes security concepts in machine learning, and describes how to attain portability across platforms by re-utilising the same concepts and architectures.

Androidアプリ開発を長くやっていると、当然、とんでもない失敗をたくさんやらかします。 リリースの翌日大炎上。クラッシュ数グラフがうなぎ登り。低評価レビューの嵐。そこまで行かずとも、危うくとんでもないバグ付きアプリをリリースするところだったぜ、というヒヤリハット事例もたくさん。皆さんもそんな経験ありますよね。 このセッションでは、そんなAndroidアプリを開発していると遭遇する可能性のある失敗事例、失敗に繋がってしまった間違った設計、それに対してどのように対策をしたのか等を私の経験から紹介していこうと思います。 「あるある」「すでにやらかしたわ」と盛り上がりつつ「え、そんなことあるのか」「なるほどそうすればいいのか」という発見が一つでもあればと思います。

昨今、Androidアプリでのチャート表示はMPAndroidChartというOSSライブラリをよく使われているのを目にします。 このライブラリは様々な種類のチャートを表示することができ、非常に便利なライブラリなのですが、動的・リアルタイムでのデータ追加は強引に行うことはできますが、ライブラリ公式ではサポートされていません。 今回 bitFlyer の主力機能である『プロ向け取引ツール bitFlyer Lightning』のAndroidネイティブ版において、秒間最大30個超のデータを受け取って処理しリアルタイムに表示するキャンドルスティックチャートを用意する場面に出会いました。 MPAndroidChartを用いて強引にリアルタイムに見えるような実装を行ってもパフォーマンスがあまり良くないチャートになってしまいました。 そのため、今回はOSSライブラリを使わずに、大量のデータをリアルタイムに受け取り、処理を行い、描画するキャンドルスティックチャートを自前で実装し実現しました。 本セッションでは秒間30個超のような高速でストリームに流れてくるデータを受け取り処理を行い、リアルタイムに表示を更新するキャンドルスティックチャートを実装する手順、中身、チャートに用いるデータの管理方法、Tipsなどを1ステップずつ解説します。 <予定している内容> - チャートの基本 - Androidアプリにおけるチャートを表示する際のソリューション - スクロール、拡大縮小、長押しの取得が可能なチャートの実装方法 - 高速に追加されるチャートに表示するデータの管理方法 - 実装するにあたっての罠やTips ※ 時間があれば、応用として非リアルタイムラインチャートについての実装にも軽く触れる予定です。

AndroidやGoogle Nest Hubなど画面を持つデバイスでのActions（音声対話アプリ）にグラフィカルなユーザーインターフェイスを表示できる新機能「Interactive Canvas」が2019年8月にリリースされました。「動物しりとり」という1日に200回ほど使われている発表者のActionsに発表者がどのようにInteractive Canvasを導入してもともと音声のみだったユーザー体験を作り変えていったのか、事例を元にInteractive Canvasの使い方、作り方を解説します。

When you think of Bluetooth on Android this first thing that pops into your head is probably a phone controlling a speaker or smart watch but, that’s not all the technology can do. Bluetooth is powerful and the API for Android is flexible allowing you to solve some pretty interesting problems. I work for YAMAP, the number one outdoor app in Japan. One of our main goals is to keep our users safe while exploring the outdoors. In the event of an emergency, we want the most up to date location information, even if the user is hiking out of cellular service range. To accomplish this we implemented a large scale peer-to-peer BLE network and along the way encountered many special cases and learned lessons that could benefit anyone trying to communicate over BLE on Android. In this talk we’ll take a hands-on look at implementing BLE communication between app instances and cover the following topics in detail. - Bluetooth types and their availability on android - Checking for specific device feature availability (a bit trickier than you might expect) - Recommended configurations for BLE clients and servers including tips on battery life and performance - Notes about interoperability with app instances running on iOS

Androidでは、iOSのReplayKit同様にスクリーンキャプチャできる技術としてMediaProjectionがあります。今回は、MediaProjectionを使ってスクリーン配信アプリを実装する上で、ハマったことなどについてお話していきます。 ＜基本＞ 1. MediaProjectionで画面をキャプチャする実装の話 2. OpenGLで映像フィルターを実装する話 2. MediaCodecでH.264にエンコードしてRTMPで送信する話 ＜応用＞ 3. Xperia 1やPixel 3 XLなど、特殊なアスペクト比のデバイスに対する対処策について 4. MediaProjectionを使って、端末内部の音声をキャプチャする話 5. Oboe(AAudio/OpenSL ES)と組み合わせて、音声を低遅延でキャプチャする組み合わせについて

ExoPlayerはカスタム可能なインターフェースを提供し、より使用者に適した形で最適化できるように設計されています。 様々なシチュエーションにおいて、どのようにPlayerを最適化することができるかを主に話します。 また、動画再生ではクラッシュではなく、動画が止まったり映像がカクついたりするような再生不具合が発生しますが、そのような際のデバッグ方法や調査方法などのTipsも紹介します。 例) 例外(BehindLiveWindowExceptionなど)を減らすためにどのようなことができるか。 例) 再生開始時の最初に取得すべき解像度を考える 例) TVやMobile、LIVE/VODでどのようなことを考慮すべきか