[Question] Sharing data between App and Screens

[anzhi0708]

Hello, another noob question ;-P

The example code (e.g. five_by_five.py) are about opening a blank, pure-text screen, I could not figure out how to pass data between App class and Screen objects. Like, only one App instance was allowed, then what's the relationship between Screens and the App? Can I simply visit App's instance variables by calling self.app.data in class Screen? I tried self.parent but it was not working. Or do I have to use global variables to share data? Thanks a lot :3

[anzhi0708]

Oh I think I just figured it out, just overwrite every __init__ method and I think that will do the trick.

[davep]

Can I simply visit App's instance variables by calling self.app.data in class Screen?

Every widget from Screen down has access to self.app so, if you're holding your app state in your app, that's one route to it.

As for the more general questions about Screen, perhaps the guide entry for them will help?

[anzhi0708]

Thanks a lot man!

And sorry for taking your time for this kind of noob questions ;-(

Here's another: Screens do not have push_screen method, how could I switch from Screen B to Screen C then?

[davep]

No apology needed, always happy to help out and provide pointers. :-)

Here's another: Screens do not have push_screen method, how could I switch from Screen B to Screen C then?

push_screen and related methods are part of the App class. And, as pointed out above, all widgets can access their app via self.app, so... (I'm sure you're way ahead of me by this point ;-) )...

[anzhi0708]

OK I see, Screens actually can visit App's data by calling self.app.data, I dunno why the LSP did not work but thanks!

[davep]

If you're using some sort of type checker then, yes, it'll complain that any custom attributes on your app aren't available. The reason is that self.app will be typed as App, not MySuperCoolNewApp which you'll have created and inherited from App. There's currently no simple way around that I'm afraid, but self.app will be an instance of your app class, even though the type hinting and inference will say otherwise.

If you want to work around that (I prefer to so I'm with you here), it's likely better to take the opposite approach and create custom child widgets that the parent code can know about, which makes the typing issues much easier to deal with. Take this app of mine for example; in there I use the widgets to hold the state, rather than store a global state in the app (in effect I do store the global state in the app, but via the DOM).