So you've got a Google Home device, some really cheap LED light bulbs, and wonder how you can integrate those seamlessly in your home, so you can simply talk to the Google Assistant to change the light color in your living room... That's what we will see today, first doing some slight retro-engineering with an Arduino to understand how those light bulbs work, and then creating an Android Things and an Actions on Google project to control those.
XamarinのMonoチームが開発しているプロジェクトのひとつに、Android StudioやXcodeから.NETやXamarinのライブラリを利用できるEmbeddinator-4000というものがあります。Xamarin.AndroidやXamarin.iOSを使わなくてもC#のコードが再利用できる仕組みです。 本セッションでは、このEmbeddinator-4000を使って、Android StudioからC#のコードを再利用する方法を説明し、またその技術的背景を解説します。 技術的背景の説明はある程度の技術知が必要かもしれません(monoやXamarinに関する前提知識はあまり求めません)。Android開発者が関心をもちそうなトピックは、Javaと他言語(今回の場合はMono/.NET)の相互運用の部分です。Xamarinの低レベルの仕組みもある程度解説することになると思います。 セッションの構成(予定) - Embeddinator-4000とは(Xamarin.Androidとの違いなど) - Embeddinator-4000の使い方 - 技術的背景の解説 - 組み込みmono - Androidとの相互運用
Have you ever got a crash because you did something wrong with a Fragment? I did, many times! Fragments are not easy to use, and many experts even recommend to avoid them. But what is the alternative? We tried Conductor, we liked it and I am going to show you what can you do with it. In this talk you will learn: The basics of Conductor: Routers and Controllers. Conductor and the new Architecture Components from Google. Navigation from Controller to Controller. Handling configuration changes with Controllers. Retaining views vs. recreating them. Running espresso tests on a single Controller. ...and of course everything in Kotlin! By the end of the talk you will want to start using Conductor on your next project!
近年のAndroidデバイスには多くのセンサーが組み込まれるようになった。Googleはこれらのセンサーを活用してActivityRecognitionというユーザーの行動認識APIをAndroidフレームワークで提供した。 ユーザーの行動を認識することによって、アプリケーションプロバイダは適切なタイミングで適切な内容のコンテンツを提示することができるようになる。 例えば車を運転中であれば、車やドライブに関する情報である。 このActivityRecognitionを実用的に活用するためには、その認識精度が非常に重要になる。誤認識が発生するとユーザー離反の原因となり得る。また、ActivityRecognitionのエンジン自体はブラックボックスとなっているため、改善が難しい。 このセッションではActivityRecognitionの基本的な利用方法を説明し、現状の認識精度を調べた結果を報告する。さらに、複数のセンサーデータをシミュレーションし、精度向上のヒントとなる情報を探る。最後に実用的なActivityRecognitionの利用方法を説明する。
Android アプリを使っていて「この機能どうやって作っているんだろう?」と思ったことはありませんか?また、数十MBのアプリに「いったい何が入っているんだろう?」と疑問に思ったことはありませんか? Android アプリの中身はわりと簡単に覗き見することができます。 このセッションではAndroid アプリのAPK の中身を覗き見する方法を紹介し、実際に中身を見てみます。面白い発見があるかもしれませんよ?
※Elastic = 伸縮自在な・弾力性のある [内容] Androidアプリ開発において生じる問題を解決するために行ったチームビルディングについて話します。 [対象者] ・Globalメンバー(英語ベース)を含めた多様性のあるチーム作りに興味がある方 ・中・大規模の組織で開発プロセス上におけるステークホルダーが多く困っている方 ・会社のiOSファーストの意思決定に困っている方 ・Androidエンジニアの採用に苦労している方 問題例) ・外国人メンバーとのコミュニケーション ・無名スタートアップにおける採用の難しさ ・iOSファースト ・ビジネスの成長 VS 技術負債解消
USB接続するアプリを開発した経験がある方はいらっしゃいますでしょうか?ほぼいらっしゃらないですよね。このセッションでは今後みなさんに役立つかどうかはわかりませんが、USB接続してデータのやりとりをするアプリを開発した時の事をお話します。 USB接続するための基礎的な部分をまず説明したのちに、実際にどのように開発・デバッグを進めていったか。ハマりどころについてお話していきます。 詳細な内容としては以下の通りです。 # USB接続を扱う時の基礎知識 ## Accessory modeと Host mode - 今回はAccessory modeでUSB接続するアプリを作りました ## 基本的な使い方の説明 ## USB接続周りの権限は特殊 # USB接続するアプリの開発 ## どんなUSB接続するアプリを作ったか? ## ハードウェアがまだ出来ていない時にどうやって開発していたか? ## USB接続しているのでデバッグが大変 ## ハマりどころ - ActivityでしかUSB接続を検知出来ない - 特定の機種でとある条件でUSB接続のイベントが飛んでこない - close処理を忘れるとUSBを抜き差ししないと二度接続が出来ない - 物理的にはささっているけど、USBのDETACHEDとATTACHEDが連続して呼ばれてしまう
Dialogflow(旧:API.AI)は自然言語処理を提供するプラットフォームです。基本的なDialogflowの使い方と、Android アプリにチャットボットを構築する方法をご紹介します。 対象者 - 自然言語処理をAndroidアプリに導入したい方 - 既存のAndroidアプリにチャットボットを導入したい方 - 自然言語処理が全くわからないけど使ってみたい方 内容 - 基本的なDialogflowの使い方 - Androidアプリに導入する方法
Android Auto は、Lollipop の登場とともに発表されたスマートフォンと自動車をつなぐ比較的新しい仕組みです。現在着々と市販車のカーナビシステムに組み込まれてきており、かつスマートフォン単体でも Android Auto が動作するようにもなっています。今後アプリが自動車内にいるユーザとのエンゲージメントを得るためには、Android Auto について知っておくことは大きなアドバンテージになるはずです。 本セッションでは、Android Auto そのものの概要やそのフレームワークがもつ API の紹介から、Android Auto が生まれる経緯を踏まえつつフレームワークがどのように構築されているか、Android Auto を支えている技術を深掘りして見ていきます。その上で、フレームワークを使うときの注意点やノウハウ、また注意点・ノウハウの Android Auto 以外での一般的な応用を考察します。
Do you want to send patches to Kotlin? Do you want to know what the best practise of Kotlin development? Do you want JetBrains to list your name in Kotlin blog? This is the talk for you! This talk will explain how to send patches to Kotlin (mainly Kotlin plugin) repository as an external contributor. The expected audience should know the followings: * Git/GitHub * Kotlin syntax The expected outlines are followings: * Setup development environment * Communicating with other developers * Developing one of Kotlin plugin features * Implementing unit tests * Sending a pull request After this talk, you will be ready to send pull requests to one of the best computer languages in the world!
自分の関わるAndroidのアプリ開発ではマルチモジュールな作り方を実践しています。 その中で得られた知見を共有します。 下記がagenda(仮)です。 - マルチモジュールに分けた動機 - メリット - デメリット - 技術的な実現方法 - ハマりポイント & 気をつける場所 - 途中からマルチモジュール化する - etc
■対象者 ・流行りにのってMVPっぽい設計にしたがあまりメリットが感じられていない人 ・MVPやCleanArchitectureを採用したがテストが書けていない人 ・設計やテストについて他社の事例や知見が知りたいと思っている人 ■概要 CleanArchitectureを採用し、なんとなくPresenterを作ってみたけれど、Activityとの役割が曖昧で、コードが二箇所に分散しただけでかえってメンテしにくくなってしまった...。そんなプロジェクトに心当たりのある方も多いのではないでしょうか? このセッションでは話者が数年間試行錯誤した経験を元に、Model-View-Presenterアーキテクチャを採用したアプリをどのように改善し、よりよい設計にしていくかについての知見を紹介します。 また、Presenterに対してMockitoなどを使ったテストを有効に書くための手法やTipsなども紹介したいと思います。 ■アジェンダ(仮) ・MVPアンチパターンと改善例 ・MVPでテストを書く ・Presenterのテストの書き方 ・テストライブラリを活用する ・テストのリファクタリング ・テストのガイドラインを定める ・Presenterを整理する ・ドメインモデルを厚くする ・テンプレートクラスを自動生成する
JUnit 5 constitutes the next major evolution of the most popular unit testing framework for programming languages on the JVM. JUnit has been embraced by developers for decades now, and continues to amaze with a revised architecture built from the ground up in version 5. This talk aims to give an introduction to the motivations, architecture and intricacies behind evolving beyond the well-known JUnit 4, and gives an overview of the new features provided by its successor. Attendees will come to embrace the versatility of aspects like dynamic test generation, new APIs for expressive test case declaration, as well as the elaborate backwards compatibility agenda enforced by JUnit 5, which allows for consistent and gradual migration for existing test suites. Finally, the advantages of early adoption for Android developers specifically are presented by introducing the audience to a third-party Gradle plugin, which enables any Android project to profit from what will eventually become the future de-facto standard for unit testing.
■概要 Android Wearでは、時計の盤面を変更することができます。その時計の盤面というのがWatch Faceと呼ばれるものです。 Watch Faceは、Android Wearを利用する上でユーザーの目に最も触れる機能です。 Android WearのWatch Faceは単純に日時を表示するだけではなく、歩数や天気などの小さな情報も表示できます。 このセッションでは、Android WearのWatch Faceに関連するAPIや、それを利用したWatch Faceの実装方法、そしてWatch FaceをPlayストアに公開する方法などについてお話します。 ■対象者 - Android Wearアプリ開発に興味がある人 - Android WearアプリのWatch Faceに興味がある人 - Androidアプリ開発をある程度やったことのある人 ■目次案 - Watch Faceとは - Watch Faceに関連するAPIについて - Watch Face API - Complications API - Watch Faceを作ってみよう - Android Wearアプリのデバッグ方法 - Watch Face APIを利用して時計を描画する - Complications APIを利用してWatch Faceに小さな情報を表示する - Watch Faceの設定画面を用意する - Watch Faceを公開しよう - Android Wearアプリ単体で公開する - Android Wearアプリを既存アプリのAPKに含める - Android Wearアプリの審査について
■対象者 ・Android初級者〜中級者 ■概要 アプリのユーザーにとって、通知はとても重要な機能です。適切なタイミングで適切な内容を出すことでユーザーの利便性を向上できる一方、過度な通知や見た目の悪い通知を出せばユーザーのアプリへの信頼を損なう恐れもあります。 Googleも通知を重要な機能と捉えているため、Androidの通知APIはOSのバージョンアップのたびに頻繁に更新が入ります。アクションボタン、スタイル、ヘッドアップ通知、スタッキング、チャンネル、etc。新しい機能がバージョンアップのたびに追加されるため、開発者が後方互換性を維持したまま通知機能を開発していくのは大変な作業です。Support Libraryでも一部応されていますが、実際にはバージョンごとに分岐を書かなくてはいけないことも多いのではないでしょうか。 本セッションでは、Androidの通知がどのような変遷を経てきたかを機能ごとに振り返るとともに、ICSからOreo※までをサポートするためにはどういう実装をすればいいか、どのOSの組み合わせて検証すればいいか、他にどこに気をつければいいかを解説します。 ※Support LibraryがICSより古いOSのサポートを切っているため、ICS以前の通知は本セッションのスコープ外とします。
このセッションでは、今からAndroidアプリ開発を始めるに当たり、2018年において必要となる基礎的な知識や学習のコツを網羅的に紹介します。 対象者はまだAndroidアプリ開発をした事がない初学者や、久しぶりにAndroidやってみようかなという人です。 簡単なサンプルアプリを題材にして、以下のようなトピックに触れます * Android アプリの基礎知識 & 用語解説 * レイアウト * 非同期処理 * ネットワーク通信 * 通知 * 主要なアーキテクチャ * テストとその自動化 * デバッグ方法 * 最低限必要となる各種便利ライブラリ * トレンドのキャッチアップ * etc... このセッションを通じて、スラスラとAndroidアプリが実装できるようなるわけではありませんが、Androidアプリ開発の学習を開始するに当たって必要となる最新の基礎知識を獲得することができます。
リファクタリング、ナビゲーション、ファイルの移動、ビルド・・・、マウスを使って操作していませんか? マウス、トラックパッドは窓から投げ捨ててしまいましょう。 Android Studioの知ってトクするショートカット、便利技100選を紹介します。 明日から開発速度が100倍くらいになる!かもしれません。 なおマウス、トラックパッドを処分する際は自治体の定める方法でお願いいたします。
Shame is the most powerful, master emotion. It’s the fear that we’re not good enough. Vulnerability is about showing up and being seen. It’s tough to do that when we’re terrified about what people might see or think. Brené Brown We live in a society that's motivated by comparison, in a culture in which everything you do is never enough, one in which you are constantly engaging with people using shame, either to shame or to be shamed, and in which making yourself vulnerable – exposing your fears and uncertainties, taking emotional risks - is considered a form of weakness, and something most of us want to run away from. But as an Android developer you cannot run away from being vulnerable. No matter your level, you will be constantly exposed, you are constantly vulnerable. With pull requests, stack overflow (questions or answers), blog posts, talks.. You are being vulnerable. Unfortunately that means you are also more exposed to being shamed, to being told off on how wrong you are, or how little knowledge you have. This kind of behavior can be toxic and can lead to people feeling insecure about themselves (hello impostor syndrome). It's not only you. This is something that affects all of us the moment we decide to be developers. And it has an impact in our growth, our jobs and the way we interact back with the community. I want to explore what shame and vulnerability really are, how we perceive it and how it affect us in the core of our interactions and our job. What makes Android developers vulnerable. Learn the tools we are already using to fight against shaming behaviour, and what we can do in our day to day job to make it even better. With this talk I want everyone to leave the talk knowing they are good enough, they are brave enough, and they can put a stop to toxic behavior we don't realize we do.
In this talk I'll show how you can increase developer productivity of your Android Teams by adding simple debug features to your app, hacking gradle and Android Studio to turn your Devs into Super Heroes who ship much better products faster than ever. Everybody talks about Design, Architectures, Libraries and what not, but, what we often forget is that most of the times quick wins for us as developers can be much more beneficial than tackling large refactors to use the latest technologies available so if we apply the 80-20 rule to our development workflow we can achieve so much more. People with any level of android experience can see this talk.
Managing states within the Android application is never easy; when you mutate something in one place, and/or another place, and somehow you want to share the mutated value in multiple places, then you find yourself lost and your value never becomes as you expected. In this talk, I'll talk about flux architecture as one of the solid solutions for managing states within Android application; by achieving unidirectional data flow, we aim to think less, focus more on feature development, and scale faster. I'll also show some example implementations with Flux architecture and try to explain pros and cons of choosing flux architecture for Android application development.
Hands on codelab to learn more about Android Things
特定用途に特化した専用端末は、Kiosk端末と呼ばれています。 例:ATM、切符販売機、店舗の予約受け付け端末など 本セッションではAndroid 5.0から追加されたDeviceOwnerを活用し、 下記の要件を満たすAndroidのKiosk端末化についてご紹介します。 * 通常操作では、専用アプリ(Kioskアプリ)以外の画面には遷移できない * 端末を再起動しても、強制的にKioskアプリが立ち上がる * 特定の手順を踏むと、Kioskアプリ以外の画面に遷移できる また、Kioskアプリ固有の問題とその対処についてもお話しする予定です。
Android上の開発は非同期の扱いを避ける事はできないです。ネットワーク、フレームワーク、ユーザの操作などから非同期処理が発生してます。油断してしまうとアプリが複雑化してメンテナンスが難しくなります。皆様はネットワークからレスポンスを待っている途中、ユーザが画面をローテーションしても問題ないですか?並行してユーザがいろんな操作しても大丈夫でしょうか? Model-View-Intent アーキテクチャは非同期処理が発生する前提で考えられたため、すべてがストリームとして扱ってデータの流れを一方通行にするかつ不変オブジェクトを使うのが MVI アーキテクチャの方針です。マルチスレッディングやAndroidのライフサイクルの対応から生じる問題がアーキテクチャによって解決されるおかげでアプリのロジックに集中できるようになり、コードが書きやすく、今後の保守も楽になります! 皆様が MVI アーキテクチャの強みを理解し自分で実現できるようにする目標で Kotlin と RxJava を使って並行処理、画面ローテーション、スナックバーを含んだ画面をどうやって作っていくかを語るつもりです!
AOSPにて公開されてるDataBindingのコードを読み、実際にどのような仕組みになっているか、デバッグ方法等を簡単に紹介します。 また、実際にパッチを投げた話も紹介したいと思います。 # 対象者 DataBindingに興味のある人 # 予定内容 * DataBindingの仕組み * DataBindingのデバッグ方法 * AOSPへパッチの送り方 * バグ修正した話
Androidの画面構築に欠かせないViewGroup。使い方は当然ご存じだと思いますが、レイアウトアルゴリズムがどのように実装されているかまでご存じでしょうか? このセッションではViewGroupのレイアウトの基本的な流れのおさらいと、いくつかの有名なViewGroupのレイアウトアルゴリズムについて解説します。ViewGroupの基本的な話は程ほどにし、内部実装について掘り下げた話をします。 注意:このセッションを聞いてもConstraintLayoutなどの使い方は学べません。 ■目次(案) ・Viewってどうやってレイアウトされているの? ・View#onMeasure ・知ればシンプルなMeasureSpec ・View#onLayout ・使おうgetMeasureWidth、getMeasureHeight ・FrameLayoutのonMeasure、onLayout内部実装解説 ・LinearLayoutのonMeasure、onLayout内部実装解説 ・weightの実現方法 ・ConstraintLayoutのonMeasure、onLayout内部実装解説 ・特徴的な各機能の実現方法 ■対象者 ・独自ViewGroupを作るのが好きな方 ・特にonMeasureやonLayoutをついつい自分で書いてしまう方 ・各ViewGroupのレイアウトを「特に」知りたい方 ・Viewのレイアウトを本気でチューニングしたい方
With the introduction of ARCore, applications can now easily deliver rich augmented reality experiences. In this session, you will learn how to add AR to your application, why and how physically-based rendering can be used to make the experience even more immersive.
■概要 Android4.4から導入されていたHCE(Host Card Emulation)ですが、イマイチ流行りませんね! 面白そうだけどとっつきづらそう。ICカードのお作法とか色々と面倒くさそう。そういったイメージも障壁になっているのではと思います。 ですので今回は細かいことは置いておいて「ケータイでピッとするやつ」ぐらいの認識でもサクッと作れちゃう!という気持ちにさせるようなセッションを目指します。 サクッと作れる人が増えれば面白い使い方を思いつく人も増えるのではという思いを込めて… ■アジェンダ(仮) HCEとは NFCってなんだっけ Androidアプリ with HCE *APDU等、ICカード周りの話題にはあまり触れない予定です ■対象者 Androidアプリ開発経験の有る方 HCEに興味はあるけど触ったことが無い方 ケータイでピッとするやつを自分で作ってみたい方
■概要: AndroidのJavaとOracleのJavaは微妙に異なると言われていますが、普段その違いを意識することはあまりありません。 実際、「だいたいJava6ぐらいかなー」って思っていればうまくいくことが多いと思います。 そこで今回は「全く同じJavaコードを書いてもOracleのJVMとAndroid Runtimeで異なる動作をすることがある」っていうのを紹介したいと思います。 題材にするのはよく使われるArrayListです。 ■対象者: JavaでArrayListを使ったことがある。 if文やfor文、拡張for文、Iteratorなど、Javaの基本的構文を書いた or 読んだことがある。 世界にはJavaコードから生成されたプログラムを動かす実行環境がたくさんあるらしい(OracleのJVM、Dalvik仮想マシン、Android Runtime) ことを知ってる。(これを読んだあなたはもう知っているので対象者です) ■目次 ・普通に書けば、普通に同じ動作をする ・ArrayListを拡張for文で回す←ここまでは同じ ・for文中にあることをすると・・・おおっと ・大丈夫なこともある? ・なぜ大丈夫なこともあるのか? ・Javaは不思議だなぁ。AndroidもJavaだもんね、同じことが・・・ ・ピュアJavaだと思った?残念Androidでした ・AndroidはJavaとAPIが同じなだけ ~いつからAndroidをJavaだと錯覚していた?~ ・ネタばらし ・もちろん逆パターンもあるぞ ・その他の事例もあるぞ(先駆者紹介) 注意:このセッションは好奇心を満たすだけで、明日使えるテクニックは何もありません
# 概要 Android端末に使われている CPU は多種多様にある。ARMアーキテクチャーとは?から、それぞれのメーカーが作った Snapdragon, Exynos, kirin, MediaTek などのCPUの性能の違いや歴史を話したいと思います。またスマートフォン端末ではあまり話に上がらないGPUについても話せれたなと思います。 # 話す内容(予定) - AndroidとCPUの歴史 - ARMアーキテクチャーとは - CPUの種類と性能差 - 最新スマートフォンの性能 - スマートフォンとGPU
#概要 Android Architecture Componentsは、Android特有のUIコンポーネントの複雑さに対処するために産まれたライブラリです。 Google I/O 2017で発表されたとたん、話題の的となったArchitecture Componentsですが、 いったいどのようにして、ライフサイクルイベントを拾い、各コンポーネントはどのように反応しているのでしょうか。 Lifecycle, LiveData, ViewModel, Roomの内を覗いて、それらがどう動いているのか、探ってみましょう。 #対象者 - Android Architecture Componentsを使っている人 - ライブラリの中を覗くのが好きな人 #話す内容 - Android Architecture Componentsの中身 - Android Architecture Componentsを使うときの注意点など
タッチ操作で意図通りにぐりぐり動くUIを作りましょう。 Androidでは多くのコンポーネントが提供されており、標準的な操作への対応であれば、タッチイベントのハンドリングをアプリで独自実装しなければならないシーンは少ないと思います。 しかし、少し凝った操作系を作ろうとすると、独自にタッチイベントを捕まえ動きを実装する必要があります。 このタッチイベントのハンドリングは奥が深く、ドラッグとタップ両方できるようにする、複数本の指でピンチもできるしフリックもできるなどを実現しようとするとタッチイベントに対する深い理解が不可欠です。 Androidのタッチイベント伝搬の仕組みや、MotionEventが保持する情報といった基本的な説明、マルチタッチへの対応、陥りがちなポイント、有用なユーティリティの説明などを交えつつ、ぐりぐりと意図通りに動くUIの作り方を説明します。
動画の時代が来ると、数年前から言われており、動画を扱う案件が増えていると思います。 しかし、MediaCodecを使用した動画編集に関する情報はネット上にもとても少ないです。 そこでMediaCodecを使った動画編集を、サンプルと共に情報公開をしたいと思います。 目次案(検討中) * MediaCodecの概要 * OpenGLESの概要 * MediaCodecとOpenGLESで動画にフィルターをつける。 * MediaCodecとOpenGLESで動画にウォーターマークをつける * まとめと個人的な所感
MVP、MVVM、クリーンアーキテクチャ等、Androidアプリケーションの設計を整理するパターンは様々存在しますが、 実際にこれらのパターンを開発で適用しようとすると、どうしてもネックになりやすいのがAndroid SDKに依存する機能の呼び出し部分です。 例えば + Contextに依存する処理 + 画面遷移 + FragmentManagerの操作 + DialogFragmentの表示、 + Lifecycleイベントのハンドリング などがあげられます。 Fat Activity/Fragmentを避けようとMVP、MVVM、クリーンアーキテクチャ等のパターンを適用したはずなのに、どうしてもActivity/Fragmentにロジック部分が残ってしまいがちで結局設計を逸脱した例外的な処理の記述の仕方を行った経験などがある方もいらっしゃるのではないでしょうか。 本発表ではDagger2のScope、Subcomponentの機能を活用し、Android SDK由来の各種機能を疎結合に整理する方法、その利用例をご紹介します。 なお、本発表のサンプルコードはAndroid Data Bindingを利用したMVVMパターンを適用したアプリケーションを例として使用します。 ## 目次(予定) + Scopeは二つに分ける(Singletonスコープ、Lifecycleスコープ) + Context依存を切り離す + 二つの方法、メリット/デメリット + 画面遷移を整理する + Delegationパターンを使ってActivity/Fragment/DialogFragmentに対応する + FragmentManager(DialogFragment)依存を切り離す + Lifecycleイベントのハンドリングを整理する + Android Architecture Componentsを利用するパターン + 自前でコールバックを定義するパターン ## 対象者 + Fat Activity/Fragmentをスリムにしたい人 + Dagger2の基本的な使い方は理解しているが、実践的にAndroid実装に適用する際のベター/ベストプラクティスを知りたい人
NDKを使って高パフォーマンスなアプリケーションを作成する手法、チップス、APIなどを紹介します。 本セッションは日本語、英語混合セッションとなります。 ・C++を使ったAndroidプログラミング ・Android電話向けパフォーマンスチューニング手法 ・systrace, simpleperf等紹介 ・CPU governor挙動について ・Android NDK packaged the necessary API and tools to create low latency audio apps , high end graphics games, stunning video/camera apps, and accelerated Machine Learning applications; plus tools and Android Studio IDE to make creating Android high performance applications an pleasant experience. Goes through Audio, Graphics, Camera, Tools and Studio IDE to help developers to create compelling high performance Android applications.
There is a lot of Hype with ML and AI lately, and TensorFlow is the framework of choice from Google. But as a Mobile Developer you might have asked yourself, how can I benefit from it? In this talk, you will learn your first steps into the fascinating ML world for mobile. The session will show examples in: - Classifying example - Detection example - Analyzing example Also, we will have a state of the art report, which hole is TensorFlow covering, explanation of some real use cases, theory of Neural Networks, showcasing how models are training, what is the motivation of using ML on Mobile instead of on a server, etc. I will show as well some live demos on Android of how TensorFlow works, showcasing iOS and explaining how we can adapt our own models to Google samples.
Androidアプリの開発では多様な画面サイズや画面回転への対応など、柔軟性を意識してUI・レイアウトの構築を行う必要があります。また、Android 7.0でのマルチウィンドウのサポートもあり、画面構成の変更時の状態保持に対する理解の重要性も高まっています。 このセッションでは、ウィンドウサイズの変更に強い画面の構築を通して得た知見、Tipsを共有していきたいと思っています。 ■ 対象者 ・マルチウィンドウや横画面でも表示の崩れないレイアウトの構築に興味のある方 ・構成の変更時(ウィンドウのリサイズ、画面回転等)の画面状態の保持に対して苦手意識を持っている方 ■ 内容(予定) ① ウィンドウサイズの変更に強いUI・レイアウトの構築について ・様々な画面サイズ、OSバージョンで表示の崩れないレイアウトを構築する上でヒントとなる知見やTips ・fitsSystemWindows / WindowInsetsを活用してシステムUI(ステータスバー等)のサイズに影響されないレイアウトを組む方法 ② 構成の変更時の画面の状態保持について ・savedInstanceState、setRetainInstance、それぞれの状態保持の手法の利点と使い分け ・Android 7.0で強化されたonSaveInstanceStateで保存するペイロードへのサイズ制限とその対策 ・構成の変更とActivityの再生成を理解した上で、画面の状態保持に対して取りうる戦略を考える ※特定のアーキテクチャとの組み合わせでのより効果的な解決方法など、発展的な内容にまでは踏み込みません。
AndroidのViewレイアウトを定義するために、XMLで消耗していませんか? 私はViewの生成をAnkoのみで実装したアプリをリリースしました。 そこで得られた知見などを共有したいと思います。 * Kotlin Ankoを使う上で必要なKotlinの機能やシンタックスについて簡単に触れます。 * Ankoの内部実装 Ankoの内部実装を紐解きます。 一見、黒魔術的に思えるAnkoのView生成の仕組みを解説します。 * Ankoなら出来ること AnkoはKotlinのコードベースであるため、動的なレイアウトが可能であったり、再利用性が高いことが特徴です。 XMLでは出来ない、Ankoならではのテクニックを共有します。 * Ankoでは出来ないこと Ankoでは実現不可能なことも存在します。そのいくつかを紹介します。 * Ankoのハマりどころ 私がAnkoのみで開発する上でハマったポイント、その回避策を紹介します。 * ViewだけじゃないAnko AnkoではIntentの発行やダイアログ、トーストの操作もサポートしています。Viewレイアウトの定義だけでない、Ankoのその他の機能を紹介します。 * Anko DSL Preview CfP時点では安定していないAnkoのPreview機能。 セッション時点ではどうか?最新情報をお届けしたいと思います。
Android開発では、出来る限りdexファイルのサイズを削減しなければいけません。ProGuardを使うことで、無駄なコードを削除し、dexファイルサイズを削減することが出来ます。コード量を削減することで、アプリの高速化も期待できます。またInstant Appsでは4MB制限があるため、ProGuardの重要性がより増しました。しかし、ProGuardの設定は複雑なため、なんとなくのコピペですませがちです。 本セッションではなんとなく動いているProGuardから脱出するために、 - Proguardはそもそも何をしているのか? - OkHttpなどのライブラリでなぜこのProGuardの設定の追加が必要なのか? - Proguardを導入することでどれくらいの削減/高速化が期待できるのか? - Android StudioのAPK AnalyzerでProGuardの結果を見る - (時間が余りそうならfacebook/redexについて) について説明し、なんとなく動いているProGuardから脱出することを目指します。
🏴☠️ ARrrrg! 🏴☠️ This was my first reaction reading through the code of the sample provided by Google for it's new ARCore. After the first shock, I took a close look on how the app works, and what ARCore could do for my use case: Having my virtual collection of toy figures always with me ❤️. 🤖🤴 In this talk, I will talk about Augmented Reality, walk through the current demo app for ARCore on Android and purpose a better way of writing the app, extending it to be able to read different models at different times ... Expect a bit of Computer Graphics terminology, source code watching, Pirates, and more lame jokes.
アプリは作ってリリースすれば勝手にユーザーが増えてビジネスとして成長していくわけではありません。せっかくインストールしてもらっても、操作しにくかったり使い方が理解されなかったりすると結局起動されなくなり、いずれアンインストールされます。使い続けてもらうためにはユーザーに寄り添って何度も何度も何度も継続的に改善を繰り返していかなければなりません。しかし一口に改善といっても、何を持って改善されたといえるのでしょうか?改善されたというためにはそれを裏付ける指標が必要です。その指標を得るにはログを取り、解析をしなければなりません。 ではログ自体はどうやって取れば良いのでしょうか?「ログなんか取っておけば良いでしょ?」、そんなふうに考えていた時期が私にもありました。しかしアプリを改善させるためにログ解析をしていると、ログの抜けや重複、衝突などがあり、正しく解析できないことが何度もありました。ログを取るためのトラッカーはアプリ開発者が設計して実装しなければ、そういった役割を果たせるものではないのです。 また指標はGoogle AnalyticsやFirebase Analyticsでパッと見れるものならば良いですが、アプリの個々の機能の指標を作ろうとするとHadoopやBigQueryのようなログ解析のインフラと、ExcelやGoogle Data Studioのような可視化のためのツールも必要になります。それらをうまく活用するためには、元のログを解析しやすいようにしておく必要があり、それもトラッカーを埋めるアプリ開発者が行わなければなりません。 本発表ではアプリ作るだけだった私がログ取りやログ解析を行い、実際にデータに基づいたアプリの改善を行うようになるまで、何を学び、何に気をつけて開発を行っているかをお話します。
CleanArchitectureは各レイヤーごとに役割が明確に決まっており、大規模開発などに非常に向いている。 しかし一方、大きなデメリットとして ・DI周りの実装がそもそも解りづらい(特にDagger) ・クラス数が多くなる→単純に作業量、コード量が増える&ケアレスミスですぐ動かなくなる ・CleanArchitectureの構造を理解していないとオレオレ実装が蔓延る といったものがあるのではないだろうか。 そこで注目したのがKotlinとTemplateの存在。共通のテンプレートを作成し、それを使うことで、 ・DIの実装が解りづらい?→Templateがやってあげるよ ・作業量が増える?→Templateがやってあげるよ ・コード量が増える?→KotlinだからJavaより減るよ&読みやすいよ ・ケアレスミス?→Templateがミスしやすそうなところは全部やるよ ・オレオレ実装?→みんな同じTemplate使えば差異がぐっと減るよ という状況を作り出した。 本発表では、上記のCleanArchitectureのデメリットを減らし、最大限活用したら開発が爆速になったお話に加え、CleanArchitectureを採用したことで得られたメリットについてお話しようと思います。
Builds can always be faster. 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. The great news is that Android Plugin 3.0.0 and higher include major changes that bring significant performance improvements to large multi-module projects—in some cases, we've experienced builds that are 3-5X faster! Some of the improvements include: * Better parallelism for multi-module projects through a fine grained task graph. * Variant-aware dependency management. (When building a certain variant of a module, the plugin now automatically matches variants of local library module dependencies to the variant of the module you are building.) * Compilation avoidance via new dependency configurations. * Faster incremental build speed due to per-class dexing. Each class is now compiled into separate DEX files, and only the classes that are modified are re-compiled. * Faster resource packaging with AAPT2 enabled by default. In order to bring about these improvements, there are some breaking changes in the plugin behavior, Domain Specific Language (DSL), and APIs. In this talk, a member of the Android Studio team shows you how to easily migrate your project to the new plugin, resolve build errors, optimize your build configuration, and prepare your project to take advantage of future improvements to the plugin.
In this talk I'll go through the process Dropbox followed to go from supporting Offline Files to supporting Offline Folders. I'll focus on the things paint points of implementing it in Android, like Doze and the way Android manages storage.
# 概要 Java6から登場しているPluggable Annotation Processing API。 Dagger2やButterKnifeなどメジャーなライブラリで使われてるのは見たことあるけど自分で触ったことはないという人が多いのではないでしょうか? 普通にアプリを作っているだけだと中々触れる機会がないけど奥が深いこの機能、Android開発にどう活かすことができるのかを解説します。 # 対象者 - 毎回似たようなお決まりのコードを書くことが多い方 - Annotation Processingって聞いたことあるけどいまいち何してるのかよくわかってない方 - コード生成という単語にビビッと来たそこのあなた # 目次(予定) - そもそもどんなことができるのか - アノテーションとコード生成 - JavaPoetとKotlinPoet - Android開発の現場においてどのように活用できるのか - Kotlinから使う場合の注意点 などを私自身が作成、公開しているライブラリのコードを交えて紹介します
「対象者」 ・UIテストの実行時間で悩んでいる人 ・UIテストに興味がある人 「概要」 AndroidアプリにおけるUIテストは以前と比べ、実装しやすくなってきています。 そのためUIテストを実装する方が増えてきているかもしれません。 しかし、UIテストの実行時間は問題になりやすいです。 せっかく実装した価値のあるUIテストも、実行時間の長さによりあまり利用されないといったケースもあります。 UIテストだからしょうがないと諦めてしまっては勿体ありません。 本トークでは、SWETが取り組んでいるUIテストの実行時間を短くするための色々な方法について述べます。 tipsレベルからSWETが開発しているサービスまで紹介する予定です。
Kotlin offers a modern language design in contrast to Java, while at the same time maintaining fully interoperably: Data classes, properties, delegation, inline functions, string interpolation and much more. But, if Java can't offer these features how can Kotlin, what does Kotlin do to make it possible to use this Syntactic sugar? In this talk, we will go backstage and dig into the Bytecode that Kotlin generates to make all the features we love work on a runtime that technically does not support them. We will look at the impact kotlin code generations has on method count. Get a deeper understanding of how Object and companion object work and see the implications of the use of either under different circumstances. Finally look at common patterns that can help reduce the size of both the bytecode and method count.
7/10 developers don’t really know how to test their apps and write testable code. From practically writing code to test genuine production level scenarios with different approaches to incredibly optimising your tests cases, we will also see what’s new in Android Test Support Library 1.0. ---Outline--- -> Important Testing GuideLines -> Espresso and Robolectric (In and Out ,Crisp and To the point) -> Making Code highly Testable using MVVM , Repository Pattern and Data binding ->Pure production level Scenarios Testing Demo:- -> Will be showing the order lifecycle of an e-comm site and show how different orders states can be Unit Tested( A very genuine and typical use case applicable to almost every startup or company) -> Will be showing This with the following three approaches using Dagger 2 a.) Using Robolectric (JVM based without needing a device or emulator) b.) Using Espresso (Unit Instrumentation Tests) c.) Testing the ViewModel (Purely JVM based) -> Optimise them further (reducing test suite running time from 16s to 180ms) -> Espresso Unit Instrumentation Testing Vs Robolectric Unit Testing Vs Unit Testing MVVM architectured app (Detailed analysis including performance) -> Integration Testing Using Espresso -> Demonstrating the New Features of Android Test Support Library 1.0 -> Android Test Orchestrator -> New Features Of AndroidJUnitRunner -> Espresso 3.0 New Features -> New Test Rules ->If time allows -> UI Automator in Action -> Testing on Multiple Devices Fire Base Test Labs -> Continuous Integration Using Circle CI -> What’s More In AWS Device Farm
Androidアプリにかぎらず、アプリ開発は大きな裁量のある自社案件だけでなく、様々な制約のある受託案件も多く存在します。 受託をするからには「どのくらいの期間で」「何人の人員で」「おいくら万円になるのか」等を見積もり出さなくてはなりません。 「この機能ならこれくらいだな」と直感で出してしまうと、あらゆるところに待ち受ける地雷であっという間に爆発四散してしまうでしょう。 Androidアプリ固有の問題、機種固有の問題のみならず、開発フローの問題、社内政治的問題、期間の問題、そして開発者のエゴの問題などなど。 このセッションでは、アプリ開発時に感情に含めなければならないあらゆる要素について、技術的観点以外についても解説していきます。 ※講演者及び周辺人物の経験則に基づく要素が大きいということを予めご了承ください 発表内容(予定) ・Androidアプリ開発固有の問題 ・機種固有の問題 ・開発周辺環境の問題 ・関わる人間の問題 ・社内政治の問題
Androidの公式言語として仲間入りしたKotlinの初学者向けハンズオンです。 Kotlinの概要と誕生の背景から始め、 Kotlinの基本文法、クラスやオブジェクト、拡張関数を学び、体験します。 実際に手を動かす課題としては、FizzBuzzなどの簡単なものから、 クラスの定義とその機能追加などちょっとだけ本格的な内容も含みます。 Kotlinの言語そのものにフォーカスしているため、 本セッションで得られる知識は、Androidに限らず他の分野でも応用できるでしょう。
▶対象 ・Androidで動画を扱うアプリに携わっている人 ・Androidの動画周りに興味がある人 ▶概要 画像やテキストが主流だった時代から動画の時代へと移り変わってきました。そこで、今回はAndroidで動画を扱うために必要なTipsなどをお話できればと思います。 動画Player周りでは、Androidで主流になっているExoPlayerを使って説明していく予定です。 最後にインスタのライブ配信やFacebookライブの様なライブ配信をAndroidでどう実現するかや実際にそのデモを行います。 ▶内容 ・動画の配信Protocolと概要 (MPEG-DASH, HLS) ・Androidでの動画再生 with ExoPlayer ・ExoPlayerでできることとその内部実装 ・Androidで動画配信 ・Androidでライブ配信 (デモ)
■背景 Downloadable FontやEmoji Compatibility Libraryなどの便利な便利な機能が存在します。 しかしこれを活用する知見がまだ少ないのではないでしょうか? ■内容 どういう仕組で動いているのか。 実際にCalligraphyをDownloadable fontに置き換える方法。 Emoji Compatibility LibraryのMinimum SDK Version 19にどう対応するか。 どうやってテストするか。 など実践的なところを紹介していきます。
Droid Kaigi 2017 で How to apply DDD to Android Application Development という講演を行いました。本セッションはその続きです。 前回ドメイン駆動設計とは何か、何をするのか、を解説し、戦略的設計について話しました。今回は戦術的設計について踏み込みます。 様々な手法があるなかで、ドメインを隔離することをテーマに、Androidアプリ開発で取り入れやすいエッセンスを紹介します。 前回同様ドメイン駆動設計の内容については「エリック・エヴァンスのドメイン駆動設計」及び「実践ドメイン駆動設計」に準拠します。 本セッションはドメイン駆動設計の前提知識がない方にもわかるようお話ししますが、前回の動画 https://academy.realm.io/jp/posts/droidkaigi17-how-to-apply-ddd-to-android-application-development/ を見ていただくか、内容をまとめたブログ http://y-anz-m.blogspot.jp/2017/03/droidkaigi-2017_9.html を読んでいただくことをおすすめします。
# 概要 (50分としていますが、30分も多分可能です) Androidアプリに限らず、昨今のウェブサービス・アプリの通信周りでは専らRESTとJSONが使われていることと思います。 そんな中、現在私達が開発しているアプリではREST + JSONではなくgRPC + Protocol Buffersを使うという選択肢を取りました。 gRPC, Protocol Buffers共にGoogleが開発した新しい通信フレームワークおよびシリアライズフォーマットです。様々な魅力的な特徴がある一方で、まだまだ採用例が少なく情報も充実していないのが実情です。 そんなgRPC + Protocol BuffersをどのようにAndroidアプリ開発で用いるのか、メリットやデメリットは何なのか、開発の上で工夫した点などをお話できればと思います。 # 内容(予定) - gRPCとは何か - Protocol Buffersとは何か - Androidアプリにおけるメリット・デメリット - gRPC + Protocol BuffersをAndroidアプリ開発に導入する - 実際の開発の際の工夫、苦労する点、etc # 主な対象者 - REST + JSON以外の選択肢を検討したことがなかった人 - アプリ開発でRPCを使いたい人 - サーバ・アプリエンジニア間でJSONレスポンスの仕様共有に苦労している人 - 新しい技術に積極的に挑戦してみたい人
AndroidTVデバイス向けのOreo対応進んでいますか? AndroidOから新たに追加されるRecommendations Channelsの話を中心とした、AbemaTVでの開発のTipsを紹介します。 またテレビデバイス向けのUI改善についての小話も紹介します。
昨今のAndroid開発において、Gradleはビルドを司る重要なシステムです。その動作を司るbuild.gradleには、アプリ開発における効率を高める無限の可能性がありますが、気がついたらいつも同じスクリプトをコピー&ペーストしていたりしませんか?その改善をプラグインとして作り、公開することができれば、自分だけではなく世界の開発を改善することができます! このセッションでは、Androidのビルド改善に取り組もうとしている&既に取り組まれている方を対象として、Gradleプラグインの作成を最小の構成から始め、そのデバッグ方法や、単独のプロジェクトへの切り出し、公開方法までを手順を追って紹介します。 プラグインというと難しそうに感じますが、その実態はただのJavaクラスです。新しいファイルを作ることさえなしに、まずはbuild.gradleの中で定義することから始めましょう。
■対象者 ・Espressoで自動テストを書いてみたものの、不安定なテストが多くて困っている方 ・Espressoでテストを自動化する範囲をより広げて行きたい方 ■概要 AndroidのUIテストツールであるEspressoの特徴の1つに、 「UI操作に関する同期(待ち合わせ)処理を自動的にやってくれる」 というものがあります。 公式ドキュメントによると、この自動同期機能の恩恵により、 テストコードで明示的にwait/sleep/pollingを書く必要がなくなる、とも書かれています。 ところが、RxJavaなどの非同期処理を主体としたフレームワークが広く採用されるようになってから、Espressoの自動同期機能がうまくいかず、UIが更新される前に次の操作が実行されてしまい、テストが失敗するケースに直面することが多くなってきました。 皆さんの中にも、UI更新の待ち合わせがうまく行かず、その場しのぎにsleepを挿入した経験の有る方がいらっしゃるのではないでしょうか? このセッションでは、Espressoの自動同期処理が何をしてくれるものなのか? Espressoの自動同期処理でうまく行かないときにどうすれば良いのか? という疑問を解決すべく、最新のEspresso 3.xの実装にもとづいて、以下の内容について解説します。 ・Espressoが提供する自動同期機能が保証してくれること・くれないこと ・Espressoの同期処理をカスタマイズするIdlingResource APIの概要 ・Espressoが提供しているIdlingResource実装の紹介と、その使い道 (一例として、RxJavaの非同期処理を待ち合わせる方法も紹介します) ・最後の手段: IdlingResourceを使わずに、簡単に同期を取る方法 このセッションを聴いた方が、 タイミングによって失敗してしまうような、 不安定なEspressoテストを自力で修正できるようになることを目指したいと思います。
Androidアプリ開発における難しさの1つは、不連続性です。たとえば、通信中に画面回転をした場合、その結果を受け取るにはどうしたらよいでしょうか。あるいは、商品詳細画面で商品をお気に入りに追加したあとに商品一覧に戻ったときに、一覧画面でもお気に入りマークを正しく表示するにはどうしたらよいでしょうか。 このトークでは、画面回転や画面遷移における代表的な不連続性を取り上げ、それぞれにどのような対応が選択肢としてあるかを紹介します。 前半では典型的なユースケースを例にどのような不連続性があるか紹介します。たとえば、画面回転ではアクティビティが再生成される一方で、setRetainInstance(true)にしたFragmentやLoaderは生き残ります。それを利用することで画面回転をまたがったデータの保持が可能です。しかし、画面遷移においてアクティビティが破棄されていた場合は、onSaveInstanceStateでデータを保存してやる必要があります。さらに、Low Memory Killerでアプリのプロセスが殺された場合は、Applicationクラスで保持していた情報も失われてしまいます。 このように、Androidアプリにおける不連続性の種類と特徴を理解することが、適切な対応への第一歩となります。 後半では、不連続性を克服するための手段として、つぎのような手段を紹介します。それぞれについてメリット・デメリット、向いている用途について解説することで、トークを聞いた開発者が、それぞれの不連続性に対して適切な対応を取れるようになることを目指します。 1. AsyncTask 2. Loader 3. Architecture Component 4. RxJava 5. Kotlin Coroutine
iOSエンジニアは必要に迫られてATS対応というものを実施しているようですが、Androidエンジニアは何もしなくていいのでしょうか? 本セッションでは、HTTPS通信の役割と仕組み、Android MのusesCleartextTrafficの設定、Android NからのNetwork Security Configurationの設定について解説したいと思います。 また、HTTP Public Key Pinningについても触れます。 本セッションを通して、ユーザーがより安全にアプリを利用できるようにするために、Androidエンジニアとして何ができるかを考えるきっかけにできると幸いです。
2008年にリリースされて以来、Androidは猛烈なスピードで進化し、多くの開発者に愛されて発展してきました。 本セッションではこの9年間の(そしてAndroidが生まれる前にどのような設計思想を持って作られたかという点も踏まえて)アーキテクチャの進歩を振り返り、アプリケーション設計のトレンドを予測します。 通常のセッションではなく、聴講者と発表者が対話し、ディスカッションしていく(TEDのような)スタイルにて講演を実施します。これまでやったことがないチャレンジングな手法です。 講演を通じて、Androidの根底を支えるライフサイクル、ActivityやView、XMLによるUIの分離という設計思想からMV-Whateverなどのアプリケーションのデザインパターンに至るまで、そして今後どのような未来に向かっていくか、Architecture Componentsなどが登場した経緯を紹介します。 ディスカッションしながらすすめることで、これらのライブラリ、デザインパターンが解決したかった問題に触れられます。参加者がAndroidの歴史を追体験でき、単純に学ぶよりも楽しく学べ、初学者から中級者の理解を助けます。 "2017年の東京、新宿に住むエンジニア、マーティ・マクフライはAndroid歴史学者であるドロイド博士(通称ドク)を手伝って、タイムマシンの実験を行う。タイムマシンに改造されたデロリアンDMC-12が到着した先にはガラケーしか存在しない時代だった。デロリアンに乗った2人は現代のAndroidまで帰ってこれるのか?!"
# 概要 サービス提供者間のデータ連携が活発になるにあたり、認証・認可の重要性が一層増しています。そのような背景に応じてか、Google Identity Platform上のAndroidの機能が続々と登場しています。また、OAuth2.0などの技術標準がより一般的になってきました。これらを上手く利用し、ユーザー体験の利便性を損なわない、セキュアなAndroidアプリを作る方法についてお話します。 # 扱う技術(予定) - Firebase Authentication - SMS Retriever - Smart Lock - OpenID Connect(+ OAuth2.0) - FIDO # 詳細 "スマートフォン(スマホ)を使った金融サービスを生みやすくする。(中略) 同じサービスに同じ規制をかけ、銀行とフィンテック業者が連携しやすくする" と金融庁は宣言しました。Fintechに限らずサービスプロバイダは、ユーザーのデータをAPIなどを介して提供・利用し、新しい体験を創造していく流れが加速するでしょう。 その際に鍵となる概念が、"認証"と"認可"です。サービス提供者は、別のサービスのAPIを叩いてデータを提供してもらうには、ユーザーに**認可**をもらう必要があります。そして、認可の操作の前に、正しいユーザーを**認証**しなければなりません。 この認証と認可には、一般的にOAuth2.0、それを取り込んだOpenID Connect, FIDOといった技術仕様があります。また、Googleが提供しているFirebase AuthenticationやSMS Retriever APIなどもあります。 では、そのような技術・標準・APIをAndroidでどのように適用すればいいのでしょうか? 本セッションでは、上述した技術や標準をAndroidアプリで使う場合の実装方法・気にすべきポイントといった部分についてお話させて頂きます。
■対象者 Instant Appsの概要を知りたい方 既存アプリをInstant Apps対応しようと考えている方 これから作るアプリのInstant Apps対応を見据えた設計にしたい方 ■概要 Google I/O 2016にて発表された1年後、Google I/O 2017でようやく一般開発者も可能になりました。Instant Appsは、アプリをインストールすること無く、直ぐにネイティブアプリと同等の動作をすることが出来るため、ユーザ体験が著しく向上します。 既にアプリの数が溢れているこれからの時代、対応は必須なのではないでしょうか? しかしながら、Instant Appsはapkのサイズが4MBという制限が設けられていて、既存アプリをInstant Apps対応するには一手間加える必要があります。 このセッションでは、Instant Apps対応の基礎知識と共にモジュール設計から、DIを含む既存アプリの移行にフォーカスを当てて解説していきます。
ここでははじめてAndroidでUnit Testを書く人、これからUnit Testを増やしていきたい人を対象としたハンズオンを行います。 ・基本的なアサーション ・Mockitoを使ったモックやスパイ ・SQLiteを使った部分のUnit Test ・Robolectricを使ってAndroidフレームワークのコードを利用した部分のUnit Test ・非同期処理のテスト 等をカバーします。 対象とするコードはDroidKaigi公式アプリ等の実践的なものとし、より現場に近い状況でどのようにUnit Testを書いていくかにフォーカスしたいと思います。
■対象 ・脳みそが筋肉でできているAndroidエンジニアからある種の勇気をもらいたい方 ・個人でAndroidアプリを完成させて記念すべき1作目をリリースしてみたい方 ・個人Androidアプリで10万ダウンロードいってみたい方 ・Androidアプリエンジニアだけど微妙に職に困ってる・今の待遇に不満がある方 ■お話する内容 個人アプリ開発において 「そこそこダウンロードしてもらえるアプリ」を 「作る・完成させる・リリースする」ために 実践してること、してないこと ■お話しないこと AndroidStudioの使い方とか プログラミングのこととか ■本邦初公開 ・どっきどき!スクレイピング怒られ事情 ・どっきどき!GooglePlay(AppStore)怒られ事情 ・一生内緒にするつもりだった!書き込みゼロのアプリ内掲示板をアクティブにした裏技
モバイルアプリに開発において、端末(デバイス)の管理は重要です。そこで、デバイスファームを利用することでデバイス管理のコストを抑えることができます。 今日ではデバイスファームも様々なOSSやサービスが展開されています。 このセッションでは、デバイスファームの紹介とメリット・デメリットについて紹介します。
[内容] 大切なデータを守るために、暗号化は有効な手段ですが、同時に鍵を安全に扱う方法を考える必要があります。 Androidでは、バージョン4.3以降で「Android Keystore プロバイダ」が提供され、アプリだけが使える鍵を管理出来るようになりました。 ただし、この鍵はユーザーの操作によって消えることがある仕様になっています。 本セッションでは、「Android Keystore プロバイダ」の基本的な使い方と鍵が消える条件を解説すると共に、鍵が消えることを想定した使い方について考察します。 [セッション構成] -Android Keystore Providerとは -アプリの鍵が消える時 -消える条件について -バージョンによる違い -消えることを見越して
■対象 ・Widgetに関心がある方 ・Widgetをこれからつくりたい方 ・Widgetをつくられたことのある方 ■概要 Widgetはメインのアプリにバンドルして提供されるミニアプリです。Widgetにより、アプリの機能やコンテンツに、ホーム画面からスムーズにアクセスできるようになります。アプリを開かずとも、ユーザーが必要な情報に触れることができるため、コンテンツへのエンゲージメントを高めることができます。 今までWidgetは、アプリインストール後にホーム画面から別途追加する必要があり、登録フローがユーザーに分かりにくい状態でした。しかし、Android O からWidget機能が強化され、アプリの中からWidgetの追加を行えるAPIが提供されるようになりました。 本セッションでは、この新APIを踏まえて、Widgetの実装についてお話致します。Widget特有の実装方法や重要な内部APIの挙動、開発における注意点などについてもご紹介するつもりです。
KotlinはJavaよりもシンプルで安全なコードを書くことができます。また、同じ処理を書く場合も、いくつかのやり方があります。文法に関する説明は、公式ドキュメントを見れば分かりますが、使いどころ、特にAndroidアプリ開発における使いどころについては、まだそれぞれ模索している段階といってよいのではないでしょうか。 このセッションでは、私がフルKotlinのアプリをチームで開発した経験の中で分かった、Kotlinの各種文法の適切な使いどころや、バグを生みやすいコードのパターンなどを紹介してみたいと思います。 例えば、lateinitとnull初期化の使い分け、interfaceのデフォルト実装とabstractクラスの使い分け、引数なしの関数とcustom getterの使い分け、定数とlazyとcustom getterの使い分けなどがあります。また、property delegationの使いどころ、スコープ関数の使いどころ、レシーバー付き関数型の使いどころなど、Kotlinの基本文法を紹介しつつ、Androidアプリ開発をした経験からActivityライフサイクルやFragmentライフサイクルに合わせた使いどころ・注意点などについて解説してみたいと思います。
昨今のアプリ開発は大規模になってきており、モバイルアプリのエンジニアとサーバサイドのエンジニアが分担し開発することも多いと思います。 その際、仕様を含めたAPI定義のすり合わせ、変更についての情報共有などの円滑なコミュニケーションが必要になります。 また、API定義の変更に関してはモバイルアプリは漏れがないように迅速に追従していく必要があります。 本セッションでは、API定義を管理するSwaggerに焦点を当てます。 また、Swaggerを用いてAPI定義からJSONのマッピングオブジェクトを自動生成することにより工数削減と品質向上を図り、生産性を高める方法を紹介します。 - Swaggerとは - Swaggerを用いたAPI定義 - AndroidにおけるSwagger Code Generatorを用いたコード自動生成 - (時間があれば)mustache記法について
●概要 AndroidアプリのアーキテクチャパターンとしてMVVMが採用されることが多くなりました。Androidではデータバインディングがサポートされており、効率的にMVVMで実装を行うことができます。しかし、実際にMVVMで開発をしようとすると様々な問題に遭遇します。また、MVVM以外のパターンも存在するため、それらと比較してあえてMVVMを採用する理由は何か、という点も気になります。 私は2010年頃から様々なプラットフォームでの開発においてMVVMを採用しており、現在担当しているAndroidアプリもMVVMで開発しています。その経験をもとに、Android以外のプラットフォームでの実装パターンを参考にしながら、MVVMのメリットを活かしてAndroidアプリを効率的に実装するためのポイントを紹介します。また、Fluxなど他のパターンとの比較を行い、アーキテクチャ選定の観点からも考察します。 (プログラミング言語はKotlinを想定します) ●アジェンダ(予定) ・MVVMの歴史と概要 ・AndroidアプリにおけるMVVMの基本的な実装パターン ・他のプラットフォーム(WPF, Javascript等)におけるMVVMとの比較 ・AndroidアプリをMVVMで実装する際のポイント ・画像のバインディング ・RecyclerViewへのバインディング ・ViewModel間の連携 ・アニメーションとの連携 ・Contextの扱い ・ユニットテスト ・効率的なA/Bテストの実施方法 ・アンチパターン ...etc ・Flux等の他のアーキテクチャパターンとの比較 ・MVVMを採用する上での基準を考える
Google announced that Google shifts from mobile-first to AI-first at Google I/O 2017. What does it mean? In this talk, I will talk about 3 things. First, we will see environment changes around us. You may think "AI is not my business" but it happens. I will talk how our life has been changed and what will happen in the future. Then, I will introduce the basics of machine learning and how to run machine learning models on Android devices. I will also refer to machine learning frameworks and JNI. Finally, I will share knowledge of continuous improvement of machine learning products. When you want to deploy your model to production, you have to think about more things such as APK size, CPU usage, memory usage, versioning, monitoring, ... We will see how to address these challenges. You will learn what I've learnt in 30 min. This is what I wanted to know when I started machine learning.
ここ数年でいくつかの、他のAndroidアプリをエミュレートするAndroidアプリが登場しています。その多くがLINEやゲームを2アカウント同時使用できることを謳っており、多くのユーザーに使われていると思われます。 本セッションではこれらのアプリがどのようにして他のアプリをエミュレートしているのか調査した結果と、これらのアプリを使用することによる危険性の分析について発表を行います。
ConstraintLayout 1.0 made building flexible UI easy, with a deep integration in the Android Studio layout editor. The recently introduced 1.1 version is bringing even more flexibility, with new capabilities like barriers or groups. This talk will take a deeper look at the current state of the library, why you should use it and when: architecture, performance behavior, examples of complex UI, animation capabilities, extending the library in your project via subclassing, and discussing some upcoming features.
React Nativeが出てきてしばらく経ちましたが、処理系が特殊なこともあり、黒魔術的なイメージを持っている人も多いように思います。 しかし、実際には素直な読みやすいJavaで実装されている部分も多く、Androidエンジニアが読めば充分読めてしまうレベルです。 本セッションでは、React NativeのAndroid向け実装を様々な面から紹介することで、React Nativeへの心理的障壁を下げてもらうことを目的とします。 次のようなトピックを想定しています。 * JavaScriptCoreはどこで・いつ動くのか * ネイティブブリッジの仕組みから見る「Androidらしさ」 * ビルドの仕組みから見る「Androidらしさ」
RecyclerView is now a de facto standard for representing a large data set into a limited window as a scrollable view. One of the advantages of using it compared to ListView is that RecyclerView can change how the data set is presented in addition to a simple linear list (such as Grid, StaggeredGrid) by changing the LayoutManager attached to it. But it's not well known that you can provide your own LayoutManager to achieve even more flexibility in addition to the three (Linear, Grid, StaggeredGrid) default LayoutManagers provided by the library. In this talk I'm going to explain how you can create your own LayoutManager in details based on the experience that the presenter created a Flexbox implementation as a LayoutManager.
Go言語を用いて Android 向けゲームを作る手法について紹介します。Go言語で Android 向けゲームを作る方法はいくつかありますが、ここでは特に gomobile という Go言語公式のツールを使った手法について取り上げます。gomobile を使うことで、Go言語のみを用いて Android アプリを作ることができます。ゲームでない通常のアプリを作ることも出来ますが、gomobile は非常に限られた機能しか提供しないため、gomobile で何が出来て何が出来ないのか、あらかじめ考慮が必要です。gomobile で出来ること、ないし使用上の留意点、ハマリどころ等を、実際に使い込んだユーザーの観点から解説します。
Material designで実装するアプリケーションにはSharedElementTransitionを始めとする、脳に優しい、美しいアニメーションが必要不可欠です。ですが、いざ実装を開始すると、様々な細かな仕様で躓くことも少なくありません。 このセッションでは、そんなアニメーションの実装を実例とともにコードベースで解説をしていきたいと思っています。 サンプル的な意味合いの強いプロジェクトではなく、実際にリリースされているアプリのコードをもとに解説していきます。 また実装する際には、アニメーションを実際に考えるデザイナーの人とどのようにコミュニケーションを取る必要があります。その際のこつや、どのようにコミュニケーションを取っているか、についても同時に紹介したいと思っています。 - アニメーションの紹介 - 実装手法の説明 - どんなトリックが存在するのか - 効率的なアニメーションデバッグの方法 - デザイナーとのアニメーションに関するコミュニケーション方法 - どこまで頑張るかの線引き などについてお話しします。 対象者:Animation実装に苦手意識のある人/初級者
■ 概要 「OpenGL ES」と聞いてよくわからないけど難しそうと感じていませんか? 難しいと感じる原因は2つあります。一つはOpenGL ESが何をやっているのかわからないということ、もう一つはOpenGL ESを使って実現したい機能の高度さです。 前者は、Androidエンジニアが「iOSやSwiftよくわからない」と言うのと同じようなものです。理解さえしてしまえばどんな高度な機能の開発にも応用できます。 本セッションでは、OpenGL ESが何をやっているのかを理解するために、基礎となるGPUの仕組みから、OpenGL ESを使って描画するまでを紹介します。 また、AndroidでOpenGL ESプログラミングをする際にハマりやすいポイントについても紹介します。 ■ 発表内容(予定) - GPUの仕組み - GPUとCPUの違い - GPUとOpenGL ESの関係 - OpenGL ESプログラミングの基礎 - 画面を描画するまで - シェーダープログラミング - Android OpenGL ESプログラミング - GLThreadの話 - UIコンポーネントとの連携 - デバッグ方法
2017年7月にピックアップ株式会社の技術顧問に就任し、現在では新規Androidアプリの開発を進めています。 その中でもスピード感を持ちつつ、同じサービスのiOS、Androidアプリを作るにあたって苦労した点や、工夫した点など、 他のアプリ開発でも十分に役立てるような内容をお話できればと思います。 【アジェンダ(予定)】 ・技術顧問とは ・普段の仕事 ・プロジェクトの概要 ・現在のチーム体制 ・iOS、AndroidエンジニアがAPIを書く ・コードレビューの観点や仕組み ・CIやツール周り ・ライブラリやアーキテクチャの選定 ・社内全体でスキルをあげていく仕組み
一般的なアプリを開発している際には、ほぼお目にかかることはなく、日本語での情報も少ない Android の機能「Accessibility Service」。 許可にはユーザーに設定画面から許可をしてもらう事が必要になっており、デバイス全体を握ることも可能な権限をも付加させることができます。 通常であれば視覚障がい者の方などへの読み上げサービスとして使用するなどが正しい使い方ですが、一方でその権限の高さを悪用したウイルスアプリなども存在しています。 このセッションでは、正しく Accessibility Serviceを使用するとこんな機能が作れるというのを紹介しながら、逆に Accessibility Service を使用するとここまでできてしまうという紹介をしていきたいと考えています。 セッション予定 - Accessibility Service 概要 - Accessibility Service を使用したデモ/実装紹介 ① - Accessibility Service を使用したデモ/実装紹介 ② - Accessibility Service を使用したデモ/実装紹介 ③
FlutterはAndroid、iOS両方のアプリをDartで書けるフレームワークです。Firebaseとの連携やMaterialデザインに沿ったUIコンポーネントが標準で用意されています。 公式ドキュメントやcodelabを見れば一通りの実装はできるのですが、国際化やキャッシュ、CIといった細かい部分の実装をどうすればいいのかはまだ実例が少ない印象です。 本セッションでは、少し複雑なサンプルアプリを例に、Flutterのここどうすればいいの?という部分を説明していきます。
◾️概要 RasberryPiにAndroidThingsをインストールして簡易なホームセキュリティを構築する手順、Tips、苦労話を話します。 センサーの取り扱い方やFirebaseを使う事でサーバーを用意せずにAndrodアプリから監視する方法も紹介します。 ◾️アジェンダ(仮) ・AndroidThingsとは ・AndroidThingsでセンサーを取り扱う ・Firebaseを使ってAndroid端末とやり取りを行う ・AndroidThingsの辛い話 ◾️対象者 Androidアプリ開発の経験者 AndroidThingsで何か作ってみたい人 電子工作してみたい人
GraphQLはFacebookが開発したWeb API用のクエリ言語の仕様で、RESTful APIを置きかえるAPIアーキテクチャと考えられています。GitHubのWe API v4がGraphQLで提供されたことにより注目が集まっており、発表者(`@__gfx__`) も仕事でGraphQL APIの開発を行っています。いまやサーバーサイドエンジニアにとって、RESTful APIを置きかえるものとして検討に値する技術といえるでしょう。 さて、Web APIがGraphQLで提供されるようになるのであれば、Androidエンジニアにとっても無縁ではありません。GraphQLとは何なのか、RESTful APIと比べてどういう利点・欠点があるのか。Java/Kotlinから使うにはどのようにするのか。 本セッションでは、これらの疑問に対して回答を試みます。GraphQLは一見とっつきにくい技術ですが、本セッション後は魅力的な技術に見えていることでしょう。オフィスに帰ったらAPI設計者にこう提案してみてください: 「DroidKaigiでGraphQLを知ったんですが、サーバーサイドもクライアントサイドも楽に開発できるようになると聞きました。うちもGraphQLにしましょう!」 ## ToC(予定) * GraphQLとは何か * GraphQLとは何か * なぜGraphQLを学ばねばならないか * GraphiQL: The GraphQL IDE の使い方 * GraphQLとの付き合い方はいくつか * 単にRESTful APIの置き換えとして * GraphQLからWeb API clientを生成する * e.g. https://github.com/apollographql/apollo-android * Viewに必要なデータをまるっと取ってくるための自動化されたWeb APIとして * The Relay Framework * Relay on React Native * Relay on Android Java/Kotlin のPoC * GraphQLに関するFAQ
DroidKaigiに出席するAndroid開発者の皆様には馴染みがないかもしれませんが、 近年ディレクターやデザイナーが主体となってお知らせダイアローグやプッシュ通知その他のマーケティング施策を実行できるようにするマーケティングオートメーションツール(以下MAツール)というものが開発されています。 自分はMAツール界隈ではアプリ内メッセージと呼ばれているお知らせダイアローグを見た時、 これはなんだか面白そうだと開発に参加してそろそろ一年経ち、それなりに色々面白かったので その様子をご紹介したいと思います。 こんな世界があるのかーと物珍しく眺めていただければ幸いです。 以下は内容一部変わる可能性がありますがお品書きです。 ■ MAツールとは - プッシュ通知やお知らせダイアローグの表示、各種ユーザー行動のトラッキング、その結果の再利用までをWeb上でディレクターだけでできるようにしていくもの - ディレクターやデザイナーはより自律してユーザとの接点を作る施策を行うことができる - エンジニアはその分、各画面のUIのアニメーションや性能改善、アプリならではの機能の開発に専念できる ■ 技術的に携わっている要素について - プッシュ通知 - 複数バージョンのGMSとFCSへの対応 - iOS/Android両方で使えるようにするための機能の取捨選択 - 他の同様のツールとの共存について - お知らせダイアローグ - 途中でバックグラウンドを挟んだ場合やViweGroupのAPI Levelによる挙動の違いへの対応 - ChromeBookなど特殊な画面サイズの端末への対応 - AndroidとiOSで標準的なUIが違うため、AndroidのカスタムViewを書いたり - クロスプラットフォーム対応 - 各種ビルドツールをつなぐために環境変数や動的・静的ライブラリのリンクといったコンピュータ要素に詳しくなっていく話 - 代表的なクロスプラットフォームに対するライブラリ提供方法の例 - テスト自動化 - 検証項目が加速度的に増えていくので自動化がマストになっていく - AppiumやXCUITest, Espressoを検討した時の話
【概要】 最近のSNSアプリには当たり前のようにマルチログイン機能が実装されるようになっていますが、いざ自分でこのマルチログインを実装しようとすると様々な壁にぶつかります。具体的には、シングルトンの扱いや、実行中の非同期処理のキャンセル、永続化されたデータの扱いなどです。本発表では、マルチログイン機能を開発するための手法を解説します。 【対象者】 ・マルチログイン機能の実装に悩んでいる方 ・マルチログインによってコードが複雑化してしまって困っている方 【目次】 ・マルチログインの定義 ・マルチログインの実装において障壁となるもの ・シングルトン ・実行されている非同期処理 ・永続化されたデータ ・障壁を回避するための方法論 ・シングルトンで定義して良いもの、ダメなもの ・非同期処理の管理方法 ・Daggerを使った永続化データのコンテナ化
Recently, Tumblr released Graywater, a RecyclerView library for decomposing large list items to improve scroll performance. This talk walks through how to build an advanced, flexible list implementation backed by Graywater and utilizing Dagger 2 multibinding to configure Graywater for different screens. Although Graywater has greatly reduced OutOfMemory errors at Tumblr, the library is not for all apps. The talk cover the benefits and limitations of Graywater in comparison to other recently-released RecyclerView frameworks, such as Litho and Epoxy, as well as implementation decisions and details.
デザインスプリントは短期間でプロトタイピングと検証を繰り返しアイデアを洗練させるGoogleの提唱するスタートアップ向けプログラムです。 本トークではデザインスプリントの紹介からワークショップの体験記、現場への導入まで、デザインスプリントをやってみてよかったこと難しかったことなどをお話します。 プログラミングに入る前からがアプリ開発です。 アプリ開発のための選択肢をより広げるために、デザインスプリントという手法のご紹介をできればと思います。
86件のセッション