배열 변수를 AppDelegate 클래스에 저장하는 이유 (세 가지 이슈)

세 가지 이슈 - 접근성, 데이터 보존 그리고 일관성.

 

memolist 배열은 앱의 여러 객체가 참조하는 공유 데이터. - 일종의 공용 저장소.

따라서 memolist 배열은 뷰 컨트롤러나 객체가 접근하기 쉬운 위치에 저장되어야 한다.

또한 사용 중간에 메모리 관리 이슈나 객체 소멸로 인해 데이터가 삭제되지 않아야 하며,

여러 곳에서 사용하더라도 일관성을 유지할 수 있어야 하며, 파편화되거나 쪼개지지 않아야 한다.

글 작성 화면에서 사용하는 데이터 객체와 등록한 글의 목록에서의 객체가 일치하지 않으면 문제가 생길 수 있다.

 

이런 조건을 충족시키는 저장소로는 뷰 컨트롤러는 적당하지가 않다. 

간단히 이유를 들어보자면,

뷰 컨트롤러는 생명 주기가 길지가 않아서, 사용자가 화면 전환시 소멸하기 때문이다.

또한 초기 화면 역할을 하는 목록 뷰 컨트롤러 또한 거의 사라지지 않는다고 생각할 수 있겠지만, 

완벽하게 보호되는 것은 아니다.

 

또한 컨트롤러 클래스는 하나 이상의 인스턴스가 생성될 가능성이 존재한다.

스토리 보드에 N개의 뷰 컨트롤러가 모두 동일한 클래스 A에 연결되어 있다면 N개의 인스턴스 A가 생성될 수 있습니다.

즉, memolist의 배열이 여러개가 존재할 가능성이 생기는 것입니다. 

이 경우 어느 인스턴스에 데이터를 저장해야할 지 쉽지 않을 것입니다.

 

또한 특정 뷰 인스턴스의 인스턴스를 참조하는 방법도 고민해 보아야 할 문제이며,

여러 이유로 전역 변수를 정의하기에 적당하지 않습니다.

 

따라서 AppDelegate 클래스에 전역 변수를 저장하기에 적당합니다.

왜냐하면 이 클래스는 앱 전체의 라이프 사이클을 ㅍ관리하는 역할을 하기 때문에 앱 내에서 반드시 하나의 인스턴스만 존재하도록 OS적으로 보장되어 있을 뿐만 아니라, 어디서든 쉽게 접근할 수 있습니다. 중복될 가능성도 전혀 없으며 뷰 컨트롤러가 참조하기도 쉽습니다.

 

또한 AppDelegate의 생명 주기는 앱 자체의 생명 주기와 함께함으로 도중에 소멸된 가능성도 없으며, 데이터 유실을 걱정하지 않아도 됩니다.

 

그럼에도 불구하고, AppDelegate에 저장하는 것이 완벽한 해결책은 아닙니다.

AppDelegate 객체에 저장되는 데이터는 어디까지나 메모리에 저장되기 때문에, 앱이 실행되는 동안에만 데이터가 유지됩니다.

다시 말해 앱이 종료되면 저장된 데이터 역시 사라진다

한번 생성된 데이터는 앱을 종료하더라도 영속적으로 보존되어야 하는 메모 앱의 특성상 충분히 큰 문제이다.

따라서 이후 데이터 저장이란 주제로 다뤄보자

 

Firebase 등도 있고 UserDefault?? - 스터디에 올려주신 부분인데 데이터 다루는 부분이 너무 약하다 ㅠ__ㅠ

파 이 팅 ^__^