WIP: Clean Architecture Principles #21

Manually merged
vanitasvitae merged 83 commits from cleanArchitecture into master 2 years ago
Owner

This PR adds a cleaner separation of concerns by separating the code using architectural boundaries.

  • app contains android bindings and UI of the Android application
  • data contains a database implementation using the requery ORM framework
  • domain contains the business logic of the app. Pure java only.
  • entities contains pojo dto classes that represent basic entity classes like Account, Message...

TODO (to restore pre-PR functionality):

  • Add accounts
  • Remove accounts
  • Connect account on login
  • Bind RosterStore to database
  • Persistent EntityCaps caching
  • Client State Indication
  • Connect/Disconnect based on "enabled" flag of account
  • Auto-Reconnect using ReconnectionManager
  • Initial connect of enabled accounts on app start
  • Receiving messages
  • Sending messages
  • Notifications on new messages
This PR adds a cleaner separation of concerns by separating the code using architectural boundaries. * app contains android bindings and UI of the Android application * data contains a database implementation using the requery ORM framework * domain contains the business logic of the app. Pure java only. * entities contains pojo dto classes that represent basic entity classes like Account, Message... TODO (to restore pre-PR functionality): * [x] Add accounts * [x] Remove accounts * [x] Connect account on login * [x] Bind RosterStore to database * [x] Persistent EntityCaps caching * [x] Client State Indication * [x] Connect/Disconnect based on "enabled" flag of account * [x] Auto-Reconnect using ReconnectionManager * [x] Initial connect of enabled accounts on app start * [ ] Receiving messages * [ ] Sending messages * [ ] Notifications on new messages
vanitasvitae added the
Module: app
label 2 years ago
vanitasvitae added this to the (deleted) milestone 2 years ago
vanitasvitae self-assigned this 2 years ago
Poster
Owner

I should probably redo 6ae00a936b again. We probably do want to have some sort of MercuryConnectionRegistry, that does know each account and does react to enable/disable/delete events by connecting/disconnecting the connection.

Right now it is a little bit tidy to sort out events as

  • observeAllAccounts only returns a list (Observable<List>) of all accounts on each change, but there is no convenient way to transform that list into events like account XYZ added, account ABC deleted etc.
  • above technique would also collide with the way we currently add new accounts, as we would run into twice-connected accounts that way.
  • Observing changed accounts as Observable does not work either, as there is no emission for deleted accounts.

What we probably need is a registry where existing accounts are registred on startup. Registered accounts are observed on a per-account basis, so that each account has its own subscriber that acts on enabled-changes by connecting/disconnecting. These subscribers also do initial connection if needed.

This would allow usecases to register accounts after inserting them into the database and/or connecting, which would allow fine-grade control.

I should probably redo https://codeberg.org/Mercury-IM/Mercury-IM/commit/6ae00a936b3fe64155a047c6e34ead57ee520174 again. We probably do want to have some sort of MercuryConnectionRegistry, that does know each account and does react to enable/disable/delete events by connecting/disconnecting the connection. Right now it is a little bit tidy to sort out events as * observeAllAccounts only returns a list (Observable<List<Account>>) of all accounts on each change, but there is no convenient way to transform that list into events like account XYZ added, account ABC deleted etc. * above technique would also collide with the way we currently add new accounts, as we would run into twice-connected accounts that way. * Observing changed accounts as Observable<Account> does not work either, as there is no emission for deleted accounts. What we probably need is a registry where existing accounts are registred on startup. Registered accounts are observed on a per-account basis, so that each account has its own subscriber that acts on enabled-changes by connecting/disconnecting. These subscribers also do initial connection if needed. This would allow usecases to register accounts *after* inserting them into the database and/or connecting, which would allow fine-grade control.
vanitasvitae closed this pull request 2 years ago
The pull request has been manually merged as 576b300732.
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.