안드로이드 App architecture: Common patterns를 알아보겠습니다. 출처: https://developer.android.com/topic/modularization/patterns 모든 프로젝트에 적합한 modularization(모듈화)을 위한 하나의 전략은 없습니다. Gradle의 자유로운 성질 때문에 적은 제약사항으로 project(프로젝트)를 묶어야 합니다. 이 문서에서는 일반적인 규칙과 흔히 사용되는 patterns(패턴)를 전체적으로 다뤄 당신의 multi(멀티) module Android 앱에 적용할 수 있게 도와줍니다. • 메모: 이 문서에 있는 추천과 좋은 사례들은 다양한 방면으로 앱의 확장 가능성, 품질 향상, 굳건함, 테스트하기 쉬움을 제공해 줍니다. 하지만, 당신은 이것을 지침으로 사용하고 당신이 필요할 때에만 적용하기를 권장합니다. ⊙ High cohesion and low coupling principle: 높은 응집력 그리고 낮은 연결성 원칙; Modular 코드를 설명하는 하나의 방법으로는 coupling(연결)과 cohesion(응집)을 사용해서 설명하는 것입니다. Coupling은 modules가 다른 modules를 참고하는 정도를 나타내고, Cohesion은 여기서는 하나의 module의 요소가 얼마나 연관되어 있는지를 나타냅니다. 일반적인 규칙으로는 당신은 낮은 coupling과 높은 cohesion을 구현하도록 노력해야 합니다. • 낮은 coupling은 modules 가능하다면 다른 것들과 독립적이어야 한다는 뜻입니다. 따라서 하나의 module을 수정한다면, 0 또는 가능한 적게 다른 modules에 영향을 줘야 합니다. Modules는 다른 modules의 내부 동작을 알 필요가 없습니다. • 높은 cohesion은 시스템처럼 동작하는 코드의 모음을 의미합니다. 이것은 명확하게 정의된 역할을 수행하며, 특정한 domain(분야) 안에서만 동작합니다. Ebook을 예시로 들어봅시다. 하나의 mo

사용 언어: Kotlin 1.9.22 사용 버전: Android Studio Hedgehog 2023.1.1 Patch 2 안드로이드 Room database LIKE with wildcard를 알아보겠습니다. LIKE에는 wildcard(와일드카드)가 존재합니다. '%'와 '_'가 대표적인데요. '%'는 아무 단어나 상관없다는 뜻이고, '_'는 아무 단어 한 글자만 가능하다는 뜻입니다. 다음과 같이 글자를 찾는 query(쿼리)로 LIKE를 사용하여 만들었습니다. airport를 치니 검색이 되지가 않네요. 저는 airport만 들어가면 전부 나왔으면 좋겠는데 말이죠. 이럴 때 사용하는 게 wildcard입니다. 평범하게 '%'만 붙이면 오류가 뜹니다. 그래서 '||'도 같이 사용해 주어야 합니다. '||'는 String의 '+'와 같이 글자를 붙여주는 역할을 합니다. 다시 실행해 봅시다. 제가 생각한 데로 잘 나오네요. 끝. 참고 프로젝트: https://github.com/Jaehwa-Noh/Project-Flight-Search-App/tree/compose-flight-search-app 카테고리: Android

사용 언어: Kotlin 1.9.22 사용 버전: Kotlin Playground 안드로이드 코틀린 short-circuit evaluation을 알아보겠습니다. 문서를 보던 중, short-circuit evaluation 이란 단어를 보게 되었습니다. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-boolean/or.html Short-circuit evaluation은 minimal evaluation 또는 McCarthy evaluation 등으로도 불립니다. 우리나라 말로 번역하자면, 단축 평가 또는 단락 평가가 되겠군요. 전자공학을 전공한 저로서는 short-circuit을 보면 단락이 생각나네요. 그래서 short-circuit evaluation이 뭐냐 하면은 논리 연산인 AND와 OR의 경우 하나의 조건만 보고 다음 조건을 확인하지 않는 것을 말합니다. 두 개의 조건이 있는 Boolean 연산자가 있다면, 첫 번째만 보고 두 번째는 생략할 수 있다는 것인데요. AND의 경우 하나가 false 면 다른 하나가 뭐든 false이기 때문에 첫 번째 것만 보고 판단할 수 있습니다. OR의 경우 하나가 true 면 다른 하나가 뭐든 true이기 때문에 첫 번째 것만 보고 판단할 수 있습니다. 코틀린의 '||'와 '&&'는 shortcut-circuit 기능을 사용합니다. 아래의 코드를 보시죠. 코드를 보시면, 10 / number은 원래 0으로 나누기 때문에 오류가 발생해야 합니다. 하지만, shortcut-circuit evaluation을 사용하기 때문에 두 번째까지 확인을 하지 않고 통과가 됩니다. 'or'의 경우는 shortcut-circuit evaluation을 사용하지 않기 때문에 모두 확인하는데요. 보시다시피 오류가 발생합니다. '&&' 경우도 보시죠. 'and'로 변경하면 오류가 발생합니다.

