프로젝트를 만드게 되면 진행하는 일련의 과정을

루틴으로 만들고 계속 개선하려고 한다.

 

1. 프로젝트 생성, GIT 연결

2. 개발환경 설정

3. 개발 구조

4. 테스트

 


프로젝트 시작

 

프로젝트 생성

 

 - 패키지 이름, 프로젝트 이름

 

 

Git

 

Git Issue 생성

 - 개발 환경 설정 생성

 

.gitignore 설정 https://www.gitignore.io/

 

gitignore.io

Create useful .gitignore files for your project

www.gitignore.io

 

gitflow(개념만 사용)

 - 생성 프로젝트 mater branch 업로드

 - develop branch 생성, 업로드

 

 

 

 

 


개발 환경 설정

 

feature/environment 생성

 

 

gradle 설정

 

gradle 버전 관리 파일(dependencies.gradle) 생성

 - 모든 버전 reference로 사용

 - 앱 버전 0.1 시작

 

문서화 : gradlw dokka

 - apply plugin: 'org.jetbrains.dokka'

 - classpath "org.jetbrains.dokka:dokka-gradle-plugin:$dokkaVersion"

 

코드 검사 : gradlew lint

 

사용할 라이브러리 추가

 - anko, koin, rxandroid, rxjava, rxbinding...

 

 

 

기본 파일 구성

 

resource 설정

 - strings(ko) 추가

   : 아주 조금이라도 해외에서 앱이 쓰일 수 있다면 default를 영어로 한글은 strings(ko)를 사용하자.

 - dimens 추가

 

BaseColor 설정

https://material.io/resources/color/#!/?primary.color=252F4A&secondary.color=22B94E&view.left=0&view.right=1

 

Color Tool - Material Design

Create and share color palettes for your UI, and measure the accessibility of any color combination.

material.io

 

패키지 구성 및 필요한 기본 클래스들 추가 (Rx 기반)

component

 - BaseActivity

 - BasePresenter

 - BaseView

 - BaseViewModel

ext

 - LifecycleExtensions

 - RxExtensions

 - ViewExtensions

util

 - AutoClearedDisposable

ui

 - custom

 - main

Constants(optional)

App

 

 

Manifest Warning 제거

 - fullBackupContent 설정

 - MainActivity View action 추가

 

 

 

 

 


개발 구조

 

 

MVP, MVVM, Clean Architecure, Rx, LiveData, AAC, DataBinding, Coroutine, DI

위의 기술들을 어떻게 접목하느냐에 따라 천차만별의 구조가 나오게 된다.

 

심지어 MVP만 보아도 사용하는 방법다 가지각색이다.

Contract interface 안에 View, Presenter interface를 사용할 수도 있고

View만 추상화해서 사용할 수도 있다.

 

하지만 결국 몇가지 공통적인 문제들을 해결하기 위한 표현이 다를뿐이라고 생각한다.

 

1. 뷰와 모델, 그리고 이 둘을 어떻게 연결할까?

2. 비동기 처리

3. 응집도는 강하게 결합도는 약하게

 

3번이 너무 추상적이긴 하지만 이 정도가 안드로이드의 가장 근본적인 문제인 것 같다.

 

하지만 천차만별인 구조들 중에

하나의 완성된 프로젝트를 만들고 나면 다른 기술을 적용하는 것이 그리 어렵지 않다고 생각한다.

 

그러니 나만의 완성된 구조를 만들고 계속 날카롭게 다듬자.

 

 

 

 

 


테스트 코드

 

좋은 구조를 가지지 않는 이상 테스트 코드 많은 일을 만들어 낸다.

좋은 구조부터 갖자

 

 

 

 

 

 

'Android > Common' 카테고리의 다른 글

수명주기; Lifecycle  (0) 2020.06.22
비동기  (0) 2020.05.14
안드로이드 개발자 로드맵  (2) 2020.05.07

+ Recent posts