Hey! I need a bit a of heads up from experienced compose users. So, I have a pretty large desktop application with lots of screens (=views), about 150 total. We're hoping to start gradual migration to Compose and I am playing around with it to figure out how views should be architectured.
Usually you'll have some kind of storage for data which is used in the UI, depending on the architure pattern it is often called Model or something like that. Additionally, you'll have something which performs actual logic of the UI, it can be called a Controller, or something similiar to that. And of course you have a View, something which defines the visuals of the UI and it's presentation. Depending on the approach (MVC/MVVM/MVA/etc) these entities can be called and organized differently but in the end you have a data, which can be operated upon in some way, and presented to the user somehow.
Most of our current UI is written in such a way, that data and all UI logic is kept in a single class, which nicely encapsulates whole UI state and operations. We would like to continue doing our UIs the same way - it is familiar to all our developers and also will simplify things during the migrations process.
Now to my question, while skimming through various examples and playing with compose a bit I found it difficult to figure out how to organize 'Model' and 'Controller' in a single class. I don't have much experience with jetpack on Android, but the thing I am looking for seems to be usually referred as ModelView. However, I can't find any good examples of ModelView in compose for desktop application thus I can't really understand if it actually the thing which would suit our goals.
- Are there any good, bite-sized examples of ModelView pattern with compose for desktop application?
- If ModelView approach is not actually the thing I am looking for, what would be the best approach to encapsulate business logic and UI state in a single class while allowing it to freely communicate with external systems of the application?