Opracowanie rozwiązania pamięci offline HTML5 dla iOS/Android w 2011

Problem:

Potrzebuję rozwiązania agnostycznego (np. HTML5) do przechowywania i odpytywania ponad 250 000 wierszy danych w trybie offline na urządzeniu typu telefon lub tablet (np. iOS/Android). Chodzi o to, że mam ludzi pracujących w Odległych obszarach bez połączenia danych komórkowych i muszą uruchamiać zapytania na tych danych i edytować je w trybie offline. Częściowo będzie to oparte na geolokalizacji, więc jeśli są aktywa w obszarze, w którym się znajdują (wykorzystuje GPS), to pokaże te aktywa i pozwoli im być edycja. Po powrocie do biura mogą zsynchronizować dane z powrotem do serwera biurowego.

Powodem, dla którego podchodzę do tego ze standardowego punktu widzenia sieci, jest w zasadzie oszczędność pieniędzy i czasu, pisząc go raz w HTML5, a następnie działa na wielu platformach, a nie dwa razy w Objective C i Java. Też jak napiszesz coś co jest agnostyczne to nie jesteś zablokowany i nie idź na dno ze statkiem jak wszyscy się przeniosą na nowszy. Mieliśmy podobny aplikacja napisana dla Windows Mobile 5, Teraz jest bezużyteczna, ponieważ ta platforma jest martwa.

Baza danych offline na urządzeniu musi być:

  • szybko (Odpowiedzi poniżej 2 sekund)
  • potencjalnie wykonywać połączenia i mieć relacje z innymi tabelami zdolnymi do odpytywania bazy danych
  • wybierz dane w określonym zakresie lub kryteriach, np. przez współrzędne x i y na podstawie odczytu GPS.

Opcje:

HTML5 local przechowywanie:

Dobrze dla małych ilości danych

wady:

  • dla ponad 10 000 wierszy nawet na wysokiej klasy maszynie przeglądarka będzie powoli do czołgu.
  • nie można wykonywać złożonych zapytań dotyczących danych, aby wyciągnąć dane, które chcesz, ponieważ musisz iterować przez cały magazyn i ręcznie go wyszukać.
  • ograniczenia dotyczące ilości pamięci, która może być przechowywane

Web SQL Database:

  • spełnia wymagania.
  • Szybkie uruchamianie zapytania na 250 000 wierszy (1-2secs)
  • może tworzyć złożone zapytania, łącza itp
  • obsługiwane przez Safari, Androida i operę, więc będzie działać na urządzeniach z systemem iOS i Android

wady:

  • Deprecated on November 2010
  • wada bezpieczeństwa przy atakach między katalogami. Nie jest to problem, ponieważ nie będziemy na wspólnej hosting

IndexedDB:

Przechowuje obiekt klucza/wartości podobny do przechowalni lokalnej, z wyjątkiem indeksów.

wady:

  • powolne uruchamianie zapytania na 200 000 wierszy (15-18secs)
  • nie można uruchamiać złożonych zapytań
  • nie można łączyć z innymi tabelami
  • nieobsługiwane przez główne telefony lub tablety, np. iPad/Android
  • Standard niekompletny

To pozostawia jedyną opcję wdrożenie przestarzałej metody Web SQL, która może działać tylko przez kolejny rok lub dłużej. IndexedDB i local storage są obecnie bezużyteczne.

Nie jestem pewien, jak Mozilla i Microsoft dostali standard bazy danych Web SQL przestarzały i dlaczego W3C na to pozwolił. Podobno między nimi mają 77% rynku przeglądarek desktopowych. Na zaawansowanych urządzeniach mobilnych Mozilla i Microsoft mają prawie zerowy wpływ, ponieważ [95]}Safari, Opera i Android mają ponad 90% udziału w rynku [96]. Jak Mozilla & Microsoft może dyktować, który standard powinien być używany na rynku mobilnym, czyli tam, gdzie najczęściej używana jest pamięć offline, nie ma sensu.

