앞서 매니페스트가 무엇인지 다루었던 포스트에서
<activity> Activity, <service>의 Service, <receiver> Broadcast Receiver, <provider> Content Provider을 4대 컴포넌트라고 말씀 드렸죠?!
오늘은 그 4대 컴포넌트가 무엇인지
세세하게 알아보는 시간을 가지도록 하겠습니다.
Activity
사용자와 상호작용하기 위한 진입점으로 사용자 인터페이스를 포함한 화면 하나를 나타냅니다.
구글 이메일의 이메일 목록을 표시하는 액티비티
예를 들어 이메일 앱이라면
새 이메일 목록을 표시하는 액티비티가 하나 있고, 이메일을 작성하는 액티비티가 또 하나, 그리고 이메일을 읽는 데 쓰는 액티비티가 또 하나 있을 수 있습니다.
여러 액티비티가 함께 작동하여 해당 이메일 앱에서 짜임새 있는 사용자 환경을 구성하는 것은 사실이지만, 각자 서로 독립되어 있습니다.
따라서 이메일 앱에서 허용할 경우 다른 앱이 이런 액티비티 중 하나를 시작할 수 있습니다.
예를 들어 카메라 앱이라면 이메일 앱 안의 액티비티를 시작하여 사용자가 새 이메일을 작성하고 사진을 공유하게 할 수 있습니다.
<액티비티가 시스템과 앱의 상호작용 돕는방법>
1. 사용자가 현재 관심을 가지고 있는 사항(화면에 표시된 것)을 추적하여 액티비티를 호스팅하는 프로세스를 시스템에서 계속 실행하도록 합니다.
2.이전에 사용한 프로세스에 사용자가 다시 찾을 만한 액티비티(중단된 액티비티)가 있다는 것을 알고, 해당 프로세스를 유지하는 데 더 높은 우선순위를 부여합니다.
3. 앱이 프로세스를 종료하도록 도와서 이전 상태가 복원되는 동시에 사용자가 액티비티로 돌아갈 수 있게 합니다.
4. 앱이 서로 사용자 플로우를 구현하고 시스템이 이러한 플로우를 조정하기 위한 수단을 제공합니다.
Service
서비스는 백그라운드에서 앱을 계속 실행하기 위한 다목적 진입점입니다.
이는 백그라운드에서 실행되는 구성 요소로,
오랫동안 실행되는 작업을 수행하거나 원격 프로세스를 위한 작업을 수행합니다.
서비스는 사용자 인터페이스를 제공하지 않습니다.
예를 들어 서비스는 사용자가 다른 앱에 있는 동안에 백그라운드에서 음악을 재생하거나, 사용자와 액티비티 간의 상호작용을 차단하지 않고 네트워크를 통해 데이터를 가져올 수도 있습니다.
다른 구성 요소(예: 액티비티)가 서비스를 시작한 다음 실행되도록 두거나 자신에게 바인딩하여 상호작용하게 할 수도 있습니다.
서비스가 백그라운드에서 시스템에 앱 관리 방법을 지시히는 것은 두가지 체계로 되어 있습니다.
1. 사용자가 바로 인식할 수 있는 작업: 음악 재생 등
앱은 사용자에게 이와 관련된 알림을 보내고 음악재생을 포그라운드로 옮기 라고 시스템에 지시합니다. 이때 시스템은 사용자가 불편함을 느끼지 않도록 프로세스가 계속 실행시켜야 합니다.
2.사용자가 바로 인식하지 못하는 작업: 데이터 동기화 등
사용자가 잘 인식하지 못하므로 자유롭게 프로세스를 관리할 수 있습니다. 도중에 사용자와 좀더 직접적인 관련이 있는 작업에 RAM이 필요할 경우 해당 서비스를 종료할 수 있습니다.(그런 다음, 나중에 서비스를 다시 시작할 수 있습니다.)
바인딩된 서비스
바인딩된 서비스는 다른 앱(또는 서비스)에서 서비스를 사용하고 싶다는 의향을 표현했기 때문에 실행됩니다. 이는 서비스가 다른 프로세스에 API를 제공하게 됩니다. 따라서 시스템은 프로세스 사이에 종속성이 있는지 알게 됩니다.
예를 들어 프로세스 A가 프로세스 B의 서비스에 바인딩되어 있을 경우,
시스템은 프로세스 A를 위해 프로세스 B를 실행해야 한다고 인식하고, 사용자가 프로세스 A에 관심을 갖고 있으면 시스템에서 프로세스 B도 사용자가 관심을 기울이는 것처럼 취급해야 합니다.
Broadcast Receiver
Broadcast Receiver는 시스템이 정기적인 사용자 플로우 밖에서 이벤트를 앱에 전달하도록 지원하는 구성 요소로, 앱이 시스템 전체의 브로드캐스트 알림에 응답할 수 있게 합니다.
Broadcast Receiver도 앱으로 들어갈 수 있는 또 다른 명확한 진입점이기 때문에 현재 실행되지 않은 앱에도 시스템이 브로드캐스트를 전달할 수 있습니다.
예를 들어 앱이 사용자가 알람을 예약한 경우, 그 알람을 앱의 Broadcast Receiver에 전달하면 알람이 울릴 때까지 앱을 실행하고 있을 필요가 없습니다. 그래서 대부분의 브로드 캐스트는 배터리가 부족하다거나 화면을 캡처했을 때 등의 시스템에서 발생하는 경우가 많습니다.
브로드캐스트 리시버는 사용자 인터페이스를 표시하지 않지만, 상태표시줄 알람으로 사용자에게 알립니다. 이런 특성상 대부분 메인 역할을 하기보다 진입점으로서 역할을 하게 됩니다.
Contents Receiver
콘텐츠 제공자는 파일 시스템, SQLite 데이터베이스, 웹상이나 앱이 액세스할 수 있는 다른 모든 영구 저장 위치에 저장 가능한 앱 데이터의 공유형 집합을 관리합니다. 다른 앱은 콘텐츠 제공자를 통해 해당 데이터를 쿼리하거나, 콘텐츠 제공자가 허용할 경우에는 수정도 가능합니다.
(쿼리하다: 데이터베이스에 정보를 요청하다)
예를 들어 Android 시스템은 사용자의 연락처 정보를 관리하는 콘텐츠 제공자를 제공합니다. 적절한 권한을 가진 앱이라면 콘텐츠 제공자를 쿼리하여 특정한 인물에 대한 정보를 읽고 쓸 수 있습니다.
보통 앱에서 콘텐츠제공자에 빌드된 API 및 지원이 많기 때문에 데이터 베이스에 대한 추상화로 생각하기 쉬우나 시스템 설계의 관점에서 보면 핵심 목적이 다른데요
<시스템의 입장>
콘텐츠 제공자는 URI 구성표로 식별, 이름이 지정된 데이터 항목을 게시할 목적으로 앱에 진입하기 위한 입구
(URI : 웹 서버가 리소스를 고유하게 식별할 수 있도록 하는 것, URL과 URN이 있으며 일반적으로 URL을 사용)
☞앱에서 URI 네임스페이스에 넣을 데이터를 매핑할 방식을 결정
→해당 URI를 다른 엔터티에 전달
→ 전달받은 엔터티는 URI를 사용해 데이터에 액세스
콘텐츠 제공자는 앱 전용이기에 공유되지 않는 데이터를 읽고 쓰는데도 유용합니다.
Menifest의 4대 컴포넌트 다들 잘 아셨을까요?
단어들이 어렵지 않나요?ㅜㅜㅜ
저도 모르는 단어 하나하나 찾아가면서 공부했답니다ㅜㅜㅜ
그래도 앱개발을 위해 모두 화이팅 입니다!!
[출처 : 안드로이드 개발 가이드 - App Manifest.xml]