Clean account types
- Dominant language
- Kotlin
- Stars
- 5.6k
- Forks
- 2k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 92
Description
### Actual behaviour
The app handles account using 4 (!) different formats:
- `Account` - obviously
- `OwnCloudAccount` - wraps account, platform API + adds some own API
- `String` - needs to get account by name
- `int` - get by hash code?
Of course the conversion, getters, etc code spills to code that actually uses account data.
### Expected behaviour
- 1 (one) data type to deal with.
- data type provides all required API to query about account capabilities (this logic taints the UI heavily)
- no ad-hoc conversions are required to manage app accounts
### Solution
- Immutable `NextcloudAccount` type providing all the functionalities.
- Current account available directly in `UserAccontManager`, avoiding expensive queries to platform `AccountManager`
- No references to `Account` (long term, I guess)
### Alternatives
- sanitizing `OwnCloudAccount` but it's not a data type as it brings a lot of platform services with and does not provide too much functionality right now
Contributor guide
Assessment
This issue has not been assessed yet.