Kiedy używać dostawcy treści

Rozumiem, że dostawcy treści zezwalają na publiczne udostępnianie danych między aplikacjami. Zastanawiam się jednak, czy ktoś myśli o tym, aby dostawca treści używał tylko w swojej własnej aplikacji. Czy miałoby to jakieś korzyści? Jakieś wady?

W przeszłości właśnie zaimplementowałem SQliteOpenHelper, aby uzyskać dostęp do danych z mojej bazy danych, ale rozważam utworzenie dostawcy treści. Wydaje mi się, że podejście URI do żądania danych jest jasne i zwięzłe. Z drugiej strony, czy używanie dostawcy zawartości tylko dla mojej aplikacji będzie zbędne (ponieważ w nim będę miał klasę SQliteOpenHelper) i będzie wymagało więcej pracy niż potrzebuję?

Jeśli nie planujesz udostępniać danych, nie myśl o dostawcach treści. Są potężne, ale trudne do napisania, a ich wdrożenie będzie po prostu głupie, jeśli zamierzasz ich używać wewnętrznie.

Zastanawiam się jednak, czy ktoś myśli o tym, aby dostawca treści używał tylko w swojej własnej aplikacji.

Oczywiście ... na przykład w przypadku starej aplikacji listy zadań do wykonania, którą napisałem, musiałem napisać dostawcę treści, aby umożliwić innym aplikacjom pobieranie i dostęp do stanów zadań. To była część wymagań, ale co więcej, miało to sens i sprawiło, że aplikacja była ładniejsza.

Twierdzę, że zdecydowanie dobrym pomysłem jest użycie ContentProvidernawet, jeśli nie zamierzasz upubliczniać go.

Dobrą praktyką jest zapewnienie dodatkowego poziomu abstrakcji danych, aby ułatwić wewnętrzne zmiany. Co się stanie, jeśli później zdecydujesz się zmienić podstawową strukturę bazy danych? Jeśli używasz a ContentProvider, możesz zawrzeć w nim wszystkie zmiany strukturalne, gdzie jakbyś ich nie używał, jesteś zmuszony do zmiany wszystkich obszarów kodu, na które wpływają zmiany strukturalne. Poza tym miło jest móc ponownie używać tego samego standardowego interfejsu API do uzyskiwania dostępu do danych zamiast zaśmiecać kod niskopoziomowym dostępem do bazy danych.

Ponadto zawsze istnieje możliwość, że będziesz chciał ujawnić swoje dane w przyszłości. Jeśli nie użyjesz ContentProviderprzedniej części, znacznie trudniej będzie ją zamontować w późniejszym terminie.

Następnie są inne części Androida, w których ContentProvidersą wymagane / zalecane, na przykład podczas używania SyncAdapters i jeśli chcesz mieć widżet aplikacji, który obejmuje na przykład dostęp do danych.

Podsumowując, pisanie z ContentProvidergóry wiąże się z niewielkim nakładem pracy (kiedy już nauczyłeś się API, co i tak jest dobrym pomysłem), więc ma to sens, nawet w przypadku danych prywatnych.

Spójrz na MOTODEV Studio dla Eclipse. Jest to środowisko programistyczne, które rozszerza Eclipse. Mają narzędzie, za pomocą którego można automatycznie generować dostawcę treści dla bazy danych. Jeśli dostawca treści ułatwia dostęp do danych i nie ma to znaczącego wpływu na wydajność, używaj ich. W większości scenariuszy tak będzie.

Krótko mówiąc, Content Providerspomaga w efektywnym zarządzaniu danymi . Sugerowałbym użycie ich z następujących powodów.

