droidkaigiに参加してきました。 #droidkaigi

droidkun

4/24にサイバーエージェントで行われたdroidkaigiに参加してきたのでメモを共有します。
皆さん書いてあるので殆ど同じかと思いますがw

個人的にはKotlinがインパクトあってよかったなと思いました。groovyでもかけますが、Kotlinのほうが今っぽい仕様で書きやすそうでした。
また、同期戦略の話もとてもおもしろかった。どうやるかは知ってたけど、「どのように同期するか?」というもう一つブレイクダウンしたものに関してはフル同期すればいいやと考えていたので新しい考え方が得られた。

参考

基調講演 Activity, Fragment, CustomView の使い分け -マッチョなActivityにさよならする方法- あんざいゆき

まっちょなActivity

  • Activityに全てを書いたら破綻する(まっちょなActivity)
    • Activityはテストしにくい
      • Unitテストは書ける
    • 色々機能がごちゃまぜ、長いコード
      • アンリーダブルコード
      • デグレの元
    • 技術的負債

Activity,Fragment,CustomViewの特徴と役割

  • レイアウトとロジックを持てる
    • Activity
    • Fragment
    • (Cusom)View

Activity

  • 単純には画面の単位

Fragment

  • FragmentはView寄りではなく、Activity寄り

View

  • 四角いエリアを専有して、イベントを受け取る
  • CustomViewのパターン
    • 既存のViewを組み合わせたViewGroup
    • 独自のルールでViewを配置するViewGroup
    • 独自の計算でサイズが決まる既存のView
    • 独自の見た目のView

比較

  • 他アプリから呼ばれるので、入り口を分けたかったらActivityを用意するしかない
  • Fragmentは画面回転の前後でデータほ保持できる
  • OptionMenuをスライドインした時に表示したい。ということであれば、Fragmentでメニューを生成するといい

Fragmentは難しい…?

  • SquareさんがFragmentつらい宣言した。
    • View&独自MVPで置き換えた
  • CustomViewでできること
    • Viewのadd/removeで画面切り替えて代替することは可能
    • MVP/MVCの限界
      • オレオレMVP/MVCは学習コストが高い
        • FragmentはAndroid Devに書いてあるが、独自のはない。。。頑張って書く
    • CustomView
      • パーツとして使用
  • Fragment
    • ネットワーク処理
    • DB、ファイル
    • Loader
    • メニュー
  • Activity
    • スクリーン系
      • Actionbar, Menu, Fragment管理
    • Intent処理
    • その他残り

まっちょなActivityにさようなら

  • (CV)データの保持(画面回転時とかに使用)
    • EditText, RadioGroup, Spinnerなどはデフォルトで保持してる
    • 独自の値の選択機構, ImageViewは独自でカンバル必要がある
    • CustomViewにデータ保持器校を持たせる
      • BaseSavedSateを継承したクラスを作る
      • CompoudButtonのコードがわかりやすい
  • (CV)データとViewのマッピング
    • SpinnerのselectedPosition⇆データ
    • RadioButtonのChecked⇆データ
  • (CV)バリデーション

    • 失敗時のメッセージはToast or 同じView内に表示
    • 全体をViewにバリデーション走らせたりしたらいい
  • (Fragment)通信処理中のやつ

    • データ持てるらしい

Fragmentではまらないためのあれこれ

  • 落とし穴にはまらないにはどうすればいいのか

はまらないポイント

  • 引数付のコンストラクタを使わない
  • 引数なしのコンストラクタをpublicにする
  • non staticなインナークラスにしない
  • 初期値の設定とコールバック
    • 初期値はsetArguments(),getArgments()を使う
    • ActivityへのコールバックはonAttach()
    • FragmentへのコールバックはsetTargetFragment()を使う
  • Fragmentのバックスタックは難しい
    • うまく使わないとライフサイクルの問題
    • むやみに使うなキケン
  • Fragment内でstartActivityしない
    • Fragment内でstartActivityForResultは更に危険
  • Fragment in Fragment
    • Loaderとの組み合わせは危険
    • getChildFragmentManager()を使う

