localStorage på Mobil: Den Ultimative Guide

Har du nogensinde brugt lang tid på at udfylde en online formular, kun for at miste al din indtastning på grund af en utilsigtet genindlæsning eller et tab af internetforbindelse? Det er en frustrerende oplevelse, som mange webudviklere forsøger at afhjælpe ved hjælp af browserens indbyggede lagringsmekanismer. På desktopbrowsere som Chrome og Firefox fungerer localStorage ofte fejlfrit til at gemme midlertidige data, som f.eks. formularindhold, så brugeren kan fortsætte, hvor de slap. Men hvad sker der, når vi flytter over til mobile enheder, især iOS? Mange oplever, at de samme løsninger, der fungerer perfekt på computeren, pludselig svigter på mobilen. Denne artikel vil dykke ned i, hvorfor dette sker, hvordan web storage fungerer på tværs af enheder, hvordan data ryddes, og hvilke alternativer og overvejelser du bør gøre dig for at sikre en robust brugeroplevelse på alle platforme.

Hvad er Web Storage (DOM Storage)?

Før vi adresserer de mobile udfordringer, er det vigtigt at forstå grundlaget for web storage. Web Storage, også kendt som HTML5 Storage eller DOM Storage, er en webstandard, der giver webapplikationer mulighed for at gemme data lokalt i brugerens browser. Den er designet som et mere robust og større alternativ til traditionelle cookies. Der er to hovedtyper af web storage:

• localStorage: Denne type lagring har ingen udløbstid. Data gemt i localStorage forbliver i browseren, selv efter at browseren er lukket og genstartet, og endda efter en genstart af operativsystemet. Data er delt mellem alle faner og vinduer fra samme oprindelse (samme domæne og underdomæner), hvilket gør det ideelt til langvarig lagring af brugerpræferencer, offline-data eller, som i dit tilfælde, backup af formularer.
• sessionStorage: I modsætning til localStorage ryddes data gemt i sessionStorage, når browser-sessionen slutter – det vil sige, når browseren eller den specifikke browserfane lukkes. Data i sessionStorage er også begrænset til den aktuelle browserfane; selv to faner fra samme hjemmeside vil have forskellige sessionStorage-data. Dette gør det velegnet til midlertidig lagring, der kun er relevant for den aktuelle session, f.eks. en indkøbskurv under en enkelt browsing-session.

For at illustrere forskellene kan vi se på denne sammenligningstabel:

Virker localStorage på mobil? Den store udfordring

Det korte svar er: Ja, localStorage er bredt understøttet på mobile browsere, herunder iOS (Safari) og Android (Chrome, Firefox, osv.). Problemet, du oplever med, at det ikke virker på iOS, er sandsynligvis ikke en mangel på understøttelse af API'en i sig selv, men snarere nuancer i, hvordan mobile browsere, især Safari på iOS, håndterer visse JavaScript-begivenheder og lagringspolitikker.

Din kode bruger window.onbeforeunload til at gemme data, når brugeren forlader siden. Dette er en klassisk tilgang, og den fungerer som nævnt godt på desktop. På mobile browsere kan adfærden af onbeforeunload dog være mere uforudsigelig. Mobile operativsystemer og browsere er optimeret til at spare på ressourcer og kan lukke baggrundsfaner eller processer aggressivt. Dette betyder, at onbeforeunload-eventet måske ikke altid udløses pålideligt, især hvis brugeren hurtigt skifter app, lukker browseren fra app-switcher, eller hvis systemet dræber processen for at frigive hukommelse.

Specifikt for iOS og Safari er der historisk set været udfordringer med JavaScript-udførelse under sideaflæsning og med lagringspersistens. Selvom localStorage i princippet er persistent, har Apple indført visse politikker for at beskytte brugerens privatliv og enhedens ydeevne, som kan påvirke lagrede data. For eksempel er der en kendt politik, der sletter IndexedDB-databaser (som er en mere avanceret lagringsmekanisme, vi vil dække senere) efter syv dage med inaktivitet for en given oprindelse i Safari. Mens dette primært gælder for IndexedDB, kan det skabe forvirring og bekymring om localStorage's pålidelighed.

