developer tip

서버 전략에서 데이터를 캐시하기위한 클라이언트 (iOS)의 핵심 데이터

optionbox 2020. 12. 24. 23:37
반응형

서버 전략에서 데이터를 캐시하기위한 클라이언트 (iOS)의 핵심 데이터


백엔드와 통신하는 많은 iOS 앱을 작성했습니다. 거의 매번 HTTP 캐시를 사용하여 쿼리를 캐시하고 응답 데이터 (JSON)를 Objective-C 객체로 구문 분석했습니다. 이 새로운 프로젝트의 경우 Core Data 접근 방식이 합리적 일지 궁금합니다.

내가 생각한 것은 다음과 같습니다.

iOS 클라이언트는 서버에 요청하고 JSON에서 CoreData 모델로 개체를 구문 분석합니다.

새 개체가 필요할 때마다 서버를 직접 가져 오는 대신 CoreData를 구문 분석하여 이미 요청을했는지 확인합니다. 해당 개체가 존재하고 만료되지 않은 경우 가져온 개체를 사용합니다.

그러나 개체가 존재하지 않거나 만료 된 경우 (일부 캐싱 논리가 여기에 적용됨) 서버에서 개체를 가져와 그에 따라 CoreData를 업데이트합니다.

이러한 아키텍처가 있으면 다음과 같은 이점이있을 수 있다고 생각합니다. 1. 백엔드에 대한 불필요한 쿼리를 피하십시오. 2. 오프라인 브라우징에 대한 완전한 지원을 허용하십시오 (DataCore의 RDBMS를 사용하여 관계형 쿼리를 만들 수 있음).

이제 여기 SO Gods에 대한 내 질문이 있습니다.

  1. 나는 이것이 일종의 백엔드 로직을 두 번째 (Server + CoreData) 코딩해야한다는 것을 알고 있지만 이것이 과잉입니까?
  2. 내가 예상치 못한 제한 사항이 있습니까?
  3. 다른 생각은 없나요?

우선, 등록 된 iOS 개발자라면 WWDC 2010 세션에 액세스 할 수 있어야합니다. 이 세션 중 하나는 "세션 117, 서버 기반 사용자 경험 구축"에 대해 설명했습니다. iTunes 에서 찾을 수 있습니다 .

REST / JSON / Core Data의 스마트 한 조합은 매력처럼 작동하며 코드를 재사용하려는 경우 시간을 크게 절약 할 수 있지만 HTTP에 대한 지식 (앱이 제대로 작동하려면 Core Data에 대한 지식이 필요함) 안전함).

따라서 핵심은 REST 및 핵심 데이터를 이해하는 것입니다.

  • REST를 이해 한다는 것은 HTTP 메서드 (GET, POST, PUT, DELETE, ... HEAD?) 및 응답 코드 (2xx, 3xx, 4xx, 5xx) 및 헤더 (Last-Modified, If-Modified-Since, Etag,. ..)

  • 핵심 데이터를 이해한다는 것은 모델을 설계하는 방법, 관계를 설정하는 방법, 시간 소모적 인 작업 (삭제, 삽입, 업데이트)을 처리하고, UI가 응답 성을 유지하도록 백그라운드에서 일을 수행하는 방법을 아는 것을 의미합니다. 그리고 물론 sqlite에서 로컬로 쿼리하는 방법 (예 : id를 프리 페치하여 서버 측 등가물을 얻으면 새 개체를 만드는 대신 개체를 업데이트 할 수 있음).

