Android Application의 해부

※ 이 글은 http://android-runner.springnote.com/pages/2691246 에서 가져와 조금 수정하였습니다. 

안드로이드 어플리케이션에는 네 가지의 구현 요소가 있다.
        

  • Activity
  • Intent Receiver
  • Service
  • Content Provider

모든 어플리케이션이 네 가지 요소 모두를 사용하는 것은 아니고, 이 네 가지 요소 중 일부의 조합으로 이루어지게 된다. 일단 만들고자 하는 어플리케이션이 필요로 하는 컴포넌트를 결정하면. 컴포넌트 목록을 AndroidManifest.xml 파일에 기록해야 한다. 이 xml 파일은 어느 어플리케이션에서 어떤 컴포넌트를 선언하고 그들의 기능과  요구 사항이 무엇인지를 정의한다.
※ 자세한 내용은 Android manifest file documentation을 참고


Activity

Activity는 안드로이드의 네 가지 구현 요소 중 가장 일반적인 것으로 보통 어플리케이션에서 하나의 화면을 의미한다. Activity는 기반 클래스인 Activity를 확장한 클래스로 구현한 하나의 클래스로, 이 클래스는 뷰(View)와 이벤트(Event) 응답으로 이루어진 인터페이스를 화면상에 보여주게 된다. 많은 어플리케이션들이 여러 개의 화면으로 구성된다. 예를 들면, 문자 메시지 어플리케이션은 연락처 목록을 보여주는 화면과 선택된 연락처에 메세지를 쓰기 위한 두 번째 화면, 그리고 예전 메세지를 다시 보거나 설정을 변경하기 위한 또 다른 화면을 가질 수 있다. 이러한 각 화면이 Activity가 되며, 다른 화면으로 이동은 새로운 Activity를 시작하는 것이다. 상황에 따라 특정 Activity가 이전 Activity에 값을 보낼 수도 있다. 예를 들면, 사용자에게 사진을 선택하게 해주는 Activity는 호출자에게 선택된 사진을 리턴해줄 수 있다.

 새로운 화면이 열리면 이전 화면은 정지되고 히스토리 스택(History Stack)에 쌓이게 된다. 사용자는 히스토리에 남아있는 이전 화면으로 돌아갈 수 있으며 히스토리 스택에 저장할 필요가 없는 경우 삭제될 수 있다. 안드로이드는 이 히스토리 스택을 홈스크린(Home Screen)으로부터 실행된 각 어플리케이션마다 유지하게 된다. 

 

(Broadcas) Intent Receiver

Intent Receiver는 작성한 어플리케이션 내에서 휴대폰에 전화가 걸려오거나 데이터 네트워크 접속이 활성화되는 것과 같은 외부 이벤트를 처리할 때 사용된다. Intent Receiver는 UI를 표시하지는 않지만 NotificationManager가 사용자에게 어떤 일이 발생됨을 알리도록 사용하게 된다. Intent Receiver AndroidManifest.xml에 등록되지만 context.registerReceiver()를 이용하여  코드상에 등록해줄 수도 있다. Intent Receiver로 부터 호출되기 위해 어플리케이션이 실행되고 있을 필요는 없지만 만일 필요하다면 Intent Receiver 트리거될 때 시스템이 어플리케이션을 구동시킬 것이다. 또한 어플리케이션은 Context.sendBroadcast()를 호출하여 자신의 Intent  다른 어플리케이션에 브로드캐스팅 할 수 있다.


※ Intent and Intent Filters

 안드로이드는 화면과 화면 사이를 이동할 때 Intent라는 특별한 클래스를 사용한다. Intent는 어플리케이션이 하는 일에 대한 정보를 담고 있다. Intent에서 가장 중요한 부분은 action과 data의 동작에 대한 자료구조이다. 일반적으로 action은 MAIN(특정 어플리케이션의 관문), VIEW, PICK, EDIT 등이며 데이터는 URI로 표현된다. 예를 들어,  연락처를 보기 위해 VIEW action에 대한 Intent를 생성하고 해당 인물을 나타내는 URI data를 만들어 VIEW action 데이터로 지정해주면 된다. 이와 관련된 클래스로 IntentFilter가 있다. Intent는 어떤 작업에 대한 요청이라면 IntentFilter는 Activity상의 또는 Intent Receiver의 Indent를 어떻게 핸들링 하는지를 나타낸다. 예를 들어, 어떤 사람의 연락처를 표시하는 Activity가 사람에 대한 정보를 표현하는 data에 적용되었을 때 VIEW Action을 핸들링 할 수 있는 intentFilter를 사전에 생성한다. 또한 각 Activity는 그들의 intentFilters를 AndroidManifest.xml 파일에 기록한다. 화면과 화면의 이동은 Intent를 해석하는 것으로 동작한다. 앞으로 갈 때(forward) Activity는 startActivity(myIntent)를 호출한다. 시스템은 설치된 모든 어플리케이션을 위한 IntentFilter를 조사하고 IntentFilter들이 myIntent에 가장 잘 맞아 떨어지는  Activity를 고른다. 그 새로운 Activity는 Intent를 전달받고, 구동이 시작된다. Intent 해석은 startActivity이 호출되는 실행 시점에 일어나며, 이러한 과정은 두 가지 장점을 지닌다.

  • Activities는 간단하게 Intent 형태의 요청을 통해  다른 컴포넌트의 기능을 재사용할 수 있다.
  • Activities는 동일한 IntentFilter를 가진 새로운 Activity의해 언제든지 대체 가능하다.

