[pillar]

I'm developing this map application. The user is able to move on the map. If you press right, it will move right so that 50% of your last screen is still showing and 50% is new map. The map data is loaded over-the-air as PNG's received as bytearrays. It is only loading the part that is not known yet, in order to save time/data received.

This is all working nice, except the fact that I would like to cache old parts of the map, in order to make it even more time and data efficient. My problem is that I'm having a hard time to get the concept of image caching down. It would be easy if it would always move 100% and load totally new screen. But when it's only moving 50%, it get's complicated.

Do you guys have any suggestions?

Only thing I have come up with is that if I could somehow divide the image data (bytearray) into 4 squares and in case of movement divide the extra data into two - that way I would have a coordinate system and could just look up in an array, if I already have those coordinates loaded. The problem is that I don't know of a way to divide the image that way. Is this understandable? Any suggestions?

[dcrocha]

What if you get the image, as a byte array, draw it and store in a Hashtable, for example.

Then when you get the second image, or 50% of it, you would draw two images instead of two:

1) The one in the Hashtable, using Graphics.drawImage() overload to draw just a portion of the acquired image.
2) The one you've just received, also using drawImage() to drive just a portion of it.

Or you could receive three or four images at once, as a single byte array, and then split the images using

createImage(byte[] imageData, int imageOffset, int imageLength)

.

Daniel

[peterblazejewicz]

hi pillar,

or save in RMS, use two different RMS: one for storing just-loaded image index (or could be geocoding data, map tile data, etc), second one to save only bytes from that image, and store index as access point ("key" from index RMS+"recordID" from image data RMS) in hashtable,
that way you can easily and fast retrieve textual data from first rms if no image data is currently required and both or only image data from the latter RMS if you need to load "cached" visual data,
You could even implement inteligent algorithm at runtime to decide how many data can be precached in RMS because RMS offers a way to retrieve of current RMS data and available size, and because RMS is faster then on-air download it could be also solution you can think about in your implementation,
RMS-based solution will be slower than in-memory caching Daniel wrote but could improve runtime memory usage,

hth,
regards,
Peter