Obecnie mam aplikację mapową offline HTML5 (zbudowaną na Leaflet i KendoUI z niestandardowymi dodatkami), która ma manifest aplikacji i działa dobrze na wielu platformach. Jednak waham się przed użyciem manifestu do przechowywania w ten sposób rzeczywistych kafelków mapy (pliki PNG przechowywane jako pamięć podręczna kafelków w stylu TMS).
Zagadnienia:
- W około 1000 plików PNG może być dużo kafelków (10 MB - 50 MB)
- Pierwsze pobieranie może być bardzo powolne (i trudne do pokazania postępowi użytkownikowi)
- Manifesty aplikacji działają lub nie działają, jeśli nie zawiodą całego buforowania offline (zgodnie z [whatwg.org] [1])
- Użytkownik offline czasami łączy się ponownie i musi uzyskać odświeżenie kafelków. Są to małe delty, ale mechanizm manifestu aplikacji przeładuje wszystkie pliki js, css i PNG, gdy tylko aktualizacje manifestu
Alternatywny pomysł: oddziel aplikację internetową od przechowywania śliskich kafelków mapy. Przechowuj kafelki w bazie danych przyjaznej dla aplikacji internetowych
Aktualizacja:
[PouchDB ostatnio dodał obsługę binarnych obiektów blob. Otrzymuję dobre wstępne wyniki. Zobacz: /programming/16721312/using-pouchdb-as-an-offline-raster-map-cache ]
- Sugeruje to Ben Nolan http://bennolan.com/2011/06/03/offline-mapping.html
- Podobna praca nad Mapami na patyku: http://developmentseed.org/blog/2010/oct/02/maps-stick-version-2-released/ ([przestarzałe] [2])
- MBtiles http://mapbox.com/developers/mbtiles/
- TileStream https://github.com/mapbox/tilestream
- Lous Remi: http://louisremi.com/2011/10/07/offline-web-applications-were-not-there-yet/
Pytanie: Co kolektywna mądrość (i doświadczenie) mówi o następujących wyborach bazy danych przyjaznej JavaScript:
- SqlLite
- Wygląda na to, że musisz w tym celu utworzyć natywną aplikację, aby móc rozmawiać z JavaScript
- Np. Dodaj bibliotekę DLL do rodzimego programu dla Windows i PhoneGap dla Androida / IOS
- WebSQL
- osłabiony
- ale był to SQL Lite, który mogłem łatwo generować i dystrybuować z hosta serwera WWW
IndexDB
- Przechowywanie obiektów blob wydaje się działać, patrz: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
- Jestem zaniepokojony, czy jest to jedyny sposób, aby początkowo wypełnić DB
- Czy to w zasadzie plik SQLLite? Czy mogę wysłać go do masowego przesyłania bazy danych?
- Skłaniam się ku temu jako rozwiązaniu. Czy to ich mamki, o których nie wiem?
Wymagania:
- Szybka początkowa populacja (poprzez pobranie) do klienta Web DB
- Kompatybilny z obecnym API Leaflet TileLayer (tzn. Wolałbym nie pisać niestandardowej warstwy, ale w razie potrzeby ...) (np. MbTiles)
- Platforma: Laptopy z systemem Windows, ale pożądane są tablety z Androidem i IOS (mogę poczekać na wydanie IndexDB, nie potrzebuję natychmiastowej pomocy)
- Wolałbym nie pisać aplikacji natywnej (EXE, IOS, Android), ale jeśli to najlepszy sposób ...
- Generowanie map internetowych po stronie serwera (będzie to proces automatyczny). Użytkownik wybiera lokalizację, wybiera mapy, a następnie dynamicznie przekształca się i zamienia w śliską pamięć podręczną kafelków (ta praca jest już w dużej mierze wykonana).
- Szybkie początkowe pobieranie zbiorcze
- Odświeżanie delty zmiany mapy (napiszę tę logikę na podstawie stałych numerów akcji i aktualizacji daty)
- Minimalny wpływ na bieżącą aplikację internetową Ulotka i KendoUI
Aktualizacja:
Kluczowy pomysł w tle: podczas gdy aplikacja internetowa jest dość stabilna, śliskie kafelki mapy są generowane w locie dla Twojej lokalizacji i rodzaju problemu, który robisz (na zapleczu). Pomyślałem więc o dwóch innych sposobach przeniesienia początkowego „wielkiego wybuchu”, a następnie aktualizacji:
Plik zip (prawdopodobnie nie jest to dobry pomysł - ponieważ dodaje obciążenie serwera) również rozbudowa na komputerze klienckim będzie wymagała interakcji użytkownika, ale pozwala śliskim kafelkom używać lokalnych adresów URL
Interfejs API plików HTML5: Nie przyjrzałem się temu szczegółowo. Ale wygląda na to, że ma większość operacji tworzenia lokalnego drzewa plików w formacie TMS: http://www.html5rocks.com/en/tutorials/file/filesystem/ to, co będzie interesujące do przetestowania, to wydajność (np. Czy mogę korzystać z stron internetowych aby zmaksymalizować przepustowość dysku i sieci). IndexDB nie jest powszechnie wdrażany jako przyjazny dla pracownika sieci (interfejs synchronizacji: /programming/10698728/indexeddb-in-web-worker-on-firefox
Znalazłem dodatkowe informacje na temat korzystania z IndexDB z Ulotką:
https://github.com/calvinmetcalf/leaflet.pouch (synchronizuje couchdb z indexdb w trybie offline) Również tutaj są niektóre testy prędkości odczytu / zapisu dla indexdb, websql i lokalnego sklepu: http://jsperf.com/indexeddb -vs-localstorage / 15
A oto jak korzystać z interfejsu API pliku do odczytu / zapisu z javascript: (a także z prośbą o zwiększenie limitów pamięci) http://www.html5rocks.com/en/tutorials/file/filesystem/
Dziękuję, Tom MacWright (aka tmcw), za dobre opinie. Twój przykład naprawdę pomoże, gdy będę mógł tworzyć niestandardowe warstwy do przyjmowania binarnych obiektów blob.
Wczoraj przeprowadziłem kilka testów z IndexedDB i używając niektórych wielopełniaczy i bibliotek myślę, że rozwiąże to moje problemy. Teraz nadszedł czas, aby włożyć w to trochę potu, a ja zdam raport.
BTW: jeśli chcesz zobaczyć moje wyniki moich badań w bazach danych po stronie klienta, zobacz:
/programming/14113278/storing-image-data-for-offline-web-application-client-side-storage-database