B_log

개요 이번 글에서는 iOS File System에 대해서 이야기해보겠습니다! 어떤 앱에서 다른 앱(또는 위젯)에 원하는 데이터를 전달하는 데에 저장소에 대한 이해가 필요해서 이 글을 쓰게 되었어요 :] 우선, 공식 문서를 기준으로(iOS를 초점으로) 저장 시스템의 기본을 이해해볼게요! File System이란? Apple 생태계의 기본 파일 시스템은 APFS로 macOS, iOS, watchOS, tvOS 파일 시스템의 기본이 돼요(iOS 10.3 이상, macOS HighSierra 이상). 여기서 파일 시스템이란 데이터 파일, 앱 및 운영체제와 관련된 파일의 저장소를 처리하는 시스템을 의미해요. 특정 데이터를 저장, 삭제, 수정하는 것처럼 파일 시스템과 상호 작용하는 코드를 작성하기 위해서는 이 시스..

1편 글에 이어서 2편 글을 이어나갈게요! SwiftUI에서 UI 업데이트하기 SwiftUI의 View에서 프로퍼티 값을 변경할 경우, @State를 마킹해서 "변경이 필요한 상태 값"이라는 것을 표시해요. UIKit의 경우 특정 객체의 상태를 변경해주기 위해 그 객체에 접근해서 메서드를 통하거나 직접 그 프로퍼티의 값을 변경했었어요. 이 과정에서 타이밍에 따라 의도하지 않은 결과가 나오거나 버그가 발생하는 등의 문제가 발생하기 쉬워서 고려해야 할 게 많아요. SwiftUI의 경우 @State로 마킹된 프로퍼티의 값이 변경될 경우, 그 뷰를 무효화(invalidate)하여 숨겼다가 body를 다시 계산해서 보여줘요. UIKit의 경우 어떤 값을 보여주다가 그 값을 갱신할 경우 기존의 UI에서 reload..

시작하기 항상 해야 하는 숙제 느낌이 있지만 막상 공부는 안 했던 SwiftUI에 대한 이야기를 해보려고 해요... 애플은 "Better Apps, Less Code"라는 말을 표방하여 SwiftUI를 설명하고 있어요. 더 적은 코드로 더 나은 앱을 개발할 수 있기 때문에 장점으로는 1. 가독성 향상 2. 앱 개발 속도 향상 3. 디버깅 유리 4. 선언형 을 꼽을 수 있어요. 하지만 최소 버전이 iOS 13이라는 점과 다양한 버그 때문에 많은 현업에서 사용은 꺼려지고 있는 것으로 알고 있어요. 그래도 언젠가 해봐야 하기 때문에 이 글을 시작으로 천천히 공부해나가려고 해요! 참고 자료는 Raywenderlich의 SwiftUI by Tutorials 입니다 :) Xcode에서 SwiftUI로 프로젝트를 생..

지난 1편에 이은 2편 글이에요! 이어서 써 내려가 볼게요 :) Views 위젯을 만들면서 신경 써야 할 View는 크게 세 가지가 있어요. 첫 번째는 지금까지 이야기했던 Placeholder이에요. 이제 살펴봐야하는 것은 Snapshot과 timeline이고요! Snapshot Snapshot의 정의는 아래와 같아요. Snapshot is where the system needs to quickly display a single entry so the expectation is for your extension to quickly return a view 스냅샷은 시스템이 single entry를 빠르게 보여줄 필요가 있을 때 extension이 빠르게 return 하는 view라고 해요. 이것만 봐서..

개요 프로젝트로 위젯을 맡게 되어 처음으로 위젯을 만들어보려고 해요. 코드를 경험하기 전, 전체적인 이해를 위해 WWDC20 # 10028 - Meet WidgetKit을 듣고 정리해보려고 해요 :) 코드에 대한 설명이라기보다 이번 세션은 위젯의 개념을 설명하는 것이 포인트였다고 생각해요. 더 자세한 설명은 추가 다른 세션을 통해 이해하고, 예시를 만들면서 구체화해볼게요 :) Widget을 간단하게 이해하기 Widgets are not mini-apps Widget은 미니 앱이 아니에요. 위젯을 이해할 때 작은 버튼들로 채워진 미니앱으로 인식하는 것이 아니라, 콘텐츠를 홈스크린에 뿌려주는 도구로 이해해야 해요. Smart Stacks Smart Stack이란 widget 묶음이 자동으로 전환되어 적합한 ..

개요 MVVM을 학습하며 GitHub에서 여러 Repository를 참고했어요. 그 과정에서, 같은 MVVM이지만 개발자의 설계에 따라 구현 구조가 크게 다른 것을 확인했어요. MVVM은 정의하기에 따라 다양한 형태를 가질 수 있기 때문에 이런 문제를 해결하기 위해 여러 회사들에서 ReactorKit을 활용한다고 들었어요. 저 역시 두 가지 프로젝트를 MVVM으로 설계하며 위의 문제를 경험했었기 때문에 ReactorKit 공식 GitHub의 README를 해석하며 전체적인 구조를 이해해보려고 해요 :) 글이 길어져서 우선 이 글에서는 기본적인 내용만 다루고, Advanced 이후 내용은 다른 글에서 추가해볼게요! Basic Concept (기본 콘셉트) ReactorKit은 Flux와 Reactive P..

개요 MVVM을 보다 잘 활용하기 위해 ReactorKit에 관한 학습을 시작한 도중에 이런 설명을 보게 되었어요. ReactorKit is a combination of Flux and Reactive Programming. 여기서 Reactive Programming은 이해할 수 있지만 Flux는 처음 들어보는 개념이었어요. 그래서 이 글에서는 ReactorKit을 이해할 수 있을 정도로만 Flux의 기초 개념을 이해해보려고 해요 :) Flux의 정의 Flux의 기본 개념을 이해하기위해 우선 Flux 공식문서를 살펴봤어요! ReactiveX처럼 첫 페이지에 가장 간단한 설명이 쓰여 있었어요. "사용자 인터페이스를 빌드하기 위한 앱 아키텍쳐"라는 의미예요. 우선 Flux라는 것이 아키텍처라는 것을 알게..

문제 해시 - 완주하지 못한 선수 문제 분석하기 굉장히 쉬운 문제예요! 머리 예열 겸 코딩 테스트 연습을 다시 풀고 있어요. 아쉽게도 지원 언어가 C++, Java, JavaScript, Python 뿐이고 Swift는 없어서, 저의 경우 Java, JavaScript, Python으로 풀었는데 이 글에서는 Python의 코드로만 설명해볼게요 :) 그리고 이 글을 쓰게 된 이유는 가장 아래 문제 풀이 고민에서 말해볼게요! 두 가지 배열이 주어지고, 앞선 배열인 participants는 반드시 뒤의 배열인 completion 보다 요소 1개를 더 가지고 있고 이 요소를 찾는 문제예요. 가장 단순하게는 participants를 for문으로 돌고, completion을 그 안에서 순회하면서 매칭 되는지 여부를..