[droidkaigi] 開発を効率的に進められるまでの道程

@cattaka_net

About

  • Androidアプリの開発者
  • Wantedly
  • 開発経歴
    • 2009年ぐらいからAndroidアプリ作ってる
    • 改修とかやってた

アプリ開発を効率化について

ボトルネック対策

  • テストを書くことが一番のボトルネックになる
    • バグゼロで
    • 品質100%で

テストを書くに至った経緯

  • よくある問題
    • 小さなリファクタリング
      • 意識してないところで壊れる
    • リファクタリングしないようにする
      • ストレスが溜まる
  • テストを書き始める
    • 最初はロジックのテストを書く
    • 要件一覧表の1項目1テストを書く

開発途中からテストを導入する話

  • 外部依存する箇所にDIを入れる
    • 通信, DB, Pref
    • 上記はインターフェイスを1つ噛ませる
    • Daggerとか、オレオレDIをつかう
  • グローバル変数を取る
  • シングルトンもなくす
  • 投げっぱなしのスレッドを止める
  • 最小限のリファクタリング
  • ひたすらテストを書く

DB

  • RenamingDelegatingContextを使うと別ファイルになる
  • SQLiteHelperのContextにnull渡すとオンメモリ上になる

ひたすらテストを書く

  • ブラックボックステスト
  • コンバージョンにつながるところは重点的に書く
    • ログイン周り
    • 応募
    • ユーザのプロフィール入力
  • テストの粒度はまちまち

[droidkaigi] 絶対に落ちないアプリについて

絶対落ちないアプリ…

  • そんなのはない
  • バージョンが多種多様
  • ベンダによる謎のカスタマイズ
  • 鬼門: カメラアプリ
  • alpha.mixi.co.jp/entry….

crashlyticsのランキングから

  • バグに向き合う
  • FragmentTransactionのミス
  • ライフサイクルの終わったコントローラへの不正なアクセス
  • APIとの連携みす
  • カメラアプリとの連携ミス

Agenda

ライフサイクル

  • ちゃんと頭に入れましょう
    • 動作を確認する
  • Activityを保持しないをOnにする!!!!

非同期ライブラリ

AsyncTask
  • 使わない!
  • AsyncTaskがActivityより長生きする…
  • 長くても2~3秒のもののみ使う(通信には使わないほうがいい)
  • やりっぱなしをやめる
    • cancel()すればいいのでは?
    • BitmapFactory.decodeStream()みたいなキャンセルできない操作もある
  • 画面回転等で結果を引き継げない
    • 回転するとアカン
  • 使い方
    • staticクラスにする
    • WeakReferenceにして使う
    • doInbackground()でループしてる場合は、キャンセルしたかどうかをチェックする
Loader
  • LoaderManagerはActivityやFragmentに一つ
  • Loaderいい
EventBus
  • Observerパターンのような感じで、ライフサイクルオブジェクトは自分のライフサイクルに合わせてイベントの購読/非購読が簡単

Context

ActivityContextが長く参照される
  • メモリーリーク!!!
  • ActivityとApplicationContextをちゃんと意識して書く!

FragmentTransaction

  • DialogFragmentの表示非表示で使われる

[droidkaigi] アプリの企画、プロトタイプからリリースに至るまで

@__chocomelon

About

  • Pixiv Inc.
    • pixivマンガアプリリリースした
  • Android, iOS開発

Mission

  • 何故作るか
  • 3ヶ月

Brain Streaming

  • 背景を調査
  • 全員で同じ場所でやる
  • 圧倒的な当事者意識が大事
  • ユーザストーリーを考える
    • 何をしたいのか「誰々は◯◯がしたい」の形で考える
    • 機能ベースで考えない
  • アプリのウリを考える
    • 説明文80文字、詳細をざっくり

Quick Prototype

  • 雑なプロトタイプ
  • アプリ1人,サーバ1人
  • 1日1機能で
  • 捨てる前提でUIなどの練度は気にしない
  • 動くプロトタイプ
  • メンバーとの物理的近さ大事
    • 共有するのに地味にコストがかかる
    • ちょっとしたことでも共有しやすい