• Działa jako warstwa abstrakcji między interfejsem użytkownika a bazą danych . Możesz zaimplementować walidację danych w ContentProviders, aby sprawdzić poprawność danych wprowadzonych przez użytkownika. Pozwala także modyfikować strukturę bazy danych bez dotykania interfejsu użytkownika i innych części.
• Dobrze współgrają z innymi klasami platform Android, takimi jak SyncAdapter. Na przykład możesz automatycznie odświeżyć listę, gdy wartość w bazie danych zmieni się za pomocą ContentProviders wraz z CursorLoader. Bez ContentProviderów musisz samodzielnie zaimplementować wiele takich funkcjonalności.
• Możemy bezpiecznie udostępniać nasze prywatne dane innym aplikacjom . Korzystanie z ContentProviders pozwoli nam łatwo i bezpiecznie udostępniać nasze dane innym aplikacjom.

Więc nawet jeśli nie potrzebujesz teraz żadnej z tych funkcji, możesz potrzebować ich w przyszłości i dobrze jest pójść o krok dalej i wdrożyć je teraz.

Zgadzam się, że ContentProviders są trochę trudne do zrozumienia, ale są zdecydowanie pomocne, nawet jeśli chcesz używać ich wewnętrznie we własnej aplikacji. Najlepsze jest to, że możesz dostosować dostawców treści pod kątem odpowiednich identyfikatorów URI.

Oto scenariusz, w którym możesz mieć 5 tabel w swojej bazie danych, ale przed użyciem musisz połączyć kilka z nich w określonych zamówieniach. I utwórz identyfikator URI treści dla każdego z tych połączeń. Możesz wtedy użyć tych identyfikatorów URI jako tabeli :)

Sugeruję, abyś poszedł dalej z dostawcą treści, będziesz zaskoczony, jak potężny jest.

Z mojego punktu widzenia dostawca treści ma wiele zalet, pozostawiając w spokoju tylko udostępnianie danych innym aplikacjom. Jeśli musisz zsynchronizować się z serwerem za pomocą adaptera synchronizacji, użyj wiadomości w chmurze Google, automatycznie zaktualizuj interfejs użytkownika, gdy podstawowe dane w bazie danych zmienią się za pomocą programów ładujących, zaimplementuj wyszukiwanie, użyj widżetów ... wtedy dostawca treści jest dla Ciebie.

Wolę, abyś postępował zgodnie z wytycznymi, ponieważ pewnego dnia być może będziesz musiał zaimplementować niektóre z powyższych funkcji dołączonych do dostawcy treści

Nawiasem mówiąc, możesz szybko zbudować bazę danych i CP w mniej niż 5 minut za pomocą generatora dostawców treści

Jak wspomniano w dokumentacji: Tworzenie dostawcy treści

Nie potrzebujesz dostawcy do korzystania z bazy danych SQLite, jeśli użycie odbywa się całkowicie w ramach Twojej własnej aplikacji.

Po co więc zawracać sobie głowę rozwijaniem tego narzutu? Chcesz łatwiejszego i szybszego rozwoju, prawda? Zatem wystarczy jedna warstwa abstrakcji (potomek SQLiteOpenHelper).

Zobacz Brzytwa Ockhama Nie twórz bytów bez dobrego powodu.

Nie używaj dostawcy treści, jeśli nie chcesz udostępniać danych innym aplikacjom. Użyj prostej bazy danych sqlitedatabase do wykonywania operacji na bazie danych. Zachowaj ostrożność podczas korzystania z dostawców treści do przechowywania poufnych danych, ponieważ inne aplikacje mogą uzyskać dostęp do Twoich poufnych informacji

Korzystanie z dostawcy treści może pomóc w uzyskaniu dodatkowego poziomu abstrakcji - umieszczenie go we własnej aplikacji znacznie wydłuża czas tworzenia projektu. Jeśli jednak używasz go do udostępniania danych, ustawień aplikacji lub konfiguracji w wielu aplikacjach, wybór należy do dostawcy treści.

Obserwuj swoje poziomy bezpieczeństwa, a polecam użycie SQLcipher do szyfrowania danych podczas resetowania (DAR), jeśli Twój dostawca treści pisze do SQLite. (Korzystałem z dostawcy treści w kilku rozwiązaniach i zapewniłem możliwość wykonania na żywo „migawki” wartości operacyjnych do debugowania i testowania).