@eaglesakura です。 DroidKaigi 2018の公募で落ちたため、Qiitaに書きます。 ある（私の感覚としては）規模の大きな案件を成功させるにあたり、プロジェクト全体でFirebaseをフル活用する方針をとり、概ね成功したと思われるので、どのようなことを行ったのか後々のために書き残しておきます。 前提 Android / iOS両対応で、コンシューマ向けアプリ開発でのお話です。 Firebase Realtime Databaseの導入理由 アプリ仕様上、サーバー上の マスターデータ を無数のAndroid / iOS端末でリアルタイム同期しなければならないため、必然的にFirebase Realtime Databaseが候補として上がり、それを導入することとしました。 Firebase Realtime Databaseは信頼に値するのか？ デモ日にFirebase

@eaglesakura です。 結論から言うと、DIは怖くないぞ。 DI(Dependency Injection, 依存注入)は昨今のプロダクト開発では当たり前のように使われています。 DIそのものに関しての解説は参考URLを読んでください。 参考 http://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f 私自身は今年になって担当案件の開発規模が大きくなり、それに従ってUnitTestや依存関係が増えてきたことで、スマートな依存解決を求めて「どんなもんだろうな」と調べるようになりました。 遅いですか？ 遅いですね。 AndroidのDIライブラリ 一般的なAndroid界隈の開発では Square/Dagger やそれをForkした Google/Dagger2 が有名です。 なぜDagger系ライブラリを使わなかったのか コードの追いづらさ

前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である

アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ

@eaglesakuraです。 俺、L-Previewやめるってよ Android L PreviewがリリースされてからこのかたずっとLを使い続けていました。日経ソフトウエアで新APIの記事書いてるので、みんな買ってね♡ さて、Lの新機能は非常に良く出来ていますが、ぶっちゃけて言えばDeveloper Previewなのでバグバグです。どのくらいバグバグかといえば、たまに3G/LTE回線にすら繋がらなくなる（電波は3本立っている）くらいバグバグです。 Preview版なので、別に完璧は求めてません。単に、俺個人の感想として「L-Previewは人類には早すぎた」とか思ってるだけです。 ようやくまとまったお金を手に入れることができ、常用端末と開発用端末を切り離すことが出来ました。喉元過ぎて忘れないため、L−Previewで何が問題だったかをメモっておきます。 なお、ここでのバージョンはLP