2007:02 - Karlstads universitet

sekunder att skapa.
Enkelhet - användare D˚a det tar tid att skapa records s˚a kommer det ocks˚a ta tid
att överföra en katalog till den mobila enheten. Detta ställer visserligen inga tekniska krav
p˚a användaren men m˚aste änd˚a beaktas d˚a alla väntetider bör minimeras. Det f˚ar anses
orimligt att anta att användaren accepterar en flera timmar l˚ang installationsprocedur.
Minne - allokering (jmf. RAM) En RecordStore kräver lite overhead vad gäller min-
nesallokering. Det som tar plats är objektet RecordStore vilket är tillräckligt litet för
att kunna allokeras i samtliga J2ME-kompatibla enheter. (Detta p˚ast˚aende stöds av att
RecordStore är en del av J2ME som m˚aste finnas implementerat.)
Minne - varaktigt (jmf. HDD) Förutom de data som sparas i varje record s˚a h˚aller
systemet ocks˚a internt en identifikator för varje record samt en header för varje Record-
Store. Dessutom kan det finnas ytterligare implementationsberoende information som sys-
temet sparar för att exempelvis kunna synkronisera data [7]. Ett enkelt test genomfördes p˚a
Sony-Ericsson W800i för att fastställa exakt hur mycket overhead denna lösning innebär
(observera att detta är implementationsberoende och därför bara ger en fingervisning).
Metoden getSize() returnerar, i bytes, hur stort utrymme en given RecordStore har tagit
i anspr˚ak, inklusive samtliga overheads [7]. För att ta reda p˚a hur mycket overhead varje
RecordStore kräver skapades en s˚adan utan records. getSize() returnerade d˚a 48 vilket
allts˚a innebär en overhead p˚a 48 byte för varje RecordStore. Därefter lades en record till
i RecordStore:n vilket gav värdet 80 byte. I denna record placerades en byte data vilket
allts˚a innebär en overhead p˚a 31 byte (80 − 48 − 1 = 31). För att vara säkra p˚a att den
första record:en i en RecordStore inte kräver extra overhead skapades ytterligare en, med
samma resultat - 31 byte overhead.
15