반응형

개요

안드로이드에서, 앱에 들어갈 수 있게 하는 것을 컴포넌트라고 칭합니다.
즉, 각 컴포넌트 안드로이드 앱에 대한 진입점(entry)라고 말할 수 있습니다.

또한, 안드로이드 앱(Android app)은 안드로이드 컴포넌트들로 이루어져있는 데요,
(즉, 안드로이드 컴포넌트란, 안드로이드 앱(Android app)의 필수적인 빌딩 블록을 말합니다.)

진입점들의 특징을 알아봅시다.
(총 4개가 있습니다, 액티비티, 서비스, Broadcast Receiver, ContentProvider)


정리
- 컴포넌트들시스템 혹은 유저가 우리의 앱에 들어갈 수 있게하는 진입점들이다.

액티비티 (Activities)

- 액티비티는 사용자와 상호작용하기 위한 진입점임.
- 액티비티는 인터페이스를 포함한 화면 하나를 나타냄.
예를 들어, 이메일 앱이면,
1) 새 이메일 목록을 표시하는 액티비티 하나, (화면 하나)
2) 이메일을 작성하는 액티비티 하나. (화면 하나)
3) 이메일윽 읽는데 쓰는 액티비티 하나. (화면 하나)
이렇게 3개의 화면, 즉 3개의 액티비티 구성으로 인터페이스를 구성하여, 이메일 앱을 만들 수 있음.

- 여러 액티비티가 함꼐 동작해서, 이메일 앱을 구성하는 건 맞지만, 액티비티는 각자 서로 독립되어 있음.
예를 들어, 카메라 앱이면, 이메일 앱 안에 액티비티를 시작하여,

- 액티비티를 하나의 Activity 클래스의 하위 클래스로 구현해야함.

서비스 (Service)

- 서비스특수한 목적으로 백그라운드에서 앱을 실행하기 위한 다목적 진입점임.
즉, 1) 오랫동안 실행되는 작업을 수행하거나,
2) 원격 프로세스를 위한 작업을 수행.
- 서비스는 사용자 인터페이스를 제공하지 않음.
(e.g. 서비스는 사용자가 다른 앱에 있는 동안, 사용자와 액티비티 간의 상호작용을 차단하지 않고, 네트워크를 통해 데이터를 가져올 수 있음.)
- 액티비티 (혹은, 다른 구성요소)가 서비스를 시작하게 한 다음,
실행되도록 두거나, 그 해당 액티비티와 바인딩하여 상호작용할 수도 있음.
- 시작된 서비스는 작업이 완료될 떄 까지 (소멸되기 전까지) 해당 서비스를 계속 실행하라고, 시스템에게 지시함. (e.g. 백그라운드에서 데이터를 동기화하거나, 사용자가 앱을 종료후, 음악(멜론)앱을 재생하는 서비스의 예시임)
바인딩된 서비스
- 바인딩된 서비스(Bound services)는 다른 앱(또는 서비스)에서 서비스를 사용하고 싶다는 의향을 표현하면, 실행됩니다.
- 바인딩된 서비스 개념은은 기본적으로 서비스가 다른 프로세스(서비스, 앱 등)에 API를 제공하는 것과 같음.
- 그래서, 시스템은 프로세스 사이에 종속성이 있는지를 알게됨.
(즉, 프로세스 A가 프로세스 B의 서비스에 바인딩되어 있을 경우, 시스템은 프로세스 A를 위해 프로세스 B를 실행해야 한다는 것을 인식하게됨)

아래와 같은 애플리케이션이, 시스템에서 애플리케이션을 실행할 때, 바인딩하는 서비스로 빌드됨.
- 라이브 배경화면, 알림 리스너, 화면보호기, 입력 메서드, 전급성 서비스 등

- 서비스는 Service 하위 클래스로 구현됨.

Broadcast Receiver

(브로드캐스트는 보통 방송, 즉, 불특정다수에게 같은 정보를 보내는 것을 의미한다.)

- Broadcast Receiver는 시스템이 정기적인 사용자 플로우 밖에서, 이벤트를 앱에 전달하도록 지원하는 구성 요소임
- 안드로이드 앱이 시스템 전체의 브로드캐스트 알림에 응답할 수 있게 함.
- Broadcast Receiver도 앱으로 들어갈 수 있는 진입점
- 그렇기 때문에, 현재 실행되지 않은 앱에도 시스템이 브로드캐스트를 전달할 수 있습니다.
(예를 들어 앱이 사용자에게 예정된 이벤트에 대해 알리는 알림을 게시하기 위한 알람을 예약할 경우, 그 알람을 앱의 Broadcast Receiver에 전달하면 알람이 울릴 때까지 앱을 실행하고 있을 필요가 없습니다.)

- 대다수의 브로드캐스트는 시스템에서 발생합니다.
(예컨대 화면이 꺼졌거나 배터리가 부족하거나 사진을 캡처했다고 알리는 브로드캐스트가 대표적입니다.)

