며칠 전 2018/2/8~2/9에 개최된 DroidKaigi2018 공식 응용 프로그램의 소스 코드는github에서 공개합니다.
매년 참가자들이 드라이드 카이지 공식 애플리케이션을 개발하는 것이 관례가 됐고, 올해도 안드로이드의 최신 기술을 수집하는 느낌으로 개발됐다.
일본 안드로이드 최선단자가 공동 개발한 앱으로, 코드만 읽으면 최첨단 기술을 포착할 수 있다.
꼭 복제해 보시는 걸 추천합니다.
그렇긴 하지만 최첨단 기술이 많이 집중돼 있어 읽기 어려운 장면도 있다고 생각해요.(나야)
그래서 이번에는 드라이키지 2018 공식 앱을 읽을 때 제가 채운 부분을 해설하고 싶습니다.
같이 읽고 싶은 글.
DroidKaigi 2018 App Architecture by takahirom
DridKaigi 어플리케이션 내부bytatsuhama 50 보기
연락 없는 제 Drid Kaigi 어플에 대한 잡담회.

DridKaigi 프로그램의 소스 코드를 사용합니까

갑작스럽지만 공식적으로 적용되는github의 코드는 상당히 크다.
앱 자체에 많은 기능이 있기 때문에 읽어볼 때 큰 느낌을 받을 수 있다.
갑자기 이걸 읽으면 고통스러워...

simplify 분기

그런데, 놀랍게도!이런 사람들을 위해 간소화된 창고를 만들었어!
역시 월드@takahirom님
그리고 플렉스 버전과 코로틴 버전도 만들었어요, 정말 대단해요!
어쨌든 이 얻기 어려운 간략화판simplify 분기을 복제해 봅시다.

build.어디 있어요?

그럼 곧 질문을 드리겠습니다. Drid Kaigi 2018 공식 앱의build입니다.gradle은 Kotlin Script로 작성됩니다.
그래서build.gradle이 없습니다.build.gradle.kts는 그것의 대체품이다.
최신gradle을 사용하면 자동으로 읽을 수 있지만, 읽지 않으면build 파일 이름을 지정하기 위해 settings입니다.gradle에 한 줄을 추가하면 됩니다.
settings.gradle

rootProject.buildFileName = 'build.gradle.kts'

