현재 안드로이드 앱 개발을 하고 있습니다.
처음이다보니 데이터베이스, ViewModel 개념에서 걸려 넘어져 있는 중입니다.. (흑흑)
그리하여 ViewModel에 대해 ChatGPT한테 물어물어 공부를 해보았습니다.
GPT 이놈이 할루시네이션(뻔뻔한 거짓말)이 있다는 것을 알지만 물어보면 바로 대답을 해주다보니
키워드로 검색하는 것보다 훨씬 편리해서 실험적으로 이 방법을 써보았습니다.
(언젠가는 키워드로 검색하는 시대가 사라지겠지요..)
공부한 방법은 다음과 같습니다.
1. GPT한테 물어본다.
2. GPT가 알려준 답변에서 모르는 단어(개념)에 대해 다시 물어본다.
3. 2번의 반복. (주제에서 너무 벗어난 것 같으면 멈춘다)
4. 할루시네이션에 의한 잘못된 정보를 걷어내기 위해 구글링을 통해 검증한다.
5. 단어(개념)을 나만의 언어로 요약하여 블로그에 정리한다.
제 개인적인 공부로서 모르는 부분 위주로 GPT한테 물어보았습니다.
(아마 이런 것도 몰라?하실 것도 있을 겁니다 허허;;)
얼핏 대충은 알더라도 사실 정확하게는 모르는 부분은 과감하게 다 물어보았습니다.
이 포스팅의 내용이 도움이 되실지는 모르겠으나,
그냥 GPT 가지고서 이렇게도 공부하는구나.. 라고 제 실험적 공부법을 보는 눈요기 정도라도 되시면 좋겠습니다 ㅎㅎ
* 빨간색 형광펜: 찾아서 알게된 단어(개념) (2024-02-21 기준)
* 노란색 형광펜: 아직 찾지 않은 단어(개념) (2024-02-21 기준)
* 초록색 형광펜: 주제에서 벗어나 나중에 찾을 단어(개념)
0. ViewModel이 무엇입니까?
ViewModel은 Android 앱에서 UI 관련 데이터를 처리하고 관리하기 위한 구성 요소 중 하나입니다. 주로 MVVM (Model-View-ViewModel) 아키텍처 패턴에서 사용됩니다. ViewModel은 UI 컨트롤러 및 비즈니스 로직과 UI 간의 중간 매개체 역할을 합니다.
1. Lifecycle-aware: ViewModel은 Android의 수명 주기를 인식하고, 이에 따라 데이터를 유지합니다. 활동이 재생성되거나 구성 변경이 발생해도 ViewModel은 유지되므로 데이터 유지 및 UI 상태 관리에 용이합니다.
2. UI와 데이터 분리: ViewModel은 UI 관련 데이터를 처리하고, UI 컨트롤러 (Activity, Fragment 등)에서 데이터에 접근할 수 있도록 합니다. 이를 통해 UI 로직과 비즈니스 로직을 분리하여 코드의 가독성과 유지 보수성을 향상시킵니다.
3. 메모리 누출 방지: ViewModel은 앱의 메모리 누출을 방지하는 데 도움이 됩니다. 예를 들어, 액티비티의 경우 구성 변경으로 인해 onDestroy()가 호출되면, ViewModel은 해당 액티비티의 참조를 계속 유지하지 않습니다.
4. 테스트 용이성: ViewModel은 비즈니스 로직을 분리하고, 단위 테스트를 용이하게 만듭니다. ViewModel의 메서드는 일반적으로 순수한 Kotlin 코드이므로 테스트하기 쉽습니다.
5. 공유 데이터: 여러 UI 컨트롤러가 동일한 데이터에 액세스해야 하는 경우 ViewModel을 사용하여 데이터를 공유할 수 있습니다. 이를 통해 데이터의 일관성을 유지하고 중복을 방지할 수 있습니다.
ViewModel은 Android Jetpack 라이브러리에서 제공되며, androidx.lifecycle.ViewModel 클래스를 상속하여 구현됩니다. ViewModel을 사용하려면 AndroidX 라이브러리를 프로젝트에 추가하고, ViewModelProvider를 사용하여 ViewModel 인스턴스를 얻어야 합니다.
=> 그럼 "MVVM (Model-View-ViewModel) 아키텍처 패턴" 에 대해 물어보자.
1. MVVM (Model-View-ViewModel) 아키텍처 패턴이란?
MVVM은 Model-View-ViewModel의 약자로, 안드로이드 앱 개발에서 널리 사용되는 아키텍처 패턴 중 하나입니다. 이 패턴은 UI 로직과 비즈니스 로직을 분리하여 앱의 유지 보수성과 확장성을 향상시키는 데 도움이 됩니다.
-
앱의 데이터 및 비즈니스 로직을 나타냅니다.
-
데이터베이스, 네트워크 호출, 파일 시스템 액세스 등과 같은 데이터 소스와 상호 작용합니다.
-
일반적으로 데이터의 구조를 정의하는 데이터 클래스와 데이터를 가져오고 업데이트하는 메서드를 포함합니다.
2. View:
-
사용자 인터페이스를 나타냅니다.
-
사용자에게 정보를 표시하고 사용자 입력을 처리합니다.
-
화면 구성 요소인 액티비티, 프래그먼트, XML 레이아웃 등을 포함합니다.
-
View와 Model 사이의 중간 매개체 역할을 합니다.
-
UI 관련 데이터를 관리하고 뷰에 표시되는 데이터를 제공합니다.
-
비즈니스 로직을 처리하고 뷰와 독립적으로 데이터 상태를 관리합니다.
-
뷰와의 직접적인 의존성을 줄이고 테스트 용이성을 향상시킵니다.
-
단일 책임 원칙(Single Responsibility Principle) 준수: 각 구성 요소는 단일 책임을 갖고 있으며, 역할이 명확하게 구분됩니다.
-
데이터 바인딩(Data Binding): View와 ViewModel 사이의 데이터 흐름을 자동화하는 데 사용됩니다. 이를 통해 XML 레이아웃과 ViewModel 간의 바인딩을 처리하고 반복적인 코드 작성을 줄일 수 있습니다.
-
확장성과 유지 보수성 향상: 각 구성 요소가 분리되어 있으므로 코드 수정 및 유지 보수가 쉽습니다.
-
테스트 용이성: 비즈니스 로직은 ViewModel에 집중되어 있으므로 단위 테스트 작성이 용이합니다.
MVVM은 안드로이드 앱 개발에서 널리 사용되며, Android Jetpack 라이브러리에서 지원하는 ViewModel과 LiveData와 함께 사용되면 앱의 아키텍처를 더욱 향상시킬 수 있습니다.
=> 그럼 "아키텍처 패턴" 에 대해 물어보자.
2. 아키텍처 패턴이란?
아키텍처 패턴은 소프트웨어 시스템을 설계하고 구축하는 데 사용되는 구조적인 체계나 설계 원칙의 집합을 말합니다. 이러한 패턴들은 시스템의 구조를 조직화하고, 코드의 유지 보수성, 확장성, 재사용성, 테스트 용이성 등을 향상시키기 위해 개발되었습니다.
1. 모듈성(Modularity): 시스템을 독립적인 구성 요소로 나누어 유지 관리하기 쉽게 만듭니다.
2. 유연성(Flexibility): 시스템을 변경에 대해 유연하게 만들어 새로운 요구 사항을 수용할 수 있도록 합니다.
3. 확장성(Scalability): 시스템이 증가하는 요구 사항에 대해 확장할 수 있도록 합니다.
4. 유지 보수성(Maintainability): 코드의 가독성과 유지 보수가 쉽도록 만듭니다.
5. 테스트 용이성(Testability): 시스템의 각 구성 요소를 단위 테스트하고 통합 테스트할 수 있도록 합니다.
1. MVC (Model-View-Controller): UI, 비즈니스 로직, 데이터 모델을 분리하여 애플리케이션을 구성하는 패턴입니다.
2. MVP (Model-View-Presenter): MVC 패턴의 확장으로, 뷰와 모델 사이에 프리젠터를 추가하여 뷰와 모델의 의존성을 줄입니다.
4. Clean Architecture: 비즈니스 규칙, 사용자 인터페이스, 외부 데이터 소스 등을 격리된 계층으로 나누어 애플리케이션을 설계하는 패턴입니다.
5. Hexagonal Architecture (Ports and Adapters): 애플리케이션의 내부 동작을 사용자 인터페이스 및 외부 시스템에서 분리하는 패턴입니다.
이러한 아키텍처 패턴들은 각각의 장단점과 사용 사례에 따라 선택되며, 개발자는 프로젝트의 요구 사항과 특성을 고려하여 적절한 패턴을 선택하고 구현해야 합니다.
=> 모르는 단어(개념)
(3) 코드의 유지보수, (4) 단위테스트, (5) 비즈니스 로직, (6) 프리젠터, (7) MVVM, (8) 비즈니스 규칙
3. 코드의 유지 보수란 무엇인가?
코드의 유지 보수는 소프트웨어 시스템이 변경되거나 업데이트되어야 할 때 해당 코드를 수정하고 관리하는 과정을 말합니다. 소프트웨어가 개발된 후에도 시간이 흐름에 따라 비즈니스 요구 사항이 변경되거나 새로운 기능이 추가되어야 할 수 있습니다. 이러한 변경에 대응하기 위해서는 코드를 수정하고 업데이트하여 새로운 요구 사항을 충족해야 합니다.
1. 버그 수정: 사용자가 발견한 버그를 수정하고 문제를 해결합니다.
2. 기능 추가: 새로운 요구 사항에 따라 새로운 기능을 추가하거나 기존 기능을 개선합니다.
3. 성능 향상: 시스템의 성능을 향상시키기 위해 코드를 최적화하거나 개선합니다.
4. 보안 업데이트: 보안 취약점을 해결하고 시스템을 보호하기 위해 보안 패치를 적용합니다.
5. 기술적 부채 감소: 코드의 가독성을 높이고 중복을 제거하여 기술적 부채를 관리하고 감소시킵니다.
-
소프트웨어는 계속해서 변화하고 발전하기 때문에, 비즈니스 요구 사항에 맞게 소프트웨어를 유연하게 유지해야 합니다.
-
사용자의 요구 사항에 따라 시스템을 지속적으로 개선하고 업데이트하여 사용자 경험을 향상시키기 위해 필요합니다.
-
코드의 유지 보수는 소프트웨어 시스템의 수명을 연장하고 시스템의 가치를 유지하는 데 중요한 역할을 합니다.
따라서 코드의 유지 보수는 소프트웨어 개발의 핵심적인 측면 중 하나이며, 효과적인 유지 보수 전략은 소프트웨어 개발 프로세스의 중요한 부분입니다.
핵심: 유지보수 = 수정, 관리
>> 유지보수(Maintainability)를 위주로 하는 프로그래밍
>> 개발자의 코드 유지보수
3.1 보안 패치란 무엇인가?
보안 패치는 소프트웨어나 시스템에서 발견된 보안 취약점을 해결하기 위한 소프트웨어 업데이트를 말합니다. 보안 패치는 주로 새로운 버전의 소프트웨어나 패치 파일 형태로 제공되며, 보안 취약점이나 악용 가능성이 있는 버그를 수정하거나 보완합니다.
1. 보안 취약점 해결: 소프트웨어의 버전 업데이트나 패치를 통해 발견된 보안 취약점을 해결합니다. 이러한 취약점은 해커가 시스템에 침입하거나 중요한 정보를 탈취하는 등의 공격을 수행할 수 있는 위험한 상황을 초래할 수 있습니다.
2. 시스템 보호 강화: 보안 패치는 시스템의 보안 수준을 높이고 공격으로부터 시스템을 보호하는 데 사용됩니다. 이는 사용자 데이터의 안전성과 개인 정보 보호를 보장하기 위해 중요합니다.
3. 보안 업데이트 배포: 보안 패치는 소프트웨어 개발자나 제조업체가 취약점을 해결하는 데 사용됩니다. 이러한 패치는 보통 업데이트 서비스를 통해 사용자에게 배포됩니다.
4. 최신 보안 기술 적용: 보안 패치는 최신 보안 기술이나 새로운 보안 표준을 적용하여 시스템을 더욱 안전하게 만듭니다. 이는 지속적인 보안 관리와 시스템의 보안 수준을 유지하는 데 중요합니다.
일반적으로 소프트웨어 제조사나 개발자는 보안 취약점이 발견되면 가능한 빠르게 관련 패치를 개발하고 배포합니다. 사용자는 보안 패치를 적용하여 시스템이나 소프트웨어의 보안을 유지하고 최신 보안 문제에 대응할 수 있습니다.
핵심: 보안 패치 = 보안 결함수정
3.1.1 패치란?
"패치"라는 용어는 주로 소프트웨어나 시스템에서 발생하는 버그, 취약점, 오류 등을 수정하기 위한 작은 수정 패키지를 가리킵니다. 이러한 패치는 일반적으로 새로운 버전의 소프트웨어나 시스템의 일부로 제공되거나 따로 다운로드할 수 있습니다.
1. 버그 수정: 소프트웨어나 시스템에서 발견된 버그나 오류를 수정하는 데 사용됩니다. 이러한 패치는 프로그램의 예상치 못한 동작을 수정하고 안정성을 향상시킵니다.
2. 보안 수정: 보안 취약점이 발견되면, 해당 취약점을 해결하기 위한 보안 패치가 배포됩니다. 이러한 패치는 시스템의 보안을 강화하고 중요한 데이터를 보호하는 데 사용됩니다.
3. 성능 향상: 소프트웨어나 시스템의 성능을 향상시키기 위해 새로운 기능이나 최적화된 코드가 포함된 패치가 배포될 수 있습니다.
4. 호환성 문제 해결: 다른 소프트웨어나 시스템과의 호환성 문제를 해결하기 위해 패치가 제공될 수 있습니다.
패치는 일반적으로 이전 버전의 소프트웨어나 시스템을 업그레이드하거나 수정하는 데 사용되며, 사용자가 시스템을 최신 상태로 유지하고 안전하게 유지할 수 있도록 돕습니다.
핵심: 패치 = 결함수정
3.2 기술적 부채란 무엇인가?
기술적 부채(Technical Debt)는 소프트웨어 개발 과정에서 일시적으로 빠른 개발을 위해 고의적으로 또는 무의식적으로 발생하는 부정적인 결과물을 의미합니다. 이는 개발자가 특정 기술적 결정이나 코드 작성 방법을 선택할 때, 미래에 발생할 수 있는 추가 작업이나 수정을 대비하지 않고 단기적인 이득을 위해 선택하는 경우에 발생합니다.
1. 코드 품질 저하: 코드의 가독성이 떨어지거나, 중복된 코드가 존재하거나, 비효율적인 알고리즘이 사용될 수 있습니다.
2. 테스트 부족: 충분한 테스트가 이루어지지 않은 경우, 버그가 발생할 가능성이 높아지며 유지보수가 어려워집니다.
3. 기술적 제약: 미래에 발생할 수 있는 변경이나 확장에 대비하지 않고, 단순하게 현재의 요구사항에만 집중하는 경우가 있습니다.
4. 의존성 관리 부족: 외부 라이브러리나 프레임워크의 버전 관리가 제대로 이루어지지 않거나, 업데이트가 무시될 경우에 발생합니다.
기술적 부채는 초기에는 빠른 개발이 가능하도록 도와주지만, 시간이 지나면서 이로 인해 추가적인 비용과 리스크가 발생할 수 있습니다. 이에 따라 기술적 부채를 관리하고 최소화하는 것이 중요합니다. 기술적 부채를 관리하는 방법으로는 코드 리팩토링, 테스트 주도 개발(TDD), 지속적인 통합(CI), 지속적인 전달(CD) 등의 개발 방법론과 관련된 프로세스를 도입하는 것이 있습니다.
핵심: 기술적 부채 = 미래를 생각 안하고 단기적으로 만들다가 생긴 부정적 결과
>> 기술 부채
3.2.1 라이브러리와 프레임워크란?
라이브러리(Library)와 프레임워크(Framework)는 모두 소프트웨어 개발에서 사용되는 도구이지만, 그 사용 방식과 목적에서 차이가 있습니다.
-
라이브러리는 재사용 가능한 코드와 함수의 모음으로, 특정 기능이나 목적에 따라 구축된 독립적인 소프트웨어 모듈입니다.
-
라이브러리는 주로 개발자가 필요할 때마다 필요한 기능을 호출하여 사용합니다. 즉, 개발자는 라이브러리가 제공하는 기능을 수동으로 호출하여 사용합니다.
-
예를 들어, 데이터베이스 접근, 네트워크 통신, 이미지 처리 등과 같은 기능을 수행하는 라이브러리가 있습니다.
-
대표적인 라이브러리로는 jQuery, Retrofit, Gson 등이 있습니다.
-
프레임워크는 소프트웨어 개발을 위한 구조와 규칙의 집합으로, 개발자가 응용 프로그램의 특정 기능을 구현하는 데 사용됩니다.
-
프레임워크는 일반적으로 제어 역전(Inversion of Control)의 개념을 적용하여 개발자가 특정 규칙에 따라 코드를 작성하도록 유도합니다.
-
개발자는 프레임워크가 제공하는 틀 안에서 필요한 기능을 확장하거나 오버라이드하여 사용합니다.
-
예를 들어, 웹 애플리케이션 개발을 위한 Spring Framework, 안드로이드 애플리케이션 개발을 위한 Android SDK 등이 프레임워크의 예입니다.
라이브러리와 프레임워크의 주요 차이점은 제어 흐름에 대한 주도성에 있습니다. 라이브러리는 개발자가 호출하는 방식으로 개발의 주도성이 개발자에게 있습니다. 반면에 프레임워크는 개발자가 프레임워크가 정의한 규칙에 따라 개발을 진행하므로 프레임워크가 주도성을 가집니다.
따라서, 개발자는 라이브러리를 사용하여 필요한 기능을 추가하거나 확장할 수 있지만, 프레임워크를 사용할 때에는 프레임워크가 정의한 구조와 규칙을 따라야 합니다.
핵심:
라이브러리 = 재사용할 코드와 함수의 모음. 개발자가 주도. 기능추가, 확장 O
프레임워크 = 개발을 위한 구조, 규칙 집합. 개발자가 따라야 함. 구조, 규칙 따라야
+ 모듈이란?
소프트웨어 개발에서 "모듈(Module)"은 소프트웨어를 구성하는 작은 부분이자 독립적인 단위를 말합니다. 모듈은 프로그램 내에서 특정 기능이나 역할을 수행하는 코드의 집합이며, 일반적으로 다른 모듈과 상호작용할 수 있습니다.
1. 독립성(Independence): 모듈은 다른 모듈과 독립적으로 개발되고 테스트될 수 있습니다. 이는 모듈이 다른 모듈에 영향을 주지 않고 독립적으로 수정되거나 업데이트될 수 있음을 의미합니다.
2. 재사용성(Reusability): 모듈은 한 번 개발되면 여러 프로그램이나 시스템에서 재사용될 수 있습니다. 모듈화된 코드는 유지보수가 쉽고, 향후 프로젝트에서 재사용될 수 있는 가치가 있습니다.
3. 추상화(Abstraction): 모듈은 특정 기능이나 역할을 추상화하여 제공합니다. 이는 모듈을 사용하는 개발자가 내부 동작에 대해 자세히 알 필요 없이 모듈의 인터페이스를 통해 기능을 사용할 수 있도록 합니다.
4. 캡슐화(Encapsulation): 모듈은 관련된 코드와 데이터를 하나의 단위로 묶어 캡슐화합니다. 이는 모듈 내부의 구현 세부 사항을 숨기고 외부에서의 접근을 제어함으로써 모듈의 안정성과 보안을 높입니다.
모듈은 소프트웨어의 다양한 부분에서 사용됩니다. 예를 들어, 함수, 클래스, 패키지 등은 모두 모듈의 형태입니다. 모듈은 소프트웨어를 더 나은 구조로 조직화하고 유지 보수성을 향상시키는 데 중요한 역할을 합니다.
핵심: 모듈 = 소프트웨어의 작은 독립단위. 예) 함수, 클래스, 패키지
3.3 비즈니스 요구사항이란 무엇인가?
비즈니스 요구사항이란 비즈니스 관점에서 시스템이나 소프트웨어에 대한 기능적이거나 비기능적인 요구사항을 의미합니다. 쉽게 말해, 비즈니스 요구사항은 조직이나 기업이 소프트웨어나 시스템을 개발하거나 업데이트할 때 원하는 기능, 기대하는 성능, 그리고 사용자 경험 등을 명시한 것입니다.
1. 기능적 요구사항: 시스템이나 소프트웨어가 어떤 기능을 제공해야 하는지에 대한 요구사항입니다. 예를 들어, 사용자 인증, 데이터 검색, 주문 처리 등이 기능적 요구사항에 해당합니다.
2. 비기능적 요구사항: 시스템이나 소프트웨어의 성능, 보안, 확장성, 사용자 경험 등과 같은 품질 측면에 대한 요구사항을 의미합니다. 예를 들어, 응답 시간, 시스템 가용성, 보안 요구사항 등이 비기능적 요구사항에 해당합니다.
3. 사용자 스토리(User Story): 사용자 관점에서 작성된 기능적 요구사항의 한 형태로, 사용자가 시스템이나 소프트웨어를 어떻게 사용할지에 대한 이야기입니다.
4. 요구사항 우선순위: 비즈니스 요구사항에는 우선순위가 있을 수 있습니다. 어떤 기능이나 요구사항이 다른 것보다 중요하거나 긴급한지를 명시할 수 있습니다.
비즈니스 요구사항은 프로젝트의 성패를 좌우하는 중요한 요소로, 이를 명확히 이해하고 문서화하여 개발 과정에서 참고하고 준수해야 합니다. 비즈니스 요구사항을 충족시키지 못하면 프로젝트가 실패할 수 있으며, 비즈니스 요구사항을 충족시키는 것은 프로젝트의 성공에 필수적입니다.
핵심: 비즈니스 요구사항 = 원하고 기대하는 성능
3.3.1 시스템 가용성이란?
시스템 가용성(Availability)은 시스템이 정상적으로 동작하고 사용 가능한 상태로 유지되는 정도를 나타냅니다. 다시 말해, 시스템 가용성은 사용자가 시스템에 접근하여 서비스를 이용할 수 있는 시간의 비율을 의미합니다.
1. 시스템 장애 처리: 시스템이 장애 발생 시 이를 어떻게 처리하고 복구하는지에 따라 가용성이 결정됩니다. 장애 발생 시 빠른 대응과 복구가 이루어져야 합니다.
2. 하드웨어 및 네트워크 신뢰성: 하드웨어 및 네트워크 구성 요소의 신뢰성이 시스템 가용성에 직접적인 영향을 미칩니다. 안정적인 하드웨어 및 네트워크 환경을 유지하는 것이 중요합니다.
3. 자동화된 모니터링 및 경고 시스템: 시스템의 상태를 지속적으로 모니터링하고, 잠재적인 문제가 발생할 경우 빠르게 대응할 수 있는 자동화된 모니터링 및 경고 시스템이 가용성을 향상시킵니다.
4. 데이터 백업 및 복원 정책: 데이터의 백업과 복원 정책이 시스템 가용성에 영향을 줍니다. 데이터가 손실되거나 손상된 경우 빠르고 효율적인 복원이 필요합니다.
시스템 가용성을 높이기 위해서는 이러한 요소들을 고려하여 시스템을 설계하고 구축해야 합니다. 고가용성(High Availability)을 갖는 시스템은 장애 발생 시에도 서비스 중단이 최소화되며, 사용자에게 끊김 없는 서비스를 제공할 수 있습니다. 따라서 많은 기업들이 시스템 가용성을 최대화하기 위해 노력하고 있으며, 이는 비즈니스 연속성을 보장하는 데 중요한 역할을 합니다.
핵심: 시스템 가용성 = 시스템이 정상 동작하고 유지되는 정도
>> 가용성이란?
4. 단위 테스트란 무엇인가?
단위 테스트(Unit Test)는 소프트웨어 개발에서 가장 작은 단위의 코드 조각을 테스트하는 것을 말합니다. 이는 일반적으로 함수, 메소드 또는 클래스와 같은 개별적인 모듈을 테스트하는 것을 의미합니다. 단위 테스트는 소프트웨어의 특정 부분이 의도한 대로 작동하는지 검증하고, 코드 변경이나 리팩토링 후에도 여전히 예상대로 동작하는지 확인하는 데 사용됩니다.
1. 독립성(Independence): 단위 테스트는 다른 부분과 독립적으로 실행될 수 있어야 합니다. 즉, 다른 모듈에 의존성이 없고, 외부 환경에 영향을 받지 않아야 합니다.
2. 자동화(Automation): 단위 테스트는 자동화되어야 합니다. 개발자가 테스트를 실행하고 결과를 확인하는 데에는 최소한의 노력만 필요해야 합니다.
3. 재현성(Repeatability): 단위 테스트는 반복 가능해야 합니다. 같은 입력에 대해 항상 같은 결과를 반환해야 합니다.
4. 빠른 실행 속도(Fast Execution): 단위 테스트는 빠르게 실행되어야 합니다. 이는 개발자가 빠르게 피드백을 받고 코드 변경 사항을 검증할 수 있도록 합니다.
단위 테스트는 일반적으로 테스트 프레임워크를 사용하여 작성되며, 각 테스트 케이스는 특정한 기능이나 동작을 테스트하는 코드 조각입니다. 단위 테스트를 작성하면 소프트웨어의 신뢰성을 향상시키고, 버그를 빨리 발견하여 수정할 수 있습니다. 또한, 코드의 변경이나 리팩토링을 할 때 기존 기능이 올바르게 작동하는지 확인할 수 있습니다.
핵심: 단위 테스트 = 가장 작은 단위 코드(모듈) 테스트
4.1 리팩토링이란?
리팩토링(Refactoring)은 소프트웨어 코드를 변경하여 가독성, 유지보수성, 확장성 등을 향상시키는 과정을 말합니다. 이는 코드의 구조를 개선하고 중복을 제거하여 코드의 품질을 향상시키는 작업을 포함합니다. 리팩토링은 코드의 외부 동작에는 영향을 주지 않으면서 내부 구조를 개선하는 것을 목표로 합니다.
1. 가독성 향상: 코드를 더 명확하고 이해하기 쉽도록 변경하여 다른 개발자가 코드를 더 잘 이해할 수 있도록 돕습니다.
2. 유지보수성 개선: 코드를 더 쉽게 이해하고 수정할 수 있도록 만들어서 향후 변경에 대비합니다.
3. 중복 코드 제거: 코드 중복을 제거하고 일반적인 기능을 추상화하여 코드의 중복을 최소화합니다.
4. 설계 개선: 좋은 소프트웨어 디자인 원칙을 적용하여 코드의 구조를 개선합니다.
5. 안정성 향상: 코드의 안전성을 높이고 버그를 줄이는데 도움을 줍니다.
리팩토링은 코드를 작은 단위로 변경하고, 각 단계마다 테스트를 실행하여 기존 동작이 유지되는지 확인합니다. 이는 리팩토링 작업이 코드의 기능을 손상시키지 않으면서 수행되는 것을 보장합니다.
많은 소프트웨어 개발자와 팀이 지속적으로 리팩토링을 수행하여 코드베이스를 건강하고 유지보수 가능한 상태로 유지하고 있습니다. 리팩토링은 소프트웨어 개발 프로세스의 핵심 요소 중 하나로 간주되며, 코드의 질을 향상시키고 프로젝트의 성공을 보장하는 데 중요한 역할을 합니다.
핵심: 리팩토링 = 코드 내부구조 개선(가독성, 유지보수성, 확장성)
5. 비즈니스 로직이란 무엇인가?
비즈니스 로직은 소프트웨어나 애플리케이션의 핵심 기능이나 규칙을 정의하는 부분을 말합니다. 이는 사용자가 시스템을 사용하는 방식과 시스템이 작동하는 방식을 결정하는 로직입니다.
1. 데이터 처리 규칙: 데이터베이스에서 데이터를 가져오고 저장하는 방법, 데이터의 유효성을 검사하는 방법 등과 같은 데이터 처리 규칙이 비즈니스 로직에 속합니다.
2. 업무 규칙 및 프로세스: 비즈니스에서 특정 업무를 수행하는 방법에 관한 규칙이 비즈니스 로직에 포함될 수 있습니다. 예를 들어, 주문 처리, 결제 처리, 사용자 등록 등의 업무 프로세스가 비즈니스 로직에 해당합니다.
3. 사용자 권한 및 규칙: 시스템 내에서 특정 사용자가 특정 기능을 실행할 수 있는지 여부와 같은 권한 및 규칙이 비즈니스 로직에 포함될 수 있습니다.
4. 알림 및 이벤트 처리: 특정 상황이나 이벤트 발생 시 사용자에게 알림을 보내거나 특정 작업을 수행하는 규칙도 비즈니스 로직에 포함될 수 있습니다.
비즈니스 로직은 주로 소프트웨어의 백엔드 부분에 구현되며, 데이터의 유효성 검사, 데이터의 가공 및 처리, 비즈니스 규칙의 실행 등을 담당합니다. 비즈니스 로직은 소프트웨어의 핵심 부분이므로 정확하고 효율적으로 구현되어야 합니다.
핵심: 비즈니스 로직 = 시스템 사용방식, 작동방식 결정. 백엔드 부분. (데이터 검사, 가공, 처리 등)
6. 프리젠터란 무엇인가?
프리젠터(Presenter)는 소프트웨어 개발에서 사용자 인터페이스(UI)와 비즈니스 로직 사이의 중간 역할을 담당하는 디자인 패턴입니다. 주로 MVC(Model-View-Controller) 또는 MVP(Model-View-Presenter) 아키텍처에서 사용됩니다.
1. 비즈니스 로직과 UI 간의 중계: 프리젠터는 비즈니스 로직과 UI 사이에서 중계자 역할을 합니다. 즉, 사용자의 액션에 따라 UI를 업데이트하고, 사용자 입력을 처리하여 비즈니스 로직을 호출하거나 데이터를 변경합니다.
2. UI 로직 분리: 프리젠터는 UI와 관련된 로직을 분리하여 유지보수성을 향상시킵니다. UI 관련 로직은 프리젠터에서 처리되고, 비즈니스 로직은 모델이나 서비스 계층에서 처리됩니다.
3. 테스트 용이성: 프리젠터는 비즈니스 로직과 UI 로직을 분리함으로써 테스트 용이성을 제공합니다. 비즈니스 로직은 독립적으로 테스트할 수 있으며, UI 로직은 더 이상 테스트할 필요가 없습니다.
4. 상태 관리: 프리젠터는 UI의 상태를 관리하고 업데이트합니다. 사용자의 입력이나 비즈니스 로직의 결과에 따라 UI 상태를 변경하고 업데이트하는 역할을 담당합니다.
프리젠터는 보통 사용자 이벤트를 처리하고, 데이터를 가공하여 뷰에 전달하며, 상태를 관리하고 업데이트합니다. 이는 UI와 비즈니스 로직 사이의 의존성을 줄이고, 코드의 재사용성과 유지보수성을 향상시키는데 도움이 됩니다.
핵심: 프리젠터 = UI와 비즈니스 로직(백엔드) 사이의 중간 역할. MVC, MVP에서 사용.
6.1 UI 로직을 더 이상 테스트할 필요가 없다는 의미는?
"UI 로직은 더 이상 테스트할 필요가 없습니다."라는 문구는 일반적으로 MVP (Model-View-Presenter) 아키텍처에서의 설계 원칙에 기반합니다.
이 문구는 UI 로직이 Presenter로 옮겨졌기 때문에 Presenter를 중심으로 테스트해야 한다는 의미를 가집니다. Presenter는 비즈니스 로직과 UI 간의 중개자로서 역할하며, UI와 상호작용하면서 비즈니스 로직을 호출하거나 데이터를 업데이트합니다.
Presenter는 비즈니스 로직과 UI 로직을 분리하여 UI 로직을 최소화합니다. UI 로직은 주로 화면의 표시와 상태 관리와 같은 단순한 작업을 다룹니다. 이러한 UI 로직은 주로 프레젠터에서 처리되기 때문에 테스트할 필요가 없다고 합니다. 대신에, 프레젠터에 중점을 두고 테스트 케이스를 작성하여 UI와 비즈니스 로직을 테스트합니다.
따라서 "UI 로직은 더 이상 테스트할 필요가 없습니다."는 UI 로직을 테스트하지 않고, 대신 Presenter를 테스트하는 것을 의미합니다. Presenter에 대한 테스트는 사용자의 액션에 대한 반응과 화면의 상태 업데이트가 올바르게 이루어지는지를 확인합니다.
핵심: UI 로직이 프리젠터로 옮겨져서(처리되어) 프리젠터에서 대신 테스트한다.
6.2 뷰에 전달된다는 의미는?
"뷰에 전달하며"는 프리젠터가 가공한 데이터나 상태를 사용자 인터페이스(UI)에 전달하는 것을 의미합니다.
프리젠터는 비즈니스 로직과 UI 간의 중간 역할을 담당하며, 비즈니스 로직을 처리한 결과를 UI에 반영하기 위해 사용됩니다. 이러한 역할에서 프리젠터는 사용자 인터페이스와 데이터 간의 통신을 담당하며, UI의 상태를 업데이트하고 화면에 데이터를 표시합니다.
예를 들어, 사용자가 어떤 액션을 취하면 프리젠터는 해당 액션을 처리하고 필요한 데이터를 준비합니다. 이후에, 프리젠터는 준비된 데이터를 UI에 전달하여 화면에 표시하거나 UI의 상태를 업데이트합니다. 이를 통해 사용자는 프리젠터를 통해 처리된 데이터를 화면에서 확인하고 상호작용할 수 있습니다.
따라서 "뷰에 전달하며"는 프리젠터가 가공된 데이터나 상태를 UI에 전달하여 사용자가 해당 정보를 시각적으로 확인하고 상호작용할 수 있도록 하는 과정을 의미합니다.
핵심: 프리젠터가 비즈니스 로직에서 처리한 결과를 UI에 전달한다.
6.2.1 뷰라는 것이 UI인가?
네, 맞습니다. "뷰(View)"는 사용자 인터페이스(UI)를 구성하는 요소 중 하나입니다. UI는 사용자가 소프트웨어나 애플리케이션과 상호작용하는 부분을 의미하며, 여기에는 화면에 표시되는 모든 요소가 포함됩니다.
뷰(View)는 사용자에게 정보를 표시하거나 사용자의 입력을 받는 역할을 합니다. 예를 들어, 화면에 텍스트, 이미지, 버튼, 입력 필드 등을 표시하는 것이 뷰의 역할입니다. 뷰는 사용자가 소프트웨어나 애플리케이션과 상호작용할 수 있도록 합니다.
따라서 "뷰(View)"와 "UI(User Interface)"는 서로 유사한 의미를 가지며, 일반적으로 UI의 구성 요소 중 하나로 사용됩니다. UI는 뷰(View)뿐만 아니라 컨트롤러(Controller)나 프리젠터(Presenter) 등의 다른 요소도 포함할 수 있습니다. 함께 사용되는 아키텍처나 디자인 패턴에 따라 다른 용어들이 사용될 수 있습니다.
핵심: 뷰 = UI 구성 요소 중 하나. 예) 텍스트, 이미지, 버튼, 입력필드 표시
6.2.2 여기서 비즈니스라는 것의 구체적 의미는?
"비즈니스"는 상업적인 활동이나 사업에 관련된 활동을 가리키는 용어입니다. 여기서 "비즈니스"는 조직이 이윤을 창출하거나 특정 목표를 달성하기 위해 수행하는 활동을 나타냅니다.
"비즈니스 로직"은 소프트웨어 개발에서 사용되는 용어로, 특정 비즈니스 규칙, 정책, 프로세스 및 규정을 의미합니다. 이는 소프트웨어가 특정 비즈니스 목표를 달성하기 위해 수행해야 하는 작업을 정의합니다.
예를 들어, 은행 시스템에서의 비즈니스 로직은 계좌 개설, 입출금 처리, 이체, 대출 신청 및 승인 등과 같은 업무 규칙과 프로세스를 포함할 수 있습니다. 이러한 비즈니스 로직은 은행의 핵심 비즈니스 활동을 지원하고, 고객 서비스를 제공하기 위해 필수적입니다.
따라서 "비즈니스 로직"은 특정 비즈니스 영역에서 수행되는 작업과 프로세스를 컴퓨터가 이해하고 처리할 수 있도록 정의하는 것을 의미합니다. 비즈니스 로직은 주로 소프트웨어의 백엔드 부분에 구현되며, 사용자 인터페이스(UI)와는 독립적으로 동작합니다.
핵심:
비즈니스 = 소프트웨어가 달성해야 할 목표 작업.
비즈니스 로직 = 컴퓨터가 이해, 처리할 수 있도록 정의. 백엔드 부분. UI와 독립적.
7. "MVVM (Model-View-ViewModel): 뷰와 모델 사이에 뷰 모델을 추가" 이것의 의미는?
MVVM (Model-View-ViewModel)은 소프트웨어 개발에서 사용되는 디자인 패턴 중 하나로, 뷰(View)와 모델(Model) 사이에 뷰 모델(ViewModel)을 추가하여 뷰와 비즈니스 로직을 분리하는 패턴입니다. 각 구성 요소는 다음과 같이 정의됩니다:
-
모델은 애플리케이션의 데이터와 비즈니스 로직을 나타냅니다.
-
데이터베이스에서 가져온 데이터, 외부 서비스로부터 수신한 데이터, 사용자가 입력한 데이터 등을 포함합니다.
-
모델은 보통 비즈니스 도메인의 객체나 데이터 구조를 표현하고, 데이터의 유효성을 검증하거나 데이터 조작을 담당합니다.
-
뷰는 사용자 인터페이스(UI)를 나타냅니다.
-
사용자에게 데이터를 표시하고 사용자의 입력을 받습니다.
-
안드로이드 앱에서는 레이아웃(XML 파일) 및 액티비티, 프래그먼트 등이 뷰에 해당합니다.
-
뷰 모델은 뷰와 모델 사이의 중간 계층으로, 뷰와 모델 간의 통신을 촉진하고 비즈니스 로직을 처리합니다.
-
뷰 모델은 뷰가 필요로 하는 데이터를 제공하고, 뷰의 상태를 관리합니다.
-
뷰 모델은 뷰와 독립적으로 테스트할 수 있으며, 보통 안드로이드에서는 LiveData나 RxJava와 같은 라이브러리를 사용하여 데이터의 변경을 관찰하고 뷰에 반영합니다.
-
뷰 모델은 뷰에서 발생한 사용자 입력을 처리하고, 이를 모델에 전달하여 데이터를 업데이트하거나 비즈니스 로직을 수행합니다.
MVVM 패턴은 뷰와 모델 간의 강력한 분리를 가능하게 하며, 안드로이드 애플리케이션의 유지보수성과 확장성을 향상시키는 데 도움이 됩니다. 또한, 코드의 재사용성과 테스트 용이성을 높여줍니다.
핵심:
MVVM = 모델 - 뷰모델 - 뷰
뷰모델로 뷰(UI)와 비즈니스 로직(백엔드)을 분리하는 패턴.
모델 = 데이터, 비즈니스 로직
뷰 = UI
뷰모델 = 뷰에서 입력 처리 -> 모델 전달 -> 데이터 업데이트/비즈니스로직 수행
7.1 비즈니스 도메인의 객체란?
비즈니스 도메인의 객체는 특정 비즈니스 영역이나 도메인에 속하는 데이터나 개념을 나타내는 객체를 말합니다. 이러한 객체들은 해당 비즈니스 도메인에서 중요한 역할을 수행하며, 비즈니스 규칙을 구현하고 도메인 간의 관계를 표현합니다.
1. 계좌 (Account): 은행 계좌를 나타내는 객체로, 계좌 번호, 잔액, 소유자 정보 등의 속성을 포함합니다. 이 객체는 입금, 출금, 잔액 조회 등의 기능을 제공할 수 있습니다.
2. 거래 (Transaction): 계좌 간의 자금 이체를 나타내는 객체로, 송금 계좌, 수취 계좌, 금액, 거래 일시 등의 정보를 포함합니다. 이 객체는 거래의 유효성을 검사하고 처리하는 기능을 수행할 수 있습니다.
3. 고객 (Customer): 은행 고객을 나타내는 객체로, 고객의 신상정보, 계좌 목록, 거래 내역 등을 관리합니다. 이 객체는 고객의 신원을 확인하거나 계좌를 관리하는 기능을 제공할 수 있습니다.
4. 이자율 (InterestRate): 예금 상품의 이자율을 나타내는 객체로, 예금 종류, 이율, 적용 기간 등의 정보를 포함합니다. 이 객체는 이자를 계산하고 적용하는 기능을 제공할 수 있습니다.
비즈니스 도메인의 객체는 해당 비즈니스의 핵심 개념을 객체지향적으로 표현한 것입니다. 이러한 객체들은 비즈니스 로직과 함께 동작하여 비즈니스 요구사항을 충족하고 소프트웨어 시스템을 구현합니다.
핵심: 비즈니스(소프트웨어의 목표 작업의) 도메인(영역에 대한) 객체(개념을 객체지향적 표현)
>> 혼란스러운 도메인, 도메인 모델, 도메인 객체 용어 정리
7.1.1 도메인이란?
"도메인(Domain)"은 특정 주제나 분야를 가리키는 개념으로, 일반적으로 컴퓨터 과학에서는 두 가지 주요 의미로 사용됩니다.
1. 인터넷 도메인: 인터넷에서 도메인은 웹사이트나 네트워크의 주소를 나타냅니다. 이는 일반적으로 도메인 이름(예: example.com)과 그에 대응하는 IP 주소로 구성됩니다.
2. 소프트웨어 개발에서의 도메인: 소프트웨어 개발에서의 도메인은 특정 비즈니스 영역이나 주제를 가리킵니다. 이는 해당 분야의 전문 용어, 규칙, 프로세스 등을 포함하는데, 이를 기반으로 소프트웨어 시스템이 구축됩니다.
따라서 "도메인"이란 소프트웨어 개발에서는 특정 비즈니스 분야를 가리키며, 해당 분야의 개념과 규칙을 모델링하고 구현하는 데 사용됩니다. 도메인 모델은 비즈니스 로직과 데이터 모델링의 기반을 형성하며, 소프트웨어 시스템이 비즈니스 요구사항을 충족시키기 위한 중요한 요소입니다. 도메인 주도 설계(Domain-Driven Design, DDD)와 같은 접근 방식은 소프트웨어 개발에서 도메인 중심의 설계와 개발을 강조합니다.
핵심: 도메인 = 영역
7.2 액티비티와 프래그먼트란 무엇인가?
안드로이드 애플리케이션에서 액티비티(Activity)와 프래그먼트(Fragment)는 사용자 인터페이스(UI)를 구성하는 주요 구성 요소입니다.
-
액티비티는 안드로이드 애플리케이션에서 사용자 인터페이스(UI) 화면을 나타냅니다.
-
액티비티는 일반적으로 하나의 화면을 담당하며, 사용자와 상호작용하고 다른 액티비티로 전환될 수 있습니다.
-
안드로이드 애플리케이션은 하나 이상의 액티비티로 구성될 수 있으며, 각 액티비티는 화면의 레이아웃을 정의하고 사용자 입력을 처리합니다.
-
액티비티의 생명주기 메서드를 통해 액티비티의 상태 변화를 관리하고 애플리케이션의 동작을 제어할 수 있습니다.
-
프래그먼트는 액티비티 내에서 재사용 가능한 UI 요소를 나타냅니다.
-
프래그먼트는 액티비티 내의 일부 UI 영역을 차지하며, 액티비티가 여러 프래그먼트로 구성될 수 있습니다.
-
프래그먼트는 독립적으로 생명주기를 가지며, 액티비티의 생명주기와 관련하여 관리됩니다. 따라서 액티비티 내에서 프래그먼트가 추가되거나 제거될 때 생명주기 메서드가 호출됩니다.
-
프래그먼트는 액티비티와 밀접하게 연결되어 있으며, 액티비티의 UI를 동적으로 관리하고 다양한 화면 크기 및 방향에 대응할 수 있도록 도와줍니다.
액티비티와 프래그먼트는 안드로이드 애플리케이션의 주요 구성 요소로서, 사용자와의 상호작용을 담당하고 애플리케이션의 화면을 구성합니다. 함께 사용되어 복잡한 사용자 인터페이스를 구현하고, 사용자의 다양한 상호작용을 처리할 수 있도록 도와줍니다.
핵심:
액티비티 = UI 화면
프래그먼트 = 액티비티 내에서 재사용 가능한 UI 영역
>> 안드로이드 기초 - 액티비티(Activity)란?
>> 안드로이드 - 프래그먼트(Fragment) 사용하기
7.2.1 생명주기 메서드란?
안드로이드 애플리케이션의 생명주기(Lifecycle) 메서드는 안드로이드 시스템이 애플리케이션의 상태 변화를 관리하고 애플리케이션이 이러한 변화에 응답할 수 있도록 하는 메서드입니다. 안드로이드에서는 애플리케이션이 시작되고 실행되는 동안에 여러 가지 상태 변화가 발생할 수 있습니다. 이러한 상태 변화에 따라 시스템은 애플리케이션에 알리고, 애플리케이션은 이에 대응하기 위해 생명주기 메서드를 호출합니다.
여러분의 액티비티 또는 프래그먼트와 같은 컴포넌트는 생명주기 메서드를 구현하여 시스템의 상태 변화에 대응합니다. 일반적으로 다음과 같은 생명주기 메서드가 있습니다:
1. onCreate(): 컴포넌트가 생성될 때 호출됩니다. 일반적으로 초기화 작업을 수행하는 데 사용됩니다.
2. onStart(): 컴포넌트가 사용자에게 표시되기 시작할 때 호출됩니다. 화면이 표시되기 전에 실행되는 초기화 작업을 수행할 수 있습니다.
3. onResume(): 컴포넌트가 화면 상에 표시되고 사용자와 상호작용할 수 있는 상태가 될 때 호출됩니다.
4. onPause(): 다른 액티비티나 다이얼로그가 포커스를 가져가기 시작할 때 호출됩니다. 사용자의 현재 상태를 저장하거나 일시 중지된 상태를 처리하는 데 사용됩니다.
5. onStop(): 컴포넌트가 더 이상 사용자에게 표시되지 않을 때 호출됩니다. 리소스를 해제하거나 데이터를 저장하는 데 사용됩니다.
6. onDestroy(): 컴포넌트가 소멸될 때 호출됩니다. 사용되지 않는 리소스를 해제하거나 정리 작업을 수행하는 데 사용됩니다.
안드로이드 시스템은 애플리케이션의 상태에 따라 이러한 생명주기 메서드를 호출하여 애플리케이션이 적절하게 동작할 수 있도록 합니다. 애플리케이션 개발자는 이러한 생명주기 메서드를 재정의하여 애플리케이션의 동작을 제어하고 필요한 작업을 수행할 수 있습니다.
핵심: 생명주기 메서드 = 앱의 상태변화에 응답
예) onCreate, onStart, onDestroy 등
>> 안드로이드 액티비티 생명주기(Life Cycle)
>> 의외로 잘 모르는 Fragment의 Lifecycle
+ 컴포넌트란?
"컴포넌트(Component)"는 소프트웨어 개발에서 기능적으로 독립적인 부분을 가리키는 용어입니다. 이 부분은 주로 특정한 기능을 수행하거나 재사용 가능한 요소로 구성됩니다. 안드로이드 애플리케이션에서 컴포넌트는 다양한 형태로 구현되며, 각각의 역할과 특징이 있습니다.
1. 액티비티(Activity): 사용자 인터페이스(UI) 화면을 표시하고 사용자와의 상호작용을 관리하는 컴포넌트입니다. 주로 화면 단위의 독립적인 기능을 제공하며, 애플리케이션의 여러 화면을 담당합니다.
2. 프래그먼트(Fragment): 액티비티 내에서 재사용 가능한 UI 조각으로, 액티비티의 UI를 구성하는데 사용됩니다. 프래그먼트는 액티비티 내의 일부 영역을 차지하고, 독립적인 생명주기를 가지며 액티비티와 분리되어 관리됩니다.
3. 서비스(Service): 백그라운드에서 실행되는 컴포넌트로, 사용자 인터페이스를 가지지 않고 애플리케이션의 백그라운드 작업을 처리합니다. 서비스는 다른 컴포넌트와 독립적으로 실행되며, 오랫동안 실행되거나 시스템 또는 다른 애플리케이션과 상호작용할 수 있습니다.
4. 브로드캐스트 리시버(Broadcast Receiver): 안드로이드 시스템에서 발생하는 브로드캐스트 메시지를 수신하고 처리하는 컴포넌트입니다. 브로드캐스트 리시버는 시스템 또는 다른 애플리케이션의 이벤트에 대한 알림을 받고, 이를 처리하여 특정 동작을 수행할 수 있습니다.
5. 컨텐트 프로바이더(Content Provider): 애플리케이션 간 데이터 공유를 위한 인터페이스를 제공하는 컴포넌트입니다. 데이터베이스, 파일 시스템 또는 네트워크 등 다양한 데이터 소스에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행할 수 있습니다.
이러한 안드로이드 컴포넌트들은 서로 상호작용하여 애플리케이션의 동작을 제어하고 사용자에게 기능을 제공합니다. 개발자는 이러한 컴포넌트들을 조합하여 안드로이드 애플리케이션을 구축하고 사용자에게 효과적인 기능을 제공할 수 있습니다.
핵심: 컴포넌트 = 소프트웨어에서 기능적으로 독립된 부분
예) 액티비티, 프래그먼트, 서비스 등
+ 다이얼로그가 포커스를 가져간다는 것의 뜻은?
다이얼로그(Dialog)는 안드로이드 애플리케이션에서 사용자에게 메시지를 표시하거나 사용자 입력을 요청하기 위해 일시적으로 나타나는 작은 창입니다. 다이얼로그는 사용자와의 상호작용이 필요한 경우에 사용되며, 주로 다음과 같은 목적으로 사용됩니다:
1. 알림 다이얼로그: 사용자에게 메시지를 표시하여 정보를 전달하거나 경고를 제공합니다.
2. 확인 다이얼로그: 사용자의 동의를 요청하거나 특정 작업을 확인합니다.
3. 입력 다이얼로그: 사용자로부터 정보나 데이터를 입력받는 데 사용됩니다.
다이얼로그는 주로 액티비티의 일부로서 생성되거나 액티비티와 관련된 컨텍스트에서 호출되어 사용됩니다. 다이얼로그가 표시되면 사용자는 일반적으로 다이얼로그와 상호작용하며, 필요에 따라 다양한 동작을 수행합니다.
안드로이드 애플리케이션에서 다이얼로그가 포커스를 가져간다는 것은 사용자가 다이얼로그와 상호작용할 때, 애플리케이션의 다른 구성 요소(예: 액티비티)가 포커스를 잃게 되는 상황을 의미합니다. 다이얼로그가 나타나면 일반적으로 사용자의 주의가 다이얼로그로 이동하게 되며, 이때 다이얼로그가 포커스를 가집니다.
예를 들어, 사용자가 애플리케이션 내에서 버튼을 클릭하면 확인 다이얼로그가 표시될 수 있습니다. 이때 다이얼로그가 표시되면 사용자는 확인 또는 취소와 같은 버튼을 클릭하여 다이얼로그와 상호작용하게 됩니다. 이러한 상황에서 다이얼로그가 포커스를 가져가고, 액티비티나 다른 컴포넌트는 포커스를 잃게 됩니다.
따라서 다이얼로그가 포커스를 가져간다는 것은 사용자의 주의가 다이얼로그로 이동되어 다이얼로그와 상호작용할 때 발생하는 상황을 의미합니다.
핵심:
다이얼로그 = 일시적인 창
예) 알림, 확인, 입력 창
다이얼로그가 포커스(주의)를 가져간다 = 액티비티에서 다이얼로그로 주의가 이동
>> 대화상자
+ 리소스가 해제된다는 뜻은 무엇인가?
리소스를 해제한다는 말은 컴퓨터 시스템에서 현재 사용 중인 자원을 해제하고 반환하는 것을 의미합니다. 안드로이드 애플리케이션에서는 주로 메모리 리소스의 해제에 관심이 있습니다.
안드로이드 애플리케이션에서는 메모리 관리가 중요한 부분이며, 사용하지 않는 리소스를 적시에 해제하지 않으면 메모리 누수(memory leak)가 발생할 수 있습니다. 메모리 누수는 시스템 자원이 계속해서 소비되면서 시스템의 성능을 저하시킬 수 있는 문제입니다.
1. 메모리 해제(Memory Deallocation): 이미지, 비트맵, 비디오 등의 큰 리소스를 사용한 후에는 더 이상 필요하지 않은 경우 해당 리소스를 해제하여 메모리를 확보합니다.
2. 파일 자원 해제(File Resource Deallocation): 파일을 읽거나 쓴 후에는 파일 핸들이나 스트림을 닫아야 합니다. 이를 통해 파일 관련 리소스를 시스템에서 해제할 수 있습니다.
3. 네트워크 연결 해제(Network Connection Deallocation): 네트워크 통신 후에는 연결을 적절히 닫아야 합니다. 이는 네트워크 리소스를 효율적으로 관리하고 네트워크 연결에 대한 리소스를 해제하는 데 도움이 됩니다.
리소스를 적절하게 해제하면 애플리케이션의 성능이 향상되고 시스템 리소스가 효율적으로 관리됩니다. 메모리 누수를 방지하고 애플리케이션의 안정성을 유지하기 위해 리소스를 적절하게 해제하는 것이 중요합니다.
핵심: 리소스 해제 = 현재 사용 자원 반환 (메모리)
'혼공노트' 카테고리의 다른 글
| 코틀린에 대한 작은 정리 (1) (0) | 2024.04.03 |
|---|---|
| 안드로이드 ViewModel을 공부해보자 (with ChatGPT) (3) (0) | 2024.02.28 |
| 안드로이드 ViewModel을 공부해보자 (with ChatGPT) (2) (0) | 2024.02.24 |
| 오일러의 공식 (2) 세계에서 가장 아름다운 공식 (0) | 2022.12.15 |
| 오일러의 공식 (1) 멱급수, 매클로린 급수 (0) | 2022.12.14 |
댓글