J2ME: Problem med for stor JAR fil - komprimering af tekst

"If size is a constraint: use SDK classes wherever possible; inherit whatever possible; put common code in one place; initialize big arrays at runtime by parsing a string; use short names; "

og har du kørt en obfuscator på dine klasser inden de blev pakket.
http://proguard.sourceforge.net/

Ja, jeg har kørt en obfuscator, jeg bygger både via Netbeans og via antenna for at kunne sammenligne størrelser.

Jeg initialiserer netop 'big arrays at runtime by parsing a string', men jeg har lagt dem ud i underklasser fordi jeg ellers for een stor klasse der ikke kan loades.

så skal du nok implementere din egen komprimerings algoritme.. desværre ikke noget jeg har kendskab til men det burde være muligt at gøre det... skal løbe nu men måske google har nogen svar på det.

Jeg tror ikke at jeg kan lave komprimering bedre end den, der allerede sker. Jar-filen bliver jo allerede komprimeret. Har ihvertfald ikke fundet noget på Google...

Jeg tænker mere på om jeg skal prøve lægge teksterne i en ekstern fil, som jeg så kan læse fra via et indeks, der fortæller hvor den enkelte streng starter.

Er der ingen erfaringer med noget lignende derude?

desværre.
nu siger du det kun må være 64kb er det telefonen der sætter den restriktion eller er det fordi det er best practice ikke at lave dem for store?
jeg kan ikke huske det.. men hvis en application må optage 64kb er det så alt den plads der overhovedet er til rådighed incl rms. for hvis der er mere plads i rms ville jeg indlæse det fra en url og gemme i rms efter programmet er lagt ind.

Hmmm - du kunne smide dem ned i Jad-filen:

Streng_1 = "lang tekst1"
Streng_2 = "lang tekst2"

osv.

Og så initialisere dit array ved start af midlet ..

(uprøvet!)

brilleaben: Ideen er god, men der er to problemer...

1. At lægge teksterne som streng1, streng2, ... tager mere plads end at lægge een lang streng som man ved initialisering bryder op i kortere strenge.
2. Jeg har mange sæt af tekster. De skal ikke bruges samtidigt og det ville ikke kunne lade sig gøre at lægge dem alle i een klasse uden løbe tør for memory. Jeg bliver derfor nødt til at lægge dem i flere klasser. Hver ny klasse fylder.

Derfor er det bedre at lægge alle teksterne i en ekstern fil. Jeg har så et array over hvor de enkelte sæt af strenge starter, så jeg hurtigt kan load dem.

Njaa - så skal du jo have dem komprimeret.  Hvis det er tekststrenge, er Huffman encoding vel det nemmeste at have med at gøre?

brilleaben: Når projektet laver jar-filen komprimeres resource-filerne også. Jeg tror ikke at jeg kan gøre det bedre end det.

Så svaret på det oprindelige spørgsmål er, foreløbigt: Man kan spare plads ved at lægge resource-teksterne i een fil, der så kan komprimeres sammen med resten af jar-filen. Dette kræver en ekstra datastruktur med oplysninger om hvor de enkelte sæt af resourcer ligger i resource-filen.

Og: Man kan ikke omgå problemet med for stor jar-fil ved at lade brugeren downloade og gemme resource-teksterne i recordstore fordi recordstor kun garanteres at have 8KB plads.

Hvis I vil have point må I lægge et svar.

ok svar.