Blog > Komentarze do wpisu
iOS / iPhone - jak przechowywać, zapisywać dane aplikacji

Po przerwie, temat rozgrzewający (dla mnie) a mianowicie zestawienia sposobów przechowywania danych aplikacji na urządzeniach iOS.

 

 

Wykorzystanie NSUserDefaults jest chyba najprostszym sposobem, w jaki możemy przechowywać dane naszej aplikacji. Klasa ta powinna (może) być wykorzystywana do zapisywania prostych informacji konfiguracyjnych naszego programu, na przykład flagi, czy jest to jego pierwsze uruchomienie / pierwsze uruchomienie po aktualizacji czy tez nie, bądź innych informacji konfiguracyjnych (preferencji użytkownika).

 

 

Keychain, jako bezpiecznym mechanizm przechowywania danych i jako taki powinien być wykorzystywany do zapisu danych wrażliwych, takich jak informacje prywatne użytkowników bądź nazwy i hasła.

 

Listy wlaściwości PLists możemy z powodzeniem wykorzystywać do przechowania większych ilości, ale bez przesady) danych posiadających określoną strukturę (ang. structured data). Przykładowo, PLists możemy użyć do zapisu wygenerowanych przez użytkownika listy pozycji geograficznych, bądź też użyć mechanizmu do przechowywania danych demo naszej aplikacji. Jeśli pracujemy nad biblioteką, którą będziemy udostępniać innym programistom, PLists mogą być użyte, jako platforma konfiguracyjna dla osób, pracujących z naszą biblioteka.

 

 

Archiwizacje obiektów (ang. object archiving) możemy wykorzystać do serializacji / deserializacji bądź danych binarnych, bądź danych strukturalnych w przypadku, gdy nie chcemy, bądź nie możemy do ich przechowywania użyć PLists.

 

 

Core Data to stosunkowo skomplikowany (niektórzy mogą się tu ze mną nie zgodzić) mechanizm przechowywania danych wprowadzonych przez Apple wraz z wersją 3.0 systemu iOS. Wykorzystywany może być przede wszystkim do przechowywania większej ilości danych powiązanych ze sobą zależnościami (relacjami). Core Data, jako backend wykorzystywać może nie tylko SQLite, o którym powiemy sobie krótko za chwile, ale także przykładowo pliki XML, bądź inne w opracowanym przez programistę formacie. Backend, jest obsługiwany automatycznie i nie wymaga bezpośrednich interwencji programisty. Do innych zalet należą przykładowo mechanizmy „undo”, „redo” i integracja z iCloud.

 

 

SQLite jest moim ulubionym mechanizmem przechowywania danych relacyjnych, najprawdopodobniej ze względu na szybkość, nieduże wymagania i moje wcześniejsze, bogate doświadczenia z SQL-em i relacyjnymi bazami danych. Powinien być wykorzystywany, gdy zależy nam na szybkości, gdy chcemy, aby nasze dane były dostępne na wielu platformach (przykładowo na iOS i Androidzie). Za wadę w tym wypadku można uznać podatność na błędy programistyczne i konieczność ręcznego oprogramowania niektórych mechanizmów jak na przykład wspomnianej integracji z iCloud. Ciekawe porównanie SQLite z CoreData znajdziecie w artykule Deana Gereaux zatutyłowanym iOS Data Storage: Core Data vs. SQLite.

 

 

Gdy żaden z powyższych mechanizmów nie spełnia naszych wymagań, przykładowo, gdy dane nie powinny znajdować się na urządzeniu użytkownika, gdy przykładowo chcemy, aby były dzielone z / udostępniane innym użytkownikom naszej aplikacji, powinniśmy zdecydować się na ich przechowywanie na serwerach zewnętrznych. Oczywiście, gdy jedyne, na czym nam zależy jest synchronizacja danych pomiędzy rożnymi urządzeniami, w pierwszym wypadku powinniśmy rozważyć iCloud.

 

 

Zestawienie oparte o własne obserwacje i listę udostępnioną przez Allesandro Orru. Jeśli coś istotnego pominąłem, proszę dać znać!

poniedziałek, 29 sierpnia 2016, m0rt1m3r

Related Posts Plugin for WordPress, Blogger...

Polecane wpisy





PowerBuilder Tetris
D - Tetris



Programowanie iOS

C# ToolBox

SQL / TSQL / PLSQL ToolBox

Linux / Unix ToolBox





Zaprzyjaznione Strony

Sprite Bandits

Cake Time