Przechowywanie danych w shareprefernce czy w bazie danych ?

Witam,
Mam takie pytanie dotyczące przechowywanie danych.Po prostu przechowujemy list kart. Podana karta ma wiele właściwości. Dane są wrażliwe więc są szyfrowane i odpowiednich miejscach odszyfrowane. Moje pytanie jest takie co jest lepsze stosowanie sharePreference czy zapisywanie ich do bazy ?

Nie ma żadnych ograniczeń co do tego co można przechowywać w SharedPreferences, chociaż przechowywanie danych o zagnieżdżonej strukturze może być bardzo kłopotliwe.

Generalnie zaleca się, żeby w SharedPreferences trzymać proste wartości bool, int, string, które są związane z konfiguracją aplikacji. Z kolei dane o złożonej strukturze, które prezentuje aplikacja powinno się trzymać w bazie danych. Dodatkowo Android ma coś takiego jak ContentProvider, który pomaga zarządzać dostępem do danych (które znajdują się np. w bazie danych SQLite) i umożliwia ustawienie różnych stopni dostępu, a także pozwoleń na poszczególne operacje. ContentProvider umożliwia przykładowo ustawienie prawa do zapisu danych tylko dla naszej aplikacji oraz prawa odczytu dla innych aplikacji.

Jeżeli masz w aplikacji dane wrażliwe, to bez względu na wybór sposobu ich przechowywania powinny być one szyfrowane przed zapisem i odszyfrowywane w trakcie odczytu. Cały proces szyfrowania i odszyfrowywania danych trzeba obsłużyć samodzielnie.

Dodatkowo Android od wersji 5.0 wspiera szyfrowania całej partycji danych hasłem użytkownika. Z kolei od wersji 7.0 wspiera szyfrowanie poszczególnych plików.

Mam klasę Card i zawiera ona 10 pól moim teraz zdaniem najlepiej to zrobić sql zrobić tabel przed zapisaniem podane dane zaszyfrować i odszyfrowywać w odpowiednim miejscu

Prostsze jest zapewne użycie SnappyDB. @Haskell content provider nie powstał w celu "ułatwienia dostępu do bazy", a w celu udostępnienia bazy innym programom/procesom (jak np sync adapter, gdzie synchronizacja odpala się w nowym procesie), użycie content providera jako lokalnego cache dla aplikacji nie ma sensu

P.S. SharedPreeferences to zwykłe pliki xml, więc jeśli wepchasz tam za dużo, to wydajność będzie tragiczna.