01-22-2009 10:43 AM
How I can get a Screen was instaced, can I get it?, I've a list of results and if you clicK in a especific record this do a specific request and open a new screen, if you go back return to the result list.
I mean that can i have a "Vector" of screens or stored the screens?, only instance one time and store this in array o vector and when you will need the screen get it from array.
01-22-2009 10:49 AM
01-22-2009 11:03 AM
Thanks and excuse my English language, but each screen request information from the server and i would
like make a request only once, so i need get a screen has already been instantiated and show it to user
and no repeat the same request all the time.
01-22-2009 02:44 PM
I suggest you review the following Threads:
There are many possible ways of doing what you are trying to do. To help make this discussion easier to follow, let us focus on just one way and explain the issues with it.
You can keep a Vector of all the Screens you have created, and then choose to display one of these rather than recreate it.
However there is a potential problem. The usual way of going from one screen to another on the Blackberry is to PUSH the new screen on to the Display stack, so that it covers up the preceding screen. Then, when the user has finished with a screen, you POP that screen off the stack, exposing the one below.
But screens can only appear once on the Display Stack. So say, you get Screen A from the Server and display it. Then you get Screen B and display it. Then the user asks for Screen C, so you get it as well. Now, if you have used standard BB processing you will have A, B and C on the Display Stack. But now the user wants Screen A again. You can't just push your saved Screen A, because it is already on the Display Stack.
So if you want to do this, then you should pop the current screen and push the replacement screen, at the same time, so you don't have a hierarchy of screens. But this makes it difficult for the user to go 'Back' (like you can in a Browser for example).
The other problem is the overhead of keeping all the Screens in memory.
Instead of doing this, you could retain the details that the Server has sent you, from which you create the Screen. Then you don't have to get the details again from the Server (which is going to take a long time), instead you can just recreate the screen.
Hope this is clear.
01-22-2009 10:15 PM
"Instead of doing this, you could retain the details that the Server has sent you, from which you create the Screen. Then you don't have to get the details again from the Server (which is going to take a long time), instead you can just recreate the screen."
"retain the details that the Server has sent you" --- > Data Vector -->Vector 1
Lot of thanks peter but i would comment that I need to store in a vector1 : text and images extracted from server . It is posible? -- (overhead of memory) --
How much images (.gif) can I allocate in this vector1?, what do you suggest? or is preferable only store text in the vector1?
And another point .. this vector1 will grow because will store another vector2 that is a conversation thread -- dinamically generated for the user (lot of messages [300 characters per message]) --
what do you suggest?, what is the most effective?
1.- request to server data (text and images) every time user need the screen
2.- get data (text and images) only once and store it in a vector1 and allow this grow with the vector2 (conversation thread) and images?
01-23-2009 04:00 AM
01-23-2009 05:46 AM
Simon's comments are absolutely spot on. Thanks Simon.
Just to add, you can do some rough calculations to determine the space that is required by the data you are passing round. These are just rough and based on my observations, not on any actual RIM published data:
a) For a String of text, which is an Object, you need to double the number of characters and then add 100 for the Object reference, and that will let you know how many bytes of storage each String will take. So a String with 300 characters needs about 700 bytes.
b) For the image, you can store the bytes of data that are sent down from the Server. If you do it this way, then you know the Server size in bytes, so add 100 bytes for the Object reference overhead.
Finally to confirm Simon's comment, that "retrieving pictures is even more valuable", consider the following. In some testing I did on GPRS, sending a picture took about 1 second for each 1K bytes, so is slow. In addition it uses up the battery (network traffic does this).