View + InputConnection + Editable + Bitmapを使って縦書きのTextViewを実装した話をします。 TextVIewやStringを使わなくても文字入力ができるViewを作ることが可能です。 iOS / UWP / Windows / macOS / Ubuntuなどの他プラットフォームでの縦書きTextViewの実装経験も交えて、Androidでの縦書きTextView実装の概要と注意点について話します。 また周辺技術としてUnicodeの話、OpenTypeの仕様を中心としたフォントの話もあります。 # 内容 - TextViewとは何者か - 文字列入力系としての側面 - フォント描画系としての側面 - IMEとは何か - 文字入力の仕組み - IMEとアプリの関係性 - InputConnectionの罠 - StringとEditableについて - StringとAndroid Studioの関係 (閑話) - UnicodeとフォントからBitmapが作られるまで - テキストレンダリングエンジン実装の概要 - フォントの役割とOpenTypeの仕様 - OpenTypeや文字列描画系から見たUnicode Emoji事情 (閑話) - 昨今のAndroid内のフォント事情 - Variable Fontの登場 - 縦書きTextView実装で気をつけるべきこと
Intended Audience
文字についてUnicode / IME / フォントと言われて何となくイメージが浮かぶ方を対象にしています。 特に: TextViewの独自実装に興味のある方 / 文字入力システムに興味のある方 / 文字描画システムに興味のある方 / 縦書きに興味のある方 に聞いてもらえると嬉しいです。Android Testing Support Library (ATSL) is announced to be reborn into Android Test and to be a part of Android Jetpack. One of the main themes of Android Test is "Write once, run everywhere" which roughly means that if you write one test class, it will be possible to run both Instrumented Test and Local Unit Test. It also reportedly provides the execution entry point and unified form of collection of the results for both Instrumented/Local Test by the project called "Project Nitrogen". In this session, you would learn the following contents: * How to organize your test code to be "write once, run everywhere" ready * How they are executed under the hood * What's new about Project Nitrogen (hopefully) Notice I have nothing to do with Google or Android Test team, so all contents of this session will be external observations.
Intended Audience
People who are already writing Android's tests and are interested in new testing methods.Since Kotlin was added to the official development language of Android in 2017, the importance of Kotlin continues to increase. Due to Kotlin's flexible notation, extension function, Coroutine, etc., how to write test code is changing dramatically from the Java era. In this session, you would learn the following contents: * How to write Kotlin's extension test * How to write Kotlin's Coroutine test * New testing frameworks & assertion libraries of Kotlin era Notice I have nothing to do with Google or JetBrains, so all contents of this session will be external observations.
Intended Audience
People who are already writing Android's tests and are interested in doing them in KotlinAndroid Thingsでは様々なハードウェアを扱うことができますが、より高度なハードウェアを操作する場合はドライバ(ソフトウェア)が必要になります。いくつかのドライバはAndroid Thingsに標準で備わっていますが、多くの場合は一から、あるいは、他のプラットフォーム向けのドライバをAndroid Things向けに移植しなければならないでしょう。Android Thingsではユーザーが独自にドライバを開発できる仕組みがあり、User-space Driverと呼んでいます。 本セッションでは、User-space Driverを効果的に設計するには対象ハードウェアのデータシート(電気的な仕様やタイミングチャートなどが記載された仕様書)をどのように読み取り、ドライバとしてどのように設計すべきかを解説します。 また、その設計をKotlinでどのように具体的に実装に落とし込むのかを実例を元に解説します。
Intended Audience
・Android ThingsのUser-space Driverの実装方法を知りたい方 ・Kotlinでハードウェアを操作するドライバをどのように書くのかに興味がある方 ・Arduinoなど他のプラットフォームからのドライバの移植を考えている方 ・Android Thingsで独自のプロダクトを開発したい方(趣味・実用レベル問わず) 前提知識: ・Androidアプリの開発及びKotlinに関する基礎的な理解があることRecyclerViewでのページング処理を簡単にしてくれるPagingLibraryの使い方や実装上のポイントなどを解説します。 - Paging Libraryの基本的な使い方 - Room / APIと組み合わせた実装 - DataSourceの種類について解説 - 実装するときのポイントや注意点
Intended Audience
- Paging Libraryを使ってみたい方 - 前提知識: LiveData / RecyclerViewの基本的な使い方Androidアプリを作る際には、Drawableや画像を扱うことは避けられません。 表現力の高いアプリを作るためには、より多くのDrawableや画像を扱うことになると思います。 しかし画像の扱い方を少し間違えると、読み込みが遅くなったりOOMでアプリが落ちるといった悲劇に見舞われてしまいます。 アプリの動作が高速で安定していることはユーザー体験の最低限の条件です。 このセッションでは、Drawableと画像の扱い方の基礎を理解でき、安定したアプリ実現するために役立つ情報を話します。 ■セッションで説明しないこと ・Android上での画像処理 ・NDK、Render Script、OpenGLなどを使った各種エフェクトなど ■目次(案) ・Drawableの扱い方 ・そもそもDrawableとは何か ・扱う際の注意 ・使い回しと状態の複製 ・Drawableの種類と使い分け ・画像の扱い方 ・Bitmapの扱い方 ・recycle、orientation、inSampleSize ・Uriの種類と扱い方 ・GrantPermission ・Pから登場したImageDecoderの解説(仮) ・なぜ画像ライブラリを使うのか ・便利な使い方と内部動作略解 ・Picasso、Glide
Intended Audience
・Drawableのことが詳しくわからない初級者 ・画像について理解を深めたい中級者 ・画像を扱うことが多いアプリ開発者■概要 Wi-Fi peer-to-peerやMultipeer Connectivityなど、Android端末同士、iOS端末同士での通信はフレームワークレベルでサポートされています。 それならAndroidとiOSの間でもP2Pで通信したい!と思いついたのが運の尽き。紆余曲折を経て悲しい結末に向かうまでのお話となっております。 ほんの少しだけローレイヤーの話も出来たら良いなと思っています。 ■アジェンダ(仮) Wi-Fi peer-to-peerを使ってみる Multipeer Connectivityと連携できるのか Advertising packetに希望を託して
Intended Audience
ピアツーピアの通信に興味の有る方 意地でもサーバーと会話したくない方With Kotlin Coroutines graduating from experimental status, it’s time to invest in exploring ways of making good use of it. In this talk, I will show you the different use cases of Kotlin Coroutines as used with RxJava today. By the end of this talk, you should have a better understanding of how to achieve most use cases of RxJava with Kotlin Coroutines.
Intended Audience
Developers with a background in programming with Kotlin.Google I/O 2017 で Kotlin が公式開発言語になってから DroidKaigi 2019 時点で 2 年近くになりますが、その間にも Kotlin Coroutines や Architecture Components, Android KTX などの周辺環境が整備されてきています。Java と比較して Kotlin 時代の Android アプリ開発どういうものなのかをもう一度整理して、これから Android アプリ開発を行いたい人や、まだ Java で Android アプリ開発を行っている人に示したいと思います。
Intended Audience
1. Java で Android アプリ開発をしている人 2. これから Android アプリ開発を行いたい人 3. Kotlin に興味がある人ConstraintLayout has had quite a year in 2018: the release of 1.1 in April and then announcement of 2.0 in May. The ConstraintLayout team has certainly kept us busy with frequent updates, optimizations, and new features including groups, barriers, circular constraints, and optimizations. As if that wasn't enough, ConstraintLayout 2.0 now adds a Helpers API and the MotionLayout, which builds on the capabilities of ConstraintSets to give developers featured-packed and fine-grain control in building animated transitions within a layout, including key frame animation. In this session we will look at concrete examples and code (and also adventure to the design view and motion editor) to show how to use these features to do really cool things with ConstraintLayout. We'll also talk about the features in ConstraintLayout's future.
Intended Audience
Android developers with some familiarity with ConstraintLayout but that have not as much experience in the newer features including the capabilities of MotionLayout.Androidの公式言語として仲間入りしたKotlinの初学者向けハンズオンです。 Kotlinの概要と誕生の背景から始め、 Kotlinの基本文法、クラスやオブジェクト、拡張関数を学び、体験します。 実際に手を動かす課題としては、FizzBuzzなどの簡単なものから、 クラスの定義とその機能追加などちょっとだけ本格的な内容も含みます。 Kotlinの言語そのものにフォーカスしているため、 本セッションで得られる知識は、Androidに限らず他の分野でも応用できるでしょう。
Intended Audience
・Kotlinに興味があるが未経験の方 ・JavaでAndroidアプリ開発を行っていたが、よりよい言語を求めている方The Android platform provides many powerful and flexible layouts, but sometimes you may need something more custom, more performant, or both! A custom ViewGroup can be a valuable tool in building delightful and performant UI at the cost of being complex and difficult to build. Learning some tips and tricks can help with the difficulty, and building a custom ViewGroup can provide so much insight into how platform layouts work. In this talk we will go through a step-by-step example of building a custom ViewGroup including: - Implementing onMeasure and onLayout - Handling an arbitrary number of children - Streamlining layout logic for performance - Utilizing custom LayoutParams - Creating custom attributes for additional functionality At the end of this talk, hopefully you will have the confidence and knowledge to try building your own fully custom ViewGroup.
Intended Audience
Android developers that: - Have some experience with building Android UI - Are trying to increase performance of complex UI - Want to build reusable layout components for their team or for open sourceAndroid ThingsのSoMを利用したプロダクト開発の実際について発表します。 Android ThingsのSoMをメインコントローラーとして採用したプロダクトを2019年にローンチします。プロダクト開発を通して得たThingsのPros / Consやノウハウを可能な限り共有します。
Intended Audience
Android Thingsを利用してプロトタイプから量産製品を開発しようと考えている方 Android Thingsが実用的なのか疑問に感じている方Mockito 2.x solves many problems that most of the Android developers had in their unit tests in Mockito 1.x. But what if we have today a large app with tons of unit tests written in Mockito 1.x and PowerMock, will it be an easy task to migrate? Unfortunately, it is not a straight forward task since Mockito 2.x is not fully compatible with the old behavior of Mockito 1.x. Adding to this complexity, if we have PowerMock in some of our old unit tests, then we have to face another dimension of complexity since most of PowerMock versions have integration issues with Mockito 2.x. This session goes through the learnt lessons and the tips and tricks that are needed to be considered to successfully migrate to Mockito 2.x. This session introduces techniques that can help developers to get rid of PowerMock and develop clean unit tests. This session has several demos to show the benefits of Mockito 2.x migration and the techniques for getting rid of PowerMock in unit tests.
Intended Audience
Basics of Mockito and unit testingUnit testing coverage is a great way to show us the amount of tested lines and branches of code, but is this really enough? The answer is "no" since unit testing coverage does not really fully measure the efficiency of the unit tests. This is why there is a need for having techniques that show unit tests efficiency. Mutation testing is one of these powerful techniques. The main idea of mutation testing is to perform byte code modifications (mutations) to original Android app source code and then run app unit tests to check if they are strong enough to fail as a result of these mutations. This session discusses mutation testing techniques, and demonstrates PIT as a powerful mutation testing tool for Android apps with demos.
Intended Audience
Basics of unit testing.In big Android projects, project build duration is a very important metric that should be monitored frequently because big projects usually contain a lot of code with dependencies to many libraries, and some of these libraries may be huge like Guava, and usually a complex logic exist in certain areas of the project. Enhancing build time is essential. Not only essential for engineering productivity but also essential for product time to market for getting products out of the door faster. For big projects, solving this build problem may be very hard and very tricky, since it can require optimizations on the build management system (Gradle is assumed for this case), and may be requires huge refactoring on the current app implementation to reach to the desired build time target. This session discusses some of the useful tips and best practices to consider for having modularized android projects with faster build times.
Intended Audience
Basics of Android development.2018年末に大規模リファクタリングを終えて、React Native v1.0が公開されました。 React Nativeを使ったAndroidアプリ開発がどう変わったのか、どの様に変わっていくのかを説明します。
Intended Audience
Androidアプリ開発者 クロスプラットフォーム開発に興味があるエンジニアの方 Androidアプリ開発に興味のあるWebエンジニアの方近年、自然言語処理を用いた音声アシスタントやチャットBOTサービスが普及してきている。AndroidにおけるSpeechRecognizerも非常に認識精度が高い。 しかしこのような対話をベースとしたサービスは利用環境が制限される。例えば劣悪な環境雑音下での音声アシスタントとの会話や、文字自由に入力できないときのチャットBOTサービスはかなり使いづらい。対話が複数回必要になると更に難易度が増す。AndroidにおけるSpeechRecognizerが優秀であっても途中でユーザーがドロップする確率が高くなってしまう。 ユーザーにとって究極にフレンドリーなサービスは、何も言うことなく、何も文字を打つことなく正確に命令をすることであるが、現状では非常に実現難易度が高い。 よって今回は、ユーザーの仕事をなるべく減らし、かつ正確に命令をできる状態を目指す。 本セッションでは、最初にDialogFlowやAndroidのSpeechRecognizerの基本を極めて簡単に説明する。次にユーザーが特定の環境で、なるべくユーザーの仕事を減らしながら特定の目的を果たすために、AndroidのSpeechRecognizerとDialogFlowを組み合わせて用いることでボイスコマンド音声認識の精度向上を試みる。そしてその具体的な手法及び結果を示す。
Intended Audience
DialogFlowによる自然言語処理に興味がある DialogFlowを使ってみたいけどいまいち実用化できるケースが思い浮かばない Androidで音声アシスタントのようなものを作ってみたいAndroid Thingsでおうちをいい感じにするぞー!
Intended Audience
初心者# 概要 技術は常に進化していきます。ノウハウが集約された進化に追従していくことは、より安定したアプリケーション開発を目指す上で不可欠です。 しかし、時を経て、機能が追加されるほど、コードは膨らんでいき、進化に追従することが大変になっていきます。 現在約20万行のコードを抱えるじゃらんAndroidアプリも、変更される理由の異なる複数の機能が絡み合い、気軽に新しい有用な技術を取り入れることが難しい状況になっていました。 そこで我々は、新しい機能を別レポジトリのモジュールとして切り出し、新アーキテクチャで構築する取り組みを進めています。 これによって、それぞれを独立した機能として、最適なアーキテクチャに進化させていくことを目指しています。 ここでは、共通化したもの/しないもの、実装方法のBefore/Afterや、苦戦した点についてお話します。 # キーワード * Modular Architecture * Android Architecture Components * MVVM * Atomic Design * Dependency Injection * JUnit
Intended Audience
レガシーコードとの向き合い方に悩んだことがある方Android Wearは失敗した、終わったとよく耳にしますが、私はそうは思いません。 つい先日、「Wear OS by Google」が発表され、FitやGoogleアシスタントが強化されるなど、まだまだ進化はつづいいています。 そんなAndroid Wearには多くの可能性を秘めており、様々なことが実現できるでしょう。 本セッションでは、そんなAndroid Wearでは何ができるのか?どんなことが実現できるのか?を、ライブ形式でWatchFaceアプリを実装しながらお話します。 次のような方を対象としています。 ・Android Wear向けアプリを作ってみたい方 ・Android Wear向けアプリを作ったことがある方 ・Android Wearで何か新しいことをやってみたい方 ・Wearable端末が好きな方
Intended Audience
Android Wearを持っている方、Android Wearのアプリ開発に興味がある方、自分独自のWatchfaceアプリが作りたい方が対象です。 This session targets for who has Android Wear, is interested in developing Android Wear apps or desire to develop your own watchface app.2014年末からAndroid Studio v1.0.0が出てから、ほとんどの方がAndroid Studioを使ってAndroidアプリの開発をしていると思います。 IntellijをベースにしたAndroid Studioでは非常に多くの機能が存在しています。しかしあまりにも多いため、埋もれてしまっている便利な機能があるのではないのでしょうか? このセッションでは、Android Studioの隠れた便利な機能を紹介して、Android Studioを使った開発をより快適に出来るようにお手伝いしたいと思います。 以下の知識がある方を想定しています。 * Android StudioでAndroidアプリの開発をしたことがある * Android Studioの設定をあまり変えたことがない * 複数人での開発を主にしている * セッション中にすごいと思ったら「おー!」って言ってくれる このセッションでは以下の設定の話をする想定です。独断と偏見で大半の方が触らないであろうと思った設定を中心に説明します。 * 自分専用のアクションリストを作ってみる * !=をカッコ良く * 通知周り * File Color * Kotlinのファイルフォーマット忘れ防止 * 急に別の言語書きたくなった時のストレス発散方法 * JSON書きやすくする * Run Configurationや.ideaの共有 * Layout Editor * Pluginのインストールの強制
Intended Audience
少なくとも「Android StudioでAndroidアプリの開発をしたことがある」は満たして下さい。まだ規模が小さいスタートアップや、ある程度の規模の会社でも新規事業部などに所属する場合、プロダクトにAndroidアプリ担当者が一人というのはよくあるケースだと思います。 0からジョイン出来ればまだいいですが、前任者から引き継ぐ形でジョインする場合、何からやればいいのか?など迷うことが多いのではないでしょうか? このセッションでは、そうした状況に直面している方へ、私が二社で経験したことを共有していきたいと考えています。 主な内容 - 引き継ぎ時に確認すべきこと - 引き継いだ。さあ、まず何からやろう? - タスクは山積み。どうやって優先度を付けよう? - レガシーなコードがいっぱい...。書き直すべき?
Intended Audience
初級〜中級者を想定しています。 Androidアプリの開発経験に依らず、1人でAndroidアプリの開発を担当する予定の方、もしくは前任者から引き継いで間もない方などに、特に聞いて欲しいです。Let’s face it, we spend a lot of time writing the same code over and over again. Maybe you are using the same pattern in different places. Maybe you copy&paste some classes and layouts when you create a new Activity using MVP or MVVM. Maybe you “reuse” the same files when you create a new App. What if you could generate that code automatically? Well, you can, and I’m going to show you how by writing your own Android Studio Plugin. In this talk you will learn how to create a new Android Studio Plugin using Kotlin, create templates to generate code automatically, write live templates to insert frequently-used constructors in your code, easily integrate Android Studio with Jira, create a brand new full App in minutes using feature modules with templates and much more.
Intended Audience
Android developers that want to save time by automating processes via and Android Studio plugin. E.g. Move a ticket in Jira/Trello/Other without leaving Android Studio, etc.working with Flutter and kotlin/native for cross platform development (done on a conference app). see article https://tech.olx.com/fast-prototypes-with-flutter-kotlin-native-d7ce5cfeb5f1
Intended Audience
Developers皆さんの作っている Android アプリにも Dialog はあると思います。「画面を増やすより楽だろう」とついつい軽く作られがちな Dialog ですが、見せ方や内容をよく考えないとユーザー体験を悪化させることにつながりかねません。 このセッションでは、Android アプリの Dialog について、もう一回振り返り、よりよい Dialog を作るために考えたいと思います。 1. Android アプリの Dialog とは? 2. Material Design から考える Dialog 3. DialogFragment 4. それ本当に Dialog で作るの? ちなみに101とはアメリカ合衆国の大学で入門向けを意味する番号です。
Intended Audience
Android の Dialog について振り返ってみたいアプリ開発者ARCoreのSceneformは2018年5月にリリースされました。Sceneformを使うと、ARKitに比べて簡単に、リアルに、オブジェクトを空間に配置して操ることができます。 私はARKitとARCoreそれぞれネイティブでアプリを開発してきました。その開発の中で得られた、Sceneformの使い方、実際にどのようにSceneformをプロダクトで使っているか等の知見をARKitと比べてお伝えします。 この30分のセッションを聞いた後、あなたはARCore Sceneformを使いたくて仕方がなくなるでしょう。
Intended Audience
- ARCoreの実践的な知識を得たい方 - ARに興味があるAndroidエンジニア - ビジネスとしてAR領域に興味がある各職種の方業務として、既存iOS/Androidアプリのリプレイスをクロスプラットフォームのアプリで行うことになりました。 その中で、まずはFlutter/React Nativeの2つで検証することに決まり、現在作業を進めております。 技術検証の内容としては、以下の内容を行っています。 * 公式ライブラリがないReproなどをリプレイス前と同様に動作させたい。 * CI上でテストを走らせたり、ブランチマージ後にFabric Betaを配信させるようにしたい。 * 公式プラグインについても正常に動作するかを確認して欲しい。 iOS側が正常に動かなくなるなど、実際にFlutterを検証していく中でつまづいたことを共有して行こうと思います。 また、私はFlutter/ReactNativeを触るまではiOSエンジニアの経験しかなかったため、発表のポイントがそちらの観点にずれるかもしれませんが、そちらの点のみご了承ください。
Intended Audience
Flutter/ReactNativeを触ったことがない初心者向けセッションです。 また、これからFlutter/ReactNativeを業務で使い始めたいエンジニアの方にはより響くかもしれません。 iOSあるいはAndroidの経験がある方がより理解しやすいと思います。業務として、既存iOS/Androidアプリのリプレイスをクロスプラットフォームのアプリで行うことになりました。 その中で、まずはFlutterを検証することに決まり、現在作業を進めております。 技術検証の内容としては以下の内容を行っています。 * ReproやAdjustなどFlutter公式ライブラリがないものをリプレイス前と同様に動作させたい。 * CI上でテストを走らせたり、ブランチマージ後にFabric Betaを配信させるようにしたい。 * 公式プラグインもあるFirebaseやCrashlyticsなどについても正常に動作するかを確認して欲しい。 iOS側が正常に動かなくなるなど、実際にFlutterを検証していく中でつまづいたことを共有して行こうと思います。 また、私はFlutterを触るまではiOSエンジニアの経験しかなかったため、発表のポイントがそちらの観点にずれるかもしれませんが、そちらの点のみご了承ください。
Intended Audience
Flutterを触ったことがない初心者向けセッションです。 また、これからFlutterを業務で使い始めたいエンジニアの方にはより響くかもしれません。 iOSあるいはAndroidの経験がある方がより理解しやすいと思います。いろいろなことができるAndroidアプリですが、その反面ソースコードが複雑になりがちです。 その複雑さの要因をひもときながら、オブジェクト指向設計、ドメイン駆動設計などの活用方法をお話しします。
Intended Audience
・オブジェクト指向についてなんとなく知っている方 ・大規模なアプリまたは大人数での開発をしている方 ・継続してAndroidアプリを運用、開発している方 ・ソースコードのリファクタリングを考えている方 ・これからちゃんとした設計をしたいなぁって方I walk through the different steps required to convince both management and engineers that Kotlin was the right way to go. Both by easing concerns and risks around its adoption (commit queue, unit testing and build times) as well as how to effectively on board the team.
Intended Audience
Developers trying to get their team/company to adopt Kotlin as their main development language for Android.In this talk we are going to see the internals of the new Dexing Compiler D8, introduced in AS 3.0 as experimental, D8 will give us faster and smaller outputs of dex files. We will understand better how is the Dex Processing in Oreo/P from the ART perspective, and how is affected in the new bundle apps. Additionally, we will see more about R8 a replacement for Proguard used in AS 3.2
Intended Audience
Android Developers with basic knowledge of the build process.近年モバイル開発界隈でレイアウトに関する関心が非常に高まって来ています。 iOSDC2018のIRT(Interactive Round Table)ではiOS開発有識者によるiOS開発におけるレイアウトに関して非常に深い議論が行われました。 その中でiOSのGUIレイアウトには非常に苦しく辛い部分があり、iOSエンジニアは日頃iOSのレイアウト開発に頭を悩ませています。 しかしAndroid StudioのGUI Layout Editorでは、iOSエンジニアが「こうだったらいいのに...」ということが見事に解決されているのです! iOSエンジニア視点でAndroid StudioのGUI Layout Editorの素晴らしさをiOSのレイアウト開発と比較して解説し、少しでも多くの方にAndroid StudioのGUI Layout Editorの素晴らしさ・美しさ・快適さを実感していただければと思います。
Intended Audience
- AndroidのレイアウトをまだXMLで組んでいる方でこれからGUIエディターを使っていきたい方 - AndroidのGUIエディタを使ってみたけど、やっぱりXMLで書いちゃう方がラクだと感じている方 - iOSとAndroidのレイアウト周りの開発の違いなど把握したい方 - iOSのレイアウト少し触ってみたら発狂してしまった方# 概要 技術は常に進化していきます。ノウハウが集約された進化に追従していくことは、より安定したアプリケーション開発を目指す上で不可欠です。 しかし、時を経て、機能が追加されるほど、コードは膨らんでいき、進化に追従することが大変になっていきます。 現在約20万行のコードを抱えるじゃらんAndroidアプリも、変更される理由の異なる複数の機能が絡み合い、気軽に新しい有用な技術を取り入れることが難しい状況になっていました。 そこで我々は、新しい機能を別レポジトリのモジュールとして切り出し、新アーキテクチャで構築する取り組みを進めています。 これによって、それぞれを独立した機能として、最適なアーキテクチャに進化させていくことを目指しています。 ここでは、共通化したもの/しないもの、実装方法のBefore/Afterや、苦戦した点についてお話します。 # キーワード * Modular Architecture * Android Architecture Components * MVVM * Atomic Design * Dependency Injection * JUnit
Intended Audience
レガシーコードとの向き合い方に悩んだことがある方MotionLayout is a new ViewGroup focusing on animation, which is provided with the ConstraintLayout 2.0 library. We provided this ViewGroup to allow developers to create complex animations in a declarative way, which existing Android animation framework, such as Layout Transition using TransitionManager, CoordinatorLayout or ObjectAnimator, didn't cover. In this talk we will going to cover the topics from the getting started and how MotionLayout differs from the existing animations framework to the deep dive into how the MotionLayout works. Following topics are going to be included: - Getting started - What is MotionLayout - Highlights of the key usages - What is the difference with the ways of animation Android framework provides - Integration with the layout editor - Where to use MotionLayout - Real app examples - Replacing existing animations in a declarative way - Integration with other key Jetpack components - How MotionLayout works internally - Math behind the scenes - Future plans
Intended Audience
Difficulty level : Beginner - Intermediate Target audience: Developers interested in animations or MotionLayout. Prerequisite about MotionLayout isn't required, but we are also going to cover the topics beyond the getting started level.私達Android Textチームは昨年のGoogle I/Oで"Best practices for text on Android"というタイトルで発表を行いました。 Droid Kaigi 2019では、この発表のフォローアップ、およびもう一歩踏み込んだ内容を話したいと思います。 トピックは以下の内容を検討しています。 ・TextViewのパフォーマンス特性 ・PrecomputedText(Compat)の使い方とその原理 ・その他Google I/Oでは語られなかった雑多な変更等について We did a session in Google I/O 2018 about the best practices for text on Android. I'm going to follow up the Google I/O talk and give a talk of more internal details. I will talk about - The performance tuning of TextView - How to use PrecomputedText(Compat) and its internal details. - Minor changes not featured in Google I/O 2017 "Best practices for text on Android" in Google I/O 2018 https://events.google.com/io/schedule/?section=may-9&sid=532cc42d-df69-4ded-9766-2987ea46d2d7
Intended Audience
AndroidのTextViewを使ったことがある方 Androidが文字を表示する仕組みに興味がある方 People who has an experience of using TextView on Android. People who are interested in how the Android renders the text on the screen.RxJavaの使い方は沢山です。間違った使い方もあります:コードの一部を変更したときに思わぬところで問題が起きるとか、コードを読んでも何をしているのかわからないとか。だが、正しい使い方に従えば最高のツールになります。Rxから得たベストプラクティスをアプリにも適用できます。 アジェンダ: ・サイドエフェクト隔離で不具合を防ごう ・どうやってビューとプレゼンターで一本のストリームでデータを共通できるか ・その流れを一方通行にする事で機能の追加を楽で安全にしよう ・不変オブジェクトを使って安心してデータを弄ろう リアクティブなアーキテクチャを作れるようになり、ロバストかつ楽しいアプリ開発を目指しましょう!
Intended Audience
デベロッパーの初心者からエキスパートまで全員モバイルアプリのリリースって毎日すると手間かかるしユーザーさんはダウンロードしてくれない時も多くないですか?ちょっとした修正でリリースするのは・・・それから同じ修正をiOSやWebにも入れてリリースしないとな・・・という時はありませんか?Squareではその課題を解決するためにバックエンドにできるだけ任せたらどうかと考えました! では、画面移動のロジックをサーバーに任せたアプリってどんな感じなん でしょう?要するに次にどの画面に遷移してどういう情報を表示するかわからないモバイルアプリなわけです。 Cash Appはサーバー、Android、iOS、Webを組み合わせてそんな仕組みを開発してます。下記のアジェンダの通りそれを紹介させて頂きます: ・何故その仕組みを選んだのか ・どうやって作ったのか ・どこで苦労したのか ・その仕組の強みとの短所は何のか 少し変わったクライアントとサーバーの組み合わせでユーザーさんに素早く機能修正を届けよう。
Intended Audience
デベロッパーの初心者からエキスパートまで全員This talk will elaborate on Freshworks' journey to class-platform development for mobile apps. It covers on why we decided to do a common code base solution, strategies, study we took and the decision(GoMobile) we came up with. Also how writing Golang code solved the problem and how GoMobile tool works under the hood to enable code sharing between platforms :)
Intended Audience
EveryoneKotlinは今やAndroidアプリ開発において無くてはならないものになりました。 またNull Safety機構等、便利な機能が豊富にあります。 一方、そのままでは手の届きにくい場所というものも有るかと思います。 本セッションでは幾つかの実例(たぶん)と、素のKotlinで書く場合とは違った、Arrowを利用した別解を共有できればと思います。 ### このセッションの目的 Arrowを触ったことがない人が、 * 簡単なDataTypeなら使えるようになる * applicative/monad 構文が使えるようになる * 使う上でのDocumentを探す上で、知っておくと助かるwordがいくつかわかる ### やらないこと * Monadそのものの説明等 ### 時と場合によってはやること * KEEP87におけるprototypeでのextension classの簡単な紹介
Intended Audience
* Kotlinでの何かしらの開発経験 * Androidアプリ開発経験 上記の両方または片方を満たす方Amazon Fire TVはAndroidだってご存知でしたか? Androidだということは、自分の好きなアプリが作れちゃうんです! 本セッションでは、Amazon Fire TV向けアプリではどんな事ができるのか、できないのか。どんなことに注意をしないといけないかのチップスをお伝えします。 またその実装方法を、具体的なコードを交えて1からご説明します。 次のような方を対象としています。 ・Amazon Fire TVを持っている方 ・Amazon Fire TV向けアプリを作ってみたい方 ・Amazon Fire TVを用いてユーザーへアプローチをしたい方
Intended Audience
・Amazon Fire TVを持っている方 ・Amazon Fire TV向けアプリを作ってみたい方 ・Amazon Fire TVを用いてユーザーへアプローチをしたい方Abstract: We all have heard stories about modularization, faster builds, quicker iterations and all the good things we get through it. But when it comes to actually breaking your legacy into modules, your code can give you a serious run for money. In this talk I will share how 60+ Android Devs at Booking got together to defeat the legacy and modularized the app to get 10 times faster builds. If you attend this talk you will be able to learn the best practices about modularizing your large code bases and avoid the pitfalls that we discovered in journey. Description: * In April 2017, devs @ Booking realized that it was becoming very difficult to iterate on changes while writing code for our Android App. * A clean build took up to 12 minutes even on the most powerful Macbooks available in the market. * An incremental build took up to 2 minutes. * We had tried several things to beat this like Composite Builds, JRebel for Android, building in the cloud with gradle cache etc. but nothing seemed to work. * In January 2018, a task force was formed to tackle this problem with the help of modularization since Gradle updates that were announced gave us a hope that building individual modules could be the answer to this. * At the same time, we had to integrate a new product in the app and we decided to create it in a separate module. * Of course the challenges of dependencies baffled us, but we started breaking the monolith in small steps to facilitate the development of that feature. * Within a quarter we were able to ship an MVP with our main application that was written completely in a separate module. * Guess the build times for this module to test incremental changes? 10 seconds and that’s when we got the signal that this is the way forward. * Especially if we wanted to support instant apps, app bundles etc. * I’ll cover how we extracted the modules, what is the current architecture we have and how we plan to leverage these efforts to move even faster in future. * We also leverage App Start Tests to help teams (mostly down the funnel) start their Activities/Screens instantly instead of going through the whole funnel to test each iteration of their code change. * App start tests are nothing but Instrumentation Tests that we run in emulator and suspend them for 24 hours, so that people can interact with the emulator to test their changes on the part of the funnel with all the pre-requisites fulfilled automatically.
Intended Audience
Preferably for people who already have apps that are at least a year old.本セッションでは、Material Themingの一歩先を目指したCustom Material Themingとこれをチームメンバーで作るためのサービスデザインについて紹介します。 Material Designを利用しているとどうしても同じMaterial Designを利用したアプリとデザインが似てしまい、ブランドに合ったデザインを提供することが難しいと感じたことはありませんか?そんな悩みを解決してくれるのがMaterial Themingです。さらにGmail、Google News、Google PayなどではMaterial Themingを利用するだけに留まらず、それぞれのブランドに合うようにMaterial Themingをカスタマイズされています。 今回私たちが運営しているママ向けNo1アプリのママリを用いてMaterial Themingのカスタマイズ方法や、サービスデザインの一環としてCustom Material Themingを取り入れる方法を紹介します。本セッションを通じて、「Custom Material Themingをやってみたい」、または「デザインシステムをさらに良くしたい」と思っていただけると幸いです。 このセッションでは以下の話をする想定です。 - Custom Material Themingの作り方 - Custom Material Themingを用いたサービスデザイン - デザイン設計書
Intended Audience
- Material Designを使っていると他のアプリとデザインが似てしまい困っている方 - Material Themingをカスタマイズする方法を知りたい方 - みんなでデザインシステムを作っていく仕組み作りを知りたい方Physically based rendering is a set of concepts that help create photorealistic results in 3D/AR. Modern Android devices are now powerful enough to deliver such experiences in real-time. In this talk, we will use Filament, the Open Source renderer behind Sceneform, to explore the physics of lights and materials. With this understanding you will be able to create photorealistic materials and lighting setups for your 3D/AR scenes. This talk will also explore some of the techniques used in Filament to achieve high quality and high performance on mobile devices.
Intended Audience
This talk is aimed at developers who are interested in photorealistic rendering on mobile. It will be particularly useful to developers thinking about or already working on AR experiences. No prerequisite knowledge of OpenGL, Vulkan or 3D rendering is required.With improvements in the ART runtime, developers should feel better about favoring good development patterns over memory-optimized-but-ugly-and-fragile techniques. But all of this is based on assumptions about the improvements of ART over Dalvik — what are the details? This talk will examine some of the specific improvements that ART has made, over Dalvik and over time, and will demonstrate what these improvements mean for raw performance of garbage allocation and collection work.
Intended Audience
Any Android developer wanting to better understand the behavior of the Garbage Collector to improve performance. No prerequisite knowledge is required.Photography is a powerful art form that you can use to share experiences, tell stories or simply delight others. I will share with you what I learned after over 10 years of practice. We will study some of my photos (https://www.flickr.com/photos/romainguy/) to learn about composition and exposure rules, when to use them, when to break them. You will also learn a bit about equipment, when and why it matters, and when it doesn't. Finally you'll get a peek at the entire process of publishing a good photograph.
Intended Audience
Anybody who'd like to get into photography or to improve their photography skills.GitHub API v4 が GraphQL になるなど、最近注目されてきている GraphQL。 Android で用いる場合は apollo-android を使うのが主流になってきており、Kotlin もサポートされています。 ですが、実プロダクトで導入されている事例はまだ少ないと思っています。 そこで本トークでは、実プロダクトへの導入実績を元に、 - apollo-android を始めとするライブラリ等の導入と気をつけるべき点 - ユニットテストについて - キャッシュ等のパフォーマンス面について - GraphQL を導入してよかった点、苦労した点 をお伝えできればと思います。
Intended Audience
GraphQL の導入を検討中の方MotionEvent、これはタッチ操作やマウス操作などのユーザーの入力をアプリ(View)に伝えるクラスです。OnClickListenerで受け取るクリックイベントも元をたどればMotionEventです。このMotionEventを受け取ってさまざまな操作ができるViewは公式のものだけでも非常にたくさんのものが用意され、OSSで公開されたもの、また皆さんが独自に作ったものもあるでしょう。 このMotionEventはアプリ内でも自由に作ることができるということはご存じでしょうか?MotionEventを作り、既存のViewに送り込むと当然そのMotionEventに該当する操作を受けとったものとして動き始めます。adbコマンドを使って自動操作をさせるなどは有名だとは思いますが、これをアプリで自在にできるようになるとさらに実現できることの幅が広がっていきます。 タッチ操作だけでマウスが接続されているかのような操作を行う。指一本でもピンチ操作を行う。別の端末の操作をフィードバックさせる。などさまざまなおもしろい操作方法を実現できます。 このセッションではMotionEventをどのように作るのか、どのような順序で伝えれば意図した操作ができるのか実例とともに順を追って丁寧に説明します。
Intended Audience
Androidアプリの開発経験のある方- 0からアプリを作るとなったとき、アプリケーションのアーキテクチャに悩み、なぜClean Architectureを選択したのか、実際にサービスインしているアプリを例にとって説明します。また、導入にあたっての苦労や今後導入したい方への注意点を話したいと思います。 - 実際に開発していると「新規メンバーに伝え、どうやって品質を下げないようにするか」や、「Clean Architectureの原則にどうしても従えない時どうするか」といった考えなくてはならない点が多々出てきます。そのような場合、どのように考えどういう行動をとったか共有したいと考えています。 - 予定しているアジェンダ - 導入するまで - Clean Architectureへの理解 - サンプルアプリ開発 - Kotlin, RxJava, Dagger, Retrofitを使ったレイヤードアーキテクチャ - 参考にしたプロジェクト - チームに良さを説く - 導入後 - 新規メンバーにどうやって伝えるか - 開発を回していくためのTips - 開発中の問題点とその解決策 - リリース後 - 導入してわかったメリット、デメリット - これから導入を考えている人へ
Intended Audience
- Clean Architectureに興味がある人 - Clean Architectureを導入しようと考えている人Sprite KitとはiOS固有の2Dゲーム開発用のフレームワークです。 キャラクタ同士の衝突や、キャラクタに重力をかけて落下させる動きなど、物理演算を使ったアクションを簡潔に記述できます。 残念ながらAndroidにはそんな便利なものはありません。 ですが、もしSprite Kitで作ったiOSのアプリをAndroidに移植したくなったら... 本セッションでは、Sprite Kitを使ったiOSアプリをAndroidに移植するにあたって、どのような課題があり、私がそれをどう解決したかについてお話しします。 ・移植で満たす必要のある要件 ・使用する技術の選定方法と選定理由 ・Sprite KitにあってlibGDXにない機能をどう補うか ・Open CVを使って画像から自動的に抽出した輪郭を衝突判定に利用する ・ネイティブライブラリを詰めこんだアプリのサイズを抑える
Intended Audience
・Androidアプリに物理演算を使用したインタラクションを実装したことがある方、方法を知りたい方 ・Sprite KitのコードをAndroidアプリに移植したことがある方、してみたい方 ・libGDXに興味がある方 ・OpenCVで画像の輪郭から動的にポリゴンを作成する方法を知りたい方Androidのアプリの実装をしていると、左右のスワイプでFragmentを切り替える実装によく出会います。 この実装については、検索すればたくさんの情報が見つかりますが、サンプル的な内容のものは見つかっても、実際のアプリでどのように運用しているかといった内容のものはあまり見つからないように思います。 本セッションでは、私が今までのプロジェクトの中で試行錯誤を経て辿り着いたベストプラクティスをご紹介します。 ・どのようなPagerAdapterを使うのが良いか ・PagerAdapter周りのいくつかの問題 ・これが最強のPagerAdapter ・スムーズなスワイプを実現するには ・OOMを超えて
Intended Audience
・Android初学者 ・ViewPagerとFragmentを組み合わせた実装でお困りの方 ・動的にページ数が変わるFragmentのViewPagerを実装したことがある方/する必要がある方 ・ViewPagerでのスムーズなスワイプを実現したい方 ・ViewPager絡みのOOMを解決したい方At I/O 2018, Google released the Firebase ML Kit which creates various exciting opportunities for Android Developers aiming to build smart apps without having to worry about the nitty-gritties of Machine Learning. The Firebase ML Kit APIs offer features like face detection, text recognition, object detection, etc. Your apps can also label a provided image for special characteristics and identify popular landmarks in a picture. In this talk, I will outline the usage of all the 5 APIs available in Firebase ML Kit and I’ll be doing so by using a sample app that utilizes these APIs. I will be walking you through the working of each api and you will leave the talk having sufficient knowledge of the APIs to go ahead and implement them in your own apps.
Intended Audience
The talk is a tech talk which will outline the usage of all the 5 APIs available in Firebase ML Kit. I’ll be using a sample app that I’ve created and will be walking the participants through the working of each api. I’ll also be talking about how they can upload a custom model to firebase and use that instead of using the preloaded models. After the talk, the attendees will have a good overview of these newly introduced apis and they will have enough knowledge to go ahead and implement them in their apps. Some blogs I've written on the same topic : https://medium.com/coding-blocks/google-lens-firebase-54d34d7e1505 https://medium.com/coding-blocks/creating-a-credit-card-scanner-using-firebase-mlkit-5345140f6a5c https://medium.com/coding-blocks/creating-a-qr-code-reader-using-firebase-mlkit-60bb882f95f9 https://medium.com/coding-blocks/identifying-places-in-a-provided-image-using-firebase-mlkit-fe3c918756da https://heartbeat.fritz.ai/building-pok%C3%A9dex-in-android-using-tensorflow-lite-and-firebase-cc780848395 Github repo for the code covered in the blogposts : https://github.com/the-dagger/MLKitAndroid Draft Slides : https://docs.google.com/presentation/d/1ibjMFCZkqbdN6Arxbt8HxKLOOAK2RahIDCyOMCuBJQI/edit?usp=sharingAs an Android developer, you probably have heard lot about Flutter, the newly released Framework by Google for making beautiful cross platform apps. Due to Flutter still being in beta, there are not many online resources available for someone looking to start building apps with it and here's where my talk will help you. This talk is aimed for Android developers trying to wrap their heads around Flutter and how it correlated with the native Android Framework. I'll be highlighting Flutter's similarities, dissimilarities to the Native Framework and the pros and cons of using Flutter in your production app. By the end of this talk, you will be motivated enough to flutter ahead with Flutter and get your hands dirty with it.
Intended Audience
I'll be covering the basics of flutter required by someone to get started with and make a simple app with an advance UI in flutter. The talk is mainly aimed at Android Developers wanting to learn Flutter and hence the talk will quite often refer common topics in the Android Native Framework and their Flutter counterparts. The talk will also graze upon some advance UI patterns to showcase how easy it is to recreate them in Flutter to run on Android and iOS alike. I recently wrote a blog with the same title that has more than 40,000 views on medium : https://proandroiddev.com/what-the-f-tter-understanding-flutter-as-an-android-java-developer-2158086a2bd9 The talk however will be a more in depth overview than the blog so that the attendees have a good knowledge of basic concepts in the Framework. Draft Slides : https://docs.google.com/presentation/d/1WXNkjvXaiVMXs_N5Wdx2acRz94uhzSlgfxHFB2_sw8M/edit?usp=sharingNavigation Graphs, introduced at I/O ‘18, finally provide us with a framework to build beautiful, consistent, and easy multi-screen applications. It’s a flexible tool, and with new frameworks come new questions -- but fear not! By the end of this session, you’ll be on your way to: 1. Set up a new NavGraph 2. Retrofit existing Activity+Fragment flows into a NavGraph 3. Pass data back and forth between NavGraph nodes We’ll also discuss when you *shouldn’t* use NavGraphs, and briefly touch on the “Single Activity vs Multi Activity” debate.
Intended Audience
Audience requires no prior knowledge of Navigation Graphs, but should understand Fragments and Activities at a high level.Kotlin is the perfect language for Android development, but for those of us saddled with legacy code, Android idioms from years past don’t always translate nicely to Kotlin. On the flip side, idiomatic Kotlin can produce un-idiomatic Java APIs! In this talk, we’ll discuss fun things like: - Tips to avoid the dreaded “I added Kotlin and now my build time is 30 minutes” - Some overarching goals to keep in mind when porting (old) Java to Kotlin - Generating useful APIs in Kotlin, consuming them in Java, and vice-versa
Intended Audience
The audience should have a general familiarity with Kotlin, but they do not need to be experts.To Observable or to Flowable? That is the question. Basically every RxJava code sample on the internet uses Flowable - but is that the best for Android developers? In this talk, you'll learn when you'll learn appropriate times for using Flowable on Android, how you should reason about backpressure, and what backpressure actually is! We'll also go through some commonly-used RxJava extensions (e.g., Room) and discuss what makes sense for your app and architecture.
Intended Audience
It would help for the audience should have a cursory understanding of RxJava, but in-depth concepts will be explained through the talk.There are few repetitive questions that come to our mind every time we switch companies. What makes a team fast? What makes a team effective? What are good product specifications? How to ensure the product quality? How many engineers are enough engineers? Where are the 10x engineers? Why some code is impossible to modify without breaking? Why hiring more engineers doesn't make a team faster? How to collaborate with product managers and designers? In this talk we are seeking answer to those questions by introspecting our experience working in different companies from different countries with different culture. This talk is about defining an engineering culture that can add value to the company in every aspect of it, from the product, design to delivery. We will talk about what makes a great engineer, what is good code, and what is an effective and efficient development process. We will give recommendations on how to design software that makes development easier and faster, how to change a team's development process to make it faster. The take away from this talk is a set of practices that will empower every engineer to strive, grow, and deliver great software, even among companies that struggle enforcing a strong engineering culture. Content Brief: Intro: “State of the art” Silicon Valley Style Why Silicon Valley is able to disrupt? Engineering culture Product & Design Sensibility Ownership Communication Agile Process Remove waste (Automate) Growth mentality Hiring Effective team How to develop the best product? Process Agile methodology: small changes, ship, validate metrics, Improving a product by writing clean code What? Why? How?
Intended Audience
Any developer will benefit from this talk on how to address day to day problemsMany developers fluent in Java don't feel comfortable converting common Java idioms to Kotlin. This talk will go through the famous Items in Effective Java and show how they translate to Kotlin. This talk will be helpful for all type of developers. The less experienced will learn some useful idioms and the more advanced ones will be able to learn how Kotlin language features make idioms so much easier to implement.
Intended Audience
For everybodyDagger2とはJava用のDependency Injectorです。 そして、Dagger-AndroidとはそのDagger2をAndroid用に拡張したライブラリです。 昨今、Dependency InjectionはAndroidアプリ開発に欠かせない技術となっております。 そして様々なDI用のライブラリがある中で、Dagger2はその中で代表格であるといっても過言ではありません。 そのような状況の中、一方で、Androidアプリを開発する際にマルチモジュールなプロジェクトで開発する現場が増えてきました。 このマルチモジュールなプロジェクトを実践する中で、どのようにDependency Injectionを実現するか。 実はこれがマルチモジュールプロジェクトで開発する際の、大きなハマりどころの一つだったりします。 本セッションでは、この大きなハマりどころをDagger2を使ってどのように解決するかを説明します。 アジェンダとしては仮ですが下記を予定しています。 1. Dagger2再入門 2. Dagger-Androd再入門 3. シングルモジュールプロジェクトでのDI 4. マルチモジュールプロジェクトでのDIの辛さ 5. Dagger2を使ってマルチモジュールプロジェクトでDIを実現する
Intended Audience
・マルチモジュールプロジェクトでのDIにお困りの方 ・マルチモジュールプロジェクトでのDIについて興味がある方 ・Dagger2の使い方を知りたい方 ・Dagger-Androidの使い方を知りたい方 ・Dagger2, Dagger-Androidの内部実装を知りたい方- VectorDrawableAnimationとLottieの使い分け + ShapeShifterを用いたVectorDrawableAnimationを作るためにデザイナさんに共有したこと(仮) + VectorDrawableAnimationを用いたDiscreteSeekBarの作成概要(https://material.io/design/components/sliders.html#continuous-slider) + Lottieはprogressをsetできるから便利だよね - 実際のプロダクトで `動き` のコードをMotionLayoutへ移行した話 + 移行前のコードと移行後のscene.xmlを用いて話します(パフォーマンスの話はしません) - LayoutManagerを少しだけ書いて作成した、良さそうな動きをするRecyclerViewの話 (https://twitter.com/amyu_san/status/1034082583624073216)
Intended Audience
- 動き をつけたいアプリを作りたい方 - アニメーションのサンプルを見てみたい方This session guides through taking an existing app and making it a multi-module app using dynamic delivery and app bundles.
Intended Audience
Intermediate developers- AndroidTV向けのアプリケーション開発するときは、`Leanback`というライブラリを理解することがとても重要です。 - そんな`Leanback`ライブラリについて、使い方や便利なところ、困ったところを共有します。 - Leanbackを適応してAndroidTVアプリを開発すると、アプリケーションのアーキテクチャからどうしても反れてしまったり、 要件を実現しようとすると異常に工数が膨れ上がったりする場合があります。 - コードの情報も少なく手探りで進めたAndroidTVアプリの開発のTipsを共有できればと思います。 - 予定しているアジェンダ - Leanbackライブラリの導入とその使い方 - Leanbackライブラリに沿ってアプリを作る - できること - できないこと - プレイヤー画面 - PlaybackTransportControlGlue - MVPからはみ出した実装 - 発生した問題とその解決 - リリース、その後 - とまらないonSavedInstanceStateエラー
Intended Audience
AndroidTVアプリ開発に興味がある人 AndroidTVアプリ開発に携わっている人プログラムを分析することで書式エラーやバグなどの疑わしい構造を検出するプログラムをLintといいます。 Androidには標準でLintが用意されています。またKotlin用に用意されているLintもあります。 我々開発者はこれらのLintを用いることで、標準的なコーディングをある程度維持することができるようになります。 さらに、通常の開発では少なからずそのチーム独自のルールがあるものです。 この独自ルールをLintをカスタマイズすることで、そのルールを維持することが可能です。 本セッションでは、これらのLintの特徴や違い、使いどころを紹介します。 また、チームでの独自ルール維持のため、Lintをカスタマイズする方法についてもご紹介します。 下記が現在考えているアジェンダです。(変わることがあります) 1. Lintとは 2. android-lint 3. ktlintとdetekt 4. ciとlintでチームに秩序を 5. Lintをカスタマイズする方法
Intended Audience
・android開発におけるLintに興味がある方 ・コーディング規約維持を自動化したい方 ・一歩進んだLintのカスタマイズ方法を知りたい方 ・kotlinにLintをかけたい方■概要 私は普段iOSをメインで書いているのですが、AndroidのConstraintLayoutを初めて触ったときに 「これ、AutoLayoutやん」 と思いました。 そこで今回のセッションでは、ConstraintLayoutとAutoLayoutにおいて共通する考え方をお話した後、一方でどのような違いがあるのかを説明し、実際に同じ要件のレイアウトをConstraintLayoutとAutoLayoutで実装してみたいと思います。 ■アジェンダ 1. AutoLayoutとは 2. ConstraintLayoutとは 3. ConstraintLayoutとAutoLayoutの共通点 4. ConstraintLayoutとAutoLayoutの相違点 5. AutoLayoutでレイアウトを組んでみる 6. ConstraintLayoutで同じレイアウトを組んでみる 7. まとめ ■ ゴール ・AutoLayoutの考え方でConstraintLayoutを組めるようになる ・ConstraintLayoutの考え方でAutoLayoutを組めるようになる ・AutoLayoutとConstraintLayoutでそれぞれ嬉しいところ, 辛いところがわかるようになる
Intended Audience
・普段iOSをメインで書いているがAndroidも書くよという方 ・普段Androidをメインで書いているがiOSも書くよという方 ・iOSとAndroidにおけるUIの組み方の違いを知りたいデザイナーの方An Android App Bundle is a new upload format that includes all your app’s compiled code and resources, but defers APK generation and signing to Google Play. Google Play’s new app serving model, called Dynamic Delivery, then uses your app bundle to generate and serve optimized APKs for each user’s device configuration, so they download only the code and resources they need to run your app. You no longer have to build, sign, and manage multiple APKs to support different devices, and users get smaller, more optimized downloads. Additionally, you can add dynamic feature modules to your app project and include them in your app bundle. In this talk, we discuss how to configure your app to build app bundles and make the most out of Dynamic Delivery; use the Play Console to inspect and manage your app bundle; test your app bundle locally using bundletool and integrate these tests into your CI builds; and use the Play Core Library API to request, monitor, and manage on demand downloads. Additionally, find out what's next for Android App Bundles and support for Dynamic Delivery.
Intended Audience
All developers: optimize download sizes for your users (which improves UX, user retention, and number of downloads), and make managing app uploads and updates much much easier. Advanced developers: learn how to harness Dynamic Delivery to allow users to download certain features on-demand. Explore strategies and best practices to make the most of the technology and the PlayCore API.私が担当しているプロダクトにてLottieを使い開発を行いました。 その結果Android / iOSでスムーズにリッチなアニメーションを使い実装していくことができました。 ・Lottie導入で得ることができたメリット ・デメリット ・デザイナーさんとのやり取りで生じたこと ・導入事例 ・導入結果 上記の項目で話すことができたらと思います。
Intended Audience
Lottieをまだ使ったことがない方 エンジニアの力を借りずにリッチなアニメーションを導入したい方PWAはJava/Kotlinなどのネイティブアプリと対立するわけではなく、Webアプリの開発者をモバイル開発の土壌に上げるものとして非常に有用な仕組みであり、次世代のモバイルアプリケーションとしての答えの一つだと考えています。 PWAを知らない方に対しての簡単な説明をし、PWAの肝となるService Workerを実際に活用した"クライアントだけで動く"動画編集の体験を実現するための方法をご紹介します。
Intended Audience
* クロスプラットフォームに興味のある方 * PWAの技術に興味がある方 * PWAを知らない方 * Webの知識がある程度あるとより楽しめると思います!Builds can always be faster and more efficient. Whether you are a lone developer or a large team, a 10% build speed improvement adds up over the course of a project. And your time is important. If you're an Android Developer using Android Studio, you are already familiar with the Gradle build system and the Android plugin. In this talk, a member for the Android Studio team discusses tips, tricks, and strategies you can use to improve build speeds using Android Gradle plugin 3.3.0+. * Improve build speeds when supporting Android App Bundles * Incremental compilation while using annotation processors * Faster configuration with Lazy task configuration * Utilizing single-variant project sync * Understand classpath dependency synchronization * Variant-aware dependency management * Compilation avoidance via new dependency configurations * Sneak peek into future improvements of the plugin
Intended Audience
Intermediate developers on moderately-sized teams that want to improve build speeds.長く運用しているアプリは往々にして以下のような課題を抱えがちだ ・ソースコードを読んでも内容が理解できない ・テストコードが存在しない そのようなアプリを一念発起してリファクタリングしようとするケースは多いだろう。しかしその時、 ・どうすれば読みやすいコードになるんだろう ・どう手をつければ良いのだろう ・テストコードが無いからデグレするかも... という悩みが生まれる 今回の発表では個人の小さなアプリではあるが、 ・4年近く放置されててソースコードが(書いた本人ですら)理解できない ・テストコードが0 といった絶望的な状況から、 ・CleanArchitectureに則った可読性の高いコード ・99%Kotlin化 ・99%Testable(domain層のテストは100%カバー) へと生まれ変わった軌跡とそこで得た知見について発表する予定だ。 具体的には、 ・どこから手をつけていったか ・仕様ファーストでリファクタリング ・仕様からUseCase(Domain層)の作成 と言った内容を話す予定だ。特にCleanArchitectureで悩みがちなUsecaseをどう切り崩したか、について話そうと思う。
Intended Audience
・CleanArchitectureに興味がある人 ・CleanArchitectureを導入しようと考えている人 ・アプリのフルリプレースを考えてるけどどこから手をつけようか迷ってる人 ・CleanArchitectureのUseCase(Domain層)ってどういう粒度で考えればいいの?と悩んでる人You have been hearing about Kotlin/Native for a while, and aren't you yet sure about how to use it? Can you really use it to write multiplatform components? What about the web, and your backend? Join us in this excursion in the Kotlin/Native world, where you will learn about its advantages, disadvantages, state-of-the-art, and whether you can use it to develop your mobile applications properly.
Intended Audience
Android developers with Kotlin knowledge.A grid system is at core of any standard, objective design and yet most android applications (and mobile applications in general) fail to pick up on this. In this talk, I will talk about the grid system and why its so important for design in general and on android in particular. Talk structure - What is the grid? - Why is it so important for design? - Evolution of the grid - Grid in print design, on the web and elsewhere - The typographic grid - Grid on mobile and android - Material design guidelines - Material design keylines, metrics, typographic grid - Examples: With and without the grid - Key takeaways for android/mobile designers, best practice on android - Some tools to help with your design: keyline pushing, designer tools
Intended Audience
Intended audience - mobile designers: grid guidelines for android and the best practices/tools that can be employed - mobile developers: background on what the grid is and why its important? how to match designs given by the design team to the given design specifications - startups and businesses: what is the grid in design and why every app/platform should be designed with the grid in mind No specific prerequisite knowledge required.SpekはJetBrain社が開発しているUnit Testが書けるテストフレームワークです。RSpecというRubyのテストツールに記法が似ています。 JUnitに慣れているとはじめは特殊に感じるかもしれませんが、慣れると「このテストは何を確認したいのか?」がとてもわかりやすいのでおすすめです。 本セッションではまずSpekの利用方法をお話します。 後半は実例を交えながら、どのようなテストを書けばよいのか、ということや、開発の主流になってきているLiveDataやRoomを利用したクラスのUnit Testを作成する際にはまったポイントについてお伝えできればと思います。 ・Spekの紹介と利用方法 - Spekとは - given / on / it - Mockitoと組み合わせたテスト例 ・Room導入時のUnit Testの書き方 / はまったところ - Roomはコンテキストを利用しなければならないが、Unit Testを行うには? ・LiveData導入時のViewModel Unit Testの書き方 / はまったところ - LiveDataのライフサイクルとテスト
Intended Audience
・Unit Testを今年こそ書くぞと思っている方 ・もっと簡単にテスト書いてみたい方 ・Spekを知らないけど、今後利用してみたい方They say a perfect marriage is all about communication - that is why Firebase and Cloud Functions are such a perfect couple. Firebase is what we have convened into calling a Serverless Framework. You do not need to set up any infrastructure behind your app, you can connect it easily with Firebase and have access to a lot of functionality. In this session, we will showcase different examples of how the Cloud Functions can be used in conjunction with Firebase, and how this can improve the functionality of our sample app.
Intended Audience
Android/Mobile Developers. Having a basic understanding of Firebase will be helpful as well.As Android developers we are aware of fragmentation in the Android OS, but what about fragmentation in Continuous Integration for Android? There are many different platforms out there that we can use in our CI process. Each of them offers many different possibilities and set ups. In this session, we will have a walk around all the different possibilities we can have. You will discover new platforms, see new things you can do in your platform of choice and be a little bit wiser after attending.
Intended Audience
Android developers with interest in Continuous Integration, Development and Deployment皆さんのアプリをより毎日使ってもらえるようなアプリにするために、Android アプリがどのように起動されるのかを知っておく必要があると思います。このセッションでは Android アプリを起動する方法と、その使いどころについて説明します。 - ランチャーアイコン - ショートカット - 通知 - App Widget - App Shortcuts - Assist App and so on...
Intended Audience
Android アプリの起動数を増やしたいアプリ開発者BitriseやCircleCI, TravisCIなどに代表されるCIツール(継続的インテグレーション)の導入方法を解説した記事は多くありますが、実際に運用フローに組み込むところまで言及されていることは少ないと思います。 複数人のエンジニアが絡む中規模以上の開発においては、開発フローに一定のルールを設け、ブランチ運用とCIをうまく連携させて自動化しヒューマンエラーを減らすことが大事です。 3〜5人での開発体制の中規模アプリを2週に1度のペースでリリースを年単位で続けた自身の経験を元に、実運用に耐えうるブランチ運用とCIレシピから事故の少ないリリースフローまでをGitFlowとBitriseをベースに解説します。 また、Google Play Developer Publishing APIを活用して安定的なリリースを行うための手法や各プロダクトに合わせたカスタマイズ方法についても、実際の業務での運用を元に解説する予定です。 目次(予定) 1. 開発体制のルール化とマイルストーンの設定 2. GitFlowを用いたアプリ開発フロー 3. CIツールとブランチ運用の連携による作業自動化 4. Google Play Developer APIを活用した安定的なリリース手法
Intended Audience
- 複数人開発で開発フローに悩んでいる方 - 最近開発メンバーが増えてリリース運用の属人化脱却を考えている方 - 今のデプロイやリリースの作業が全て手動でなんとかしたい方 - CIを動かしただけで満足してしまって効果的に活用できてないと感じているそこのあなた!ここ数年、アプリ内の設計やアーキテクチャはよく注目され議論や改善が行われていますが、API設計も同様によく考えて設計するべきだと感じています。 WEBで使いやすいAPIとアプリで使いやすいAPIは大きく異なり、設計を間違えるとアプリ側で強引にデータの整合性を保たなくてはなりません。 簡単にリファクタリングできない要素だからこそ、一定のルールを持って取り組むべきです。 このセッションではAPIを実際に作るわけではないクライアントエンジニアとしてどのようにAPI設計に関わっていくべきなのか、 アプリの特性を詳しく知らないサーバーサイドエンジニアに対してアプリで使いやすいAPIのために何に注意して話をすればいいのか、伝えていくべきなのかを自身の経験を交えつつお話します。 目次(予定) 1. マスターデータとユーザーデータを分けて考える 2. アプリや言語の特性を考慮してモデル構築をする 3. サーバーサイドエンジニアへ伝えるべきポイント 4. Swaggerなどのスキーマ定義ツールの活用
Intended Audience
- いつのまにか決まったAPI設計をアプリで使って辛い思いをした経験がある方 - 今のAPIに不満はあるけど何をどう伝えれば解決するのか悩んでいる方 - API設計よくわからないからとサーバーサイドエンジニアに丸投げにしちゃっていた方Google I/O 2018でConstraintLayout2.0が発表されました。 その中で特にアニメーションにフォーカスした新しいレイアウトであるMotionLayout。 このMotionLayoutによってAndroidのアニメーションは 複雑なアニメーションを今までよりも簡潔に実装できるようになりました。 このセッションではそのMotionLayoutを解説していきます。 そこから - 既存のAndroidのアニメーションの実装とどう違うのか - 何が実現できるようになったか - MotionLayoutを使ってiOSアプリのようにユーザーの操作によってUIを動かすアニメーションを実現 をメインにiOSエンジニアの視点でお話ししたいと思います。
Intended Audience
- Android初心者 - UI・UXにこだわりを持つエンジニア - iOS・Android両端末を開発しているエンジニア、または開発したいエンジニアViews are one of the most primitive component in android development. But this primitive component has many things dependent on it such as performance of our apps. This talk will take deep dive to how android's view are drawn on screen. Tips to optimize view performance and best practices. The talk will be discussing following things: 1. View life cycle 2. Relationship with view group and its participation in life cycle. 3. How android draws view on screen 4. Common pitfalls when we are working with custom views. 5. Bad performance pattern which can easily occur eg. Over draw, double layout taxation 6. Best practice to make a custom view. 7. Tools to debug problems like frame drops 8. Tips to improve performance pattern.
Intended Audience
IntermediateConstraintLayout2.0.0から導入されたMotionLayoutの紹介をします。 MotionLayoutは始点と終点のConstraintを指定するだけで、クリックやスワイプに合わせたアニメーションを補間する新しいアニメーションライブラリです。既存の方法では出来なかった、もしくは難しかったアニメーションを簡単に実装することが出来ます。 セッションではMotionLayoutの実装方法の説明に続いて、実際にMotionLayoutを開発に導入する際に遭遇した困難を交えながらMotionLayoutの可能性と限界についてお話しします。
Intended Audience
- 基本的なConstraintLayoutの知識KoinはKotinを前提として作られた新しい軽量なDependency Injectionのライブラリです。DelegateなどのJavaにはない機能を使うことでよりわかりやすいDIを実現しており、Architecture ComponentなどのAndroid独自の機能もサポートしています。最近バージョン1.0.0がリリースされ、実際のプロジェクトへの導入もますます増えてきそうなライブラリです。 セッションではKoinの詳細な説明のあと、既存のAndroidアプリのDaggerによるDIをKoinで置き換える方法についてお話しします。 - Koinとは? - Koinの使い方 - Android Architecture ComponentとKoin - JavaとKotlinが共存するプロジェクトでのKoin - DaggerによるDIをKoinで置き換える 時間があればKoinの内部実装に関してもお話しします。
Intended Audience
- DaggerでのDIについて基本的な知識を持っている人# 概要 近年、Androidアプリはどんどん複雑化していますが、それと裏腹に、よりスピード感を持った開発が求められています。 しかし、そのような状況でもエンジニアとしてアプリの品質を落とすわけにはいきません。 本発表では、発表者が業務で行なっているTDDの知見を基に、テストとはなにか、そしてアプリの品質を高めより早くリリースするために如何に重要であるかを再確認し、また、エンジニアにとってどれだけメリットがあるかを熱く語ります。 そして実際のAndroid開発(MVVM)において効果的なテストを書くために何を考え、どのような意識をもつべきか、espressoを使ったUIテストとJUnitを使ったunitテストを例に話していきます。 本発表を聴き終わった後、きっと誰もがテストを書きたくなることでしょう。 # 発表のゴール * テストを書きたくなる * どうすればテストを書けるかわかる * 良いテストを書ける気がしてくる # 予定している内容 ## テストとは? * テストの四つの価値 * テスト makes happy ## TDDとは? * 開発の流れ * メリット・デメリット ## テストの種類と特徴 * unitテストーJUnit * UIテストーespresso * 中間のテストーRobolectric ## テストの書き方 * 基本知識 * unitテストーJUnit * UIテストーespresso * Tips:AssertJ * 粒度と数 ## テストのためのAndroidコード設計 * ロジックとUIの分離(MVVMを例に) * 依存の注入とmockの活用 * Tips:LiveDataのテスト * Tips:Daggar2が使えない時は ## まとめ
Intended Audience
・Android開発初心者〜中級者 ・テストに興味があるがいまいち良くわからない方 ・テスト駆動したいと思っている方 ・テストなど書かない方In this talk we will cover journey of APK when we hit run button of Android studio till the point when Launcher Activity onCreate method is called. Following is the outline of the talk: 1. Compilation of APK: Basic components of APK, how the APK zip archive is formed, compiling java to class file format and how this is changed to DEX, JVM vs DVM, zipping to APK format 2. Decoding runtime of Android: Comparing ART and Dalvik, different steps involved till installation of android app, how the modern AAB, split APK works during runtime and optimizes. Importance of optimizing bytecode. 3. Multidex: The point where app meets multidex, what happens under the hood during multidex and best practice to avoid common errors of multidex. 4. Starting of Android App and best practice to have minimum app start time: How the app starts from forking a zygote to the onCreate callback and how the start time can be badly affected if not taken care of. Best practice to have minimum start time of apps.
Intended Audience
Intermediate/Advanceアプリケーションが巨大になってくると、コンポーネント同士が密結合したり依存関係が複雑になりがちです。こうしたアプリケーションではテストが書きにくくなったり、特定のビルドだけ依存先のコンポーネントをカスタマイズするといったことが難しくなります。こうした問題を解決する設計パターンとして、依存性の注入(Dependency Injection: DI)というものがあります。依存性の注入とは、コンポーネントの依存関係をソースコードから排除し、外部に追い出してしまうソフトウェアパターンです。 本セッションでは、皆様が普段開発されているAndroidアプリにおいて、依存性の注入がどのように適用できるか、どういったメリットをもたらすかを解説します。また、現時点で最も利用されているDIコンテナであるDaggerと最近注目されつつあるKoinを比較しつつ、それぞれのDIコンテナでの実装についても紹介します。 アジェンダ(予定) ・依存性の注入(DI)とは? ・Androidアプリ開発におけるDI ・主なDIコンテナの紹介 ・Dagger / Google製の最もポピュラーなDIコンテナ ・Koin / 今注目のKotlinで実装されたDIコンテナ ・DI導入後のテストの書き方 ・単体テスト ・UIテスト
Intended Audience
以下のような課題を感じているAndroid初級者が対象です ・クラス間の複雑な依存関係や密結合に悩んでいる人 ・依存性の注入という単語は知っているがイマイチ理解しきれていない人 ・雰囲気でDaggerを使っている人昨年「開発者が知っておきたい通知の歴史」というセッションでAndroid 8 Oreoまでの通知の機能について振り返りました。しかし幸か不幸か、通知機能はまだまだ進化を続けます。案の定Android 9 Pieでもまたいくつかの通知に関する新機能が追加されました。 本セッションではAndroid 9 Pieで追加された通知の新機能について、機能の概要と実装方法を紹介していきます。 アジェンダ ・メッセージ体験の改善について(Smart Reply、画像の表示、Reply Draft、etc) ・通知チャンネルのAPI追加について(通知チャンネルグループのブロック機能、Do Not Disturb機能の強化について)
Intended Audience
・Android 9 Pieの通知機能について知りたい人ビジネスロジック、Domain層、UseCase。これらはMVVMやMVP、CleanArcitectureなど、3-Layeredアーキテクチャーではよく聞く単語だ。 しかし、いざ設計しようとすると 「つまり、ビジネスロジック/Domain/UseCaseって何?」 「レポジトリから取得したデータをそのまま渡すだけになるんだけど、これでいいの?」 などなど、首をひねりながら設計する人は多いのではないだろうか。かくいう私もその一人だった。 今回の発表では、CleanArchitectureにフォーカスし、「ビジネスロジック/Domain/UseCase is 何」という疑問を紐解いていこうと思う。 具体的には個人で開発しているアプリの「らくでん」の実装を元に、 ・ビジネスロジックってどういうものを指すのか ・Domain層(UseCase)をどのように設計していくか ・何をDomain層に入れるか/入れないか を話していく予定だ。
Intended Audience
・CleanArchitectureに興味がある人 ・CleanArchitectureを導入しようと考えている人 ・CleanArchitectureを使ってるけどUseCaseの設計が迷ってる/よく分からない人 ・ビジネスロジック、Domain層、Usecaseって単語は聞くけどつまり何?という疑問がある人Styling your Android app has always been a bit of a dark art. This talk will show you the patterns which allow you to conjure up your themes and styles, without going crazy when you come to update them in a few months time. The talk will cover some of the limitations of Android’s styling system, and the ways you can mitigate them.
Intended Audience
Prerequisite knowledge: The Android UI system, and basic styling Session Aims: To know the practices needed to maintain good themes and stylesMachine learning is becoming an important part of mobile development to help us provide a frictionless experience for our apps users. However at the same time it can be a pretty complex subject to tackle. Luckily for us though, Firebase MlKit is now available for us to ease this implementation into our apps. In this talk I want to introduce you to Firebase MlKit and how you can integrate it into your production apps. We'll look at how we can perform face recognition, image labelling, text recognition and several more commonly used mobile use cases. Firebase makes it so easy that you'll walk away with the confidence in being able to provide these experiences to your users in no time!
Intended Audience
BeginnerAndroid security is nowhere near where it should be. I have been able to hack and get sensitive information from a few different apps and I’m just an amateur hacker at best. Whether it’s because we are exposing information when making HTTP requests to our backend servers or because we’re simply storing things we shouldn’t in our apps, it’s easy to forget mobile devices aren’t as safe as we think they are. In this session, we will explore a number of ways an Android app can be exploited and most importantly methods that we can use to avoid these attacks. We will finish by looking at common techniques that will help you protect sensitive information within your application by adding tampering detection and making sure every external communication request is made securely.
Intended Audience
Any Android developer regardless of their level. I;ve given this talk before and always heard from Android developers they;ve learned a lotAndroid Things lets you build professional, mass-market products on a trusted platform without previous knowledge of embedded systems. It is estimated that by 2020 there will be 50 billion connected things. But what does it take to get started with Android Things and be able to say you’re truly working with the Internet of Things? How can you learn this platform and get ahead of the IoT revolution using your existing Android skills? In this session, we will explore what Android Things is and how you can get started building IoT applications with your existing Android knowledge. We will then build a real-life Android Things application using a Raspberry Pi 3 and Android Studio, the IDE you already use and love.
Intended Audience
Any developers interested din getting into Android Tings or IoT.LineageOSやResurrectionRemixなど色々とあるカスタムROMの紹介や、オリジナルカスタムROMの作成について説明します
Intended Audience
- カスタムROMについて少しでも興味がある人 - 組み込み系をやったことない人Even though Android is a mature platform by now, the adoption of Kotlin at Google I/O 2017 brought about a sweeping wave of freshness and enthusiasm amongst developers. Regardless of what the language and design patterns we use when writing an app, there is only one way to ensure correctness and quality: testing, static analysis and continuous integration. Many still think that setting up a CI for your project is hard, onerous, and not that useful, but we’re going to see how this is not true. Focusing on static analysis and unit testing, we’ll walk through setting up a continuous integration pipeline for a modern open source Android project using Gradle, CircleCI and Kotlin. We’ll see what benefits this brings to a codebase and how with a few tricks we can make sure external contributors adhere to the project code style, how we can prevent subtle bugs to sneak into the codebase, all with very little effort and zero budget.
Intended Audience
Android developers; there is no need for prior knowledge of the tools used, although it's good if the developers know about unit testing as I will not be covering that aspect much.In this session, we'll cover how elevation works on Android. From an overview of the available APIs, seeing what is new in Android P, and getting to the nitty gritty of how shadows are rendered on HWUI and Skia. Lastly, we'll learn how to take advantage of the existing APIs and work within their limitations to obtain original and unique results. This talk follows the track of existing blog article(s) on the topic: https://blog.usejournal.com/playing-with-elevation-in-android-91af4f3be596 and another upcoming article. There is also an open source app, Uplift, which will be used to showcase the effects as we talk about them: https://github.com/rock3r/uplift
Intended Audience
Android developers; there is no need for prior knowledge of the tools used, although it's good if the developers know about unit testing as I will not be covering that aspect much.Android Architecture Components / MVVMアーキテクチャのパワーは受託開発で生きるのか、死ぬのか。 クライアントの要望、仕様を、最速で実装に落とすことが優先されてしまう受託開発。 モダンなアーキテクチャ導入でのパフォーマンス向上。 それに対して、受託ビジネス特有のリソース不足、それに伴うソースコードの治安悪化。クリーンな設計を保つ難しさ。 ・ デメリットが多い受託開発目線での、モダンな設計の功罪。 ・ アプリ開発に携わる、営業ドリブンな受託開発会社への提言。 ・ 初学者の方に向けた、AACの活用・失敗例の共有。 上記を主目的とし、ここ一年で経験したニュースフィードアプリリニューアルでの事件簿/学びを共有できたらと思っています。 1. 外注側から見た、タスクボードスクラム/アジャイル開発体制のメリット・デメリット ・週次スプリントでのリリース高速化と、それに伴うGoogle Play Storeレビューのフレッシュさ ・iOS基準で考えられてしまいがちなスタートダッシュ ・どうしてもブラックボックス化して情報格差が生まれてしまう、「プロダクト・バックログ」 ・透明性、効率化の反面、両OSのベロシティ統制が取りづらい「スプリント・バックログ」 2. どうしても優先されてしまうスピードと、MVVMの実装コスト ・短納期に比例して増える、強引なビジネスロジック、CommonなUtil、複雑化したRepositoryパターン ・各画面からのMVVM設計導線の独立による、作業分担の透明化 ・複雑な制御をアプリ側に持たせる依頼と、MVVM実装コストの兼ね合い ・急遽の増員が増えがちな受託開発、スピードに応じて散らかっていくソースコード 3. Java / Kotlin 言語選択の壁 ・受託独特の、浅く広く広がる技術スタック ・レガシーなシステムを書き換えるに足る、学習コストとリソース ・モダンなアーキテクチャをJavaで実装する、時代への逆行 ・深まる属人化と、後進育成に踏み切れないリソース不足 ・モダンなライブラリを使用したい場合の、Kotlin導入の必然性・Javaへのサポートの減少 4. アプリとサーバーサイド、ピースフルな責任範囲を求めて ・理想は、アプリ内でデータはクリーンな設計の上を流れるだけ、そして、こちらの要求を全て叶えてくれるAPI ・ローカルデータはどこまで許容すべきか ・初動時のコンパクトでクリーンな設計と、サーバーサイド依存による属人化 ・人の入れ替わりごとにずれていくAPI設計と、それに応じたアプリ側で取り扱うEntityのねじれ 5. AAC(LiveData) ・レガシーニュースフィードアプリのリニューアル、LiveDataによる大幅なパフォーマンス向上 ・ライフサイクル同期による、突貫工事で頻発に起きていたメモリリークやクラッシュの減少 ・後方互換を主題とした、上流 / 外部API との連携の難しさ ・observeViewModelの乱用・不気味な更新挙動 6. AAC(Room) ・RoomとSharedPreferencesの採択 ・LiveDataと、SharedPreferencesによる大規模なキャッシュ。 ・使われていないRoom 7. DataBindingとUI ・BindingAdapterの活躍、スピーディなUI周りの仕様変更などの修正。 ・RecyclerViewとDataBindingライブラリの親和 ・ConstraintsLayoutでのレイアウト機種依存崩れの減少、パフォーマンス向上
Intended Audience
・ AACの活用・失敗例のインプットを目的とする、初学者の方 ・ アプリ開発に携わる、SES/受託開発会社に在籍する方 ・ 受託開発に携わり、クリーンな設計を武器に、レガシーなものと対峙せんとしている方 ・ コアとなる部分の設計、実装をパートナーに外注している方App performance is crucial for success of mobile applications yet it is difficult to measure without disrupting code quality, distracting effort and brainpower from the parts of code that actually matters. Solutions like New Relic help but are prohibitively expensive, especially for smaller teams. At Rakuten we built an app performance tracking SDK that automatically measures network and UI performance with 0 lines of code on the app side. The SDK weaves measurement statements into application's bytecode at compile time, so that you don't have to write that repetitive code. After internal release, several rounds of improvements and successful deployment to millions of users we open sourced the SDK last year. In this talk I will share how the sausage is made (hint: byte code weaving), the interesting details we encountered during development (e.g. that class verification at class load time differs on different android runtimes, or that RxJava has subclasses Runnable with implementing run() method, etc.) and finally how you can use it in your own application. The code is available at https://github.com/rakutentech/android-perftracking
Intended Audience
App developers that want to learn how to use professional performance tracking tools (without paying for NewRelic). Developers that want to understand how professional performance tracking tools function and how to use/change/extend bytecode weaving.Engineering is hard - but staying sane is even harder. Developer communities love to follow the hype - new programming languages, frameworks, libraries, architectures, tools... but in the reality of engineering high quality mobile applications picking the best new library is the least of our problems. Did you ever deal with… …a lack of motivation, boredom and depression? …an indifferent coworker? Or the one that always over-promises and under-delivers? Or the one in the remote office that seems to do nothing all day long? …not feeling valued? feeling powerless? …feeling insufficient? being scared to ask questions & look stupid? …the frustration at the end of a work day? …smoking/drinking/eating more than we would like? These questions effect everyone, but we rarely ever talk about them in the developer community. In this talk I will explore how we view our craft, work and life, how we can approach it on personal level and how good management can facilitate better work and life. After all work can create a lot of positive emotions as well 🙂. I hope to share my experiences & thoughts and get the conversation going in the community.
Intended Audience
People who * are open to exploring how our work impacts our emotions and mental health - and vice versa * are interested in basic psychology in the workplace * want to learn about practical mental models/coping mechanisms/approaches to dealing with the non-technical side of workAndroidアプリでは、「アプリ内アイテム」と「定期購入」の2種類の商品を扱うことができます。このうち定期購入は、ユーザー向けのコンテンツや機能に対して、月/年単位で課金できるものです。 定期購入ではアプリ内アイテム課金で考慮することに加え、購読期間や自動更新についてなども考慮する必要があります。 しかし、ゲームなどのアイテムに代表されるアプリ内アイテムの課金と比較して、定期購入が導入されているプロダクトは少なく、参考にできる情報は多くありませんでした。 そこで、このセッションでは、2016年にプロダクトに定期購入を導入して現在まで運用した経験から、定期購読のアプリへの組み込み方や注意点などをお伝えします。 Topics: ・導入方法 ・In-app Billing Version 3 API ・Google Play Billing Library ・サーバーサイドとの連携 ・デベロッパーペイロードについて ・テストの方法 ・ストア公開時の注意点 ・自動更新について ・定期購入の乗り換え
Intended Audience
・アプリ課金について知りたい方 ・アプリに定期購入を導入したいと考えている方“This is my invariable advice to people: Learn how to cook- try new recipes, learn from your mistakes, be fearless, and above all have fun!” - Julia Child. The first lessons of an apprentice cook typically focus on identifying quality. Reinforced by repetitive acts, which helps understand the product and the method. This training only focuses on the detail rather than the bigger picture. With these new skills a cook learns how to adapt. Once they have a strong grasp of the fundamentals cooks are less fearful of experimentation. After they’ve gained confidence in their ability to adapt, improvisation teaches them how to act based on their intuition. Finally, when they have enough technical skill, a chef’s creativity finally enters the picture. A dish is simply the expression of a personal challenge, filtered through the whole of a cook’s experience and knowledge. Adapt, try new things, overcome and learn from your mistakes, repeat. How well do you think you'd cope if you had to be a professional chef for a day? What if we replace “cooks/chefs” with “Android developers” in the previous text? The software we create is the expression of our knowledge, of what we’ve learned, and our own experiences. The path of becoming a senior Android developer can be very similar to the one cooks take to become chefs. I want to learn from chefs and their journeys and apply it to our own craftsmanship. I want attendees to learn what it takes to become a good Android developer, what it means to be senior developer, and finally how to lead a team successfully.
Intended Audience
Every level, it is about personal development and career growth that can be applied at any level (junior to senior)The stereotype of the lonely developer working by themselves, without communicating with anyone is a myth. We work in teams. We work with people: other developers, or designers, product managers, project managers. Other people. We underestimate the work it takes to build a good team. A team that functions and is productive, a team that solves problems, a team that knows how to communicate, and that completes tasks. We even underestimate how many skills each person has to learn to make the team function. Hell’s Kitchen is a reality cooking show in which two teams compete on every episode. Once you’ve watched a few of them you can start predicting which one will be the losing team because of the mistakes they make, because you’ve seen the same types of mistakes before. But these mistakes are not isolated to cooks and chefs, we can see them in our own teams frequently. With this talk I will investigate what constitutes a good team, what skills are needed and what the most common mistakes are that make teams fail. And I want to do all of this using Hell’s Kitchen as an example of good or bad teams. Attendees will walk away knowing what actions and skills they will need to work on to make their team better.
Intended Audience
All levels. This talk is about team building and dynamics.This talk will give you the tools to prepare for interviews, whether it’s making your hiring process better, or simply preparing for an interview as a candidate. As a candidate, interviewing for a new job can be quite stressful and time consuming. It feels like you are being put through an exam. Often, we forget we are also evaluating the company we are interviewing with, especially when we start interviewing for the first time, and it is hard to know what to look for. On the other hand, interviewing candidates for a position can be stressful too. You want to find the perfect person to join your team, but there are many factors that feel out of our hands (e.g. rain can affect the mood of the candidate and the person interviewing and impact the result). We need to effectively control the factors that we can. With this talk we want to focus on the whole process of finding the right people to work with, from the job advert to the offer. And we want to do it from both points of view, as the company and as the candidate. We want to show candidates behind the scenes of the interviewing process, to make it feel less intimidating. We want to teach them how to choose a job and a company that fits with them. We want to give some tips on how to prepare for interviews, and the sort of exercises they might encounter. We also want to help companies improve their hiring process. There is no solution that works for everyone, but there are patterns everyone can follow to do better. We want to show them how to reach candidates, make sure qualified candidates apply, show them how to deal with the unavoidable biases they will face, help them understand the pros and cons of different types of exercises, and finally, help them find the perfect new hire for their team. Hiring and interviewing is not easy, and there is no easy solution to it. But we hope that with this talk we would make it a little bit better for everyone involved.
Intended Audience
Everyone.In general, android application projects require us to take care of much many stuff. How do you check the apk size, implied feature changes and permission changes? How about design assets, license files and proguard rules? Do you run any static analysis? How to see it? Are you handling these matter manually? Didn't you fail to handle them? Perhaps, do you ignore some of the stuff...? For example, it would be dangerous if new apk contained new permissions but you couldn't notice it, right? You should be aware of them but it would make you work harder. We are engineers so we should go with lazy methods. In this talk, I will explain - What can be semi- and/or fully- automated - How to automated stuff like - Introduce Danger - Report differences between two apk files - Import design assets to vector drawables or png files - License files - Proguard rules - Report results of static analysis these are just examples so the actual items would depend on the presentation-time. このセッションは英語でやりますが、発表者自身もそんなに英語が得意なわけではないので簡単な英語で構成したり、日本語の補助資料を用意するつもりです。 以下、概要訳。 一般に Android アプリプロジェクトに関わる上、気にしないといけないことは数多くあります。 apk サイズの変化や feature, permission 増減 デザインアセットの管理、ライセンスファイル、Proguardルール 静的解析の実行やその結果の見方 これらは一例ですが、こういった管理を手動でやっていたりしませんか?漏れたりしたことはありませんか? もしかして無視したりしてませんか? 例えば apk が新しい permission を要求することに気付かず、そのままリリースしてしまうのは非常に危険です。 そういったことを気を払うべきですが、気を払いすぎるとタスク過多になってしまうかもしれません。 僕らはエンジニアですから、 Lazy な手法でこれらを解決していきましょう。 このセッションでは - 何を半あるいは全自動化できるのか - どうやって自動化していくのか (プレゼン時間次第ですが、以下の内容を予定しています) - Danger の導入 - apk の差分とそのレポート - デザインアセットの vector drawable / png でのインポート - ライセンスファイル - Proguard ルール - 静的解析結果のレポート
Intended Audience
People who ・Don't know what you should start automating from ・Don't know how to automate material management ・Wanna be lazy :) 想定する人 ・どこから自動化を始めればいいのか分からない人 ・マテリアル管理の自動化の仕方が分からない人 ・怠惰でいたい人【概要】 マテリアルデザインの根底にある哲学とそこに至る背景を整理考察した内容を発表します。 「デザイン哲学=そのデザインを作成した人の哲学」という視点から、マテリアルデザインの本質を紐解いていきます。 【背景】 マテリアルデザインが2014に発表されてから、多くの開発者やデザイナーはGoogleが提供するマテリアルデザインガイドラインを参照して開発を行ってきました。 マテリアルデザインガイドラインにはルールの記載はあるが、ルールにいたった理由や背景が記載されていません。 理由や背景がないために、企画・開発・デザイン間でガイドラインにどこまで従うべきかの判断が難しい状況が度々起こるかと思います。 そもそも作った人はどういった意図でこのガイドラインに落として行ったのかを考察することで、議論の有効な論点の一助となればと思います。
Intended Audience
マテリアルデザインに興味がある方であればどなたでも【概要】 ユーザーとしては同じに見えたほうがわかりやすくとも、データとして同じものとして扱うわけにはいかない!ダメ。絶対! そんな状況を、ほぼ同じものを2つ作る冗長案でもなく仕様をがんじがらめにする縛り案でもなくStrategyパターンで柔軟かつ無駄なく解決していったという話をします。 【背景】 ユーザーにとって理解しやすいプロダクトを作ろうとすると、次のような要求が出てくることが多々あると思います。 - 細かい概念差分があり同じデータとして扱うことができない。 - でもユーザーからすればなんら変わらないデータに見える。 - 仕様的には "ほぼ" 一緒。 その時に上がりやすい解決方法は「完全に別物として作ってしまう。」or 「同じものとして作って仕様をがんじがらめにする。」になってくると思います。 この選択のために企画と開発者が来る日も来る日も将来起こりうる仕様変更について議論する日々が続く。 そんな状況を打開するヒントとなればと思います。
Intended Audience
クライアントエンジニア最近のモバイルアプリ開発の技術選定において一つの選択肢になりつつあると思います。そのFlutterを使ってアプリをリリースをした過程で得られた知見について話します。 ・これまでのAndroidアプリ開発との違いはなにか ・Flutter独特のつまづきやすいポイントはどこなのか ・テストコード、CI、Push、などアプリ開発においてのありがちな技術について ・Firebaseとの親和性について 普段Androidアプリを開発しているのでAndroidエンジニアから見たFlutterはどう違うのか、逆に似ているところはどこなのかという視点でお話しします。
Intended Audience
・普段Android開発を業務で行なっている方 ・Flutterを個人で触っている方 ・Flutterの採用を検討されている方 ・Flutterを業務で使っている/ 使ったことのある/ 使う予定がある方Google Assistant や Amazon Alexa といった音声アシスタントシステムが登場し、様々な場面で日常に入り込んで来ています。 しかし、音声をベースとしたサービスやプロダクトはまだまだ試行錯誤の段階であり、 Webやネイティブアプリ以上にプロトタイプの作成や改善の繰り返しが重要です。 本セッションではそのような開発の流れに耐えうる Google Assistant アプリをちゃんと作成できるように、 リリース前にユーザーにテストをしてもらう方法や、開発環境と本番環境の切り分け、 CLIベースでのテストが行える構成について実際の運用での知見を交えて紹介します。
Intended Audience
・Google Assistant アプリを開発・運用していきたい方 ・スマートスピーカー関係の案件が降ってきそうで慌てている方coroutinesはKotlinの最新バージョンである1.3で標準となった非同期処理のための機構です。 現在のAndroidアプリ開発において、非同期処理といえばRxJavaがデファクトスタンダードです。 しかしながら、RxJavaは本来リアクティブプログラミング(RP)をするためのフレームワークであり、非同期処理はその一面に過ぎません。 そのため、RxJavaの非同期処理はRPを必要としない人にとっては過度に多機能で複雑なものになってしまっています。 一方、coroutinesは非同期処理の複雑さを解決することを主眼に置いています。 コールバック地獄や複雑なメソッドチェーンを必要とせず、普段書いている同期処理とほとんど同じように簡単に記述することができます。 本セッションでは、そんなcoroutinesについて、以下の内容をお話しします。 - coroutinesのコンセプトと使い方 - Androidアプリ開発での利用方法 - RxJavaを使った非同期処理との比較と、coroutinesへの段階的移行について - Android Architecture Componentsを利用したMVVMアーキテクチャでの活用方法 本セッションを聴講することで、coroutinesを使った非同期処理を実際のプロダクトに導入するために必要な知識を得ることが出来ます。 coroutinesの登場によって、Androidアプリ開発において非同期処理が複雑だった時代は過去のものとなりました。 本セッションが皆さんが次の時代へと進む一助になれば幸いです。
Intended Audience
・Androidアプリの非同期処理を簡潔に書きたい方 ・coroutinesに興味がある方 ・Androidアプリ開発におけるcoroutinesのベストプラクティスを知りたい方 ・RxJavaを採用しているが、ObservableやFlowableを使っていない方 ・Kotlinの基礎的な文法を理解されている方(セッション中に紹介するコードは全てKotlinとなるため)弊社のアプリケーションでは、サーバーサイドで発生したイベントによってユーザー状態が変更されることがあり、その変更に合わせてクライアインサイドのがめんを強制的に遷移させる必要があります。 その要求の実現のためにSingle ActivityでFragment Transactionでの画面遷移管理をするClearnArchitecture + Reduxの構成を採用しました。 そこでの試みとして、通常のデータの変更だけでなく画面遷移やエラー等もすべてアクションとしてReduxのシングルトンを通してフロー整理する構成にしました。一年ほど開発を続けてきており、それなりに見通しよく柔軟なアーキテクチャになったと感じていますので、一つのアプリケーション設計の参考例としてご紹介いたします。
Intended Audience
Single ActivityのAndroidアプリケーション実装のアーキテクチャに悩んでいる方 サーバーのデータに合わせて画面遷移が強制的に必要になるようなアプリケーションの設計に悩んでいる方AndroidでMIDIのアプリケーションやサービスを作るのはどれくらい現実的なのか? Androidのオーディオ/MIDIアプリケーションには常にパフォーマンスの問題がついてまわり、またコンピューティングリソースも限られています。 それらの問題に、アプリケーション開発者も、GoogleのAndroidフレームワーク開発者も、さまざまな改善を試みてきました。それでもこの分野はまだiOSに追いついているとは言えない状況です。 このセッションでは、講師(atsushieno)のMIDIデバイスサービス開発経験をもとに、オーディオおよびMIDIに関連するAndroidのJavaおよびネイティブ(NDK)のAPIを紹介しながら、それらが直面する問題や解決方法、今後何を改善しうるのかを、模索し議論していきます。 android.media.midi API、Oboe(やOpenSLESやAAudio)が主な話題ですが、Androidの外の世界にも目を向け、さまざまな開発環境の選択肢にも目を向けた内容にする予定です。 参考リンク: - https://source.android.com/devices/audio/latency/latency - https://github.com/google/Oboe - https://www.utdallas.edu/~cxl137330/courses/spring14/AdvRTS/protected/slides/45.pdf - https://techbooster.booth.pm/items/126263
Intended Audience
Androidのオーディオ・サウンド関連APIの、やや低レベルな部分に興味のあるアプリケーション開発者。Android SDKやNDKの使い方は解説しません。Google I/O 2018でMotionLayoutが登場され開発者はより簡単にアニメーションを表現できるでしょう しかしながら、Androidにはアニメーションを表現するためのAPIが数多く存在します 求められている動きや表現に応じて最適な選択をするためにはそれぞれの特徴を理解した上で選択しなければなりません そこで本発表では、アニメーションを表現する上でどのような選択肢があるのか特徴や使い所などを整理し説明します
Intended Audience
- Android開発初心者〜中級者 - アニメーションをあまり実装したことがない方 - アニメーション周りの全体像が知りたい方現在自社(https://pay.co.jp/ )で新規開発しているReactNativeアプリケーションでハマった箇所、ツラかった箇所を共有します。 プロジェクト構成としてはReact Nativeを触るのがAndroid/iOSのアプリエンジニア4名で、フロントエンジニア0名から中規模(画面数50程度)のアプリを開発、ReactNativeを業務で触るのは全員が初めての状況から起こった諸々についてです。 Flutterが話題をかっさらっていく昨今ですが、まだまだReactNativeも負けていないと弊社では考えています。企業的にはスタートアップに近い状況からどうやってこのアプリがリリースしたかを語りたい所存です。 以前の発表でやろうと思って時間と主題の遠さから断念した内容でもあります(スライド https://www.slideshare.net/NatsukiYamanaka/20180911payreact-native-api/41 の先)
Intended Audience
特にReactNative等クロスプラットフォーム技術に興味がある、導入を検討しているネイティブエンジニア。もしくは環境構築やプラットフォーム固有のバグに嫌気がさしているエンジニア。快適なAndroidアプリをユーザーに提供しようと思うと、避けて通れないのが + クラッシュフリー + ANRフリー + 高い描画パフォーマンス + 短い起動速度 等の非機能要件です。現在のGoogle Play Consoleでは、Android Vitalsというこれらの各種パフォーマンス指標をウォッチし、改善の役に立てることができる情報を見ることができる機能が提供されています。 本発表ではAndroid Vitalsを知らない方、知っているが何となく触れずに来た方、見ているが実際にどう活用するべきかわからない方などに向けて、Android Vitalsをどう見るか、どう活用していくかという話をします。起動速度や描画速度の改善を目的とした際に、Android Studioのパフォーマンスプロファイリングの機能を活用する方法、あるいはGoogle Play Consoleの自動テストを活用して致命的なクラッシュ問題を避ける方法など、Android Vitalsに限らずAndroidアプリのパフォーマンス改善に役立つ方法についても実践内容を交えてお話ししますので、そちらに興味がある方にもおすすめです。
Intended Audience
+ Android Vitalsを知らない方 + Android Vitalsを知っているが何となく触れずに来た方 + Android Vitalsを見ているが実際にどう活用するべきかわからない方 + Android Studioのパフォーマンスプロファイリング機能を有効に活用する方法を知りたい方 前提知識 Androidアプリ開発についての基本的な知識無限スクロールViewPager、それは全てのAndroidアプリエンジニアの夢といっても過言ではないと思います。過去様々な実装がWeb上で共有されたり、無限スクロールViewPager用のライブラリはいくつも世の中に存在しており、実際皆さんも一度は実装したり、実装にチャレンジしたりしたのではないでしょうか。例えば単純にとても大きなサイズのViewPagerを作るところまでは出来ても、コンパクトな実装で作ろうとしたとたんにFragmentの挙動に悩まされたりした経験などあるはずです。実際、コンパクトで不具合のない無限スクロールViewPagerを実装するためにはFragment、FragmentManagerについての深い理解が必要ですが、なかなかそこについての詳細な説明は手に入りにくいのが実情です。 本発表では、本物の無限スクロールViewPager(単にとても大きい数字をgetCountで返すのではない)の実装を通して、Fragmentの適切なState管理についてのベストプラクティスを解説します。 ## 発表内容の抜粋 + デフォルトのFragmentPagerAdapterの実装解説 + デフォルトのFragmentPagerAdapterの実装上の問題 + Tagを使ってFragmentを適切に管理する + "同じFragment"がViewPager内に存在することで発生する問題 + FragmentのStateを複製し、Fragmentのコピーを生成する + (おまけ)Scrollerを使って無限TabLayoutを実装する
Intended Audience
+ Fragment管理について突っ込んだ情報が知りたい方 + ViewPagerの無限スクロールを実装したことがある方、実装に興味がある方受託開発が主な弊社で、Android開発を主に行っている自分がFlutterアプリを業務で開発した際に得たtipsを共有します。 ・StreamBuilderのdataが消えている・・。 ・え、iOSってそうなんだ ・Shift_JIS? ・ホットリロード ・デザインパターン ・WebViewつらい
Intended Audience
Flutterに興味のある人Streaming再生やExoPlayerができること、またその内部実装についてお話します。 ExoPlayerは活発に開発が行われています。ExoPlayerが去年から今年にかけてどのような変化があったかについてもお話します。 動画再生は様々なStreamingProtocol, file形式, 暗号技術がある中で個人で学ぶにはハードルが高いものとなっています。業務においても大規模に配信された動画の再生にも携わっているため、その中で得られたtipsなども一緒に話していけたらと思っています。 トピック ・Streaming再生とは (HLS, MPEG-DASH) ・Download再生 ・DRM ・ErrorHandling, AudioFocus、字幕 ・ExoPlayer Extensions (Cronet, ffmpegなど) ・この一年間でのアップデート
Intended Audience
Streaming再生やExoPlayerの活用方法や内部実装に興味がある人本セッションでは、Googleがオープンソースで開発している機械学習フレームワーク「TensorFlow」を使って、Androidアプリ向けの機械学習モデルを作成して、動作させる上で筆者が得た知見と課題を共有します。 まず始めに、TensorFlowを中心とした、Androidアプリ開発と機械学習(Machine Learning)について概観します。 次に、TensorFlowモデルをAndroidアプリに組み込む形式として、TensorFlow Mobile、TensorFlow LiteならびにTensorFlow Liteの量子化モデルについて解説します。 最後に、それらのモデルを実際にAndroidアプリに組み込んだ経験から、それぞれの利点と欠点、そして課題を共有します。
Intended Audience
Androidアプリに機械学習モデルを組み込むことを検討しているAndroidアプリ開発者。 機械学習モデルを組み込んだアプリの開発を予定しているAndroidアプリ開発者。Androidに限らずアプリケーションの開発において、設計・アーキテクチャの課題は常々付きまとうものです。 MVP / MVVM / MVI / Clean Architectureなど、今回のDroidKaigiにおいても多くの登壇者が設計に関する知見を共有してくださることと思います。 しかし、Androidの初学者、あるいは既にレガシーなコードを抱える開発者にとって、モダンな設計というのはどうにも取っつきにくい領域です。 公式のドキュメントであるAndroid Developersには「Guide to app architecture」というページがあります。 このページでは、Architecture Componentsを用いたテスタビリティと構成の変更(Activity / Fragmentの再生成)への強さを兼ね備えた設計について細やかな解説がされています。 https://developer.android.com/jetpack/docs/guide 本セッションでは実際に「Guide to app architecture」を参考にして既存アプリの改良を進めた経験を基に、以下のようなお話をさせていただく予定です。 ・「Guide to app architecture」で解説されている設計の概要と要点 ・既存アプリの設計改良において留意したポイント ・既存アプリの特徴、開発体制に合わせた設計のアレンジ ・実際に既存アプリに取り入れた設計とその効果
Intended Audience
・既存アプリの設計改良についてどこから着手していいか悩んでいる方 ・プロダクトの成熟フェーズへの変化の中で既存アプリの設計改良を検討している方 ・MVP / MVVMなどのレイヤー化された設計に興味を持ちつつも取っ掛かりが掴めない方ソフトウェアにおいてのチーム開発には秩序が必要です。 個人開発ならばやりたいようにやればいいですが、チーム開発ではそうはいきません。 育った環境、キャリアパス、スキルレベルや技術に対する方針も異なる人々と同じソースコードをいじりながら、一つのプロダクトを作っていく必要があります。 そのためには、秩序が必要です。秩序は、デジタル大辞泉では次のように説明されています。 『ちつ‐じょ【秩序】。その社会・集団などが、望ましい状態を保つための順序やきまり。』 (デジタル大辞泉) 秩序があることで、レベル感の違うエンジニアが複数いても、ある程度無駄を省いた開発をしながら、ある程度の品質を維持することが可能になります。 当セッションでは、秩序のある状態とない状態を比べて秩序のある開発が有効であることを説明し、 秩序のほとんどを開発初期に決めることができることを説いて、実際にどのようなルールや仕組みを設けるといいのかを紹介していきます。 ほとんどの現場で、紹介する多くの例がすでに取り入れられると思いますが、改めて洗い出した上で最後にはチェックリストにして紹介します。 - 無秩序なチーム開発 - 秩序のあるチーム開発 - 開発初期および事前に決めることができる秩序 - 方針を決める - テスト方針を決める - 設計方針を決める - コーディング規約を決める - 事前にツールを入れておく - lintを入れる - Dangerを入れる - CIの設定をする - DeployGateの設定をする - テンプレートを作っておく - プルリクテンプレート - イシューテンプレート - コミットメッセージテンプレート - 毎回作るものは、ライブラリやサンプルを作っておく - 強制アップデート - トラッキング - 認証 - APIとのつなぎ方も用意しておく - swaggerを使った方法 - 開発初期の秩序チェックリスト
Intended Audience
- リードエンジニアの方 - 秩序だった開発がしたい方 - これから新しいプロジェクトを立ち上げる方If you've been an Android developer for any length of time, sooner or later you will have encountered adb -- the Android Debug Bridge. Part of the Android SDK, it is most commonly used to view the logs continuously being emitted within a device (via adb lolcat) or to run commands directly on device via a shell. But it is, as its name suggests and as you might already know, also a bridge to a variety of other functionality and information. Have you ever wondered how adb does its magic? Or what _actually_ happens when you type in `adb shell`? In this session, we'll dive right into the deep end and take a peek under the hood to understand how every Android developer's favorite tool works.
Intended Audience
Intermediate Android developers would derive the most from this. Audience should have a working knowledge of the Android SDK tools, and have ideally viewed device logs indirectly or via the adb tool itself. Anyone curious about adb's functionality and/or puzzled by some of the tool's behavior will find this session useful.私が現在開発をしているAndroidアプリ「家族アルバム みてね」では、画像を高速に閲覧するための工夫を随所に入れています。WorkManagerを使ったバックグラウンドでの画像の事前キャッシュ機能もそのひとつです。 このセッションでは、画像の事前キャッシュ機能を開発するに至った経緯を共有したうえで、WorkManagerの実践的な利用方法や実装・テスト手法や実装上の苦労した点などを知っていただければと思います。 ◼️予定しているアジェンダ ・画像表示速度に関する課題について 「みてね」のAndroidアプリでは、特に海外ユーザーに対してより快適にアルバムを閲覧してもらうために画像の表示を高速化しなくてはいけない課題を抱えていました。セッションではより詳細に課題のポイントを説明します。 ・WorkManagerの利用に到るまでの経緯 課題を解決するために、最終的にAndroidアプリ側でバックグラウンドで画像を事前にキャッシュする手法を選択し、その実装のためにAndroid Jetpackに含まれるWorkManagerを利用することにしました。 ・WorkManagerによる機能実装について WorkManagerは「ネットワークなどの端末リソースの状態を検知する」「定期実行する」「ユニークなジョブ実行を保証する」などバックグラウンドで処理を実行する際に気をつけたいことがAPI自体にすでに備わっているため、それらの複雑な条件はAPIに任せて実装したい処理に自体に集中することができます。 ここでは、Workerを実装する際に重要な以下の点についてを話したいと思います。 ・冪等性を担保した処理の実装 ・テストの書き方について ・タイムアウトなどWorkManager自体の制約について ・その他 ・機能を実装した結果得られた効果とさらなる課題 WorkManagerによって効率的に画像を事前キャッシュすることで得られたユーザー体験の向上をデモンストレーションによって体験していただければと考えています。また、残されている課題についてもご紹介できればと思います。
Intended Audience
・Androidアプリで画像表示速度についての課題を抱えている方 ・WorkManagerを用いた実際の課題解決のサンプルを知りたい方 ・Androidアプリのバックグラウンド処理実装に興味のある方ChromeOSでは、Androidのアプリを動かすことができ、beta版ではありますが、LinuxをChromebook上で起動することができるため、Android Studioを使用した開発から実機での確認までが端末上で完結する開発環境となります。 そんな今後Androidの開発環境として魅力的なChromebookでのAndroid開発環境の構築と、キーボードや画面サイズ変更などが頻繁にあるラップトップAndroidアプリ開発における注意するポイントなどを発表したいと思います。
Intended Audience
ChromeOSに興味がある人、ラップトップ向け、キーボードありなどのタブレットなど、スマホとは違う環境向けのAndroidアプリ開発に興味のある人This talk focuses on leveraging gradle for running tests, filtering tests, creating test reports and artifacts (e.g. coverage reports) , test setup for multi module apps, instant apps and multi platform projects in Kotlin. The second part of this talk will focus on using Firebase TestLab and the various options available to perform cloud testing effectively including scaling large number of automated UI tests.
Intended Audience
Android Engineers interested in generating code coverage for instrumentation tests and unit tests, using gradle for android builds, writing unit and instrumentation tests, interested in cloud testing and test sharding across cloud devices.PHPでゲームボーイエミュレータを見る連載がある雑誌に載っていました。ゲームボーイはシンプルな構造で、コンピュータアーキテクチャを理解するために非常に良い題材です。 本セッションでは、CPUやメモリなどのコンピュータアーキテクチャの基礎的な話と、Kotlinでエミュレータを実装する話をさせて頂きます。 もしかしたらコンピュータアーキテクチャをあまり知らないというエンジニアの方もいらっしゃるかもしれません。このセッションで学びへの第一歩を踏み出して頂ければ幸いです。
Intended Audience
・コンピュータアーキテクチャを学んでみたい方 ・コンピュータアーキテクチャの基礎は知ってるものの、実際にどういうものか腑に落ちていない方 ・エミュレータ実装に興味がある方 ・他の言語でゲームボーイエミュレータを実装されたことがある方Roomは、SQLiteをオブジェクトのマッピングを行うと同時に、LiveDataやRxJavaのFlowableでデータ変更時に通知を受け取ることもでき、DBへのアクセスを飛躍的に簡単にする便利なライブラリです。 しかし既存のSQLiteOpenHelperを使ったアプリをRoomに移行しようと思っても、その移行方法がわからずに諦めている方も多いと思います。 実はシンプルなテーブルしか持たないDBの場合には、適切なEntityの作成と空のmigrationの作成だけで移行ができますが、複雑なテーブルの場合には一手間必要です。 本セッションでは、Roomがtableを管理する仕組みを紐解きながら、以下の説明を行います。 ・複雑なtableを使っている場合の移行方法 ・SQLiteOpenHelperを残しながら、一部だけRoom化する方法 ・既存のtableに合わせたEntityのソースを自動生成する方法
Intended Audience
Roomの便利さに魅了されながらも、既存のアプリのRoom化の方法がわからずに諦めている方。NDKを使って高パフォーマンスなアプリケーションを作成する手法、チップス、APIなどを紹介します。 昨年の同様のセッションに引き続き、 NDKの更新情報、ツール、パフォーマンスチューニングなど、Androidでのパフォーマンスを追求する際に必要となる情報をお届けします。 ・C++を使ったAndroidプログラミング ・Android電話向けパフォーマンスチューニング手法 ・systrace, simpleperf等紹介 ・CPU governor挙動について
Intended Audience
パフォーマンスを愛する全てのエンジニアに- PWAの登場により、WebのNativeアプリ化ができるようになった - Cordova / Capacitorを使うことで、Google Playからも配信可能 - CapacitorのNative UI Shellを使うことで、Native APIとWebの併用もできる - Webとアプリの境目がなくなってきてる今だからこそできることをやろう!
Intended Audience
- 小さく検証しながらアプリリリースをしたい - アプリ開発のエンジニア不足だけど、Web制作者はいる - これからAndroidアプリをつくりたいAs engineers we rely on open source software all the time - even Android itself is open source! Imaging (or rememeber) how difficult it would be to write modern applications without Retrofit, lottie, RxJava, JUnit etc. But closed source development is still the default approach in most engineering orginzations. At Rakuten we have started developing our libraries as Open Source Software and see many immediate benefits: * Developer efficiency: State of the art SCM, CI/CD, Code coverage etc. tooling for free * Developer happiness: Better tools make developer's life better - but more importantly contributing to the open source community is just really satisfying * Recognition: Both individuals and organization get fame for their contributions to open source, exhibit A: Jake Wharton and Square Inc. There are more benefits, but you get the idea. In this talk I will share my experience as Open Source Software advocate/evangelist it Rakuten's tech division. I will dispel some common myths about open source development, explain how to convince non technical stakeholders that OSS is great, how to establish a process for OSS in an organization and how to evangelize for more open source development within the company. After this talk the audience will be able to bring OSS development to their own organization and understand how to develop in the open without disclosing secrets (passwords, user data, access keys etc.).
Intended Audience
People who * want to understand the benefits of developing products/services as open source software * want to know how to setup/manage an OSS process in an organization * want to be OSS advocates/evangelists (i.e. someone who drives open source development in an organization)このセッションは約6年間仕事とは別にプライベートでアプリを開発し続けてきた私が - プライベートアプリを始めるコツ、続けるコツ (しかも楽しく!) - 仕事のスキルアップへの還元のコツ (せっかくなので仕事にも役立てたい!) - 技術的な目線から最近やってみてよかったこと をお話していきます。 プライベートでAndroidアプリを開発していくTips集です。 我々アプリ開発者にとってプライベートで自らアプリを持つ意義の一つは「アプリ開発の一通りのプロセスに関して、何でも自由に挑戦できるplaygroundを持つことができること」ではないでしょうか。Meetupや同僚から得たノウハウは、自ら真似てみるのが効率の良い学習方法です。私はDroidKaigiで得た情報を、数ヶ月かけて自分のplaygroundで試すことを毎年楽しみに取り組んでいます。 このセッションでは、そんなplaygroundを手に入れるまでのちょっとしたコツ、メンテナンスしていくコツをまず紹介します。そして最近の「プライベートアプリを持っててよかった」というエピソードを、最近のトレンドを交えてお話ししていきますので、それが皆さんのモチベーション維持のヒントとなり、持って帰って頂ければ嬉しいです。 ターゲットは「これからプライベートアプリを始めてみようかな?」もしくは「昔作ったものを壊して作り変えようかな?」と考えている皆さんです。そんなみなさんを少しでも後押しすることを目標とします。昨今のAndroid界隈の最新事情を踏まえながらお話しますので、これからAndroidを始めたい人にも楽しんで頂ければと思っています。 ★ 紹介するTips (予定) アイデアを見つけるちょっとしたコツ / 友達とではなくて一人で取り組む / 最初の頑張りどころ / 変にこだわらず気軽に壊す / 壊しやすいけど完全に壊れないようにbranch strategyを考えよう / signatureを無くすとモチベーションも無くなるかも / 程よい規模をキープ / 広告 & tracking はコードを書くモチベーションが下がった時の防衛線 / あえて設計にメチャクチャこだわる (DI、modularize、testability) / 仕事で採用しているアーキテクチャパターンをそのまま真似る / デキる同僚が持ってきたアイデアをそのまま真似る / 真似つつアレンジもしてみる / 意外と厄介なinstant appに挑戦 / pushを打つとどうなるかを体感する / UIデザインをちゃんと考えてみることでわかる、UI設計の難しさ / 画面デザインはマテリアルデザインガイドと睨めっこ / やりたいことが広がったらAPIも作ってみよう / なんならiOSも / 応援したいサービスのアプリをどうしても改善したくて運営会社に乗り込み、APIの使用許可をもらってプロトタイピングさせてもらった話から見える、プライベートアプリに取り組むエンジニアとしての価値向上作戦
Intended Audience
- これからプライベートアプリを始めてみようかな?と思ってる人 - 一度始めたものの様々な事情にて上手く続いてない人 - Androidアプリ開発の広い知識をおさらいしたいと思ってる人 (もしこんな人がいれば) - 開発チームでlead業務 (management業務) も担いながら技術のキャッチアップも並行して行いコードを書き続ける、というスタイルで居るエンジニア (= スピーカー) が普段どうやってキャッチアップをしているか?に興味のある方Threat intelligence is not just a combination of IoC’s and Yara rules, those are just data. In order for an analyst to perform malware analysis, requires detailed data reports, breakdowns and correlations of applications with similar samples and behaviors at once. In our presentation, we will highlight some of the advantages of using our unified platform apklab.io to hunt for new mobile threats. Moreover we will provide an analysis on the latest mobile banking threats that was found in Google Play Store in 2018. Context matters to build intelligence.
Intended Audience
Developers, Malware Analysts, Professionals with knowledge of Android OS and internals.Android Architecture Components Pagingライブラリはタイムラインのような長いリストの読み込みをサポートするライブラリです。2018年5月正式リリースされ、10月より2系が正式リリースされました。 既にAACの導入を行なっていたり、モダンなアーキテクチャの導入を済ませているプロジェクトにおいては、Pagingライブラリの導入は容易だと思われます。しかし、内部のリファクタリング中や、他の大規模な機能開発が進んでいるプロジェクトではどうでしょうか。 本セッションでは、新規案件の開発と並行しながらリファクタリングの一環としてAAC Pagingライブラリを導入した話を共有します。また、下記の事柄について説明をします。 - AAC Pagingライブラリ概要 - ライブラリの効果、影響 - 導入時に見積もれたこと、見積もれなかったこと - 導入して楽しかったこと
Intended Audience
前提知識:RecyclerView, LiveData 聞いてほしい人:Pagingライブラリが便利そうと感じているが、導入への一歩を踏み出せない人。AACを入れようと考えているが、どこまで入れようか悩んでいる人。AACを入れると本当に良いことがあるのか疑問がある人。https://github.com/ashishb/adb-enhanced
Intended Audience
Android developersAndroid Studioにはアプリをデバックするための便利な機能が入っています。 しかし、機能が多すぎて使いこなせていないのではないでしょうか? 本セッションでは、問題があるサンプルアプリを題材にAndroid Studioのデバック機能を使いこなすことで、効率的にデバックする方法を説明します。 具体的に以下のことを学ぶ事ができます。 - デバッカーを使いこなす - ネットワーク通信周りの問題を検知する - パフォーマンスの問題がある部分を特定する - LayoutInspectorを使いこなす Android Studioを使いこなし、アプリ開発を効率的にしましょう!
Intended Audience
・アプリのデバックをより効率的にしたい方 ・Android Studioのデバック関連の機能を知らない方Google I/O 2018にてMotionLayoutが発表されました。MotionLayoutはConstraintlayout 2.0のサブセットであり、複数のレイアウト間を連続的に遷移する機能を提供します。 単に連続的に遷移といっても、従来のアニメーションやLayoutTransitionと大きく異なり、ユーザーの縦スワイプや横スワイプのような操作に追従する遷移ができます。このような遷移には以前は非常に高度な実装が必要でアプリ開発者泣かせの課題でした。MotionLayoutはこの課題に対し、Constraintlayoutの要素を使いつつ体系的に動きを記述することでそれを実現しています。 本発表ではMotionLayoutのコンセプトと考え方をお話した後、メジャーケースやMaterial Designに登場するもの、私が過去に実装したものが具体的にMotionLayoutでどのように実装できるかをお話します。 主なトピック - コンセプト - 考え方 - メジャーケースの実装方法 - Material Design等にでてくるものの実装方法 - 過去に実装アニメーションを置き換える例
Intended Audience
難易度: - 中級 対象読者: - ユーザー操作に追従するアニメーションの実装に興味がある人 - ConstraintLayoutを使ったことがあればベターNavigation Architecture Component は, AndroidアプリにおけるActivity および Fragment 間の遷移をより簡単に実装するために開発されました. これまで, Fragment間の遷移はFragmentTransactionを用いて実装したり, Deep Link も独自に実装することが主流でした. Navigation Architecture Component は, アプリ内における遷移を包括的に管理するために開発され, 同時に先述の問題を解決しています. このセッションでは, 実際にプロダクションで Navigation Architecture Component を利用してリリースした経験を元に, 以下の内容について発表する予定です. - Navigation Architecture Component の基本的な考え方と使い方 - Navigation は何を解決するのか - 基本的な使い方 (Fragment同士の遷移, ActivityをまたぐFragment間遷移, Shared Element, etc.) - Deep Link の実装方法 - コードから読み取れるNavigationライブラリの思想から考えるアンチパターン - Navigation Editor の使い方と, そもそも使うべきかの話 - Navigation Editor の概要 - Navigation Editor はいつ使うのか / 使ったほうがいいのか - SafeArgs によるActivity/Fragment間のデータ受け渡し - SafeArgs の概要と使い方 - サポートされているデータ型と使い方 - 独自クラスの受け渡し方法などのTips - 実際にプロダクトで用いた経験に基づく個人的ベストプラクティス - AAC(Android Architecture Components) と併用したときに困ったこととその解決策など - Navigation Graph をどう分けるか
Intended Audience
Navigation Architecture Component を使ったことがない方 / 使い始めたい方 複雑になってしまった Activity / Fragment の遷移やDeepLinkをよりシンプルに記述・管理したい方前提1 AndroidにはWiFi DirectというAndroid端末同士でP2P通信ができる機能があります。 これを使うとAndroid端末間でByteStreamを使ってbyteデータをやり取りすることができます。 前提2 AndroidにはVpnServiceというサービスクラスがあります。 これはAndroidでVPNを繋ぐときに利用するサービスでVPNソフトを作りたいときなどに利用します。 このサービスにはAndroid端末で外部通信に流れるPacketデータが全て流れてきます。 さて、これらの前提を元に、ここにSIMが刺さっていないAndroid端末が一台あります。 さらにSIMの刺さったAndroid端末がもう一台あります。 もうわかりますね? さあ、SIMの刺さっていないAndroid端末からHTTP通信を成功させてください。 ・え?なんでWiFi Direct + VpnServiceなの?普通にテザリングでよくない? ・VpnServiceに流れてくるbyteデータは生のIP Packet ・HTTP通信はTCP通信というプロコトルの上で成り立っている ・TCP通信って?UDP通信ってのもあるの? ・Packetの構成 ・TCP通信の仕組み ・AndroidでSocket通信する ・Socket通信で流れてくるbyteデータは生Packetではない ・足りないデータは作るしかない ・いろいろ頑張ったら〜、できた! このセッションでは通信の低レイヤーの話が出てきますが、それを理解してもらうことが目的ではないです。 このセッションを聞いて「Androidではこういうことも出来るのか」という可能性を感じてもらえると嬉しいです。
Intended Audience
マニアックな話が大好きな人 Androidの可能性に興味のある人 KotlinでSocket通信を実装する話に興味のある人この頃、Androidの専用端末は増えてきているように思います。 実際、居酒屋に置いてある注文用の端末がAndroidの専用端末だったりして、 そうとは知らずに見たり触ったりしたことがある人はたくさんいると思います。 でも、それらの端末で動いているアプリの開発の話はあまり聞かないと思います。 そこで本セッションでは専用端末アプリの開発について、色々と話してみたいと思います。 Google Playに出さないアプリの開発話に触れてみませんか? ・専用端末って、普通のAndroid端末とどう違うの? ・プリインアプリについて ・システムアプリ、DeviceOwner ・システムアプリの種類 ・SystemPermission ・専用端末の調達方法とアプリの開発手法 ・汎用端末を使う場合 ・市場に出回っていない端末を使う場合 ・この世にまだ存在しない専用端末を開発して使う場合 ・Google Playがないと困ること ・専用端末アプリのUpdateの仕組み ・なぜ専用端末にするの? ・専用端末アプリと普通のアプリの違い, etc.
Intended Audience
マニアックな話が好きな人 専用端末アプリの開発話に興味のある人事業と開発が一体となったチームで最速で仮説検証サイクルを回していくために、SUUMOアプリチームが取り組んでいる開発プロセスの改善についてお話します。 私が所属しているチームでは、リーンな開発を実現して価値を提供するまでの速さを追求した結果、スプリントを廃止してカンバン方式を導入するに至りました。 * なぜスプリントがうまくいかなかったのか * なぜかんばん方式を採用したのか * 運用してみて見えてきたメリット・デメリット について実例ベースでお話します。 開発プロセスについてもBuild-Measure-Learnの仮説検証サイクルを回していくことの大切さについて伝えたいと考えています。
Intended Audience
サービスの仮説検証の速度を上げたい方 開発プロセスについて悩んでいる方 なんとなくスプリントを運用している方Koin は Kotlin で記述されたKotlin 開発者のための実用的な軽量な DI コンテナです。 既存のコンテナとは違い、プロキシ、コード生成、リフレクションなどは使われていません! 以下のような様々なプラットフォームに対応しています。 - Android - AAC - Kotlin Application - KUnit - Spark - Ktor 今後、新しくKotlin を使いアプリケーションを作成する人は検討に値するライブラリだと思っています。 個人的な感想としては、比較的簡潔に記述することができるため、「DI 初心者...><」 って人にもおすすめです! 細かなところでは、依存性の注入をしているログを視覚的に確認できたりします!意図した通りに注入されてるか確認するのって意外に面倒ですよね? # 内容予定 - DI とは何か? - DI とは何か? - なぜDI しなければいけないの? - koin の説明 - koin の概要説明 - koin を使った初めてのDI まで - Android での koin の説明 - Android での koin の説明 - koin with AAC (Android Architecture Component) - Multi Module 環境も koin - Unit testing with koin - Unit Test での koin の説明 --- ここはできたら... - koin の中では何してるの? - koin の中では何してるの?
Intended Audience
Kotlin でDI に挑戦してみたい人。 Dagger 以外の DI コンテナについて知りたい人。# 概要 「アジャイル」「スクラム」「ウォータフォール」「リーン」、世の中には様々な開発手法が存在し、どの開発手法を選ぶのかは、チームの大きな課題の一つでしょう。 そこで、「リーンXP」はいかがでしょうか? リーンXPは「ユーザーに価値のあるものだけを細かく届ける」考え方のリーンと、「変化を受け入れ最大の効率を目指し日々改善を繰り返す」エクストリームプログラミングとを組み合わせた開発手法です。 本発表では、発表者が所属するAndroidチームで実践している最高におすすめな開発手法「リーンXP」を紹介いたします。 ユーザーストーリー・じゃんけん見積もり・TDD・ペアプロそして卓球といった要素で形成されるリーンXP開発の基本的な流れから、AndroidアプリにおけるペアプロとTDDの具体的な進め方を説明し、実践を通しての感想・成果、メリットデメリットをエンジニアの目線から語ります。 # 発表のゴール * リーンXP開発の雰囲気がわかる * ペアプロしたくなる * 会社に卓球台を置きたくなる # 予定している内容 ## リーンXPとは * 原則・プラクティス * 基本的な流れ ## エンジニアリング * ペアプロ・TDD * インクリメンタル * CI・CD * 卓球 ## プロダクト * MVP * ユーザーインタビュー * ユーザーストーリー * じゃんけん見積もり * 卓球 ## まとめ
Intended Audience
・Android未経験〜上級者 ・ペアプロに興味がある方 ・リーンXPに興味がある方 ・テスト駆動開発に興味がある方 ・卓球を仕事に組み込みたい方Android アプリに地図関連の機能を導入する場合は Google の Maps SDK for Android を利用することが多いと思います。この SDK 自体は以前から存在し目新しさはないのですが 、Android Architecture Components の ViewModel や LiveData を使い、また Kotlin で書くとどうなるかということについて説明します。 またカメラ移動のポイントやピン(marker)のカスタマイズの方法、便利な拡張関数や緯度経度から距離を算出する方法など、地図アプリケーションを作る上でのTipsについても紹介させていただきます。
Intended Audience
・これから地図機能を導入したいと考えている方 ・Kotlin、Android Architecture Components に興味がある方Android Architecture Components の ViewModel を利用した MVVM アーキテクチャを採用する場合、ロジックは必然的に ViewModel に集まり ViewModel のサイズは膨らみがちです。 このセッションではテストしやすいよう ViewModel をどう設計するか、どうテストするかについて説明させていただきます。 (テストフレームワークは Spek を予定していますが、セッション近辺の状況しだいで変更する可能性があります。)
Intended Audience
・Android Architecture Components に興味がある方 ・これからテストを書いていきたいというテスト初学者多くのアプリではユーザーを API サーバ側で認証し識別する必要があると思いますが、Firebase Authentication を利用することで簡単に、安全なユーザ認証の仕組みを構築することができます。 (Firebase Authentication は他の Firebase プロダクトと独立してこれ単体で、アプリ⇔自前 API サーバ間の認証で利用できます。利用料金はかかりません。) このセッションは Firebase Authentication で実現できることの紹介からはじめ、アプリ側の実装の方法、認証トークンを取り扱う上での注意点、サーバ側での認証の方法について説明します。 コードは Kotlin、非同期な処理はコルーチンを使うことを前提とします。
Intended Audience
・ユーザ認証の方法に悩んでいる方 ・まだ Firebase Authentication を使ったことがない方Want to know the standards and best practices Googlers followed while building their annual Android app? This session is for you, where we will decode everything they wrote! Right from why they choose Clean Architecture to the tools and libraries used by them to make Google I/O Android App more flexible for developers and easy to use for attendees.
Intended Audience
Basic Kotlin and Intermediate Android Development knowledge would be sufficient.We are at a stage where we are building for billions across the globe. Apps need to be more secure that could not be reverse engineered at all. Proguard and Obfuscation are a step towards it. Must to know things that can help you to secure your application.
Intended Audience
Android Enthusiasts :)Android Architecture Components is a set of libraries for designing great apps. It contains APIs for implementing concepts like Lifecycle and ViewModel. Whilst these APIs are great, they do come with some questions: • How do Lifecycle, LiveData and ViewModels work under the hood? How and where should each of them be used? • What is the difference between a ViewModel from Architecture Components and the one from the MVVM pattern? • Lifecycle components exist for Activities, Fragments and Application. Why don’t we have the same for Views? • Can we have ViewModels for Views also? • Is LiveData a replacement for RxJava? Can they live side by side? • How does LiveData work with DataBinding? • How should view state be handled and what goes into a Bundle versus a ViewModel? To answer all of these questions and more we’ll do a deep dive in the internals of Lifecycle, LiveData and ViewModels.
Intended Audience
No other knowledge neededThe design and usability of an app can be heavily influenced by one of the most common UI elements: TextViews. From font selection and pairing, type size, scale and alignment to line breaking… there’s a lot to consider when displaying text. There are many best practices from print and the web that we can learn from. This talk covers the design principles behind producing balanced, legible text layouts and how to implement them on Android.
Intended Audience
Basic Android knowledgeAndroidX Testで導入された最新のAPI (ActivityScenario, Truth, JUnit, etc)の紹介と、"Write it once, run it everywhere"を実現しているAPIの実装について話します。
Intended Audience
Android Applicationのテストに興味がある方。このトークでは - “monolithic”(= appのモジュールに大量なコードが入っている) - dagger2で依存管理を行なっている という特徴を持つアプリから、1機能を別moduleに切り出す (実際に切り出した) お話をします。 instant appの登場 (2016 Google I/O) などでアプリのmodule分割(modularization)の重要性は以前から薄っすらと広まっていたものの、dynamic feature module (dynamic delivery) の登場によりその重要性は決定的となりました。 アーキテクチャについての議論が盛んだった昨年の流れに則り、DIライブラリを使って依存関係をきちんと管理しているプロジェクトも多くあるかと思いますが、いざそんなプロジェクトでmodularizeを行おうとすると一筋縄では上手くいきません。 このトークではメジャーなDIライブラリの1つであるdagger2を使った設計パターンで、よくあるケース(*1) を例に取ります。このパターンでappから1機能をmoduleとして切り出した際、大きく3つの困難 (*2) がありました。monolithicな状態からスタートして、どのようなstepでmodule切り出しを進めていくのが良いか、どのような困難に当たるのか、どういうアプローチで解決すれば良いのか、順々に紹介していきます。 これから同じ事をやっていこうとしている方達への前準備にもなれば良いなと思ってますし、さらにこのセッションを通してDagger (DIライブラリ) へのさらなる理解を手助けすることができれば最高です。 本トークは、参加頂く皆さんに「問題」と「アプローチ」の両方をきちんと理解して持って帰ってもらいたいと思っていますので、課題設定に15分ほど時間を使って進めていく予定です。本トークで取り上げる実例(課題)が一体どういうアプリなのか?何のためにdagger2を使っているのか?moduleとして切り出すものは何を実現する機能で、どういう実装をしていたのか?それらを踏まえた上で話を進めますので「Dependency Injectionとは何か?」「dynamic deliveryとは何か?」をそれぞれ薄く知っているくらいの前提知識で楽しんでいただけるようにしていきます。 (*1) App全体で共有したいデータやクラスを “AppComponent“ で管理し、各機能の依存はそのcomponentの “SubComponent” として管理するパターン。AppComponentに @Singleton スコープを与え、いくつかの @provider メソッドに @Singleton スコープを与えることで シングルトンで管理しているデータなどが存在している。 (*2) これらの話を深掘りしていく予定です [1st step (appの外に新たなmoduleを作ろう)] - どうやってmoduleをsetupすればよいか (AndroidManifest, build.gradle) [2nd step (buildを通そう)] - buildが通らない理由 - moduleを作ったことによる依存グラフの変化を改修する [3rd step (Dagger2の依存グラフを再度チェックしよう)] - 各moduleの中のdependency graphとインスタンスの生存期間をreviewする - 切り出したmoduleを精査してclassへ internal 修飾子をつけていくことで、将来的に都合の悪い依存が生まれないようにしてしまおう
Intended Audience
- appを複数moduleに分割することを考えている方 - Dagger2を使ったアプリでmodularizationすることを考えている方 - dynamic feature deliveryの準備をそろそろ始めようと思っている方 - Dagger2をより理解して使えるようになりたい方 (普段Dagger2を “なんとなく” 使っている人)LINEは、2018年末にAndroid上でAnimated PNG(APNG)フォーマットの読み込み及び表示を行うことのできるライブラリをOSSとして公開します。このライブラリは元々メッセージングアプリ「LINE」で使われてきた内製ライブラリの一部を切り出したものです。 ライブラリの公開にあたってはリファクタリングを行う必要がありましたが、そこでは多くの問題が起きました。 このセッションでは、リファクタリングの際にどのような問題があったのか、そしてその問題をどのように解決していったのかについてお話しします。 古いコード特有の問題点、画像の処理が起因の問題点、Kotlin化に伴う問題点など数多くの課題をどのように解決すればいいか、そのノウハウについてお話しします。 NDKを使用しているライブラリのため、C,C++側のコードのリファクタリングについても触れます。 以下の内容を話す予定です。 - 内製ライブラリができた経緯とその後の変遷と、それにより現在起きている問題の紹介 - 5年という年月でいかにコードは古くそして汚くなるのか - その問題を解決するためのリファクタリングのノウハウ - リファクタリング前後の実際のコードを例にどのように修正を行ったか - Java→Kotlinへのリファクタリングのノウハウ - C,C++コードのリファクタリングのノウハウ - クローズドソースではなくOSSにしたからこそのリファクタリングのノウハウ
Intended Audience
- OSS化に興味がある方 - 長期間運用されているコードのリファクタリングに興味がある方 - Java→Kotlinのリファクタリングに興味がある方 - NDKコードのリファクタリングに興味がある方Google I/O公式アプリはGoogle I/O のセッションスケジュールなどがみれるGoogleが開発したアプリになります。 https://github.com/google/iosched このコードにはAndroid開発において重要な技術がたくさんつまっていて、得られるメリットが多いです。 ・使われているアーキテクチャ ・使われている技術 ・マルチモジュール ・テスト 最終的なゴールをコードが読めるようになるというのを目標に解説していきます。
Intended Audience
・これからサービスを1から立ち上げる方 ・サービスをリプレイスする方 ・アーキテクチャを選定している方近年QRコードは、仮想通貨や決済、連絡先の交換といった様々なところで使われています。 読み取りが早く、様々なところで使うことのできるQRコードですが、Androidで利用しようとするとCamera APIやSurfaceViewといったAndroid特有の部分でつらみを感じます。 本セッションでは、そんなQRコードについて、そしてリーダーを作る上でのベストプラクティスと注意すべきポイントを話したいと思います。
Intended Audience
- QRコードについて知りたい人 - QRコードリーダーを実装したい人 - 今あるQRコードリーダーをもっと早くしたい人Android開発の現場にKotlinが急速に普及しつつある昨今、ユニットテストの領域にも様々なKotlin製ライブラリが登場しています。代表的なモノとして、RSpecライクなDSLでテストケースの記述が可能な「Spek2」、Kotlinの言語仕様に沿った自由度の高いモックライブラリ「MockK」などが挙げられます。 これらのライブラリは、これまでデファクトであったJava製ライブラリと異なり、Kotlinの言語仕様をフルに活かせる設計で作られており、導入することでKotlinを使ったAndroid開発の生産性を大きく向上させることができます。 しかし、「これらKotlin製テストライブラリを複合してAndroidのユニットテストに導入した事例」はあまり表に出ておらず、発表者である私自身も導入に多大な苦労を強いられました。 このセッションでは、発表者が業務でSpek2、MockK、JaCoCoを導入した経験を元に、各ライブラリの概要および簡単な利用方法、導入時にハマったポイント等の知見を共有します。最終的に、聴講者がSpek2、MockKの基本的な利用方法を知り、Kotlinフレンドリーなユニットテスト環境をライブラリの導入までできるようになることをセッションのゴールとします。 時間に余裕があれば、JaCoCoを使ったカバレッジ算出の手順も解説し、カバレッジレポートの出力まで含めたテスト環境の構築を一通りできるような発表とします。 # アジェンダ - Kotlin製テストライブラリの紹介 - ライブラリの基本的な利用方法 - Spek2 - MockK - 導入 - ハマりポイントの紹介(Gradleの記述、JUnit4との共存等) - カバレッジレポートの出力 ※時間に余裕があれば - JaCoCoの導入 - マルチモジュールでのカバレッジ算出 by JaCoCo
Intended Audience
- Kotlin製アプリにイマドキのユニットテストを導入したい方 - テストの生産性を上げたい方 - Java製テストライブラリに不満を持っている方Google i/O 2018でもFlutterブースが開設される、メルカリさんの技術カンファレンスの公式アプリでも使用されるなど、Androidエンジニアからも注目度の高いFlutter。 業務でも使用される例もちらほらと聞こえるようになり、普及してきた様子が伺えます。 しかし、テストは書かれているでしょうか? また、Flutterアプリケーションに対するテストの知見は一般化されているでしょうか? 本セッションでは、Flutter記述言語であるDartの基本的なテストの記述方法から、 応用的なアサーション方法、Flutter特有のモジュールのテスト方法まで、幅広く解説します。 本セッションの内容だけで自動テストを書き始められるようになっていただくのが目標です。 以下、アジェンダです(予定)。 1. Flutterで使用できるテスト環境 2. テストのテンプレート 3. 基本のアサーション expect 4. matcherを使って複雑な条件を組み立てる 5. よく使う便利なライブラリとイディオム 6. 「テストできない!」がなくなる設計のアドバイス
Intended Audience
・Flutterアプリケーション開発をしたことがある方 ・Flutterアプリケーションのテストを書きたい方所属企業で開発しているWebサービスには、すでにAndroidアプリとiOSアプリが存在しています。 たった4人で各種アプリ(とサーバーサイドとWebフロントエンド)の開発をしなければならなくなった開発チームは、 Flutterでこれらのアプリの後続版を作成し、アップデートとして公開する道を選びました。 新規ではなく、すでに存在しているアプリのアップデートとして Flutterで作成したアプリを提供する際の知見を公表します。 新規開発以外にFlutterを使用できるケースあることを知ってもらい、開発の際の選択肢を広げてもらうのが目的です。 以下、予定しているアジェンダです。 1. 少人数チームにはFlutterが向いている理由 2. 開発してわかった、Flutterが適しているサービス/適さないサービス 3. AndroidエンジニアをFlutterエンジニアに仕立てるには 4. 新規開発とアップデート、どう違う? 5. アップデートの際に注意すべきこと
Intended Audience
・Flutterでアプリケーション開発をしてみたい方 ・業務でFlutterを使う機会を虎視眈々と狙っている方アプリ開発に携わるエンジニアは、多かれ少なかれ担当アプリの成長のために仕事をしています。エンジニアリングやその他の方法をもちいてアプリを成長させたり、その成長をより加速させることは、アプリ開発を担当するエンジニアの大切な仕事です。 本セッションのゴールは、受講対象者の方が、アプリを成長させるためにエンジニアができることを一つでも学ぶことができ、それをDroidKaigiが終わってから実務で真似しようと思えることです。 本セッションでは、「アプリの成長」の定義を下記2つとしています: 1. エンジニア目線でアプリケーションをスケールさせる、またはスケール可能な状態にすること 2. より多くのユーザーにアプリを利用してもらうこと 4−5人以上で開発するような大きいアプリケーション、かつ歴史が長く数年前からのコードも共存するようなアプリのメンテナンスにおいて、開発者の人数が増えた場合でも開発スピードを落とさず、さらにより多くのユーザーにアプリを利用してもらうための機能追加が容易にできるような内部構造にしておくことは、アプリを成長させるためにはもはや必要不可欠であるといえます。 本セッション内では、アプリを成長させるために業務の中で行ったAndroid技術の選定やAndroidチーム内での取り組み(ペアプロ・モブプロ・お集まり会・もくもく木曜日)を含め、クオーターや半期目線で立てた技術戦略(テスタブル化・テストカバレッジ・Kotlin化率)について紹介し、どのようにアプリの成長や、開発スピードの向上につながったか(またはつながらなかったか)を成功事例・失敗事例を踏まえて振り返ります。振り返ったのち、今までやってきたことを踏まえ、今後アプリをさらに成長させるためにこれから行いたいことについても紹介します。
Intended Audience
・「アプリをさらに成長させたい」と考えている方 ・ある程度の規模、かつ歴史の長いようなアプリをこれからもっと良くしていきたい方 ・チームビルディングやチーム開発について興味のある方 ・技術戦略について考えている方、興味のある方Flux and Redux come out from JavaScript community and now MVI in android. Find out about three different, but similar Data Uni-Direction Architectures, Flux, Redux, and MVI. I'll cover, - What is Flux? - What is Redux? - Which points are different between Flux and Redux? - What is MVI? - Which points are different between Flux, Redux and MVI? - What are pros of MVI in Android? - How can I apply MVI to existing architectures, especially in MVP? The aim of presentation is, - Understanding Data Uni-Direction Architectures, what, why and how
Intended Audience
Audience who are interested in MVI Audience who are interested in Data Uni-Direction Architectures Audience who are interested in various architectures Audience who want to know how to apply MVI to real project Audience who understand basic of architectures such as MVP,MVVMLearn how Jetpack changes the way to solve problems from the traditional programming. It covers basic of Jetpack especially in Architecture Components. I'll cover, - Lifecycles wraps lifecycle to Presenter - LiveData subscribes data changes to UI - ViewModel manages data with lifecycle - Room makes you easy to manage SQLite - Navigation implements navigation in GUI - WorkManager choose the best way for background work The aim of presentation is, - Understanding Jetpack, Architecture Components, what and how
Intended Audience
Audience who wonder what Jetpack is Audience who wonder how to use Jetpack especially in Architecture ComponentsDuring this talk you will learn how to build VR applications for Android starting with a basic Open GL ES prototype and moving towards a more complex one using Unity. We will start by explaining how to build simple prototypes with Java, OpenGL ES and the Google VR library. Then, we'll dive into Unity, which will allow you to build complex VR applications. We'll also show you how to build Android native plugins (Java, JNI) in order to explain you how Unity can interact with the Android components (we will take our player plugin as example). We'll give you some tips on UI/UX best practices for VR and some hints on 3D optimization for mobile platforms (in order for you to always keep your app at 60fps) which will give your users a smoother experience. All our examples will be based on CINEVR, the VR application we've been working on at Cinemur.
Intended Audience
Intermediate level in Android development (3-4 years of experience) OpenGL ES basics 3D development knowledgeViewModelはJetpackに含まれており、MVVMは既にAndroidにおけるメジャーな設計です。 しかし、ひとえにViewModelと言っても実装方法は様々です。 何が正しい役割なのか、どの技術を用いればよいのかと迷うことも多いと思います。 この発表では3種類のViewModelを紹介します。 ・LiveData + DataBindingパターン ・RxJavaで状態を持たないパターン ・RxJavaで状態を持つパターン それぞれのメリットを検証し、どんな時にどのパターンを使うべきか例を挙げます。 「何がViewModelとして正しいのか」よりも「アプリや画面に合うViewModelを見つける」ことを目指します。
Intended Audience
- 色んなViewModelを知りたい方 - ViewModelを作っているが、実装方法にモヤモヤしている方 - ViewModelを作っているが、アプリ内に相性の良くない画面があって困っている方テストしやすいコードを書くためにDI(Dependency Injection, 依存性注入)が広く用いられています。 AndroidアプリでのDIといえばDaggerなどのライブラリとセットで解説されることが多く、 ライブラリが高機能であるが故に初心者にはハードルとなっています。 この発表ではDagger等を用いずに原始的な方法でDIに取り組みます。 Kotlinのデフォルト引数を用いることで原始的ながらシンプルに記述できる方法を示し、 特定のライブラリに依存せずに実践できる方法を紹介します。 初めて取り組む方でもDIの感覚を掴み、すぐに現場で使えることを目指します。
Intended Audience
- これからDIに取り組む方 - DIにハードルを感じている方みなさんのアプリはTV対応していますか? AbemaTVやNetflix、Amazon Primeビデオなどの動画ストリーミングサービスが人気を博している今、Android TVやFire TVといったテレビデバイスやそれに対応したアプリへのニーズが高まってきています。 しかし、テレビデバイスに対応したアプリは未だ少なく、Android TV / Fire TV開発に関する知見も少ないのが現状です。 そこでこのセッションでは、モバイルアプリとテレビデバイスアプリ開発の違いやleanbackと仲良くなる方法を中心に、AbemaTVにおける実装例を踏まえながら、Android TV / Fire TV開発に関して包括的のに発表します。 仮ですが、アジェンダは以下の通りです。 - モバイルアプリとテレビデバイスアプリ開発の違い - Android TVとFire TV対応について - leanbackの各コンポーネント紹介と実装例 - テレビデバイス特有のニッチなTips - マルチプラットフォーム (FlutterやKotlin Native) 開発について - leanbackの未来予想図
Intended Audience
これからテレビデバイス対応をやろうと検討している方 leanbackの概念を理解したい方 テレビデバイス対応はしているが、他のアプリにおけるTipsを知りたい方Material DesignはGoogleが提供するオープンソースのデザインシステムで、Androidアプリはもちろん、iOSアプリやWebサイトのデザインから実装まで広い範囲で利用できます。 Google I/O 2018ではMaterial Designが大幅にアップデートされ注目を浴びました。 Google I/Oでの発表だけにとどまらず、Material componentsという各クライアントプラットフォーム向けに利用できるコンポーネントも開発が続けられています。 このセッションでは、新しいMaterial Designの概念的な説明や、推奨されるデザイン例のみならず、Material Componentsの実装例など、新しいMaterial Designに対応するための様々なTipsを紹介します。 仮ですが、アジェンダは以下の通りです。 - 新しいMaterial Designの概念 - 新しいMaterial Designのグッドパターン / アンチパターン - Material Componentsの実装例 - 新しいMaterial Designに対応するための便利なTool紹介
Intended Audience
新しいMaterial Designについてキャッチアップしたい方 Material Componentsに興味がある方"Screen rotation!" Rotate the screen and the Activity is recreated. It's a big reason to use ViewModels, but orientation changes aren't the only type of configuration change that happen on Android. And even when a configuration change happens, Android doesn’t need to destroy and recreate the Activity. In this talk we'll discuss the different types of configuration changes, what they mean, and why they happen. After the talk, you'll have a better understanding of the various types of configuration changes on Android and be able to make an informed choice for when—and when not—to handle them in your app.
Intended Audience
The talk is aimed for beginner to intermediate Android developers. Having a basic understanding of the Activity lifecycle is helpful. The goal is to help developers approach the challenges that really start to come up when porting apps to Android on Chrome, but the material is useful even just for phones.Testing is important. While we can do our best to write our code in a platform agnostic way, some code just depends on the Android system to work properly. Integration tests are one solution, but they depend on a physical or virtual Android device to run. This talk will showcase several options for how to test components that interact directly with the Android framework, including the benefits and drawbacks of each. After this talk, you'll have the tools you need to implement a comprehensive testing approach that can run entirely on your development machine; Android framework not required.
Intended Audience
An audience member should be familiar with Android development and want to test their code on their desktop rather than a physical or virtual Android device. The challenge the talk addresses is how to test code that, as an example, creates a Notification, or requests audio focus.大規模アプリケーション開発の現場では、開発体制やビジネス上のさまざまな課題があります。それらに対し、マルチモジュール化は多くのメリットを提供してくれます。 本セッションでは、実際の大規模アプリケーション開発現場が抱える開発体制やビジネス上の課題を挙げ、それに対してマルチモジュールを導入した体験談をTipsを交えてご紹介します。
Intended Audience
大規模アプリケーション開発に携わっている方、興味がある方 マルチモジュールに興味がある方アプリの改善活動を行う中で、ユーザーのアプリの使用状況を計測するSDKは必要不可欠な存在です。計測SDKにより、日々のユーザー行動をモニタリングでき、施策の効果検証などを行うための、様々な角度の情報を集められます。リッチな計測値を、他のデータベースと連携させリアルタイムに解析するため、独自のデータ分析基盤を開発しました。 アプリを改善するための基礎となる計測SDKには、3つの使命があります。1つ目は必要な情報を収集すること、2つ目は適切なタイミングで送信すること、3つ目はライブラリ自体が安定して動作することです。 本セッションでは、堅牢で安定した計測SDKをつくる方法を紹介をしていきます。まず、なぜFirebaseAnalyticsなどの外部SDKを選択しなかったのか、独自で計測SDKを作るとどんなメリットがあるか詳しく解説します。次に、計測SDKをつくる上でのアンチパターンを示し、計測時に使用者側のアプリへ影響を及ばさないために考慮すべき事項を説明します。さらに、アプリの改善活動を進める上で必要な計測値について解説し、どのような値をAndroidアプリで取得できるかを示します。そして、計測SDKの設計についてサンプルを例示しながら解説します。計測値の扱い方や、再送処理やエラーハンドリングをどのように実装するか、アプリのライフサイクルをどう活用するかなどについて触れます。最後に、計測値の管理方法や、ライブラリの公開方法など運用時に遭遇する問題についても紹介できればと思います。
Intended Audience
・独自の計測SDKをつくろうと考えている方 ・アプリからどんな情報を送信できるか関心のある方 ・アプリ改善施策の効果検証に注力されたい方 ・計測に関わらず独自ライブラリの開発を行いたい方Building an app from scratch that is supposed to be maintained and extended for years to come and needs to replace an active application with millions of downloads in Japan alone is no easy task. Still, that’s what we tried when completely rewriting the UNIQLO Android app this year. This talk will go over our requirements and design choices, the things we think we did right and we think we did wrong. Topics covered: There is no silver bullet. Clean architecture Architecture components RxJava DI with Dagger 2 Behavior driven testing Effective testing Clean vs velocity
Intended Audience
Developers and software architects interested in a discussion about architecture and best practices.アプリ内課金には、一回きりの購入と定期購入の2種類があります。ユーザーにとって普段見慣れたUIでワンタップで簡単に決済できるのは魅力的です。 アプリ内課金では公式のライブラリが提供されており、非常に簡単に導入することができます。以前はIn-app Billing Version 3 APIというライブラリを使う必要がありました。現在はよりシンプルなGoogle Play Billing Libraryがリリースされています。このライブラリには、使いやすいAPIが用意されており、AIDLを直接触らず、冗長な共通処理も書かなくて済みます。ライブラリ以外にも、Google Play ストアアプリやGoogle Play Consoleも継続的に機能やデザインが改善され、ますますアプリ内課金を導入しやすい状況になっていると言えます。 本セッションでは、定期購入をアプリに導入した経験をもとに実装方法や運用方法について説明します。まず、定期購入を導入した経緯や、どのような効果が得られたかについて紹介します。次に、Google Play Billing Libraryの各メソッドの使い方を、内部実装や実際の挙動を踏まえて詳細に説明します。そして、アプリに組み込む際の導線設計や具体的な実装方法を説明します。ここでは、ライブラリを使いやすくするためにRxJavaと組み合わせる方法についても解説します。最後に、課金時の動作確認の方法や、課金動向を分析する各種ダッシュボードの使い方など運用時に欠かせない事項も紹介します。 なお、このセッションでは定期購入の話を中心とし、一回きり購入にはあまり触れません。 定期購入は、運用して初めて分かることが多々あります。決済タイミングや無料試用期間、支払い猶予期間など、ドキュメントの説明と実際の動作をつきあわせることで更に理解が進みます。アプリ内課金はユーザーにとって非常にセンシティブで、販売者の利益にも直結する重要なシステムですので、定期購入対応で得られた知見、実装前に知りたかったノウハウを詳しく紹介できればと思います。
Intended Audience
・定期購入について関心のある方 ・今既に定期購入を使われている方 ・Play Billing Libraryの仕様や内部実装について知りたい方 ・アプリ内課金で何ができるのか知りたい方ランチャーはホーム画面のアプリです。故に、プリインストールされているランチャーだとしても、端末メーカーによってカスタマイズされているものは多く、Google Play Store にも様々なランチャーアプリが公開されています。 こうしたランチャーには、アプリ管理、ワークスペース、ウィジェット、等々、多くの機能があります。さらに、App Shortcuts (Nougat) や Notification dots (Oreo) などは、Android の新機能としてもアナウンスされています。ホーム画面のアプリであるため、 Multi-Window や Multiple Users などの機能も正しくサポートすることが求められます。 一方で、ランチャーについて網羅的に解説している公式ドキュメントは存在しません。AOSP のランチャー実装である Launcher3 のコードが唯一のリファレンスです。すなわち、ランチャーベンダは、Launcher3 を fork して開発しながらも、トレンドを取り入れるには、自力で新機能に追従する必要があります。 本セッションでは、カスタムランチャーを開発した経験をもとに、その実装方法について解説を行います。Launcher3のコードを読み解きながら機能を洗い出し、ランチャーの全体像を俯瞰できるような基本的な解説に加え、Launcher3 の拡張方法やデバッグ方法、特殊なパーミッションのハンドリング、Androidのアップデートへの追従の仕方、アプリ配布時の注意点等、より実践的な解説も行います。
Intended Audience
* ランチャーをこれから開発しようと考えられている方 * ランチャー上で Widget や App Shortcuts がどのように処理されているか知りたい方 * AOSPなアプリのアーキテクチャに興味がある方UX is more than looking good and being fast. Android is full of subtle visuals, animations, and other small indicators that help users create a mental model of the system. This talk will go into detail on what you need to look out for, and how you can implement the right "feel" in your app. This will include discussion on using Google's new Material Components library, customising it when necessary, and implementing your own components from scratch. In essence, the tools we use to gain a serious advantage as native developers.
Intended Audience
This talk is for Android developers of any experience level. It will assume a basic amount of knowledge with regards to Android's View and styling system.RxJava has become an invaluable tool to many Android developers, aiding in the composition of the several asynchronous systems we must deal with. However, with so much power RxJava can sometimes be the hammer we hold with almost everything looking like a nail. This talk aims to run through anecdotal examples of where RxJava has worked well, and where it maybe wasn’t the best idea.
Intended Audience
This session is aimed at Android developers who have used RxJava, or have considered using RxJava in their applications. It assumes a basic level of familiarity with RxJava and observable streams.最近、「FIDO 2.0」「Web Authentication(WebAuthn) API」「生体認証」といったキーワードを目にする機会が増え、いわゆる「パスワードレスなユーザー認証」がすぐそこまで来ています。 フィッシング攻撃、漏洩からの〜パスワードリスト攻撃、最大文字数や統一されない使用可能文字など、パスワード認証に関わる苦々しい記憶からついに抜け出すことができると注目されています。 Android と FIDO のこれまでの経緯としては、2017年12月に次のような発表がありました。 * FIDO UAF 1.1技術仕様を実装した初のFIDO(R) Certified(認定)製品が利用可能になった * Android 8.0以降のデバイスへのFIDO認証導入が容易になった キャリアのアカウント設定で生体認証が利用できたり、生体認証に対応したアプリを用いてインターネットバンキングアプリにログインできる事例も出てきました。 また、Androidアプリに関わる開発者にとって生体認証に関わる機能自体は新しいものではないでしょう。 * 2015年 : Android 6.0 Marshmallow : FingerPrintManager * 2018年6月 : Android P(Android 9 Pie) : BiometricPrompt このように生体認証を取り巻く環境は確実に変化しているものの、 まだまだ「アプリやサービスに生体認証 "のみ" でログイン」よりも「画面ロック解除」の用途としてのイメージが強いように感じます。 今回のセッションで扱う "WebAuthn" はWebアプリから生体認証やセキュリティキーを用いた認証を可能にする仕組みです。 Chrome の新しいバージョン(70)では "WebAutnn" で Android の指紋認証、 Mac の Touch ID をサポートしているため、Chrome + WebAutnn を組み合わせることでWebサービスに Android の指紋認証を用いてログインできるようになります。 パスワードレスなユーザー認証の普及の障壁だったWebサービスへの生体認証への導入が今後普及することにより、モバイルアプリにおける生体認証にも影響を与え、業界全体で安心安全なユーザー認証をできる世界に向かっていけると考えられます。 本セッションではその準備として、以下の内容を予定しています。 * WebAutnn 概要 * Chrome + WebAuthn でできること * Webサービス開発者は何をする必要があるか * 新規サービスで導入する際の注意点、パスワード認証からの移行方法など
Intended Audience
概要、できることはみんなに聞いてもらいたいところですが、 * 新しい技術に興味がある開発者 * 生体認証に興味はあるけど実装難しそうで手を出せない開発者 : "誤解" をときましょう * モバイル/Web問わず、登録や認証を担当したことがある開発者 : パスワード認証との"違い"、パスワード認証からの移行方法を理解しましょう * モバイル/Web問わず、登録や認証をこれから担当する開発者 : 新規サービスでパスワードレスな認証方式を導入する際のポイントを理解しましょう と言った皆さんに楽しんでいただけると考えています。Androidアプリではdexあたりのメソッド数の上限が65,535と決まっています。この上限を超えた場合はmultidexを使うことになりますが、Android 5.0以前ではいくつかの制限やパフォーマンスの制約があります。また、Android 5.0以降であってもビルド時間の増大やapkサイズの増加などの影響があります。 このセッションでは、発表者が実際に開発しているアプリケーションのdexメソッド数を減らした経験を通じて得た知見を共有します。 この発表では次のようなトピックについて触れます。また、実際にそれぞれの手段によってどれくらいdexメソッド数が減ったかについても紹介します。 - dexメソッド数を正しくカウントする - 定義数と参照数の違い - multidexでのカウント数の罠 - dexメソッド数の増減を把握しよう - dexメソッドをカウントするGradleプラグインの利用 - 増減を可視化する - ビルドの設定を見直そう - ProGuard設定を見直そう - 不要な依存ライブラリを除外する - Synthetic accessor methodを減らそう - Synthetic accessor methodとは - Android Lintの警告を利用する - Synthetic accessor methodを削除する - Kotlinインラインメソッドを利用しよう - inline修飾子で何が起きるか - inline修飾子を使ったときの注意点
Intended Audience
- multidexをやめたい人 - ビルド時間を短縮したい人 - Android特有のdexメソッド数がどのように算出されるかに興味がある人私たちは建築業界向けのSaas &ANDPADを開発しています。Saasでは、複雑な権限設定や権限に応じた画面の出し分けロジックなど、toC向けアプリとは異なる設計指針が必要となってきます。今までの開発ではネイティブ(swift/kotlin)を中心にアプリを開発してきましたが、昨今アプリ開発で注目を浴びつつあるFlutterをプロダクションに導入できないかと日々調査しています。 この度新規アプリにおいてFlutterを採用し、プロダクションリリースに向けて開発を進めているので、ネイティブアプリで培ったSaasアプリのノウハウをどのようにFlutterに適用していったのか、その内容をお話します。 目次 ・swft/kotlinの開発で用いたSaasでのアプリ設計 ・swift/kotlin環境での運営上のツラミ ・Flutterアプリで実現しているSaasアプリの設計 ・権限管理とUI描画の仕組み
Intended Audience
・Saasアプリに関心がある方 ・Flutterアプリの開発に興味がある方ユーザーが画面操作しなくても頻繁に外部からのイベントで画面遷移が発生するアプリ、 あなたならどのようなアーキテクチャを採用しますか? 弊社ではタクシー配車サービスを提供しています。 そのため、タクシーメーターと連携するアプリを開発し、各タクシーに設置しています。 このアプリは画面操作はもちろんタクシーメーターの操作、またプッシュ通知をトリガーに画面遷移する必要があります。 このように外部デバイスと密に連携し、様々なイベントを処理するアプリに最適なアーキテクチャとは何なのでしょうか。 アーキテクチャはそのアプリごとに最適なものが異なる、と考えています。 少々特殊な事例ですが、我々の試行錯誤の結果、またどのように改善を進めていこうと考えているか、をお話しできればと思います。 キーワード - MVVM - Redux - Flux - StateMachine - multi module
Intended Audience
- アーキテクチャの採用理由や事例を聞きたい - デバイスと連携するアプリに興味があるJavaからKotlinに移行して得られる大きな恩恵の一つである拡張関数. このセッションでは,Androidアプリケーションの開発で積極的に使っていきたい拡張関数を,標準で用意されているものから自身で定義したものまで幅広くご紹介します.
Intended Audience
- Kotlinを始めたばかり / 拡張関数について明るくない方 - よりAndroid開発を省力化したい方ユーザー体験が高いAndroid アプリを開発する上で、デザイナーとエンジニアの効率的なワークフローは重要です。 特に Material Design を利用したアプリ開発の場合、Material Component を利用すれば、ある程度エンジニアだけでも見栄えするアプリが開発できてしまうので、どこまでをデザイナーが行い、どこからエンジニアが実装を行うのかという、デザイナーとエンジニアの作業の流れ(ワークフロー)が曖昧になってしまうという課題があります。 こういった課題を解決する上で、Google ではエンジニアとデザイナーが協業しやすいよう、Material Design を中心として、Gallery, Material Theme Plugin, Resizer, Google Fonts 等様々なツールを提供する事で、より良いアプリ開発のワークフローを提案しています。 本セッションでは、エンジニアとデザイナーが Material Design のアプリを作る上でどのようなワークフローでアプリをデザイン・開発していくかのが良いかを、Material Theming, Gallery などを利用したワークフローを通じて説明します。
Intended Audience
- デザイナーと協業しているエンジニアの方 - エンジニアと協業しているデザイナーの方 - Material Design をこれから使いたいと思っている方 - 既存のアプリに Material Componentを組み込みたいと思っている方生産性を改善したい、というのは思いは誰しもが持っているものかと思います。 ですが、チーム全体の生産性の改善を行うには非常に多くの工数が必要になることが多々あり、中々思うように進めることができません。 そこで、本セッションでは、生産性を改善したいが、そこまで多くの工数を割くことができないエンジニアに向けて、 + 一人から始められる + すぐに取り掛かることができる + すぐに効果が現れる といった生産性の改善方法に焦点を絞って紹介します。 生産性の改善により確保できるようになった工数をつかって、更にチーム全体の生産性改善を行っていきましょう! 主に下記についての紹介をデモを交えて行う予定です(内容は一部変更になる可能性あり)。 よく知られていそうな機能については短く、あまり知られていないと思われる機能については少し詳しく紹介していきます。 ## チーム編 + チームでいろいろ共有しよう + code styleを共有しよう + inspection 設定を共有しよう + 辞書の設定を共有しよう ## 個人編 android studio + レビュー用リポジトリのススメ + とりあえず Cmd + Shift + A + コミット情報の簡単確認 + kotlin REPL でいろいろためしてみよう + 正規表現をチェックしよう + Language Injectionでミスを減らそう + スクリーンショットと画面の動画を保存しよう + デバイスエクスプローラーを利用してSharedPreferenceやファイルのやりとりを楽にしよう ## 個人編 adb + テキストを入力しよう + 現在表示中のactivity, fragmentを確認しよう + urlスキームを送信しよう ## 個人編 debugger + 変数の値を書き換えよう + 再ビルドなしで、log を出力しよう + 条件付きでログを出力しよう + 条件付きでブレークポイントでとめよう ## 個人編 その他 紹介のみ web debugging proxy 利用のススメ
Intended Audience
Android開発の生産性を改善したいと思っている人 Android Studioやadbで利用できる便利機能を知りたい人はてなではこれまで、Webサービスと連携するスマートフォンアプリをいくつも開発・メンテナンスしてきました。このようなアプリは、サービスをグロースさせるために、Webアプリと歩調を合わせて開発していく必要があります。Android / iOSの二つのプラットフォームで展開するアプリを改善していくのは途方もないことです。 継続的にアプリを改善していくために、私たちは新たにReact Nativeの採用を決めました。開発言語には当然ながらTypeScriptを選び、また新規にGraphQL APIも開発しています。 React Nativeはただクロスプラットフォームのコードを書けるだけではなく、ReactというWeb業界で進化を遂げてきたライブラリの、先進的なパラダイムを利用できるところにも大きなメリットがあります。また型による恩恵を受けるためにTypeScriptを利用しています。 長い期間スマートフォンアプリを開発していると、REST likeなAPIが徐々に腐敗していくことにも課題感を感じていました。これを解決するためにGraphQLを採用することにしました。アプリを改善する過程で表示要素の増減がある場合でも、GraphQLであれば小さな変更で対応でき、メンテナンス性も維持できます。 React Native + TypeScript + GraphQLのシナジーは、アプリの開発に大きな変化をもたらしました。Apolloライブラリを利用することで、ReactからGraphQLを効果的に利用でき、またGraphQLのクエリからTypeScriptの型を生成することもできます。これらの効果によって、クライアントサイドで必要な情報をクエリに記述していちどに取得し、型で保護されたまま一気にUIへと流し込むことができました。 いいことづくめのようですが、苦労した部分もあります。パラダイムがすっかり変わってしまったため、設計もいちから考え直す必要に迫られました。またネイティブコードとReact Nativeのハイブリッドで開発するために、コードの棲み分けや連携に気を遣う必要がありました。さらにReactで高いパフォーマンスを発揮させるために必要だったこともあります。 ReactNative及びGraphQLの台頭によって、今、我々スマートフォンアプリエンジニアの開発が大きく変わろうとしているのかもしれません。本セッションでは、React Native + TypeScript + GraphQLを実際に既存のアプリに取り入れたことで知り得たアプリケーション構成方法について、皆さんにノウハウを共有したいと思います。
Intended Audience
- React Nativeを使ってAndroid/iOSアプリを素早く開発したい人 - React Nativeのプロダクション導入を検討している人 - GraphQLの導入に興味がある人PdfRendererはAPI Level21で追加されたPDF表示のためのコンポーネントです。 これを使ってアプリ内でPDFの表示が行えるようになりました。 ところがPdfRendererはただPDFを渡せば表示してくれるような簡単なものではなく、PdfRendererによって生成されるbitmapを自分で処理する必要があります。 本セッションでは、PdfRendererを使ったPDF表示処理がどのように行われるか意識しつつ、サンプル実装を解説します。
Intended Audience
PdfRendererは使ったことがないが興味がある/これから使う予定があるかた PdfRendererを使っているがコピペで動かしているかた 前提として、ImageViewを使って画像を表示するアプリを作成する程度のAndroidの知識が必要ですThe time has finally arrived: We are able to use Virtual Reality to build Android Apps while beeing inside Virtual Reality 🤯 This talk will not focus on already exiting in VR creation tools like poly and the unreal VR mode, it is focusing on ways of using existing tools to build Android Apps in Android Studio, AIDE and more. After listening to my talk, audiences will be able to understand ways of reducing the development time of VR and AR apps by cutting down the transition/emulation phase. Additionally it will highlight breakthrough ways of using the infinite space VR offers to better organize your daily work.
Intended Audience
Innovators looking for ways improving their creation of AR/VR apps. Basic knowledge of computing needed, no in depth knowledge of Android development needed but nice to have.Android開発におけるCI環境の構築は、うっかりミスの事前防止や、機械的な作業を自動化させることによる負荷の軽減が期待できます。 ただしCI環境と一口に言ってもCIツールはいくつもありますし、それぞれのサービスにはそれぞれのメリット/デメリット、なにより設定方法が異なるため、選定から構築までの段階で疲弊しがちです。 現在のAndroidプロジェクトはgradleコマンドで大体のことができるのだから、CIツールで本当にやりたいことは、決められた処理を決められたタイミングで実行したいだけなのに…。 本セッションではこうした悩みの解決策として、あえて各CIツールの特色というものを無視し、まずDockerを使ってローカルでCIの真似事ができるようになったところから順次CIツールに導入させていくというやり方で、とにかく汎用的で使い回しが(比較的)しやすいCI環境づくりの一例をお話します。 【対象予定のCIツール】 - Circle CI - GitLab CI - Jenkins - (調査結果しだいで)GitHub Actions
Intended Audience
【話さないこと】 - CIとはなにか - Dockerとはなにか、Dockerのインストール方法 - 各CIツールの特色、独自の処理の詳しい解説 【対象者】 - とにかくCI構築の第一歩を踏み出したい方 - アプリ開発は完全にわかった(エンジニア基準)ので、そろそろCIのことを考えたい方 - 他人のCIを構築する上での辛みとその解決策をどんなレベルでもいいので知りたい方Android開発にモジュール化の波が来ています。モジュール化は我々の開発を変えていきますが、それにあわせてテストで気をつけなければいけないことは何でしょうか。本セッションではテストに焦点をあてて、マルチモジュールなプロジェクトにおけるテストとテストに関わるタスクがどう変わるのか?をお話したいと思います。 アジェンダは下記を予定しています。 ・マルチモジュールプロジェクトでのテスト方針 ・モジュール内のテスト ・モジュールをまたいだテスト ・テストメトリクスの集計
Intended Audience
・マルチモジュールなプロジェクトでテストがどうしたらよいか気になっている人 ・マルチモジュールなプロジェクトでテストのメトリクスをとりたい人アプリでビットコインを送ったり、もらったらするには、ウォレットという機能が必要になります。 ウォレット機能をアプリで作るにはbitcoinjというライブラリ使います。このbitcoinjを使い、どのようにしてウォレットアプリを作っていくか、またどういった課題があるのかをお話しします。 さらに、Lightning Networkというセカンドレイヤーと呼ばれる新しい技術を紹介し、今後のウォレットアプリの未来も話そうと思います。
Intended Audience
ウォレットアプリに興味ある方、ビットコインを使ったアプリに興味ある方、ブロックチェーンのアプリ利用に興味ある方LINEのクライアントチームでは、巨大なコードベースに対して沢山のエンジニアが同時に複数の機能を開発しています。 それら開発中の機能はリリースバージョンが一つ一つ異なっており、かつ、ある機能が別の機能に依存しているということも頻繁に起こっています。 そのような環境の中で、リリーススケジュールを管理したり、同時に横断的なリファクタリングを行うことは困難です。 この問題を解決するために、私達はフィーチャーブランチを使う代わりに、多くの場合次のような戦略をとっています。 まず、機能はたとえ開発中であっても、開発のメインブランチに入れてしまいます。 次に、その完成していない機能がリリースビルドに含まれないよう、フラグを使ってガードします。 このフラグは、プロパティファイルに記述しておくことで、BuildConfig クラスの boolean フィールドとして生成されます。 このフラグを使った機能の管理を行うことで、フィーチャーブランチによる管理と比べて、以下のような利点があります。 - 開発そのものとリリーススケジュールを分離できる - リリース前に問題が発覚したときに、安全に機能を無効化できる - 横断的なリファクタリングやライブラリAPIの更新を行っても、大きなコンフリクトが発生しにくい - デバッグのためだけの機能の管理が楽になる - 開発中の機能を他の開発者に見せることができる - 企画者やデザイナーにデモを見せる際の機能切り替えが楽になる このセッションでは、フラグの実装の詳細とその利点、さらに実装中に起きた問題とその対処法についてお話します。
Intended Audience
チームで開発を行っている方 git-flow で起きるコンフリクトに頭を悩ませている方 リリース予定より早くフィーチャーブランチをマージしてしまい、泣く泣くリバートをしたことある方 リリースブランチで機能に問題が見つかって、リバートしたかったけれど他のコミットのせいでうまく行かず、大変な思いをしたことがある方After spending hours working on a PR your finally ready and submit the PR for review, the feedback is good, but before you can merge you have been asked to fix a few small issues, do some formatting here, tidy up some code to match the projects code style, fix a forgotten check null here, and the list goes on. Over time, we can lose entry days or weeks of productivity fixing up these small mistakes. How do we remove repetitive tasks that take up our time? We automated them. In this talk, we will look at a few tools you already have like Android Studio, yes, you be surprised how many small issues you can fix with a few checkboxes. A few tools you may not be using yet and how they can either auto fix small issues or at least highlight issues when the code is fresh in your mind.
Intended Audience
Anyone who has had PR reviews.FlutterはMaterial Designのコンポーネントが豊富に揃っており、あまり深く考えずに画面を実装することができます。とはいえ言語が違えば作り方も違う。JavaやKotlinでは書き慣れているあの機能をFlutterで実装するにはどうすれば…?という壁が次々と襲いかかることでしょう。 レイアウトの作り方、RecyclerViewのようなリスト表示やタップイベントのハンドリング、SwipeRefreshLayoutやViewPagerといった操作とViewのコントロールが絡み合った機能…などなど、色んな所に落とし穴が潜んでいます。 本セッションでは、こういった「ちょっとひと手間かけないといけない実装」について、なるべくシンプルにわかりやすく実装することを目的に、実際のコード例を紹介しながら解説します。 基本的にAndroidの話メインで解説を進めますが、「iOSのアレはどうやって実装する?」という話も少し織り交ぜつつ、クロスプラットフォームのアプリを作る楽しさを紹介します。
Intended Audience
・Flutterに興味がある人 ・クロスプラットフォーム開発に興味がある人Code review is not just an inspection but rather a journey of the reviewer and the reviewee working together to reach the goal - delivering a good product. In this talk, we plan to speak about how a reviewer can make a collaborative code review, especially on Android app development. Android app development requires the reviewer to take into account various considerations; while there are some useful tips for the reviewer to find out potential bugs or improvements in the code. First, we define what a good code review is and explain the typical steps of a good code review. We think a typical process of a good code review is as follows: 1. Understand the goal and the background of the change 2. Run the app and verify the behaviour 3. Read the code and the layout XML carefully 4. Add any comments you come up with in your mind 5. Take back and think if there might be a better way 6. Have a conversation with the reviewee Then we will dive into each step and show some key tips for the review of Android development with an example from our real experience. For example, we believe running the app on a device is crucial to the review of the Android app code, so we will give an example and explain why it is important. Instead of talking about important yet too general things around code review, such as wordings of the comments, whether or not pointing out a format, etc., we are rather focusing on the entire process and Android-specific topics.
Intended Audience
- A developer who wants to improve the quality of the code through code review - Senior software engineers responsible for mentoring junior software engineers - Those who are interested in how to make a collaborative code reviewアプリ内で地図を表示するとき、ほとんどの方はGoogle Mapを使っていると思います。ユーザが慣れ親しんだジェスチャーで違和感なく操作でき、マーカや背景画像を拡張することも容易です。 しかしGPS以外の位置情報ソースを活用したり特定の場所に近づいた際のインタラクションのような "とりあえずマップを表示する" 以外の拡張を加えることを考えると、独自Viewをつくったほうがシンプルな表示となったり拡張性を高めることが可能になります。 そこで今回は展示に関連したアプリにて独自の会場内マップViewをつくった話をします。 このViewについて簡単に説明すると、 1. GPSの代わりに屋内位置推定を用いた現在地と方角を表示 2. ズームレベルの変更によって背景画像の拡大とマーカを移動(ただしマーカは拡大しない) 3. 回転によって背景画像の回転とマーカの移動(ただしがマーカは回転せず常に同じ方向で表示する) 4. ユーザの位置移動や操作によって移動・ズームイン・アウト・回転する という振る舞いをするViewです。 このようなViewを実現するためのアプローチとして、まずGoogle Mapが実現している機能について分析し、そこから実装すべき機能を取捨選択し、機能別にどのように実装していくか構想をすすめ、いざ実装をすすめて発生した改善点について段階を踏んで話していきます。 アジェンダ - Google Mapが実現している機能 - 現在地と方向を表示 - スワイプによる移動 - ピンチイン・ピンチアウトによるズームイン・アウト - 回転によるマップの回転 - ズームレベルで変わる背景表示 - ズームレベルが変わってもサイズの変わらないマーカ表示 - etc.. - 独自マップ風View実装のアプローチ - 今回実装するマップについて - 現在地を表示するためのインドアロケーション - 機能の取捨選択 - ジェスチャーのハンドリング - 現在地と背景、マーカの表示方法の違い - ズームと回転をViewに反映させる - ユーザの移動によって可能なインタラクション - 気持ちよく感じさせるためのTips
Intended Audience
- Custom Viewについての知見がほしい人 - マップのようなUIをつくることになった人メテオフォール型開発というキーワードが日本で流行りましたが、 チャレンジングなサービスのアプリ開発において、プロジェクトの停止や大規模な変更は一定以上の確率で発生してしまうものです。 そのような状況の中で、Andoridエンジニアとしてどのように案件と関わっていくかを解説します。 アジェンダ - 崩壊リスクのあるプロジェクトとは - 崩壊リスクのあるプロジェクトへの取り組み方 - 崩壊リスクのあるプロジェクトでの設計 - 崩壊リスクのあるプロジェクトでの開発 - 崩壊リスクのあるプロジェクトでのテスト - 崩壊後のモチベーション管理 - 崩壊後のノウハウ共有
Intended Audience
- 新規・リニューアルのアプリ開発のプロジェクトに携わる方 - 変更の多いアプリ開発に携わる方Gradle plugins architecture is awesome, add a plugin to the classpath and apply it to your project and that's it your done. But, what if there are no plugins for what you need? What if you just need something simple? What if you want a build flavor without actually making yet another build flavor? In this talk we will explore just how programmable we can make our builds without needing to create any plugins, we will look how you can add build parameters, how you build can dynamically reconfigure its self-depending on flavor, the environment it's running in, and just how easy it is to automate anything with just a few Gradle scripts and some tasks.
Intended Audience
Basic Android development experienceHave you ever had you're a designer give you SVGs that just don't render correctly? UI performance decrease since moving to vector icons from PNG? There are lots of things that can cause lower performance when drawing android vector drawables. The cause of all of them is a lack of communication. Designers know how to create beautiful and marvelous icons. What they might not know how Android works with vectors, limitation of the format and performance characteristics. In this talk, we will look at some of the common mistakes both developers and designer make when moving to vector drawables. How you can retroactively correct common problems when converting an SVG to vector XML, and how you can effectively communicate with your designer to reduce bouncing back and forth
Intended Audience
Some experience with using Vector drawablesGradleはJavaやC++, Pythonなどいつくかの言語で使われているビルドシステムです。 Androidのビルドシステムとしても採用されており、プロジェクトの設定からアプリのビルド、ライブラリ・依存関係の管理、プラグインによる拡張など、Androidアプリ開発に便利な機能が揃っています。 Gradle5.0からBOM importのサポートが予定されており、Preview版としてGradle4.6から使用可能になりました。 BOMファイルには関連した複数のライブラリのバージョンをまとめて定義することができ、BOMファイルを参照することでプロジェクト内で各ライブラリのバージョンを個別に設定しなくてよくなります。 Androidアプリ開発ではあまり馴染みのないBOMについての説明と、マルチモジュールプロジェクトでの導入、他プロジェクト・チームに導入する際の展望についての話になります。 大規模なプロジェクトではいくつものライブラリを使うことになりますが、全ライブラリのバージョン情報をBOMファイルに定義することで、BOMファイルの更新のみで複数モジュール、プロジェクトのライブラリをまとめて更新することができます。 また関連ライブラリのバージョンをまとめて定義することで、誤ったバージョン指定によるライブラリ間のバージョン差異によるビルドエラーを防ぐことができます。 BOMファイル自体もバージョニング可能なため、BOMファイル内に定義しているライブラリ群のいずれかで新しいバージョンがリリースされたときは、BOMファイルを更新しBOMファイルを参照している他のモジュール・プロジェクト内でBOMファイルのバージョンを更新する、という流れになります。 BOMファイルを活用することで、複数のプロジェクトで最新のライブラリバージョンを使いやすくなるのではと考えています。 アジェンダ - Graldeでのライブラリ管理についておさらい - BOMファイルの起源と書き方 - 1つのBOMファイルに書くライブラリ群の分け方 - 複数BOMファイルを参照する際に気をつける点 - 複数プロジェクト、チームにまたがったBOMファイル運用
Intended Audience
- いくつものライブラリの管理で疲労している方 - 常に新しいライブラリで開発をすすめていきたい方 - 複数案件のライブラリ管理をまとめてスッキリさせたい方# 概要 弊社ではスマートロックを作っていて、スマートロックとの通信はBLEで行なっています。本セッションではスマートロックのアプリを作った経験を元に、BLEを使用したアプリの設計、ハマりどころについて話します。 # このセッション得られるもの * BLEアプリ開発のハマりどころ * 通信先が複数あるアプリ設計の参考 # 発表内容(予定) * BLEについての簡単な説明 * AndroidのBLEのAPIをそのまま触るのは辛いので、RxAndroidBLEの導入をおすすめ * BLE通信設計のパターン - どのようにService, Characteristicを配分するか - MTU(1パケットに詰められるデータ量)を超えるデータを転送するときに起きる問題と対処法 * BLE通信デバイスとWebサーバーの両方にデータがあり、それらをアプリが中継する場合のアプリ設計パターン - どうモデリングするか - モデルの取得先がデバイスとサーバー両方にあるけど、Repositoryはどう作る? - デバイスとサーバーの情報をアプリでいかに同期するか
Intended Audience
* BLEもしくはIoTに興味がある人、ハマりたくない人 * BLEを使用するアプリの設計に興味がある人はじめてAndroid開発をする、もしくはAndroid開発を始めてみて数ヶ月、どう学んでいけばいいのか、どう情報収拾をするか、開発時に考慮するべきことは何かなど、分からないことが多くあるのではないでしょうか。 このセッションでは、Androidの歴史をはじめ、Android開発時によく見かけることになる機能やライブラリの紹介、日本のAndroid界隈で主流となっているイベントやコミュニティ、本などをご紹介するつもりです。 基礎的なところを押さえて、次の一歩への取っ掛かりとなれば幸いです。
Intended Audience
・Android開発をこれからしようとされている方 ・最近Android開発をし始めた方 ・他のセッションが難しくて分からない方 ・Android開発未経験者の教育係になりそうな方【諸注意】 - 本セッションはiOSを貶すものではなく、またAndroidを褒め称えるものではありません - 応募時点で本セッションではAndroidのソースコードを掲載する予定はありません 日本でAndroidスマートフォンが発売されてから約10年、iPhone(3G)が発売されて11年が経とうとしています。 Androidはメジャーバージョンが9となり、iOSは12が提供されています。互いに似た機能を取り込んだりすることもありましたが、基本的にこの2つは同じスマートフォンであっても別物であるという認識を、一般ユーザーの方も知るようになってきました。 ですが、それでもいまなお頑張ってiOSを模したデザインのAndroidアプリがGoogle Playで配信され、どうやってiOSの○○のような見た目をAndroidで実装するかといったノウハウが共有されています。 なぜこのような苦しい思いをしてまで、別物であるはずのiOSのデザインに合わせた実装をする必要があるのでしょうか。いえ、ありません。 本セッションでは、iOS(主にiPhone)とAndroidのハード面の違いだったりソフトウェア(OS)の違い、それこそいまとなっては常識と化したUXの視点などから「なぜiOSアプリのデザインを単純にそのままAndroidに合わせるべきではないか」ということをお話します。 【話さないこと】 - 具体的なAndroidデザインの実装方法
Intended Audience
- 本セッションは仕様〜画面設計段階の話をするので、デザイナーやプロデューサーの方も対象となります - アプリのデザインの決定権を持っている方 - なんとかAndroidに合わせたデザインに持っていくための材料を探している方Background processing is an integral part of Android development, and the WorkManager API is the architecture component to manage your Android background jobs. New battery optimizations are key to improving the user experience, but these bring new challenges for the developers implementing background jobs: * API Level 23 introduced Doze Mode and App Standby * API Level 24 limited implicit Broadcasts and introduced doze-on-the-go * API Level 26 further limited background behavior WorkManager supports a combination of opportunistic and guaranteed execution. In this talk you’ll learn what WorkManager is and how you can use it to: * Schedule a simple task * Chain tasks * Display task status in the UI * Cancel tasks WorkManager API is part of Android Jetpack’s Architecture Component, and is currently in alpha.
Intended Audience
Basic of Android architecture. This talk aims to present the WorkManager API, which problem this library solve, and how to use it.App signing by Google Play is often seen as a hefty price to pay to get all the advantages offered by Android App Bundles. You want the smaller APKs for your user and the support for dynamic modules that Android App Bundles offers, but the main concern is that you lose control of your signing keys to Google! In this talk I’m going to explain what problem app signing by Google Play is solving, how it integrates in the Android App Bundle story and what are the gotchas and the edge cases that you need to consider when opting-in to app signing by Google Play. App signing by Google Play is not just available for Android App Bundles. If you’re deploying APKs you can still benefit from this feature. You can improve the security of your releases maintaining all the control that you’ve today (and you’ll be ready to smoothly move to an Android App Bundles tomorrow)!
Intended Audience
Basic knowledge of Android architecture and APK signing. Explain why and how to use App Signing by Google Play.日本向けに展開してきた Android アプリを海外展開するために英訳をあてて各国の Play Store へリリース!しかし、英訳だけでは十分なユーザ体験を提供できませんでした。。。 海外のインターネット環境は日本ほど恵まれておらず、低速で不安定なインターネット環境でも快適な体験を提供するためには、通信処理・画面遷移・データの保持に大幅な設計変更が必要でした。 本セッションでは、Android アプリの海外展開に必要な ・低速なインターネット環境で問題となる事象の紹介 ・WorkManager を使った UX 改善方法 ・apk サイズの削減方法 ・画像を扱う通信の改善方法 について分析方法も踏まえて紹介いたします。
Intended Audience
・海外に向けて Android アプリを展開予定の方 ・apk サイズの削減を行いたい方 ・通信のチューニングを行いたい方 ・オフラインでも動作する編集機能の提供を検討されている方テストコードを書く際に、複雑な依存関係をどううまくハンドリングするかは悩みの種です。特に粒度の小さいユニットテストでは、テスト対象のモジュールが内部的に依存しているモジュールを"ハリボテ"に差し替えることでテストの網羅性や堅牢性を高めることは広く行われています。 このようなハリボテは一般的に「モック」という呼び名で親しまれていることが多いですが、「XUnit Test Patterns」の著者Gerard Meszaros氏はこのような役割をするオブジェクトを「テストダブル(テスト用の影武者)」と定義し、細かく分類しました。モックはこのテストダブルのひとつに過ぎません。 本セッションでは、このようなテストダブルの定義を再確認し、どのような用途でどのようなダブルを使うのが適切であるかを実際のコードとともに確認します。それを通じて、いままでなんとなくモックを使っていたひとも、これからテストコードを書き始めるひとも、より分かりやすく読みやすくテストダブルを使い分けられるようになることを目指します。 また、テストダブルの使い方から逆説的にこれまでのモジュール設計で無理のあった部分を洗い出し、より堅牢で保守性の高いコードを書くための示唆についても確認します。
Intended Audience
・うまくテストを書けなくて悩んでいるひと ・テストダブルに馴染みがないひと ・テストダブルを使っているが使い分けに自信がないひとAndroid Architecture Componentsは Google I/O 2017で発表されたライブラリ群です。これにより、高い安定性やメンテナンス性、テストのしやすさを備えたアプリを設計出来ます。 googlesamplesは, Googleが公開しているサンプルリポジトリです。Googleが推奨する設計の例として、Androidアプリ開発におけるAACの使い方を示す小さなサンプルやベストプラクティスが紹介されています。 参考URL https://developer.android.com/topic/libraries/architecture/ https://github.com/googlesamples/android-architecture-components https://github.com/googlesamples/android-sunflower 発表された当時AACは、Lifecycle/LiveData/ViewModel/Roomだけでしたが、2018年の Google I/Oでは 新たにNavigation/Paging/WorkManagerが追加されています。 本セッションでは、この新Componentsを踏まえた最新のAACの実装についてお話致します。AAC特有の画面設計、データ更新方法や開発における注意点などについてもご紹介するつもりです。
Intended Audience
・AACでどんなことができるのか知りたい方 ・AACでこれから開発しようと考えられている方 ・これからAndroidアプリを開発しようと考えられている方 ・googlesamplesのAAC実装を読んでみたい方データ表現とは、狭義には整数や少数、あるいは文字列などが、コンピュータ内部の2進数としてどのように表現されているかという意味ですが、ここでは広義の意味として、現実世界に存在する概念を、Kotlinのクラスとしてどのように表現するかについて、日々のAndroidアプリ開発の中で実践していること・発見したことを発表したいと思います。Javaで書いていた頃にも理論上可能ではあったものの、実装コストや不完全さで採用されてこなかった方法が、Kotlinの強力な言語機能、あるいはΛrrowなどの周辺ライブラリによって、より簡潔でより堅牢に、適切なデータ表現を実現することが可能になりました。具体的には、nullableにすべきところとすべきでないところ、data classやsealed classの使い方や使いどころ、PairやEitherなどのクラスの使いどころなどについて、実践的なAndroidアプリ開発の例を交えて紹介しつつ、数学的な分析を含めたより一般的なクラス設計・データ表現の方法について、解説したいと思います。
Intended Audience
普段KotlinでAndroidアプリを開発していて、Kotlinの各種便利なクラスや文法を使っているものの、それらの使い分けがイマイチ明確ではないと感じていたり、もっと使いこなせる方法を知りたいと感じていたりする方。現実世界の複雑な概念を、より簡潔でより堅牢にAndroidアプリのコードに落とし込みたい方。また、自分の実装方法に対して、論理的な根拠・理由を確立したい方。デスクトップもモバイルも最大のシェアを持つ業界標準 Web ブラウザは Chrome ですが、Android であっても通常の Chrome ブラウザでは要件を満たせないケースは意外と多くあります。 そもそも Chrome を始めとした Google 謹製アプリが提供されない AOSP 端末の開発、非標準的な UI/UX 端末開発時に専用のブラウザが必要とされる場合、セキュリティ問題などのために標準ブラウザを採用できないケース、マルチプラットフォーム対応に Web を利用したいがブラウザの制約によってやりたいことが出来ない場合、などなど ... Mozilla が世界中のキャリアやメーカーに向けてカスタマイズした Firefox の提供をしている取り組み、独自のブラウザを必要とする国内企業へのカスタム Chromium ブラウザ提供、Web 標準 API だけでは実現できない場合にカスタムブラウザを作って実現するアプリ開発、さまざまな目的と実装のカスタムブラウザ案件を見てきた経験から、ドキュメント通りのブラウザのビルドだけではないカスタムブラウザ開発をご紹介します。 具体的な発表内容は時間・要望あるいはカスタムブラウザ採用企業の意向によって調整しますが、Chromium/Firefox をベースにカスタムブラウザ開発を行った案件から学んだ知見やノウハウ、ブラウザベンダーが標準で提供しているブラウザカスタマイズのための仕組み、WebView ベースでブラウザアプリ開発を行う際に役立つフレームワークの紹介などを行う予定です。 Firefox 1.0 日本語リリース担当から始まり Mozilla Japan (現 WebDINO Japan) にて国内での Firefox OS 端末展開や世界中の Firefox カスタマイズ事例を見てきて、現在 CTO として Web とブラウザの領域拡大に取り組む立場ならではの視点でお話しします。
Intended Audience
ブラウザ・ウェブ・オープンソースなどが好きな方。 オープンソースという言葉とトレンドを生んだ Netscape のソースコード公開から 20 年、一度自分でカスタムブラウザを開発してみたかった人、ブラウザをビルドしてみたが何故か標準ブラウザと機能やパフォーマンスの違いがあり困った人、カスタムブラウザではどんなことが出来るのか興味のある方、自社の製品開発でカスタムブラウザを必要として困っている人、Web エンジニアだが Web プラットフォームの限界から抜け出す仕事がしたい人、などおのお越しをお待ちしております。 勿論、現ブラウザベンダーのエンジニアもウェルカム!You’re building your app, you’re out on your way, Activity to fragment, you’ll add deep links one day. Notifications, transitions, you pass arguments, too, Just a messy piece of cake, for a developer as you. But then hitting back, or up or away - What should happen? You’re lost! The road starts to sway! They talked about launch modes, affinity, activity stack... Let’s deep dive to those, then learn the new stuff from Jetpack!
Intended Audience
This session can be either a deep dive to Android navigation (activity stack, launch modes, etc..) or focus more on the new navigation component.Time has come where we know how significant is our power as mobile developers. We create pieces that sits in everyone’s pocket and joins to the most part of their day. App creators play a major role in how do people feel connected. If they feel strangled by over-connection. If they feel excluded by struggling to communicate. In what is their mood, due to how an app communicated back to them.. Today we know our power, and our responsibility. We know that we contribute to an inclusive world, a communicating world, a connected world, a well being and balanced world. This talk will explore how you can create a wonderful communication experience for your users, right in the space between their Joy Of Missing Out (JOMO) and Fear Of Missing Out (FOMO).
Intended Audience
Keynote session (selected for DroidconSF 2018) can be 30 or 50 minutesHappy people - dance. Happy apps - animate! Happy devs - easily write delightful apps which make their users happy! 2 years ago, when ConstraintLayout was born, it added to the family performant expressive layouts. Since then, it grew and evolved, and became abundant with powerful animation opportunities! ConstraintSet, Key Frames and the new shiny MotionLayout - this session will utilize them all to make your apps dance, and your users happy!
Intended Audience
Creating new animations with the brand new MotionLayout (presented in DroidconNY) can be 30 or 50 minutesUsing ARCore Sceneform, you can place 3D objects to the real world very easily. But if you want to change the object to the specific state, you must have knowledge about 3D programming. In this session, I will talk about basic 3D programming for ARCore. It contains about "How to scale, rotate, and translate the obejcts" and "how to use the matrix and vector in 3D programming." If you're not familiar with 3D programming, this session must be useful to start developing ARCore. After 50 minutes of this session, you will be a strong ARCore developer. Trust me!
Intended Audience
- Developers who want to start ARCore development - Developers who want to study basic 3D programmingFridaは主にモバイルアプリケーションをデバッグするための開発者向けツールであり、アプリケーションに実装されている関数呼び出しを追跡やフッキング(メモリ上で関数などの処理を改ざんする手法を指します)による関数の改ざんを可能とします。近年はモバイルアプリケーションに限らず、情報セキュリティ技術者の間では様々なソフトウェアをリバースエンジニアリングする目的で活用されています。サイバーセキュリティの観点では、悪意のあるソフトウェアの動的解析のような防御視点の使い方だけでなく、フッキングによりゲームのチート行為のような攻撃者視点の用途で使われてしまうことがあります。 本講演では、サイバー攻撃の技術を専門とする情報セキュリティ技術者として、Fridaを用いたアプリケーションの解析手法や、フッキングによりアプリケーションを改ざんする手法を初心者向けに解説することで、アプリケーション開発者のセキュリティ対策に貢献することを目標とします。講演ではFridaというツールやフッキングという手法の解説に加えて、Fridaを用いたフッキングによる簡単なアプリケーションの改ざん手法の実演を交えることで、聴講者の理解を深められるように努めます。
Intended Audience
情報セキュリティ技術に興味がある人Androidを取り巻く状況はこの2年間で大きく変化しています。例えば次のような変化がありました。 ・Android関連パッケージのAndroidX (Jetpack)への再編 ・記述言語のKotlinへのシフト ・Android Architecture Components(AAC)の浸透 このめまぐるしい変化にEspressoのテストコードも対応していかなければなりません。 本セッションでは、最新トレンドに対応したEspressoのテストが書けるようになることを目標に、次のトピックを紹介します。 ・EspressoをAndroidX対応にする ・EspressoをKotlin対応にする ・Espresso Test Recorderを使ってKotlinで記録する ・変更に強くするためにKotlinでPage Objectデザインパターンを適用する ・AACを採用したアプリに対するEspressoテストの注意点 また、2018年後半に公開が予定されているProject Nitrogen導入に伴う変化についても(具体的な公開時期や発表時間の制約によりますが)可能であれば紹介したいと考えています。 本セッションの内容を学んで、UIテストコードもAndroidの最新潮流に乗り遅れないようにしましょう!
Intended Audience
・EspressoのテストをKotlinで書きたいと考えている方 ・既存のEspressoテストを最新トレンドに移行したいと考えている方 ・AACを採用したAndroidアプリのUIテストをEspressoで書きたいと考えている方 ※Espresso初心者の方も付いていけるように配慮しますが、時間の制約から、詳しいAPIの説明などは割愛すると思います。Gradle Kotlin DSLとは、KotlinのDSLでGradleのビルドスクリプトが書けるというものです。普段書いているbuild.gradleは補完が効かないため、雰囲気やコピペで済ませてしまうことが多いかも知れませんが、Kotlinで書くことによって、補完やコードジャンプができ、より一層理解が深まります。そんなGradle Kotlin DSLですが、ドキュメントがまだまだ少ないため、このセッションでは基本的な書き方をまずはじめに解説します。さらに、ビルドごとに実行するタスク以外にも、ファイル変換するタスクや不要なリソースを整理するタスクなど、今までシェルスクリプトや他の軽量スクリプト言語で書いていたものをGradle Kotlin DSLで書く方法を紹介します。このことにより、Kotlinさえ書ければ誰でもメンテナンスできるという状態にすることができます(ついでに、GitHubが100% Kotlinになります!)
Intended Audience
Gradle Kotlin DSLに興味がありつつもまだ入門できていない方。Androidアプリ開発を便利にしたい方。メタプログラミングが好きな方。皆さんのプロジェクトでは、UIテストは書かれているでしょうか?UIテストを真面目に書いても、バグを検知できなかったり、後々の改善によって壊れてしまい開発スピードを低下させてしまうといったことがあるのではないでしょうか?このセッションでは、我々のプロジェクトで実際に運用されている「コスパの良いUIテスト」ついて紹介し、その書き方を詳しく解説したいと思います。また、UIテストでしばしば問題となる「非同期処理」について、RxJavaとKotlin Coroutinesの2パターンでどう対応すべきかについても考えてみたいと思います。
Intended Audience
テストがほとんどないプロジェクトのデグレを効率よく減らしたい方。UIテストの導入に興味があるものの、イマイチ導入に踏み切れない方。KotlinConf 2018 で Kotlin/Native のベータ版が発表されました。 「聞いたことはあるけど使ったことはない」「本当に Kotlin だけで開発できるの?」「他のツールとどう違うの?」という方向けに、 Kotlin/Native を利用したクロスプラットフォーム開発についてご紹介します。
Intended Audience
クロスプラットフォーム開発に興味がある方 Android または iOS エンジニアの方R8はJavaコードを最適化されたdexコードに変換するためのシュリンカーです。Proguardを置き換える目的で作成されました。R8ではコンパイルタイムの軽減、dexコードのさらなる最適化を目指しています。 dexコードのさらなる最適化とは具体的にどのようなものでしょうか? 本セッションでは、R8でどのような最適化が行われているかをバイトコードレベルから説明します。また、Kotlinに関する最適化など、R8の特徴について説明し、Proguardと比べどこが進化したのかを紹介します。 具体的に以下のことを学ぶことが出来ます。 - R8の内部実装 - R8とProguardの違い - R8ではどのような最適化が行われているか?
Intended Audience
- dexファイルの最適化に興味ある人 - R8でどのような最適化が行われているかを理解したい人JSONをパースするのにGsonが一般的に使われていると思います。しかし、なぜGsonを使っているのか説明できる人は少ないのではないでしょうか? Android開発では他にもMoshiやKotlin serializationなどの優れたライブラリが存在します。 本セクションでは、各serializationライブラリの特徴/内部構造を理解することで、あなたのアプリに適したライブラリを見つけ出すことを目指します。 具体的には以下を学ぶことが出来ます。 - 各ライブラリの特徴 - 内部実装の差異 - あなたのアプリに最適なライブラリを発見できる
Intended Audience
- Serializationライブラリの内部実装を学びたい人 - アプリで使うSerializationライブラリの選定に悩んでいる人# English Decription(Japanese below) Fintech became a real thing. Just like the financial startup and the largest chat service collaborated in Japan, the boundary between financial institutions and others are no longer distinctive. Financial data will be able to read/write from any services based on the decisions of users. We all know universally interconnected financial data is a good UX for users because users regained a choice to control the data. To protect such innovation, OpenID Foundation has been working out to define global standard called Financial API(FAPI) including security profile for Android. As OpenBank in the UK has already adopted the idea of FAPI across the service, it’s not too much to say all services handling financial data will be required to comply with FAPI. The problem of FAPI is its complication. OAuth and OpenID Connect themselves are already complicated standard, but FAPI is the extension of them. Thus, simply using third-party client SDK like `Google Sign-In` will not meet the requirement. So at this point, Android developers involving in Fintech services need to implement by themselves with the clear understanding of requirements in FAPI. That’s why this session is here for. In this session, I will introduce AppAuth, an OAuth/OIDC client SDK build by OpenID Foundation, the same organization who defined FAPI. Through AppAuth, we will lean requirements in FAPI, implementation of FAPI in context of OAuth2.0, OIDC. # Outline (May change later) 1. Review of OAuth 2.0 for Native Apps 2. What is FAPI? 3. Understanding the implementation of OAuth2.0, OIDC in FAPI via App Auth 4. Understanding implementing of FAPI specific requirements # 日本語Description 本セッションでは、AppAuthというOpenID foundationが作成した認可(OAuth)や認証フェデレーション(OIDC)のクライアントSDKを通して、金融機関向けのAPIクライアントとして満たすべきセキュリティ要件を考えていきます。 昨今は某証券と某チャットが結びついて「銀行・証券口座」のデータの読み書きがアプリ間で可能になり、まさにFintechが実際のイノベーションとして実態を結んだと言っていいでしょう。その素晴らしいユーザー体験を守るために作られた国際標準がFinancial API Security Profileです。 当然その中にはアプリに要求する仕様も含まれており、最早Androidによるモバイル端末で金融サービス連携をすることは避けられない時代です。 しかし、FAPIは複雑なOIDCを更に拡張したものなので、素直にGoogle Sign-InなどのよくあるクライアントSDKでは要件をクリアできません。おそらく現時点で要求を満たしたものはないかと思われます。 そこで、本セッションではFAPIを規定したOpenID Foundationが作ったAppAuthを通じてFAPIの仕様と理解をしていきたいと考えています。 以下が、アジェンダ(仮)になります 1. OAuth 2.0 for Native Appsのおさらい 2. What is FAPI? 3. AppAuthを通してOAuth2.0 in FAPIの要件を理解しよう! 4. AppAuthを通してOIDC in FAPIの要件を理解しよう! 5. Implementing FAPI specific要件 in Android
Intended Audience
- anyone interested/ works in Fintech - anyone interested/ needs to understand FAPI, OAuth, OIDC - anyone interested/needs Authorization and ID Federation# English Description (Japanese below) We are exhausted with passwords. Users are exhausted with passwords because of too many web-services. Operators are exhausted with passwords because of defense against password-related attacks like Phishing. We, as developers, are also exhausted because of poor UX in passwords. In last DroidKaigi, I have presented “AuthN and AuthZ with Android”(認証と認可と君と) for the purpose of introducing FIDO UAF 1.1, the password-less authentication framework. Since the presentation, a lot of innovation has been made. For example, major browsers adopted, implemented, and released WebAuthN which will play important role in FIDO 2.0, which will be the new version of UAF 1.1. Android hasn’t been left behind by the advancement in Authentication. In March 2018, FIDO2.0 package was released in Android API, and that is exactly what I am going to talk about. At the end of this session, the audience will understand what `com.google.android.gms.fido.fido2*` will do, how to use it with `BiometricPromptAPI`, and how it is related to WebAuthN. ## Outline 1. Reviewing FIDO UAF 1.1 2. Safetynet Attestation vs Key Attestation 3. com.google.android.gms.fido.fido2 4. fido2 with BiometricPrompt 5. fido2 with WebAuthN # 日本語Description 去年のDroidKaigi2018「認証と認可と君と」ではそういった苦労から我々を開放するパスワードレス認証「FIDO UAF 1.1」とAndroid上での実装方法についてお話しました。それから早1年、次バージョンにあたるFIDO 2.0の一翼を担うWebAuthNが主ブラウザに実装され、更にChromeの最新Ver70ではAndroidの指紋認証との連携ができるようになりました。勿論、Android自体にも大きな動きがあり、2018年にはAndroidのAPIに新しくFIDO2.0用パッケージが登場しました。本セッションでは、com.google.android.gms.fido.fido2* についてBiometricPromptAPIなどのAndroid内のFIDO2関連のAPIと絡めつつ、実装方法をお話します。 ## Outline 1. Reviewing FIDO UAF 1.1 2. Safetynet Attestation vs Key Attestation 3. com.google.android.gms.fido.fido2 4. fido2 with BiometricPrompt 5. fido2 with WebAuthN
Intended Audience
- anyone interested in Authentication - anyone interested in FIDO - whoever wants to understand difference between FIDO in Android and WebAuthN■ 概要 クライアントアプリの要件は年々高度化・複雑化してきており、エンジニアとしてのスキルを伸ばすことはもちろんとして、普段の開発を効率化することが重要になってきています。本セッションでは、私が実際に業務で開発しているアプリで導入している「サポート機能」を題材として、開発を効率化する手法を紹介します。サポート機能とは、デバッグビルドでのみ有効となり、開発を効率化するための機能の総称です。 汎用的なサポート機能として、Dockerのように環境をコンテナ化することでランタイムでの動的な環境切り替えを実現してビルド時間を削減したり、アプリ上に独自のログ機構を実装することで社内でのバグ報告を効率化したり、永続データをアプリ上から変更可能にすることでデバッグを効率化したり、といったものを紹介します。サービス特化なサポート機能として、ユーザーステータスの動的な変更や、特定状態の再現機能を実装することでテストを効率化するといったものを紹介します。 ■ 目次 - サポート機能とは - 汎用的なサポート機能 - サービス特化なサポート機能 - デバッグビルドでのみサポート機能を有効化する手法 - 汎用的なサポート機能 - ビルド時間を削減するためのコンテナ機構 - ランタイムでの動的な環境切り替え - 複数環境の同時起動 - バグ報告を効率化するためのログ機構 - ユーザーの行動をトラッキング - Logcatライクなログをアプリに表示 - バグ報告をSlackに投稿 - デバッグを効率化するための永続データ変更機構 - SharedPreferencesの変更 - SQLiteの変更 - サービス特化なサポート機能 - ユーザーステータスの動的な変更 - 特定状態の再現機能
Intended Audience
- ビルド時間を削減したいと思っている方 - バグ報告を効率化したいと思っている方 - テストを効率化したいと思っている方 - デバッグを効率化したいと思っている方 - もっと先へ加速したいと思っている方■ 概要 クライアントアプリの要件は年々高度化・複雑化してきており、それに伴ってクライアントアプリが扱わなければいけない状態もどんどん増えていきます。扱う状態が増えていくにつれてバグや開発コストが増加することが多く、クライアントアプリにおける状態管理は重要なウェイトを占める題材です。 状態管理にまつわる問題をスマートに解決するための手段として、WebフロントエンドではReduxが採用されることが増えており、同じフロントエンドとしてReduxから得られるメリットの多くはAndroidにも当てはまります。本セッションでは、Androidにおける状態管理の難しさを具体例を交えて紹介し、それを解決する手段の1つとしてのReduxをコードレベルで解説します。 ■ 目次 - Androidにおける状態管理の難しさ - ライフサイクルとの付き合い方 - 画面を跨いだ情報のリアルタイム同期 - 複数のデータソースを扱う必要性 - Reduxの概要 - Reduxが登場した背景 - Reduxが解決する課題・解決しない課題 - Action/Reducer/Storeの概要 - Reduxの実装 - Action/Reducer/Storeの実装 - Middlewareの実装 - RxJavaの活用 - Reduxのテスト - Android Architecture Componentsとの関係性 - 他のアーキテクチャ(MVP/MVVM/Layered Architecture)との関係性
Intended Audience
- アプリの状態管理に苦労している方 - 画面を跨いだ情報同期に苦労している方 - Reduxのメリット・デメリットや実装方法を知りたい方 - 他のアーキテクチャとの比較結果を知りたい方Kotlin Coroutinesは非同期処理をシンプルに記述できるKotlinの言語機能です。実験的な機能としてこれまでも提供されてきましたがKotlin 1.3で正式にリリース予定です。 Androidの誕生から10年たちアプリの利用シーンが増えた結果、アプリ開発の複雑さも増してきています。開発者はアプリの性質に合わせてMVVMをはじめとしたアーキテクチャとArchitecture Components(AAC)など複雑性を解消するライブラリを組み合わせ、実装上の課題を解決してきました。 本セッションでは新登場のCoroutinesを既存のアプリケーションへ適用する方法と導入するメリットを中心に解説します。 Coroutinesの本質を理解することはアーキテクチャをよりシンプルに保ちます。そして言語機能の追加がアプリ開発現場に与える影響を考察していきます。 設計・開発の効率化といえば、これまで多くの場合、ライブラリの導入がメインでした。しかしアプリの複雑性が増加するにつれて多数のライブラリを導入しつづけることは開発者に多くの知識を要求し、イニシャルコストの増加に繋がります。言語そのものの力を理解することでコストを下げ、より素早い開発を実現できます。 本セッションはアプリ開発で実践できるよう、なじみのあるアーキテクチャを通じてCoroutinesを学んでいきます。 聞き終わったときには、AACなどモダンなライブラリのなかで効率的な非同期処理に対応する方法を習得できます。 セッションの構成(変更する可能性があります) - はじめに:Coroutines登場の背景 - 現代のアプリケーション開発の課題 - 期待されるCoroutinesの役割 - アプリケーションへの適用 - MVVMアーキテクチャで実践するCoroutines - Coroutinesの便利な使い方 - 他アーキテクチャにおける利用指標 - まとめ:AndroidアプリにおけるCoroutinesの役割
Intended Audience
手を動かして実践してひとへのヒントとなります ・Coroutinesを使いたいと感じているひと ・よりモダンで効率的なAndroidアプリ開発に興味があるひと ・新しいパラダイムをいち早く知りたいひと ・アプリ開発が複雑だと感じるひと ・アプリ開発経験を前提としてあったほうが楽しめますAndroidが出始めた頃 (2010年あたり) 、設定画面を作る常套手段は PreferenceActivity でした。checkboxやinput formなどシンプルなUIが予め用意されており、さらにそのUIからPreferenceへの書き込みや更新が隠蔽されているため、ボイラープレート的なコードを最小限に押さえることが出来たのです。ところがPreferenceActivityは、Fragmentの登場と共にPreferenceFragmentへ形を変えたあたりからどんどんイマイチになっていき、最近ではあまりメジャーではなくなってしまいました。 そんな最近、preferenceに関するライブラリ群が support libraryの中に追加され、PreferenceFragmentもPreferenceFragmentCompatとして進化を遂げて帰ってきてくれました。非常に小さな実装で、Materialなデザインと共に、非常に容易に設定画面を実現することができるようになったのです。ただし、使おうとすると「なぜ?」という事が多いことも事実です (styleというものを指定しないとクラッシュするなど...) 。 このセッションでは、そんな便利だけどちょっと癖のあるPreferenceFragmentCompatの使い方を紹介します。SelectorとText入力というBasicな使い方を紹介した後、少しAdvancedな使い方として凝ったUIを持った設定画面の作り方も紹介します。そしてここ1年くらいの間では、こういった設定データ管理はRoomという別の選択肢も登場してきましたが、設定データの管理という目線からのPreference vs Room という考察も行っていこうと思います。
Intended Audience
- PreferenceFragmentの存在を知らなくて興味のある方 - 設定データの管理方法として Preference vs Room の対比に興味のある方しかし、UIテストで避けては通れない課題として実行時間が長くなるという問題があります。 なにも対策を行わなければ、UIテストの実行時間は右肩上がりになってしまいます。 UIテストの実行時間を短くするにはどうしたらいいのでしょうか。 本セッションでは、UIテストを高速化するためにどのようなことをやると良いのかについて紹介していきます。 主に紹介することは以下のようにいろいろな方面からの話を予定しています。 ・テストコードでおこなうべきtips ・テストを実行する環境に対するtips ・効果的なワークフローにするためのtips そして、なにもおこなっていないときと上記のようなことをしたときの実行時間を比べ、どの程度効果があるかもふくめ紹介します。 これによりUIテストをより効果的に利用できるようになればと思います。
Intended Audience
・UIテストをさらに広く利用したい方 ・UIテストの実行時間で悩んでいる方 ・UIテストについてより知りたい方Atomic Designはデザインシステムを作る手法の一つです。 AndroidにおいてもAtomic Designという手法は導入でき、エンジニアとデザイナとのコミュニケーションコストが下がり、デザイン構築のコストを減らすことができます。 デザインの構築はとても複雑です。デザインシステムがないと、プラットフォーム間での違いや画面ごとの違いなども起こりがちで、同じスタイルなのに画面ごとに名前の違うスタイルや、スタイルを使わずViewに直接属性を書くといったことがよく発生します。 Wantedlyではデザイナーが主導となり、社内で統一されたデザインシステムの構築をしています。 デザイナーが構築したコンポーネントや各種リソースをAtomic Designとして各プラットフォームに実装しています。 このセッションでは、WantedlyにおけるデザインシステムについてとAndroidにおける実装についてお話します。アプリをまたいだAndroidでの実装手法、デザインのモジュール化などについてもご紹介するつもりです。
Intended Audience
・デザインシステムに興味のある方 ・デザインを組む上でどういった単位でコンポーネントを作るか悩んでいる方 ・スタイルやリソースをどう管理するか悩んでいる方FlutterにはFirebaseを使う上で便利なプラグインが豊富に用意されており、手軽にサーバレスなアプリケーションを作ることができます。しかし、AndroidやiOSで既に馴染み深くなった実装でも、Flutter(Dart)という環境で改めて取り掛かろうとすると意外とつまづいてしまいます。 本セッションでは、Flutterで使えるFirebaseの機能の紹介と実装のポイントを、実際のコードやデモンストレーションを交えて説明します。Firestore(データベース)やFirebase Cloud Messaging(プッシュ通知)、Firebase Analytics(イベントログ解析)といったFirebaseのメインとなる機能を中心に、時間の許す限りすべてのFirebaseプラグインの使い方について解説します。 また、クロスプラットフォームならではの落とし穴やコツ、実際にFirebaseを使ったFlutterアプリを作ってみた上での知見なども紹介します(参考:https://inside.pixiv.blog/consomme/5246)。
Intended Audience
Flutterを使ってみたいと思ってる人 Firebaseを使ってアプリを作ってみたいと思ってる人# 概要 これまでも人類は、さまざまなやり方でマルチプラットフォームを試みてきました。全てのコードを共通化できるというのはとても大きな特徴ですが、各プラットフォーム間の差異が壁となるパターンもあります。 特にView部分に関して言えば、各プラットフォームのAPI依存が大きく共通化で苦労する点があります。 しかし、Kotlin/Nativeを用いれば、プラットフォームに寄らないView以外のロジック部分を共通化することで、メンテナンス性の向上や開発をスムーズにしてくれます。 さらに、AndroidとiOSはもちろんWebブラウザでつかうJSコード、サーバサイドのコードも共通化することが出来ます。 そしてついに、2018年10月に今までβ版だったKotlin/Nativeの1.0がリリースされました。 本セッションでは、主にAndroid, iOSに焦点を絞ってAndroidエンジニアとiOSエンジニア双方の観点から見た、概要・良い点・厳しい点などを、Kotlin/Nativeを使った簡単なアプリと、実践的な動画アプリのサンプルを交えてお伝えします。 # 目次(案) - Kotlin/Nativeとは。 - 概要 - 他マルチプラットフォームツールとの比較 - 簡単なサンプルを用いた解説 - 基本的な使い方 - Android - iOS - Web - Server - 実践的なサンプルを用いた解説 - Androidエンジニアの観点 - iOSエンジニアの観点 - まとめ
Intended Audience
ReactNative, Flutter等のマルチプラットフォームを検討している人 少数精鋭チームでAndroid, iOS, Web, Server開発を考えてる人 Kotlin/Nativeの現状を知っておきたい人UnityによるARの実装方法は、多く掲載されておりますがAndroid Studioでの実装例について情報が少ない現状です。 AndroidでARを実装していく際に、既存のアプリにAR機能を追加していくことが今後可能性としてあるかと思われます。 そういう背景から今回は、私がARCoreの概要および主要な機能について、初心者にわかりやすく説明いたします。 具体的には、3つの主要な機能について説明する予定です。 ・Sceneform - 3Dモデルの表示やTextViewなどのAndroid標準のコンポーネントをARとして表示する機能 ・Argumented Images - 任意の画像をマーカーにして、ARを表示することができる機能 ・Cloud Anchors - 複数の端末で1つのARを操作することができる機能 これらの具体的な実装方法と、ハマりやすいポイントについてコードレベルで解説いたします。
Intended Audience
・Android開発を経験したことがある、AR開発初心者の方 ・Unityではなく、Android Studioで既存のアプリにAR機能を組み込みたいと考えている方 ・ARに興味があり、概要から実装まで簡単に知りたい方Architecting a reactive app can be challenging and complicated, but luckily Flutter is built on a modern reactive framework which makes it much simpler to use reactive architecture. In this talk, we will take a look at Flutter's reactive framework and a few reactive architectures which take advantage of Dart's async library.
Intended Audience
Mid-level to senior mobile app developers■ 概要 2017年にGoogle I/Oで発表されたAndroid Architecture Components(AAC)はAndroidアプリ開発をする上では今や欠かせないものとなりました。 ActivityやFragmentのライフサイクルをあまり意識せずにデータを扱うことができるため、ViewModelやLiveDataのいずれかは使っているプロジェクトが多いのではないでしょうか。 AACを使っている中でこの使い方で合っているのだろうか、なんとなく使っているけれど大丈夫だろうかと思ったことはありませんか。 そこで本セッションでは、AACのViewModelの内部の仕組みについて解説します。ViewModelの仕組みについて理解を深め、onSaveInstanceStateとの違いを理解することで、UI状態の保存、復元を効率よく管理する方法を学んでいきましょう。 ■ 目次案 - AAC ViewModelとは - ViewModelの概要 - onSaveInstanceStateとの違い - ViewModelの実装例 - ViewModelの仕組み - ViewModelStoreによるViewModelの管理 - ViewModelProvidersでViewModelが取得できるまで - ViewModelProvider.Factoryとは何か - 画面回転時にViewModelが破棄されない理由 - ViewModelのライフサイクル - UI状態を効率的に管理する - UI状態を保存する手段 - ViewModelを使って構成変更に対応する - onSaveInstanceStateとViewModelを使い分ける
Intended Audience
- Androidアプリ開発をある程度やったことがある人 - AAC ViewModelをなんとなく使っている人 - AAC ViewModelの理解を深めたい人Dependency Injection(DI)とは、オブジェクトを別のオブジェクトに供給する技術の一つです。 大きなアプリケーションを開発する上で、DIは欠かせない非常に便利なものです。 現状Androidアプリ開発においてはDagger2を採用しているプロジェクトが多いですが、その他にもいくつかの選択肢があります。 本セッションではDagger2, Motif, Koin, Kodein-DIの4つのDIを取り上げ、D各々の解説を行います。 - Dagger2 - Motif - Koin - Kodein-DI
Intended Audience
DI未経験者 Dagger2は使ったことがあるが、その他は使ったことがない方Android端末管理の高度化・標準化を実現するために企業でのAndroid端末の利用をサポートするためのプログラム「Android Enterprise」 Android Enterpriseでは管理者がGoogle Playを管理し、承認したアプリのみを配信する事が可能となります。 会社から支給するデバイス向けに、利用デバイスを企業の監視下において管理できる「DeviceOwner」と端末内のデータを個人領域と仕事領域に分け、仕事領域のみ企業の監視下で管理できるBYOD向けの「ProfileOwner」等があり、端末のセキュリティをより強固にする事が可能です。 このセッションではAndroid Enterpriseについての詳細や機能を、デモを交えて紹介し、端末管理の仕組みにおける今後の方向性などのお話ができればと思います。 ・使い慣れたこれまでの機能と企業向けに設計された管理機能を組み合わせた「管理されたGoogle Play」 ・会社所有端末の管理 - Device Ownerで完全な端末の管理を行う - Device OwnerとProfileOwnerの併用で多様なニーズに応えた端末の管理を行うCOMPモード - Device Adminはレガシー機能 ・従業員が所有している端末の管理 - 仕事領域を作成し、ProfileOwnerで仕事用プロファイルを適用 ・会社所有の端末を専用端末として管理 ・デバイスプロビジョニング方式 -QR code device provisioning -NFC device provisioning -DPC identifier install -Google Accounts Method -Zero-Touch Enrollment ・ここまで出来る!DevicePolicyManagerで制御可能な機能について ・端末管理の今後 -Device Admin Deprecation
Intended Audience
・端末管理機能(DevicePolicyManager)に興味があり、活用したい方 ・ニッチな機能に興味がある方 ・MDM導入を検討されている方最近の Android アプリ開発において GUI アーキテクチャに MVVM が採用されることが増えてきていると思います。 しかし、ViewModel が Fat になってしまうという声があるなど、MVVM の真の力を発揮できていないようです。 本セッションでは、MVVM の真の力を開放するためのアーキテクチャと、 RxJava と Kotlin によって現実的になった Reactive な MVVM の実装を支える技術について話します。 ## 話すこと(予告なく変更される可能性があります) - MVVM とは - MVVM の目的(Why) - PDS(Presentation Domain Separation) - PDS を実現すると何が嬉しいのか - MVC 系はすべて PDS を実現することが目的 - コラム: Android アプリ開発に最適な GUI アーキテクチャとは - MVVM のアーキテクチャ(What) - MVVM のコンセプト - Model, View, ViewModel の責務 - Reactive な MVVM の実装(How) - Reactive な MVVM の実装を支える技術 - View -> ViewModel の実装 - ViewModel -> Model の実装 - Model -> ViewModel の実装 - ViewModel -> View の実装 - Reactive な MVVM を支えるアーキテクチャパターン(Option) - Model をどう設計するか 〜DDD, Clean Architecture, Flux 風味〜 - State - UseCase - Repository - DomainModel - コラム: マルチモジュールとライブラリ管理 ## TODO - Reactive な MVVM の実装を支える Android specific で Innovative な Expertise のライブラリを公開する - そのライブラリのサンプルとして DroidKaigi Conf App を実装して実装例にする
Intended Audience
- Android アプリ設計パターン入門を読んだ人 - MVVM を理解を深めたい人・やっていきたい人 - ViewModel が Fat になりがちな人 - MVVM の真の力を理解し、体得したい人 - 最高の MVVM で優勝したい人 ## 受講する必要がなさそうな人 - この世はでっかいシングルトンだとわかっている人 - ViewModel は Model の射影であるとわかっている人 - MVVM は単方向データフローだとわかっている人 - MVVM インフラを構築したことがある人 - MVVM 警察ARCore, Sceneform, Firebase等, 2019年の技術を駆使してスマートフォン黎明期のARアプリであるセカイカメラを再現したらどのような構成になるのか試してみました(発表者は当時の開発メンバーの1人)。その過程を通じてScneformを使ってJavaで実装する方法、Cloud AnchorsとFirebaseを組み合わせてAR空間を共有するための実装をする方法等、AndroidでのARアプリの開発方法についてお話したいと思います。
Intended Audience
Androidアプリを開発したことがあり、ARCoreを使ったARアプリ開発に興味を持っている方As a mobile app developer, you probably have noticed Google's active efforts on bringing their machine learning expertise to mobile development. From TensorFlow's earliest mobile app demo to TensorFlow Lite and Android Neural Networks API, we are witnessing how latest research (e.g. MobileNet) drastically reduced machine learning model size and CPU / memory consumption on mobile devices. This year, with the beta release of ML Kit, we now have another powerful toolbox to leverage machine learning in the mobile application development. This talk features a side project Magritte, an educational application that helps people learn foreign languages. It's sort of like Duolingo but with eyes, the application recognizes daily objects using custom machine learning models embedded on device and speaks the vocabulary out loud with the chosen language. By presenting the Magritte app, the talk will reveal how the models for TensorFlow mobile were initially trained and optimized, how the performance was improved with TensorFlow Lite and MobileNet models, and eventually the migration to ML Kit.
Intended Audience
Android developers who are interested in getting to know how to leverage machine learning power in their applications by running the inference with model on-device.We, Android developers, feel very lucky to develop for such a modern, mature, optimized and secured platform. Our apps can run on smartphones, Chromebooks, TVs, cars, watches... and now, with Android Things, we can even build our own custom devices, running Android. To demonstrate how nice it is to use Android for IoT / embedded devices, we will see how to build a few IoT projects and understand why using Android to build IoT products can be a smart move.
Intended Audience
Beginners and Intermediate Android developersYou developed a feature, tested it yourself - everything works well. You send it to the internal testing, your managers... And they say it is slow! We ran into the exact same situation and dug into the tools that may be used to make your Android app work on 60 frames per second. This presentation is intended for the people who haven't dived into the UI performance yet. You will see some examples of easy and fast ways to check if your app works well and if it is not, how to find the potential problem. In the presentation, I will tell you about: How android renders views and why does it matter to you (DisplayLists, Choreographer, VSync, Render Thread - things that will be covered) How to understand that you have a problem (GPU profiling, SysTrace) How to get metrics about the current rendering speed (fps) of your app ( dumpsys gfxinfo, Systrace, HierarchyViewer) Some of our mistakes we made, how we found them and how we fixed them (overlaying Controllers (analog of Fragments), incorrect usage of RecyclerView with NestedScrollView How to easily find GPU overdraw and fix it (using GPU overdraw in dev settings and export view layers in HierarchyViewer or Scalpel to show you the ways to improve) How to be sure that the problem doesn’t regress (Android Vitals, dumpsys gfxinfo)
Intended Audience
People who have only a basic knowledge about UI profiling or doesn't have it at all. Developers who ran into the low-fps app problem who does not know how to start and what to measure.Firebase Realtime Databaseを使用したオブジェクトが複数端末を移動するアプリの作り方について、流しそうめんを題材に説明します。 Realtime Databaseは以下のケースで使用することが多いと思います。 ・チャット ・ユーザー/グループ管理 このセッションでは、少し変わったRealtime Databaseの使い方を提案します。 そうめんが複数端末で上から下に流れることを実現するには、端末間のアイテムの受け渡しが重要になります。 オブジェクトの存在位置をRealtime Databaseに保存し、端末間でバケツリレーすることで流しそうめんを実現します。 Realtime Databaseにデータの同期を任せることで、簡単に端末間で連携するアプリを作ることができます。 また、大量にアイテムをRealtime Databaseに保存した場合、ブラウザからデータが削除できなくなったときの対処方法など、アプリ開発でのtipsをお伝えします。
Intended Audience
・Firebase Realtime Databaseに興味がある方 ・端末間の連携に興味のある方 ・Androidアプリ開発初心者 - 中級者 ・変わったアプリを作るのが好きな方Cicerone is a lightweight library that makes the navigation in an Android app easy. Mainly, Android apps can be divided into two categories: Activity-based or a Single Activity (and some variations, as usual). What unites them - need for navigation from screen to screen. In this talk, I would like present you a lightweight solution of the complicated problem. In this talk, we will discuss: The problem of screen navigation in Android Common solutions and their drawbacks Ready frameworks (Conductor, Flow, Architecture Components Navigation) and why they don't fit any project Qualities we want to achieve (and how Cicerone fulfills them) Decisions that were made while designing the library How to use it Common examples of building the navigation in case of using Drawer Menu or Bottom Navigation Panel.
Intended Audience
People who are tired from the complexities of the in-app (and deep link) in Android and are looking for a testable and maintainable solution for navigation problems.“If I had asked people what they wanted, they would have said faster horses.” a message from Henry Ford’s that continues to resonate so many decades later.
Intended Audience
Working in a startup environment requires to respond and adapt to market and user needs quickly. Users usually do not know what they want and the market provides many hidden opportunities. The issue is only to discover them and apply. Moreover, it is not that easy: how would you know if users want that fancy feature, which you have been developing for the last month? How would we answer the question if the feature is valuable and everybody just stays in queue shouting, "take my money"? Lean startup approach suggests testing everything. In this talk, we want to focus on A/B testing. It is a well-known methodology and is heavily used nowadays for many digital products. We will go through the couple of successful tests we did and share some results. Besides that, I will explain how we did a setup for the mobile environment and how it enables us to run many A/B tests constantly.Wireless communications between devices are not only limited to Bluetooth and Wi-Fi. Thread is an IPv6 based low-power mesh networking technology for IoT products, intended to be secure and future proof. Thread is running over 6LoWPAN, which is natively supported by Android Things. This talk will be an introduction to LoWPAN APIs and the Thread network protocol, and it is especially targetted for the curious who have never heard about those technologies yet, but wish to know more about those through easy-to-understand explanations and demos.
Intended Audience
Intermediate IT levelUIテストを実装をおこなうための情報は増えてきています。 またUIテストでできることも増えてきています。 人がおこなっていた検証などをUIテストにおきかえたいといったケースもあると思います。 しかし、導入しようとして挫折したケースや、運用中にコストがかかりすぎてしまい頓挫したケースなどいろいろとあると思います では、実際にプロジェクトに導入をし、運用をしていくためにはどうしたらいいでしょうか? そこで本セッションでは、導入・運用時においてなにをやるべきなのかを整理して紹介します。 本セッションでは以下のそれぞれのフェーズに関して話す予定です。 ・導入前にやるべきこと ・実装中にやるべきこと ・運用前にやるべきこと ・運用中にやるべきこと これにより、どのフェーズの段階の人でも何かしらプラスになるセッションになると思います。 またこのセッションを聞くことにより、UIテストを効果的に用いれるようになるはずです。
Intended Audience
・UIテストの導入に挫折したことがある方 ・UIテストを導入しようと思っている方概要 IoTデバイスとスマホとの接続方式として採用されることが多いBluetooth Low Energy(BLE)。 Android 4.3(kitkat)でBLEのサポートが開始されて早くも5年が経過しました。 iOSのBLEに比べて何かと辛いところが多いAndroid BLEですが、BLEを使ったアプリやサービスは順調に増えており、今後もいろいろなIoTサービスの中で活用されていくことが予想されます。 この発表ではAndroidのBLEアプリ開発で遭遇するはまりどころ、解析方法、つながりやすくするために 試してみたいことなどを紹介したいと思います。 対象者 - BLEを使ったAndroidアプリを開発中またはこれから開発したみたい方。 - BLEを使ったIoTハードウェアのFWを開発している方でAndroid側の実装に興味がある方。 話す内容 - AndroidのBLEはどうして繋がりにくいのか? - つながらないときの解析方法 - つながらないときに試してみたいこと - おすすめBLEライブラリ紹介
Intended Audience
- BLEを使ったアプリの開発しているかた、興味がある方 - BLEを使ったIoTハードウェアのFWを開発している方でAndroid側の実装に興味がある方detekt はKotlinの静的解析ツール(linter)です。 linter や test などは CI で常に実行されるようにすることでその効果を最大限に享受することができます。 ほとんどのCIにおいて実行時にジョブの失敗を決定するのはコマンドの成否によります。 detekt のカスタマイズ性は非常に高く、detektコマンドを失敗させるタイミングにもロジックを組み込むことができます。 この発表では、そのカスタマイズと利用方法について CI 上で実行する際のポイントと共に紹介したいと思います。
Intended Audience
初心者向け/静的解析の導入を検討されている方Androidアプリを開発していると、以下のような経験をしたことはないでしょうか? 「アプリの動作重くない?速くしてほしいんだよね。」 「データ消費量やばくない?減らしてほしんだよね。」 「アプリの消費電力多すぎない?減らしてくれない?」 Google Play Storeに公開しているアプリであれば、ユーザーレビューでアプリパフォーマンスの指摘を受けることもあると思います。 私が開発しているヘルスケアのプラットフォームアプリは上記の問題が発生していました。 もちろん、パフォーマンスを改善するための方法論に関しては、Android公式ドキュメントやAndroid Perfomance Patternという公式動画でも丁寧に説明されています。 しかし、紹介されているツールの使い方が難しかったり、定量的かつ継続的な改善のノウハウには言及していません。 実践的なパフォーマンス改善に関しての日本語ブログは少なく、日本語ネイティブのAndroid Developerにとってラーニングコストも高い状況です。 更に、パフォーマンス悪化の原因は、複合的であり、何から始めればよいのかわからないことも多々あります。 今回のセッションでは、複合的な原因を分解し、アプリパフォーマンスの定量化と改善のための実践的な方法論を紹介します。 ついつい起こしがちなアンチパターンに関しても具体例を交えて説明していきます。 このセッションでは、小難しい話はなしにして、初心者でも実際にアプリに適用できる状態を目指します。 1. アプリパフォーマンスへの考え方 - アプリマルチスレッドの全体像(thread, handler, looper, service) 2. アプリのパフォーマンス測定の基礎(CPU, Memory, Network) - ツールを使いこなす(Android Profiler, Command Line Tool) 3. 定量化と継続的改善のための実装と数値の追跡方法 - データ通信量 - ANR対応 - 消費電力 具体的内容 1. Androidアプリケーションにおける、パフォーマンスに影響を与える要素について全体像を話します。 2. アプリのパフォーマンス測定のために必要なツールの紹介と使い方について説明します。 3. パフォーマンス改善のための具体的な項目について考え、踏みやすいアンチパターンの実装例とベストプラクティスについて説明します。また、アドホックな定点観測ではなく、継続的に観測していく方法に関しても言及します。
Intended Audience
- アプリパフォーマンスを向上させたいが何から始めればよいのかわからない人 - アプリパフォーマンスでの継続的な結果測定と改善方法が知りたい人 - パフォーマンスを悪化させるアンチパターンに関して具体的実装が知りたい人build.gradleのカスタマイズ、あまり補完が効かなかったり、エラー箇所が分かりづらかったりして、毎回苦労されていませんか?それ、Kotlinで解決しましょう。 2016年5月の発表から開発が続けられてきたKotlin Gradle DSLが、Gradle 5.0において1.0のリリースを迎えてプロダクションレディになりました。このセッションでは実際のAndroidアプリのbuild.gradleをKotlin化する手順を通じて、Kotlin移行するべきなのか、どの位手間が掛かるのか、移行するメリットは、といったトピックについてお話しします。 - Kotlin Gradle DSLの位置づけ - Kotlin化で嬉しいこと - 既存プロジェクトを移行してみる - よくある問題と対策
Intended Audience
普段build.gradleに手を焼いている方、Gradleプラグインを書いている方アプリのソースコードが巨大化・複雑化する中で、バグなく手戻りなく更に高速に開発を進めるために、テストは不可欠なものになります。テストに関する記事・発表が増え、実際に導入してみる機会も多くなってきたと思います。そこでこのような不安を感じたことはありませんか? "テストする項目はこれで大丈夫?" "なにか漏れているものはない?" "このテストコード読みにくくない?" 本セッションでは、まず初めにテストを継続的に書いていく仕組みとしてTest Driven Developmentについてお話しします。TDDはテストを先に書いてから実装をするもの、と思われがちです。しかし重要なことはそのサイクルに乗ることで前出の不安を解消しながら開発を進めることです。 そのあと実際に導入した経験を元に、TDDでAndroidアプリを開発していく流れを、どう考えながら行うかやtipsを交えながら具体的にお話しします。 テストに使うフレームワークについて、JUnit/Spek/Robolectric/Espresso等との相性も説明していく予定です。
Intended Audience
- TDDに興味がある - Android開発にテストを導入したい - テストを書いているが書いたものに不安を感じる - きれいにテストを書きたいDroidKaigi 2017 と 2018 でドメイン駆動設計(Domain Driven Design : DDD)に関する講演を行いました。本セッションはその続きです。 2017ではドメイン駆動設計とは何か、何をするのか、を解説し、戦略的設計について話しました。2018では gradle の module としてドメインの置き場を分けることでドメインを隔離できること、IDや数値や種類を値オブジェクトとして見つけ、Kotlin の data class や enum class として実装することを話しました。 今回は残りの戦術的設計(Entity や Service、Application Serviceなど)について解説し、実装の一例として Android Architecture Components と Kotlin の Coroutines を使った方法を紹介します。 ドメイン駆動設計の実装方法はドメインによって異なるため、既存のアプリ(Google I/Oアプリなど)を元にするか、ドメインを明示したサンプルアプリをあらかじめ用意することを予定しています。 これまで同様ドメイン駆動設計の内容については「エリック・エヴァンスのドメイン駆動設計」及び「実践ドメイン駆動設計」に準拠します。 本セッションはドメイン駆動設計の前提知識がない方にもわかるようお話ししますが、2017の講演内容をまとめたブログ http://y-anz-m.blogspot.jp/2017/03/droidkaigi-2017_9.html および2018の講演内容をまとめたブログ http://y-anz-m.blogspot.com/2018/02/android.html を読んでいただくことをおすすめします。
Intended Audience
Android アプリにドメイン駆動設計を取り入れたいと思っている方Kotlin Coroutinesの導入したくありませんか? Kotlin Coroutinesを実際にAndroidアプリへ導入するまでに必要となる知識があります。まず基本的な理解や、どの機能をいつどのように使っていくべきなのか、エラーハンドリング、ライフサイクルのハンドリングなどの知識が必要になります。 しかし現状でこの導入するための知識を一通り得るにはコーディング、コードリーディング、ドキュメントを調べる、などの作業が必要になります。 そこで本セッションでは、いち早く導入に至るまでの知識を身につけるのを目的に、説明してきます。 今回はCoroutinesのChannelなどについては話しません。説明する時に分かりやすくなるときは、内部実装まで踏み込んで話します。 内容(予定) * 入門Kotlin Coroutines - Kotlin Coroutinesとは - Kotlin Coroutinesの基本的な機能をコードを例に出しながら簡単に説明します。 - launch、async、withContextなどのコルーチンビルダー - coroutineScope、supervisorScopeなどの関数 - Deferred、CoroutineContext、Jobなどの主要なクラスとその概念 * 実践Kotlin Coroutines - suspend function vs async await - Androidでの実践的な書き方、coroutineScopeなど上記の使い分け - Androidのライフサイクルのハンドリング、エラーハンドリング - RxJavaを使ったプロジェクトの置き換え
Intended Audience
Kotlinは慣れているが、Kotlin Coroutinesはまだ経験のない初心者向け。 担当しているAndroidアプリに導入していきたい人向け。Androidアプリにおいて、デバイスセンサーの活用方法について話します。 デバイスセンサーはAndroidで鬼門になりやすい部分ですが、センサー利用のユースケース自体が少ないため実践的ナレッジが溜まりにくくなっています。 しかし、Android Wear、Android Things、その他のIoTや通信技術の発展で、ビジネス要件が多様になってきています。 Android端末内のセンサーのみならず、その他のセンサーデバイスやBLEとの連携を行うサービスが増加しています。 つまり、Androidアプリ開発者であっても、デバイス寄りの知識を習得する重要性が高まってきました。 デバイスセンサーとの連携においても重要な点は以下です。 - データの取得方法 - データの保持 - データの同期 - パフォーマンス 今回は歩数データについてのみ話しますが、端末内外問わずデバイスセンサーを利用する際に注意すべき内容を網羅しています。 アプリに歩数データ機能を組み込む際の課題ついて、以下のように詳細に掘り下げていきます。 * 歩数データ機能 - 歩数データ機能を持つアプリとしてRequiredな機能要件 - ドメイン固有な機能要件 * 歩数データ取得の精度 - Android Frameworkではないデバイスセンサーの仕様に依存する部分の理解 - Android OSによる制限(Doze, バックグラウンド制限)とOSごとの対策(Service利用法) * 歩数データの保存方法 - Local DB構成 - Local DBへの書き込みタイミング - Google Fitによるデータ購読 * 歩数データのサーバー同期 - アプリ内の他の機能との連携のためのサーバー同期(Push通知, JobScheduler, WorkManager) * パフォーマンスの注意点 - 歩数取得Service、Local DBトランザクション、サーバー同期タイミングのAndroid Framework的なお作法について
Intended Audience
・AndroidでSensor APIを利用しているが、メーカーの独自OS仕様や、デバイスセンサーの仕様に苦しんでいる人 ・AndroidでSensor APIを利用しているが、昨今のAndroid OSのバックグラウンド制限に困惑している人 ・AndroidでGoogle Fitの実践的方法が知りたい人Based on personal experience of using ReactorKit in iOS, which in my opinion is concise and easy to understand. I would like to share how unidirectional data flow can be achieved in Android. In this session I will try to explain: What is unidirectional data flow and the core concepts behind it. 3 basic components that we use to create Unidirectional data flow in Android: - View: Receives and displays State. - ViewModel: Receives Actions, communicate with Store, and emits State. - Store: Stores and updates application’s data, either online or offline. The concepts of Action and State: - Actions: Immutable payload that describe updates to State. - State: Represents the data that is being used at a point of time in the app. Using ViewModel to: - Receives Action from View. - Listens to Store’s updates using Rx. - Propagate State to View using LiveData. Benefit of using Unidirectional data flow - Testability - Predictability - Traceability - Debugging and Replay - etc
Intended Audience
Android developers with prior knowledge of: - Android Architecture Components, ViewModel and LiveData. - Reactive Programming. You can: - Implement clear and concise data flow, and - Adapt the pattern to your use case. - Make use of libraries that you are currently using.■概要 近年Androidアプリの設計に関する議論が盛んになってきています。 中でもMVVM(Model-View-ViewModel)設計は、Google製のライブラリAAC(Android Architecture Component)の登場によって以前よりも実装が容易になりました。 本セッションでは、AACを活用したMVVM設計によるアプリ実装を具体的なコードを用いて解説いたします。 使用するライブラリはAACのRoom, ViewModel, LiveDataの他に、DataBindingも使用いたします。 ■目次 - AACについて - Roomとは - ViewModelとは - LiveDataとは - サンプルアプリの設計をみる - アーキテクチャの設計図 - 各レイヤーの役割 - サンプルアプリの実装をみる - Repository層の実装 - UseCase層の実装 - ViewModel層の実装 - View層の実装
Intended Audience
- AACを用いてアプリ実装に挑戦してみたい人 - MVVM設計を用いたアプリ実装に悩んでいる人概要 最近ではメモをとるときに、紙とペンでなくスマートフォンやタブレットを使うことが多いかもしれません。 それでも「ちょっと計算したい」や「図を書いて説明をする」「お絵かきする」など、 ”フリーハンド” でやりたい時って意外に多いですよね? このセッションではこの "フリーハンド" をデジタイザペンを用いてAndroid端末上に実現する話をします。 発表内容(予定) - デジタイザペンについて - Androidでとれるタッチイベント - デジタイザペンでとれるイベント - Apple Pencil みたいなことがしたい - デジタイザペンを使ってでできること - デジタイザペンが上げるプロダクトの価値
Intended Audience
- アプリ内にフリーハンドする機能を作りたい人概要 「Rx と Kotlin Coroutines どっち使う?」 みたいな議論ありますよね。 「そもそもそんな議論が間違っている!」という意見ありますよね。 「結局何が正しいの?」って思いますよね。 そんな Rx と Kotlin Coroutines 役割を皆さんと考えていけたらいいなと思ってます。 発表内容(予定) - Rx について - Kotlin Coroutines について - イベント処理・非同期処理について - こんな時どっち使う? - Rx と Kotlin Coroutines の接続
Intended Audience
- Rx と Kotlin Coroutines の使い分けについて悩んでいる人 - Rx と Kotlin Coroutines について何となくでも知っている人## 概要 Λrrow (arrow-kt.io) を使った FP プログラミングで Kotlin をもう一歩だけ安全な開発にするためには。 ## 話すこと - 関数型プログラミングとは? - Arrowとは? - Arrow における DataType とは? - 理解しやすい Option/Either/Try/Validated の説明と実例 - Kotlin との親和性 - なぜダックスフンドが可愛いか
Intended Audience
Android開発経験者 犬が好きな人Flutter is the current trending technology for cross platform. Flutter's getting to attract mobile developers' attention, especially Android Developers, and some already have released applications. When you consider if you can use it in production, there should be many things to check. I'll talk about what I can give for your technical decisions. Topics are supposed to be the following. (Mainly Android Perspectives) [Topics] ・Whole Pictures (but concrete for techinical decisions) ・How Flutter Platform works and runs with Native Code ・How Flutter Rendering Mechanism Works ・Integration into Existing apps ・Development Environment ・Factors For Quick Release ・usage of libraries for basic app development ・http clients, serializations, view components, bindings, touch events ・release steps for both Android and iOS ・Deep dive into continuous development ・Basic way to write Flutter Test ・How to implement Plugins (There are so many cases where you can't find what you want in official)
Intended Audience
・Developers who want to know how Flutter works for technical decisions ・Developers who want to release Android app with Flutter ・Developers who want to know the practical issues for continuous app maintenanceデザイナーとエンジニアの距離を近づける Lottie 利用術 Lottie の登場により、エンジニアによる実装コストを抑えながらも デザイナーが意図したアニメーションをよりダイレクトに Android を始めとした各種プラットフォームで表現できるようになりました。 しかし、各種プラットフォーム上で Lottie ライブラリが実装されているとはいえ、 プラットフォームごとに Adobe After Effects のプロパティの対応状況は異なり 望んだアニメーションをマルチプラットフォームで統一的に表現できない場合があるなど、まだまだ課題は残されています。 また、アニメーションの制作をデザイナー側で完結しやすくなった反面、アニメーションの表現を修正していくたびに - AE でアニメーションを修正して Bodymovin ファイルを書き出し - Bodymovin ファイルをデザイナーからエンジニアへ受け渡し - エンジニアが新しい Bodymovin ファイルをアプリへ反映させる などの作業が必要となる場合があり、デザイナー・エンジニア間のデータのやりとりの回数が多くなってしまう問題が起こりえます。 そこで本セッションでは、 デザイナーやエンジニアの両方が、プラットフォーム間の特性を踏まえながらも より Lotiie の性質や仕組みより深く理解して利用できるようになるために そもそもどのように Adobe After Effects (AE) で表現されるアニメーションが Bodymovin ファイルに変換され、lottie-andoird を通してアニメーションを実現しているのか を解説します。 さらに、 Hyperion-Android と Lottie Dynamic Properties を用いて アニメーション個別にコードを書くことなくアプリ上の Lottie アニメーションの挙動を変化させていくことで AE 上での編集回数を減らしながら、より効率的にデザイナーとエンジニアがアニメーションのブラッシュアップを実現できるような方法を紹介します。
Intended Audience
- デザイナーとして Bodymovin, Lottie を利用している、もしくは導入を検討している方 - エンジニアとして lottie-android を利用している、もしくは導入を検討している方- 「ライブ視聴・チャット・課金要素・リッチなアニメーション・すごいジェスチャー」が1画面に収まったFatActivityを例にして、リファクタリングのBefore / Afterを紹介 - Android Architecture ComponentsとFluxを用いた、可読性にこだわったアーキテクチャの採用 - 他の画面と違うアーキテクチャの採用。画面によってアーキテクチャが違うことへの考え方
Intended Audience
- AACやRxに触れたことがある方 - FatActivityをなんとかしたいと思っている方- 14プロジェクト、ビルド回数50回/日以上のアプリたちのビルドログを1年以上取り続けた結果 - 150人以上の社員がいつでもアプリをインストールできる社内配信の仕組みを整備した話 - どのように上司を説得してCIの上位プランを通したのか
Intended Audience
- 気付いたらたくさんアプリがあったが、CI&CD環境に妥協している方AndroidでCIしてますか? 2018年現在では活用できるCIサービスが様々存在することもあり、AndroidのCI環境を構築することは特に複数人が開発にかかわるような環境では一般的なことになっていることと思います。その中でもAWS CodeBuildは1分単位の実行時間での課金体系、同時実行タスク数の制限が他サービスに比べてゆるい、など特徴的なCIサービスであることもあり、一度は導入を検討した方もいるのではないでしょうか。 しかし、AWS CodeBuildは特に他サービスとの連携周りの機能が貧弱なこともあり、様々な利点がありながらも導入されない、といったことが多いのではないかと思います。本発表ではAWS SAMを活用してAWS CodeBuild最大限に活用する方法について説明します。なお、本発表内のAmazon LambdaのコードはGolangを使用しています。 ## 発表内容抜粋 + AWS CodeBuildの特徴、利点 + 依存ライブラリ入りのDockerイメージを作っておくことでビルド時間を短縮する + SlackからCodeBuildをコントロールする + AWS SAMを活用してWebHookの仕組みを簡単に実装する + GitHubとSlackのWebHookを同一のコードベースで管理する + (おまけ)DangerをCodeBuild上で活用するためのハック
Intended Audience
AndroidのCI環境を導入したいと考えている方 AndroidのCI環境を使っているが、現在の環境に満足していない方 AndroidのCI環境にAWS CodeBuildを使っているが、活用しきれていないと感じている方昨今、ビットコインをはじめとする暗号通貨をアプリで用いる案件は増えてきており、ブロックチェーンやDApps(分散型アプリケーション)市場の成長により今後も更に増えていくと思われます。 Android端末上でトラストレスにビットコインの送付や着金などを行う方法としてSPV(Simplified Payment Verification)がありますが、これは実際にビットコインネットワークに参加する方法であるため、モバイル端末の過酷なネットワーク状況下で常時複数のピアとソケット通信をしければなりません。また、それに伴い通信量も通常のアプリと比べ大きくなってしまいます。 更には、ユーザのビットコインの秘密鍵をAndroid端末上でどのようにして安全に保持するのかという問題もあります。 本セッションでは、上記のようなビットコインなどの暗号通貨をAndroidで扱う際に発生する問題に対して、如何にして対処すべきかをbitcoinjと呼ばれるAndroidアプリでよく使われるビットコインライブラリの内部コードの解説を交えながら、実際のビットコインのウォレットアプリを作っている経験を元にお話します。
Intended Audience
・Android x ビットコインに興味がある方 ・暗号通貨に関連するプロジェクトに携わっている/携わる予定の方 ・アプリ内でビットコインを使ってみたいと思っている方 ・Android上で動くDAppsを作ってみたいと思っている方 ・アプリでどのようにしてビットコインを扱っているのか気になる方# 概要 Kotlin 1.3の登場と、JetpackはAndroidのアプリ開発に大きな影響を与えます。 このセッションでは、KotlinのCoroutine、Contract、Android KTXや、Jetpackによって実装が少しかわったArchitecture Componentsを使った実践的なアーキテクチャガイドを提供します。 # 内容 - Coroutines - Custom Contractと使いどころ - Android KTX - 高階関数、ラムダ、Sealed Class - LiveData / ViewModel
Intended Audience
- Androidアプリ開発者 - Kotlin利用者 - Jetpackが気になっている人 - アーキテクチャに興味がある人# 概要 Google I/OでアナウンスされたSlicesは、Google検索やGoogle Assistantを利用してユーザーエンゲージメントを向上することができる、強力な機能です。 Slicesはまだ日本語に対応していませんが、そのため準備をしておくためのチャンスでもあります。 Slicesがいかにしてその機能を実現しているのか、その内部実装を概観したうえで、ダイナミックでインタラクティブなSlicesの作成を学び、Slicesの日本での公開に向けた準備を開始しましょう。 # 話すこと - Slicesの内部実装 - Slicesとパーミッション - Slicesの作成方法 - Slicesの更新とユーザーインタラクション - SlicesとGoogle Assistant
Intended Audience
- ユーザーエンゲージメントを増やしたい人 - Slicesに興味のある人 - Jetpackの内部実装に興味のある人ARCoreのCloud Anchorsを使うと複数端末間で同じAR空間を共有することができますが、Cloud Anchorsが提供してくれるのはあくまで、どういう特徴点の部分にどういう姿勢でオブジェクトを配置するかというアンカー(目印)だけです。実際にARアプリとして提供する際には、そのアンカーのID、どのオブジェクトを配置するのか、アニメーションの同期...等々、様々なことを端末間で共有するための機能をアプリ開発者自身が実装する必要があります。このセッションではNearbyやFirebaseと組み合わせてどのようにそれらの機能を実装するのか実験してみた過程をお話したいと思います。
Intended Audience
- ARアプリを開発してみたいと考えている方 - AR空間を複数人で共有することに興味のある方 - ARCoreを使ってマルチプレイヤーのARアプリを開発したいと考えている方Android 9からWi-Fi RTT(Round-Trip-Time)に対応しました。 Wi-Fi RTTを使えばGPSの届かない屋内などの場所でも、Wi−Fiアクセスポイントとの距離から位置情報を取得することができます。 Wi-Fi RTTを使った屋内測位にはAndroidアプリだけでなくアクセスポイントなど様々な要素が登場します。 本セッションではWi-Fi RTTを使った屋内測位を行うには何を行えばいいか解説します。
Intended Audience
屋内測位に興味のある方 Androidアプリ作成の基本的な知識を持っている方 カンファレンスアプリを作っている方昨今、gRPC+ProtocolBuffersの注目度が増してきていますが、それでも通信処理はREST APIが広く採用されています。 そんな中、現在私達が開発しているアプリでgRPC+ProcolBuffersを採用する事になりました。 このセッションでは、実際の開発を通じて感じたgRPC+ProcolBuffersのメリットとデメリット、開発時の工夫や注意点をお話したいと思います。 API通信に対して問題を抱えている人やgRPC+ProtocolBuffersの導入を検討している人に聞いて欲しいです。 内容(予定) ・gRPCとは ・ProtocolBuffersとは ・Androidアプリ開発に導入する方法 ・開発を通じて感じたメリット・デメリット ・開発時に注意したい点 etc
Intended Audience
・Androidアプリの通信速度に問題を抱えている人 ・gRPC+ProtocolBuffersの導入を検討している人 ・サーバー・アプリエンジニア間でAPIの仕様共有に問題を抱えている人Flutterは、アプリケーションもUIもWidgetであり、アプリから各画面のUIまでが「1つのWidgetツリー」に集約されます。 このセッションでは、Flutterの基本クラスやメソッドを応用して、アプリ全体や画面単位で共有する(伝播させる)状態のツリーへの提供方法と、提供する状態を誰もが利用可能なグローバル公開にならないよう、不要なアクセスを制限する戦略の基本を説明します。 画面レイアウトの Widgetツリー内で、複数の 子Widget から参照が必要な状態があったと思ってください。 手軽さを優先して、状態を直接伝播するために Lexical scope を使った場合は、スコープが絶たれないよう1つのクラス内で、画面レイアウト Widgetツリーの構築定義をすることになります。 「Flutterのツリー定義コードは、ネストが深い」「状態がツリー内のどの Widgetからも変更可能」「ツリー内にビジネスロジックまで書いてしまう」という問題は、このようにして発生します。 Google I/O 2018 セッション「Build reactive mobile apps with Flutter」では、Widgetツリーへの状態伝播の手段として、InheritedWidgetクラスや scoped_modelパッケージが、bloc(Business Logic Component)導入のための基礎知識として紹介されています。 リアクティブなアプリを作るためにも、Widgetツリーへの状態伝播とアクセス制限の基本戦略は必要でしょう。 併せて動作確認に使用する、機能限定ですが横断的関心事を扱ってくれる(手軽に動作確認ログ出力機能などを自動追加する)、内製AOP(Aspect Oriented Programming)も、開発の一助となるよう提供したいと思います。
Intended Audience
Flutter初学者の方 Widgetツリー構築コードのネストが深くなってしまうことや、 ツリーからビジネスロジックを分離する基本を学びたい方。 InheritedWidgetクラスを使ってみたいが、 どのようなことに注意して、実装や応用したら良いのかを学びたい方。誰しもこういうアプリを作りたいなと思っても、時間がなかったり、制作を躊躇っちゃた人向けのセッションになります。 とあるイベントの1週間ぐらい前に個人アプリで作りたいと思いついたように思ってアプリリリースまでの知見を共有します。 どういう過程を経て、理解しつつアーキテクチャーの採用したのかなど。 アジェンダー 1.作りたいアプリの機能構成など含めた選定 1.1. 画面構成 1.2. やる・やらないの線引き 1.3. リリースするプラットフォーム 2. Flutterへの理解 2.1. ドキュメント確認 2.2. Widget/Pluginの確認 2.3. サンプルコードの動作確認 2.4. アーキテクチャー選定 2.5. アプリ作成 3.アプリリリース準備 3.1. 各サイズのアプリのアイコン作成 3.2. Store公開への準備 4.アプリリリース 4.1. 審査が通らなくて苦戦した話
Intended Audience
・Flutterを開発をしてみたい方 ・初心者の方KotlinはAndroid開発の現場を大きく改善しました。より簡潔で、安全で、楽しいものへと。 しかし、Android SDKはJavaで書かれており、アプリのコードとの境界面は、時に緊張に満ちたものとなっています。 Android KTXは、Android SDKを拡張関数でラップすることで、Kotlinでのアプリ開発をより簡潔で楽しいものへと変えます。 このセッションでは、Android KTXを概観し、提供されている拡張関数を見ながら、それらがどのようにしてあなたの開発を手助けするか見ていきます。 そのうえで、良い拡張関数とはどのようなものかを考えていきましょう。
Intended Audience
- Kotlinを使っている人 - 拡張関数に興味のある人 - きれいな拡張関数とはどういうものかに興味がある人2018年8月7日にAndroid 9.0 Pieにリリースされました。 日本でサポートしている端末は現状少ないですが、各キャリアでアップグレードが発表されており、シェア拡大することが予想されます。 現在開発しているアプリではminSdkVersion16で開発しており、21にあげていいのではという話が出ました。 エンジニア的には今すぐ上げたいという気持ちになりますが、ユーザーシェアのビジネス面を考えると難しいところがあります。 本セッションでは ・minSdkVersionを更新するモチベーション ・minSdkVersionを更新するメリット/デメリット ・今後のバージョンを上げる時の方針 についてお話します。
Intended Audience
・minSdkVersion21未満のアプリを作成している方 ・minSdkVersionの方針について困っている方 ・バージョンアップの背中を押されたい方■概要 D.R.Y(Don't Repeat Yourself)を信条とするプログラマの夢であるクロスプラットフォームアプリ開発。 Android/iOS 向けの "ネイティブ" アプリを開発できるツールとしては、古くは Titanium Mobile や Adobe AIR Mobile、現在では Xamarin, React Native や Flutter が知られています。 このセッションでは主なモバイルクロスプラットフォーム開発ツールが「どのようにして共通化を実現しているか」あるいは「共通化できない事はなにか」を解説します。 それらを踏まえて、Kotlin でクロスプラットフォーム開発ができるという事で大きく注目される Kotlin/Native とそれらがもたらす未来の開発エコシステムについて、私個人の予想を語ってみます。 ■登場予定の開発ツール * Titanium Mobile * Adobe AIR Mobile * Delphi * RubyMotion * Xamarin * React Native * Flutter * Kotlin/Native, Kotlin Multiplatform ■話さないこと * ゲームアプリ開発ツールについて * ガワネイティブ、Webアプリ開発ツールについて
Intended Audience
* Android / iOS 向けのネイティブアプリ + その他 でのアプリ開発を共通化したい方Java/Kotlin製のAndroidアプリにアバター機能を追加する際にUnityをaarのライブラリ呼び出しとして導入しました。前例が見つからず、いろいろな試行錯誤を繰り返し意図する動作を実現することができました。 本セッションでは ・なぜUnityを使うのか ・Androidから見たUnityの特性について ・AARでのUnityの呼び出し方 ・Android上で起こった問題と解決法 についてお話します
Intended Audience
・Androidアプリ上からUnityの呼び出し方を知りたい方 ・苦しんだ話が好きな方Flutterを活用することでAndroid/iOSのアプリを同時開発できます。Flutterはまだまだ歴史が浅いこともあり、Hello Flutterの次の1歩として、実際のアプリ開発はどのように進めていくのか?遭遇する様々な問題をどう乗り越えるか?効率的に開発を行うにはどうすべきか?など、多くの課題に遭遇します。 本セッションでは、実際に私がFlutterをプロダクションに適用する中で得られた知見(画面/レイアウト/プラグイン/国際化/開発環境/リリースほか)を、カンファレンス時点におけるベストプラクティスとして、デモを交えてお伝えできればと考えています。Flutterによるアプリ開発を、世の中でさらに加速させるとっかかりになるようなお話をできればと考えています。
Intended Audience
・Flutterアプリ開発に興味のある方(Flutter未経験でもモバイルアプリ開発の経験を有している方) ・簡単なFlutterアプリは開発したもののその次を修得したい方What do ProGuard, Multidex, Resource Merger and Realm have in common? Answer: All of these components owe key functionality to the Android Transform API. It is a centerpiece of the Android Gradle Plugin's internal architecutre, as it is responsible for processing intermediary build artifacts, and before the introduction of D8, it was even tasked with the bytecode transformation of Java 8 code for Android as well. To third-party developers, it offers a hook into the creation of an APK through a centralized concept, the Transform, which can inspect and modify classes or resources. Little documentation and a lack of accessibility to the topic have rendered the Transform API a "hidden gem" in the Android plugin infrastructure. This talk will explore the Transform API, and introduce the required steps to register a custom transformation for a given scope to the audience, in a live coding session.
Intended Audience
Attendees are expected to be familiar with the concept of a Gradle plugin, however they do not need to have prior experience writing a plugin themselves.JUnit 5 is the latest iteration of the famous unit testing framework for the JVM. With the advent of its release in 2016, a powerful model for writing test extensions was introduced, allowing for the augmentation of tests with new functionality. What used to be @RunWith and @Rule, has now matured into a much more versatile tool for developers. This talk will demonstrate and explore the capabilities of the JUnit 5 Extension Model. Listeners will learn to appreciate the ExtensionPoint API based on concrete examples, including: - Hooking into the test lifecycle; - Providing test method arguments through a ParameterResolver; - Test instance post processing
Intended Audience
As this is not an introductory talk to testing, listeners are expected to be familiar with the core concepts of unit testing in general. However, prior knowledge of JUnit 5 in particular is not required, since the relevant API is introduced as it becomes necessary throughout the talk.Androidアプリのリリース後に絶対にバグを発生させたくない機能のひとつが「ログイン機能」ではないでしょうか? そのような事態を未然に防ぐには、リリース前にログイン機能を自動テストするのが効果的です。 一口にログイン機能と言っても、ユーザーIDとパスワードを入力するものや、GitHubやTwitterなどに認証・認可を任せるOAuth2などが有ります。 前者のテスト自動化は有効なユーザーIDとパスワードを用意すれば比較的簡単に実現できますが、後者はどうでしょうか? AndroidアプリがOAuth2の認証・認可の仕組みを使おうとすると、一時的に(WebViewではない)ネイティブブラウザを操作する必要があります。そのためには 「Androidアプリの操作途中で一時的にChromeネイティブブラウザを操作する」 というシナリオを自動化する必要があります。 本セッションでは、Appiumでこのようなシナリオを実現する方法を解説します。 具体的なトピックは次の通りです。 ・Appiumの簡単な紹介 ・Appiumで操作対象をWebViewに切り替える仕組み ・Appiumで操作対象をChromeネイティブブラウザに切り替えようとしたときの問題点と解決方法 ・Chromeネイティブブラウザをネイティブアプリの1つとして扱う ・Chromeネイティブブラウザ内の操作したいUIコンポーネントを特定する ・Chromeネイティブブラウザをスクロールして操作したいUIコンポーネントを見付ける Appiumでネイティブアプリの操作途中でWebViewを操作する方法は様々な箇所で解説されていますが、Chromeネイティブブラウザのケースについての解説は見あたりません。 Chromeネイティブブラウザをネイティブアプリの1つとして扱うことで、制限付きながら操作はできるのですが、画面外にあるUIコンポーネントをスクロールして操作するのはとても大変です。 本セッションを聴いて、Chromeネイティブブラウザを途中で起動するようなテストも自動化してしまいましょう!
Intended Audience
「Androidアプリ→Chromeネイティブブラウザ→Androidアプリ」と連携するシナリオを自動化したいものの、方法が分からず諦めた方▶概要 Androidでリアルタイムに音声処理をする方法としてOpenSL ESとAndroid NDKを使った手法があります。 Android OからはOpenSL ESの代わりにAAudioと呼ばれるAndroid C APIが誕生しました。 今回はAndroid NDKを使って、より低遅延でリアルタイムに音声を処理する方法とそこでハマった部分についてご紹介したいと思います。 ▶内容 ・Androidのオーディオ関連のAPIのご紹介 ・Android NDKで出来ること ・Android NDKのパフォーマンスチューニングの手法 ・OpenSL ESとAAudioを使い、音声をリアルタイムに処理するアプリのデモと解説
Intended Audience
・Android NDKに興味がある人 ・Androidで音声を扱うアプリに携わっている人 ・Androidの音声周りに興味がある人Google Play Consoleにはアプリのリリースを行う際にいくつかのトラック(alpha, beta, production)を選択することができる。 また、2018年には新たにinternalトラックが開放された。 クックパッドアプリでは、これらのトラックを有効活用し、リリース自動化を行い、人間によるリリーススケジュールの管理をやめたときの話をする。 また、その際にぶつかった技術的制約などにどう対応したか、リリース自動化に向けて行った様々なTipsを紹介する。 - なぜクックパッドアプリは週次リリースを行うことを決めたのか - Google Play Consoleのトラック紹介 - 各トラックの違い、使い分け - リリース前レポートとは - 週次リリースを支える技術紹介 - fastlane, fastlane/supply - アプリのversionCode管理を自動化する
Intended Audience
- リリースフロー、リリーススケジュールを管理することに課題を抱いている人 - fastlaneによるリリース自動化に興味のある人近年、クロスプラットフォーム開発環境のひとつとしてReact Nativeに注目が集まっています。 2018年だけでも、React Native自体の大幅なアップデートや、react-native-domの登場、AirbnbのReact Nativeリプレイスなど、話題に事欠きません。 キャッチーな話題が多いReact Nativeですが、実際の開発まわりになると「触ったこと無いし、実際よくわからない」という方が多いのではないでしょうか。 そんな方に向けて、本セッションでは、React NativeとそのtoolchainであるExpoを用いたアプリ開発の実際について紹介します。 React Nativeを触ったことがない方が、実際にアプリを作るための足がかりになれば、と思っております。 ■目次(仮) - React NativeとExpoのそれぞれの概要 - React NativeとExpoを用いたアプリ開発の利点/欠点とユースケース - 利点 - 環境構築の容易さ、便利なライブラリ群、Build設定まわりの管理移譲、など - 欠点 - apkサイズ、OSS選定のつらさ、ネイティブ実装による独自拡張ができない、など - React NativeとExpoを採用できるユースケース - Hello, Worldから味わうExpoでの開発の雰囲気 - プロジェクトの作成 - 利用するエディタ - Reactの雰囲気 - Hot Reloading - など - 実際に開発する上で知っておきたいTips - TypeScriptの導入 - よく使われるライブラリの紹介 - ライブラリの探し方 - CI上でのBuildやテスト、配信 - パフォーマンスチューニングの基礎 - Over The Air - など
Intended Audience
- React Nativeを用いたクロスプラットフォームなアプリ開発に興味がある方 - Androidエンジニアの文脈で、React Nativeの良し悪しを知りたい方 - アプリエンジニアのリソースが不足しているチームでアプリ開発に取り組みたい方ある程度の規模の機能開発の場合、エピックブランチなどで開発しますが、チーム開発ではmasterブランチに頻繁に変更が入るので追随していくのが大変になることがあります。またテストのない既存の画面に新機能をそのまま追加実装するとデグレしやすくなります。 本セッションではフィーチャーフラグを用いて既存機能に影響を与えないように開発中のコードを随時masterにマージしていく方法を紹介します。また既存コードと分離することで新規コードはテスタブルで切り替え可能な仕組みにする方法を紹介します。 アジェンダ(仮) ・エピックブランチの利点・欠点 ・フィーチャーフラグとは ・FeatureBuilder導入 ・機能のON/OFFを切り替える ・機能のV1/V2を切り替える
Intended Audience
・複数人でチーム開発している方 ・既存コードへの変更少なく追加機能を実装したい方 ・新規コードをテスタブルにしたい方 ・ABテストを使った機能を実装している方サービスを立ち上げる際に、サーバを必要とせずスタンドアローンのモバイルアプリケーションだけで十分ということはほとんどないと言ってもよいでしょう。 従来であれば自分でWebアプリケーションを開発し、クラウド環境にインスタンスを立ててAPIを提供していました。 Baas(Backend as a Servie), Faas(Function as a Service)としてのFirebaseを利用すれば、より簡単にサーバ側の仕組みを開発することが可能となります。 本セッションではFirebaseのパワフルな機能を、そのクライアントとなるAndroidのコードとともに紹介します。 主に扱うFirebaseの機能は下記のとおりです。 * Firestore(NoSQLデータベース) * Cloud Storage(ストレージ) * Authentication(認証) * Cloud Function(イベント駆動コード実行基盤) * Cloud Messaging(通知)
Intended Audience
Androidの基本的な知識 Kotlinの基本的な知識ARCoreやSceneformを利用する事で、3Dを専門としていないエンジニアでもARアプリの開発が容易に行える環境が整ってきました。 私自身も3Dの知識が全くないところから、画像を認識して3Dオブジェクトもしくは動画を流すという機能を既存アプリに追加することができました。 もちろん「3Dの知識が全くないままできる」という訳ではないので、初心者がAR開発を初めて苦労した点や、メインで使用した「Sceneform」「Argumented Images」などについて共有したいと思います。
Intended Audience
Androidアプリ開発者で、ARCoreを使用した機能に興味のある方プログラミング経験1年弱の21歳のカップル二人のAndroid開発の経験談 プログラミング未経験からmapアプリを作った経験談と未経験から企業に入り学んだことを二人で喋ります♡
Intended Audience
・これから開発を始めようかと考えている初心者 ・社会人全般 ・初心に帰りたい人 ・カップルエンジニアを見たい人近年注目を集めるGraphQLをKotlinで学ぶセッションです。 そもそもGraphQLとは何か、どういう課題を解決できるのか、という基本的な話から始まり、その仕様や文法を駆け足で紹介します。 後半はKotlinでの実装の仕方をクライアント、サーバーともに解説します。 クライアントにはKotlinによるAnroidアプリを想定し、サーバーサイドもKotlinで実装します。 Kotlinならではの工夫しやすいポイントやハマりやすい罠も紹介できればと思います。
Intended Audience
Androidの基本的な知識 Kotlinの基本的な知識In the case of feature development, we will develop it with Epic branch. However, in team development, it is difficult to follow along because the master branch frequently changes. If you add the new feature as it is to existing screen without testing, it will be easy to degrade. In this talk, I will explain how to merge the code under development to master at any time so as not to affect the existing function by using the feature flag. Also, I will explain how to make the new code a testable and switchable by separating it from the existing code. Agenda (tentative) · Pros/Cons of Epic branch · What is a feature flag? · Introduce FeatureBuilder · Toggle feature ON / OFF · Toggle feature V1 / V2
Intended Audience
People who - develop with multiple people - want to implement additional feature with few changing to existing code - want to make new codes testable - implement feature using AB testAndroidの初回リリースから10年を経た現在、当時からは考えられないほどの様々な端末やプラットフォームがサポートされるようになりました。 OSの進歩に伴ってアプリそのものも高機能なものとなり、複雑化したアプリ開発をサポートするツールや技術も格段に進歩してきました。 また、個人に依存したアプリ開発からチームでの開発が主流になり、「チームの中でのAndroidアプリエンジニア」としての振る舞いが求められるようになったと感じています。 本セッションでは現状の最新技術をベースに、2019年のAndroidアプリエンジニアとしての基礎知識・共通言語を身につけるための方法や求められる振る舞いについて話したいと思います。
Intended Audience
・これからAndroidアプリ開発を学ぼうとしている方 ・Androidアプリ開発についてもっと学びたい方 ・チームでのAndroidアプリ開発に悩んでいる方「Android公式ページのOpenGL ESチュートリアルは一通り試したけど、実際にアプリを作るにはどうすればいいんだろう?」とお悩みの方はいませんか? 本セッションでは、OpenGL ESを使ってアプリを開発する例として実際にお絵かきアプリを作ります。 チュートリアルで作るタッチイベントで三角形を回転させるサンプルをスタート地点に、以下の機能を持つお絵かきアプリの作り方を紹介します。 * なめらかな線を引ける * 複数のブラシが使える * ブラシの太さが変えられる * ブラシの色を変更できる * 描いた絵をエクスポートできる また、セッション内容の再確認やオリジナルのお絵かきアプリを作る参考として活用していただく目的で、作成したお絵かきアプリはソースコードを公開する予定です。
Intended Audience
お絵かきアプリの作り方に興味がある方、OpenGL ESを使ったアプリ開発に興味がある方を対象としています。絵文字がUnicode規格として正式に導入されてからというもの、今や世界中で利用されるなど、テキストコミュニケーションにおいてその役割は年々増加しています。 Unicode Emojiの規格(UTS51)は毎年改定され、その都度新たな文字や規則が追加されます。仕様は複雑化しており、今後もその傾向は続くでしょう。 そのためAndroid OSのバージョン間で差異が発生し、下位互換が必要になります。そのようなUnicode絵文字に関する様々な罠と対処法、メンテナンス性を高めるための設計戦略についてお話します。 目次(案): - 絵文字テキストレンダリング概論 - テキストレンダリングについて - その中でのUnicode Emoji処理の位置づけ - UTS51の解説 - Emoji Sequence - Grapheme Cluster - Presentation Style - AndroidにおけるUnicode Emoji処理の実装戦略 - Unicode Emojiの文字列処理 - EmojiCompatの概要と利点 - カスタム絵文字フォントの利用
Intended Audience
- Unicode Emojiを入力/表示可能なアプリの開発者 - OSやアプリを跨いだ際にUnicode Emojiがなぜ頻繁に壊れるのか気になるAndroidエンジニア - Unicode Emojiが豆腐にならないようにするためにどうすればいいか知りたいAndroidエンジニア多くのスマートフォン向けのアプリはAndroidとiOSの両OSに対応することになると思います。 その際に両OSの採用しているアーキテクチャが異なっていると実装上の差異が生まれやすく、バグの温床になったり無駄な工数がかかってしまうことが多いです。 そこで、誰もがクロスプラットフォームによる開発を夢見るわけですが、既存のアプリをいきなりReact NativeやFlutterなどのクロスプラットフォームへ移行するのはリスクやリソース不足もあり、なかなか実現するのは難しいです。 弊社では両アプリのアーキテクチャをClean ArchitectureとMVVMに揃えることで問題を解決することにしました。 その際に両OSのエンジニアがこのアーキテクチャの実装やガイドラインを整えたのですが、言語や使用しているライブラリによる認識のズレがあり、細かいところでの議論や調整が多々ありました。 今回は両OSでアーキテクチャを揃えるにあたり、KotlinとSwiftの違いやRxJava2とRxSwiftとの差異によって、どのような実装の違いが出てくるかを解説します。 また、将来的にどのようなアーキテクチャに移行していくと両OSの開発がよくなっていくのかを考察していきます。
Intended Audience
アプリのアーキテクチャに興味がある方 既存のアプリのアーキテクチャを変えたい方 AndroidとiOSのライブラリ等の違いに興味がある方When your team is 1 or 2 engineers, having properly configured CI might be not needed. When you have a big team of more than 100 engineers it’s a necessity. But what about the middle size team with 10 to 20 engineers?
Intended Audience
Did you ask yourself how to keep a good pace reviewing pull requests and getting them merged quickly? How not to have many conflicts with each other? How to have a good test coverage with instrumentation tests and run them fast? How to have app releases constantly and not spending hours on it? I can assume that at least one question popped up once in a while. I this talk I would like to share our experience with CI and CD and how we have effectively adapted it to our needs. The topic will include proper setup of CI for assembling builds and running tests, speed up integration tests using 3rd party tools and automated merging process. An additional interesting subject would be how we have achieved releasing an app update every week just in 2 clicks. So, at the end developers are focused most of the time on product needs and have all routine automated. This talk will be useful for engineers who are planning to scale their teams and improve development and release setup. Join my talk if you want to reach a new level of performance of your team.Google I/O 2017 で Android に Kotlin が正式採用されてからずいぶんと時間が経ち、その間に Kotlin の機能を活用したライブラリも登場してきました。 Kotlin は DSL を作成することも意識して作成された言語であり、「Anko」や「Spek」など、Kotlin があってこそ実現されたライブラリもいくつか出てきました。 利用する側としてみると、これらは非常に簡潔で明快な API となっていますが、実装視点で見た場合に Kotlin のどのような機能で実現されているか把握している人は少ないのではないでしょうか? 本トークでは、Kotlin のテストフレームワークである「KotlinTest」を例にして、Kotlin のどのような機能でそれが実現されているのかを解説していきます。
Intended Audience
Kotlin の DSL を活用したライブラリや API を利用しており、それがどのように実現されているかについて興味がある人。あるいは Kotlin を用いて、独自の DSL を用いた API を実装したい方。APKファイルのサイズを小さくしようとしたらProguardを利用しての圧縮が一般的です。 ところが外部ライブラリを多量に利用しているとコード最適化していてもサイズが肥大していってしまいます。 特に多くのアプリ開発に携わる方は、様々な要求にも対応できるように機能を盛り込んだオレオレライブラリを作成する場合もあり、機能1つ追加したらAPKファイルサイズが10MB増えました、なんてこともあります。 開発するアプリ毎に使用しない機能のコードを削除したりして調整するのは、マニフェストファイルやbuild.gradleも編集したりと手間だったりします。 本セッションではそんな手間な部分をプロジェクトのモジュール化してビルドの設定のみでAPKファイルの軽量化する手法を紹介します。
Intended Audience
・モジュールの仕組みについて知りたい方 ・多くのアプリに携わる方で同じコードを流用しつつAPKファイルを軽量化したい方 ・アプリ毎に独自ライブラリの不要コードやパーミッション設定を削除するのが手間な方MotionLayoutはLinearLayoutやRelativeLayoutと同じViewGroupの1つで, アニメーションの実装に特化したレイアウトです. これまでも CoordinatorLayout や TransitionManager といった似たようなことを実現できるものがありました. さて, これらとは一体何が違うのでしょうか? そして, 実際に使いたい時, MotionLayoutを適用できるポイントを見つけるにはどうすればよいでしょう?また, それらを効率的に実装するためにはどうすればよいでしょうか? このように, MotionLayout自体は非常に便利ですが, いざ使おうと思っても難しいポイントがいくつもあります. 本セッションでは, MotionLayout の基本的な使い方から, 現場で使うためのTipsを紹介すると共に, デザイナーとの関係についても考えていきたいと考えています. それを踏まえ, 以下の内容を予定しています. ## MotionLayout とは - 概要と, これまでにアニメーションAPIとの違い ## MotionLayout を用いたアニメーション実装の流れ - 経験を元にした, 実装ミスが起きにくく変更に強い効果的な実装手順とファイル管理方法を紹介します ## デザイナーが考える理想のアニメーションを作るために - KeyFrameSet を用いることで, デザイナーがつくるモックと同等クオリティの実装をするための実践的なTipsを紹介します. - 自由自在なeasing, 複雑なレイアウト構造やカスタムViewにおけるアニメーションなど ## MotionLayout がつくるアニメーション実装の未来 - MotionLayout の登場によってアニメーションのための Java/Kotlin コードがほとんど不要になった今, デザイナーであってもAndroidのためのアニメーション実装ができるのではないでしょうか? - XML でほとんど記述できることが本当に良いのか - 将来的に登場予定である Motion Editor が起こす革命
Intended Audience
Android アプリ開発におけるアニメーション実装の現状とこれからを知りたい方 MotionLayout を使ってみたいが使いどころが難しいと感じている方 Android のアニメーション実装に興味があるデザイナーの方AndroidStudioの発達でAndroidの開発がよりよく快適になりました。 またそれに伴ってAndroidの端末自体のスペックも進化していきました。 アニメーション要素のないUXは開発者にとってもユーザーにとってもつまらなくて使い続けるのは難しいものです。 それらは本来楽しくて美しく、ユーザーがアプリを上手に使いこなすきっかけにするだけでなく、 スクリーンを生き生きとさせる不思議な力を持っています。 Androidには、比較的簡単にアニメーションを作成するのに役立つツールがあります。 このセッションでは、改めてAndroidのAnimationの各APIを振り返り、 いくつかの重要なアニメーションツールを使いこなす学びのきっかけになればと思います。 - プロパティアニメーションの作成 - オブジェクトの移動と非表示 - 繰り返しと反転のアニメーション - アニメーションのタイミングを調整する
Intended Audience
- Android開発を始めてまだ日の浅い初心者 - UIの実装には慣れたけどUXの実装に不安のある方 - Animationについてもっとノウハウを勉強したい方AOSPで公開されている標準メールアプリのメッセージ詳細画面では、HTMLメールの表示のためにWebViewが使われています。 この画面はWebViewの他にタイトルや転送ボタンのViewGroupがヘッダー・フッターとして並び、同時にスクロールする構成です。このレイアウトはどう実装すべきでしょうか? 一案として ScrollView+ViewGroup+WebView の構成を思い浮かべますが、これを実装すると思わぬ重大なバグが発生します。 このセッションでは、AOSPメールアプリでWebView+ViewGroupのレイアウトを実現するための驚くべき内部実装を詳細に解説します。 また、このレイアウト構成を応用して弊社ニュースアプリを最適化させた経緯についても話します。 これによりリアルな現場で繰り広げられた問題発見・原因分析・動作検証のフローも参考になると思います。 ※話さないこと ・AOSPのメールアプリにおけるメッセージ詳細以外の画面仕様について ・WebViewの内部実装について
Intended Audience
・WebViewとViewGroupを組み合わせたい方 ・AOSPのメールアプリにおけるメッセージ詳細画面の構成を知りたい方 ・ViewGroupが好きな方 ・直面したバグの検証方法を知りたい方When having to share code between iOS and Android, most companies choose C++. It is a well known language with very good tooling, but it also has a lot of pitfalls. For one, it is a very complex language. It also makes it really easy to accidentally introduce memory leaks or segmentation faults; especially if you're used to automatic memory management via a GC (Kotlin) or Arc (Swift). It also looks quite different from modern language like Swift or Kotlin. Now that we iOS developers got (mostly) rid of Objective-C, and Android Developers got (mostly) rid of Java, it feels archaic having to go back to a language with an archaic Syntax like C++. Rust looks and feels a lot like Kotlin or Swift, and it offers the same easy ways of sharing code as C++. In addition to that, Rust has a very safe memory management model, high performance, a way to do fearless concurrency, and a very rich package ecosystem. As a bonus, it compiles to WebAssembly, so the shared code could also be used in any HTML5 app. This talk showcases how one can share very performant cross platform code between iOS, Android and others by using Rust.
Intended Audience
People interested in sharing code cross platform. People interested in Rust, people that don't want to use C++. Also, comparisons between Kotlin and Rustマイクロサービスという開発手法が脚光を浴びて久しいですが、クライアントサイドから見ると複雑なものです。この複雑さを解消する手段の一つとして BFF (Backends for Frontends) という手法が注目されています。これはフロントエンドののためにマイクロサービスの情報を加工・集約するサーバーです。 FiNCはヘルスケアのプラットフォームとして30以上のマイクロサービスから成り立っています。その中心プロダクトであるFiNCアプリ (Android: Kotlin / iOS: Swift) は、多くの一般ユーザーの他、法人ユーザー、コンテンツ提供者、ダイエットの指導者など様々なエンドユーザーが利用し、機能も多く複雑なアプリケーションになっています。 この複雑さにより、Android/iOS間の複雑なコードの重複, パフォーマンスの低下などの問題が起きていました。これらに対処するために、クライアントサイドでのFiNCではAndroid/iOSアプリのためのBFFをKotlinで構築しました。そして、現在はクライアントエンジニアが自分たちでBFFの開発を進めています。 本セッションでは、主に以下の3点について紹介します。 1. 複雑なAndroid/iOSアプリ開発で起こった問題、それに対するクライアント/サーバーの包括的取り組みと、その中でBFFが問題をどう解決するのか 2. BFFの技術選定とその理由 (Kotlin, Spring Webflux, Coroutines, Protocol Buffers)、具体的な機能実装の例、その効果の計測 3. Future Planについて: 複雑なAndroidアプリにおけるユーザ体験・開発体験・素早い機能改善を維持するために、我々が取るべき技術戦略
Intended Audience
クライアントサイド開発者としてマイクロサービスの扱い方を理解したい人、サーバーサイド開発者としてクライアントサイド開発者の悩みを理解したい人 複雑なAndroid/iOSアプリ開発におけるコードの重複などに課題感を持っている人 Server-side KotlinやBackends for Frontendsに興味がある人Room は Android 向けのデータベース ライブラリです。2017 年の I/O で発表してから多くの開発者に受け入れられ、コミュニティーのフィードバックに基づいた機能強化も続いています。 このセッションでは Room 2.1 移行で追加した機能の詳細を解説し、既存の機能と組み合わせてどのように実用できるか紹介します。
Intended Audience
SQL の基本知識私はこれまで新規開発が多く、時代の流れととともに、MVC・MVP・MVVM・Clean Architectureを経験してきました。 MVC、MVP、MVVMではモデルの部分がイマイチどう設計していいかわかりませんでしたが、Clean Architectureを試してみて、いままでのモデルを方針に従って分割でき、わかりやすくなったと思っています。 また現在Flutterも盛り上がってる中、私もチャットアプリを作成中で、それをClean Architecture で実現しています。 そこで、本セッションではFlutterではどのようにクリーンアーキテクチャを実現するかをお話します。
Intended Audience
- Clean Architectureに興味がある方 - Flutterに興味がある方FlutterとはiOS/Androidアプリが作れるマルチプラットフォームフレームワークです。ホットリロードや豊富なウィジェットなどの特徴により簡単に高速開発することができます。 本セッションではAndroidエンジニア向けにFlutter入門の話します。AndroidにおけるView、Intent、非同期処理などをFlutterでどのように実装するかを紹介します。 アジェンダ(仮) ・Flutter概要 ・View、Intent、非同期処理・・・ ・Flutterアプリのリリース
Intended Audience
・Flutterに興味がある方アプリにアニメーションを加えることは、ユーザー体験をリッチにさせることに繋がります。私が担当したアプリではその為の手段として、デザイナーやiOSエンジニアも巻き込んで、Lottieの利用やShaed Element Transitionを導入しました。 本セッションでは、そこで得られた知見とその結果を発表します。 ・画面遷移時のShared Element Transitionの導入 ・Lottieを利用したお気に入りアニメーションの導入 ・導入してみて辛かったこと ・導入してからのこと 私が実際に導入してみて得られた知見や結果をまとめて共有することで、「アプリにアニメーションを入れてみよう」と思えるような発表にしたいです。
Intended Audience
・アニメーションを入れてみたいが何から始めれば良いか分からない人 ・初級者向けですChrome Custom Tabsを使うと簡単にそのアプリの一機能であるかのようにブラウザを呼び出すことができます。この仕組みはChromeだけの機能ではなくFirefoxなど多くのブラウザアプリで実装されています。 このセッションではChrome Custom Tabsで呼び出すことのできるブラウザアプリを作るというアプローチで、Chrome Custom Tabsの仕組みを通じ、アプリ同士を連携させるプロセス間通信の使い方についてじっくりと解説します。
Intended Audience
Androidアプリの開発経験のある方Can you explain Android security matters of which you have to be aware? I'll talk about the security-aware implementation of Android app in Kyash where I'm working for. Ex) The way to detect the falsification of the app, the important points for API (network) call. Androidアプリを作る時に、最低限気をつけるべきセキュリティまわりの実装について理解していますか? この発表では、ネットワーク通信時の注意点や、アプリの改竄の対応など、私の所属するKyashでも行なっている対策について体系立てて説明します。
Intended Audience
The people who want to develop security-aware apps or want to know the basic knowledge of Android security quickly Androidアプリのセキュリティに気をつけるべきアプリを開発しようとしている人、セキュリティについて手早く全体像を知りたい人Do you like DataBinding? I love it. I'm using DataBinding a lot in Kyash Inc where I'm working for. I know DataBinding has both pros and cons, you may not like it because of some cons. I'll talk about its pros and cons, why I love it, how it changes our development style, and the useful Custom Binding Adapters which I'm using in Kyash Inc. DataBindingを使っていますか?私の所属するKyashのプロダクトでは、DataBindingをフル活用しています。もちろんDataBindingには長所・短所があり、実戦導入をしていない人もいるでしょう。 この発表では、DataBindingのPros、Consをお話しした上で、DataBindingを使うとどのような開発スタイルになるのか、 また、実務で使っている便利なCustom BindingAdapterについて説明します。
Intended Audience
The people who doesn't know DataBinding well or who are thinking whether they should introduce DataBinding or not. DataBindingについてあまり知らない人、新しいアプリにDataBindingを取り入れようか悩んでいる人Google I/O 2018で紹介されたNavigation Architecture Componentはアプリ内の画面遷移をよりシンプルに記述可能になるライブラリです。SafeArgsを使えば型安全に値を渡し、画面遷移させることができます。DeepLinkもサポートしているため、 本セッションでは実プロダクトでNavigation Architecture Componentを導入した経験をもとに、使い方から気をつけることまでを発表します。 - Navigation Architecture Component Overview - 特徴について - 使い方 - ToolbarやBottomNavigationとの連携 - SafeArgs - 導入方法、使い方 - SafeArgsを使ったより安全な画面遷移 - 自前のクラスを遷移先に渡す - DeepLink - 使い方、内部実装 - Deeplink時にどのようにしてBackstackがつまれるか - Navigation Architecture Componentをより深く知ってみる - NavControllerのnavigateが呼ばれてから遷移するまで - Navigation Architecture ComponentとFragmentのLifecycleの関係 - Tips - LiveDataと併用したときに気をつけること - navigationのidの割り振り
Intended Audience
Navigation Architecture Componentの使ったことがない・使ってみたい人Getting started with Android Instrumentation (or UI) tests can be difficult: UI tests can be challenging to write, taking too much time and effort. Even after you have written them, they can take too long to run. As deadlines approach, we often skip testing in order to write code faster. How can we make our tests better? What if UI tests were easier to write? What if they actually helped us develop faster? At Simple we've architected our application and UI tests so that it's easy to do most development even while offline. This also lets us start new features before the backend services are finished. Whether it’s test driven development (TDD) or “test after” development (TAD?), let’s make life easier by writing UI tests while we develop. In this talk we will cover: - Architecting application code to be easier to test - Android Instrumentation testing using Dagger and Mockito - Integrating tests into your development process - Writing feature-focused tests that can run offline
Intended Audience
For people who want to write better Android Instrumentation testsDo you master Android theme? Do you set the view attributes in each styles or views instead of using `android:theme`? I'll talk about the attributes you can set in `android:theme` and touch Material Theming a little bit. AndroidのThemeを使いこなしていますか?本当はandroid:themeで設定できるものを、styleや各Viewのattributeで設定していませんか? この発表では、AndroidのThemeで設定できる属性について体系立てて説明します。Material Themingについても触れる予定です。
Intended Audience
The people who doesn't use Android thene effectively Androidのthemeをうまく活用できていない人Androidアプリ開発においてのアプリ内データベースはこれまでたくさんのサードパーティ製のライブラリに支えられてきました。 その中でも速度・インターフェイスの簡潔さから特にRealmは広く使われてきたと思います。 しかし、2017年のGoogle I/OではRoomと呼ばれる公式のオブジェクトマッピングライブラリが公開されました。 シンプルなSQLiteのオブジェクトマッピングライブラリを公式が提供ということでRoomは非常に注目を集めました。 そしてRoomの発表から1年以上が経ちました。その間には安定バージョンがリリースされ、既存のデータストアからの移行を考えている人もいるのではないでしょうか。Realmを使用してきた開発者の中にもRoomへの移行を検討している人もいるかと思います。 本セッションではそんな既存データストアの移行の話を、2年間の間、Realmを使用している実際のプロダクトの例をベースにご紹介します。 詳細な内容については次のような内容を予定しています。 ・なぜRealmから移行するのか ・なぜ移行先はRoomなのか ・移行計画の建て方 ・スケジューリング ・実際の移行計画 ・移行に際して調査したこと ・速度比較やRxJavaサポートについてなど ・既存設計にどのように組み込んでいったか ・既存の設計との比較、Roomを組み込んだ際のデータ取得周りの設計方針 ・Roomで大量データを効率的にさばくためのTIPS ・RealmとRoomでは実現の仕方が異なるケースの解決方法
Intended Audience
・Realmに限らず、Roomへの移行を考えている人 ・Roomをこれから使用してみようと思っている人 ・現在はRealmを使用しているが、Roomに興味のある人 ・ローカルデータストアの設計に興味のある人One of the best places to learn idiomatic Kotlin is the stdlib. Now I don’t mean just using the stdlib but going to the source, literally. In this session, we’ll look at some of the methods and tools inside the stdlib and dig into how they’re written to reveal intermediate to advanced language features, slick syntax and conventions, and high-level abstractions to help you write more fluent objects and interfaces. We’ll also take a few glances at the underlying bytecode to understand how and why the features work the way they do.
Intended Audience
Developers that are of beginning to intermediate level in Kotlin Developers that are trying to write more idiomatic Kotlin Developers that want to learn more advanced syntax and language featuresAppleのARKit登場後、GoogleもTangoに変わる新たなAR PlatformとしてARCoreを発表し、mobileAPPにおけるxR開発が急速に広がるきっかけをつくっています。ARCoreが登場する前は、AR SDKとしてVuforiaが広く使われていましたが、なかなかかんたんには利用できない時期もありました。そこでこのSessionでは、個人的な体験をもとに3年ほど前から現在までAndroidをめぐるAR開発環境はどのように変化してきたのかを振り返り、広く使われてきたVuforiaと最近対応端末を増やしてきているARCoreについて比較してみたいと思います。(ARCoreのTipsやBest practiceはほとんど取り上げない予定です。)
Intended Audience
AndroidでのAR開発に興味がある方 ARKit以前にAndroidでAR開発しようとした/していた方 開発言語にJavaを利用したことがある方Push通知はアプリ利用者に対する何らかのイベントの発生、フォローしている人の新着情報、あるいはサービスやアプリ内機能の宣伝など多岐に渡る用途で使われています。 Push通知の開発を始めると、サーバーサイドですべての通知を制御するかアプリ側で通知をフィルタリングするか、あるいは高速に通知を配信するためにはどうすればいいかなど、様々な悩みが出てきます。 Push通知は幅広い用途に使われるため、こうすればすべて解決!という設計はなく、ケースバイケースで適した設計を考えなければいけません。 本セッションでは、Firebase Cloud Messaging(FCM)を利用して、用途にあわせた設計をアプリだけではなくサーバーサイドも含めて考察します。 まずはFCMでできることをおさらいした上で、具体的な設計の話に入ります。 また、実際の例として発表者が業務で開発しているアプリにおけるPush通知の設計も紹介します。
Intended Audience
FCMでできることを知りたい方やPush通知をどのように実装するか悩んでいる方を対象としています。# 概要 Androidアプリを作っただけでiOSアプリもできればいいのに… Androidアプリエンジニアなら一度は思ったことがあるでしょう。 そんな欲望を叶えてくれるOSS Multi-OS Engine(通称MOE)をご存知でしょうか? MOEはIntelとMigeranが開発している100%オープンソースのクロスプラットフォーム用ライブラリです。 MOEを利用することで、View以外の部分をiOS・Androidで共通化でき、UIの組み立て以外は全てKotlinとAndroidStudioだけで済ませることが可能です。(なんとiOSアプリのデバッグ実行もAndroidStudioからできてしまいます) 嬉しいことにRxJavaやRetrofitなどおなじみのライブラリも問題なく使用することができるので、iOSのView部分以外は、本当に通常のAndroidアプリとほぼ同様に開発することが可能です。 日本ではあまり話題に上がらないMOEですが、海外ではフォーラムも動いており、水面下で開発が進められてます。(人気があるとは言い難い状態ですが。。。) 個人的にはもっと盛り上がることを祈ってしまうくらい良くできています。 本発表ではこのMOEを使って、DroidKaigi2018のAndroidアプリ を実際にiOS対応できるか試しつつ、基本的な使い方と、できること・できないこと、いいところ・悪いところを共有していき、皆さんがMOEを始める足がかりにしたいと思っています。 MOEユーザーを増やしたい! (DroidKaigi2018アプリがうまくいきそうにない場合他のサンプルアプリで試すことになるかもしれないことをお許しください) # 目次 ## Multi-OS Engineとは * 概要 * 基本的な使い方 * ここがすごい * できること・できないこと ## iOS対応させるには? * 全体の見通し * commonの作成 * Android側のコードの修正 * iOS側コードの作成 ## 一画面ずつやってみた ## まとめ
Intended Audience
・iOSアプリをなるべく工数をかけずに作りたいと思っているAndroidエンジニア ・全部Kotlinで書きたいAndroidエンジニア ・AndroidアプリのついでにiOSアプリを作りたいエンジニアIf you are into mobile development, you probably heard of Flutter. It's the new kid in the block and offers you a native cross-platform development environment. One of the biggest advertisements for the Flutter is "You won't say no to your UI/UX designer anymore" and one of the biggest reason for this is: Animations. In this talk we will go through, how you can create the widely used animations in Flutter by explaining the key concepts of it and of course, we will see some code :)
Intended Audience
It's for beginner and advanced developers who is into FlutterQRコードを読み込んで何かをする機能というのは様々なアプリでよくみます。 ただ、プロダクトに投入するには簡単なサンプルでは仕様を満たすことができないことが多いと思います。 実際にプロダクトにQR読み込み機能を実装した時、スキャンレイアウト・スキャンエリアを絞らなければいけないなどよく見るサンプルでは満たされない仕様がありました。 QRによく使われる ZXing ライブラリではその仕様を満たすことが難しかったため Googlde が提供する Mobile Vision を導入して解決しました。 Mobile Vision は Firebase MK Kit の一部で今後統合されることから ML Kit の使用が推奨されていますが基本的な使い方は同じなので Firebase ML Kit で解説したいと思います。 このセッションでは Firebase ML Kit を使って、以下のよくある仕様を満たしたQRリーダの実装を紹介します。 ・QRスキャンレイアウトをカスタマイズする ・QRスキャンエリアを絞った読み込みの実装
Intended Audience
・QRコードリーダをプロダクトに投入したい方 ・細かい仕様を満たしたQRリーダーを実装したい方OpenGL ESとは、スマートフォンなどの携帯端末に組み込まれている2D・3D CG用APIです。これを活用すると、高速な描画を実現することができます。 OpenGL初心者である私が、とある事情でフィルターを自前実装することになり、それを受けてOpenGLの基本的な部分を理解し、フィルターの実装までたどり着けた経験から、普段OpenGLに触れていない方でも「自分も出来るかも!」となる手助けをしていきます。 そんな本セッションでは、Camera2 APIから受け取ったテクスチャをOpenGL ES 2.0を介してフィルターをかける話をしていきます。最終的にカメラ等のInputに簡単なShaderを通して任意のフィルターを自前実装できるようになります。 フィルターをかけるにあたって必要なOpenGL ES 2.0のAPIやGLSL、Camera2 APIを介したInputなどについてご紹介できればと思います。
Intended Audience
Open GL ES初心者の方 AndroidのOpen GL ESに興味のある方 フィルターの内部実装に興味のある方2018年5月にAndroid Things 1.0がリリースされました。 まだまだ導入事例の少ないIoTプラットフォームですが、たとえば次のような点で開発者から支持されています。 ・Androidに慣れ親しんでいる開発者が使いやすい環境(IDEやライブラリ)が整っています。 ・開発言語にKotlinを使うことができます。 ・FirebaseやGCPと連携し、堅牢かつ柔軟なインフラを持ったアプリを開発することができます。 このセッションでは、Android Thingsの概要とアプリの開発方法、導入するメリット、実際のプロダクト例などをご紹介します。 ■発表すること ・Android Thingsの概要 ・Android Thingsアプリの開発方法 ・Google Cloud PlatformとAndroid Thingsの連携 ・Android Thingsを導入するメリット/デメリット ・Android Thingsを活用したプロダクトの紹介とライブデモ ■発表しないこと ・Android Thingsがサポートする個々のハードウェアに関する詳しい説明 ・一般的な電子工作に関する詳しい説明 ・Kotlinの言語仕様に関する詳しい説明
Intended Audience
・Android Thingsに興味のある開発者 ・IoTプロダクト開発に興味のある開発者現在、バージョン66以降のWebViewでは、Google Safe Browsingがデフォルトで有効となっており、フィッシングサイトなどの危険なサイトへのアクセス時に警告が表示されるようになっています。 もちろんそのままでも使えますが、WebView周りのクラスでは、Safe Browsingの挙動を制御するためのAPIが提供されています。 本セッションでは、Safe Browsingの基礎から、各APIの使い方を通して、WebViewを使うアプリをより安全にする方法をお伝えします。 なお、WebViewではありませんが、SafetyNet APIとして提供されているSafe Browsing APIについても触れる予定です。 【アジェンダ(予定)】 ・Google Safe Browsingの基礎知識 ・Safe Browsingを制御するためのAPI ・SafetyNet Safe Browsing API ・ユースケース 【話さないこと】 ・Safe Browsing以外の、WebViewでのセキュリティ対策 ・Safe Browsingの性能
Intended Audience
・WebViewを使ったアプリを開発している人 ・セキュリティに興味のある方Cloud Firestoreはモバイル開発に対応しているクラウドのNoSQLデータベースです。 Firebase SDKを使うことでオフラインファーストなネットワーク処理とデータベースプログラミングをクライアントサイドだけで実現できます。 本セッションでは私たちがFirebase と Cloud Firestore、Cloud Functionsを使ったサーバレスアーキテクチャで1つのAndroidアプリを開発した経験をもとに: - スキーマレスなデータベースにあわせたデータ設計 - 効率の良いCloud Functions の活用法 - データアクセス権限を設定するセキュリティルール - 呼び出しクエリの最適化。パフォーマンスチューニング - ハマりどころ。バッドノウハウ などを「アプリエンジニア自身が実装する」というコンセプトでお話いたします
Intended Audience
Firebaseやサーバーレスアーキテクチャに関心のあるアプリエンジニア。 新規アプリを少人数で高速に開発したいチームや、既存のクライアント/サーバーモデルを持つアプリとは違った新しい開発体験を求めている方。This talk will focus on building apps for the next billion. We'll explore the market of these late adopters of Android smartphones and the conditions that differentiates them from most of our current target audience (Data affordability, Device affordability and Linguistic barriers). We'll review the different steps taken by Google in bringing down the barriers including the introduction of Android Go. We'll discuss what Android Go is, why it was made, what changes it brings and its intended impact. We'll also cover the differences between Android Oreo (Go) and Android One and the impact of Android One so far since it's launch. I'd also like to share a few experiences of mine while building Gramseva: Kisan, an app for farmers to inform them of the latest agricultural commodity prices, help them decide whether to stock or sell their produce, help them bargain with vendors and offer them an easy way to share and access this information at all times. I also had a chance to interview a few farmers from a village in Kalchinna, Uttar Pradesh, India and hope to share my experiences with them. Then we'll look into a few steps we can take in building apps that are conscious of battery, memory, connectivity, localization and performance. The many considerations that developers need to take care while building apps for these smartphones and how the little things can make a difference. We'll explore tools we can use to profile our apps, simulate bad network connections and eventually optimize our apps. Alongside that, we'll also explore how to build Android Go compliant apps.
Intended Audience
Developers, Entrepreneurs and the like looking to build applications for farmers or late adopters of Android smartphones due to barriers in network connectivity, device affordability and linguistic barriers.アプリの画面のように起動し、ユーザーの選択でシームレスにChromeに移ることもできるChrome Custom Tabsや、ランチャーアプリから横スワイプするだけで表示されるGoogle Nowのように、UXを損なうことなくアプリ間を遷移するためには、場合によって通常のIntentによるActivityの遷移とは異なる方法を取る必要があります。 本セッションでは、上で挙げた2つのアプリを始めとした、シームレスな連携をしているアプリの実装がどのようになっているのかを紐解き、その上で他のアプリに画面を提供する方法について考察します。 ※ アプリ間連携のUX改善のために必要なAndroidの知識についての解説がメインであり、良いデザインについて解説するセッションではありません
Intended Audience
このセッションの内容の大部分はニッチ向きとなっています。その上で以下に当てはまる方にはよりお楽しみいただけると思います。 - 別アプリ同士の連携をまさにしようと考えている方 - AIDLを使ってAndroidのプロセス間通信を使ってデータのやり取りをした経験がない方 - ランチャーアプリとGoogle Nowがどのような仕組みで連携しているかについて知りたい方「Android公式ページのOpenGL ESチュートリアルは一通り試したけど、実際のところどういう仕組みで描画しているのかよく分からない。」とお悩みの方はいませんか? それを理解するためにはOpenGL ESの仕様を調べるだけではなく、GPUの仕組みも理解することが重要です。 OpenGL ESとGPUの両方を知ることで、バグの原因の予測方法・重くなりやすい処理などに対する理解も深まり、より良いアプリを開発できるようになります。 本セッションでは、基礎的なGPUの仕組みとして、CPUとの違いや画面に描画されるまでの過程、シェーダープログラミングの基本などを説明します。 また、その説明を踏まえてAndroid公式ページのOpenGL ESチュートリアルが何をしているのか、GPUのレベルも含めて紹介します。
Intended Audience
GPUの仕組みやOpenGL ESの基本を知りたい方を対象としています。As Android developers, we use many libraries in our apps. Today, you'll seldom find an app without AppCompat, Retrofit, or RecyclerView. But how do these libraries actually work? This talk will focus on some of the interesting internals that make some of our favorite libraries work.
Intended Audience
Prerequisite knowledge: how to write Android apps. Challenges the session aims to resolve: an explanation and understanding of how these libraries we all use actually work under the hood.Media playback in Android is always a challenge. Not only because of the huge eco-system (many device resolutions and hardware variants), but also the nature of Media playback itself: codec, media standard, drm, performance, etc. ExoPlayer made by Google is an elegant solution for many years. Though this issue has not been resolved yet, for years: https://github.com/google/ExoPlayer/issues/867 (How to use ExoPlayer in a ListvVew or RecyclerView?). I address this request as the main concern of this talk, as well as discuss about related problems one may faces while solving them. The talk will be tentatively organized as follow: - Quick intro about how Media playback is, in 2018. - Quick intro: what is ExoPlayer and how good it is. - Quick intro: what is RecyclerView and how good it is. - Quick intro: what are other 'scrollable' view like ListView and why people still use them and want to play video on them. - Why people want to make ExoPlayer works together with RecyclerView/ListView/etc? - A common blueprint (list of problem) to solve the problem and what is the concern? - Limited resource in infinite collection of item. - SurfaceView versus TextureView. - Single ExoPlayer instance versus more than one. - From collection view to fullscreen and back. - Activity's configuration change (not just rotation). - Anything else? - My proposal(s): a quick Demo (library name may included). - The proposal in detail: implementation and how it could solve the problem(s). - Other side-note about things one may not thought of. Future work. - Wrap up and maybe something else interesting (eg: bring MotionLayout to the game).
Intended Audience
People who are interested in Media playback in Android, or RecyclerView, or both.# 概要 Lottieを使用すれば、 複雑なアニメーションをInterpolator等を駆使せずに、開発コストを抑えて実現することができます。 また、他のプラットフォームでも共通のファイルを使用することができるので、 サービス全体の開発工数削減も期待できます。 本セッションでは、 そんなLottieの特徴や扱い方、そして実際にプロダクトに導入してみて、どのように運用しているのかをご紹介いたします。 # 内容 - Lottieの仕組みについて - Androidでの取り扱い方 - Lottieでできたこと/できなかったこと - Lottieを使用せずに実装して苦労した話 - マルチプラットフォームでの共通アニメーション機構
Intended Audience
リッチなアニメーションをプロダクトに導入したい方 Lottieの導入を悩んでいる方Learning to be more efficient on the command line is an investment with extremely high returns over time. This talk will cover a plethora of command line tips and tricks along with real world examples of how mastering the command line can save us valuable time as developers.
Intended Audience
All Android developers.The correct handling of timezones and locales is one of the most under-appreciated parts of software development. Commonly known as internationalisation (i18n), a lot of people underestimate the impact that getting it wrong can have for your users as well as your systems. Drawn from experiences with working on a global network of backend systems, websites and mobile apps in more than 30 locales for the last 10 years, this talk will start with an introduction to the concepts behind timezones and locales. We’re going to look at the history of time measurement and time synchronisation and how we eventually ended up with the global system of timezones of today. Today’s model is full of interesting and sometimes outright bizarre quirks and we’ll look at some of best and worst of them. From there we’ll look at idea behind locales and why cultural context is at least as important as a locale’s common collection of purely technical data such a number formats or text direction. After this, we’re going to talk about how our common runtime environments represent these ideas. Technical topics covered are: - How does the JVM deal with timezones and locales and in which way is this is handled differently on Android devices? - What level of support and libraries does the Android SDK offer for Java and Kotlin? - Ways to make your developer life supporting multi-lingual/-locale apps easier. - How can you survive a "WHAT? We have to support daylight-savings-time?" request? - Managing user expectations and dealing with changing timezones/locales at runtime - How can you support 30+ languages in the Play Store - and would you even have to? Eventually, we’re also revealing why a whole country skipped a day and what they gained from going through this effort. Stay tuned!
Intended Audience
All AudienceDoze、App StandbyなどAndroid OSはバージョンアップの度にバッテリー寿命を少しでも維持するための仕組みを追加してきました。 公式ドキュメントに「It is critically important that apps be as respectful of battery life as possible.」とまで書かれています。 我々アプリ開発者も、省電力化の仕組みを理解し、それに最適化されたより高品質なアプリをユーザーに提供することが求められます。 本セッションでは最新のAndroid 9(Pie)までにシステムが導入したバッテリー生存のための仕組みを網羅するとともに、省電力下の制限に従った実装、更に省電力なアプリを目指すための手法についてお話します。 - バッテリー最適化の歴史 - 省電力機能の詳細な解説 - 浅いDoze、深いDoze - App Standby - App Standby buckets - バックグラウンド実行制限 - 省電力機能の制限に従った実装手法 - Doze、メンテナンスウィンドウの理解 - AlarmManagerやJobScheduler、またはWorkManagerの活用 - Doze状態など特定状況下の再現と動作テストの手法 - 更に省電力なアプリを実装する
Intended Audience
- Dozeなどのシステム制限と向き合いたい開発者 - バッテリー消費に敏感なユーザーへも安心なアプリを届けたい開発者So - you’ve built an app. Now you think it’d be good to make some money with it and instead of only charging a one-off purchase price you’re maybe considering a free app with extra features. Or you might think about a subscription model to create an ongoing cashflow by selling a service. Depending on your actual type of projects in the Android-ecosystem you might never had the need to look into monetisation of an app. Welcome to the pleasure dome, you’re now dealing with the exciting world of in-app billing on Android. In a nutshell, it’s a Google Play service - implementation should be smooth and easy and super-straight-forward, right? RIGHT? Maybe there’s more to it than meets the eye. It already starts with Google’s nomenclature. There’s Android Pay. And Google Wallet. And In-app billing. And Google Pay. And subscriptions. Jeez - let’s start with sorting out all those different use cases once for all. Well, at least until Google starts their next round of product consolidation and renaming anyway. After we’ve dealt with that, we’re going to look at the actual in-app billing API, its different manifestations over time and which parts of them could become the quirks and pain points in your implementation. Part of this will be understanding what the differences between purchases and subscriptions are and how to specifically cater for subscription events such as cancellations, recurring billings and trial periods using a server-to-server API provided by Google. We will also have a look at other libraries, such as billingx or Register and see how they might be able to make your lives easier. Another big topic is managing your in-app products in Google Play. Approaching this setup from the wrong end might lead to a massive chain of follow-on work with regards to managing international pricing and product descriptions across a plethora of languages. An easy way to measure your success is provided by Firebase Analytics. After a sidestep into the integration of in-app billing with Firebase Analytics we’re going to have a brief discussion of edge cases such as in-app billing and WebViews, and potential legal implications of selling goods via Google Play.
Intended Audience
Intermediate-level, developers with 2-3 years+ experience.Rx(Reactive Exctension)はいまや当たり前に使われだしています。Rxは聞いたことがあるけど使ったことがない、使ったことがあるけど実はよくわかっていないかも、という方向けに、実践的なRx利用の話をしつつ、基本からおはなしします。
Intended Audience
Android経験ありのRx未経験者サーバーとの通信や定期実行など、非同期処理を実装したくなることはよくあると思います。しかし、「Android 非同期処理」などでググったところで多種多様な実装を紹介する記事が見つかり、初心者の皆様は迷ってしまうのではないでしょうか? 本セッションでは、非同期処理を実装する際に候補となるクラスやライブラリをまとめてご紹介し、どういうユースケースのときに使うべきか/使わないべきかを解説します。 話す予定のクラス・ライブラリ(予定) ・Thread ・Handler ・AsyncTask ・AsyncTaskLoader ・Service ・JobIntentService ・JobScheduler ・FirebaseJobDispatcher ・AlarmManager ・WorkManager ・RxJava ・Kotlin Coroutines
Intended Audience
初級者向けです。特に最近Android開発を始めたばかりで、非同期処理の実装方法で迷っている人向けです。Fladle is a gradle plugin that let's you easily parallelize your UI and Instrumentation tests on Google Cloud Test Lab. Learn how it is build under the hood and how you can use it to improve and scale your testing infrastructure in a cost effective way. https://github.com/runningcode/fladle
Intended Audience
Knowledge of CI systems and a bit of gradle is nice but optional.実業務開発・運用中によくあるAPI/Webの問題か、アプリの問題か、を解決するための通信周りのデバッグ手法について詳しくお話します。 アジェンダ: - WebAPIで問題があったときにどちらの不具合かを突き止める - SSL通信を改ざんして期待値の確認 - WebViewアプリデバッグテクニック - モックを使ったWebAPIテスト手法
Intended Audience
Android/iOS開発の経験があり、実業務でTCP/I通信周りで困ったことがある方。アプリの仕様が時間とともに大きくなるにつれて、 アプリ内に含まれるビジネスロジックもどんどん複雑・巨大になっていき もはや手がつけられない、こんな経験はないでしょうか。 この問題に立ち向かうにはどうしたらいいのでしょう。 もしかすると、ドメイン駆動設計を取り入れることで この問題を改善できるかもしれません。 このセッションのゴールは、ドメイン駆動設計を導入することで 実際にどのような効果が期待できるのかを参加者がイメージできるようになることです。 このセッションでは、ドメイン駆動設計を導入することによって 実際にどのような問題を解決できるのかの説明に重点を置きます。 また、開発の流れのイメージを持ってもらいやすいように、 ドメイン駆動設計を取り入れていないかんたんなサンプルアプリに ドメイン駆動設計を取り入れ改善する例について話します。 このセッションで話すこと • ドメイン駆動設計で何が解決できるのか • そもそもビジネスロジックとは何か • ユビキタス言語とは • ユビキタス言語を使うことのメリットは何か • ドメインモデルとは • ドメインサービスとは • ユビキタス言語を見つけてみる • ドメインモデルを実装してみる • 実装したドメインモデルを使って処理を組み立ててみる • 普段の会話と実装の間でフィードバックループを回す このセッションで話さないこと • クリーンアーキテクチャなどのアーキテクチャ自体の詳細 • 書籍「エリック・エヴァンスのドメイン駆動設計」にある各パターンの詳細な解説(セッションで話す内容の範囲のパターンについては簡単に説明します)
Intended Audience
• ドメイン駆動設計のメリット・デメリットについて知りたい方 • エリック・エヴァンスのドメイン駆動設計を読んでみたが、実際にドメインモデルを見つける段階まで進んでいない方 • ビジネスロジックを多く含むアプリを開発しているが、ドメイン駆動設計についてはよく知らない方 • クリーンアーキテクチャのユースケースをどうやって実装するか迷っている方Abstract: Just as Batman is (almost) everyone’s favourite superhero, Flutter should be every developer’s favourite mobile development SDK! If you haven’t tried it yet, oh boy you’re missing out on something really cool. Join me at GDG DevFest London, where I’ll make you fall in love with Flutter. Description: Flutter is an open-source mobile application development SDK created by Google. It is used to develop applications for Android and iOS by coding just once in Dart and deploying to both of these platforms. Flutter makes it so easy to build mobile apps without impacting the app’s performance. The app it produces is a treat for the eyes as everything is drawn right on the screen, pixel perfect! “Why do I need this when I already have React Native?”. I got that covered in this talk for you along with the following takeaways: Why coding twice is not productive anymore? A brief about how Flutter came into existence Flutter’s ability to keep the same performance as the native app Comparison with React Native and other cross-platform SDKs/frameworks Live coding, like you’ve never seen before Best resources to get started with Flutter By the end of this talk, you will be itching to write your first app in Flutter!
Intended Audience
Developers who already have some experience with Android/iOS development and would love to get more productiveMonolithicなAndroidアプリのmoduleを分割し、multi-moduleなアプリケーションを実現することは、最近のAndroid開発において重要な関心事として取り上げられています。Sansan株式会社が提供する名刺管理サービスEightのAndroidアプリケーションでは単一moduleであったアプリケーションのmodule分割を推し進め、現在では数十のmoduleで構成されるアプリケーションとなりました。 このセッションでは実際のアプリケーションのmoduleを分割した経験から、multi-moduleアプリケーションの有用性、効果的な部分とそうでない部分、ベストプラクティスについて説明します。 Multi-moduleアプリケーションの意義とは? * ビルドの高速化 * Kotlinとモジュールの関係 * クリーンアーキテクチャとの関係 * Dynamic feature module ただ分割するだけじゃだめ?multi-moduleで効果的にビルドを高速化するテクニック * 並列処理を効果的に行う構造 * Annotation processingやgradle pluginに気をつける * 高速化が効果的に行われないケース * Multi-module化によってビルドに時間がかかるケース アプリの設計とMulti-module化 * 横方向(レイヤ)でのmodule分割と縦方向(機能)でのmodule分割 * Multi-module化によりクリーンアーキテクチャを促進する * DIを利用してより効果的なmodule間の依存関係を構築する Multi-moduleアプリケーションを実装する * Multi-moduleでのgradleの設定Tips * 実装におけるハマりポイント * Multi-moduleとdagger2 * dynamic deliveryが可能なmoduleとそうでないmodule * moduleをまたいだ画面遷移の実現方法
Intended Audience
アプリケーションのmulti-module化に興味がある人 | アプリケーションのビルド時間に問題を抱えている人 | アプリケーションのよりよいアーキテクチャに興味がある人Beta版がリリースされて、さらに盛り上がりを見せているKotlin/Native。KotlinConf2018にいき、参加者たちからも熱い期待が寄せられているのを感じました。クロスプラットフォーム開発をKotlinで行いたい。そんな開発者の願いが現実になりつつあります。会場で一緒に手を動かしてアプリ開発をしてみましょう! 本セッションではKotlin/Nativeを使いライブコーディングし、簡単なAndroidアプリ開発を行います。どのようにKotlin/Nativeを使うのか説明し、開発の注意点やTipsを紹介します。 発表内容(仮) ・Kotlin/Nativeの仕組みの簡単な説明 ・開発環境の説明 ・ライブコーディング/デモ ・まとめ
Intended Audience
・Kotlin/Native初学者 ・Kotlin/Nativeを使って何か作ってみたい人 ・Androidアプリを開発している人 ・Kotlinでクロスプラットフォーム開発をしてみたい人リモートにある画像をアプリで表示する際、画像ローダー系のライブラリを使うことが多いと思います。 有名どころですと、PicassoやGlide、Frescoなどのライブラリなどがありますが、みなさんはどのような理由で導入したか覚えていますか? 本セッションでは、各画像ローダーの特徴をデモを交えながら整理していき、今プロダクトで使用しているライブラリが本当に最適なのか、見直すきっかけとなるような情報を紹介したいと思います。 ■主な内容 - 画像の読み込みパフォーマンスの比較 - 画像加工オプションの比較 - キャッシュ機構の比較 - ドキュメントの充実度の比較 - 上記以外にも検討中
Intended Audience
- 画像ローダーはデフォルト設定でなんとなく使っている人 - 今使っている画像ローダー以外のライブラリが気になっている人 - 主に初級〜中級向けの内容になりますDroidKaigi 2019 が開催される頃には Google Pixel 3 が無事に日本で発売されていて、開発者のリファレンス端末問題に一応の決着がついているはずですが、世の中の Android が搭載されたスマートフォンは多種多様であることに変わりありません。1 アプリを例に、どのような端末が使われていて、どのような問題が起きたかを元に、検証端末の選び方を考えてみたいと思います。
Intended Audience
1. 検証端末に悩んでいる人 2. スマートフォンが好きな人 3. どのバージョンの Android から対応すれば良いのか悩んでいる人現在の Appium による Android の E2E テストでは、主に UiAutomator が用いられています。 E2E テストでは、 API との通信や DB への書き込みなどの非同期処理が終了した後に、次の操作を行いたいという欲求が多々あります。しかし UiAutomator を用いた Appium によるテストではそれらをサポートする標準機能は存在しません。 Android の UI テストフレームワークである Espresso では上記の処理と同期をとることができる機能が存在し、適当なスリープなどで処理を待つ必要はありません。 Appium でも Espresso の機能を利用することができる Espresso Driver の開発が進められています。 本セッションでは、UiAutomator 及び Espresso Driver による Appium テストの仕組みと、Espresso Driver を用いることでの利点を解説します。 また2018年内に公開予定の “Project Nitrogen” による Espresso の変化で、Appium による E2E テストにどのような影響があるかを紹介します(Google の発表状況によって内容が大きく異なる可能性があります)。
Intended Audience
・Appium を E2E テストツールとして導入を検討されている方 ・Appium を用いて Android アプリの自動テストを行われている方Androidアプリを含むアプリ開発では機能の開発とリリースを素早く行う事が求められます。もちろん不具合も最小限に留めなければなりません。 開発速度と品質を両立する上で自動化されたテストとCI(継続的インテグレーション)およびCD(継続的デリバリー)は開発者の助けとなります。 本セッションでは、自動化されたテストを開発フローに組み込んでより効果的に実行するプラクティスを扱います。 CI、そしてCDをAndroidプロジェクトに導入し、開発からリリースまでのプロセスを統合的に管理する手法についてご紹介する予定です。
Intended Audience
・CI/CDとはなにか知りたい方 ・AndroidプロジェクトにCI/CDの導入を検討されている方 ・自動化されたテストをどう実行していくか戦略を知りたい方 ・開発からリリースまでのプロセスにどうCI/CDによる自動化を取り入れるかに興味がある方 ・CircleCIやBitriseのWorkflowをどう構築するかでお悩みの方近年、Googleのセキュリティポリシーがより厳しいものになって来ており、新OSバージョンにアップデートされる度に我々開発者たちはそれに伴う仕様変更を余儀なくされてきました。 ユーザー操作による権限の付与を経なければアクセスできなくなった情報や取得方法自体変わってしまった情報など、その都度最適な対応方法を模索して来たと思います。 特に2018年11月から、targetSDKVersionを引き上げなければGoogle Playへアップロード出来なくなった為、この対応に一喜一憂した方々も多いかと思います。 本セッションでは、各権限で得られる情報と付与する為に必要な手順、それぞれの情報を得た場合のメリットやデメリットなどを考察し、これらの情報の活用する場合に気をつけるべきポイントをお伝えしたいと思います。 ・使用履歴にアクセスできるアプリ ・ユーザー補助サービス ・他のアプリに重ねて表示 ・アプリの権限 ・システムアプリの設定変更 ・電池の最適化 ・バックグラウンドサービス ・提供元不明アプリのインストール
Intended Audience
・AndroidのOSバージョンアップに伴う仕様変更の変遷を知りたい方 ・アプリが取得可能なあらゆる情報を活用したい方Most Android developers use it every day, but what actually goes on under the hood of the Android Gradle Plugin? In this talk, you'll learn about AGP internals and answer questions like: -What's D8 and R8? -What is mergeResources and why does it take so long? -Why are there so many tasks? -How can I measure and speed up my builds? You'll come away with a better understanding of the toolchain which will make you a better equipped Android developer!
Intended Audience
Android users who use Gradle as their build system.In this talk we will explain how we are writing libraries in Kotlin and running them on Android and iOS. We will show how common code is run, do it can access native platform APIs, and how to configure the project to be compatible.
Intended Audience
Mobile Developer with a knowledge of KotlinAre you tired of decrypting the JUnit test that you wrote a few weeks back? Do you want to write nice, readable & structured tests that are actually fun to write and joy to read? If you have answered yes to at least one of the questions above, I have a solution for you. Join this talk and fall again in love with unit testing. We will cover: - Describe how Spek works - Comparison with JUnit - Sample tests for a project following a clean architecture pattern (data, domain & view layer)
Intended Audience
Every one of us should have our projects tested, so everyone should attend :)In this session, we'll discuss: - what is GRPC and why you should consider using it - what is Wire and how is it different from alternatives - what the latest Wire toolchain will provide the next generation of Android apps
Intended Audience
Mobile app developers who use APIs at scale前回に引き続き 個人アプリ開発においての 企画→開発→リリース→プロモーション→運営 に関わる 事実に基づく最新情報をお話させて頂きます 合わせて ・脱孤独 ・脱島国 に挑戦しつつ 得た知見やエピソードをお話いたします リラックスして聞いて頂ける内容となっております 以下、予定しているざっくりとしたメニューです --- 【Previously on 長尾session】 ■前回セッション3分間ダイジェスト 【飽和状態のGooglePlay】 ■今だからこその狙い目 ・技術勝負はコスト高 ・MaterialDesignは部分使いに限る 【一体どーしたGooglePlay】 ■某A社的様相を呈してきたGoogle in 2018 - 2019 ・日々容赦なく消されていく自作アプリたち ・長尾作"某映画の公式アプリ"も抹殺され心停止寸前 ・復活方法のご紹介 ■結構いろいろバレてます ・Google警察apkガサ入れエピソード 【VS ネズミ大陸 forever】 ■[訃報] 公式アプリついに登場 ■功を奏した、奏さなかったサバイバル施作 ■一体いくら儲かってるのか ・暮らしに役立つ赤裸々お財布事情 ■孤独でも大丈夫 ・アプリ内掲示板はFirebaseで 【脱孤独】 ■個人開発仲間は待っていても来ない ■うら若き未エンジニアをお教室に連行 ・企画〜リリースまで全面的にお手伝い ・開発者登録&新規リリース最新トラップ ■生まれたての開発者には ・言語は?ライブラリは? ・長尾流"はじめの一歩" ■ぴよっこエンジニアとのハプニング集 ・平均年齢差16歳のジェネレーションGAP ・続々と持ち込まれるWindowsPC&中華Androidとの格闘 ・社会人未経験'sのイノセントな発想 【脱島国】 ■マンツーマン英会話100レッスンを経て ・思いを伝えることは誰にでもできる ・ITカンファレンスパーティ向けフレーズ10選
Intended Audience
・個人アプリを作ってリリースしたい方 ・実際にあったGooglePlayでの削除事例、復活方法を知りたい方 ・プログラミング教育、エンジニア育成を視野に入れている方 ・英語をしゃべれないエンジニアからある種の勇気をもらいたい方Kotlin/Nativeを実際に触ってみたいという人に、開発環境導入から仕組みの説明、実際に簡単なアプリケーションを作成するところまで一緒に行うハンズオンです。会場で一緒に手を動かしてアプリ開発をしてみましょう! Androidアプリ、iOSアプリ、webアプリ、serverアプリそれぞれに対応して進めていきます。 ※参加人数に応じては当日説明対応しない可能性があります
Intended Audience
・Kotlin/Native初学者 ・Kotlin/Nativeを使って何か作ってみたい人 ・Androidアプリを開発している人 ・Kotlinでクロスプラットフォーム開発をしてみたい人Android開発で悩むことはいっぱいあります。そのたびに検索したり、リファレンスを見たりしますが、説明が不十分だったり、たまたま解決しただけで本質的には解決されてないことなどがあります。 本セッションでは、UdacityやCode Labを通してGoogleが提供している、実際に動くコードを元にAndroid開発で勘違いされていることや、あまり知られていないことを学びます。
Intended Audience
・Android開発初級者〜中級者 ・チーム開発をしていないAndroid開発者Fluxアーキテクチャを採用しているプロジェクトにAndroid Architecture Components を組みこもうと思った際に、いかにFluxアーキテクチャらしく組み込むか。 実際のプロダクトに組み込んだ例を元に解説します。
Intended Audience
- FluxアーキテクチャにAACを組みこみたい - Fluxアーキテクチャに興味がある - AACに興味があるAndroidアプリをローカライズする上での基本的な知識やTips等を紹介します。 - 基本編 - Androidアプリで複数の言語に対応する方法 - 設定言語による日付・時刻の表示のされ方の違いと対応方法 - 地域や国による数値・金額の表示方法の違いと対応方法 - Tips編 - 多言語対応するごとに増加し続けるstringリソースの管理Tips - プレースホルダー付きのstringリソースを扱いやすくするTips - 言語を切り替えても崩れない画面レイアウトを構築するためのTips 国外向けのアプリを開発している方に限らず、日本国内向けのアプリを開発している方にとっても、 アプリを多言語・多地域の方が使えるように対応していくことが今後(特に2020年に向けて)ますます重要になると思いますので、 そういった方々の一助となるようなセッションにしたいと考えています。
Intended Audience
- Android開発 初/中級者 - これから、多言語・多地域に向けたアプリを作りたい人 - 今あるアプリをローカライズしたい人Android で Redux アーキテクチャを採用する例が増えている昨今ですが、実装方法は様々です。一例としてはRxJava2による実装が挙げられます。 一方、Kotlin Coroutinesの登場によりRxJava2をCoroutinesでどう書き換えるかもホットなトピックとなっています。 そこで今回はReduxアーキテクチャをKotlin Coroutinesで実装してみて、RxJava2での実装との比較をし、両者のProsConsを明らかにし、来る未来のアーキテクチャとその実装を考えてみたいと思います。
Intended Audience
- Reduxアーキテクチャに興味がある人 - Coroutinesに興味がある人 - CoroutinesのChannelに興味がある人 - RxJava2からCoroutinesへの書き換えに興味がある人Qtは、クロスプラットフォームのアプリケーションフレームワークであるため、Android/iOS などのスマートフォンから、(趣旨からは外れますが)macOS/Windows/Linuxといったデスクトップ、はたまた組み込み系で使われるQNX/INTEGRITY/(vxWorks)などのRTOSまで、幅広い環境で同じアプリケーションを動作させることができます。UIの開発にはQMLというシンプルではあるが強力な宣言型の言語/環境を使いプログラミングの実演をしながらながら、そのパワーを説明したいと思います。
Intended Audience
- Android/iOS端末で同じアプリケーションを開発する必要がある方 - Qtは知っているけど最新の動向を知らない方私たちのチームでは、GraphQL を取り入れた開発を行っております。 その開発の過程で生じた問題を GraphQL のスキーマファーストな開発で乗り越える話をします。 具体的には開発において GraphQL の API サーバを開発し、Android のクライアントサイドを開発するはずが、 API サーバの開発を待たずして Android の開発準備が整ってしまいました。 このままでは Android 側開発者たちに待ちの時間が発生してしまいます。 これを解決するために Android 開発者とサーバサイド開発者ともに並行して開発するため、 GraphQL によるスキーマファーストな開発を実践してみた話をします。 - スキーマファーストな開発とは - スキーマファースト開発の実践方法 - クライアントサイド - サーバサイド(こっちは軽め)
Intended Audience
- GraphQL の概要をざっくりと知っている方 - GraphQL での開発を今後考えている方 - GraphQL でスキーマファーストな開発をどのようにするのか興味がある方Googleの主要なアプリやライブラリは、未だに6年以上前のAndroid 4.1をサポートしています。これはInstant AppやPWAのWebAPKインストール機能など、比較的新しい機能も含まれています。 本セッションではこれらの機能をGoogleはどのようにして提供・実装しているのかについて、興味深いものをピックアップして紐解いていきます。
Intended Audience
- サポートライブラリの深い実装に興味のある方 - しばらく古いAndroidバージョンと付き合っていく必要のある方