Fejlfinding på iOS

Hvis din localStorage.setItem kode ikke bliver udført på iOS, er det første skridt at bekræfte, at onbeforeunload-eventet faktisk udløses. Du kan prøve at logge en besked til konsollen eller sende en lille netværksanmodning for at se, om funktionen overhovedet kører. Hvis den ikke gør det konsekvent, skal du overveje alternative triggere til at gemme dine formulardata:

• Debounced input-events: Gem data, hver gang en bruger indtaster noget i et felt, men med en forsinkelse (debounce) for at undgå at gemme for ofte. Dette sikrer, at data gemmes løbende, mens brugeren arbejder, og ikke kun ved afslutning.
• Autosave-knap eller periodisk gemning: Implementer en synlig "Gem udkast"-knap eller en automatisk gemningsfunktion, der periodisk gemmer data hvert par minutter.
• Formularindsending: Gem data, umiddelbart før formularen sendes, eller som en del af indsendelsesprocessen.

Husk, at mobilbrowsere kan have forskellige JavaScript-udførelsesbegrænsninger sammenlignet med desktop. Det er afgørende at teste grundigt på tværs af forskellige iOS-versioner og enheder.

Hvornår ryddes localStorage?

Selvom localStorage er designet til at være persistent, er det vigtigt at forstå, at data ikke er uforgængelige. Brugere kan aktivt rydde deres browserdata, hvilket ofte inkluderer localStorage. Dette kan ske utilsigtet, hvis en bruger rydder "alle cookies og andre webstedsdata" uden at være klar over, at det også påvirker localStorage. Her er de typiske måder, localStorage ryddes i populære browsere:

Google Chrome

I Chrome ryddes localStorage, når følgende betingelser er opfyldt:

• Brugeren vælger "Ryd browserdata" (Clear browsing data).
• "Cookies og andre webstedsdata" (Cookies and other site data) er valgt.
• Tidsrammen er indstillet til "Fra begyndelsen af tid" (from beginning of time).

Det er også muligt at slette localStorage for et specifikt websted direkte fra Chromes udviklerværktøjer under fanen "Application" -> "Local Storage".

Mozilla Firefox

I Firefox ryddes localStorage, når disse tre betingelser er opfyldt:

• Brugeren rydder "Nyere historik" (Clear recent history).
• "Cookies" er valgt til at blive ryddet.
• Tidsintervallet er "Alt" (Everything).

Ligesom Chrome kan localStorage også ryddes, hvis den samlede lagerkapacitet for localStorage er fuld, hvilket udløser en oprydningsproces baseret på en Least Recently Used (LRU) politik.

Internet Explorer (IE)

For at rydde localStorage i Internet Explorer:

1. Gå til "Funktioner" (Tools) -> "Internetindstillinger" (Internet Options).
2. Vælg fanen "Generelt" (General).
3. Under "Browserdata" (Browsing history) skal du markere "Slet browserdata ved afslutning" (Delete browsing history on exit).
4. Sørg for, at "Cookies og webstedsdata" (Cookies and website data) eller "Midlertidige internetfiler og webstedsfiler" er valgt.
5. Overvej at fravælge "Bevar favoritwebstedsdata" (Preserve Favorites website data) øverst.

Safari

I Safari ryddes localStorage via:

1. Klik på "Safari" i menulinjen.
2. Vælg "Indstillinger" (Preferences).
3. Gå til fanen "Anonymitet" (Privacy).
4. Klik på "Administrer webstedsdata..." (Manage Website Data...) og derefter "Fjern alle webstedsdata" (Remove all webstedsdata) eller fjern specifikke domæner.

Opera

Selvom Opera har fremragende dokumentation om localStorage, er der ingen lige så klare, ikke-programmatiske instruktioner til brugere om, hvordan man rydder localStorage som for de andre browsere. Typisk vil det dog være under browserens privatlivsindstillinger, hvor man rydder "cookies og andre webstedsdata".

Begrænsninger og alternativer til localStorage