- 앱도 브로드캐스트를 전송할 수 있음
(예를 들어 다른 앱에 일부 데이터가 기기에 다운로드되었고 이를 사용할 수 있다는 것을 알리는 데 사용합니다.)

- Broadcast Receiver는 사용자 인터페이스를 표시하지 않지만, 상태 표시줄 알림을 생성하여 사용자에게 브로드캐스트 이벤트가 발생했다고 알릴 수 있습니다.
-
다만 Broadcast Receiver는 그저 다른 구성 요소로의 게이트웨이인 경우가 더 보편적이고, 극소량의 작업만 수행하도록 만들어진 경우가 많습니다. (브로드캐스트 리시버 안에 많은 작업/연산을 포함하면 안됨)
(예컨대 JobService를 예약하여 시작하여 JobScheduler가 포함된 이벤트를 기초로 어떤 작업을 수행하게 할 수 있습니다.)

- Broadcast Receiver는 BroadcastReceiver의 하위 클래스로 구현되됨
- 각 Broascast는 Intent 객체로 전달됩니다. (중요)

Content providers (콘텐츠 제공자)

- 콘텐츠 제공자는 파일 시스템, SQLite 데이터베이스, 웹상이나 앱이 액세스할 수 있는 다른 모든 영구 저장 위치에 저장 가능한 앱 데이터의 공유형 집합을 관리함.

- 다른 앱은 콘텐츠 제공자를 통해, 해당 데이터를 쿼리하거나, 콘텐츠 제공자가 허용할 경우에는 수정도 가능합니다.
(예를 들어 Android 시스템은 사용자의 연락처 정보를 관리하는 콘텐츠 제공자를 제공합니다. 적절한 권한을 가진 앱이라면 콘텐츠 제공자(예: ContactsContract.Data)를 쿼리하여 특정한 인물에 대한 정보를 읽고 쓸 수 있습니다.)

- 콘텐츠 제공자를 데이터베이스에 대한 추상화로 생각하기 쉽습니다. 이런 일반적인 사례에 대해 콘텐츠 제공자에 빌드된 API 및 지원이 많기 때문입니다. 다만 시스템 설계 관점에서 볼 때 핵심 목적이 서로 다릅니다. 시스템의 경우 콘텐츠 제공자는 URI 구성표로 식별되고 이름이 지정된 데이터 항목을 게시할 목적으로 앱에 진입하기 위한 입구입니다.

- 따라서 앱에서 URI 네임스페이스에 넣을 데이터를 매핑할 방식을 결정하고, 해당 URI를 다른 엔터티에 전달할 수 있습니다. 이를 전달받은 엔터티는 URI를 사용하여 데이터에 액세스합니다. 시스템이 이렇게 할 수 있는 데에는 앱 관리에 몇 가지 특별한 점이 있기 때문입니다.
- URI를 할당하더라도 앱을 계속 실행할 필요가 없으므로 URI를 소유한 앱이 종료된 후에도 URI를 유지할 수 있습니다. 시스템은 URI를 소유한 앱이 해당 URI에서 앱의 데이터를 검색할 때만 실행되도록 하면 됩니다.
- 이 URI는 중요하고 조밀한 보안 모델을 제공합니다. 예를 들어 앱은 클립보드에 있는 이미지에 URI를 할당하고 콘텐츠 제공자가 검색하도록 하여, 다른 앱이 자유롭게 이미지에 액세스하지 못하게 막을 수 있습니다. 두 번째 앱이 클립보드에서 해당 URI에 액세스하려고 시도하면 시스템에서는 임시 URI 권한을 부여하여 그 앱이 데이터에 액세스하도록 허용할 수 있습니다. 따라서 두 번째 앱에서는 URI 뒤에 있는 데이터 외에 다른 것에는 액세스할 수 없습니니다.

- Content providers는 ContentProvider의 하위 클래스로 구현됨.
다른 앱이 트랜잭션을 수행할 수 있도록, 활성화하는 표준적인 API 집합을 구현해야함.

4대 구성요소들의 특징

- Android 시스템 디자인은, 어떤 앱이든 다른 앱의 4대 구성 요소를 시작할 수 있음. (중요, 한 앱이, 다른 앱을 시작할 수 있음)
- 즉, 사용자가 기기 카메라로 사진 캡처하는 경우, 그런 작업을 수행하는 다른 앱이 있을 가능성이 높아, 사진을 캡쳐하는 액티비티를 직접 개발하는 대신, 내가 가진 앱에서 그 앱을 사용하면 됨.
그저, 사진을 캡처하는 카메라 앱에서, 액티비티를 시작하기만 하면 됨.
이 때, 작업이 완료되면, 사진이 앱으로 반환되기까지 하여 바로 사용 가능. (사용자에게는 마치 카메라가 앱의 일부분인 것 처럼 보임)

출처/인용

https://developer.android.com/guide/components/fundamentals

반응형