React Native를 사용할 때 데이터를 저장하기 위한 옵션은 무엇입니까? (iOS 및 Android)
저는 리액트 네이티브 세계, 그리고 일반적으로 모바일/네이티브 세계에서도 아직 초보이며, 데이터 지속성과 관련하여 문서화가 다소 부족하다는 것을 알게 되었습니다.
React Native에 데이터를 저장하기 위한 옵션과 각 유형의 영향은 무엇입니까?예를 들어, 로컬 스토리지와 비동기 스토리지가 있지만 Realm과 같은 것도 보입니다. 외부 데이터베이스에서 이 모든 것이 어떻게 작동하는지 혼란스럽습니다.
구체적으로 알고 싶은 것은 무엇입니까?
- 데이터 지속성을 위한 다양한 옵션은 무엇입니까?
- 각각의 경우 이러한 지속성의 한계는 무엇입니까(즉, 데이터를 더 이상 사용할 수 없는 경우)?예를 들어, 응용 프로그램을 닫을 때, 전화기를 다시 시작하는 등의 작업을 수행합니다.
- 각각 iOS와 Android에서 구현하는 것 사이에 차이점이 있습니까(일반 설정 제외)?
- 오프라인에서 데이터에 액세스할 때 옵션을 비교하는 방법은 무엇입니까?(또는 오프라인 액세스는 일반적으로 어떻게 처리됩니까?)
- 제가 기억해야 할 다른 고려해야 할 사항이 있습니까?
도와주셔서 감사합니다!
몇 가지 현재 앱 프로젝트를 진행하는 최선의 방법을 결정하면서 배운 내용은 다음과 같습니다.
비동기 스토리지(이전에는 React Native의 "기본 제공", 현재는 자체적으로 이동됨)
운영 중인 앱에 비동기 스토리지를 사용합니다.스토리지는 장치에 로컬로 유지되고 암호화되지 않으며(다른 답변에서 언급한 바와 같이) 앱을 삭제하면 제거되지만 장치 백업의 일부로 저장되어야 하며 업그레이드 중에도 유지됩니다(기본 업그레이드(TestFlight 및 CodePush를 통한 코드 업그레이드).
결론:로컬 스토리지. 사용자가 직접 동기화/백업 솔루션을 제공합니다.
SQLite
제가 작업한 다른 프로젝트들은 앱 저장을 위해 sqlite3를 사용했습니다.이를 통해 장치와 주고받을 수 있는 압축 가능한 데이터베이스를 통해 SQL과 같은 환경을 제공합니다.백엔드로 동기화한 경험은 없지만 다양한 라이브러리가 존재한다고 생각합니다.SQLite에 연결하기 위한 RN 라이브러리가 있습니다.
데이터는 기존 데이터베이스 형식으로 저장되며 데이터베이스, 테이블, 키, 인덱스 등은 모두 이진 형식으로 디스크에 저장됩니다.SQLite 드라이버가 있는 명령줄 또는 앱을 통해 데이터에 직접 액세스할 수 있습니다.
결론:로컬 스토리지. 사용자가 동기화 및 백업을 제공합니다.
파이어베이스
Firebase는 무엇보다도 클라이언트 1개에서 n개까지 동기화할 수 있는 JSON 문서 저장소(MongoDB 등)와 함께 실시간 noSQL 데이터베이스를 제공합니다.문서는 오프라인 지속성에 대해 설명하지만 네이티브 코드(Swift/Obj-C, Java)에 대해서만 설명합니다.React Native에서 사용하는 Google의 자체 JavaScript 옵션("Web")은 캐시된 스토리지 옵션을 제공하지 않습니다(아래 2/18 업데이트 참조).라이브러리는 웹 브라우저가 연결되고 반영구적인 연결이 있을 것이라는 가정 하에 작성됩니다.Firebase 스토리지 호출을 보완하기 위해 로컬 캐싱 메커니즘을 작성하거나 기본 라이브러리와 React Native 사이에 브리지를 작성할 수 있습니다.
업데이트 2/2018 이후 저는 iOS 및 Android 라이브러리에 호환되는 JavaScript 인터페이스를 제공하는 React Native Firebase를 찾았습니다(Google이 할 수 있었거나 했어야 했던 일을 함). React Native 지원의 보너스와 함께 네이티브 라이브러리의 모든 장점을 제공합니다.구글이 실시간 데이터베이스 외에 JSON 문서 저장소를 도입함에 따라, 저는 파이어베이스에 제가 구축할 예정인 실시간 앱들을 잘 재검토하고 있습니다.
실시간 데이터베이스는 JSON과 유사한 트리로 저장되어 웹 사이트에서 편집하고 쉽게 가져오기/내보낼 수 있습니다.
결론:RN은 리액트 네이티브 파이어베이스를 통해 Swift 및 Java와 동일한 이점을 제공합니다.[/update] 네트워크에 연결된 장치에 맞게 잘 확장됩니다.낮은 활용률을 위한 낮은 비용.다른 Google 클라우드 오퍼링과 원활하게 결합됩니다.인터페이스에서 데이터를 쉽게 볼 수 있고 편집할 수 있습니다.
왕국
업데이트 4/2020 MongoDB가 Realm을 인수하여 MongoDB Stitch와 결합할 예정입니다(아래 설명).이것은 매우 흥미로워 보입니다.
2020년 9월 업데이트 영역을 사용한 적이 있는 경우와스티치: 스티치 API는 기본적으로 JS 앱(리액트 네이티브 또는 웹)이 직접 빌드하는 API 서버를 거치지 않고 Mongo 데이터베이스와 직접 대화할 수 있도록 했습니다.
영역은 변경될 때마다 데이터베이스의 일부를 동기화하기 위한 것이었습니다.
둘의 조합이 조금 헷갈립니다.이전에 스티치로 알려진 API는 여전히 전통적인 Mongo 쿼리 및 업데이트 호출처럼 작동하는 반면, 새로운 Realm 스탭은 코드의 객체에 부착되어 동기화를 혼자 처리합니다.주로.저는 여전히 Swift를 사용하는 하나의 프로젝트에서 올바른 방법으로 작업하고 있습니다.UI, 그래서 주제에서 좀 벗어났습니다.그럼에도 불구하고 유망하고 깔끔합니다.
또한 자동 매직 네트워크 동기화 기능을 갖춘 실시간 객체 저장소입니다.그들은 스스로를 "장치 우선"이라고 선전하며 데모 비디오는 장치가 산발적이거나 손실된 네트워크 연결을 처리하는 방법을 보여줍니다.
사용자의 서버나 AWS 또는 Azure와 같은 클라우드 솔루션에서 호스팅하는 개체 저장소의 무료 버전을 제공합니다.또한 장치와 지속되지 않는 메모리 내 저장소, 서버와 동기화되지 않는 장치 전용 저장소, 읽기 전용 서버 저장소 및 하나 이상의 장치 간 동기화를 위한 전체 읽기-쓰기 옵션을 만들 수 있습니다.그들은 Firebase보다 한 달에 더 많은 선불 비용이 드는 전문가 및 엔터프라이즈 옵션을 제공합니다.
Firebase와 달리 모든 Realm 기능은 Swift/ObjC/Java(네이티브) 앱에서와 마찬가지로 React Native 및 Xamarin에서 지원됩니다.
데이터가 코드의 개체에 연결되어 있습니다.정의된 개체이기 때문에 스키마가 있으며 버전 제어는 코드 무결성을 위해 필수입니다.Realm이 제공하는 GUI 도구를 통해 직접 액세스할 수 있습니다.장치 내 데이터 파일은 플랫폼 간에 호환됩니다.
결론:장치 우선, 무료 및 유료 요금제와의 선택적 동기화.모든 기능은 React Native에서 지원됩니다.수평 확장은 Firebase보다 더 비쌉니다.
아이클라우드
저는 솔직히 이것을 가지고 노는 것을 많이 하지 않았지만, 가까운 미래에 그렇게 할 것입니다.
CloudKit를 사용하는 기본 앱이 있는 경우 CloudKit JS를 사용하여 웹 앱(또는 React Native의 경우)에서 앱의 컨테이너에 연결할 수 있습니다.이 시나리오에서는 기본 iOS 앱과 React Native Android 앱이 있을 것입니다.
Realm과 마찬가지로 데이터를 로컬에 저장하고 가능한 경우 iCloud에 동기화합니다.앱을 위한 공용 상점과 각 고객을 위한 개인 상점이 있습니다.고객은 자신의 스토어 또는 객체 중 일부를 다른 사용자와 공유하도록 선택할 수도 있습니다.
원시 데이터에 액세스하는 것이 얼마나 쉬운지 모르겠습니다. 애플 사이트에서 스키마를 설정할 수 있습니다.
결론: Apple 대상 앱에 적합합니다.
카우치베이스
거물급 기업들이 뒤를 잇고 있습니다.표준 지원 비용이 포함된 Community Edition과 Enterprise Edition이 있습니다.
그들은 사이트에 리액트 네이티브에 접속하기 위한 튜토리얼을 가지고 있습니다.저도 이 제품에 많은 시간을 투자하지는 않았지만 기능 면에서 Realm의 실행 가능한 대안으로 보입니다.저는 당신이 만든 앱이나 API 밖에서 당신의 데이터에 접근하는 것이 얼마나 쉬운지 모릅니다.
[편집: Couchbase와 CouchDB에 대해 이야기하는 오래된 링크를 찾았고, CouchDB는 고려해야 할 또 다른 옵션일 수 있습니다.두 제품은 역사적으로 관련이 있지만 현재는 완전히 다른 제품입니다.이 비교를 참조하십시오.]
결론:영역과 비슷한 기능을 가지고 있는 것 같습니다.장치 전용이거나 동기화될 수 있습니다.한번 해봐야 겠어요.
몽고DB
2020년 4월 업데이트
Mongo는 Realm을 인수했으며 MongoDB Stitch(아래에서 설명함)를 Realm(위에서 설명함)과 결합할 계획입니다.
로컬에서 비동기 스토리지를 사용하는 앱의 일부에 대해 이 서버 쪽을 사용하고 있습니다.저는 모든 것이 JSON 객체로 저장되어 클라이언트 장치로의 전송이 매우 간단하다는 점을 좋아합니다.제 사용 사례에서는 TV 가이드 데이터의 업스트림 공급자와 클라이언트 장치 간의 캐시로 사용됩니다.
스키마와 같은 데이터에 대한 하드 구조가 없으므로 모든 개체는 쉽게 검색하고 필터링할 수 있는 "문서"로 저장됩니다.유사한 JSON 개체에는 추가적인(그러나 다른) 특성이나 하위 개체가 있을 수 있으므로 개체/데이터를 구성하는 방법에 많은 유연성이 있습니다.
클라이언트와 서버 간 동기화 기능을 사용해 본 적이 없으며 내장된 기능도 사용하지 않았습니다.MongoDB에 대한 대응 네이티브 코드가 존재합니다.
결론:로컬 전용 NoSQL 솔루션, Realm 또는 Firebase와 같은 명확한 동기화 옵션 없음.
2019년 2월 업데이트
MongoDB에는 Stitch라는 "제품"(또는 서비스)이 있습니다.클라이언트(웹 브라우저 및 전화기의 의미에서)는 MongoDB와 직접 대화할 수 없기 때문에(서버의 코드로 수행됨) 호스팅된 솔루션(Atlas)을 사용하기로 선택하면 앱이 인터페이스할 수 있는 서버 없는 프런트 엔드를 만들었습니다.문서를 보면 가능한 동기화 옵션이 있는 것처럼 보입니다.
2018년 12월에 작성된 이 문서에서는 샘플 앱에서 React Native, Stitch 및 MongoDB를 사용하는 방법과 문서(https://www.mongodb.com/blog/post/building-ios-and-android-apps-with-the-mongodb-stitch-react-native-sdk) 에 링크된 다른 샘플에 대해 설명합니다.
트윌리오 동기화
동기화를 위한 또 다른 NoSQL 옵션은 Twilio의 Sync입니다.사이트: "Sync를 사용하면 백엔드 인프라를 처리하지 않고도 원하는 수의 장치에서 실시간으로 상태를 규모에 맞게 관리할 수 있습니다.
저는 특히 양 팀과 이야기를 나눈 후 위에서 언급한 프로젝트 중 하나에 대한 Firebase의 대안으로 이것을 보았습니다.저는 또한 그들의 다른 의사소통 도구를 좋아하며, 간단한 웹 앱에서 문자 업데이트에 사용했습니다.
[편집] 저는 이 글을 처음 쓸 때부터 Realm과 함께 시간을 보냈습니다.파이어베이스와 마찬가지로 앱과 서버 간의 데이터 동기화를 위해 API를 작성하지 않아도 되는 점이 마음에 듭니다.또한 서버리스 기능은 이 두 가지에 매우 유용하여 제가 작성해야 하는 백엔드 코드의 양을 제한합니다.
저는 MongoDB 데이터 저장소의 유연성을 좋아하기 때문에 웹 기반 및 기타 연결에 필요한 앱의 서버 측면에서 그것이 제 선택이 되고 있습니다.
저는 MongoDB에 대해 매우 간단하고 확장 가능한 RESTful API를 만드는 RESTHeart를 찾았습니다.JSON 개체를 읽고 RESTHeart에 쓰는 React(Native) 구성 요소를 구축하는 것은 그리 어렵지 않을 것입니다. RESTHeart는 이를 MongoDB로 전달합니다.
[편집] 데이터 저장 방법에 대한 정보를 추가했습니다.데이터를 수정하고 테스트해야 하는 경우 개발 및 테스트 중에 얼마나 많은 작업이 필요한지 아는 것이 중요합니다.
Edits 2/2019 저는 작년(2018)에 고동시성 프로젝트를 설계할 때 이 옵션들 중 몇 가지를 실험했습니다.그들 중 일부는 문서에서 하드 및 소프트 동시성 한계를 언급합니다(AltConf에서 양 팀과 논의한 바에 따르면 Firebase는 10,000개의 연결에서 하드 동시성 한계를 가지고 있었지만 Twilio는 충돌할 수 있는 소프트 한계였습니다).
수만에서 수십만 명의 사용자를 위해 앱을 설계하는 경우, 그에 따라 데이터 백엔드를 확장할 수 있도록 준비해야 합니다.
빠르고 더티: 반응 네이티브를 위해 Redux + react-redux + redux-perist + AsyncStorage를 사용하면 됩니다.
그것은 거의 완벽하게 반응하는 자연계에 맞고 안드로이드와 iOS 모두에게 매력적으로 작동합니다.또한, 그 주변에는 견고한 공동체가 있고, 많은 정보가 있습니다.
작업 예제는 Facebook의 F8 App을 참조하십시오.
데이터 지속성을 위한 다양한 옵션은 무엇입니까?
반응 네이티브의 경우에는 redux 및 redux-perist를 사용할 수 있습니다.여러 스토리지 엔진을 사용할 수 있습니다.비동기 스토리지 및 redux-perist-file system-storage는 RN에 대한 옵션입니다.
Firebase나 Realm과 같은 다른 옵션들이 있지만, 저는 RN 프로젝트에서 그것들을 사용한 적이 없습니다.
각각의 경우 이러한 지속성의 한계는 무엇입니까(즉, 데이터를 더 이상 사용할 수 없는 경우)?예를 들어, 응용 프로그램을 닫을 때, 전화기를 다시 시작하는 등의 작업을 수행합니다.
redux + redux-perist를 사용하여 지속되는 항목과 지속되지 않는 항목을 정의할 수 있습니다.지속되지 않으면 앱이 실행되는 동안 데이터가 존재합니다.지속되면 앱 실행(닫기, 열기, 전화 다시 시작 등) 간에 데이터가 유지됩니다.
Android에서 비동기 스토리지의 기본 제한은 6MB입니다.Java 코드에서 더 큰 제한을 구성하거나, Android용 스토리지 엔진으로 redux-perist-file system-storage를 사용할 수 있습니다.
각각 iOS와 Android에서 구현하는 것 사이에 차이점이 있습니까(일반 설정 제외)?
redux + redux-perist + AsyncStorage를 사용하면 Android와 iOS에서 설정이 완전히 동일합니다.
오프라인에서 데이터에 액세스할 때 옵션을 비교하는 방법은 무엇입니까?(또는 오프라인 액세스는 일반적으로 어떻게 처리됩니까?)
redux를 사용하면 설계 부품(작업 작성자 및 축소자) 덕분에 파일 액세스가 거의 자동화됩니다.
가져온 데이터와 저장한 모든 데이터를 사용할 수 있으며, 추가 데이터를 쉽게 저장하여 상태(페칭, 성공, 오류)와 가져온 시간을 나타낼 수 있습니다.일반적으로 가져오기를 요청해도 이전 데이터는 무효화되지 않으며 새 데이터가 수신될 때 구성 요소가 업데이트됩니다.
다른 방향에서도 마찬가지입니다.서버로 보내는 데이터 중 아직 보류 중인 데이터를 저장하고 그에 따라 처리할 수 있습니다.
제가 기억해야 할 다른 고려해야 할 사항이 있습니까?
리액트는 앱을 만드는 사후 대응적인 방법을 촉진하며, 리덕스는 앱에 매우 적합합니다.일반 Android 또는 iOS 앱에서 사용할 옵션을 사용하기 전에 사용해 보아야 합니다.또한, 여러분은 그것들을 위한 훨씬 더 많은 문서와 도움을 찾을 수 있을 것입니다.
위의 사람들은 스토리지에 대한 올바른 정보를 얻지만, 저장해야 할 PII 데이터도 고려해야 할 경우 ASyncStorage가 암호화되지 않으므로 https://github.com/oblador/react-native-keychain 와 같은 것을 사용하여 키 체인에 저장할 수도 있습니다.redux-persist와 같은 지속성 구성의 일부로 적용할 수 있습니다.
우리는 redux-peristent가 필요하지 않습니다. 단순히 redux를 사용하여 저항할 수 있습니다.
react-redux + AsyncStorage = redux-readcision
그래서 내부에 있는 createotre 파일은 단순히 이 선들을 추가합니다.
store.subscribe(async()=> await AsyncStorage.setItem("store", JSON.stringify(store.getState())))
그러면 redux 저장소에 변경 사항이 있을 때마다 AsyncStorage가 업데이트됩니다.
그런 다음 변환된 저장소에 json을 로드합니다.앱이 로드될 때마다그리고 다시 가게를 세웠습니다.
redux-perist는 wix react-native-navigation을 사용할 때 문제가 발생하기 때문입니다.만약 그렇다면 나는 위의 가입자 기능이 있는 단순한 리듀스를 사용하는 것을 선호합니다.
비동기 스토리지보다 사용하기 쉬운 동기 스토리지를 사용할 수 있습니다.이 라이브러리는 비동기식 스토리지를 사용하여 데이터를 비동기식으로 저장하고 메모리를 사용하여 데이터를 즉시 동기식으로 로드 및 저장하는 기능이 뛰어나므로 데이터를 비동기식으로 메모리에 저장하고 앱 동기식으로 사용할 수 있습니다.
import SyncStorage from 'sync-storage';
SyncStorage.set('foo', 'bar');
const result = SyncStorage.get('foo');
console.log(result); // 'bar'
복잡한 데이터 유형을 관리하려는 경우 Realm 또는 Sqlite를 사용할 수 있습니다.
그렇지 않은 경우 내장된 반응형 비동기 스토리지와 함께 사용할 수 있습니다.
언급URL : https://stackoverflow.com/questions/44376002/what-are-my-options-for-storing-data-when-using-react-native-ios-and-android
'programing' 카테고리의 다른 글
| Angular 2 azure 배포 새로 고침 오류: 찾고 있는 리소스가 제거되었거나 이름이 변경되었거나 일시적으로 사용할 수 없습니다. (0) | 2023.05.04 |
|---|---|
| ABC를 사용하는 것과 ABC를 사용하는 것 사이에 차이점이 있습니까? (0) | 2023.05.04 |
| 스택 생성 날짜 가져오기 (0) | 2023.05.04 |
| if-statement에서 파이썬의 &&(논리적-and)에 해당하는 것은 무엇입니까? (0) | 2023.05.04 |
| 고유 값을 카운트하는 단순 피벗 테이블 (0) | 2023.05.04 |