I’m curious what strategies people here use when passing data between screens. Obviously when showing a screen, just putting data in the constructor is easy enough.
But when the pushed screen is an “editor” of sorts, how are you updating the parent screen’s data with the child screen’s result (especially since they aren’t modal).
The two approaches I’ve used so far (disliking both) are:
If the child screen is specific, I can just supply a parent object to it and the screen modifies that. For example, supplying a Contact object to a EditNameScreen.
If the child screen is generic, I supply a delegate function that - on closing - is called with the updated data.
The first I dislike because it can’t easily be reused as a generic “edit string” value. The second I dislike just because adding delegates all over the place gets a bit cumbersome.
I enjoy using a SQLite databse and just updating that. Then just have refresh functions called on editor saves or exits. I keep a redundant table for rollbacking changes for undo support. It’s easy to implement and maintain again and again across projects with reusable SQL. I don’t do IOS/Mac development so apologies if this doesn’t apply there.
it’s also pretty good for supplying test data en-mass since you can fill the SQLite DB with data pretty easily outside the app you’re making.
When I show the second, or next screen, I pass the parent or previous screen as a variable.
If data is to be saved (vs pressing cancel), I call a method on the parent or previous screen, passing variable(s) or a class as parameters. Then I let that screen deal with the data.
If the number of things being passed back are relatively small, make a Property on the screen for each of them, select them all, hold the SHIFT key down, right-click and select Convert to Computer Property.
What you’ll get is a read-only computed property for each one.
As things are changed, update the backing properties and then you can access the read-only portion in the Closing event.
If you’re creating the screen in code, you will need to use AddHandler to redirect the event. Just make sure you call RemoveHandler so you don’t leak screens.
Another option can be notifications between views/objects. It requires setting up delegates but in a somewhat more generic way and allows you to pass whatever information you like between objects. You can use the Notification_Center module in iOSKit (its pure Xojo code and does not depend on the other modules of iOSKit if you dont want to include declares). https://github.com/kingj5/iOSKit/tree/master/Modules/Notification_Center
I often want to update the master screen when the user does something on the detail screen of a split view. So I’ll call a method on the master screen:
Oh that’s interesting. I hadn’t considered the Split View as I’m only developing for the phone with this particular app. I’ll look at using that to potentially hard join them together. Thanks for the idea!
iOS and android app lifecycles where designed for 128 MB RAM devices. Now, with 8Gb+ RAM devices, it is silly to break down your app into discrete objects (screens) to constantly instantiate and destroy them just to save a few Kb of RAM. It is a shame that Xojo decided to build a “modern” tool around such outdated design… iOS and now Android have the same issue
Im not using xojo for mobile, but if I had, I would try to have a single “mobile screen” and put each individual “screen” on containers, create a manager to create, destroy, show, hide, etc the containers, that way you can access properties on the containers, run subs and functions without the constrains of having objects with a weird lifecycle. (not reinventing the wheel, this is how other tools do mobile apps this days)