(참조: Gradle으로 Kotlin의 미니멀 샘플 구축

build.gradle.kts 읽기

뭐, 처음 봐도 파일 이름이 똑같은데 내용이 코틀린인데 분위기 속에서 읽으면'아~ 그렇구나'
그나저나 분위기 속에서 읽은 나는 dependencies에 막혔다implementation(Depends.Kotlin.stdlib)어, 왜 잘 안 쓰여 있지?어떻게 됐어요?

buildSrc

implementation(Depends.Kotlin.stdlib)의 답은buildsrc에 있습니다.
창고를 자세히 보면 루트에buildsrc라는 폴더가 있는 것 같아요.
사실gradle은 구축할 때buildsrc 폴더를 스캔하여 클래스 경로에 추가합니다.
Build sources in the buildSrc project
DridKaigi 2018의 지점에서 우리는 이것을 사용하여 다중 모듈의 의존 관계를 개선한다.
Kotlin + buildSrc for Better Gradle Dependency Management

Depends.kt ＆ Versions.kt

그래서build.gradle.kts에 나타나는 Depends는buildsrc 산하의 정의입니다.
https://github.com/DroidKaigi/conference-app-2018/blob/master/buildSrc/src/main/kotlin/Depends.kt
같은 Versions에도 정의된 반이 있기 때문에 둘 다 보는 것이 좋습니다.
https://github.com/DroidKaigi/conference-app-2018/blob/master/buildSrc/src/main/kotlin/Versions.kt
솔직히 이 두 권만 읽어도 요즘 인기 있는 도서관이 다 이거라고 생각해요!이런 거 있어요!이런 발견이 있어서 기쁩니다. 꼭 읽어주세요.
모르는 라이브러리를 추천해 줬어요.
이것만으로도 많은 것을 배울 수 있다.
또한 Kotlin Script를 사용하여 build을 수행합니다.gradle을 쓴 사람은 드물 것 같지만, Kotlin Script로build을 쓴 적이 있다면.그레이드 쓰고 싶어요!이러면 아주 좋은 교과서라고 생각해서 이build.gradle.저는 kts를 구석구석 읽었으면 좋겠어요!

읽을 수 있을 것 같은 곳.

지금까지 안드로이드 스튜디오가 프로젝트를 읽었기 때문에 대체적인 분위기에서 읽을 수 있을 것 같다.
안드로이드 스튜디오는 똑똑해 독자들의 지식 부족도 모두 보완한다.
다 읽은 건 아니지만 읽어볼 수 있을 것 같은 곳을 소개하고 싶어요.

Kotshi 사용

Kotshi는 Kotolin에서 Json을 처리하는 프로그램 라이브러리입니다.
안드로이드는 대부분 Gson을 사용하지만 Kotlin과 Gson은 잘 맞지 않는 것으로 기억된다.
참조: Kotlin과 연결된 Moshi의 kotlin extension 사용
이 때문에 코틀린과 성격이 맞고 리트로핏과 성격이 맞는 모시는 반사처리가 심한 문제도 있었다.
jake신은 이 모든 문제를 해결할 수 있는 프로그램 라이브러리를 만들었다.역시 자크 신.
↑ 틀렸다.Jake신에게 이런 게 있었으면 좋겠다→사실 나는 이미 있다고 소개했을 뿐인데, Kotshi의 제작자는 ansman선생(오해뿐이다)
Kotshi↓에 대한 기사는 상세하다.
공연의 차이도 실험 중이니 꼭 읽어 보세요.
kotlin에서 json Poskotshi가 좋을 것 같아요.
그나저나 Kotshi의 정체는 Moshi의 Json Adapter인데, Moshi에 Kotshi의 adapter를 넣지 않으면 그냥 Moshi가 된다.(이 점을 오해하고 Kotshi를 쓰는 줄 알고 Moshi를 쓰는 사람은 나다

Mapper로 API 응답 변환

Drid Kaigi 응용 프로그램은 서버 응답을 클라이언트가 쉽게 사용할 수 있도록 가공하여 룸의 DB에 저장합니다.

API 정의: README에 적힌 대로.

응답 모델: DroidKaigiApi.kt

Room에 저장: Response.kt

Room DB: SessionDataRepository.kt

이런 느낌으로 룸의 DB에 서버 응답을 넣었을 때SessionRoomDatabase 이후 저장돼 있다.
이 변환 처리는 Kotlin클라이언트가 편리하게 사용할 수 있도록 바꾸다에 쓰여 있고, 확장 함수에 각 데이터를 잘 가공하는 처리라고 쓰여 있다.
고객 측 데이터 구조는 화면 규격이 바뀌면 갑자기 달라지는데, 그간 필요한 것은 필요 없기 때문에 큰 변화가 생긴다.
다른 한편, 서버측 데이터 구조와 DB 구조도 관계가 있어 그렇게 획기적으로 바꿀 수는 없다.
따라서 간단한 변경이라면 고객 측에서 매퍼를 사용하면 쉽게 대응할 수 있다.
매퍼 외에 API 사양은 고객과 다르게 보이고, 코드도 매끄럽다.
물론 고객의 요구사항에 따라 서버 API를 변경하는 경우도 있습니다. 여러 곳에서 고객 측에 흡수된 후 API를 재고하는 시기일 수 있습니다

시간 주위의 서버 응답 변환을 Json Adapter로 해결

Moshi는 API 응답을 Json으로 변환할 때 Json Adapter를 사용자 정의하고 추가할 수 있습니다.
이 SessionDataMapperExt.kt의 Json Adapter를 이용하여 API가 응답하는 시간 시스템의 데이터를 고객이 편리하게 사용할 수 있도록 변환합니다.
이 InstantAdapter를 적용하려면 InstantAdapter에서 Retrofit에 추가할 수 있습니다.

총결산

Drid Kaigi 2018의 공식 응용 프로그램에는 최신 기술이 많다

있다이런 느낌.오!

읽기만 해도 simplify 분기 많은 발견이 있으니 꼭 보세요!