Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2017年03月17日

araki

DroidKaigi 2017 に参加しました。会場の様子をレポートします!

コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリの Android 版を開発しています。

前回の記事では、DroidKaigi 2017 の参加前レポートを書きました。今回は、DroidKaigi 2017 の参加後レポートとなります。ほとんどのセッションはスライドと動画が公開されるようなので、この記事では DroidKaigi に参加できなかった方に向けて、会場の様子をお伝えします!

DroidKaigi とは?

※ 前回の記事と同じ内容を、再掲いたします。

公式サイト より引用:

DroidKaigiはエンジニアが主役のAndroidカンファレンスです。
Android技術情報の共有とコミュニケーションを目的に、2017/3/9(木)、3/10(金)の2日間開催します。

DroidKaigi とは、Android エンジニアのカンファレンスです。参加者は500人を超え、日本国内の Android カンファレンスとしては最大級の規模を誇ります。2015 年から開催されており、今回の DroidKaigi 2017 で3回目の開催となります。私は今回が初めての参加となります。

会場の様子

会場の様子をレポートいたします。今回の会場は、ベルサール新宿グランド コンファレンスセンターでした。

セッション

セッションルームは全部で6つありました。どのセッションも多くのエンジニアが発表を聞きに来ており、人気のセッションでは立ち見の人が出るほどでした。写真は Room3 の真ん中くらいから撮影したもので、私の後ろにもたくさんの聴講者がいました。

Session Room3

Session Room3 の様子

ランチ、おやつ

会場には、お菓子部屋がありました。各社のロゴの入ったお菓子や、マフィンなどがおいてあります。運営の方曰く、無限に湧いてくるとのことでした。

IMG_20170310_095808

 

他にも記念撮影スポットがあったり、

IMG_20170309_184112

 

バリスタの方がコーヒーを淹れてくれるというサービスもありました。常に長蛇の列ができていて、私は飲みそびれてしまいました。。

オフィスアワー

各セッションの後には、オフィスアワーが設けられました。オフィスアワーでは、発表者の方が質問やフィードバックを受けるために、お菓子部屋にしばらく滞在していました。発表者の周りには多くのエンジニアが集まり、発表内容について熱い議論を交わしていました。私もオフィスアワーで議論に参加したり、発表内容に関する疑問をぶつけてみたりしました。こうした貴重な経験は、カンファレンスに参加したからこそ得られるものだと感じました。

 

こちらのセッションのオフィスアワーで、MVVM について発表者の方と議論を交わしていました。とても楽しかったです!

アフターパーティー

全てのセッションが終わった後のアフターパーティーの様子です。ここでも、たくさんのエンジニアの方たちと交流することができました。

IMG_20170310_183106

 

寿司職人が握るお寿司。去年もあったそうです。大人気で、すぐに売り切れてしまいました。

IMG_20170310_191355

 

遠いですが、運営責任者の mhidaka さんが壇上にいらっしゃいます。この後、運営スタッフの方々に会場全体から感謝の拍手がありました。スタッフの方々のおかげでカンファレンス中、気持ちよく過ごすことができました。ありがとうございました!

IMG_20170310_202008

さいごに

今回は、DroidKaigi に参加できなかった方に向けて会場の様子をお伝えしました。楽しそうな雰囲気が伝わって「来年は DroidKaigi に参加するぞ!」と思っていただければ幸いです。私は来年も参加する予定ですので、ぜひみなさんも参加しましょう!


2017年03月2日

araki

DroidKaigi 2017 に参加します!

コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリの Android 版を開発しています。

弊社はエンターテイメント分野を扱っており、クレーンゲームの商品も作っているので、SNSなどで人気が急上昇した「けものフレンズ」の商品は作らないのかと思って調べてみたら、流行する前に作ってもう終わっていたようです。

 

今回は、DroidKaigi というカンファレンスの紹介をします。また、公式アプリの OSS 活動に参加したことや、気になるセッションの紹介など、参加前の現状について報告します。

DroidKaigi とは?

公式サイト より引用:

DroidKaigiはエンジニアが主役のAndroidカンファレンスです。
Android技術情報の共有とコミュニケーションを目的に、2017/3/9(木)、3/10(金)の2日間開催します。

