アーリーアクセスを公開しました
2017.12.05. 更新
「2章 OSSにおける設計者の役割」のアーリーアクセスを購入者限定で公開しました。
テキストを選択してコメントを残すことができます。気になった点、面白かった点、誤字脱字などありましたらお気軽にコメントしてください。
当プロジェクト「Android アプリ設計パターン入門」の書籍がついに完成しました。
大人気の技術書を多数リリースしているTechBoosterによる最新刊執筆プロジェクト!第一線の著者陣がAndroidアプリケーションの設計パターン入門書を書き下ろします。
設計の基本を理解できるだけでなく、第2部では生きた設計をテーマとして、実際のプロダクトをベースにソースコードを見ながら各アーキテクチャの特徴、設計指針、実装を解説します。「この本を土台にAndroidアプリケーション設計の議論ができるようにしたい」という代表 日高氏の言葉の通り、最初の一冊かつ、誰もが知る設計の基礎知識を担う本になることと思います。
みなさんの応援でぜひプロジェクトを成立させてください。
プロジェクト成立!
プロジェクトを成功させるには、たくさんの応援が必要です。
プロジェクトをシェアして応援しましょう!
価格(税込)
5,000円
価格(税込)
3,000円
価格(税込)
4,000円
1,000円 OFF!本書はモバイル分野のAndroidアプリケーション設計手法を解説する入門書です。
設計というテーマで書籍をまとめようと思った動機として「設計手法の選択は、とても難しい判断であり、正解はやってみないとわからない」ことが挙げられます。
バランスの問題と言い換えてもいいかもしれません。アプリの要件や開発プロセスなどプロジェクトの背景や開発者の技術的嗜好およびスキルセットなど技術的背景によってベストな手法が変化していくでしょうし、新規開発では大胆にチャレンジできても差分開発では地に足をつけた方法を選ぶことがあります。 開発者はこのような背景を抱えながらも、設計を通じてコミュニケーションを図り、今後の変更に柔軟に対応できて、不具合が出にくい強固なソフトウェアを目指します。
近年ではスマートフォンの普及、利用シーン拡大によりアプリの果たす役割は拡大し、変化を続けています。 本書は設計手法をすべて収集して解説するといった図録的な役割は持ち合わせていないでしょう。やりたいことは設計について議論する土台を作ることです。 アプリの設計を評価し、利点や欠点を率直にまとめること、プロジェクトの背景や技術的背景を知り、どのようなケースで有用なのかという実例を収録します。
これらの例は自分たちのアプリ開発で、どの設計がベストなのか疑問を話し合う土台として有効に機能するはずです。自分たちのプロジェクトを改善するための視点の獲得や見えていなかった課題の気付きといった形で現れると大変うれしく思います。
収録内容は、アプリ開発のプロフェッショナルが四苦八苦しながら形にした知識、知見です。役に立ってくれるに違いありません。 さきほど話の流れでついプロフェッショナルと表現しましたが、いたって普通の開発者です。というのもモバイルアプリのアーキテクチャは移り変わりが激しく、今良いと思って勧めたものでも将来に渡って良いかは保証されておらず、間違えたことを言っていないかと常に不安がつきまといます。このような不安は開発者全員が持ち合わせているのではないでしょうか。 そこで本書を書き終えるまえにベータ版として出資者のみなさんに読んでもらい、疑問点やヒントをもらいたいと考えています。すべての人が満足するように結果を反映するのは難しいですが、多くの目に触れてレビューし、議論し、設計に関して多くの視点をもつことがより良い選択に繋がると信じているからです。
第1部ではアプリケーション設計の基礎を解説します。第2部は実際のアプリケーション開発現場に注目してどのような課題を解決するための設計なのかいろいろなアプローチを紹介します。第3部は、最近登場したコンポーネントやKotlinが及ぼす設計への影響を議論します。
ソフトウェア設計は課題を解決し、目的を達成する手段といえます。アプリケーションの設計には答えはありませんが、設計手法を知ることは、よりよい開発の一助となります。 ここではAndroidプラットフォームの特徴について解説し、アプリの基本構成としてMV*パターンを学びます。第1部ではAndroid ArchitectureのTODOアプリをサンプルに基本的なパターンを紹介していきます。TODOアプリは面白みはありませんが要件が明確なことから各パターンの違いを見比べ、知れます。それぞれの設計手法に優劣はありませんが、どのような構成が自分にあっているかという得手・不得手はあります。第1部では各手法の性質を確認できます。
新規開発と継続(差分)開発は考慮するべきことは異なります。長期にわたる開発では、アーキテクチャや設計思想の変遷、Androidのバージョンアップ、流行、メンテナンス性を維持するために払うコストなどさまざまな要因の影響を受けるためです。 本章では差分開発での課題と解決するための設計というテーマを中心におき、著者の所属するメルカリのAndroidアプリを題材として開発イテレーションのなかで整合性を維持し、今後も使い続けていくコードをどのように育てていけばいいか、という日々のチャレンジがしやすい設計について紹介します。
DroidKaigi 2017のカンファレンスアプリでは、GitHubで公開後に60人以上のエンジニアから250を超えるPullRequestが集まりました。色々な人が関わるオープンソースプロジェクトなので、あまり複雑になりすぎず、かつAndroidアプリを作る上での問題を解決できるようMVVMを採用しています。中には、DataBindingの活用の仕方に戸惑ったり、ViewModelの役割に少し疑問を持つ方もいるかもしれません。 本章では、MVVMを採用した経緯から、パッケージ・クラスの分け方の指針まで、DroidKaigiアプリ設計の「なぜ」の部分を詳しく説明していきます。また、ここはこうした方がよかったかも、といった実際の反省点にも触れる予定です。Androidアプリの設計に悩む皆さんにとって少しでも参考になれば幸いです。
FluxアーキテクチャはFacebookのMobile Web Applicationで用いられているアプリケーション設計です。著者の所属する株式会社サイバーエージェントではAbemaTVをはじめとした多くのAndroidアプリケーションで、このFluxアーキテクチャをAndroidアプリケーションのアーキテクチャとして、(各チームがそれぞれアレンジを加えながら)用いています。 本章では実際にFluxアーキテクチャをどのように用いているかを解説しながら、アプリケーションで実際に用いた上で感じたメリットデメリットについて書く予定です。 これからAndroidアプリケーションにFluxアーキテクチャの導入を考えている方にとって少しでも参考になれば幸いです。
アーキテクチャはチームのために存在しています。チームとは人です。すなわち人がプロダクトを正しく作るためにアーキテクチャは存在しています。 人を支えないアーキテクチャは意味がありません。Androidが出た当初は、限られたリソースの中でうまく動作させるために、組み込みアプリケーションの方法論が重要でした。時代は進み、いまやAndroid端末のスペックは一昔前のPCと遜色がありません。提供する機能は複雑化し、画面も増加し、品質の要求は上がり、開発規模が増大して関係者も増えました。今こそアーキテクチャの出番がやってきたというわけです。 本章では中長期的にチームでAndroidアプリケーションを開発するにあたって直面した課題と、解決するために考えたこと、実際に行ったことを紹介します。取り扱うソースコードはGitHubで公開しているMastodonのAndroidクライアントアプリケーション「DroiDon」です。DroiDonは個人で開発を進めていますが、これまでのチームでの経験をすべて詰め込んで設計し、VIPERアーキテクチャを採用しています。これに近いアーキテクチャを著者の所属するトクバイのアプリでも採用してます。アーキテクチャ設計の議論のたたき台として活用できることでしょう。
出資者の設計上の課題をきいて、一問一答形式で案を出すコーナー
2017.12.05. 更新
「2章 OSSにおける設計者の役割」のアーリーアクセスを購入者限定で公開しました。
テキストを選択してコメントを残すことができます。気になった点、面白かった点、誤字脱字などありましたらお気軽にコメントしてください。
2017.07.13. 更新
目標人数を達成し、プロジェクトが成立しました!たくさんのご支援ありがとうございます。プロジェクトの進捗・執筆状況はは随時こちらで報告していきます。引き続きよろしくお願いいたします。