W komentarze Mozilli o tym, dlaczego chcieli iść z IndexedDB zamiast są głównie O "estetyce dewelopera" i nie podoba im się pomysł uruchomienia SQL w JavaScript. Nie kupuję tego.

  1. Obecnie proponowany standard jest gorszy i niezwykle podstawową implementacją NoSQL, która jest powolny i nie obsługuje nawet zaawansowanych funkcji, których ludzie potrzebują w bazie danych. Istnieje wiele kodu boilerplate, aby utworzyć bazę danych i uzyskać dane, ale twierdzą, że ludzie napiszą kilka ładnych bibliotek abstrakcyjnych nad nią, które zapewnią bardziej zaawansowane funkcje. Od października 2011 nie ma ich nigdzie.

  2. Wycofali istniejący standard Web SQL, który faktycznie działa i jest zaimplementowany w głównych przeglądarkach mobilnych / tabletów. Natomiast ich "nowe" i "lepszy" standard nie jest dostępny w głównych przeglądarkach mobilnych.

  3. Co my jako programiści mamy używać przez następne 3-5 lat, czyli kiedy Specyfikacja IndexedDB może zostać znormalizowana, mieć więcej funkcji, zaimplementowanych w głównych przeglądarkach mobilnych/tabletów i jest kilka fajnych bibliotek, które ułatwią sprawę?

W3C powinien utrzymywać równoległy standard bazy danych Web sql i po prostu naprawić problemy. Ma już wsparcie dla głównych platform mobilnych i działa całkiem dobrze. Fakt, że Mozilla i Microsoft jako dwóch graczy z największą pulpitową przeglądarką akcji byli w stanie uzyskać ten standard złomowany jest dość wątpliwy i może być postrzegany jako próba utrudnienia postępu na mobilnych platformach internetowych, dopóki nie będą w stanie nadrobić zaległości i zaoferować konkurencyjnych rozwiązań przeciwko iOS/Safari i Androidowi.

Podsumowując, czy ktoś ma rozwiązanie mojego problemu, które będzie działać na iOS/Android dla telefonu/tabletu urządzenia. Może ładny API wrapper, który może używać wielu implementacji baz danych w tle z możliwością zapytań i pozwala wybrać, która baza danych ma priorytet. Widziałem takie rzeczy jak lawnchair , ale jestem pewien, że domyślnie pozwala używać lokalnej pamięci masowej i wraca do innych. Myślę, że wolałbym użyć Web SQL (domyślnie), a następnie wolniejsze opcje.

Każda pomoc dla rozwiązania bardzo mile widziane, dzięki!

Author: Peter Aron Zentai, 2011-10-12
Source

7 answers

Zalecałbym sprawdzenie biblioteki JayData , która faktycznie ma dokładny cel stworzenia warstwy dostępu do danych dla urządzeń mobilnych. JayData zapewnia warstwę abstrakcji z zapytaniem języka JavaScript (JSLQ) i obsługą JavaScript CRUD i pozwala pracować dokładnie w ten sam sposób z różnymi typami przechowywania danych offline i online. JayData obsługuje radzenie sobie ze złożonymi podmiotami, a także relacjami z podmiotami lokalnie lub zdalnie.

W momencie pisania JayData obsługuje następujące sklepy lub protokoły: webSQL(SQLite)/IndexedDB/OData/YQL/FBQL.

Twój szczególny problem z różnymi systemami dostarczającymi różne silniki pamięci masowej można łatwo rozwiązać za pomocą funkcji dostawcy awaryjnego JayData: będzie używać dowolnej warstwy pamięci masowej, którą może znaleźć, a jednocześnie zapewnia ten sam API w stosunku do kodu konsumenta.

O tym, że WebSQL jest przestarzały do 2012 roku: w momencie pisania jest WebSQL, który nadal ma 95% pokrycia urządzeń, w tym Samsung SmartTV i Amazon Kindle. Sprawdź program kindle wykonujący testy jednostkowe WebSQL za pomocą JayData .

 17
Author: Peter Aron Zentai,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-21 06:45:52

Ja bym sobie kupił CouchBase Lite. Jest to prawie w pełni funkcjonalna implementacja CouchDB, która działa na Androida i iOS.

IOS

Android

Jeśli owijasz swoją aplikację w coś w rodzaju PhoneGap, możesz utworzyć natywne aplikacje HTML 5 dla obu platform i będziesz musiał tylko trochę programowania specyficznego dla Androida/iOS, aby zaimplementować CouchDB.

Plusy:

  • szybki silnik widoku do zapytań w wielu rzędach data.
  • Dirt prosta i potężna obsługa replikacji.

Wady:

  • przechowuj wartość klucza - przyzwyczajenie się do tego zajmie trochę czasu.
 13
Author: rwilliams,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-27 10:27:48

