안드로이드에는 4가지 컴포넌트가 있음.

Activity, Service, BroadcastReceiver, ContentProvider

Activity는 사용자 인터페이스 Service는 백스라운드에서 실행할 작업 BroadcastReceiver는 시스템 이벤트를 수신 ContentProvider는 애플리케이션 데이터를 저장

Activity

애플리케이션에서는 각기 다른 기능의 Activity를 여러 개 가질 수 있지만, 특정 시점에 보여줄 수 있는 Activity는 한 개뿐. 다양한 생명주기 콜백을 통해 현재 상태를 알려준다.

또한 액티비티에서는 UI와 관련한 작업만을 처리하도록 권장 물론 AsyncTask나 Handler를 활용해 메인 스레드 밖에서 작업을 수행할 수 도 있지만 이러한 작업은 별로 Servic에 위임함을 권장함.

Service

일반적인 사용자 인터페이스와 상관없는 작업할때 수행됨. 그리고 AsyncTask나 Handler를 활용해 UI업데이트를 할 때에는 액티비티내 백그라운드 스레드가 아니라 아예 Service로 옮기는게 좋다.

BroadcastReceiver

특수 컴포넌트로서, 무상태. 이말은 즉슨! onReceive 호출 내에서만 유효하다는 뜻. 이 는 한 가지 작업에만 유용하게 활용할 수 있는데, 그것이 바로 시스템 이벤트를 리스닝하는 것이다. 안드로이드 SDK에는 수많은 BroadcastIntent가 정의되어 있고, 이는 API에서 여러 클래스로 나뉘어 있다.

또한 이 컴포너는는 서비스나 액티비티내에서 프로그래밍적으로 선언할 수 있다는 점에서도 특별하다. 그렇기에 항상 등록/해제를 해주어야한다.

ContentProvider

애플리케이션에서 데이터를 저장하는 것.

1. SharedPreferences
2. SQLlite

Application컴포넌트

잘 사용은 안하지만, 액티비티 서비스 브로드캐스트보다 더 먼저 생성되는 최상위레벨 컴포넌트이다.

안드로이드는 항상 하나의 Application컴포넌트를 가지고 있으며, 정의하지 않으면 하나를 자동으로 생성된다. 모든 안드로이드에서 변수를 공유하거나 컴포넌트 사이에서 서로 통신할 떄 활용할 수있다. 물론 싱글턴 클래스를 활용하더라도 전역 상태를 공유할 수 있지만 Application컴포넌트를 사용하면 애플리케이션 생명주기 콜백을 구현하므로 추가 장점이 있다.

어플리케이션 아키텍처.

컴포넌트를 토대로 전체 아키텍처의 개요를 그리는 것을 권창, 이때 처음에 필요한 Activity 및 Service가 무엇인지 스스로에게 질문하고, 이어서 브로드캐스트 이벤트 및 ContentProvider를 고려한다. Activity에는 프래그먼트를 활용한 동적인 사용자 인터페이스가 들어 있을 수도 있으므로 이 아키텍처는 애플리케이션의 실제 사용자 인터페이스를 반영하지 않아도 된다.

그림 참조하기. 3-1

안드로이드 애플리케이션 매니페스트

매니페스트는 각 컴포넌트를 정의하고 애플리케이션에 대한 상세 정보를 정의하는 XML

가장 중요한 요소임!!!

1. Manifest엘리먼트. 이 엘리먼트에는 패키지명, 애플리케이션의 고유 식별자를 정의한다. 또 리눅스 사용자ID, 애플리케이션의 실행중 이름, 버전 정보, APK파일의 설치 위치를 정의.

2. 구글 플레이 필터 및 퍼미션