Android Application의 해부

Posted 2009.02.25 12:14

이하는 Google Android 개발자 사이트에서 발췌한역한 것입니다.

There are four building blocks to an Android application:

  • Activity
  • Broadcast 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 thor complete details.

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

  • Activity
  • Broadcast Intent Receiver
  • Service
  • Content Provider

모든 app가 네 가지 요소 모두를 사용하는 것은 아니고, 이 네 가지 요소 중 일부의 조합으로 이루어지게 된다.
일단 만들고자 하는 app가 필요로 하는 컴포넌트를 결정하면. AndroidManifest.xml 파일안에 그것들의 목록을 나열해야 한다. 이것은 여러분의 app를 구성하는 컴포넌트를 선언하고 및 각각이 할 수 있는 것과 요구 사항이 무엇인지를 정의한 놓은 xml파일이다. 상세 내용은 Android manifest file documentation을 참고한다.

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.

 Activity들은 안드로이드 네가지 구현 요소 중 가장 일반적인 것이다. activity는 보통 app의 화면 하나를 의미한다. 각각의 activity는 기반 클래스인 Activity를 확장한 클래스로 구현된다. 이 클래스는 View들로 구성된 사용자 인터페이스를 표시하고, 이벤트에 반응한다. 많은 app들이 여러 개의 화면으로 구성된다. 예를 들면, 문자 메시지 app는 메세지를 보내기 위한 연락처 목록들을 보여주는 화면 하나와, 선택된 연락차에 메세지를 쓰기 위한 두 번째 화면, 그리고 예전 메세지를 다시 보거나 설정을 변경하기 위한 또 다른 화면을 가지고 있을 수 있다. 이러한 각각의 스크린들은 Activity로서 구현된다. 다른 스크린으로의 이동은 새로운 activity를 시작함으로서 이루어진다. 일부의 경우, 특정 activity가 이전 activity에 값을 리턴할 수도 있다. 예를 들면, 사용자에게 사진을 선택하게 해주는 activity는 호출자에게 선택된 사진을 리턴해줄 수 있다.

 새로운 화면이 열릴 때, 이전 화면은 일시 정지되고 히스토리 스택에 쌓이게 된다. 사용자는 히스토리에 남아있는 기존에 열었던 화면 정보를 통해 뒤로 가기를 할 수 있다.

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 application), 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 BroadcastReceiver, 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라는 특수한 클래스를 사용한다. intent는 app가 처리하기 원하는 것을 서술한다. intent 자료 구조의 두 가지 중요한 부분은 action과 action 이 동작하는 데이터이다. action 위한 전형적인 값들은 MAIN(특정 app의 관문), VIEW, PICK, EDIT등이다. 데이터는 URI로 표현된다. 예를 들어, 특정인의 연락처 정보를 보여주기 위해, 여러분은 VIEW action 과 해당 인물을 나타내는 URI가 설정된 data로 intent를 만들어야 한다. 
  IntentFilter라는 관련된 클래스가 있다. intent는 실제로 어떤 일을 하기 위한 요청인 반면, intent filter는 activity를 사용하고자 하는 주체(또는 BroadcastReceiver, 아래를 참고)가 어떤 것을 다룰 수 있는지를 기술한 것이다. 예를 들어, 특정인의 연락처를 표시하는 activity는, 인물을 나타내는 data가 적용되었을 때 VIEW에 어떻게 표현할지 알고 있다고 서술한 intentFilter를 사전에 기록해 놓는다. 각각의 Activity들은 그들의 intentFilters를 AndroidManifest.xml 파일에 기록한다.

 화면에서 화면으로의 이동은 intent를 해석함으로써 이루어진다. 앞으로 갈 때(forward) activity는 startActivity(myIntent)를 호출한다. 시스템은 설치된 모든 app를 위한 intent filter들을 조사하고 intent filter들이 myIntent에 가장 잘 맞아 떨어지는  activity를 고른다. 그 새로운 activity는 intents를 전달받고, 구동이 시작된다. intent 해석은 startActivity이 호출되는 실행 시점에 일어나며, 다음과 같은 두 가지 주요한 이점을 제공한다. 

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

