Question

Hi I have two screens which I never wanna pop because they load data from the web and I don’t wanna load it all the time. However if I try to navigate from one to another I get a RuntimeException saying that I tried to push a screen that was already displayed. Is there a work around to pushScreen? Something like change screen?

Answer 1

You could certainly do what Rupak and Richard are suggesting. But, let me offer another option, that might require less redesign from what you currently have.

It sounds like you’re doing some expensive operation when a Screen is instantiated, right? And you want to avoid doing that multiple times?

Are you pushing your screens like this:

UiApplication.getUiApplication().pushScreen(new FooScreen());

UiApplication.getUiApplication().pushScreen(new BarScreen());

Instead, make sure wherever you push screens saves the screen, to be reused later (at least for these two screens you think should not be popped). I usually have something like a ScreenController class to handle this. So, you could do this:

if (_fooScreen == null) {
    _fooScreen = new FooScreen();
}
UiApplication.getUiApplication().pushScreen(_fooScreen);

…

UiApplication.getUiApplication().pushScreen(_barScreen);
UiApplication.getUiApplication().popScreen(_fooScreen);  // popped but still referenced

…

UiApplication.getUiApplication().pushScreen(_fooScreen); // pushed, but not recreated

You’re not recreating the screen every time you want to push it, or destroying its state when you pop it.

If this really isn’t what you want, and you’re convinced that your two screens should really never be popped, then maybe they shouldn’t be Screens at all. Maybe they should be Manager subclasses.

Maybe you only have one Screen (not two), which logically manages the content of both of what you originally had as two separate screens. So, to toggle between them, you would simply have the single Screen do this:

add(_fooManager);
remove(_barManager);

or

replace(_barManager, _fooManager);   // logically similar to "changing" screens

Screens fundamentally are built to use push and pop semantics. If that doesn’t work for you, just use Manager subclasses. Since Screen extends Manager, that should involve minimal code changes to refactor this way.

You do lose some of the nice transition features for switching screens. However, since I had to write BlackBerry code before those were available, I already learned to rely on alternative techniques, such as this one for animating the switching of Fields

Fully separating the View layer, from a Controller layer, is often the way to go. However, especially for BlackBerry apps, I do believe that there are some times when adhering too strictly to an MVC architecture just increases code bloat and maintenance, and isn’t really necessary to solve problems like you describe.

Anyway, just a thought.