본문 바로가기

iOS 개발/App 개발 관련

 (12)
[iOS] 최고의 디자인 패턴, MVC 에 대한 오해 https://medium.com/flawless-app-stories/the-only-viable-ios-architecture-c42f7b4c845d The only viable iOS architecture Deep dive into MVC, MVVM, MVP, VIPER as a result of which we’ll understand that for iOS there is only one possible among them. medium.com MVC Model 은 "data", View 는 유저가 보는 것, Controller 는 중개자 역할. Controller 는 Model 에서 데이터를 받아 View 를 통해 User 에게 보여주거나, User 의 동작을 View 에서 받아와 Model..
[iOS] 어떤 클로저에 [weak self] 해야 할까? 이전 포스팅을 통해 강한 참조 순환이 생기는 이유와 해결 방법을 알아보았다. 특히 클로저와 클래스 인스턴스 사이에 생기는 참조 순환은 일상적으로 발견하기 쉬운데 self 를 캡처하는 모든 클로저가 메모리 누수를 일으키는 것은 아니다. 이번 포스팅을 통해 어떤 클로저가 실제 메모리 누수를 일으키는지, 따라서 [weak self] 를 작성해야 하는지 확인해보자. non-escaping vs. escaping 클로저 클로저에는 크게 두 가지 분류가 있는데, 이름에서 알 수 있듯 어딘가로 탈출할 것 같은 클로저와 그렇지 않은 클로저이다. non-escaping 클로저 어디 가지 않고 있을 것 같은 이름의 클로저 즉, 선언되는 즉시 실행된다. 프로퍼티에 저장되거나 추후에 실행되거나 하는 일이 없다. 컴파일러는 n..
[iOS] 강한 참조 순환(Retain Cycle), 참조 순환 해결하기 Swift Document - Automatic Reference Counting 클래스 객체 간의 강한 참조 순환 (Strong Reference Cycle, Retain Cycle) 두 객체가 서로에 대한 참조를 멤버로 가진 상태에서 각 객체에 대한 참조가 모두 할당 해제 되어도 서로를 참조하는 멤버의 참조는 여전히 유효하기 때문에 접근하지도 못하는 두 객체가 메모리에 남아있게 되는 메모리 누수 현상이다. 두 객체가 메모리에 남는 이유는 Swift 의 ARC 즉, 자동 참조 카운트 때문인데 Swift 는 어떤 객체가 누군가에 의해 참조되고 있음을 카운팅하고 이것이 0 이 되었을 때 메모리에서 해제한다. 따라서 두 객체의 멤버가 서로를 참조하기 때문에 메모리에서 해제되지 않는다. 객체 간의 참조 순환 ..
[iOS] Architecture patterns(MVC,MVP,MVVM) 1.설계를 생각해야 하는 이유. -큰 규모의 소프트웨어를 제작할때, 설계 구조를 생각하지 않으면 관리가 어렵다.(버그를 찾기 힘들다..) → 즉, 소프트웨어를 이해하기 좋고, 분리되어 있어 테스트가 용이하며, 각각을 재사용할 가능성이 생긴다. 2.좋은 설계란? -기능의 책임이 균형있게 분산된 설계. -테스트가 용이한 설계. -사용이 쉽고, 유지 비용이 적은 설계. 3.Model? View? Controller(Presenter,ViewModel)? -Model: data에 접근,수정하는 계층. Domain data에 대한 책임이 있다. -View: 표현 계층에 대한 책임.(ios 개발 시 'UI'로 시작하는 것들!) -Controller(Presenter,ViewModel): View와 Model 사이를..

티스토리툴바