VLC for Androidのリポジトリについて

6860 ワード
Android Room リポジトリパターン Android テキストリンク

はじめに

リポジトリとはなんぞやとや言うことで有名OSSメディアプレイヤーアプリである「VLC for Android」にあるリポジトリの実装を調べる。
当方はAndroidの素人なのでその辺はご了承を。

各種リンク

アプリ
GitHub
公式サイト

アプリ内で定義しているリポジトリ

クラス 概要
BrowserFavRepository お気に入りを保持？
DirectoryRepository ディレクトリを保持？
ExternalSubRepository 外部ストレージ
MediaMetadataRepository メタデータ
MediaPersonRepository ?
MoviepediaApiRepository MoviepediaのApi
OpenSubtitleRepository ?
PersonRepository MoviePediaから取得した人をキャッシュ
SlaveRepository ?

データソース

どこからデータを持ってきているかを調べた結果。データベースとAPI、オンメモリーの３つのパターンがある

クラス データソース
BrowserFavRepository データベース(BrowserFavDao)
DirectoryRepository データベース(CustomDirectoryDao)
ExternalSubRepository データベース(ExternalSubDao)、 オンメモリー
MediaMetadataRepository データベース(MediaMetadataDataFullDao、MediaMetadataDao、MediaImageDao)
MediaPersonRepository データベース(MediaPersonJoinDao)
MoviepediaApiRepository REST API(IMoviepediaApiService)
OpenSubtitleRepository REST API?(IOpenSubtitleService)
PersonRepository データベース(PersonDao)
SlaveRepository データベース(SlaveDao)

ユニットテストを入れているか

クラス 　テストクラス
BrowserFavRepository ○(BrowserFavRepositoryTest)　
DirectoryRepository ○(DirectoryRepositoryTest)
ExternalSubRepository ○(ExternalSubRepositoryTest)
MediaMetadataRepository ×
MediaPersonRepository ×
MoviepediaApiRepository ×
OpenSubtitleRepository ○？(SubtitlesModelTest)
PersonRepository ×
SlaveRepository ○(SlaveRepositoryTest)

データ取得元がデータベースの場合のクラス構成

↓はExternalSubRepository周りのクラス構成。ExternalSubクラスはデータベース、SubtitleItemはオンメモリーで管理している。
LiveData、Coroutineが絡んでいるがここでは割愛する。

ExternalSubRepositoryの責務はなんなのかというと、↓のコードをにある、Roomでは表現できない？制約にそってCRUD操作を実装している。後はテスタビリティの確保。

   fun addDownloadingItem(key: Long, item: SubtitleItem) {
        _downloadingSubtitles.add(key, item.copy(state = State.Downloading))
    }

    fun getDownloadedSubtitles(mediaUri: Uri): LiveData<List<org.videolan.vlc.mediadb.models.ExternalSub>> {
        val externalSubs = externalSubDao.get(mediaUri.path!!)
        return Transformations.map(externalSubs) { list ->
            val existExternalSubs: MutableList<org.videolan.vlc.mediadb.models.ExternalSub> = mutableListOf()
            list.forEach {
                if (File(Uri.decode(it.subtitlePath)).exists())
                    existExternalSubs.add(it)
                else
                    deleteSubtitle(it.mediaPath, it.idSubtitle)
            }
            existExternalSubs
        }
    }

　

データ取得元がREST APIの場合のクラス構成

↓はOpenSubtitleRepository周りのクラス構成。

OpenSubtitleRepositoryの責務はなんなのかというと、↓のコードにある通りRest APIのクエリーパラメータの組み立てと補正。
クエリーオブジェクト的な責務を行っている状態。後はテスタビリティの確保。

    suspend fun queryWithImdbid(imdbId: Int, tag: String?, episode: Int? , season: Int?, languageId: String? ): List<OpenSubtitle> {
        val actualEpisode = episode ?: 0
        val actualSeason = season ?: 0
        val actualLanguageId = languageId ?: ""
        val actualTag = tag ?: ""
        return openSubtitleService.query(
                imdbId = String.format("%07d", imdbId),
                tag = actualTag,
                episode = actualEpisode,
                season = actualSeason,
                languageId = actualLanguageId)
    }

ExternalSubRepositoryのユニットテスト

案の定、ExternalSubDaoをモック化してテストしている。

OpenSubtitleRepositoryのユニットテスト

SubtitlesModelTestで行っている。SubtitlesModelはViewModel派生のクラスで色々面白い事をしているがここでは触れない。
OpenSubtitleRepositoryそのもの、ExternalSubDaoをモック化してテストしている。 RetroFitのクラスはモック化していなかった。

その他リポジトリの(テスタビリティ担保以外の）責務

クラス (テスタビリティ担保以外の）責務
BrowserFavRepository サーバー保存のお気に入りとローカル保存のお気に入りの整合性をとっている？
DirectoryRepository 実際にフォルダを作成、削除して、DBに同期している？
ExternalSubRepository 説明済
MediaMetadataRepository クエリーの組み立て
MediaPersonRepository なし
MoviepediaApiRepository クエリーの組み立て
OpenSubtitleRepository 説明済
PersonRepository なし
SlaveRepository 様々な保存パターンに対応する。SQL例外の補正

まとめ

  • テスタビリティ担保以外の主な責務はクエリーの組み立て、サーバーとローカルキャッシュの整合性、SQL周りの隠蔽、Retrofit周りの隠蔽
  • Coroutine、LiveDataと密結合している。AndroidのUIでしか使わないから？
  • シングルトンについてSingletonHolderとCompanionオブジェクトを分けているのはなに？