|
| 1 | +# TIL |
| 2 | + |
| 3 | +## 배운 것 |
| 4 | + |
| 5 | +#### 주요 내용: FileManager, Migration, Transaction |
| 6 | + |
| 7 | +* ImagePickerController, PHPickerController |
| 8 | + - iOS14 이전: ImagePickerController 1) 촬영 2) 갤러리 3) 갤러리 저장 => 사진 한장만 가능 |
| 9 | + - iOS14 이후: PHPickerController(PhotoKit) 1) 갤러리 => 촬영에 대한 것은 ImagePickerController => 사진 여러장 가능 |
| 10 | + - PHPickerController는 좀 더 섬세하게 컨트롤 가능(라이브포토만 가져오기, 비디오만 가져오기 등) |
| 11 | + |
| 12 | +* 사진을 저장하는 방법 |
| 13 | + 1. 갤러리 링크(String) : 사진을 저장하지 않고 단순히 보여주는 용도로 사용 => 갤러리가 달라질 수 있다는 가능성이 존재함. 앱에서는 이 사실을 알 수 없음 |
| 14 | + 2. default.realm이라는 테이블 안에 사진을 저장 (png -> data 변환하여 저장) : 난이도는 낮지만 용량의 제한이 있어 많은 이미지 저장할 수 없고, data 변환이 필요 |
| 15 | + 3. 파일 매니저(image를 그 자체로 저장) : 앱의 도큐먼트 폴더 안에 사진을 저장함 |
| 16 | + |
| 17 | +* 저장 순서 |
| 18 | + 1. 도큐먼트 위치를 알아냄 |
| 19 | + 2. 경로를 생성하고 |
| 20 | + 3. 경로에 이미지를 저장 |
| 21 | + |
| 22 | +* 이미지 저장 시 생각해야 할 것 |
| 23 | + 1. Realm에 데이터가 삭제된다면(메모), 사진도 함께 삭제해주어야 함. |
| 24 | + 2. 그렇기 때문에 사진과 데이터는 연관되는 값을 가지고 있어야 함(PK나 별도 구분이 가능한 값으로 이미지의 경로를 DB에 저장해놓고 있어야 함) |
| 25 | + 3. 이미지를 삭제하지 않으면, 그 용량이 그대로 쌓여서 앱 용량도 함께 늘어남 |
| 26 | + |
| 27 | +* 마이그레이션 |
| 28 | + - 가급적 하지 않는게 좋고, 추후에 구현할 기능을 안다면 미리 테이블을 만들어 놓는 것이 좋음 |
| 29 | + - Linear Migration을 해야 함. 사용자가 어떤 버전을 가지고 있을 지 모르기 때문에 중간 단계를 스킵하지 않고 한 단계 씩 버전을 올려주어야 함 |
| 30 | + - 그렇기 때문에 if-else문으로 처리하지 않고 if문 만으로 마이그레이션 블록을 구성함 |
| 31 | + - 마이그레이션이 많아질 수록 계속 그 코드를 가지고 있어야 하기 때문에, 미리 사전에 테이블 구성을 잘 하는것이 필요함 |
| 32 | + |
| 33 | +* Transaction |
| 34 | + - 작업 수행의 논리적 단위(데이터 정합성) |
| 35 | + - 중간에 실행 중단 시 다시 질의를 실행하는 rollback 수행 및 실행을 마치면 commit하는 단위 |
| 36 | + |
| 37 | +* ACID |
| 38 | +- 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability) |
| 39 | +- 원자성: 작업 단위를 일부분만 실행하지 않음(All or nothing) |
| 40 | + - 이전에 commit된 상태를 임시 영역에 따로 저장(rollback Segment)하여 문제가 생기면 이 상태로 rollback |
| 41 | + - savePoint: 트랜젝션 중 확실한 부분에 대해서는 rollback되지않도록 savePoint 지정 |
| 42 | +- 일관성: 일관적인 DB상태 유지(데이터 타입의 일관성, 송금금액이 Int에서 String이 되면 안된다) |
| 43 | + - 기본키, 외래키 등의 제약조건을 통해 일관성 보장 -> 규칙에 의해서만 수정 가능 |
| 44 | + - 트리거를 통해 여러 테이블에 같은 데이터 유지될 수 있도록 함 |
| 45 | +- 격리성: 트랜젝션 수행 시 다른 트랜잭션의 작업이 끼어둘 수 없음 |
| 46 | + - Lock: 데이터를 읽거나 쓸 때 다른 트랜잭션이 접근하지 못하도록 Lock을 걸고, 수행이 끝나면 unlock을 통해 접근 가능하게 함 |
| 47 | + - 트랜잭션에 따라 접근 기준을 다르게 설정 가능: Table Lock, Column Lock, Record Lock |
| 48 | + - Shared Lock: 데이터를 읽을 때, 여러 트랜잭션에 쓰기를 허용하지 않고 읽기만 허용 |
| 49 | + - Exclusive Lock: 데이터를 쓸 때, 여러 트랜잭션이 읽고 쓸 수 없도록 함 |
| 50 | + - DeadLock: Lock, Unlock을 잘못 사용하면 아무것도 할 수 없는 상태 만들어짐 |
| 51 | +- 지속성: 성공적으로 수행된 트랜잭션이 영원히 반영(Commit) |
| 52 | + |
| 53 | +* SandBox |
| 54 | +- 앱 하나하나가 다 sandBox |
| 55 | +- Container System |
| 56 | + - Bundle Container |
| 57 | + - 앱의 번들로 inpo.plist, Resource등 그룹화 |
| 58 | + - complie source(.swift)가 바이너리형태의 실행 파일로 변환 |
| 59 | + - 라이브러리는 프레임워크로 그룹화 |
| 60 | + - 스토리보드, xib, strings등 변환 |
| 61 | + |
| 62 | + - Data Container |
| 63 | + - Documents |
| 64 | + - 개발자가 Document, Library, tmp, system Data외의 직접 디렉토리나 파일 추가 불가능 > Document의 서브디렉토리를 통해 관리 |
| 65 | + - 사용자가 앱을 통해 생성한 문서, 파일 등을 저장 |
| 66 | + - Documents 디렉토리 자체는 삭제 불가능함 |
| 67 | + - Documents 내부에는 삭제/변경되어도 무방하고 사용자가 다루는 컨텐츠와 관련된 파일만 저장 |
| 68 | + - Realm에서 중요한 정보보관을 위해 Library의 Application Support 폴더로 경로 변경해 사용하기도 함 |
| 69 | + - Library |
| 70 | + - 사용자 데이터 파일과 임시파일을 제외한 모든 파일 관리 |
| 71 | + - 사용자 노출 피하고 앱의 기능이나 관리에 필요한 파일 저장 |
| 72 | + - Library 내 caches 폴더에는 앱의 스냅샷 등이 저장(ex: 알람 사운드 등) |
0 commit comments