안드로이드 어플에는 네가지 설계요소가 있다.
- Activity
- Broadcast Intent Receiver
- Service
- Content Provider
모든 어플이 네가지 요소 다 필요한건 아니다. 그러나 당신의 어플은 이 네가지 요소의 조합으로 이루어질 것이다.
일단 당신의 어플에 필요한 컴포넌트를 정해야 한다. AndroidManifest.xml 파일안에 그것들을 리스트화 해야한다. 이것은 당신이 어플의 구성요서를 정의하고 컴포넡트들의 특성과 요구사항을 선언해 놓는 xml파일이다. Android manifest file document 에 더 자세히 나와있다.
Activity
Activites는 안드로이드 네가지 설계구성중 가장 일반적인 요소이다. activity는 대개 어플에 단일 스크린이다. 각 activity는 Activity 기본 클래스를 확장한 단일 클래스이다. 클래스는 Views 로 구성된 사용자 인터페이지를 보여주고 이벤트에 응한다. 많은 어플들이 다중 스크린으로 구성되는데 예로들면, 텍스트 메시징 어플은 메세지 보내기 위한 컨택 리스트들을 보여주는 하나의 스크린, 선택된 컨택에 메세지를 쓰기위한 두번째 스크린, 설정변경 또는 이전 메세지 다시보기 위한 다른 스크린들을 가지고 있다. 이러한 각각의 스크린들은 Activity로서 구현된다. 다른 스크린으로의 이동은 새로운 activity를 구동함으로서 이루어진다. 일부 경우에는 activity가 이전 activity에 값을 리턴할 수도 있다 (예로, activity 사용자에게 사진을 선택하게 하는 activity는 호출자에게 선택된 사진을 리턴해준다.)
Intent and Intent Filters
안드로이드는 스크린에서 다른 스크린으로 이동하기 위한 Intent라는 특별한 클래스를 사용한다. intent는 어플이 하고싶은 것를 서술한다. intent data struct의 두가지 가장 중요한 점은 action 과 연동되는 data이다. action 위한 전형적인 값들은 MAIN(어플의 대문이라고 할수있는), VIEW, PICK, EDIT,등이있다. 이 데이터는 URI로 표현된다. 예로, 인물의 컨택정보를 보여주기 위해 VIEW action를 가진 intent, 인물을을 표현하기 위한 URI에 data set을 만들어야 한다.
IntentFilter라 불리는 관련 클래스들이 있다. intent는 어떤일을 하기 위해 효과적인 요청방법인 반면에 intent filter는 activity(또는 BroadcastReceiver, 나중에 나옴)가 무엇을 다룰것인지 의도하는 것의 기술한 것이다. 인물 컨택 정보를 나타낼 수 있는 activity 는 인물을 나타내는 정보에 적용되는 action VIEW를 어떻게 다룰것인지 알고 있는 걸 말해주는 intentFilter를 만들어낸다. Activites는 그들의 intentFilters를 AndroidManifest.xml 파일에 써놓는다.
스크린에서 다른 스크핀으로의 이동은 intents 결정으로 실행된다. 앞으로 갈때 activity는 startActivity(myIntent)를 호출한다. 시스템은 모든 설치된 어플을 위한 intent filter들을 확인하고 intent filter들이 myintent에 최적으로 매치되는 activity를 골라낸다. 그 새로운 activity가 구동되기 위해 연관된 intent로부터 알게 된다. intent 결정의 단계는 startActivity이 호출되는 실행시에 일어나며, 두가지 장점을 제공한다.
- Activities는 Intent 형식으로 요청함으로서 쉽게 다른 컴포넌트로 부터 재사용성이 가능하다.
- Activities는 동등한 IntentFilter를 가진 새로운 Activity의해 언제든 대체 가능하다.
Broadcast Intent Receiver
여러분이 외부 이벤트 즉, 예로들어 폰이 울릴때나 데이터 네트웍이 사용가능할 때 또는 한밤중일때 등의 대응을 수행하기 위해 어플에 코딩할때 BroadcastReceiver를 사용해라. 비록 만약 관심끌 무슨일이 일어난다면 사용자에게 경고하기 위해 NotificationManager를 사용한다고 해도 BroadcastReceivers 는 UI를 나타내는 것이 아니다. BroadcastReceivers는 AndroidManifest.xml에 등록되지만 context.registerReceiver() 를 사용한 코드로 부터 BroadcastReceiver를 등록할 수도 있다. BroadcastReceivers가 호출되기 위해 어플이 실행할 필요는 없다. 그 시스템은 어플을 구동시킬 것이며, 만약 필요하다면 BroadcastReceiver가 시작될 때 어플은 자신의 intent broadcasts 를 Context.sendBroadcast()를 가지고 역시 다른 곳으로 보낼 것이다.
Service
Servide는 UI없이 오랫동안 살이있고 실행되는 코드들이다. 좋은 예로는 재생리스트로부터 음악을 재생하는 media player를 들 수 있다. media player 어플에는 사용자에서 노래를 선택하고 재생을 허용하는 하나또는 그이상의 activitie들로 되어있을 것이다. 그러나 음악 자체 재생은 activity의해 다루어지면 안된다. 왜냐면 사용자는 음악이 새로운 스크린으로 이동후에도 계속적으로 재생되길 바랄것이다. 이런경우, media player activity는 Context.startService()를 사용해 배경으로 음악이 계속 재생되는 서비스를 구동할 수 있다. 그 시스템은 끝날때 까지 실행중인 음악 재생 서비스를 계속 유지할 것이다.(Life Cycle of an Android Application 을 읽어보면 시스템에서 서비스에 주어진 우선순위에 대해 더 알수 있다.) Context.bindService() 로 서비스(만약 이미 실행중이 아니라도 시작하는)에 접근할 수있다. 여러분이 서비스에 접근할 때, 여러분은 서비스에 의해 나타난 인터페이스를 통해 서비스와 통신할 수 있다. 뮤직 서비스를 위해 pause, rewind, 그외도 될 것이다.
Content Provider
어플은 파일, SQLite 데이터베이스, 또는 가능한 여타 다른 장치에 데이터를 저장할 수 있다. 그러나 content Provider는 만약 여러분이 어플의 데이터를 다른 어플과 공유하고 싶다면 매우 유용하다. content provider는 다른 어플이 content provider 의해 다뤄지는 데이터의 타입을 저장하고 불러내기 위해 일련의 표준 메소드를 구현해 놓은 클래스이다.
content Provider에 대해 더 알고 싶으면 Accessing Content Proviers 문서를 보아라.
