저는 Android 용 SQLite 데이터베이스 프로그래밍을 해봤지만 Content-Provider에 대해서는 다음을 제외하고는 아무것도 모릅니다. " Android 개발자 페이지를 참조 했으므로 Android SDK는 데이터를 저장하고 검색하는 데 사용되는"Content-provider "에 대해 설명했습니다."
하지만,
어떤 예나 도움이 !!
답변:
다음과 같은 주요 차이점을 발견했습니다.
데이터를 데이터베이스에 저장하는 것은 데이터를 유지하는 좋은 방법 중 하나 이지만 Android에서 생성 된 Android 데이터베이스는 visible해당 데이터를 생성 한 애플리케이션에만 해당된다는 경고가 있습니다. 즉, 한 애플리케이션에서 Android에서 생성 한 SQLite 데이터베이스는 다른 애플리케이션이 아닌 해당 애플리케이션에서만 사용할 수 있습니다.
그래서 만약 당신이 need to share data between applications, you need to use the content provider model as recommended in Android. 기사에서는 컨텐츠 제공자의 기본 사항과이를 구현하는 방법을 설명합니다.
이 링크 에서이 기사를 찾았습니다.
정말 좋은 정보가 제공되었습니다.
"Content-Provider"와 "SQLite Database"의 정확한 차이점은 무엇입니까?
ContentProvider다른 프로세스에 데이터베이스를 노출하는 구현할 수있는 API입니다. 그것은 할 수 있습니다 데이터가 SQLite 데이터베이스에 저장되는 방식으로 구현 될 수 있지만 그럴 필요하지 않습니다.
언제 데이터를 저장하는 것이 가장 좋습니까?
초록에서 대답하기는 불가능합니다. 일반적으로를 사용해야하는 경우가 아니라면 ContentProvider데이터베이스를 사용하십시오.
저는 단순히 SQLite 메서드를 사용하는 수천 명의 사용자가 사용하는 좋은 앱을 많이 만들었습니다. 그러나 그것은 얼마 전이었고 이제는 ContentProvider가 쉽게 처리 할 수있는 많은 코드를 수동으로 작성해야했습니다. 그 당시에는 코드에 복잡성 만 추가하는 것처럼 보였기 때문에 콘텐츠 제공 업체를 사용하는 것을 선호하지 않았습니다.
그러나 지난 몇 년 동안 Android가 발전함에 따라 시간을 절약하고 더 많은 일을 할 수있는 ContentProvider로 이동했습니다. 나는 지금 그것을 광범위하게 사용합니다. 콘텐츠 제공자 클래스를 작성하면 생활이 훨씬 쉬워집니다. ContentProvider를 사용하면 과거에 모든 것을 수동으로 작성해야했지만 여전히 효율적으로 작동하지 않는 커서 로더, 로더 콜백 및 대량 삽입을 훨씬 쉽게 처리 할 수 있습니다. 특히 하나의 notifychange () 메서드 덕분에 이제 자동으로 업데이트되는 목록보기를 업데이트 할 때. 즉, 이제는 내 리스너를 입력하고 목록보기 및 어댑터에서 콘텐츠를 수동으로 업데이트 할 필요가 없습니다. 또한 데이터베이스를 열고 닫는 것에 대해 걱정하거나 메모리 누수에 대해 걱정할 필요가 없습니다. 그것은 모두 콘텐츠 제공자가 처리합니다. 가끔 내가 직면하는 유일한 문제는 ContentProviders에서 복잡한 쿼리를 수행 할 수 없다는 것입니다. 이 경우에도 여전히 원시 쿼리를 사용하고 sqlite와의 구식 수동 상호 작용을 사용할 수 있습니다.
이전에 자신의 DbAdapter, Helper 및 Observer를 작성한 경우 모든 것을 ContentProvider로 변환하는 데 시간을 소비하지 않고도 새 앱으로 안전하게 이동할 수 있습니다. 그러나 내 경험을 바탕으로 ContentProvider로 이동하는 것이 좋습니다. 익숙해지는 데는 시간이 좀 걸리 겠지만 일단 경험이 쌓이면 그대로있을 것입니다.
UPDATE 2017 이제 모든 플랫폼에서 데이터베이스를 사용하는 훨씬 더 나은 방법 인 Realm으로 전환했습니다 . 몇 시간 동안 배우고 앱 개발 경력에서 수많은 시간을 절약하십시오.
기본적으로 콘텐츠 공급자는 스레드로부터 안전하지 않습니다. 콘텐츠 제공 업체를 사용하는 여러 스레드가있는 경우 다양한 예외가 발생하고 기타 데이터 불일치가 발생하는 것을 볼 수 있습니다. 이 문제를 해결하는 가장 쉬운 방법은 콘텐츠 공급자가 노출하는 각 공용 메서드에서 동기화 된 키워드를 사용하는 것입니다.
이런 식으로 한 번에 하나의 스레드 만 이러한 메서드에 액세스 할 수 있습니다.
새로운 Serval Maps 애플리케이션에서 바이너리 파일의 데이터를 애플리케이션에서 내부적으로 사용하는 데이터베이스로 가져올 필요가 있습니다. 이 작업을 수행하고 나머지 응용 프로그램을 잘 활용하려면 다음을 수행하는 것이 가장 좋습니다.
가져 오기를 수행 할 새 스레드를 생성하여 다른 스레드, 특히 UI 업데이트를 담당하는 스레드에 악영향을 미치지 않도록합니다. 그리고 동기화 된 메서드를 더 많이 사용해야하는 다른 스레드를 제공하기 위해 각 가져 오기가 끝날 때 잠시 일시 중지합니다.
Android의 콘텐츠 제공 업체가 작동하는 방식은 나머지 코드와 기본 데이터베이스간에 추상화 계층을 제공하는 것입니다. 이것은 주로 콘텐츠 제공자가 데이터베이스가 아닌 다른 곳에서 데이터에 액세스 할 수 있다는 사실에 기인합니다.
즉, 기본 데이터베이스에서 원시 SQL 쿼리를 실행할 수 없으며 쿼리 메서드와 같은 다양한 메서드에 전달 된 변수를 사용하여 SQL 쿼리의 다양한 구성 요소를 지정해야합니다. 콘텐츠 공급자가 SQL을 처리하는 방식에 맞지 않는 작업이있는 경우 두 가지 옵션이 있습니다.
쿼리에 대해 옆으로 생각해보십시오. 대체 쿼리를 통해 필요한 데이터를 얻고 커서에서 결과에 액세스 할 수 있습니다. 데이터에 정상적으로 액세스하려면 URI를 사용하고 대안이없는 작업에 대해서는 특정 쿼리와 일치하는 특수 URI를 사용합니다.
나는 같은 의심을 찾으 면서이 대답 을 읽었 으므로 그것을 공유하는 것을 생각했습니다. 그것은 말한다-
내부적으로 쉽게 변경할 수 있도록 데이터에 대한 추가 추상화 수준을 제공하는 것이 좋습니다. 나중에 기본 데이터베이스 구조를 변경하기로 결정하면 어떻게됩니까? ContentProvider를 사용하면 그 안에 모든 구조적 변경 사항을 포함 할 수 있습니다. 마치 사용하지 않는 것처럼 구조적 변경 사항의 영향을받는 코드의 모든 영역을 변경해야합니다. 게다가 데이터베이스에 대한 낮은 수준의 액세스로 코드를 흩 뿌리기보다는 데이터 액세스에 동일한 표준 API를 재사용 할 수 있다는 점이 좋습니다.
따라서 콘텐츠 제공 업체를 사용하는 것이 좋습니다.
고급 콘텐츠 관리 시스템을 생각해보십시오. 각 개체 (페이지, 이미지, 뉴스 기사, 이벤트 항목 등)에는 콘텐츠, 주소, 사용자 권한 및 시스템의 다른 부분에서 상호 작용하는 방법이 있습니다. 콘텐츠 제공자는 Android를 위해 그렇게합니다. 이제 응용 프로그램에 저장 한 파일이나 이미지를 공유 할 수 있습니다. 비즈니스 연락처, 편집 가능한 메모 등과 같은 사용자 지정 공유 가능 개체를 만들 수도 있습니다. 다른 응용 프로그램에서 열 때 이러한 개체를 처리 할 보안 및 기본 응용 프로그램을 지정할 수도 있습니다.
한 가지 차이점은 콘텐츠 제공자가 콘텐츠 관찰자에 대한 플랫폼 지원을한다는 것입니다. SQLite 데이터베이스에 대한 고유 한 Observable 패턴을 구현해야합니다.