Android

SOLID = 객체 지향 프로그래밍 및 설계에 대한 5가지 원칙, 유지보수와 확장이 쉬운 애플리케이션을 위해 사용함모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함소프트웨어가 확장에 대해서는 열려 있어야 하고, 수정에 대해서는 닫혀 있어야

애플리케이션 환경에 대한 전역적인 정보를 얻을 수 있는 추상 클래스애플리케이션의 현재 상태를 가지고 있음 안드로이드 앱은 여러 개의 화면으로 구성되어 있고, 각 화면은 해당 화면의 정보를 가지고 있는 context를 가지고 있음 액티비티나 애플리케이션 전역에 대한 정보

= androidx.lifecycle 패키지액티비티 또는 프래그먼트 같은 다른 컴포넌트의 생명 주기 상태가 변경될 때 이에 대응하는 라이브러리 -> 더욱 체계적으로 구성하고, 가벼운 코드를 유지보수하기 쉬움why?일반적으로 액티비티 및 프래그먼트의 생명주기 메소드에서

애플리케이션 구조를 모델, 뷰, 컨트롤러 세 가지 주요 측면으로 관심사를 분리함웹에서 적용된 MVC는 View와 Control이 완전히 분리된 상태지만, 안드로이드에서는 View와 Control이 함께 공존함가장 오래된 패턴이며 현재 안드로이드에서 잘 쓰이지 않음..앱

안드로이드 스레드는 크게 1개만 존재하는 메인 스레드와 여러 개가 존재할 수 있는 백그라운드 스레드로 나눌 수 있음안드로이드 시스템은 새로운 앱을 실행하면 새로운 리눅스 프로세스를 시작함 기본적으로 메인 액티비티를 비롯한 모든 컴포넌트는 단일 프로세스 및 메인 스레드에

API 통신을 위해 구현된 OkHTTP의 HTTP 통신을 간편하게 만들어주는 라이브러리Async Task가 없이 백그라운드 스레드를 실행 -> Callback을 통하여 메인 스레드에서 UI를 업데이트동일 Squarup사의 OkHttp 라이브러리의 상위 구현체https&

자신이 실행된 스레드를 정지시키지 않으면서, 비동기적으로 실행되는 비동기적인 코드 블록 스레드는 CPU 사용과 시스템 오버헤드라는 관점으로 볼 때 유한한 리소스라는 점이 문제임내부적으로 스레드 생성, 스케줄링, 파기를 위해 많은 작업이 진행됨 현대적인 CPU들은 수많은

관찰 가능한 데이터 클래스데이터 바인딩의 Observable 클래스나 Rxjava의 Observable과는 달리 LiveData는 Lifecycle을 통해 생명 주기를 인식함데이터의 변경을 활성화된 관찰자(Observer)를 통해 알리고, 주어진 LifecycleOwn

데이터가 변경될 때 이벤트를 발생시켜서 데이터를 계속해서 전달하도록 하는 프로그래밍 방식기존 명령형 프로그래밍에서는 데이터의 소비자는 데이터를 요청한 후 받은 결과값을 일회성으로 수신하지만, 이러한 방식은 데이터가 필요할 때마다 결과값을 매번 요청해야 한다는 점에서 매

사용자의 상호작용에 따라 화면 간의 이동을 구현하는 데 도움을 주는 Jetpack 라이브러리 Jetpack 라이브러리 중에서 직관적인 편이라 이해하기 쉬웠다

코드를 추가하기 전에 pubspec.yaml 파일에 location 패키지를 설치해주어야 한다앱 최초 실행 시에는 위치 권한 허용 여부를 묻는 알림창이 뜬다출처 - https://codesundar.com/flutter-geolocation-example/

안드로이드 앱을 배포하기 위해 AAB 파일을 생성하는 도중 위와 같은 에러가 떴다그냥 안드로이드 스튜디오를 관리자 권한으로 실행하면 해결된다ㅎ