DroidKaigi とは、Android エンジニアのカンファレンスです。参加者は500人を超え、日本国内の Android カンファレンスとしては最大級の規模を誇ります。2015 年から開催されており、今回の DroidKaigi 2017 で3回目の開催となります。私は今回が初めての参加となります。

公式アプリの OSS 活動

昨年、公式アプリが OSS(オープンソースソフトウェア)として GitHub に公開され、多くの人にコントリビュートされていました。今年も以下のリポジトリで OSS 活動をされています。多いときは1日で40件ほどのPR(プルリクエスト)が出されたそうです!

https://github.com/DroidKaigi/conference-app-2017

昨年もそうですが、技術的知見が詰まったリポジトリだと思います。Data Binding, RxJava, Dagger2, Retrofit など、第一線のAndroidアプリ開発で使われている技術やライブラリの使われ方を見られるので、ソースコードを眺めているだけでも勉強になります。

また、コントリビュートを目指して PR を出してみるのも刺激的で楽しいです。私も、簡単な修正ですが3つほど PR がマージされて、晴れてコントリビューターとなることができました。コントリビュートしてみたいという方は Issues の「welcome contribute」ラベルがついたものに取り組んでみてください。

セッション紹介

個人的に私が気になるセッションをいくつか紹介いたします。

How to apply DDD to Android Application Development

あんざいゆき(yanzm) さんが発表されます。ドメイン駆動設計(DDD)を Android アプリに適用する話です。最近、「エリック・エヴァンスのドメイン駆動設計」という本を読み始めて、DDD に関心があるので Android の分野ではどのように適用されていくのかという話には非常に興味があります。ドメイン駆動設計の本はまだ読破していないので、当日までに読みきって臨みたいと思います。

大規模アプリのリノベーション

北村涼 さんが発表されます。初回リリースから5年続く「はてなブックマーク」を大規模改修した話をされるそうです。弊社のアプリも初回リリースから少しずつアップデートを続けた結果、コード改善の必要性が増しているように感じるので、どういったステップでリノベーションが実施されたのかを聞きたいです。

エンジニアが武器にする Material Design

瀬戸優之 さんが発表されます。Google が提案している Material Design というガイドラインについての話です。社内のデザインフローや Material Design を社内に広める方法についても話されるようなので、他社ではどのようにアプリのデザインと向き合っているのかという部分に興味があります。

さいごに

この記事では、DroidKaigi というカンファレンスの紹介、および参加前の現状について報告させていただきました。DroidKaigi では多くの Android エンジニアの方々と技術交流ができるということで、参加前から非常にワクワクしております。参加した後も、実際にどのような雰囲気だったのか、どういった知見を得られたかなどを記事としてお伝えできればと思います。

 

以上です。


2016年12月19日

araki

SQLDelightの紹介

この記事は、Androidその2 Advent Calendar 2016 の12/18の記事です。

はじめに

コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリのAndroid版を開発しています。今回は、Androidアプリのデータベース管理で使えるSQLDelightというプラグインの紹介をしたいと思います。前回の記事で紹介したSQLBriteと組み合わせて使うと強力です。

SQLDelightとは?

square/sqldelight

SQLDelightは、一言でいうとSQL文からJavaのファイルを自動生成するプラグインです。たとえば、以下のようなSQL文が書かれたUser.sqというファイルを作成してビルドをかけます。

すると、SQLDelightはUser.sqを解析して、UserModel.javaというファイルを生成してくれます。

たった4行のファイルから、たくさんのコードが自動生成されましたね。これだけだと何に使うかわからないと思うので、次に具体的な使い方について説明します。

使い方

まず、UserModelを実装したクラスUserを作成します。AutoValueを利用すると以下のように短いコードで書けます。

各種定数

UserModelにはテーブル名やカラム名、テーブル作成用のSQL文が定数として定義されています。たとえば、SQLiteを使う時に作るであろうSQLiteOpenHelperの継承クラスで、テーブル定義をする際にテーブル作成用のSQL文を利用できます。

Mapper

UserModelで定義されているMapperを使えば、データベースの取得結果であるCursorをUserクラスに変換することができます。

Marshal

UserModelにはMarshalと呼ばれるContentValuesのビルダーも定義されています。以下のようにINSERTするときや、UPDATEするときに利用できます。