LiveDesign

  • Sketchでライブデザイン
    • 1時間ぐらいでやった
  • 遷移などを埋めていくと足りないことや決まってないことが明確になる

Prototype

  • ライブデザインのものをベースにアプリを作る
  • コードは捨てる前提
  • 技術的チャレンジしてみる
    • 言語、ライブラリを試す
  • Dog fooding
    • アプリを社内の人に使ってもらう
    • 定期的にやる
    • バグは最悪のUX
      • 指摘ばっかされる
    • やり過ぎに注意
      • バグシュウセイばっかやってた
      • 3日に1回ぐらいにおちついた
  • 振り返り

Coding

  • 空リポジトリで始める
  • レビューできる体制にする
    • 各2人
  • 用語を統一
    • アプリもサーバも統一
    • API作るにも楽
  • Circle CIでビルドして送っている
    • 常に開発の最新版をやりたい
  • こまめにPR、コミット
  • 新技術とかは積極的にペアプロする
  • 見せ方的にも技術的にも気になるところはPRを出した人がコメント付ける
  • KPTした
  • サービスについて考える時間を週1でも設けてもよかった
  • リリース前の2週間
    • 前に機能実装のFIXを目指す
    • 残りの2週間はひたすらバグ修正

Release

  • ここまで3ヶ月
  • Androidだけ
  • リリースサイクル
    • 2週間に1回
    • 月曜にリリース。20%→50%→100%
    • リリース前週の水曜日にコードフリーズ
  • 自分たちでドックフーディング
    • 朝会後の5~10分さわる
    • 朝会の後立ちながらやる
  • ヴィジョナリータイム
    • 将来(今後)について話し合う時間
    • エモい

おまけ

  • チャットにcrashlytics
    • crash free userを99%に
  • レビューをフック
    • gsutilで取得したレビューをhook
  • ご意見hook
    • hook

iOS版の話

  • 審査がネック
  • リジェクトの危機
  • リジェクトされるおそれがある機能をリリースしたら審査(ストアに公開はしない)

まとめ

  • 必要なのは圧倒的な当事者意識
  • チームメンバーとの席を近く
  • ドッグフーディング大事
  • 人を巻き込む
  • 機能を削ってクオリティを保つ
  • こまめに振り返り

[droidkaigi] Android学ぶ君へ。生き抜くためのナレッジ共有

@operandoOS

資料のリンク集

About

  • メルカリ

初級

  • WordPressのAndroidアプリのOSSを読む

Developer

1から設計する

  • 技術的判断が求められる
    • Androidのバージョンごとの機能を理解
    • Google Play Serviceを理解
    • 最新技術のキャッチアップ
  • Viewの選定
    • とりあえず沢山みる
    • Play Storeで最近人気のアプリをみる
      • 毎日みるといい
      • Wish Listを使う
    • View treeを見てみる
  • Release/運用の知識

生き抜くためのFramework

  • ソースコードを読む
    • AndroidXRef
  • Android Command Note
    • コマンド大事
    • log見るの大事。 event, radio
    • 端末の状態を知るのに楽
    • adb-pecoが便利
    • コマンド覚えましょう!
  • コードを読む力が大事
    • 気になるところから読む

メルカリのナレッジ

良いアプリをつくるために

  • 常にアプリを疑う
    • タブのスワイプ移動が出来なかった
  • 常に改善し続ける

三種の神器

  • github
  • deploygate
  • slack

Checklist

  • githubのチェックリストを作る
  • 実装に対してのみんなでチェックをするため
  • ロジック(端末のバージョン), 端末の状態(回転とか)
  • WebViewチェックリスト(2.x, 4.x, 5.x)

Testing

  • テストコードがない
  • Unitテストから始めた
  • テストを書く文化が大事
    • Junit + Mockito

まとめ

  • Androidだけでやっていくの厳しい
  • ナレッジ共有して頑張ろう

[droidkaigi] KotlinでAndroidプログラミング

@ngsw_taro

About

  • @ngsw_taro
  • エムスリー株式会社
  • Java, Android, Scala
  • Kotlin
    • 2012年開始