Broadcast Intent Receiver

You can use a BroadcastReceiver 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. BroadcastReceivers do not display a UI, although they may use the NotificationManager to alert the user if something interesting has happened. BroadcastReceivers 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 BroadcastReceivers to be called; the system will start your application, if necessary, when a BroadcastReceiver is triggered. Applications can also send their own intent broadcasts to others with Context.sendBroadcast().

 폰이 울릴 때나 데이터 네트웍이 사용가능해질 때, 또는 밤이 되었을 때와 같은 외부 이벤트에 대해 반응하여 여러분의 app에 있는 코드가 수행되기 원할 때 BroadcastReceiver를 사용할 수 있다. 무언가 관심이 대상이 되어야 하는 일이 일어났을 때, 사용자에게 경고하기 위해 NotificationManager 를 사용할 수도 있지만, BroadcastReceivers는 UI를 표시하지는 않는다. BroadcastReceivers는 AndroidManifest.xml에 등록되지만 context.registerReceiver() 를 이용하여  BroadcastReceiver를 등록할 수도 있다. BroadcastReceivers로 부터 호출되기 위해 app가 실행되고 있을 필요는 없다. 만일 필요하다면, BroadcastReceiver가 trigging될 때 시스템이 app를 구동시킬 것이다. BroadcastReceiver가 trigging될 때 app는 자신의 intent를 Context.sendBroadcast()를 통해 역시 다른 곳으로 브로드캐스팅 할수도 있다.

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 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 Life Cycle 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.

 Service는 UI없이 오랫동안 살이있으면서 실행되는 코드들이다. 좋은 예로, 재생 목록에 있는 음악을 재생하는 media player를 들 수 있다. media player app를 들여다보면, 아마도 사용자로 하여금 노래를 선택하고 재생하게하는 하나 이상의 activity들로 구성되어있을 것이다. 그러나 음악 재생 그 자체의 기능은 activity의해 다루어지면 안된다. 사용자는 새로운 스크린으로 이동한 후에도 계속 음악이 재생되기를 바라기 때문이다. 이런 경우, media player activity는 Context.startService()를 이용하여 백그라운드로 음악이 계속 재생되는 서비스를 구동할 수 있다. 그 시스템은 끝날 때 까지 실행 중인 음악 재생 서비스를 계속 유지할 것이다.(Life Cycle of an Android Application 을 읽어보면 시스템에서 서비스에 주어진 우선순위에 대해 더 알 수 있다.)  Context.bindService() 로 서비스(만약 이미 실행중이 아니라면 서비스를 시작한다)에 접근할 수있다. 여러분이 서비스에 접근할 때, 여러분은 서비스에 의해 나타난 인터페이스를 통해 서비스와 통신할 수 있다. 뮤직 서비스의 경우라면 pause, rewind와 같은 인터페이스가 될 것이다.

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.

 App은 파일, SQLite 데이터베이스나 다른 가능한 장치들에 데이터를 저장할 수 있다. 그러나 content Provider는 만약 여러분이 app의 데이터를 다른 어플과 공유하고자 할 때 싶다면 매우 유용하다. content provider는 다른 app이 content provider가 다루는 데이터 타입들을 저장하고 불러내기 위한 일련의 표준 메소드들을 구현한 표준 클래스이다.
content Provider에 대해 더 알고 싶으면  Accessing Content Providers 를 참고한다.

이 글은 스프링노트에서 작성되었습니다.

신고
« PREV : 1 : ··· : 21 : 22 : 23 : 24 : 25 : 26 : 27 : 28 : 29 : ··· : 87 : NEXT »

티스토리 툴바