Pros / Cons

SQLDelightのメリット(Pros)とデメリット(Cons)に関する私の意見です。

Pros

テーブルの定義をSQLで書くことができる点がSQLDelightのメリットだと思います。ORMライブラリは手軽で便利ですが、ORMの仕様に依存してしまうというデメリットがあります。つまりORM側の問題に依存してしまうというリスクがあります。これに対し、SQL自体を扱うSQLDelightは、SQLで出来ることなら何でもできるという点が強みだと思います。また、シンプルにSQLでテーブルを操作できるので、複雑な問題が発生しにくいのではないかと考えています。

Cons

デメリットとしては、SQLの学習コストがかかることがまず挙げられます。SQL自体はできることが多いですが、使いこなすにはそれ相応の知識が必要だと思います(私にはありません)。また、クラスのGetter, Setterのメソッド名がAutoValueの形式(User#name(), User#_id(1) など)となっていたので、個人的には見慣れないなと感じています。

まとめ

この記事では、SQLからテーブルを表すクラスを生成してくれるSQLDelightというプラグインを紹介しました。RealmなどのNoSQLのライブラリも盛り上がっていますが、SQLのパワフルさを活かしてみたいという方は、一度試してみてはいかがでしょうか?


2016年09月26日

araki

SQLBriteの紹介

コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリのAndroid版を開発しています。今回は、RxJava好きのAndroid開発者なら知っておきたいライブラリSQLBriteの紹介をしたいと思います。

SQLBriteとは?

https://github.com/square/sqlbrite

SQLBriteは、Android端末内のデータベース管理に使われるSQLiteOpenHelperをラップするライブラリです。最大の特徴は、テーブルに対するSQLクエリをRxJavaのObservableとして購読できることです。対象のテーブルに変更があるとSQL文が再度実行されて結果が流れてきます。これによって、テーブルのデータをストリームのように扱うことが可能になります。

 

使い方

ダウンロード

build.gradleのdependenciesに以下の行を追加してください。2016/09/15時点の最新バージョンは0.7.0です。

BriteDatabaseの取得

まずは、SQLiteOpenHelperをラップしているBriteDatabaseを取得します。

SQLBrite#wrapDatabaseHelper(helper, scheduler)メソッドでBriteDatabaseを取得できます。第1引数のhelperには、SQLiteOpenHelperを継承した自作クラス(ここにテーブルの作成やマイグレーション処理を書く)を入れます。第2引数にはテーブル変更の通知を行うスレッドを指定してください。通常はSchedulers.io()で良いと思います。

クエリの購読

クエリの購読には、BriteDatabase#createQuery()メソッドを利用します。

たとえば、usersテーブルの全てのレコードを取得するSQLクエリを購読する場合は、以下のようになります。insert、update、deleteなどでusersテーブルに変更があるたびに、call(Query query)メソッドに実行可能なクエリが流れてきます。

( https://github.com/square/sqlbrite#usage より引用)

 

また、mapToList(Func1<Cursor, T> mapper)メソッドを使うとクエリの実行結果がCursorとして流れてくるので、エンティティへの変換処理を書いてやれば購読時にエンティティのリストを得ることができます。

結果が1件だけの場合はmapToOne(Func1<Cursor, T> mapper)メソッドを使えば、単一のエンティティに変換できます。

Pros / Cons

私の考えたSQLBriteのメリット(Pros)とデメリット(Cons)です。

Pros – 画面間のデータの共有に使える

たとえば、画像などのコンテンツにユーザーがコメントしたときに、その画像を表示している全ての画面でコメントを更新したい状況を考えます。SQLBriteを使って、コメントテーブルに対するSQLクエリを購読すれば、コメントの追加(insert)、修正(update)、削除(delete)に対して全ての画面で最新の状態に更新することができます。また、RxLifecycleと併用すれば、Activityが破棄されている場合は変更イベントを受け取らず次の生成時に再購読する、というようにActivityのライフサイクルに対して安全に通知を受け取ることができます。

Cons – SQLを書くコスト

SQLBriteはORMライブラリではないので、データを取得するために、いちいちSQLを書く必要があります。これまでORMを使っていて、そこから乗り換える場合はSQLの学習コストがかかると思います。私はSQLBriteのシンプルさが好きですが、人によってはORMのような手軽さがなくて苦手かもしれません。このあたりは好みの問題だと思います。

まとめ

この記事では、SQLiteのテーブル変更をストリーム化するライブラリSQLBriteを紹介しました。RxJava好きの方は、ぜひ実際に使ってみてストリームの気持ち良さを味わってください。


2016年09月15日

araki

AndroidAnnotationsからの移行を進めています -Dagger2の導入-

コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリのAndroid版を開発しています。最近、AndroidAnnotationsのDependency Injection部分をDagger2に移行したので、そのレポートを書きたいと思います。技術的な話よりも、なぜ移行に踏み切り、どのように進めていったかという過程について詳しく書いていきます。

移行する理由

AndroidAnnotationsとは、コード量を削減して開発効率を上げることを目的としたライブラリです。アノテーションをつけることで、さまざまなコードを自動生成してくれます。ピクトリンクのAndroidアプリでは、View Binding、クリックリスナーの設定、savedInstanceStateの管理、画面間の値渡し、Dependency Injection (以下、DI) にAndroidAnnotationsを利用していました。実際、コード量の削減に大きく貢献しているように思います。

 

では、なぜAndroidAnnotationsから移行するのか。一番の理由は、AndroidAnnotationsの影響範囲がアプリケーション全体に及んでいたからです。一つのライブラリの影響範囲が広いと、もし何らかの理由(人気が低下して更新がなくなる、他のライブラリとの相性が悪いなど)でそのライブラリ使えなくなった場合、アプリケーション全体に影響してしまうので大きな技術的負債となってしまいます。そこで、AndroidAnnotationsの各機能を少しずつ他のライブラリに移して影響範囲を減らしたいと考えました。もともとDI機能の一部にDagger2を導入していたので、今回はAndroidAnnotationsのDI部分を全てDagger2に移行することにしました。

 

また、

  • ビルド時間の増大
  • Hoge_のような Hogeを継承したクラスが自動生成される → 自動生成されたクラスを意識する必要がある

といった点も移行の理由として挙げられます。

移行の流れ

AndroidAnnotationsの@Bean@RootContextによってクラスやContextをインジェクトしている部分をDagger2を利用したコードに置き換えていきたいと思います。

前提

私の所属するチームでは、GitおよびGithubでコードを管理しています。書いたコードは、必ずPull Request(以下、PR)によるレビューを通してからプロジェクトにマージするというルールで開発をしています。今回は、PRを作成するときや、継続的にコミットするために意識したことを書きたいと思います。

方針を示すPRを作成する

完全に移行が完了した状態でPRを投げた場合、

  • 差分が大きくてレビューが大変になる
  • 指摘があった場合、修正箇所が大きくなる

といった問題が出てくると考えたので、まずは一部の画面にだけDagger2を導入したPRを投げることにしました。実際に投げたPRのメッセージは以下です。

Dadder2導入のPR

今後のコードの書き方に大きく影響するので、他のメンバーに受け入れてもらえるように目的や動作について詳しく書きました。

継続的にコミットを進める

PRが無事マージされたので、次は移行作業に入りました。対象クラスが多くて一気に移行するのは難しい状況だったので、毎日少しずつ移行していくことにしました。一度パターンができてしまえば、移行作業は単純作業の繰り返しでつまらないものです。そのため、日々の業務の中でコツコツ進めるのはモチベーションの維持が大変でした。

そこで、1クラスだけ移行した状態でPRをあげて、PRのメッセージに移行すべきクラスのリストを作り、完了したものにチェックをしていくようにしました。こうすることで、いくつ終わったか、いつ終わりそうかが目に見えるようになったので、モチベーションを維持しながら毎日コツコツと移行を進めることができました。

Inject完了リスト

さいごに

この記事では、Androidアプリ開発をする中でAndroidAnnotationsから移行する判断に踏み切ったこと、そして段階的に移行作業を進めたことについてレポートしました。一度に全てを移行することを考えると終わりがないように見えますが、段階的に取り組むことで確実に前に進むことができると思います。千里の道も一歩からという言葉があるようにリファクタリングも一歩ずつ確実に取り組んでいく必要があると感じました。今後は、View Bindingの部分や画面間の値渡しに対して、リファクタリングを進めていきたいです。