전체 글

안드로이드 개발을 하다보면 여러개 View의 데이터를 서로 공유해야하는 상황이 꼭 발생한다. 예를 들면 회원가입 페이지에서 여러개의 화면에서 사용자의 정보를 입력받을 때, 각 화면에서는 하나의 정보(전화번호, 이름)을 받아도 이전의 화면에서 받았던 정보를 저장해야 한다. 안드로이드에서는 다양한 방법으로 각 화면간의 데이터가 공유가 가능하다. 몇가지 방법을 예시와 함께 소개하며, 편의를 위해 가장 많이 사용하는 Fragment를 기준으로 작성하였다. 아래의 방식 외에도 추가적으로 공유하는 방법이 존재할 수 있으며, 장점과 단점을 파악하여 알맞는 방법을 선택하는 것이 중요하다. 1. Navigation Argument 첫번째 방법은 Navigation Component의 Safe Args를 이용하거나 Bun..

이번 GDSC 솔루션 챌린지 / WinterCup에 나가게 되었고, 우리 팀은 카메라를 활용한 앱을 기획하게 되었다. 그 중 나는 Jetpack 라이브러리에 카메라 기능을 활용할 수 있는 CameraX가 생각났고, 해당 라이브러리를 활용하여 개발하기로 하였다. Project SetUp build.gradle(project) buildscript { ext{ camerax_version = "1.2.1" } } 2023.02.27을 기준으로 현재 CameraX의 latest version은 1.2.1이다. build.gradle(module) dependencies { // Camerax implementation "androidx.camera:camera-lifecycle:${camerax_version..

이전 포스팅에서 Dagger에 대해 공부했었다. Dagger는 범용 DI 프레임 워크로, Android에서 사용하기 위해서는 많은 개념과 이해를 가지고 있어야 한다. Hilt는 Dagger2는 Android 전용 DI 라이브러리로 Dagger에 비해 낮은 러닝커브와 빠르게 초기 DI 환경 세팅을 할 수 있는 강점을 가지고 있다. Dagger와 Hilt의 차이점을 기준으로 Hilt의 주요 개념 Component : Dagger 컴포넌트에 설치되는 모듈 컴포넌트를 정의하고, 멀티 컴포넌트를 위해서 따로 subComponents를 정의해야 한다. 컴포넌트에 생성자를 정의하고, 주입되는 메소드를 모두 정의해야 한다. @Subcomponent interface GameComponent { // component를..

의존성이란, 클래스가 필요로 하는 다른 객체 인스턴스를 의미한다. 의존성 주입은 말 그대로 클래스 내에서 객체 인스턴스의 생성을 직접 하지않고, 외부에서 생성하여 필요한 곳에 주입되도록 코드를 조직화 하는 방법이다. 의존성 주입의 이점 코드를 재사용하게 해준다. 객체 생성 방법이 변경되더라도 클라이언트의 코드에 영향을 주지 않는다. (클라이언트는 의존성 주입을 받는 클래스) 코드 테스트를 더 용이하게 한다. 테스트를 위해서, Fake 저장소를 주입하는 방식과 같이 쉽게 테스트가 가능하다. 클라이언트는 인터페이스로 객체를 알고 있으면 되므로, 좋은 설계를 촉진한다. 클래스의 추상화를 더 잘 할 수 있도록 하며, 멀티 모듈에서 모듈간의 의존성을 소거하는데 유용하다. DI(의존성 주입) 프레임 워크의 이점 프..

아무런 리소스 및 레퍼런스 없이 개발을 하는 프로젝트를 GreenField Project라고 한다. GreenField Project를 시작할 때 무엇을 먼저 하는 것이 좋을까? 가장 중요하고, 잘 변하지 않는 부분부터 공략한다. 기획자 혹은 비즈니스 부서와 함께 핵심 사용자의 시나리오를 설정하고, 핵심시나리오를 따라 코드를 옮겨 적는다. 이 때 최대한 데이터 및 UI와 같은 가변적인 요소는 배제하고, 애플리케이션의 핵심 로직, 재사용이 가능한 로직을 먼저 구현한다. 1. Domain Layer 도메인 계층은 Ui 계층에서 사용되는 비즈니스 로직을 캡슐화하여 모아놓은 곳이다. 인터페이스 형태로 존재하며, 실제 구현체는 숨겨져 있는 곳이다. 기획자 및 비개발군이 볼 수 있는 계층이며, 실제 비즈니스 로직이..

1. MVVM의 배경 기존의 패턴인 MVC, MVP의 경우 Model이 확실하게 독립적인 요소로 분리되었으나, View와 Controller, View와 Presenter의 의존성은 여전히 존재했다. 하지만 MVVM은 단방향 데이터 흐름을 가장 잘 구현할 수 있는 패턴으로, 단방향 데이터 흐름을 통해 View와 ViewModel 간의 의존성을 소거하였다. 단방향 데이터 흐름 상위 객체는 하위 객체의 상태를 읽을 수 없고, 하위객체로 이벤트를 보낼 수도 없다. 하위 객체는 상위 객체의 이벤트를 직접적으로 읽을 수 없다. MVVM에 대입하면, View는 사용자의 입력을 전달만 하고, 결과는 받지 않는다. 대신 간접적으로 상태 변경을 통보받는다. 2. MVVM의 구조 2 - 1. View View는 사용자에게..