Przeprowadziłem kolejne badania, szukając rozwiązania dla mojego własnego projektu. Wygląda na to, że ta Biblioteka jest raczej obiecująca: http://nparashuram.com/IndexedDBShim/

Pozwala na wykorzystanie IndexedDB API z WebSQL za kulisami.

To testy na najnowszych iPadach, iPhone 5, Androidzie 4.2.2.

Mam nadzieję, że to komuś pomoże.

 6
Author: KIR,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-06 17:53:12

Powiedziałbym, żebyś użył do tego Corony . Jest to prywatna platforma używana do skrzyżowanych aplikacji mobilnych, która ma wsparcie dla SQLite .

Plusy

    Jest to łatwe i ma duże wsparcie dla SQLite i nie trzeba robić dziwnych rzeczy z pamięcią Html5]}

Cons

    Musisz za to zapłacić, jeśli chcesz go używać w Android Market lub iOS Market.

Wklejam tu co o tym mówią:

Corona zawiera wsparcie dla baz danych SQLite na wszystkich platformach. To jest oparty na wbudowanej obsłudze sqlite na iPhonie oraz skompilowanym wersja SQLite na Androida. Należy pamiętać, że Zwiększa to Rozmiar Android binary by 300K.

SQLite jest dostępny we wszystkich wersjach Androida, iPhone ' a i iPada, jako podobnie jak w symulatorze Corona...

 2
Author: A.Quiroga,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-15 15:50:37

" widziałem takie rzeczy jak lawnchair, ale jestem całkiem pewien, że domyślnie pozwala używać pamięci lokalnej i spada z powrotem do innych. Myślę, że wolałbym użyć Web SQL (domyślnie), a następnie wolniejsze opcje."

Jest to konfigurowalne, każdy z 'adapterów' do silników magazynowych jest niezależny, można przekazać adapter do konstruktora Lawnchair lub, alternatywnie, zmienić kolejność, w jakiej spada z powrotem do innych opcji magazynowania, łącząc pliki javascript inaczej podczas tworzenia biblioteki. np. dla zindeksowanego-db, a następnie spadającego z powrotem do sqlite, a następnie gears sqlite: 

git clone https://github.com/brianleroux/lawnchair.git  
cd lawnchair  
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js

Oczywiście, jak sugerują inne odpowiedzi, możesz owinąć swój html5 w natywną aplikację za pomocą phonegap itp. wtedy będziesz miał wiele opcji, ale jeśli chcesz trzymać się standardów internetowych, może to być dobry sposób, aby przejść, dopóki nie będziemy mieli szerokiego przyjęcia IndexedDB.

 2
Author: user1022475,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-02-03 14:23:20

Dlaczego nie napisać prostego silnika pamięci w javascript (który obejmuje część "opartą na standardach")? Najwyraźniej nie potrzebujesz niczego bardzo wyszukanego, więc nie powinno to wymagać zbyt dużego wysiłku, aby to działało.

Wykonałbym:

  • przechowuj wszystko w formacie bson lub podobnym formacie binarnym.
  • Analizuj i twórz indeksy w plikach i czytaj przy starcie.
  • zapytanie za pomocą javascript i odczyt z dużego pliku z Twojej (oczywiście offline) sieci podanie.
  • przechowuj zaktualizowane obiekty oddzielnie.

To rozwiązanie jest możliwe tylko wtedy, gdy baza danych jest wystarczająco prosta. Ale myślę, że to może działać -- obsługa javascript jest dobra na urządzeniach mobilnych.

Dla inspiracji tutaj {[18] } jest implementacja Btree+ w javascript.

Do odczytu plików lokalnych potrzebny jest interfejs API file API , który może być użyty do dostępu do plików lokalnych. Jest on obsługiwany w większości nowoczesnych przeglądarek, nawet Safari 6. I nie udało się ustalić, czy obecne przeglądarki iPhone obsługują ten interfejs API.

 1
Author: alexfernandez,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-10-19 23:45:47

Warto sprawdzić moją bibliotekę open source https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

Moduł bazy danych Javascript dla mechanizmów magazynowania Indexeddb, WebDatabase (WebSQL) i WebStorage (localStorage) obsługujących migrację wersji, zaawansowane zapytania i transakcje.

Będąc biblioteką NoSQL, join jest ręczny, ale nie niemożliwy. W bibliotece są już wbudowane algorytmy łączenia kluczy.

 1
Author: Kyaw Tun,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-30 15:14:46