2013-01-18 4 views
13

이것은 특정 기술에 반드시 바인딩되는 개념적 질문이 아닙니다. 서버의 일부 데이터베이스, 일부 REST/JSON API가 해당 데이터베이스의 컨텐츠에 액세스하고 일부 모바일 클라이언트가 API를 통해 검색된 데이터를 표시한다고 가정 해 보겠습니다.부분 데이터베이스 모델을 서버에서 클라이언트로 동기화

클라이언트에서 일부 캐싱 메커니즘을 사용하고 클라이언트가 읽기만하는 한 데이터에 오프라인으로 액세스 할 수있게하는 것이 좋습니다. (제 경우에는 오프라인 클라이언트에 대한 쓰기 액세스를 거부하는 것이 좋습니다. 발생할 수있는 모든 불쾌한 갈등을 관리하지 않아도됩니다.

문제를 해결하는 좋은 방법은 서버 데이터베이스 모델의 하위 집합을 클라이언트에두고 서버에서 클라이언트로 데이터를 동기화하는 것입니다. 로컬 데이터베이스에 액세스하면 즉시 결과가 반환 될 수 있지만 업데이트 요청이 서버에 트리거됩니다. 서버가 수정 된 데이터를 반환하는 경우 클라이언트 모델은 로컬 데이터베이스를 동기화하고 데이터 변경 사항을 디스플레이에 알립니다.

결국 목표는 사용자가 인터넷 연결의 안정성에 관계없이 정보를 탐색 할 수 있으며 데이터를 수정하지 않는 한 연결 대화 상자 또는 이와 유사한 방법으로 짜증을 내지 않는 것입니다.

구현의 관점에서 ... 한편으로는 다른 벤더의 서버 데이터베이스와 서버 데이터베이스를 직접 연결하는 것이 좋지 않은 것처럼 보입니다. 최소한 두 데이터베이스 구현보다 공급 업체 독립적 모델이 필요합니다. 반면에 서버 데이터베이스의 데이터를 일부 전송 형식으로 변환하고 다시 클라이언트 데이터베이스에 저장하는 것보다 많은 오버 헤드가 발생합니다.

우아하고 유지 보수가 잘되는 방식으로 해결하는 방법에 대한 제안이 있으십니까?

답변

10

큰 데이터베이스의 작은 부분을 핸드셋에 로컬로 동기화하는 앱을 만들고 있습니다. 핸드셋에서 발생해야하는 초기 사전로드가 있지만 그 이후에는 백그라운드에서 비동기 적으로 업데이트가 발생합니다.

우선, JSON 또는 XML을 사용하여 서버와 핸드셋의 연결을 끊는 것이 좋습니다. 플랫폼에 관계없이 동일한 기술을 사용해야 할 때 한 가지 기술을 사용하면 항상 문제가 발생합니다. 즉, 다른 플랫폼 (웹, iOS 등)으로 확장하려는 경우 서버에서 지시 한 형식을 사용해야합니다.일반 형식을 선택하면 장기적으로 더 간단 해집니다. 실제로 JSON을 읽거나 쓰는 공공 도서관의 규모는 사소한 문제입니다.

우리가 데이터를 동기화하는 데 사용하는 두 가지 방법이 있습니다.

1. 알람 관리기

우리는 알람 관리기가 정기적으로 웨이크 업 서비스를 실행하는 데 일정 (6 시간마다 말할 수 있습니다). 웨이크 업은 서버에 접속하는 백그라운드 서비스를 시작하고 JSON에서 변경 사항을 다운로드하고 로컬 SQLite DB를 업데이트합니다. 연결이없는 경우 업데이트는 건너 뛰고 다음 웨이크 업을 위해 예약됩니다. 연결이 복원되면 자동으로 동기화를 다시 시작하기 위해 ConnectivityChanged 수신기를 추가합니다.

2 GCM

조금 더 많은 작업입니다하지만 변화가있을 때 로컬 데이터베이스를 업데이트 할 경우 배터리와 데이터 사용을 많이 절약 할 수 있습니다. Google Cloud Messaging은 기기에 웨이크 업 메시지를 보내고 동기화 서비스를 시작하도록 알릴 수 있습니다. 동기화 서비스는 위의 AlarmManager 메소드와 동일하게 실행됩니다.

우리는 데이터를 "신선한"상태로 유지하는 방법과 변경 빈도에 따라 위의 두 가지 방법을 조합하여 사용합니다. 기상 정보가 매 4 시간 이상으로 업데이트 될 필요는 없지만 RSS 피드와 같은 것이 아마도 매 30 분마다 업데이트되어야합니다.

데이터베이스 동기화를 실행하려면 다음을 사용하십시오.

수신기 -> 시스템 이벤트를 수신 및 서비스 서비스를 실행 -> 서버에 연결합니다 JSON을 다운로드하고 SQLite는 공급자에게 공급자를 업데이트 -> 데이터베이스에 레코드를 삽입하고 ContentObservers ContentObservers 콘텐츠 변경을 방송 - > 응용 프로그램이 실행 중일 때 ContentObservers는 UI를 새 데이터로 업데이트합니다.

위의 각 구성 요소에는 기술적 인 세부 사항이 많이 있지만 서버 데이터를 로컬 서버와 동기화하기위한 매우 강력한 아키텍처를 제공해야합니다 db.

+0

나는 John이 위에서 설명한 두 가지 옵션 중 하나를 강력하게 제안합니다. GCM은 Android에 내장 된 방식 때문에 선호됩니다. 그러나 프로젝트 요구가 GCM 경로를 충족시킬 수없는 경우 첫 번째 옵션이 유지됩니다. –

+0

첫 번째 옵션이 마음에 들지 않으므로 사용자가 볼 수없는 데이터를 업데이트 할 수 있습니다. GCM 내가 경량 알림을 포함 할 계획이지만이를 통해 데이터베이스 업데이트를 트리거하는 것은 내 경우에 너무 낭비 일 수 있습니다. 또한 그 푸시 서비스는 벤더 고유의 것으로 보이기 때문에 휴대 전화 플랫폼에서 얼마나 잘 작동하는지 잘 모르겠습니다. 이 세 번째 옵션에 대해 어떻게 생각하십니까? 사용법에 따라 로컬 데이터베이스를 업데이트하십시오. 데이터가 로컬에서 액세스 될 때 로컬 결과가 즉시 반환 될 수 있지만 서버에 대한 요청이 동일한 데이터에 대해 전송됩니다 – mibollma

5

비슷한 요구 사항이있는 프로젝트에서 작업하고 있습니다. 우리는 어딘가에있는 서버에 큰 데이터베이스를 가지고 싶습니다. 그런 다음 데이터를 가져 오는 모바일 장치가 필요합니다. 기기가 오프라인 상태가되면 데이터 사본을 로컬에 저장했기 때문에 괜찮습니다.

우리는 BigCouch (클러스터링을 지원하는 Apache CouchDb 포크)를 서버 기술로 사용하고 모바일 장치에서 Couchbase Mobile을 사용하기로 결정했습니다. (안드로이드 용 TouchDB는 Couchbase Mobile을 대체 할 예정이지만 아직 안정적이지는 않습니다.)

우리가 Couch * 기술을 사용하게 된 이유는 Couch가 HTTP를 통해 우수한 복제 기능을 갖추고 있기 때문입니다. 프로그래밍 방식으로 모바일 장치에서 동기화 이벤트를 시작할 수 있으며 모든 삽입, 업데이트 및 삭제를 복제합니다. 모바일 장치에 자신의 임베디드 CouchDb에 대한 정보를 저장하여 오프라인에서 읽을 수 있습니다.

Couch 도로를 내려가고 싶지 않다면 SQLlite와 같은 것을 사용하여 REST/API 호출의 결과를 저장할 수 있습니다. 그런 다음 모바일 장치가 오프라인 상태로 돌아 왔을 때를 위해 자신의 복제 논리를 작성해야합니다. 이것을 창조적 인 방법으로 할 수 있습니다. 아마도 옵션 일 수 있습니다.

+0

By Couchbase Mobile github에서 Android-Couchbase, TouchDB에서 TouchDB-Android on github을 의미합니까? 두 사람 모두 꽤 오랫동안 일하지 않았기 때문에 어떤 점이 생산성있는 환경에 적합 할 지 궁금합니다. – mibollma

+1

예. 그것들 모두는 내가 의미했던 것입니다. 두 프로젝트가 상당히 죽은 것이 맞습니다. 실제로 Couchbase Mobile은 공식적으로 사망합니다. TouchDB는 iOS 버전의 포트입니다 (꽤 안정적이며 많은 작업이 이루어졌습니다).하지만 완전하지는 않습니다. Android의 경우 당분간 Couchbase Mobile을 사용할 것입니다. 코드는 죽었지 만 작동합니다. 우리의 희망은 Couchbase 2.0이 출시 된 이후에 TouchDB 포트에 집중할 수있는 시간을 가질 것입니다. 실제로 계산 된 위험이기 때문에 처음부터 복제를 작성할 필요가 없습니다. – ryan1234