언급 한 작업에 대해 재사용 가능한 API를 구현하려는 경우 REST 및 핵심 데이터를 이해해야합니다. 그 부분에서 가장 많은 코딩을 수행 할 수 있기 때문입니다. (기존 API- 네트워크 계층 (또는 기타 )에 대한 ASIHttpRequest 및 구문 분석을위한 좋은 JSON 라이브러리 (예 : SBJSON )가 작업을 수행합니다.

이러한 API를 간단하게 만드는 핵심은 서버에서 RESTful 서비스를 제공하고 엔터티가 필요한 속성 (dateCreated, dateLastModified 등)을 보유하도록하는 것이므로 요청을 생성 할 수 있습니다 (ASIHttpRequest로 쉽게 수행 할 수 있습니다. GET, PUT, POST, DELETE) 및 적절한 Http-Header를 추가합니다 (예 : 조건부 GET : If-Modified-Since).

Core Data에 이미 익숙하고 JSON을 처리 할 수 ​​있고 HTTP 요청을 쉽게 수행하고 응답을 처리 할 수있는 경우 (다시 ASIHttpRequest가 여기에서 많은 도움이되지만 다른 것들이 있거나 하위 수준의 Apple NS-Classes를 고수하여 수행 할 수 있습니다. 요청에 대한 올바른 HTTP 헤더를 설정하고 Http-Response-Code를 적절하게 처리하기 만하면됩니다 (서버가 REST-ful이라고 가정).

기본 목표가 서버 측에서 Core-Data 엔티티를 다시 업데이트하지 않는 것이라면 엔티티에 "last-modified"속성이 있는지 확인하고 서버에 조건부 GET을 수행하십시오 ( 엔티티에 대한 "If-Modified-Since"Http-Header "마지막 수정"날짜. 해당 리소스가 변경되지 않은 경우 (서버가 REST-ful이라고 가정) 서버는 상태 코드 304 (수정되지 않음)로 응답합니다. 변경된 경우 서버는 "Last-Modified"Http-Header를 마지막으로 변경 한 날짜로 설정하고 Status-Code 200으로 응답하고 본문 (예 : JSON 형식)으로 리소스를 전달합니다.

따라서 항상 그렇듯이 귀하의 질문에 대한 대답은 항상 '상황에 따라 다릅니다'라는 것입니다. 재사용 가능한 모든 핵심 데이터 / 휴식 계층에 무엇을 넣고 싶은지에 따라 다릅니다.

숫자를 말해 보자 : 내가 원하는 곳에 내 위치를 지정하는 데 6 개월 (여가 시간, 주당 3 ~ 10 시간)이 걸렸고, 솔직히 나는 여전히 리팩토링하고 이름을 변경하고 있습니다. 특수 사용 사례 (요청 취소, 롤백 등)를 처리하고 세분화 된 콜백 (연결 가능성, 네트워크 계층, 직렬화, 핵심 데이터 저장 ...)을 제공합니다. 그러나 꽤 깨끗하고 정교하며 최적화되어 있으며 고용주의 일반적인 요구 사항 (여러 iOS 앱이있는 광고를위한 온라인 마켓 플레이스)에 적합합니다. 그 시간에는 API 학습, 테스트, 최적화, 디버깅 및 지속적으로 API 변경 (먼저 기능을 추가 한 다음 개선 한 다음 근본적으로 단순화 한 다음 다시 디버깅하는 작업)이 포함되었습니다.

출시 시간이 최우선이라면 간단하고 실용적인 접근 방식을 사용하는 것이 좋습니다. 재사용 성을 고려하지 말고 배운 내용을 염두에두고 다음 프로젝트에서 리팩토링하고 여기저기서 코드를 재사용하고 수정하십시오. 결국 모든 경험의 합계는 API 작동 방식과 API가 제공하는 내용에 대한 명확한 비전으로 구체화 될 수 있습니다. 아직 거기에 있지 않다면 프로젝트 예산의 일부가되도록 노력하고 안정적인 타사 API를 최대한 많이 재사용하십시오.

긴 응답에 대해 죄송합니다. 일반 API 또는 프레임 워크를 구축하는 것과 같은 단계에 들어간 것 같았습니다. 그런 일들은 시간, 지식, 집안일, 장기적인 헌신이 필요하며 대부분의 시간 낭비입니다.

앱의 오프라인 사용을 허용하고 네트워크 트래픽을 최소화하기 위해 특정 캐싱 시나리오를 처리하려는 경우 물론 해당 기능을 구현할 수 있습니다. 요청에서 if-modified-since 헤더를 설정하고, 마지막으로 수정 된 헤더 또는 etag를 검사하고, 해당 정보를 지속성 엔터티에 유지하여 나중에 요청에서이 정보를 다시 제출할 수 있도록합니다. 물론 동일한 HTTP 헤더를 사용하여 이미지와 같은 리소스를 로컬로 (영구적으로) 캐싱하는 것도 좋습니다.

서버 측 서비스를 (REST 방식으로) 수정할 수있는 사치가있는 경우, 잘 구현하면 괜찮습니다 (경험상 네트워크 / 파싱 코드의 3/4까지 절약 할 수 있음). 서비스가 제대로 작동하는 경우 iOS 측 (적절한 HTTP 상태 코드 반환, nil 검사 방지, 문자열, 날짜의 숫자 변환, 암시 적 문자열 대신 조회 ID 제공 등).

그런 사치가 없다면 그 서비스가 적어도 REST-ful (많은 도움이 됨)이거나 클라이언트 측 문제를 해결해야 할 것입니다 (종종 고통 스럽습니다).


내 앱의 서버 캐싱 측면을 리팩토링하기에는 프로젝트에서 너무 멀기 때문에 시도 할 수없는 솔루션이 있지만 여전히 답을 찾고있는 사람들에게 유용해야합니다.

http://restkit.org/

내가 한 일을 정확히 수행하지만 내가 한 것보다 훨씬 더 추상화되어 있습니다. 거기에 매우 통찰력있는 것들. 누군가에게 도움이되기를 바랍니다!


나는 그것이 유효한 접근이라고 생각합니다. 나는 이것을 여러 번했다. 까다로운 부분은 동기화를 처리해야 할 때입니다. 클라이언트와 서버가 동시에 모든 것을 변경할 수있는 경우입니다. 이를 위해 거의 항상 앱별 병합 로직이 필요합니다.

참조 URL : https://stackoverflow.com/questions/4878586/core-data-on-client-ios-to-cache-data-from-a-server-strategy

반응형