Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apps Networking Architecture #18

Open
rodvar opened this issue Oct 27, 2024 · 4 comments
Open

Apps Networking Architecture #18

rodvar opened this issue Oct 27, 2024 · 4 comments
Assignees
Labels
BisqClients This issue is applicable ONLY for `xClients` apps low-prio issue is low priority whilst having this label

Comments

@rodvar
Copy link
Collaborator

rodvar commented Oct 27, 2024

Follow up to #10

This issue has the following goals:

  • xClients apps (android and iOS) will have the same time of https networking, so first goal for this task is to create that and make sure its only used in these 2 apps.
  • androidNode app will have its own complex networking provided by bisq2 jars (this issue is the opportunity to start understanding how that works to be able to isolate it from the app design architecture)
  • considering all the above, structure needs to be built for the App design (MVP) to seemlessly use a facade for the networking and make its implementations solve the under the hood complexities
@rodvar rodvar self-assigned this Oct 27, 2024
@rodvar
Copy link
Collaborator Author

rodvar commented Oct 27, 2024

this might be a good candidate to add KMP Koin lib for DI and grow from there (optional for now)

@rodvar
Copy link
Collaborator Author

rodvar commented Nov 8, 2024

this will be tackled partially by and after finishing #6 so that we have a clear understanding on both worlds (xClients and androidNode)

@rodvar
Copy link
Collaborator Author

rodvar commented Nov 13, 2024

this will be tackled partially by and after finishing #6 so that we have a clear understanding on both worlds (xClients and androidNode)

after doing the above, came to the conclusion that this is not that important at the moment. So I'm downgrading the priority in favor of settings the grounds for the shared repositories concept we are discussing on matrix.

the androidNode networking foundation has been laid with the closed issue #6 , further development will continue in a per use-case base

@rodvar rodvar added the low-prio issue is low priority whilst having this label label Nov 13, 2024
@rodvar
Copy link
Collaborator Author

rodvar commented Nov 14, 2024

Next steps and update on this issue now that we have a clearer picture of the overall architecture, this becomes basically developing the networking for the xClients cause the androidNode can grow individually. This is thanks to the way in which we implemented MVP.

  1. shared/networking module using KTor so that services can incorporate the httpClient to do requests when needed (eventually wss when we figured out bisq-api).
  2. create a BaseService that gets the client inyected with some basic helper methods that every service will use
  3. the base service will need the settings repository to get info about the trusted node to connect to.

on the android node side there is some stuff to do but can be done independently whilst working each of the features.

@rodvar rodvar added the BisqClients This issue is applicable ONLY for `xClients` apps label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BisqClients This issue is applicable ONLY for `xClients` apps low-prio issue is low priority whilst having this label
Projects
None yet
Development

No branches or pull requests

1 participant