LoginSignup
5
2

More than 5 years have passed since last update.

Droid Kaigi DAY.02 (Mar 10th, 2017) 参加レポート

Last updated at Posted at 2017-03-10

Droid Kaigi DAY.02 (Mar 10th, 2017) 参加レポート

受講したものを書いております。

  • 10:40 - Room3 Android ORMの選び方
  • 11:50 - Room1 How to implement material design animation
  • 12:40 - Room3 Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
  • 14:20 - Room5 Can You Read Your Tests? Clean and Useful Android Testing, with JUnit and Spock!
  • 16:00 - Room3 エンジニアが武器にするMaterial Design
  • 17:10 - Room1 テスト0から目指すクラッシュフリー率99%

10:40 - Room3 Android ORMの選び方

gfx
個人でORMを作っている
Ormaが自身の欲しい機能を全部実装できた
SQLiteオープンヘルパーをそのまま使う
よりORMを使った方が品質の良いアプリを作れる
コードを書くのが好き
https://github.com/gfx
https://github.com/gfx/Android-Orma
Kibela
https://kibe.la/
コンフルエンスとかをやっつけたい
ローカルDBとのやりとりの方がWebAPIとの通信より 数千倍早い
cache
offline-first development
ユーザーの行動ログをローカルに一旦保存しておき、サーバに送信成功したら消す
SharedPreferences
SQLiteをwrapper
realm
SQL-92 メリットもあるしデメリットもある
object relation mapper
SQLiteは表(エクセルみたいな感じ)で入ってる
表 ⇄ Javaオブジェクト を シリアライズ、デシリアライズしている

todos.equal(Todo_Meta.title, title)
keyがJavaのフィールドであることで、typoを防止する

todos.titleEq(title)
もっと良い
補完される
ドキュメントを読まなくても使えるというのがORMとして1番いい

Association
Rails

Pub-Sub
スターとかいいねとかの状態を管理する

Migration
実際に開発する際には、ALTER TABLE文書かないといけないのか、ある程度自動でやってくれるのか見た方が良い

ActiveAndroid

もっと有名なORM
使うのが非常に簡単
デメリットはメンテナンスされていない
ベースライン
リフレクションベースで実装しているので、ソースコードが大変なことになっている
モデルの定義は 常にモデルっていうクラスを継承しないといけない
設計ミスしている
CookPadではActiveAndroidを書き直した
暗黙的に定義すると人は気づかない
データベースハンドルはない
staticおじさんが設計したもの
railsのactive recordもこんな感じ
.saveするだけで良い
Query Builder
whereに直でSQLを書いてるので、SQLを意識しないといけない
Association非常にシンプル
Has-Many Associationは使い物にならない リストを返す
Pub-Sub コンテントプロバイダーを通じて
Migration はひどい 開発中 カラムをたすたびに なんかアプリが落ちて、アプリアンインストールして使うみたいな感じになる
OSSとしては寿命

greenDAO v3.2.0

3.0.0からだいぶ変わりました。
ModelにAnnotationをつけると関連する
かなり速いらしい
Model Definition
Model 自分のコードとGreenDAOが生成するコードが混在するので、ガイドラインを作らないと混乱する
Usage DBハンドル 関連クラスがあってよくわからん
eq where文のSQLは結構進んでる
Association 保存する順番は自分でコントロールしないといけない
pub-sub, migration サポートしてない
作者がobjectboxっていうのを作ってる

Requery

アノテーションプロセッサーベース 結構モダン
スカイプのエンジニア
モデル定義 代わり映えする アブストラクトクラスを作るかインターフェースを定義するか
デフォルトで全てのものがカラムになる
DBハンドルは明示的に作る
EntityDataStoreは割と合理的
RXJava, RXjava2をサポートしている
Pub-Sub
Migration スキーマのバージョンをあげるとALTER TBALEを発行してくれる
開発中にスキーマバージョンあげるというと
他のDBもサポートしてるけど、そこが欠点

Realm

Realmオブジェクトを継承しないといけない
DBハンドルをとってきて操作する
ネストが深くなる
Query Builder type safeではない
Association, Pub-Subがサポート
Realm Mobile Platform
Migrationは結構辛い
ジェネレートテッドクラスを直接触らなくて良い、でもtype safeじゃない

Orma

ベースクラスを必要としない
何も要求しない
使い方 DBハンドルを作って、普通に使う
Todo_Relation
Query Builderはtype safe
インデックスを貼らないと検索できないようにしている
遅い操作ができないようにしている
Association いい感じに保存してくれる
Pub-Sub RXJava2
Migration スキーマdiffマイグレーション
diffとってALTER TABLEを発行している
Gitと同じことをやればいいんじゃないだろうか
renameは難しい
sqlite_master
sqlite3 foo.db
versioning hash sha256

11:50 - Room1 How to implement material design animation

12:40 - Room3 Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ

@lvla0805

14:20 - Room5 Can You Read Your Tests? Clean and Useful Android Testing, with JUnit and Spock!

15:10 - Room2 2つのアプリ、1つの設計のデザイン指針

デザインデータを1つ作ると
1つのソースで
複数の国、複数のアプリに展開できる

国ごとに課金の方法が変わる
UXデザイナーの人がやることとしては

詰まった時にどうするか?
通信が失敗したらどうするか?

エンジニアリングとデザインのバランスが重要

16:00 - Room3 エンジニアが武器にするMaterial Design

デザイナーはアイコンを作るだけ
新卒のデザイナーを教える
エンジニアもデザインの勉強するぞい!
マテリアルデザインは論理的に作られているので、エンジニアが勉強するのがおすすめです。
社内勉強会をやる!

マテリアルデザインは人間工学など色々なことが考慮されている
人間は待つことにストレスを感じる。
ユーザーを1秒以上待たせてはいけない。

UI観点では意見を出し、色彩に関することはデザイナーに任せる

17:10 - Room1 テスト0から目指すクラッシュフリー率99%

*テスト0から目指すクラッシュフリー率99% スライド

レガシーな職場でもVultureは使える
3万ユーザーくらいのアプリに対して使用実績がある

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2