鯰の住処

Namazuが真面目な話を書きます

■

Android

PokeApp作成記録

今年初めにPokemon LEGENDS アルセウスをプレイしましたが、実は人生で初めて遊ぶポケモンでした。 折角なのでライブラリの試用がてらポケモンに関連したアプリを作ってみました。 このブログでは作成したアプリの概要と使用したライブラリについて記述しています。

GitHub: https://github.com/BlondeNamazu/pokeapp

アプリの動作概要

PokeAPIを利用し、ポケモン一覧の取得/詳細情報の閲覧/お気に入りの登録が出来るアプリを作成しました。

ポケモン一覧画面

/pokemonエンドポイントを叩き、ポケモンの図鑑No.と名前を一覧表示しています。

ポケモンの名前が書かれたアイテムをタップすることで、そのポケモンの詳細画面に遷移することができます。

ポケモン詳細画面

/pokemon/{id}エンドポイントを叩き、ポケモン詳細情報を表示しています。

名前の横のお気に入りボタン（ハートマーク）を押すことで、そのポケモンをお気に入りに登録出来ます。

お気に入りポケモン一覧画面

お気に入り登録したポケモンの一覧を表示しています。（PokeAPIは関係ありません）

ポケモンの名前が書かれたアイテムをタップすることで、そのポケモンの詳細画面に遷移することができます。 また、名前の横のお気に入りボタンを押すことでお気に入り登録を解除できます。

以下、便宜上ポケモン一覧画面とお気に入りポケモン一覧画面のある画面をホーム画面と呼びます。

使用ライブラリ

主に使用したライブラリの一覧は以下です。

以下は、ライブラリを触ってみた所感です。

Jetpack Compose

xmlで記述するAndroid Viewと比べてかなり書きやすくなったと感じます。 レイアウトをコードで記述出来るという根本的な部分が個人的に好みなだけでなく、プレビュー機能なども充実しておりかなり実用的です。 また、xmlで記述する場合はViewのスタイルの指定などで必要以上にファイルが増えてしまうことも少なくありませんでしたが、それに悩まされないところも嬉しいです。

(Compose) Navigation

今回はホーム画面内でポケモン一覧画面とお気に入りポケモン一覧画面の間の遷移でCompose Navigationを利用しました。 BottomBar(BottomNavigationBar)と組み合わせており、BottomBarのアイコンをタップすると対応するページに遷移することが出来ます。 Compose Navigationを用いる場合は遷移先の情報をStringで持つ必要があり、BottomBarと組み合わせる場合はアイコンやラベルもつけることとなります。このあたりの遷移先情報はenum classでまとめてスッキリさせています。

さて、今回はCompose Navigationと既存のFragmentのNavigationの両方を使用してみたのですが、個人的には現時点でCompose Navigationをアプリ全体で利用することは難しいと考えています。 特に業務で開発するような大規模なアプリケーションでは全ての遷移を1つのNavigationで書くことは難しいですし、遷移先情報をStringで管理するということもメンテナンスコストが高くなるのではないかと懸念しています。 そこで基本的にはFragmentのNavigationを使い、一部の小規模な遷移が必要な画面でCompose Navigationを使用していくという使い分けが良いのではないかと考えています。今後のアップデートで利便性が向上し、Compose Navigationを使用したくなる場面が増えていくことを楽しみにしています。

Paging

今回最も振り回されたのはPaging Libraryかもしれません。 元々ポケモン一覧画面ではポケモンの画像も同時に表示したかったのですが、PokeAPIではページングが可能な一覧API（/pokemon）ではポケモンの名前と詳細情報を取得するためのURLのみが返ってくるという仕様の都合上断念しました。 せめて詳細画面を開くなどして画像URLを含む詳細情報を取得したポケモンに関しては、一覧取得APIの情報とRoomに保存した情報を組み合わせて表示することも考えたのですがPaging Libraryではその方法が禁止されています。 業務で使用する際はこのあたりも考慮したうえでAPI設計をする必要がありそうです。

Room

ポケモンのお気に入り状態を含むポケモン詳細情報に関しては、Roomに保存された情報をSSOTとしました。 画面ごとに情報を持つような仕様にしてしまうと情報の不整合が起こりやすくなるため、アプリ全体で参照する情報は可能な限り情報源から直接参照する形が理想的です。 Roomではこのサポートが強力で、Flowと組み合わせることで情報の更新にも対応出来るようになっています。 クライアントのDBはAPIから取得したデータのキャッシュとしての役割が大きいですが、このサポートを活用するメリットは大きいので積極的に利用していきたいライブラリの一つです。

さいごに

一旦ブログまで書きましたが、まだまだ改善出来る部分はあるので暇を見つけて改善を入れていきたいと思います。 次はサーバーサイドとかも書くアプリ作りたいですね。