Kotinとは

  • Android界隈でバズった。神も書いてた。
  • Better Java
  • OSS
  • JVM言語, altJS, Androidもサポート
  • 静的型付けオブジェクト指向言語
  • マイルドで現実見てる感
    • 簡単、安全

[doroidkaigi] 怖くないBitmap

@wasabeef

About

  • CAさん勤めてる
  • WasaBeef

Bitpamp怖い

  • outOfMemoryError…
    • みんな経験あるよね?

about bitmap

  • 画像を扱う基本API
  • BitmapFactoryで生成
  • webp(4.0以上)で使える

BitmapFactory.Options

  • inJustDecodeBounds
    • Bitmapのメタ情報だけ取得
    • 予め画像サイズだけを取得する場合など
  • inSampleSize
    • デフォルトは1
    • BitmapにFilter書けるときにとても有効
  • inPreferredConfig
    • Fomat指定
    • ARGB_8888になってる
    • RGB_545
      • 場合によってはMax時の半分ぐらいになる
    • ALPHA_8
      • Alpha値のみ有効
      • Shadowの時に有効

ライブラリ

Picasso

  • ImageLibrary
  • Transformation
  • Cache
  • Save in the world

Glide

  • Video, Gif対応
  • Picasso like
  • Sampling supoprt
  • BitmapPool
  • Thumbnail change the world.

Bitmapの編集

  • BitmapShader使ってやる
  • Blur→Transformationする前にやるといい
    • Bitmapのサイズを半分にして、Blurかけるといい。(Samplingするといい)
    • Supportライブラリのを使うといい
  • ライブラリ作った。wasabeef

Fresco

  • progressive JPEG
  • WebP support
  • Loading customization
  • XMLでも指定できる
  • Viewのサイズをdpで指定しないと何も表示されない。→若干使えない所

[droidkaigi] モバイルにおける電力最適感のための1プラクティス

@Ohoooo

難しかった…

JellyBeanとKitKatで実現するマテリアルデザイン

[droidkaigi] 僕らのデータ同期プラクティス

ブログにあがってました。

@nkzn

About

  • UIとかアーキテクト
  • WaterCell株式会社

オフラインでも使える化

NGのやつ

  • AlermManager&IntentServiceでやるやつ
  • IntentServiceが連続で走る
  • マルチスレッドでDB叩く
  • Synchronized祭り

OKのやつ

  • AccountAuthenticator&SyncAdapter&ContentProvider
  • ちょっと作るにもやることがある
  • onPerformSync()で何をするかが大事

同期アルゴリズム

同期戦略

  • Full Sync, Incremental Sync
    • Full→全部
      • 通信量がおおい
    • Incremental→逐次
      • 通信にやさしい
      • 差分だけ取ってくる

実際にやった

  • Incremental Sync
    • modifyの時間を渡して差分だけ返す
  • statusFlag(“dirty”flag)
    • clean サーバーからそのまま
    • add アプリ内で作った(サーバーにはない)
    • mod サーバーから貰ったの変更
    • delete サーバーからのを削除
  • 競合問題
    • サーバーとクライアント側の更新でどっちを勝たせるか…
    • 対応策(サーバ勝つ、クライアント勝つ、クライアントでマージしてからサーバへ送る…)
    • evernoteはクライアントでマージしてる

まとめ

思ったことを適当に。

  • 1日という長丁場でしたが、とても勉強になった。
  • RxJavaを使おうみたいなところが多かった。(本文には出てないけど)→初めはライトに取り入れたい
  • Android&Kotlinのプロダクションはまだないっぽい。サーバサイドはあるのか知りたい。
    • JavaのAnnotation周りもKotlinで使えるのかなぁ。
  • 同期戦略はとても勉強になった。クライアント側とサーバ側で初めからある程度考えておかないといけないかなと思った。
    • iOSとの兼ね合いも気になる所。
  • メモリーリーク気にしないとな〜〜
  • Fragmentはやっぱむずい(´・ω・`)が、ハマるとこを避ければ問題なさげ。