01-09-2009 04:34 PM
I am using JDE 184.108.40.206 and Simulator 8300
I have over 7 screens in my application that the user will navigate to and from as they complete their work. Right now I am creating a new screen each time they navigate to it. This of course is placing multiple versions of the same screen into the list of screens where they are pushed.
What is the best way to handle this situation? Is there a way to determine if a screen already exists in the list and if so, find it and use it rather than creating a new one eash time?
If there is not a way to do this what would the best way to be from a memory and processing stand point?
If so pointing me to some examples would be helpful as I am new to this.
Solved! Go to Solution.
01-09-2009 04:51 PM
Check this link:
And look at this link: Blackberry Developer Guide & Other documentation
There is helpful information to resolve your issue.
01-09-2009 09:45 PM
Regardless of the memory/processing used, your first consideration must be what the user wants/expects.
To make this easy, I'm going to call your screens Screen1, Screen2, Screen3, ... Screen7.
Typically screens are used in a hierarchical way, so you go from one to the other and escape back, so you will go from Screen1 to Screen2, then Screen3, but never from Screen3 to Screen1. In this case, it is quite reasonable for you to create a new Screen2 in Screen1, then push it, and when you escapes from Screen 2 (by popping it), the resources used by Screen2 will all be freed and Screen1 will magically appear because it was next on the Display Stack.
However if your User can go from Screen1 to Screen2, then Screen3,, then onto Screen1, and so on, creating a new Screen every time will result in a lot of screens. With this method, the user can escape quite happily back to where they started, which might be what they have to do.
If however the user expects to go from Screen1 to Screen2, then to Screen3 then to Screen1 at which point the values from the original Screen1 should be there, then creating new Screens each time is not going to work. In this situation, you could save all the screens, and perform the screen changes by popping the current screen and pushing the new screen at the same time, effectively swapping the screens on the top of the Display Stack. But if you do this, you loose the ability to go 'Back'.
Ok, on to your specific questions:
"Is there a way to determine if a screen already exists in the list"
Yes - Screen.isDisplayed() will tell you that. I'm not sure how useful it is because it could be buried in the Display Stack and you might have to pop a number of screens to get it back. You can't have the same screen in two places on the Display Stack. I've not tried popping a screen that was not on the top of the Stack, that might work and if it did, you would then be able to push the Screen again, effectively moving it to the top of the Display Stack. Note that it would loose its place when the user backed down the Screens.
"what would the best way to be from a memory and processing stand point"
I would make sure the structure does what the user wants, then try to make it more efficient. That said, the best thing is to create the screens only once and destroy them when the app is closed. You can do this in a number of ways, one way I use is to have a Screen manager, and just ask it for the Screen you wanted - the Screen manager will create it and retain it if one is not already created.
Hope this helps.
01-10-2009 02:00 PM
01-12-2009 03:04 AM
03-11-2010 11:48 AM - edited 03-11-2010 11:50 AM
If all screen are custom classes, what do you guys think of making them singletons, and regularly popping screens when pushing new ones? I'm am trying this approach out with success so far, but would be curious to hear any comments, particularly how this works with the framework at a lower level. Is it generally better to keep the screen stack small? This makes the 'Back' button useless, of course, but my application's workflow doesn't call for it.
Also, with regard to Peter's comment about destroying screens when the application closes - is this not handled by the framework/garbage collection?
03-11-2010 01:23 PM
My understanding of the underlying framework would suggest that having a large screen stack impacts the memory usage on the device, but little else. But that is really just an educated(?) guess. As I said in the post above, I think about how the user will interact before I worry about the resource usage.
With regard to my comment about destroying screens, you are correct that they will normally all be removed by garbage collection when the application terminates.
11-01-2011 02:49 PM
Hello Simon, I am developing a BB project kind of in an isolated mode, so forums are the only source from which I am learning and implementing stuff. Can you suggest me some links or some example that has a uicontroller?
I tried creating one, but it is no close for production standard.