DroidKaigi 2017に参加してきたので、受講してきた内容と感想を雑にまとめます。
１日目
- 10:40〜Room4 逆引き マテリアルデザイン
http://yaraki.github.io/slides/droidkaigi2017/#1
ガイドラインをちゃんと読む。 最新はwhats-newに書いてあるので、定期的に確認する。
タッチフィードバックは必ず実装すべき！
Patterns - Launch screens
0.1秒でも早くユーザが興味を持つコンテンツを見せるのが大原則！
時間がかかるならブランディングを見せる。
ブランディングはアプリの背景として設定して、アプリが起動したらすぐ通常の背景に戻す。
ダラダラ表示しない。
カスタマイズ
カスタマイズしたいときなにを設定すれば良いか、リファレンスだけじゃなく
Support Libraryのソースコードをおってみると、簡単にできたり理解が深まる。
CoordinatorLayoutめっちゃ便利。
View同士を連動させてアニメーションさせることが簡単にできる。
Transition API
API Level 19から使える（API Level 14までバックポートされている）
画面遷移時だけじゃなくViewの状態・表示切り替えアニメーションでも使える。
アニメーションをつける意義
どういうアクションをしたからこういう結果になっているのか、ということをユーザに直感的に理解させるため。
逆に、ユーザが混乱するようなアニメーションは過剰である。
11:50〜Room3 Android Security最前線！！
主にAndroid Nougatから追加・変更された外部ストレージへのアクセス方法や通信をセキュアに行う方法について
12:40〜Room1 インスペクションとAndroid Lint Custom Ruleによる、単一責任実装の実践
https://www.slideshare.net/cch-robo/android-lintsrppractice
14:20〜Room4 Android定期実行処理入門
https://speakerdeck.com/kazy1991/droidkaigi-2017
14:50〜Room5 Android Resources Refactoring
16:00〜Room3 オフラインファーストなアプリケーション開発
https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa
- プログレスをダラダラ表示してユーザの操作を阻害するようなことは、極力しないようにする。
- ネットワークが繋がっていないときでも、追加・編集などの操作はさせておいて、オンラインになってからサーバと同期する。Realm Mobile Platformを使えば上記のことが簡単にできます。
17:10〜Room4 全てSになる〜RxJavaとLWSを持ち込む楽しさ〜
https://www.slideshare.net/ryugoo/s-rxjavalws
18:00〜Room1 AccessibilityServiceを使ってアプリの可能性を広げよう
https://speakerdeck.com/litmon/accessibilityservicewoshi-tuteapurifalseke-neng-xing-woguang-geyou
２日目
10:40〜Room1 Xamarin.Android で始めるクロスプラットフォームモバイルアプリ開発
https://speakerdeck.com/amay077/xamarin-dot-android-teshi-merukurosuhuratutohuomumohairuahurikai-fa-number-droidkaigi-number-droidkaigi1
11:50〜Room4 個人で11個のアプリを公開した結果
https://speakerdeck.com/syarihu/droidkaigi-2017-ge-ren-de11ge-falseapuriwogong-kai-sitajie-guo
- 紙媒体しかない情報をアプリ化すると伸びやすい
- ネーミング大事（検索にひっかかりやすくするため）。造語は避ける
- もうちょっとこうならいいのにと感じたときにすぐメモる（アイデア）
- SNSでシェアするとインストール数があがる
- アイコンは凝らなくても機能がよければインストール数は伸びる
12:40〜Room2 Data Bindingで実現するMVVM Architecture
https://speakerdeck.com/star_zero/databindingteshi-xian-surumvvm-architecture
14:20〜Room4 Androidで音声認識を使いこなす
https://speakerdeck.com/kakka/20170310
SpeechRecognizerを起動して音声を認識させる
音声認識開始が遅いときはonPartialResultで入力を監視してしばらく入力がなければstopしてやる
デバイスがオフラインのときonErrorが呼ばれないことがあるので、timeoutを自分で設定する
解析する言語は自動判定できないので、必ず設定する
ボイスコマンドは辞書登録しておく
雑音環境では短い音声は認識精度が下がるので、ある程度ながい単語をユーザにしゃべってもらう
通常時は連続音声認識のためになにかしらレシーバを張っとく
連続音声認識がサーバと通信する（オンラインでないといけない）理由はなにか？
マイクは１つのアプリしか使えない
連続音声認識が動いてるときはSpeechRecognizerは使えないのでいったんstopする
OK Googleは優先度が低いので、他が動いているときは勝手にstopしてくれる
15:10〜Room1 Chrome Custom Tabsをさらに使いこなそう
https://speakerdeck.com/sakebook/make-full-use-of-chrome-custom-tabs
16:00〜Room3 エンジニアが武器にするMaterial Design
https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design?utm_source=dlvr.it&utm_medium=twitter
デザイン、UI、UX、実装工数
などなどを加味してUIを決定していくので、エンジニアもデザイン設計に参加すべき
ガイドラインを読み込むだけでなく、それを活かすデザインができるようになる
また、それを社内勉強会などを通じて展開しナレッジ化する
工数も一緒に説明すると良い
エンジニアもアプリデザインに積極的に関わっていくべき
メリット
デザイン作成段階で、エンジニアができるできないを判断して相談しながら進めていくことで
デザイナーの負荷も減らしつつ、工数を抑えられる
デザイン待ちの時間を削減できる（決まって変わらないであろうところから実装が勧められる）
エンジニア視点だけではなく、ユーザ視点で捉えられるようになり視野が広がる
デメリット
理論的には正しいがUI的には微妙なものができる可能性がある
エンジニアがデザインをやりすぎるとデザイナーがやることがなくなる
デザイン部分はデザイナーに任せる
最終的な決定権はデザイナーにもってもらうとうまく回りそう
アプリのデザインができる、エンジニアに意見の言えるデザイナーを育てる
マテリアルデザインはあくまでフレームで、基礎をしっかり理解した上でどういったカスタマイズを
するか考えて実行していくことがエンジニアの役割
やっていくべきこと
マテリアルデザインのガイドラインを読み込む
デザイナーと協力して工数を削減していく
知識と実装をつなげる
用意されているViewコンポーネントを知って流用する（独自に作らない）
アニメーションの実装を学ぶ
アニメーションの種類、できること、違い、使い方を理解する
UIだけでなくUXを改善する（動作速度を改善することが効果的）
パフォーマンスモデルを決める（動作速度の要件）
遷移開始はアクションから100ms以下
アニメーションは１フレーム１６ms以下
ユーザを待たせる処理は1000ms以下
1000ms以上のタスクは完全バックグラウンド（コールバックを待たず投げっぱなしにするくらいの勢い）
デザイン部分じゃなく、遷移速度、表示速度など、エンジニアしかできないことを改善することを目指す
- 17:10〜Room2 ドキッ★脆弱性 onCreate() から onDestroy() まで https://speakerdeck.com/ken5scal/dokitucui-ruo-xing-oncreate-kara-ondestroy-made 知識・調査不足による不用意な実装、人為的なうっかりミスが多い。 レビューでがんばって見つけるのも大事だが、コードチェックツールなどを活用してある程度自動化しないと辛い