Uing? Uing!!

안드로이드 스튜디오에서 파일 편집을 하다가, 왼쪽 탐색기에서 지금 보고 있는 파일의 경로를 찾고 싶을 때가 있다. 프로젝트 > 앱 > 패키지 > 내부 패키지 > ... > 파일 의 경로를 직접 찾아 들어가기란 정말 귀찮은 일이다. 이번 포스팅에서는 탐색기에서 현재 편집 중인 파일에 즉시 접근할 수 있는 두 가지 방법을 소개한다. Select Opened File (Alt+F1, 1) : 편집 중인 파일 바로 접근하기 왼쪽 탐색기 탭의 오른쪽 위 아이콘 중, 조준점 같이 생긴 아이콘이 있다. 이 아이콘을 클릭하면 바로 좌측 탐색기에서 현재 보고 있는 파일을 열어 준다. Always Select Opened File : 편집 중인 파일 항상 접근하기 좌측 탐색기 탭의 설정 버튼을 클릭하면, Always Se..

반복되는 레이아웃 하나의 앱에는 자주 재사용되는 레이아웃이 있는 경우가 많다. 예를 들면, 거의 비슷하게 툴바가 앱 전역에 걸쳐 사용되고 있을 수 있다. 같은 툴바가 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..

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

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

기본적으로, 하나의 패키지명은 하나의 고유한 앱을 의미한다. 그리고, 같은 패키지명을 가진 앱은 같은 기기에 설치될 수 없다. 그러므로, 같은 앱은 기기에 두 개 이상 설치할 수 없다. 하지만 같은 종류의 앱을 여러 타입, 또는 여러 버전으로 나누어 빌드하고 싶을 수도 있다. 아래 두 상황을 대표적인 예로 들 수 있다. (공식 문서에서도 이 두 가지를 예로 들어 설명한다.) 1) 출시용과 디버그용 앱을 분리하기 위해서 - 이 경우 디버그용 앱에는 몇 가지 기능들이 추가될 것이다. 2) 무료앱과 유료앱을 분리하기 위해서 - 이 경우 무료앱에서는 유료앱의 기능들이 잠김 상태로 표시될 것이다. 이런 경우에 사용할 수 있는 것이 Build Varients(빌드 변형)이다. Build Varients(빌드 변형)..