Uing? Uing!!

앞단 개발자의 기다림앱 개발자에게 서버 API를 기다리는 시간은 필연적이다. 이 기다림은 개발 전, 개발 중, 심지어 개발이 끝난 후에도 발생한다.기획이 완료되고, 디자인이 완성되고, 서버 API까지 완벽히 준비된 후에 앱 개발이 진행된다면 모든 것이 간단해지겠지만... 현실적으로 이런 상황은 드물다.서버와 앱 개발은 대부분 동시에 진행되기 때문에, 앞단 개발자들은 대개 이 시간을 효율적으로 활용할 방법을 찾는다.Mock Server 의 가치서버 API가 완성되기 전에 클라이언트 개발을 원활하게 하기 위해 많은 개발자들이 다음과 같은 방법들을 활용한다. 더미 API 요청: 서버에서 간단한 더미 API를 제공받아 테스트.더미 데이터 하드코딩: 앱 내부에서 가상의 데이터를 직접 생성해 사용.유닛 테스트 작성..

서브모듈이 많은 프로젝트에서 한 번에 pull 해오는 방법을 기록합니다.pull 외에 다른 submodule 관련 동작도 비슷하게 사용할 수 있습니다.터미널 명령어git submodule foreach git pullsourcetree에서 하는 방법1. 동작 > 커스텀 액션 > 편집2. 추가 > 아래와 같이 커스텀 동작 추가(맥북 기준)3. 이후 커스텀 액션 실행 가능 개인적으로는 소스트리를 좋아하지만, 서브모듈이 많은 프로젝트는 그냥 Android Studio 터미널에서 명령어 치는 게 더 편한 것 같다.더 좋은 방법이 있다면 알려주세요.

안드로이드 스튜디오에서 파일 편집을 하다가, 왼쪽 탐색기에서 지금 보고 있는 파일의 경로를 찾고 싶을 때가 있다. 프로젝트 > 앱 > 패키지 > 내부 패키지 > ... > 파일 의 경로를 직접 찾아 들어가기란 정말 귀찮은 일이다. 이번 포스팅에서는 탐색기에서 현재 편집 중인 파일에 즉시 접근할 수 있는 두 가지 방법을 소개한다. 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..

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