12-13-2007, 01:15 PM
Retired BBF Moderator
Join Date: Aug 2004
Location: Ottawa, Ontario, Canada
Post Thanks: 1
Thanked 0 Times in 0 Posts
richard.puckett is right.
This is a better coding architecture: push the screen; when it closes, have the original class that pushed the screen display the final screen.
This is an okay coding architecture (better than what you do), push the confirm screen then immediately push the loading screen. There will be no time for the confirm screen to repaint itself. Once the loading screen closes, the confirm screen shows. (This doesn't show error messages, etc, but at least it's much more modular and easier to convert to an even better coding architecture)
Other comments about having two screens communicate with each other:
There are many ways of signalling a previous screen of a task completion, such as a callback, a semaphore, etc. Some even passing the screen as a variable to the new screen, so that the new screen can call a function within the original screen. An example is pass the original screen to the loading screen as a "Screen origScreen" parameter, then check that Screen is "if (origScreen instanceof MySpecificScreenClass)" and if it is, then you can safely call your own custom functions in your original MySpecificClass screen, through a construct similiar to ((MySpecificClass) origScreen).myOwnFinishedLoadingFunc( ) .... (you may have to cast to a variable first, before calling the method) It works. Be forewarned of potential caveats of any approach you do, and try to program as generically as possible that your situation allows. It's a very powerful BlackBerry programming trick: It's very tempting to do this trick to do neat things such as modify the textfields of a previous screen while the next screen is still displayed (Not good programming practice, as this is only appropriate to do, if the two screens are intricately related to each other and are never used by itself anywhere else, and that other programming techniques may be more difficult. You'd need a very good reason to do things this way - I prefer doing a callback returning a populated object and let the previous screen populate fields on its own, it's a lot more generic/blackbox this way -- i.e. like a 411 popup lookup screen that populates fields in the previous screen)
Last edited by Mark Rejhon : 12-13-2007 at 01:26 PM.