Multiple windows in MacOS, iPad apps (and perhaps Android, etc...)

[matthewpflueger]

Hi,

Are there any known strategies for working with Crux when multiple windows are opened in MacOS and/or iPad apps (maybe even iOS apps)?

As I understand it, each window gets its own state and I was curious if crux has been used in this manner (multiple views) and what I should look out for (if anything).

Any advice greatly appreciated!

[charypar]

Hi @matthewpflueger! We've not explicitly tried this, but as I imagine it, nothing should stop one having a shared core for multiple windows in an app 🤔 The boundary I would imagine is a fair bit firmer is when app windows run in separate processes, but I'm not aware of app frameworks generally enforcing that. I might be wrong though.

Would you have an example where this is problematicm which we could look at?

[matthewpflueger]

No specific problem yet - just thinking ahead. I am building an app where I think it is reasonable for multiple windows to be opened and different views shown. Because in Crux there should be one view model derived from the model, I was thinking if there were multiple windows, the view needs to be smart enough to select/show the right things in the view model.

For example, if I have a Reminder app with multiple lists and open up a different window to show different lists, I need the view to know what list it is currently showing and NOT have something generic in the view model like current list that the view just displays. I think this is reasonable but at the cost of having some logic in the view that will need to get duplicated across platforms.

Any thoughts? Suggestions?

[charypar]

I would probably lean towards having a view model that looks something like:

struct ViewModel {
  windows: Vec<Window>
}

enum Window {
  TodoListWindow(TodoListViewModel),
  PreferencesWindow
}

The (presumably somewhat complicated) logic of constructing that is still in the core, and the shell can then unpick that and forward it down to the individual window. That way the shells are in charge of how to present multiple windows - mobile could do some paging business, a TUI could do splits or tabs (like tmux)...

Shoudl that fail, you could opt for a smarter Render capability which takes Window as payload, and dispatch that to the right window in the shell.

In a way, this is not very different from having a single screen split in two, where each half can display different kind of content, including the same content the other half is showing. At least that's how I'd think about describing it in the view model.