Uing? Uing!!

반복되는 레이아웃 하나의 앱에는 자주 재사용되는 레이아웃이 있는 경우가 많다. 예를 들면, 거의 비슷하게 툴바가 앱 전역에 걸쳐 사용되고 있을 수 있다. 같은 툴바가 FirstActivity와 SecondActivity에 사용되는 경우를 살펴보자. 각 액티비티의 레이아웃은 이런 식으로 생성될 것이다. 이 예시에서는 화면이 Frist Activity와 Second Activity 두 개밖에 없지만, 같은 타이틀 바가 100여개의 화면에 적용되어야 한다면 어떨까. 모든 화면마다 툴바에 해당하는 이 부분이 추가되어야 할 것이다. 이렇듯 반복되는 레이아웃을 재활용할 수 있도록 만들어진 것이 include 태그이다. 태그 include 태그는 한 번 작성한 레이아웃의 일부를 여기저기에서 가져다 쓸 수 있도록 해 ..

데이터바인딩(databinding) 데이터바인딩을 활용하면 레이아웃에서 변수를 정의하고 활용할 수 있다. 데이터바인딩에 대한 포스팅은 별도로 작성 예정이지만, 간단히 데이터바인딩을 활용하는 예시는 이렇다. class MainActivity: AppCompatActivity() { private var _binding: ActivityFirstBinding? = null private val binding: ActivityFirstBinding get() = _binding override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) _binding = DataBindingUtil.setContentView(t..

발단 잘 빌드되던 프로젝트가 갑자기 이런 메시지를 띄우면서 빌드되지 않았다. The Hilt Android Gradle plugin is applied but no com.google.dagger:hilt-android-compiler dependency was found. andorid-compiler 디펜던시는 build.gradle에 확실하게 잘 적용되어 있는데도 계속 빌드되지 않았다. 삽질 구글링을 해보며 여러 가지 나오는 방법들을 적용해 보았다. clean-rebuild도 해 보고, invalidate cache & restart도 해 보고, kapt를 annotationProcessor로 바꿔도 보고. 다 잘 돌아가지 않았는데, 딱 한 가지 방법이 잘 동작했다. 정확히 어떤 글에서 봤던 해결법..

나 혼자 개발한다면 git 히스토리를 살펴볼 일이 별로 없다. 하지만 다른 개발자와 한 팀으로 일한다면 현재 내가 보고 있는 코드가 어떻게 나온 코드인지 이해하기 위해 히스토리가 필요한 상황이 생긴다. 그렇다고 git 커밋 기록을 일일이 뒤져볼 수는 없는 일이다. 안드로이드가 제공하는 기능 두 가지, Annotate와 Git History를 사용하면 과거에 이 코드가 누구에 의해 어떻게 변화되어 왔는지를 확인할 수 있어 코드 이해도를 높여 준다. Annotate 안드로이드 스튜디오의 Annotate 기능은 지금 보고 있는 파일의 각 라인에 해당하는 마지막 커밋과 커밋을 진행한 사람을 보여 준다. 사용 방법은 간단하다. 1) 원하는 파일을 열어둔 후 shift를 두번 연속 눌러 검색기를 켠다. 2) ann..

티스토리 통계에서는... 티스토리 설정의 통계를 보면 방문자가 유입된 경로를 알려주는데, 아래 이미지를 보면 분명 오늘 새벽 중에 구글 검색 조회가 있었음에도 유입 키워드를 볼 수 없다. 구글로 유입된 방문자가 어떤 키워드로 어떤 게시글에 접근했는지를 확인하려면 따로 설정이 필요하다. 구글 서치 콘솔 등록하기 구글 검색 콘솔(google search console)에 내 홈페이지를 등록하면, 이후의 구글 검색 유입 키워드를 확인할 수 있다. 구글 검색 콘솔에 내 블로그를 등록하려면 몇 단계의 절차가 필요하다. 1) 내 블로그 주소 등록 콘솔에서 새 주소를 등록하기 위해 'URL 접두어' 란에 내 블로그의 주소를 적고 '계속'을 누른다. 2) 소유권 확인 구글에서는 이 블로그가 내 소유라는 것을 아직 모르..

발단 EditText에서 사용자의 입력을 추적하기 위해 흔히 사용되는 방법이 이렇게 TextWatcher를 붙이는 것이다. binding.editTextView.addTextChangedListener(object: TextWatcher { override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) { // 텍스트 변경 전 // s: 기존 문자열, start: 커서 시작 위치, count: 변경 대상 문자 수, after: 변경 후 문자 수 } override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) { // 텍스트 변경 시..

LeakCanary 안드로이드에서 메모리 누수는 흔한 문제이다. 메모리 누수가 발생하는 경우는 다양하지만, 특히 context를 잘못 사용할 경우에 흔히 발생한다. 발생하기 쉬운 문제이지만, 프로젝트의 범위가 방대할 경우 프로파일링 기능을 사용하더라도 정확히 어디에서 메모리 누수가 발생하는지 바로 파악하기 어려울 때가 있다. LeakCanary는 이런 메모리 누수 상황에서 정확히 어디에서 누수가 발생하는지를 분석하고 알려주는 라이브러리이다. 적용법 적용법은 아주 간단하다. app단의 build.gradle에 leakcanary 의존성을 추가해주면 끝이다. 물론 디버깅 상태에서만 활용할 것이므로 debugImplementation으로 추가한다. debugImplementation 'com.squareup...

라이브러리와 리소스 안드로이드 라이브러리를 개발할 때에는 리소스와 관련해서 신중하게 접근할 필요가 있다. 앱에서 라이브러리를 implementation했을 때, 라이브러리에서 정의한 리소스명들이 그대로 노출 및 사용되기 때문이다. 이때 라이브러리 내부의 리소스와 실제 앱 개발 작업이 직접적으로 엮이는 부분은 두 가지가 있다. 1) 앱과 라이브러리에 동일한 이름을 갖는 리소스가 있다면, 라이브러리의 리소스는 무시된다. 2) 앱 개발 중 라이브러리의 color, string 등 리소스가 자동완성 등에 직접 노출되고, 실제로 사용할 수도 있다. 1번의 경우 간단한 이야기이지만 이 포스팅의 논점은 아니니 다른 포스팅에서 다루는 것으로 하고, 2번이 일어나는 이유는 라이브러리 내부의 모든 리소스는 기본적으로 공개..