Repositoryパターンで実装しています。コードはすべてKotlinで記述し、Jetpackを積極的に採用しました。DIにはDagger2を採用しています。Repositoryパターンで実装するにはJetpackの活用は外せません。公認アプリでもフル活用しています。Activityで実装しました。Fragment間の遷移はNavigationを、値の受け渡しはSafeArgsを利用しています。Activityの良い点は、ViewModelを通すことで、Fragment間の値の受け渡しが非常に効率的で簡単になることです。そのおかげで公認アプリでは、あるアーティストの詳細画面でタイムテーブルをお気に入りにしたとき、一覧画面にもタイムテーブル画面にも、お気に入りにしたことが即座に反映されます。Activityで、ViewModelとLiveDataを採用しているおかげです。Activityで困る点もありました。それはToolbarと遷移アニメーションの扱いです。ToolbarはActivityに設置することが普通です。アーティスト一覧画面から詳細画面に遷移するとき、右から左にスライドするような遷移アニメーションを加えようとすると、ToolbarがActivityにあると違和感のないアニメーションにすることが困難です。ToolbarをFragmentに持たせる方法もありますが、予期せぬバグが発生する可能性を考慮してそれはやめました。今回は、遷移アニメーションをシンプルにすることで解決しました。Roomは、通信環境がなくてもアプリが利用できるようにするためには欠かせないライブラリです。フジロック開催中の会場では、インターネットに接続しづらい状況が発生します。公認アプリでは、そのようなときも利用できるように、あらかじめアーティスト情報などをダウンロードしてローカルDBに格納し、それを表示しています。その制御にRoomを活用しました。このように、Androidの公認アプリでは、最新の構成と設計に沿うように開発しました。続いて、iOSアプリで採用した技術を紹介します。iOSアプリの基本構成と設計PARTYでエンジニアをしている児玉(@_hrkd)です。今年が3度目の参加となったフジロッカーです!公認アプリは、ユーザー自身がPOSTやPUTなどの処理を行うことのないシンプルな要件で、ステート管理などには特に悩まされることはなかったため、シンプルにMVC構成を取っています。フジロックの会場のシビアな通信環境は開発当初から自明でしたので、モデル層でのアーティストデータなどのハンドリングにはかなり気を使っています。シビアな通信環境でもスムーズに利用できる工夫アプリ起動時のロード時間はたとえ数百KBの情報でも会場内では長く、ストレスになることが予想されたため、アーティスト情報やタイムテーブルなどの主要な情報はすべてJSONファイルとしてアプリ内にバンドルしました。アプリ起動時にはクラウド上にあるデータの更新日時をチェックし、バンドルされている情報より新しい場合のみデータをダウンロードするような制御をしています。アーティスト画像の取り扱いについては事前にサイズの最適化処理を実施し、アプリ側の読み込みには取得速度が早いと評判のNukeを採用しました。読み込み後のアニメーション実装もシンプルです。いった地道な実装のおかげで会場内でもストレスなく動作するUXが実現できていたと思います。Viewの実装においてお世話になったライブラリ短い開発期間を乗り越えさせてくれたライブラリ達は以下のとおりです。全画面で利用した、横スワイプ可能なタブビューを実装できるライブラリ。タイムテーブル表示の実装に利用させていただきました。ピンチズームなどの実装は自前で行う必要があります。テーブルビューのセルが0件のときにViewの切り替えをスピーディーに実装できます。CROWD(クリエイティブ集団)」です。クリエイターへのお問い合わせフィードバッククリエイターの。