꿈 많은 개발자가 되자 - Taehwan

Material Design은 크게 버전 2와 버전 3로 나눠지는데, 일반적으로 M2는 Material로 명시되어 있다.

• Material Design
• Material Design 3

안드로이드 12와 함께 나온 디자인이 머트리얼 3인데, 안드로이드 스튜디오에서 컴포즈 관련 새로운 프로젝트 생성 시에 함께 나오는 머트리얼 버전은 2이다.(안드로이드 스튜디오 패치 시 변경될 수 있다)

머트리얼 2와 3는 차이가 있다.

• 색상에 대한 층이 머트리얼 3가 더 넓다.(하지만 모든 컬러를 구글의 기본 컴포넌트에서 활용하지는 않는다)
• style 관련을 피그마 정보와 쉽게 연동되어 읽기 쉽다.
  • titleSmall, headlineLarge 와 같은 형태이다.
• 3에서는 다이나믹 컬러를 제공한다. 일반적인 회사에서는 특별히 선호하지는 않을 것 같다.
• 머트리얼 3에서 폴드 대응을 하기 위한 별도 라이브러리를 제공한다.
• 머트리얼 3 용 Exo player 용 라이브러리도 제공한다.

지금 선택한다면 3를 선택하는 건 나쁘지 않다. 하지만 2를 선택하여 활용하는 경우도 많을 것 같아 이 글을 간단하게 정리해두려고 한다.

• 3에는 아직 BottomSheet가 포함되어 있지 않아 결국 2와 3를 함께 활용해야 할 수 있다.

이 글에서 알아볼 내용

• 머트리얼 2의 색상 정보
• isLight가 뭘까?

Read More

Android Compose에서 keyboard가 노출되었는지 알 수 있는 방법은 과거 안드로이드 view 높이 변경으로 가능하다.

공식적인 안드로이드 11부터는 아래의 코드로 확인이 가능하지만 minSdk 버전 제약이 있으니 아직은 과거 형태를 공존시키는 게 좋다.

Android 11부터 활용 가능

Virtual keyboard show/hide event - stack overflow

view.setWindowInsetsAnimationCallback(object : WindowInsetsAnimation.Callback {
    override fun onEnd(animation: WindowInsetsAnimation) {
        super.onEnd(animation)
        val showingKeyboard = view.rootWindowInsets.isVisible(WindowInsets.Type.ime())
        // now use the boolean for something
    }
})

Compose에서도 특별히 keyboard 노출 정보를 제공하는 라이브러리가 없어서 stack overflow를 통해 확인하면 대부분 기존 view 높이를 기반한 코드를 활용하고 있다.

그래서 Compose에서 활용 가능한 형태로 맵핑하고 이 이벤트를 간단하게 활용할 수 있는 라이브러리를 배포하였다.

이 글에서 알아볼 내용

• View 높이 변경을 측정하여 keyboard 이벤트 처리하는 방법
• CompositionLocalProvider 활용법

Read More

안드로이드 MVVM을 효과적으로 작성하려면 알아야 할 것은 무엇일까? 그리고 왜 MVVM을 하려고 하는 것일까?

우리는 항상 새로운 것을 갈망하는데, 사실 안드로이드가 너무 고여서 재미가 없기 때문이다.

10년이 넘은 안드로이드는 초기에는 안드로이드 플랫폼의 변화에 대응하였고, MVP라는 패턴을 소개하기 시작하면서 패턴에 관심을 가지기 시작했다.

거기에 kotlin으로 언어도 변화되었고, RxJava, Coroutines, Flow 등 새로운 라이브러리가 계속 나오고 있다.

기반이 바뀐 것이다.

새로 시작하는 분들을 기준으로 한다면 엄청나게 덩치 큰 걸 한 번에 주입해야 한다는 문제가 생긴다.

따라 하는 건 누구나 하고, 동작하는 것 역시 누구나 만들 수 있다.

다만 좀 더 재미있고, 새로운 방식에 고통받으며 재미를 찾아가는 재미도 함께 해야 한다.

이 글은 지극히 주관적인 생각을 담고 있는 글이다.

이 글에서 알아볼 내용

• MVVM과 MVP
• MVVM에서의 테스트 검증
• 테스트 검증을 좀 더 잘해보자.

Read More

이 글은 안드로이드에서 MVVM을 어떤 식으로 접근하는지 고민해 보고, 따라 하기 위한 글이다.

2016년에 MVP 무작정 따라 하기 시리즈를 작성했었는데, 이제서야 MVVM 무작정 따라 하기 시리즈를 작성하려고 한다.

이미 많은 곳에서 MVVM을 활용하고 있고, 더 새로운 아키텍처를 찾기도 한다.

사실 이 시점에 MVVM 따라 하기를 작성하는 건 큰 도움이 되지는 않을 것이다.

하지만 그 중간 과정에서 주의해서 활용되어야 할 부분은 분명히 있다. 이런 부분을 기반하여 새로운 MVVM 따라 하기를 작성하게 되었다.

이 글에서 알아볼 내용

• MVVM이 뭘까?
• MVP를 알아야 할까?
• MVP와 MVVM이 어떻게 다를까?

Read More

최근 안드로이드 개발은 모듈에 대한 고민을 많이 하는 추세이다. 하나의 app 모듈에서 package를 분리하여 개발하던 방식에서 모듈 단위로의 분리를 시도하고 있다.

모듈 단위로 분리하여 개발하면 얻을 수 있는 이득은 무엇일까?

• 모듈 간 디펜던시 최소화로 아키텍처 적용의 용의
• DI 적용으로 유연한 개발 가능
• 단독 화면으로 테스트 가능성

등등 다양한 이유가 있을 것이다.

적절한 모듈 분리도 필요하고, 모듈을 분리하는 조건도 정해야 할 것이다.

• feature 단위로 모듈을 구분한다.
• feature 단위의 데이터 역시 함께 구분한다.
• Architecture에 따라 모듈화를 구성한다.(View-ViewModel + Model(+ Clean Architecture) + core + ui system 등)

다행히 DI가 있으니 이런 모듈이 여러 개여도 app/main 화면에서 쉽게 엮어 줄 수 있다.

이 글에서는 모듈 분리 기법을 소개하지는 않고, 모듈을 분리 시 어떤 식으로 관리하면 좋을지 소개한다.

폴더 구조를 include 하는 방식은 두 가지가 있다.

• include(“:모듈이름”)
• include(“:상위폴더:모듈이름”)

여기서는 상위 폴더 위치는 신경쓰지 않는 방식에 대해서 소개한다.

이 글에서 알아볼 내용

• 폴더 구조의 모듈을 정리해보자.
• 폴더 구조 작업 시 설정 부분을 살펴본다.
• 폴더 구조 작업 시 Android 카테고리에서도 볼 수 있는 방법 추가
• build.gradle plugin 관리 방법을 소개한다.
• 모듈 나누는 방법을 소개하지는 않는다.

Read More