안드로이드 App architecture: About modularization을 알아보겠습니다. 출처: https://developer.android.com/topic/modularization 많은 Gradle(그래들) modules(모듈)로 이루어진 프로젝트를 multi-module(멀티 모듈) project(프로젝트)라고 합니다. 이 지침에서는 multi-module android 앱을 위한 최고의 사례와 추천 patterns(패턴)을 포함합니다. • 메모: 이 문서는 당신이 recommended app architecture에 익숙하다고 가정하고 서술합니다. ⊙ The growing codebase problem: 커지는 코드의 문제; 계속해서 커지는 코드는 확장성, 가독성 그리고 전체의 코드 품질이 시간이 지남에 따라 보통 나빠집니다. 이것은 관리자가 쉽게 관리할 수 있는 구조를 사용하지 않은 채 코드의 증가가 일어나서 그렇습니다. Modularization(모듈화)는 코드를 구조화하여 유지 보수가 쉽게 만들고 이전에 언급한 문제들을 피하는 데 도움을 줍니다. ⊙ What is modularization?: 모듈화는 무엇인가?; Modularization은 느슨하게 연결된 코드 모음이고, 자신이 부분을 가지고 있습니다. 각각의 부분은 module입니다. 각각의 모듈은 독립적이며, 명확한 목적을 제시합니다. 작고 간단한 문제로 나누며 부수적인 문제를 풀 수 있게 해줍니다. 디자인의 복잡성을 줄이고, 큰 시스템에 유지 보수를 쉽게 만들어줍니다. ⊙ Benefits of modularization: 모듈화의 이점; 비록 유지 보수와 전체적인 코드 품질에 중점을 두지만, Modularization의 이점은 많습니다. 아래의 표에 이점을 요약했습니다. • Reusability: 재사용성; Modularization은 코드 공유의 기회를 주고, 많은 앱들을 같은 기초로 만들 게 합니다. Modules는 효과적인 빌딩 블록입니다. 앱은 그들 features(기능

안드로이드 App architecture: Architecture recommendations를 알아보겠습니다. 출처: https://developer.android.com/topic/architecture/recommendations 이 문서에서는 몇 가지 Architecture에 좋은 추천들을 제시합니다. 이것을 받아들여 당신의 앱의 품질을 높이고 강력하고 확장 가능하게 만드세요. 이것은 또한 당신의 앱을 쉽게 유지 보수할 수 있고 테스트할 수 있게 해줍니다. • 메모: 당신은 이 문서의 추천을 단지 추천으로 받아들이세요. 강제 사항이 아닙니다. 앱에 필요한 것만 받아들이세요. 아래의 사항들은 주제별로 묶여있습니다. 각각 항목에는 우선순위가 있고, 얼마나 강력하게 추천하는지 표시되어 있습니다. 우선순위의 항목은 아래와 같습니다. • Strongly recommended: 강력하게 추천; 당신이 하고자 하는 것과 정면으로 충돌하지 않는다면 이것을 따르기를 추천합니다. • Recommended: 추천; 이것은 당신의 앱을 향상 사키는 데 추천합니다. • Optional: 선택 사항; 특정한 환경에서 당신의 앱을 향상시켜 줄 수 있습니다. 메모: 이 추천을 이해하기 위해서는 당신은 Architecture 지침에 익숙해져야 합니다. ⊙ Layered architecture: 계층 구조; 우리가 추천하는 layered(계층) architecture(구조)는 관심사를 나누는 것을 선호합니다. 이것은 UI(유아이)에서 data(데이터) models(모델)까지,  single source of truth(하나의 출처 진실) 원칙을 따르고, unidirectional(단방향) data(데이터) flow(흐름) 원칙 적용하는 것입니다. 여기에 layered architecture의 좋은 사례가 있습니다. • Use a clearly defined data layer [Strongly recommended]: 명확히 정의된 data layer 사용 [강력 추천]; data l

