pachli-android/core/data/build.gradle.kts

49 lines
1.5 KiB
Plaintext
Raw Normal View History

/*
* Copyright 2024 Pachli Association
*
* This file is a part of Pachli.
*
* This program is free software; you can redistribute it and/or modify it under the terms of the
* GNU General Public License as published by the Free Software Foundation; either version 3 of the
* License, or (at your option) any later version.
*
* Pachli is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
* the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
* Public License for more details.
*
* You should have received a copy of the GNU General Public License along with Pachli; if not,
* see <http://www.gnu.org/licenses>.
*/
plugins {
alias(libs.plugins.pachli.android.library)
alias(libs.plugins.pachli.android.hilt)
change: Implement more of FiltersRepository (#816) The previous code had a number of problems, including: - Calls to the filters API were scattered through UI and viewmodel code. - Repeated places where the differences between the v1 and v2 Mastodon filters API had to be handled. - UI and viewmodel code using the network filter classes, which tied them to the API implementation. - Error handling was inconsistent. Fix this. ## FiltersRepository - All filter management now goes through `FiltersRepository`. - `FiltersRepository` exposes the current set of filters as a `StateFlow`, and automatically updates it when the current server changes or any changes to filters are made. This makes `FilterChangeEvent` obsolete. - Other operations on filters are exposed through `FiltersRepository` as functions for viewmodels to call. - Within the bulk of the app a new `Filter` class is used to represent a filter; handling the differences between the v1 and v2 APIs is encapsulated in `FiltersRepository`. - Represent errors when handling filters as subclasses of `PachliError`, and use `Result<V, E>` throughout, including using `ApiResult` for all filter API results. - Provide different types to distinguish between new-and-unsaved filters, new-and-unsaved keywords, and in-progress edits to filters. ## Editing filters - Accept an optional complete filter, or filter ID, as parameters in the intent that launches `EditFilterActivity`. Pass those to the viewmodel using assisted injection so the viewmodel has the info immediately. - In the viewmodel use a new `FilterViewData` type to model the data used to display and edit the filter. - Start using the UiSuccess/UiError model. Refrain from cutting over to full the action implementation as that would be a much larger change. - Use `FiltersRepository` instead of making any API calls directly. ## Listing filters - Use `FiltersRepository` instead of making any API calls directly. ## EventHub - Remove `FilterChangedEvent`. Update everywhere that used it to use the flow from `FiltersRepository`.
2024-07-14 15:36:52 +02:00
alias(libs.plugins.kotlin.parcelize)
}
android {
namespace = "app.pachli.core.data"
defaultConfig {
testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
}
}
dependencies {
implementation(projects.core.accounts)
implementation(projects.core.common)
implementation(projects.core.database)
implementation(projects.core.model)
implementation(projects.core.network)
implementation(projects.core.preferences)
// PreferenceDataStore
implementation(libs.bundles.androidx)
// ServerRepository
implementation(libs.semver)
testImplementation(projects.core.networkTest)
testImplementation(libs.bundles.mockito)
}