RE: [Gamedevlists-brew] porting a database file from BREW to J2ME

[Aaron I. <ais...@ap...>]

Thank you Tom P and Tom H for your insights.

I imagine that I can speed up the seek process by breaking up the database
into several smaller chunks, each stored as a separate file in the jar (but
not too small, as Tom H points out).  In addition, I had already planning on
reworking the record search algorithm so it didn't have to do any reverse
seeks, which I could tell would be inefficient from the stream API.

Given that some phones decompress the application at install time, as Tom P
explains, it seems that I can't rely on the zip compression in the jar file
alone.  

Is there sneaky way to use the built-in zip decompressor that is required
for decompressing the jar and png files?  I was thinking of putting the data
in a fake PNG 24-bit image, but I don't see a way to read it.  It would be a
shame to have to bring along a ZIP decompressor in my jar, just because they
didn't expose it in the MIDP API.

-Aaron

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Tom Park
> Sent: Saturday, December 11, 2004 5:32 PM
> To: gam...@li...
> Subject: Re: [Gamedevlists-brew] porting a database file from 
> BREW to J2ME
> 
> > > 1) Has anyone noticed a phone that completely 
> decompresses the JAR, 
> > > including non-class files, into memory when the app is 
> first loaded?  
> > > That is, do all known J2ME phones keep the resources compressed 
> > > until requested?
> > 
> > Yes. A file is only loaded into memory when you open it. To be even 
> > more
> [...]
> > It might be interesting to just store the file in the jar, and not 
> > deflate it. Maybe it would allow you do seek with good 
> performance and 
> > without
> 
> No, I'm assuming that Aaron is already asking whether it's 
> okay to leave the file decompressed in the JAR, because he's 
> worried that if the phone decompressed the JAR then it'd be too big.
> 
> Nextel iDEN phones definitely decompress the JAR upon install.
> Install is a different step from download. The classes go 
> into a program space, and resources go into a data space. 
> There are iDEN-specific JAD properties for the decompressed 
> size, e.g.:
> 
>    iDEN-Data-Space-Requirement: 112
>    iDEN-Program-Space-Requirement: 157
> 
> where the values are in KB.
> 
> Offhand, I don't know of other phones that decompress the 
> JAR, but I wouldn't assume Motorola is not or will not be the 
> only one to use this optimization for J2ME performance.
> --t
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide Read honest & 
> candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Gamedevlists-brew mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-brew
>