マッチョActivityを改善した話

pairs(https://play.google.com/store/apps/details?id=jp.eure.android.pairs&hl=ja)でマッチョActivityを改善した話をします。
ざっくりと、pairsは以下のような不健康な状態でした。
- 1000行超えActivity/Fragment
- Viewのコードとビジネスロジックが交じり合うActivity/Fragment
- staticメソッド群で実装されたApiClient/DataAccessObject

このような状況で様々な問題に悩まされていました。
- どこになにが書いてあるのか分からない
- 手を加えたら思わぬところに影響がでた

*本発表ではアーキテクチャに関する詳細な解説等は行いません。
マッチョActivityを潰すためにどのように手を付けていったのか、進めていったのかをメインに話します。

目次(予定)
- pairsについて
- 改善前のpairs
- 改善の準備
  - ActiveAndroid->Orma/Retrofit 1->2
- 改善
  - Model
  - View

MVPだのクリーンアーキテクチャだのさまざまなアーキテクチャをAndroidに適用してみた話が花盛りですが、
他のプラットフォームでうまくいったアーキテクチャをAndroidに適用してうまくいくでしょうか？
アーキテクチャが何を目的としたものなのか正しく理解せずに、技術的なパターンだけ適用してうまくいくでしょうか？

このセッションでは特定のアーキテクチャではなく、ソフトウェア開発手法・設計理論であるDDD（Domain Driven Design : ドメイン駆動設計）をAndroidアプリ開発に取り入れる方法について話します。
DDDの内容については「エリック・エヴァンスのドメイン駆動設計」及び「実践ドメイン駆動設計」に準拠します。

対象者
- DDDについて正しく理解したい人
- 特定のアーキテクチャの技術的パターンだけを適用することに疑問を感じる人

マテリアル デザインが Google I/O 2014 で発表されてから 3 年近くが過ぎ、今では多くの有名アプリがマテリアル デザインに沿った UI/UX を提供するようになっています。一般の Android ユーザーも当然のようにマテリアル デザインに沿った体験を期待しています。
本セッションでは、マテリアル デザイン ガイドライン (material.google.com) と実際の実装の間に架け橋を築きます。ガイドラインの背景となる考え方を踏まえた上で Android アプリでマテリアル デザインを実装する際の指針を提案し、プラットフォームやサポート ライブラリの各コンポーネントとマテリアル デザイン ガイドラインの関係について議論します。また、Android マテリアル デザイン サポート ライブラリの開発エンジニアの一人として、古いプラットフォームも念頭に入れた実際の実装方法についてお話します。
あくまでエンジニア目線のセッションですが、UI/UX を形にしていく上での考え方を知りたいデザイナーにも役立つようにお話します。より良い UI/UX を実現するための具体的な観点を抑えた上で、それらを実際のアプリにするための技術を見ていきます。

Data binding is not yet widely used by Android developers, and those who do use it seem to limit themselves to just replacing findViewById. However, the possibilities of data binding are endless, and with the right architecture, your code can be much cleaner and a lot easier to understand.
This talk begins with explaining the basics of data binding, and then quickly moves on to more advanced techniques/functions.
-------
I find that data binding on Android has not gotten enough coverage, and the articles and talks that do appear are very basic and not based on real life usage. I want to make Android developers realize that there is a lot more to data binding than what they have been able to read so far and explain how to architect an app with data binding in mind.

■対象者
初級〜中級者
テストやリリース周りの仕組を整備していきたいと考えている人
リリース後のクラッシュ対応、レビュー対応について検討している人


■概要
僕が所属しているminneではAndroidチーム３人で開発しています。
複数人数で安定的にアプリをリリースしていく為には、テスト〜リリースまでの仕組を整える事が必要になってきます。
また、レビューの良い評価を維持していくために、レビューの対応についても実際にやってきた事を含めながらお話していきます。

具体的には、以下の内容を発表します。

- リリースフローにテストをどう組み込んでいるか。
- テストの種類
 - 自動的テスト
  - Unit test
  - UI test
  - CI
 - 手動テスト
  - 手作業による検証
- 構築しているCI環境の仕組紹介
 - Drone.io
 - DeviceFarm
 - Slack
- リリース前の検証について
 - リリース担当
 - 検証シート作成
 - DeployGate
- リリース
 - 段階的公開
 - Crashlytics
- リリース後
 - クラッシュ監視
 - レビューの監視
 - レビュー返信の体制

■対象
Android 初級者〜中級者

■内容
Android N になり、様々なSecurity関連のアップデートがありました。DirectBoot, KeyAttestation, NetworkSecurityConfig, ScopedDirectoryなど。
本セッションでは、AndroidSecurityの観点で、 API の紹介やその使用方法から、今のAndroidアプリセキュリティのベストプラクティスを考察します。また、Framework内でのアップデート、SelinuxやSignature関連もご紹介します。

■構成
* Android Security の概要
* Android N Security APIの紹介
* 実際の開発でのノウハウ
* Android Framework の最新Security事情

■本セッションに関連する話題
* Android Security
* AndroidFramework

Androidアプリのリリース自動化を導入したことによるメリットをお話したいと思っています。
対象者：特にレベルは問わないです。リリース作業が面倒だと感じている人にはおすすめできると思っています。

リリース自動化に関する知見は一部の人は持っていますが、実際に実行に移したり導入に際しての障壁などを経験していらっしゃる方は少ないようにも思えます。

大企業・スタートアップを問わず、リリース自動化によって受けられる恩恵は大きいのでその知見を共有することで、自動化についての知見が増えていけば、と思っております。

また、自社で開発しているアプリは国内では珍しいほどに海外比率が高いため、途上国向け開発をしてる上でなぜリリース自動化が非常に有効だったのかをお伝えできればと思っております。

トーク内容：
リリース自動化に使うツールの紹介
実際に使っているツールとそのツールを選んだ理由
導入方法を詳細に説明
実際にアプリの配信を自動で行ってみる
自社リリースフローの紹介
どういったことが大幅に解消されたかの紹介
多言語化対応時やAndroidアプリを途上国向けに展開するうえでリリースの自動化が生きた場面の紹介
などについて発表させていただきたいと思っています。

How many times have you started an ambitious refactor only to get lost and end up doing a git reset --hard? Android libraries are updated constantly, sometimes with breaking changes, and it can be tough to keep up. Maybe you want to try several new technologies at once as part of your refactor. This talk will teach you some techniques for refactoring your code in a way that makes you not get so overwhelmed that you have to start over.


This talk will focus on a refactoring strategy made popular by Sandi Metz, a prominent figure in the Ruby community. Even though writing code for Android is quite different from writing Ruby, the same techniques can be applied towards tackling a large refactor in any language or framework. I will discuss concepts such as “shameless green” (keeping a green test suite or other sanity check as you refactor), and detail how layering on your refactor in stages can be extremely effective in keeping you on track and moving you closer to your goal without breaking everything. It can be hard to keep up with new Android technologies, but a good refactor can be a great introduction to a new library or concept. This talk will contain a practical example of a refactor that introduces several new technologies to an existing Android app.

■対象者
初級者〜中級者
・メソッドが複雑にならないよう実践したい方
・Android Lint の Custom Rule と静的コード解析について理解したい方

■概要
TDDやDDDが喧しい昨今、コード実装の「単一責任の原則（SRP）」意訳⇒シンプル化が求められています。

Android Studio には、インスペクションという強力なソース解析(指摘)機能があることをご存知と思います。
問題点のある実装部をエディタ上でハイライト表示したり、「Analyze」メニューの"Inspect Code..."により、指摘一覧を「Inspectionツールウィンドウ」でカテゴリ別にリストアップもしてくれます。
独自の単一責任チェックのインスペクションが欲しいと思われていませんか。

実は、Android Studio のインスペクションには、Android Lint も利用されているのです。

Android Lint は、独自の Custom Rule を作ることができます。
そして Custom Rule を作るためにAST(抽象構文木)を使ったJavaソースコードの静的解析機能も提供されています。
この静的解析機能を利用した、単一責任となるシンプルな実装パターンを強制するオリジナルの Android Lint Custome Rule の
作成(方法)を中心にお話を進め、Android Studio での単一責任実装の実践(利用方法)について発表したいと思います。

ユーザが能動的に画面をリロードすることなく更新されていくリアルタイム通信型のアプリケーションはユーザに連続的な体験を提供することができます。
本セッションではスピーカーが過去に業務で利用したことのある次の3つのリアルタイム通信基盤を紹介し、それぞれの特徴や得意なこと不得意なことを紹介します。
・Socket.io (WebSocket)
・Firebase Realtime Database
・Realm Mobile Platform
また、リアルタイムに画面を更新する際のちょっとしたテクニックやTipsも合わせて解説します。

対象：初心者以上

　効率的に開発を進めるにあたり、欠かせないと言えるのがデバッグ作業かと思います。コード上ではエラー表示がなかったとしても、いざビルドを行えばエラーログが出力され、インストールに漕ぎ着けてもアプリを動かせば不具合が起き得ます。修正をするためには、その問題が何故どうして起きたのか、原因を特定する必要があります。
　Androidの開発では、開発環境のAndroidStudioに強力なデバッガが備わっています。また、各種ライブラリなどを利用することで、様々な角度からアプリの状態をチェックし、開発をより効率的に進めることができます。
　このセッションでは、Android開発をはじめたての初心者を想定し、エラーを解決するための糸口として、Android開発で使えるデバッグ方法について紹介を行うことができればと思います。具体的には、AndroidStudioでのデバッグ方法やライブラリの紹介などを行う予定です。

In Android Nougat 7.1 the ability to create app shortcuts was introduced. Implementing shortcuts into your app helps guide users to specific parts of the app. If implemented correctly, it can help simplify the way users interact with your app, thus providing a delightful user interface experience. In this talk we will see an example of how to create app shortcuts. We will also talk about the different kinds of shortcuts you can create (static and dynamic) and how to chose which one to implement. Lastly, we'll talk about how to create a proper back stack of activities once the user launches the app through a shortcut. By the end of the talk attendees should have a clear understanding of how to help increase user engagement by making it easier for users to use their app.

「はてなブックマーク」の Android 版アプリは、2011年にリリースして以降、大きな変更を行うこと無く新機能のリリースや、不具合の修正を続けてきました。しかし初回リリースから5年が経過した今、アプリの規模は非常に大きくなり、相応にコードの複雑性も増し、コード改善の必要性を感じるようになりました。

しかし長年積み上げられてきたコードの複雑性を解消するためには、小手先のコード改善ではもはや大きな効果はありません。根本からの見直しが必要です。アプリのアーキテクチャを見直し、旧コードをすべて新たにし、モダンにして行かなければなりません。これはもはやリファクタリングではなく、リノベーションと呼べる非常に壮大なものです。

リノベーションにあたり、まず初めに取り組んだのが「画面の確認」でした。どの画面がどこから来ているのか。この画面にはどのような機能があるのか。この画面のデザインの意図は何か。ある画面とある画面の共通の View はなにか。叩いている API は何なのか。そのモデルクラスは何か。すべてを一つずつ再確認し、機能を整理し、新たな名前をつけ、それらをドキュメントに落とし込んでいきました。

次に取り組んだのは新たな設計の考案でした。まずはライブラリの選定を進めました。近年の Android 開発では有用なライブラリが数多く存在します。例えば Rxjava、Realm、DataBinding があります。これらは開発に大きなメリットをもたらしますが、これらのライブラリには設計を大幅に左右する特性があります。Rxjava を採用すればリアクティブプログラミングがアプリ中に適用されたものになりますし、Realm を採用すれば、Realm で引いたデータを常に監視する設計が考えられます。また DataBinding を利用する場合、自然と MVVM にたどり着くことになります。

つまりライブラリを選ぶということは、同時に設計の形も選ばないといけないのです。そのためにアーキテクチャの選定もほぼ同時期に行うことになりました。世の中には様々なアーキテクチャがありますが、どれを選択すべきなのかは非常に難しいものでした。アーキテクチャをそのまま当てはめようとしても、どうしても Android フレームワークや、アプリの機能、ライブラリの特性にそのままでは合致しないケースがあり、ただアーキテクチャをそのまま選択すればよいというものではありませんでした。

設計の難しさは、これらの組み合わせにあります。Android のフレームワーク、様々なライブラリ、そして提言されているアーキテクチャ。これらを組み合わせ、ベストな設計を作り出さなければならないのです。勿論その設計は変更に強く、メンテンスがし易いものでなければなりません。加えて、我々のアプリでは「５年先も機能を拡張し続けることの出来るアプリ」を目指すという目標があります。

今回のリノベーションでは、アーキテクチャをそのまま利用するのではなく「アーキテクチャの良いところを可能な限り利用するとともに、どうしても実態にそぐわないアーキテクチャの定義は、少しアレンジする」という手法で、設計に落とし込むことになりました。そしてこの設計もすべてドキュメント化し、今後の開発方針がぶれないように徹底しました。

本セッションでは、大きなアプリケーションを作り変えるために行った手法について話します。また、Android のフレームワークと適合したアーキテクチャを模索した結果、導き出した設計についても話したいと思います。

■概要
Google Play Servicesには様々な機能がありますが、あまりよく知られていない機能も多くあります。
その中から今回はGoogleサインインを簡単に実装するためのGoogle Sign-In API、Google+1ボタンを簡単に実装することができるPlusOneButton、メールやSMSで友人・知人を簡単に招待できるApp Invites、Google Play Servicesに依存しているFirebaseの一部の機能についての実装方法や実装してどう変わったのかなどの検証結果についてお話します。

■対象者
- Androidアプリ開発をある程度やったことのある人
- App Invitesに興味がある人
- Google Sign-In APIに興味がある人
- ASOが気になる人

■目次案
- Google Sign-In API
  - 以前のGoogleサインイン
  - APIの概要
  - このAPIの何が良いのか
  - 実装方法・サンプルコード
- Google Plus One Button
  - Google+1ボタンとは
  - Google+1はGoogle Playの順位に影響するのか
    - やったこと(どう実装したのか)
    - 検証結果
  - これはやるべきなのか
- App Invites for Android
  - App Inviteとは
  - App Invitesのフロー・仕組み
  - Firebase Invitesと何が違うのか
  - App Invitesの数値のとり方
  - 実際に実装して検証してみた結果
  - これは導入すべきなのか

Android 開発はボイラープレートを書くのが辛くないですか？findViewById、view.setText、view.setOnClickListener、nullチェック等。。。これらを少し楽にしてくれるライブラリはいくつかありますがそれでも完全に解決しません。Beta が取れ、実用段階に入った Android の新ライブラリ Data Binding によって圧倒的に行数を減らしてボイラープレートの問題は解決できるし、Data Binding は一部だけに適用もできるので規模を小さく、安全に少しずつ導入する事が可能です。

下記のネタをカバーします：
・Data Binding 移行の各ステップ
・裏で行われている仕組みの説明
・Data Binding におけるベストプラクティス

このセッションに参加された方は自分のプロジェクトを Data Binding へ移行するのに必要な知識を持ち、Android 開発を気持ちよくできるような人になるはず！

対象: 初心者以上

「n時間おきに〇〇(任意のタスク)したい」という機能を実装することになった場合、Android SDKが提供しているクラスだけでも幾つか選択肢があります。
また、利用するクラスやOSのバージョンによって期待できる精度や条件、振る舞いが異なります。
本セッションでは、JobSchedulerの解説を中心として、2017年に定期実装処理を組み込むなら知っておきたい情報を基礎的な部分から紹介したいと思います。

現在予定している目次:

* AlermManagerを避けたい理由について
* JobSchedulerについて
* 期待できる精度の件について
* firebase-jobdispatcher-androidなどのバックポート系ライブラリについて
* その他の選択肢について
  * push通知を利用するなど
* アプリアップデート時やOSアップデート時などのそれぞれの挙動について
* 動作検証時に確認しておきたい項目について

Androidでは、resディレクトリ下で様々なリソースをxmlで管理しています。
リソースはアプリの規模が大きくなるにつれて増えていき、秩序のない状態になりがちです。
開発しているアプリのcolors.xml、styles.xmlが綺麗に整理整頓されていると言える人の方が少ないのではないでしょうか。

私の所属するQuipperでは、デザインの統一に合わせて無秩序だったリソースまわりを整理しました。
デザインの変更にも強い設計で、エンジニアがデザインの実装で困ることも少なくなり、今見てもかなり綺麗に整理できていると思います。

このセッションでは、colors.xml、dimens.xml、styles.xmlなどのリソースの要素の命名やファイルの分け方について私なりの理想の指針を説明します。
その上で、既存のアプリのリソースをどうやってその理想の状態まで修正していったのか、チーム内でどうやって情報を共有していったのかといった、
『リソースまわりのリファクタリングをどう進めていくか』という泥臭い知見もお話ししたいと思います。

アプリのリソースを綺麗に保ちたい方、あるいは綺麗にしたいけれども効果や進め方がわからず足踏みしている方のお役に立てば幸いです。


## 草案（仮）
- Quipperでのリソースまわりの指針（命名規則、ファイル分割規則）
- styles.xmlは機能/画面単位で分割しよう
- リファクタリングBefore/Afterのインパクト
- リファクタリングのロードマップと締切の設定
- リファクタリングはcolors.xml、dimens.xmlから始めよう
- チーム内でデザイン番長を決めよう
- 規則をwikiに書いて共有しよう
- 細かい修正タスクを洗い出して他のメンバーに練習させよう

対象：
Android開発の経験がある方、興味がある方


概要：
業務で開発していたトーク機能を持つアプリに独自絵文字を実装した話をします。

誰かとメッセージのやりとりをする際に、単純な文字だけ送るよりも絵文字を追加することで表現豊かなメッセージを送ることができます。
絵文字はガラケーの時代から存在しており、スマホがメインになった現在においても
キャリア独自の絵文字やキーボードアプリ独自の絵文字など様々な絵文字が存在しています。
私が開発していたトーク機能を持つアプリでもそういった絵文字が多く使われていましたが、
端末の違いによって送信側と受信側で異なる表示になってしまうことも少なくありませんでした。

そこで、アプリ独自絵文字を実装することで絵文字を使った表現豊かなメッセージを、表示の違いなどが起きないよう可能にしました。
実装にあたってはトークで使うため表示の高速化や絵文字自体のクオリティにも注意して実装していました。
発表では実装にあたって苦労した点、どうやって乗り越えたか、そこから得た知見などお話できればと思います。


目次（予定）：
- 絵文字導入にいたる経緯
- 絵文字導入前に必要な機能を洗い出す
- 実装中にあたった壁と解決方法

アルファ版、ベータ版としてapkファイルをGoogle Playにアップロードする際に、
pre-launch reports(日本語訳はリリース前レポート、オプトインが必要)によりアプリに含まれる問題点が表示されるようになりました。
表示される内容の一つに、「セキュリティ」があり、アプリ中の脆弱性を表示してくれます。
しかし、どのような脆弱性が検出されるのかについては明かされていません。

本セッションでは、リリース前レポートがどのような脆弱性を検出する傾向にあるのかをお教えいたします。
また、その結果を踏まえたうえで、リリース前レポートとどのように付き合うべきか考察します。

言及する脆弱性は、日本スマートフォンセキュリティ協会が発行している「Androidアプリのセキュア設計・セキュアコーディングガイド」で言及されている内容を元に調査したものとなります。
なお、調査を行った時点での内容となります。

■対象者
-Android開発初心者～中級者
-Androidアプリの脆弱性対策に興味のある方

## 対象者
- 初級〜中級者
- アニメーションに苦手意識がある人

## 概要
AndroidでViewに対するアニメーションを実装する方法は様々ですが、基本は諸々のサイトで解説されています。
しかし、その多くは拡縮や移動またはそれらの組み合わせといったシンプルな実装の紹介に留められており、複雑なアニメーションを実現する際の知見はあまり見られません。
複数の要素が相対的に異なる動作をするViewなど、実践的なアニメーションをどのように実現するのか……。
本セッションではアニメーション実装へのアプローチや手法などを具体的に紹介することで、今まで何となくアニメーションにネガティブなイメージを持っていた方々に苦手意識をなくしてほしいと思っています。

Kotlinの特徴的な機能としてnull許容型や関数型や拡張関数などがよく取り沙汰されます。null安全だとか高階関数で簡潔に記述だとか拡張関数便利最高といった話は枚挙に暇がありません。確かに言語機能としていろいろとJavaに比べて便利なのは分かるんだけど、でもまぁ別にJavaを使っていてクリティカルに困っているわけではないしな〜学習コストとかチームへの導入コストを考えるとそこまで旨味を感じられるわけでもないしな〜みたいなそんな気分。わかります。

本セッションではKotlinのコードをコンパイルして得られるJavaバイトコードを、可読化したりデコンパイルする事によって、Kotlinの特徴的な言語機能がJavaでどのように表現されているかを読み解いていきます。これによりKotlinが肩代わりしてくれるボイラープレートコード群を明らかにします。Kotlinを使うことで省略できたボイラープレートコードが可読性をどのように高め、設計に影響を与えるのかについても言及します。

目次案
- Kotlinの概要
- 本セッションのアプローチ
- null許容型の正体
- 関数型とラムダ式の正体
- インライン関数の正体
- 拡張関数の正体
- データクラスの正体
- プロパティの正体
- デリゲートプロパティの正体

■対象者
Android開発をまだやったことない or はじめたばかりの人
Android開発の今を知りたい人
Android開発 やっていくぞ💪 という気持ちの人

■概要
Android開発の現状は日々変化し続けています。
OS、デザイン、開発ツール、ライブラリ、テスト、設計など日々小さくても様々な変更があり、色んな情報が飛び交います。
「Android開発難しそう」と感じたり、「やってみたけど何から始めたらいいのかわからない」みたいな経験をした方もいるかと思います。
しかし、大事なポイントを少しずつ抑えていくことによって、Androidを継続的に学べるようになります。

本セッションでは、私が過去・現在経験してきたことも交えながら、Android開発をやっていく上で大事なポイントをお話したいと思います。
まず、Android開発を始めるにあたり、何からはじめたらいいのか、継続的に学ぶために何をしたらいいのかなどを話します。
次に、実際にアプリを開発することを想定して、どのようなAndroidの技術が必要なのかなどを話します。
最後に、Android開発の現状や新しい情報をどのようにキャッチアップしていくかなどを話します。
※話す内容が幅広いジャンルを扱う可能性があるため、具体的な実装やコードは少なめになる予定です

内容案：
* どのようにAndroidを学ぶのか
* 作るアプリによってどのようなAndroidの技術が必要なのか
* 新しい情報をどのようにキャッチアップしていくかな
* 開発に役に立つ情報はどこで手に入れるか
* Android開発の今とこれから

モバイルアプリケーションを最優先に位置づけるモバイルファーストという考え方が広まってずいぶんたちました。モバイルファーストはさまざまな要素を含むものですが、その中でもオフライン時の使い勝手を考えることはとても重要です。

このオフライン時のアプリケーションに着目した概念にオフラインファーストというものがあります。

発表ではオフラインファーストとはどのような考え方なのか、また実際にAndroidアプリケーションをオフラインファーストな考えに基づいて開発する上での技術的課題の整理とそれらを乗り越えるための具体的な方法をお伝えします。

■対象者
・Espressoに興味は有りつつも、取り組む時間がなくて実行に移せていない方
・効率的に、メンテナンス性の高いEspressoテストコードを書きたい方

■概要
AndroidのUIテストツールであるEspressoは、
Android Studio 2.2から導入されたEspresso Test Recorderによって、テストを書く敷居が大きく下がりました。

しかしながら、単純にEspresso Test Recorderに頼ってテストを量産すると、
重複したコードが多数出現してしまい、画面仕様が変更された時に手が付けられなくなってしまいます。

このようなメンテナンス性の問題を解決するためには、量産したテストコードを適切に共通化する必要がありますが、
量産してしまったコードを後から共通化するのも骨が折れる作業です。

このセッションでは、業務でテストの書き方を支援している自身の経験にもとづいて、
効率的にテストコードを生成できるEspresso Test Recroderの利点を活かしつつも、
メンテナンス性を損わないテストコードを書く方法について、
ライブコーディングを交じえながら解説します。

主に、以下のような内容を考えています。

- Espressoテストコードの基本
- Espresso Test Recorderの限界を理解して、うまくテスト自動化対象を選定する方法
- Espresso Test Recorderで何を記録すべきか
- 記録したテストコードを元に、メンテナンス性を損なわずにテストを量産する方法
  (Android Studioのリファクタ機能を活用します)

個々の要素は基本的なことではありますが、
「どのように組み合わせるとうまくいくのか」という知見を皆さんと共有することで
「テストを書いてみよう」と思って下さる方が増えるような内容にしたいと考えています。

Creating optimized layouts is a stubborn task, Android developers need to spend considerable amount of time on it because there are some common pitfalls with existing layouts (LinearLayout, RelativeLayout, etc) and there are lots of screen sizes they need to care considering the device factors (screen size, density, orientation, multi window mode from Nougat).

In this talk I'm going to cover the two new layouts that were introduced from Google in 2016, ConstraintLayout and FlexboxLayout.
The topics will include Android views in general, what are the common pit falls of existing layouts, basics of the new layouts and what common layout problems they try to solve.

Disclaimer: the presenter is the author of the FlexboxLayout, but I'll try to explain the unbiased pros and cons regarding the existing and newly introduced layouts from technical point of view.

## 対象者
アプリのViewにユーザーの操作に追従する動きを入れたい人

## 概要
HoloやMaterialデザインが発表されて以降、Viewを動的に変化させることが多くなりました。Viewを動的に変化させるといっても単にアニメーションで動かすだけでなく、最近ではスクロールのようなユーザーの操作に追従して変化させるケースも増えてきています。
単一のViewを変化させるだけならばViewクラスのsetTranslationXメソッドやsetScaleXメソッドなどを使用すれば可能です。しかし、レイアウト全体を変化させたい場合、Javaのコードだけで行おうとするとかなりの量の可読性の悪いコードを書かなくてはなりません。更に、その際にAndroidフレームワークの邪魔になる書き方をしてしまうとレイアウトが崩壊する危険性があるため、そうならないように注意して実装する必要もあります。
本発表ではそれらの課題について、どのようにすればユーザーの操作に追従したViewの変化を実現しつつ、可読性を保ったコードが実装できるかについてのアプローチをお話いたします。

## 発表の構成
- レイアウトXMLの考え方
- Javaからコードを割り込ませる方法
- DataBindingを使う理由

## 関連するキーワード
- レイアウトxml
- DataBinding

【対象者】
・新しく入ったプロジェクトのテストをどうにかしたい人
・現状のテストの信頼性に不安のある人
・テストを書くときどこまで書けばいいのか分からない人
【内容】
BDDを始めとする思想では、テストを用いてそのアプリケーションの動作を保証・信頼します。
テストがないプロジェクトは信頼できない。という話を聞いたりもしますが、では「存在するだけ」で信頼できるものでしょうか。
あるいは「信頼できるテスト」は開発者にとって常に「良い物」なのでしょうか。
各開発者が持つテストに対する意識が異なる場合、テストの粒度はまちまちとなり、信頼できるテストとできないテストが混在するでしょう。
またどんなにテストを信頼していたとしても、記法・表現方法などの問題からテストを書くこと自体が負担となることもあります。

途中参加した2つのプロジェクトに対して導入したテストドキュメントの整備方針などから、具体例を交えつつ、上記の問題点をどのように解決するのかをお話できればと思います。

コンテンツ
・テストストラテジーの作成
・テストポリシーを用いた開発者間の意識共通化
・Test doubleという考え方のおさらい
・Test Size
・設計思想に合わせたテスト作成ポリシー
・MockableなAPI

2015年初めにオープンソースプロダクトとして登場したReact Nativeは、現在も活発に開発が続いています。Facebook Messengerだけではなく、プロダクションでの事例も少しずつ出てきました。
React Nativeを使うと、何が嬉しいのでしょうか。実際に業務でAndroid, iOS両対応のアプリを開発・リリースした経験から、Android Javaでの開発と比べて楽になる点や難しくなる点をお話します。

＜対象＞
* 最近のJavaScriptはどんな空気感で開発をしているのか見てみたい方
* 心のどこかでまだReact Nativeを銀の弾丸だと思っている方
* AndroidとiOSのコードはどこまで共通化できるのか知りたい方
* Webフロントエンドのコードとはどこまで共通化できるのか知りたい方

＜話したいこと＞
* NodeJS, NPM文化圏とES2015+CSS3がもたらすパラダイム
    - Promise
    - fetch
    - module
    - 様々なJSライブラリ
    - Flexbox
* FlowTypeでJSなのに静的型付けできた話
* Hierarchy Viewerで分かった、Virtual DOMの先にあるAndroidネイティブの姿
* Webフロントエンドエンジニアたちとライブラリを共有できて最高だった話

■ 対象者
初級〜中級者向け
■ 内容
Android 7.0 SDKからStreamやOptionalなど、Java 8で導入されたAPIが一部使えるようになりました。ただし、これは応募時点(2016/10/01)ではJackコンパイラを使う場合に限られていて、実践導入はまだ先になりそうです。そこで、以前から話題となっているRxJavaや、Stream/OptionalのバックポートライブラリであるLightweight Stream APIを活用して、来たるJack時代のAndroidアプリ開発について先取りできるお話をしたいと思います。

プリミティブなAndroid SDKのAPIを使う場合と比較してどのようなメリットがあるのか、デメリットは何があるのかといった話や、RxJava/Lightweight Stream APIを実践導入して得られた知見を皆様に共有できればと思います。

特にLightweight Stream APIに関しては単なるバックポートではなく、独自の機能も持っていて、Android開発において特にFragmentを使うときにちょっと便利なユーティリティとして機能します。Android開発においてはメリットがあるライブラリだと思いますので、この知見については一番共有できればと思っています。

Can make talk 30-50 mins, flexible.

We spend a lot of time putting apps together, but when was the last time you pulled one apart? How wonderful is it that Android is open-source, so we can simply look at the code when we need to? What if it were just as easy to look at the source code and behaviour of any other app?

If we can streamline the process of looking inside a compiled application then we're more likely to employ it to answer questions and teach us valuable lessons we can apply to our work. We may learn from others and also make our own apps more secure. We can pinpoint bugs that come from closed-source libraries such as those for ad and tracking networks, and work around those bugs, get them fixed faster, or even patch them if need be!

This talk will present simple real-world examples for maximum practical benefit using some of the ever improving set of reverse engineering tools for Android.

You don't need to have any experience reverse engineering anything before, but hopefully even if you do you'll pick up a few useful tips. This talk aims to make every developer more familiar with the reverse engineering tools available for Android, and how and why they should apply them. There's an incredible amount that can be learned from taking things apart!

通常のアプリ開発時にはほとんど見ないといっても過言ではないAccessibilityService（ユーザー補助機能）。本来はその名の通り老人や盲目の方など視覚にハンデがある方に向けた補助機能ですが、他のアプリの情報が取得できたりそれを活用したりできるため、使用方法次第ではアプリの幅がぐっと広がる技術です。本セッションでは、AccessibilityServiceそのものの話やAccessibilityServiceを使う上での基本的な機能紹介を踏まえた上で、スピーカーが実際に開発したデザイン確認やデバッグのためのツールを紹介し、AccessiblityServiceで出来ることと可能性を提示します。

構成
- AccessibilityServiceってなんなの？
- AccessibilityServiceの基本〜はじめてのAccessibilityService作り〜
- AccessibilityServiceで出来ること、出来ないこと
- AccessibilityServiceを使ったアプリ紹介
  - 実際に書いてみてハマったポイントなど

Android Autoはちょっと手が届かない…けどBike(自転車)なら!

「最近購入した自転車がBluetoothを喋るので何かやってみよう」Androidならそのぐらい気軽にIoTできるよ、ちょっと頑張れば既にある製品より圧倒的に使いやすい機材を自分で作れるよ、という話を、ある程度Android開発に慣れてきた開発者向けにお話しします。身近なBluetooth Low Energyデバイスや実はあんな家電もこっそり生えてるAPIに、スマホのユーザーインタフェースを組み合わせることで、手軽に自分専用の道具を作ることができます。このセッションが、普段開発しているスマホやタブレットという枠を超えた外の世界とインターネットを繋いで、世界にカジュアルに新しい価値を提供していくきっかけになると幸いです。

いま RxJava 1.0 を使っている方を対象に、RxJava 2.0 の変更の背景や RxJava 2.0 での変更点、どのようなことに注意するべきかを説明します。

RxJava 2.0 は 2016 年の 10/29 に公開された、RxJava の新しいメジャーバージョンです。1.0 に比較すると以下のような変更が入っています。
- Java 9 で標準となる予定の Reactive Streams 対応
- 分かりにくかったメソッド名やクラス名の変更
- いくつかの API の挙動の破壊的な変更

RxJava 2.0 では、RxJava 1.0 で実現できたことは、ほとんどそのまま実現できます。一方で、RxJava 2.0 なりの書き方をすることで、より Rx や Reactive Streams の恩恵に与れるようになっています。本セッションでは、RxJava 1.0 でいま Android アプリを書いている方向けに、2.0 での変更点やどのように 2.0 の機能を利用するのが良いかという話を述べます。特に 2.0 での変更の背景となった Reactive Streams がどういうものかというところから解説することで 2.0 の目指す姿を明らかにしたいと考えています。

[対象者]
初心者〜中級者向け

[内容]
Androidを開発、運用していく中で起こるつまづきやすい問題の解決、
ちょっとしたことで開発が幸せになるテクニックを紹介。
本質的な作業に集中できる時間を多く取れるようにしたいと思っています。

以下は仮予定の内容です。
問題
- ProGuard問題
    - なぜProGuardで、ビルドができなくなるのか
- メソッド数64k問題
    - 64k問題とは
    - メソッド数を知る
    - メソッド数を削減
    - 限界突破の方法
便利
- Android Studio2.2の機能
    - リファクタリングで役立つショートカット
- Google Play Console関連
    - 通知を受け取る
    - クラッシュレポートの難読の解除
- Gradeの設定
    - キャッシュ周り
    - 署名の設定

■対象者
・Android中級者〜
・C# 初心者〜

■概要
Xamarin（ざまりん）は C# によるクロスプラットフォームモバイルアプリ開発ツールです。
Microsoft が2016年4月に買収して、一気に知名度が上がりました。

このセッションでは、 Xamarin とは、Xamarin.Android とは何か、C# や .NET Framework(Mono) の強力な言語・ライブラリ機能について触れ、通常の Android アプリ開発と Xamarin を使ったアプリ開発はどこが違って、どこが同じなのかを説明します。

また、今日のモバイルアプリ開発では、DataBinding、MVVM、Reactive Extensions(Rx) といった、Microsoft が源流となっている手法が広まって来ています。
Xamarin を使うと、MVVMパターンと Rx を使用し、大部分のコードを共有できる Android/iOS 両対応アプリケーションを開発できます。如何にしてコードを共有するか、できない場合にどのような解決策が用意されているかについてお話します。

■目次（仮）
1. Xamarin とは？
・Xamarin とは何か
・Xamarin.Android とは何か
・C# の利点(Java, Swift との比較)

2. クロスプラットフォームアプリ開発とコードの共有
・MVVMパターン
・Reactive Extensions / ReactiveProperty
・Portable Class Library(PCL)によるコード共有
・プラットフォーム固有の処理を行う方法

3. Open Xamarin、Open Microsoft
・Xamarin で使えるライブラリ(C#, Java)
・All Xamarin SDKs are open source
・.NET Standard

4. Xamarin の使いどころ
・採用すべきケースとしなくてよいケース

対象: 初心者~中級者向け

Android ORMは古くて新しいテーマです。以前はActiveAndroidやGreenDAO、そしてORMLiteくらいしか選択肢がありませんでしたが、近年は綺羅星のごとく新しいライブラリが次々に生まれています。また2016年3月に1.0となったRealmというSQLiteベースでないORMも人気を博しています。また発表者はOrmaというORMを開発しており、ORMには一家言ある開発者です。

さて、このORM百花繚乱というこの状況は多様性という意味では喜ばしいものですが、逆に選択肢が多すぎて選択するのが難しいという状況となっています。その結果、もっとも著名なORMである、しかし今やメンテナンスされていない古いライブラリであるActiveAndroidが使われ続けるということも少なくないようです。これは大変残念です。

このセッションでは、Realmを含むさまざまなORMを、インターフェイス・マイグレーション・パフォーマンスについて比較検討します。本セッションがORM選択の一助となれば幸いです。

## アウトライン（仮）

* なぜORMが必要か
	* ORMは怖くない
	* リソースのキャッシュ
	* ローカルのデータストア
* 素のSQLiteDatabaseの基本
* ライブラリ一巡り
	* Simple Helpers
		* ORMLite
		* SQLBrite
		* SQLDelight
	* O/R Mappers for SQLiteDatabase
		* ActiveAndroid
		* GreenDAO
		* DBFlow
		* Requery
		* Orma
	* Non-SQLite Databases
		* Realm
* インターフェイスの詳細比較
* パフォーマンスの詳細比較
* マイグレーションの詳細比較

本セッションでは「AndroidってSDカード使えるんでしょ？」と急に出てきたちょっとヤバそうな仕様との付き合い方、
「気づいたらアプリで容量使いすぎて死にそう」という機能要件をクリアするためのストレージ戦略を解説します。
内部／拡張などストレージの種類を問わず、アプリがデータを保持するための最適な場所について横断的に考察します。

今は昔、古来のAndroidアプリではSDカードのパスを探すだけで一苦労がありました。
現在、Android SDKが提供するExternal Stroage APIでは拡張ストレージへのアクセスを可能にしており、
アプリはより多くの情報を拡張領域に保存できます。

セッションではアプリケーションの種類や保存するコンテンツの性質を考慮しながら内部／拡張ストレージを上手に使い分ける方法を紹介します。
利用にあたってはマルチアカウント、端末の空き容量、クラウド連携、暗号化など設計上考慮すべきポイントを押さえつつ、
過去のTipsが今も使えるのか？という疑問やAndroidアプリ開発のスタンダードは存在するのか？という設計上の課題を解消します。

Intents are an essential component of the Android ecosystem. They are used to express an action to be performed and can be classified into implicit and explicit intents. In an abstract way, all intents together define a navigation layer inside an application.

During this talk we will explain why the Android way to create explicit intents is error-prone and also show some problematic ways to solve it. Then, we will introduce the solution we developed at Groupon: Henson, a new library in the Dart project, that takes intent creation to new levels: It generates a fluent API to build intents. This API constitutes a navigation layer that makes it easy, convenient, fast and robust to navigate among your activities and services. Therefore, it will be impossible to miss a required extra and simple to add optional arguments as needed.

The talk will be based on the following article featured by Android Weekly:
https://medium.com/groupon-eng/better-android-intents-with-dart-henson-1ca91793944b#.4h12yxgtl

Furthermore, all the library features and possibilities will be explained in depth.

This intermediate level talk about Dart & Henson will be carried out using slides, code and demos.

▼対象者
初心者〜中級者

▼概要
Androidアプリ開発で避けて通れないパフォーマンス改善ですが、細かいtipsなどの話がされがちです。どこから手をつけていいのか、どうやって調査していくのかのノウハウはあまり多く語られていません。

本セッションでは実際のオープンソースのアプリ(Android N Easter Egg Neko) を題材に、パフォーマンスが悪化した際に「どのように調査するか (Android Studioなどのツール使い方)」から「実際のコード改善」までの一連の流れをお話しします。皆さんが自分のプロダクトで実際にパフォーマンス改善できるようになる知見を共有するのがゴールです。
また、初心者でも手をつけやすいよう、普段から開発者が慣れ親しんでいるAndroid Studioやadbのツールを取り上げたいと思います。

▼取り上げる予定のツール
・adb systrace
・Android Device Monitor

■概要
Data Binding使うことでAndroidでもMVVM Architectureが簡単に実現できるようになりました。View-ViewModel-Modelの責務を明確にすることで、見通しの良いコードが記述できるようになります。MVVMで実装する時のポイントなどについて話します。
MVVMの導入を検討している方や、興味のある方の参考になれば幸いです。

■内容案
* MVVM概要
* Data Binding概要
* Viewの役割、実装例
* ViewModelの役割、実装例
* RxJavaと組み合わせる

■対象者
設計に興味がある方

対象: 初心者〜中級者

- Kotlin(Language)どうなの?
- RxJava(ReactiveProgrammingFramework)どうなの?
- Dagger2(DependencyInjection)どうなの?
- Orma(ORMapper)どうなの?
- Retrofit(HttpClient)どうなの?

そんな疑問にお答えします。
(個人的には)もはやこの5つのソフトウェアはAndroidアプリケーション開発において無くてはならない存在です。
これらを利用したAndroidアプリケーションの作り方を紹介したいと思います。

目次(予定)
- 各ソフトウェア軽い紹介
    - Kotlin?
    - RxJava?
    - Dagger2?
    - Orma?
    - Retrofit?
- DroidKaigi2016公式アプリのコントリビューター一覧画面を作ろう
    - RetrofitをつかってApiClientを実装しよう
    - OrmaをつかってDaoを実装しよう
    - Daggerを使って依存性を注入しよう
    - ApiClientとDaoを束ねるRepositoryをつくろう
    - UseCaseをつくろう
    - Presenterをつくろう

知ってます知ってます。いまの最新版（droidkaigi開催当時）って7.1であることを。

とはいえAndroid 7.0対応の前にAndroid 6.0の対応が出来てないまま、誤魔化し誤魔化しアップデートを続けているアプリがあるんじゃないでしょうか？
いまはなんとかなっても、いつかはどうにもならず「苦渋の決断」をする日がくるのではないでしょうか？

本セッションでは7.0に向けた復習として、自分が業務で「いやここで対応すべきだ」と決断していくつかのアプリを6.0対応した際に得たノウハウを共有いたします。さあ、みなさんも早いうちに6.0対応を果たし、気持ちよく7.0対応を迎えましょう！

主に話す内容
* Apache廃止に伴う対応（さよならVolley、こんにちはokhttp）
* パーミッション対応と、コード以外に考えること
* その他、Android 7.0に加え、さらにその先のアップデートに備えて気をつけることはなにか

■対象者
SystemアプリおよびAndroid Frameworkの開発者
初級〜中級向け

■概要
Systemアプリ開発入門
一般的なアプリと同じく、端末にプリインストールされるアプリについても
OSのアップデートと共にセキュリティ観点のアップデートが多く含まれてます。
プリインなら何が可能なのか、何が不可能なのか、一般的なアプリと違いどんなことに
気を付けて開発をしなければいけないのか。その開発手法についてのノウハウをお話しします。

- Systemアプリ開発入門
 - Systemアプリ概要
  - 一般的なアプリとの違い、権限の違い
 - 権限とSystemアプリ
  - HideAPI,SELinux,Platform署名
  - Device Owner
  - Nugarでどう変わった？
 - マルチユーザーとPlatformアプリ
  - マルチユーザに対応するために
  - ユーザ間で共有したい情報を保持するために
 - Debug手法
  - Using AndroidStudio
  - BreakPoint
  - Test
 - （おまけ）Systemアプリ開発でもいろいろしたい
  - 著名Library使用(APT)などなど

■キーワード
プリインアプリ、Platform署名、Framework、SELinux、RuntimePermission、CTS、マルチユーザー

■対象者
初心者〜中級者。
最近Androidアプリ開発を初めた人やチームで開発を初めた人。

■内容
フリマアプリ「フリル」は今年で4周年を迎えました。
その中でも何度か大きなリニューアルを実施してきました。

コードベースも必然と大きくなり、複数人で大規模アプリのメンテナンスをし続けながら、機能追加などをしてきました。

このセッションでは4年間の中で、チーム開発がどのように変化してきたのか、
どういったことをやってきたのかをお話します。

・開発フロー
  ・開発環境
  ・コードレビュー
  ・プルリクエスト
  ・CIの変遷
  ・社内ユーザーインタビュー
  ・QAのやり方
  ・リリース
・数値計測
・リニューアル
・レビューマネジメント

概要:
TVデバイスは前前前世からブラウン菅→液晶→３Dと渡り歩き、
スマートテレビに辿り着きました。
近年、 本格的にAndroidを搭載したTVデバイスが普及し始めています。
みなさんのアプリはTVデバイスに対応していますか？
私が担当しているプロジェクトでは先日FireTV/AndroidTV（仮）に対応しました。
しかし、現状TVデバイスに対応するための知見はまだまだ少なく、
スマートフォン向けのアプリ対応と比べて開発の敷居が非常に高いと感じています。
　
このセッションでは、
今後TVデバイス向けアプリ開発を検討している人にフォーカスし、
導入→開発→運用と実践的な話をします。

　主なキーワード: FireTV, AndroidTV, Leanback

対象ユーザ:
	・スマートフォン向けAndroidアプリ開発経験がある方

■対象
Android アプリ開発経験者初級者〜上級者
音声認識に興味があるが、触り程度しか使っていない方

■内容
近年Googleの「OK google」のCMや、iOSのSiriの普及により、スマートフォンで音声認識を行うことが一般的になってきた。これらの技術には音声認識技術が使われていることが明らかではあるが、文章入力なのか、コマンド入力なのか、学習データ入力なのか等用途によっても様々な手法を扱われる。本セッションでは、これらの様々な手法を解説するとともに、実際に自分で開発・実装するにはどうすれば良いのかを示す。

■構成
* 音声認識の概要
* Android Speech Recognizerを使いこなす
* 様々な音声認識エンジン
* 連続音声認識とは
* 自分のアプリで「OK Google」のような機能は作れるのか
* 音声認識機能全般の評価について
* Drivemodeでの活用

■本セッションに関連する話題
* 音声認識
* 音声認識エンジン
* 雑音抑圧
* Android
* Service
* プロセス間通信
* AIDL

Can make talk 30-50 mins, flexible.

Have unit tests? How readable are they? How much time do you spend maintaining them? Brittle and time-consuming tests lead to fear, uncertainty, and distrust, and that leads to and eventual disillusionment and abandonment.

This talk will go over tools and techniques for writing tests that are a pleasure to read, easy to maintain, give you maximum return on the time you invest into them, and will prove their worth time and time again.

We'll take a look at some example tests that are exhibiting some common issues, such as:
 - readability
 - brittleness: breaking every time the implementation is changed
 - non-obvious cause + solution upon test failure
 - flakiness / unreliability
 - slow execution

We'll improve these tests in plain JUnit, move on to Hamcrest and AssertJ, and then show how Spock can take us even further to tests that are beautiful, easily maintainable, and incredibly useful.

Stop wasting time on bad tests!

This talk aims to level-up every Android developer's testing know-how and arm them with the tools required to write effective and maintainable tests.

■対象:
初級者~中級者

■概要:
Chrome Custom Tabs(以下CCT)がSupport Libraryの23.0.0から追加されました。
CCTの存在を知っていはいるが、なかなか導入できない人もいると思います。
出た当初に比べて、現在はできることも少しずつ増えてきています。
CCTでできることできないことを把握して、導入できるか再検討してみましょう。既に導入している人でも、新しい知見を持ち帰っていただきたいと思います。

■目次案:
 * CCTとは
 * 導入方法
 * 外見を変える
 * アニメーションをつける
 * Referrerをつける
 * Headerをつける
 * BottomBarをつける
 * RemoteViewをつける
 * Prefetchで素早く読み込む
 * イベントを受け取る
 * Sessionをつなぐ

■補足:
あまりコードには触れず、できることできないことにフォーカスを置こうと思っています。
事前にサンプルコードは公開し、それに沿う形にします。
余裕があれば(調べきれれば)、Chrome側から見たアプリにも触れたいと思っています。

【対象者】
デザイナーの考えを知りたい
ワンソースプロダクトの設計に興味がある
デザイナーが１人、もしくは少人数のチーム

【概要】
Quipper社では、スタディサプリとQuipperアプリという２つのプロダクトを持っています。全て一つのソースコードから生まれています。

さらに、教育系という特性上、iOSとAndroidでほぼ同時に設計を行うことが多いです。

ワンソースから生まれるプロダクトで、デザイナーがどのような考えで
日々設計に勤しんでいるか、ビジネス側の理解と開発の整合性、
エンジニアの方々との協力関係はどうなっているのかなどお話したいと思います。
※デザイナー目線でお話するので、プログラムの話は一切出てきません。

【目次】
- ワンソースプロダクトの良さと難しさ
- 日本と国外の設計の違い
- iOSとAndroid
- それぞれのOSの特性を理解する
  - マテリアルデザインで助かったこと

Pokemon GOによって再び位置情報を使ったアプリに注目が集まっていますが、AndroidのLocation Managerをそのまま使っただけでは精度の良い位置情報をトラッキングすることはできません。
このセッションでは
- バックグラウンドで安定的に位置情報を取得するアーキテクチャの作り方
- LocationManagerに設定する最適なCriteriaの作り方
- 高精度の位置情報を取得するための各種フィルターの作り方
の順に、UberやNike+と同等かそれ以上の精度の位置情報トラッキングを可能にする方法を説明します。
デモアプリと実際のフィールドテストのデータを用い、トラッキングアルゴリズム開発の過程でパフォーマンスをどのように検証していくかという方法論も説明し、参加していただいた方が自分のアプリのニーズにあった位置情報トラッキングアルゴリズムへカスタマイズしていくためのヒントも提供できればと思います。
また位置情報精度とバッテリー消費量の関係についても実際の検証データを使って考察する時間を取りたいと思います。

■対象者
Android開発をする上で便利なコマンドを知りたい人
Android開発をより効率的に行いたい人
GUIよりコマンド(CUI)が好き人

■概要
このセッションでは30分とにかくAndroidに関するコマンドの話をします。

Android Studioでlogcatを見れたり、Android Monitorから色々見れたりしますが「それターミナルからコマンドで見れますよ」と言いたいわけです。
コマンドを介せばさらに細かく端末の情報を確認することができます。
コマンドから文字を入力したり、Backキーを押したりとコマンドを介して端末操作もできます。
Intentの発行など人力で行うと面倒な作業もコマンドからなら楽にできます。
色んなコマンドを知ることで、Androidの状態や仕組みを理解する機会にもなります。

そんな「コマンドでAndroid開発を楽しみたい・効率的に開発したい！」というみなさまの熱い期待にお答えするセッションです。

私が日々使用しているコマンドからいざって時に役立つかもしれないコマンド等、色んなコマンドをご紹介していきたいと思います。
実際にコマンドを実行しながらどんなことができるものなのかを見ながら紹介していくものも用意する予定です。
コマンドを知ることで、今まで以上に作業効率の向上、Android楽しさ・奥深さを知っていただけると嬉しいです。

具体的には以下の様なものをメインで話す予定です。
* adbコマンド
* Androidのshellコマンド
* adbを便利にするTool
* Androidのコマンドを支える技術
* コマンドを組み合わせたTips

When building Calligraphy (https://github/chrisjenx/Calligraphy) it uncovered some interesting aspects of the LayoutInflater and some unknown side effects.

Calligraphy could be described as a partial "hack" - I think it's important to show to how this works and although a "hack", it's been done with safety in mind.

I will cover how the LayoutInflater works - being one of the most important parts of the Android framework, Android Developers should understand what goes on under behind their Layouts.

Secondary let's look at how Calligraphy hacks the lifecycle to allow you to it to inject into views at inflation time and then how you can roll your own version of Calligraphy!

🔥

■概要
Material Designは2014年にGoogleが提案したデザインガイドラインであり、最近では多くのAndroidアプリで採用されています。
ノハナ社では2016年1月からエンジニア主導でアプリのMateiral Design化をじっくりと進めています。
エンジニアがデザインに関わるとどのような利点があるのかをノハナ社の事例を元にお話します。

■目次案
・エンジニアがMateiral Designを理解する利点
　・Material Designの特徴とエンジニアの思考
　・デザイン巻き戻り工数の削減
　・エンジニアにしかできないユーザー体験の向上
・Material Design化の進め方
　・ノハナ社のデザインフロー
・Material Designを広めるために
　・社内勉強会とその後のフォロー
・Material Designの思想背景を理解するための思考法
　・なぜBottom navigationではBackキーでコンテンツを切り替えるべきでないのか
　・なぜSupport LibraryにもデザインガイドラインにもProgress Dialogがないのか

■対象者
・Material Designをなんとなく知っていてもっと理解を深めたい方
・デザイナーの言いなりで実装するのが嫌な方
・その他、アプリのUIを改善したい気持ちを持っている方

■ 対象者
・RxJava初級者〜中級者

■ 概要
Android開発にRxJavaを取り入れる事例がかなり増えてきており、Androidの標準APIのイケてない部分を解消したり、複雑な非同期処理をうまく記述したり、といった知見はかなり充実してきていると思います。一方で、RxJavaを使う場合のエラーハンドリングに関する知見はそれほど広まっていないのではないかと感じます。そこで本発表では、エラーハンドリングにおけるいくつかのパターンを取り上げて、RxJavaを使った実装方法を紹介したいと思います。

■ 目次
・RxJavaのおさらい
・RxMarblesについて
・エラーハンドリングで使うOperatorの紹介
	・onErrorReturn
	・onErrorResumeNext
	・retry
	・retryWhen
・よくあるエラーハンドリングの実装方法
	・Toast/SnackBarを表示する
	・代わりのデータを表示する
	・リトライする
・少し複雑なエラーハンドリングの実装方法
	・リトライするかどうかをユーザーに委ねる
	・エラーの種類によって異なるハンドリングを行う
	・他にもいくつか追加予定

Smoke and mirrors is an expression use to describe something that obscures the truth. The expression is commonly used to describe magicians.
Android developers have a lot in common with magicians, they make great and responsive UI, with limited resources. In order to make these experiences possible Android devs need to use a lot of tricks.
The talk will show examples of smoke and mirrors in: Android Framework, Google Photos, Google Calendar and Twitter.
After the talk, attendees will know how those great experiences are built.

■概要
新しいプログラミング言語のKotlin（ことりん）を使ったAndroidプログラミングのハンズオンです。長らく（特に）Androidエンジニアの注目を集めていたKotlinですが、今年2月に念願のver1.0のリリースと7月に日本初の書籍の出版があり、今非常に勢いのある言語です。

■対象者
・Android初心者以上
・Kotlin初心者

■ゴール／得られる知識・技術
・AndroidプロジェクトにKotlinを導入できる
・KotlinをAndroidアプリ開発に活用できる（Kotlinの利点を享受できる）
・Kotlinの弱点を知り、フォローできる

■注意
・ハンズオンということで実際に手を動かしていただきます
・ただし50分という短い時間の中でのハンズオン部分は非常に少ないです
・ハンズオン参加の方は、事前にお知らせする環境をセットアップした状態のノートPCをお持ちください
・ハンズオン不参加でもご聴講いただけます

■目次案
1. Kotlin概要（10分）
2. 環境構築〜導入（解説5分、ハンズオン5分）
3. アプリ実装（解説10分、ハンズオン15分）
4. 次の一歩（5分）

※題材となるアプリは検討中（ごく簡単なツール系を予定）

■登壇者について
・日本Kotlinユーザグループ代表
・講演実績多数: DroidKaigi、JJUG CCC、Hacker Tackle、LLoT、ABCなど
・執筆実績多数: Kotlinスタートブック、Software Design、日経ソフトウエアなど

「なんで、テストカバレッジ0の私がクラッシュフリー率99%台に!?」
様々な現場でAndroid開発をしていると、テストコード皆無のプロジェクトに遭遇することもあるだろう。
テストコードがないと大胆な変更をリリースするのに勇気がいる。勇気がいるからリリースが怖くなる。リリースが怖いから変更が溜まっていく…の悪循環だ。テストコードはあった方がいい。そんなことは分かっている。それでもないものはない。

本セッションではスピーカーの経験から、次のような内容を扱う
・テストコードゼロの現場では何から始めるか
・クラッシュフリー率を上げるには何が効果的か
・テストを書かない現場にどうやって文化を根付かせるか

対象は特にAndroid開発を始めたばかりの初心者や、テストコードがなくて苦しんでいる現場のプログラマを想定している。

■対象者
初心者〜上級者。
Androidアプリで実際に公開された脆弱性について興味のある方。

脆弱性はバグです。バグは必ず産まれるものです。例えセキュアコーディングガイドを隅から隅まで暗証してたとて、予期せず脆弱な実装は世にでるでしょう。本発表ではJVN49343562とJVN61297210が付与されたAndroidアプリ「マネーフォワード」の「WebView クラスに関する脆弱性」「任意の操作が実⾏可能な脆弱性」について、下記のアジェンダ(仮)でご紹介いたします。

- 脆弱性対応タイムライン
- 脆弱な実装の紹介
- 脆弱な実装の修正
- 脆弱な実装の背景
- 俺たちはどう脆弱性に向き合っていくのか

こういたノットベスト・プラクティスを共有することで、世の中のアプリの品質がより高くなることを願っています。又、一歩踏み込んでこういったバグをも知見としてオープンに共有できる文化作りに一端を担いたいと思います。

対象者:
CIの導入を考えている方、CIを導入したは良いがポテンシャルを発揮できていないと思っている方
CIとは何なのか、この世にCI as a Serviceと呼ばれるサービスが多数存在すること、テストやビルドが自分で出来る程度の前提知識が必要です

内容:
これからCIを導入するにあたって、各CI as a Service(CIaaS)などの今考えられる選択肢とその選び方
及び、考えうる最高のCI環境とその運用により得た知見について話します

最適なCIのあり方というのは開発規模や使っているツール等によって異なります
開発規模や利用ツールによってどのようなCIaaS或いはソフトウェアが選択肢にあがるのか？
各CIaaS或いはソフトウェアの強みや弱み、それらを踏まえどのように選択していくのが良いのか？
選んだ環境で、私達はソフトウェアの品質向上のために一体どのような事が可能なのか？
また、現状考えうる最高のCI環境の提起と、いかにしてその選択に至ったか？
その運用例と、運用によって得た知見について

対象者 ・RecyclerViewを使ったことがある人

RecyclerViewの要素をどう並べるかを決めるLayoutManager。
Support LibraryではLinear、Grid、StaggerdGridの3つが用意されているが、もっと凝ったレイアウトや複雑なレイアウトをしたい場合、自分でLayoutManagerを作るしかない。
この発表ではいくつかのサンプルレイアウトを使い、自作LayoutManagerを作るときのコツや注意点を紹介する。

発表内容（案）（予定）
・LayoutManagerとは何か
・RecyclerViewとLayoutManagerの関係
・LayoutManagerの動作の仕組み
・簡単な自作LayoutManagerを用意し、実際のコードを見ながらカスタマイズの要点を紹介
・まとめ