안드로이드 App architecture: UI State production을 알아보겠습니다. 출처: https://developer.android.com/topic/architecture/ui-layer/state-production 현대의 UIs(유아이)는 static(정적) 하지 않습니다. UI의 state(상태)는 user(사용자)와 상호작용하며 변화하거나 app(앱)이 새로운 data(데이터)를 불러올 때 변화합니다. 이 문서에서는 UI state를 생성과 관리하는 지침을 알려드립니다. 문서의 마지막에서는 당신은 이러한 것들을 알게 됩니다. • UI state를 생성할 때 어떤 APIs를 사용해야 하는지를 알게 됩니다. state holder에서 state가 어떤 source(출처)의 성질로 변화하는지에 따라 다릅니다. Unidirectional(단방향) data flow(흐름) 따릅니다. • UI state의 생성이 시스템 자원의 어디에서 관리되어야 하는지 알게 됩니다. • 소비하는 UI에 어떻게 UI state를 노출해야 하는지 알게 됩니다. 기본적으로 state 생성은 변경 사항을 UI state에 점진적으로 적용하는 것입니다. State는 항상 존재하고, events(이벤트)의 결과로 변합니다. 각기 다른 events와 state는 아래의 표로 요약됩니다. 간단히 위의 요약을 외울 수 있는 방법이 있습니다. staet는 존재하고, events 발생한다입니다. 아래의 도식은 state가 events에 의해 변하는 것을 시간 순서대로 시각화 한 것입니다. 각 event는 적절한 state holder에서 처리되어야 하고, 결과는 state를 변경시켜야 합니다. Events는 이렇게 발생합니다. • Users: 앱의 UI와 상호작용 • Other sources of state change: state change의 다른 source; UI, domain(도메인) 또는 data layers(레이어) 앱 data를 표현하는 APIs. 예를 들면, sn

안드로이드 App architecture: State holders and UI state를 알아보겠습니다. 출처: https://developer.android.com/topic/architecture/ui-layer/stateholders UI(유아이) layer(레이어) 지침에서 논의했던 unidirectional data flow (UDF, 단방향 data 흐름)은 UI State(상태)를 생산하고 관리하는 것을 의미합니다. 또한 UDF를 관리하는 특별한 class를 state holder(홀더)라고 합니다. 당신은 state holder를 ViewModel 또는 일반 class에 적용할 수 있습니다. 이 문서에서는 좀 더 가까이에서 state holders 공부하고 UI layer에서의 역할을 다룹니다. 이 문서의 마지막에서 당신은 앱의 state를 어떻게 UI layer에서 다루는지 이해하게 됩니다. 이것은 UI state의 생성 pipeline(과정)을 다룹니다. 당신은 아래의 사항들을 이해하고 알게 됩니다. • UI layer에 존재하는 UI state의 type(타입) 이해 • UI layer에 있는 UI state의 logic(논리) type 이해 • ViewModel이나 일반 class 같은 state holder를 적정하게 선택하여 사용하는 방법 습득 ⊙ Elements of the UI state production pipeline: UI state 생성 과정의 요소; UI state와 logic이 UI layer를 정의합니다. • UI state: UI 상태; UI state는 UI를 설명하는 property(소유물)입니다. 여기에는 두 가지 종류의 UI state type이 있습니다.   - Screen UI state(화면 유아이 상태)는 화면에 표시를 위해 필요한 것입니다. 예를 들면, NewsUiState class(클래스)에는 뉴스 기사와 UI를 표현하기 위한 다른 정보들이 있을 겁니다. 이 state는 보통 다른 layer(