Open douglasg14b opened 3 months ago
Hello, thanks for your thoughts and detailed suggestions!
It is indeed more reasonable for the server to manage and control data. However, because LifeUp did not have such a plan at the beginning, the current Android logic is difficult to change and abstract the data processing logic applicable to the server.
Nowadays, using Android apps as servers is a tricky way - Android apps rarely need to be modified, and existing API capabilities can be reused.
We will also consider whether we can make changes in this direction in the future, but for now, we can only say that the workload will be very huge and can only be regarded as a long-term goal.
We may also consider redesigning a new project based on the new architecture.
Thanks for the reply, I really appreciate it. It'd good to hear that we're on the same page, but incredibly disappointing that it may not be possible for a long time 😢
There's a whole ecosystem that can integrate automation into task management. I hope someday we either have an app that has deep API integration, or LifeUp Pro gains API capabilities.
I intimately understand the difficulty in redesigning architecture or application design that was not built with such extensibility in mind. That can be a daunting task, and sometimes re-designs can be easier than remediation. I assume the android app is written in Java? I've done similar remediation's on other projects, and tend to go for a local client/server approach to ensure the UI is detached from the actual logic behind the app itself, easing in the transition or extension of an external API. This is a tedious process however, and probably 1/2 times ends up with the platform being rewritten.
Anyways, good luck!
For various reasons I do not wish to run an HTTP server from my phone. However, running this from a server, or a docker container, would be valuable.
This would also allow for more integrated "cloud like" functionality if the app can point to a hosted cloud instance that can push tasks, task completion, updates, config...etc This could also enable DIY handling of "join task lists" for partners or families.
This can also enable usage of a DB like CouchDb which is well suited for direct client websockets as well as handling document diffs and conflicts for applications like multi-device sync or a family of LifeUp apps.
Essentially, inverting the client-server relationship to follow a more typical pattern so the mobile device is a client which may receive update from the server. Instead of the mobile device being the server, and custom servers/code being the "client".
Why: