AAC (안드로이드 아키텍쳐 컴포넌트)를 접하면서 자연스럽게 아키텍쳐에 대해 공부하고 싶다는 생각이 들었다. 무지성으로 사용했던 Repository 나 LiveData 의 사용 이유부터 여러 블로그와 깃헙들을 떠돌며 눈팅했던 코드들의 foldering 구조에서 보이는 미묘한 공통점에 대해서도 의문을 가지게 되면서 유기적으로 안드로이드 권장 아키텍쳐에 대해 공부할 수 밖에 없었던 것 같다. 💡 왜 공식 권장 아키텍쳐를 사용하는가? 사용자의 모바일 환경은 굉장히 유동적이다. 예를 들어 사용자가 SNS앱에서 사진을 업로드 하기 위해 사진 촬영을 하거나 앨범에 접근할 땐 카메라, 앨범 앱이 실행되면서(직접 구현하지 않는 이상...) 기존의 앱이 중단된다. 또 그러다 갑자기 전화가 울리면 사용자는 잠시동안 전화 ..
AAC ViewModel 안드로이드 앱에서 화면 전환, 화면 크기 변경, 언어설정, 키보드 숨김 변경 등의 경우 configuration change(구성 변경) 이 일어난다. 이때 Activity/Fragment 에서 일시적으로 onDestory() 되었다가 다시 onCreate() 되면서 화면이 다시 그려지게 된다. 그렇기 때문에 어떤 data가 뷰를 통해 보여주고 있었다면 data 가 초기화 되는 현상이 발생할 수 있다. 이를 방지하기 위해서는 화면이 다시 그려져도 data가 보존될 수 있도록 해야 하는데 그 방법도 다양하다. SharedPreference를 사용해 전역적으로 저장하거나 DB 등을 이용할 수도 있고, 일반적으로는 onSaveInstanceState() 메서드를 사용해 destroy ..
요즘 기업에서 안드로이드 직군 자격요건&우대사항을 뒤져보면 MVVM을 다루본 개발자를 찾는 경우가 많은데 트민녀인 나는 또 그냥 지나칠 수가 없었다ㅎㅎ 또 작년엔 디자인패턴 공부도 열심히 했기 때문에 새로운 패턴에 관심도 많이 갔다. 그런데 MVC 패턴도 제대로 써본 적 없는 내가 글만 보고 MVVM 패턴을 단박에 이해하기란 쉽지 않았다. 그래서 MVVM 관련 블로그도 있는대로 찾아서 읽고 또 읽었고, 블로그 코드들을 참고하며 냅다 프로젝트에 적용해 보았다. 그러다 크나큰 실수를 저지르게 되었는데.... 바로 사실 내가 MVVM 패턴을 사용한 것이 아니라 단지 AAC의 ViewModel을 사용했다는 것이다. 아마 나같은 실수를 하는 사람이 굉장히 많을 것이다. 많은 블로그에서 정확하게 명명하고 있지 않기..
이전에 객체를 전달하기 위해 Parcelable을 상속받아 Parcelable객체를 만들어 사용하는 방법에 대해서 포스팅했었다. Parcelable을 사용하는 이유는 객체 전달시 객체 직렬화 필요하기 때문인데 직렬화는 객체가 갖고 있는 다양한 변수들을 하나의 Byte 별 형태로 만드는 작업이라고 배웠다. Parcelable 인터페이스를 상속받고 메서드 오버라이딩을 통해 객체 -> Parcel, Parcel -> 객체 의 변환 과정을 명시적으로 구현 한다. 그런데 새로운 프로젝트를 진행하며 retrofit을 사용하게 되었고 자연스럽게 객체를 송수신하기 위해서 직렬화와 관련된 기술에 대해 더 찾아보던 중 Serializable에 대해서 알게 되었다. Serializable 표준 JAVA 인터페이스 내부적으로..