Selvom localStorage er praktisk, har det sine begrænsninger, især når det kommer til datamængde og persistens på visse platforme. Disse begrænsninger kan gøre det mindre ideelt for store eller kritiske data.

Størrelsesbegrænsninger

Den samlede localStorage-kapacitet er (teoretisk) begrænset til 50% af den ledige diskplads. Dog er den maksimale lagerplads for en enkelt "oprindelse" (dvs. et domæne og dets underdomæner) mere relevant i praksis. De typiske grænser for en enkelt oprindelse er:

• Minimum: 10 MB
• Maksimum: 2 GB (ifølge MDN's opdaterede tal, oktober 2022)
• Faktisk observeret: Ofte omkring 5 MB på mange systemer, uanset den ledige diskplads. Dette kan variere betydeligt mellem browsere og enheder.

Når den samlede localStorage-kapacitet er fuld, vil browseren begynde at rydde data baseret på en "origin eviction"-politik. Dette betyder, at den "mindst nyligt brugte" (Least Recently Used – LRU) oprindelse vil blive slettet fuldstændigt, indtil browseren igen er under grænsen. Det er vigtigt at bemærke, at denne sletning er "alt eller intet" – der er ingen delvis sletning af data fra en oprindelse, da delvise data kan være værre end ingen data.

IndexedDB: Et mere robust alternativ

For større og mere komplekse datastrukturer er IndexedDB API'en et langt mere kraftfuldt og passende alternativ. IndexedDB er en lav-niveau API til klient-side lagring af betydelige mængder struktureret data, herunder filer/blobs. Det fungerer som en transaktionel database i browseren.

• Kapacitet:IndexedDB kan gemme op til 80% af den tilgængelige diskplads, hvoraf 75% kan bruges af et enkelt domæne. Dette er betydeligt mere end localStorage.
• Persistens:IndexedDB er generelt meget mere persistent end localStorage. Data forbliver typisk i browseren i meget lang tid, medmindre brugeren aktivt rydder det, eller browseren (som Safari) har specifikke politikker.
• Safari's 7-dages regel: En væsentlig undtagelse for persistensen er Safari-browseren på iOS og macOS, som automatisk sletter IndexedDB-databaser syv dage efter sidste brug. Dette er en aggressiv politik designet til at beskytte brugerens privatliv og forhindre sporing, men det har store konsekvenser for webapplikationer, der er afhængige af langvarig offline-lagring.
• Kompleksitet:IndexedDB er mere kompleks at arbejde med end localStorage, da det er en asynkron API, der kræver mere boilerplate-kode. For at forenkle brugen kan man benytte wrappers som Dexie.js eller idb, der giver en mere brugervenlig grænseflade.

Mens localStorage er synkron og nem at bruge for simple nøgle-værdi-par, kan det blokere hovedtråden, hvis du forsøger at gemme store mængder data, hvilket kan føre til en "frysning" af brugergrænsefladen. IndexedDB er asynkron, hvilket betyder, at den ikke blokerer brugergrænsefladen under læse- eller skriveoperationer.

Er localStorage det rette valg til din brugssag?

Du spørger, om du kan stole på localStorage API'en til at cache dynamiske formularfelter i din Angular/Firebase app på Android/iOS-enheder for at rehydrere UI'en efter en sidegenindlæsning eller netværksproblemer. Baseret på ovenstående information er svaret nuanceret:

Fordele ved localStorage til formular-backup:

• Simpel at implementere: For mindre, ikke-kritiske formularer er localStorage utrolig let at implementere og kræver minimal kode.
• Øjeblikkelig genoprettelse: Data er umiddelbart tilgængelige for at genoprette UI'en, hvilket giver en hurtig og glidende brugeroplevelse.
• Offline-kapacitet: Data forbliver tilgængelige, selvom brugeren mister internetforbindelsen.

Ulemper og overvejelser for mobil (især iOS):

• Uforudsigelig persistens: Selvom localStorage teknisk set ikke slettes efter 7 dage som IndexedDB i Safari, kan andre faktorer (som aggressiv hukommelseshåndtering, manuelle rydninger af browserdata eller uforudsigelig adfærd af onbeforeunload) føre til datatab.
• Størrelsesbegrænsninger: Hvis din dynamiske formular kan blive meget stor med mange felter eller indlejrede data, kan du hurtigt ramme localStorage's begrænsninger.
• Sikkerhed:localStorage er ikke krypteret og bør aldrig bruges til at gemme følsomme brugerdata (f.eks. adgangskoder, kreditkortoplysninger).
• Synkron natur: Storing af meget store strenge synkront kan potentielt blokere UI'en midlertidigt.

For en kritisk brugssag, hvor tab af indtastede data er "frustrerende for brugere", og hvor din app primært bruges på mobil, bør du overveje en mere robust strategi. IndexedDB er en stærkere kandidat, selv med Safari's 7-dages regel, da den kan håndtere større datamængder og er asynkron. For at omgå Safari-reglen kan du overveje at "røre" databasen regelmæssigt for at nulstille 7-dages tælleren, selvom dette kan være besværligt. En anden og ofte sikrere løsning er at implementere en server-side autosave-funktion, hvor data gemmes i din Firebase-database, hver gang brugeren foretager en ændring. Dette giver den højeste grad af datapersistens og pålidelighed, uafhængigt af browserens lagringspolitikker.

Hvis du vælger at fortsætte med localStorage, skal du teste meget grundigt på tværs af forskellige mobile enheder og browserversioner. Overvej at bruge en kombination af strategier: localStorage som en hurtig og øjeblikkelig backup for de fleste genindlæsninger, men med en server-side backup som den primære "sandhedskilde" for at forhindre alvorligt datatab.

Ofte Stillede Spørgsmål (FAQ)

Hvad er forskellen mellem localStorage og sessionStorage?

localStorage gemmer data permanent uden udløbstid (medmindre brugeren rydder det manuelt), og data er tilgængelige på tværs af alle faner og vinduer fra samme oprindelse. sessionStorage gemmer data kun for den aktuelle browser-session (indtil fanen eller browseren lukkes), og data er begrænset til den specifikke fane.

Hvorfor virker localStorage ikke på min iPhone?

Selvom localStorage understøttes på iPhone (iOS/Safari), kan problemer opstå på grund af Safari's aggressive ressourcestyring, som kan påvirke pålideligheden af onbeforeunload-eventet, eller fordi brugeren manuelt rydder browserdata. Der er også en potentiel forvirring med Safari's 7-dages sletningspolitik for IndexedDB, selvom den ikke direkte gælder for localStorage på samme måde. Overvej at gemme data på andre tidspunkter end kun ved onbeforeunload.

Hvor meget data kan jeg gemme i localStorage?

Typisk kan du gemme omkring 5-10 MB data per oprindelse (domæne). Selvom de teoretiske grænser kan være op til 2 GB, er 5 MB ofte den praktiske grænse, man støder på. Hvis du har brug for at gemme større mængder data, bør du overveje IndexedDB.

Er localStorage sikkert til følsomme data?

Nej, localStorage er ikke sikkert til følsomme data som adgangskoder eller kreditkortoplysninger. Data gemmes som klartekst og kan tilgås via JavaScript på den samme oprindelse. Hvis din applikation udsættes for et Cross-Site Scripting (XSS) angreb, kan angribere nemt få adgang til alle data i localStorage. Følsomme data bør altid håndteres og gemmes på serversiden, og kun tilgås via sikre, autentificerede API-kald.

Hvornår skal jeg bruge IndexedDB i stedet for localStorage?

Du bør overveje IndexedDB, når du har brug for at gemme store mængder struktureret data, når du har brug for at udføre komplekse forespørgsler på data, eller når du har brug for asynkron lagring for at undgå at blokere brugergrænsefladen. Det er ideelt til offline-first applikationer, caching af store datasæt eller som en mere robust erstatning for localStorage til kritiske data, især hvis du kan leve med Safari's 7-dages regel eller implementere en workaround.

Hvis du vil læse andre artikler, der ligner localStorage på Mobil: Den Ultimative Guide, kan du besøge kategorien Teknologi.