본문 바로가기

안드로이드 기술 공유

(15)
Databinding 사용 시, 경우에 따라 View 바인딩 하는 방법 Databinding 라이브러리 사용 시, 사용되는 경우(Activity, Fragment, Adapter, CustomView...)에 따라 xml 레이아웃을 바인딩하는 방법에 차이가 있어서 간단히 정리해보았습니다. 모든 내용은, Android developers 래퍼런스의 Generated binding classes 가이드를 참고하였습니다. Activity override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val binding = DataBindingUtil.setContentView(this, layoutId) } Fragment, Adapter val binding = ListItemBin..
Android DataBinding vs Kotlin Extensions 의 XML 레이아웃 접근, 어떤 방식이 더 좋을까? MVVM 아키텍처와 코틀린을 같이 하다 보니, XML 레이아웃 뷰 접근을(findViewById) 대체할 수 있는 방식이 서로 달라서, 과연 어떤 방식으로 하는 게 좋을까? 라는 궁금증이 생겼습니다. MVVM 아키텍처를 위해 DataBinding 을 사용하고 있고, 코틀린을 위해 Kotlin Extensions를 사용하고 있다면, XML 뷰에 접근하기 위해 각자마다의 findViewById 대체 방법이 존재합니다. 우선, XML에 아래와 같은 TextView가 있다고 가정하고, 각자의 접근 방식에 대해 알아보겠습니다. [ DataBinding ] binding.textviewTitle.text = "안드로이드" [ Kotlin Extensions ] textview_title.text = "안드로이드" ..
기존 레이아웃을 데이터바인딩 레이아웃으로, 한방에 자동 변환하기! 기존 레이아웃을 데이터 바인딩으로 변환하려면, 최상단 루트(Root)를 태그로 감싸야합니다. 또한, 네임 스페이스 정의 (xmlns:로 시작하는 속성 예) xmlns:android, xmlns:app...)도 루트로 이동해야 합니다. 수동으로, 잘라내기(복사)+붙여넣기 해도 그리 복잡한 작업은 아니지만, 여러 xml파일들을 일일이 작업한다면 상당히 번거로운 작업이 될 수 있습니다. 그래서, 안드로이드 스튜디오는 이런 작업을 자동으로 수행해주는 편리한 기능을 제공해줍니다! 방법 1. 변환하기 전의 기존 레이아웃 루트에 커서를 위치시키고 2. ⌥(option) + Enter 키 (Alt + Enter for Win/Linux) 입력 후, "Convert to data binding layout" 선택 3. ..
AndroidX 로 마이그레이션 하기 개요 구글에서는 Android Support Library의 28.0.0 버전을 마지막으로, 더 이상 android.support 라이브러리의 릴리즈는 없을 것이라고 하며, 새로운 기능 개발은 모두 AndroidX 에서 이루어질 것이라고 하였습니다. AndroidX는 기존 Support 라이브러리를 완전히 대체하면서, 새롭게 추가되는 라이브러리들 까지 포함하고 있습니다. 이에 따라, 저희도 기존 support 라이브러리를 AndroidX로 마이그레이션하는 작업을 해야 합니다. 다행스럽게도, 안드로이드 스튜디오의 Refactor 기능을 사용하면, 간편하게 마이그레이션 작업을 진행 할 수 있습니다. 그렇다면, 지금부터 AndroidX로 마이그레이션하는 방법과 더불어, 이전하는 과정에서 겪을수있는 에러의 해결..
안드로이드 MVVM 아키텍처 (Android Apps Using MVVM Architecture) "아키텍처" 라는 주제는 사실 쉽게 이해하기도 힘들며, 완벽한 답안이 있는 게 아니다 보니 어떤 원칙대로 설계를 해야 하는지에 대한 모호함과 어려움이 있어서 쉽게 놓치곤 합니다. 하지만, 안드로이드 프로젝트에 적합한 아키텍처를 정의하지 않으면 코드 베이스가 커지고 팀이 확장됨에 따라 유지보수가 어려워집니다. (유지보수 : 유지하고 보수하는 것뿐만이 아니라, 가독성, 테스트, 기능 추가, 변경, 삭제, 버그 수정, 인수인계...) 그렇기 때문에, 괜찮은 방식의 아키텍처를 정하는 것에 대해 고민할 수밖에 없고 좋은 아키텍처는 개발자에게 명확한 프로젝트 가독성과 더 큰 효율과 생산성을 가져다준다고 생각합니다. 여기서 설명드릴 MVVM 아키텍처는 우리에게 가장 좋은 래퍼런스가 되는 Google Android A..
코틀린 전환과 같이하면 좋은 선행작업! 코틀린 전환의 선행작업 코틀린 전환을 시작하면서, 코틀린 전환에 효과적인 선행작업은 무엇이 있을까? 라는 생각을 해보았습니다. 단순히 자바를 코틀린으로 바꾼다면 그저 문법 변환에 그치고, 결과적으론 기존 래거시와 동일한 프로젝트 구조에 문법만 코틀린인채로 남을 것 같다는 생각이 들었습니다. 그렇기 때문에, 코틀린 전환을 하기에 앞서, 아키텍처를 선정하여 잡아놓고 시작한다면, 구조적으로 유리할뿐만 아니라, 유지보수와 테스트에도 용이하며, 코틀린 언어의 특성을 최대한 활용할 수 있고, 결과적으로는, 앱의 구조가 튼튼해져서 훨씬 더 성공적인 코틀린 전환이 될 수 있을것 같다고 생각하였습니다. 그럼 아키텍처 정의에 앞서, 코틀린 전환과 아키텍처 선정에 큰 도움이 될 수 있는 AndroidX 라이브러리를 먼저 살..
Firebase Crashlytics를 Slack과 연동하여, 실시간 버그 리포트 알림받기 팀 내에서, 앱 크래시 툴로 사용하던 Fabric Crashlytics가 Firebase로 인수되면서 Firebase의 Crashlytics로 마이그레이션 하는 작업을 진행하였습니다. 이 과정에서, Firebase Crashlytics를 Slack과 연동하여 특정 Slack 채널로 버그 리포팅 알림을 받아 볼 수 있는 기능을 발견하였고, 너무너무 효자 같이 좋은 기능이라서 같이 공유하고자 기록하게 되었습니다. 실무에서 개발을 하다보면, 개발자 PC와 연결이 되어있는 경우 Error Log를 바로 확인할 수 있지만, QA부서나 다른 타 부서의 테스트 시 발생하는 에러에 대해서는 바로 파악하기가 어려운 점이 있었습니다. 특히나, QA부서에서 테스트 도중 앱이 죽는 경우, 재현 시나리오와 같이 내용을 전달받지..