Service

Service UI와 상관없이 오랫동안 존재하며 실행되는 코드이다. 좋은 예로, 재생 목록에서 음악을 재생하는 미디어플레이어를 들 수 있다. 미디어플레이어는 사용자로가 노래를 선택하고 재생하게 하는 하나 이상의 Activity로 구성되어 있지만 재생 기능이 Activity 의해 다루어지면 안된다. 사용자는 다른 스크린으로 이동하더라도 계속 재생하기를 기대하기 때문이다이런 상황에서 미디어플레이어의 Activity Context.startService()를 이용하여 백그라운드 Service로 실행된다. 시스템은 음악 재생을 멈출 때까지 계속 재생할 것이다.(Life Cycle of an Android Application 을 읽어보면 시스템에서 서비스에 주어진 우선순위에 대해 더 알 수 있다.)  Context.bindService() 로 서비스에 연결하거나 시작하지 않은 Service를 시작한다. Service에 연결되면 Service에 접근 가능한 인터페이스를 통해 멈춤이나 다시 재생 등을 할 수 있도록 접근 가능하다.

 

Content Provider

어플리케이션은 데이터를 파일, SQLite 데이터베이스나 다른 저장 장치들에 저장할 수 있다. Content Provider는 어플리케이션 데이터를 다른 어플리케이션과 공유하고자 할 때 유용하다. Content Provider는 다른 어플리케이션이 데이터를 저장하고 가져오는 것과 같은 작업에 대한 표준 메소드들을 구현한 표준 클래스이다.


원문 : http://androidcommunity.com/forums/f4/anatomy-of-an-android-application-102/

There are four building blocks to an Android application:

* Activity
* Intent Receiver
* Service
* Content Provider


Not every application needs to have all four, but your application will be written with some combination of these.

Once you have decided what components you need for your application, you should list them in a file called AndroidManifest.xml. This is an XML file where you declare the components of your application and what their capabilities and requirements are. See the Android manifest file documentation for complete details.

Activity
Activities are the most common of the four Android building blocks. An activity is usually a single screen in your application. Each activity is implemented as a single class that extends the Activity base class. Your class will display a user interface composed of Views and respond to events. Most applications consist of multiple screens. For example, a text messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. Each of these screens would be implemented as an activity. Moving to another screen is accomplished by a starting a new activity. In some cases an activity may return a value to the previous activity -- for example an activity that lets the user pick a photo would return the chosen photo to the caller.

When a new screen opens, the previous screen is paused and put onto a history stack. The user can navigate backward through previously opened screens in the history. Screens can also choose to be removed from the history stack when it would be inappropriate for them to remain. Android retains history stacks for each application launched from the home screen.

Intent and Intent Filters
Android uses a special class called an Intent to move from screen to screen. An intent describes what an application wants done. The two most important parts of the intent data structure are the action and the data to act upon. Typical values for action are MAIN (the front door of the activity), VIEW, PICK, EDIT, etc. The data is expressed as a URI. For example, to view contact information for a person, you would create an intent with the VIEW action and the data set to a URI representing that person.

There is a related class called an IntentFilter. While an intent is effectively a request to do something, an intent filter is a description of what intents an activity (or intent receiver, see below) is capable of handling. An activity that is able to display contact information for a person would publish an IntentFilter that said that it knows how to handle the action VIEW when applied to data representing a person. Activities publish their IntentFilters in the AndroidManifest.xml file.

Navigating from screen to screen is accomplished by resolving intents. To navigate forward, an activity calls startActivity(myIntent). The system then looks at the intent filters for all installed applications and picks the activity whose intent filters best matches myIntent. The new activity is informed of the intent, which causes it to be launched. The process of resolving intents happens at run time when startActivity is called, which offers two key benefits:

* Activities can reuse functionality from other components simply by making a request in the form of an Intent
* Activities can be replaced at any time by a new Activity with an equivalent IntentFilter


Intent Receiver
You can use an IntentReceiver when you want code in your application to execute in reaction to an external event, for example, when the phone rings, or when the data network is available, or when it's midnight. Intent receivers do not display a UI, although they may use the NotificationManager to alert the user if something interesting has happened. Intent receivers are registered in AndroidManifest.xml, but you can also register them from code using Context.registerReceiver(). Your application does not have to be running for its intent receivers to be called; the system will start your application, if necessary, when an intent receiver is triggered. Applications can also send their own intent broadcasts to others with Context.broadcastIntent().

Service
A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be handled by an activity because the user will expect the music to keep playing even after navigating to a new screen. In this case, the media player activity could start a service using Context.startService() to to run in the background to keep the music going. The system will then keep the music playback service running until it has finished. (You can learn more about the priority given to services in the system by reading Lifecycle of an Android Application.) Note that you can connect to a service (and start it if it's not already running) with the Context.bindService() method. When connected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.

Content Provider
Applications can store their data in files, an SQLite database, or any other mechanism that makes sense. A content provider, however, is useful if you want your application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.

To get more details on content providers, see Accessing Content Providers.

http://code.google.com/android/intro/anatomy.html

Portions of this page are reproduced from work created and shared by Googleand used according to terms described in the Creative Commons 2.5 Attribution License.

by 좋은게좋아 | 2009/07/07 18:21 | Android | 트랙백 | 덧글(0)

트랙백 주소 : http://pitfall.egloos.com/tb/2430897
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

:         :

:

비공개 덧글

◀ 이전 페이지 다음 페이지 ▶