App Components

App Components

차례:

1. Activity

2. Service

3. Broadcast Receiver

4. Content Provider

5. Intent

1. Activity 액티비티: 

• Activity는 UI(화면)를 담당하는 컴포넌트입니다.
• 안드로이드 애플리케이션에서 화면을 구성하고 상호작용하는 데 필요한 UI 요소들은 모두 액티비티에서 처리됩니다.
• 화면을 관리 && 이벤트를 처리

 

알아두면 좋은 내용 :

1. 2개 이상의 액티비티를 동시에 Display 불가능
2. 1개 이상의 View 또는 ViewGroup을 포함
3. 반드시 애플리케이션에는 하나 이상의 액티비티가 있어야 함.

2. Service 서비스:

• Service는 백그라운드 작업을 위한 애플리케이션 구성 요소이다
• Service는 주로 네트워크 작업, 데이터베이스 작업, 파일 다운로드 등과 같은 장기 실행 작업을 처리하는 데 사용됩니다.
• 사용자가 다른 애플리케이션으로 전환하더라도 백그라운드에서 계속해서 실행된다.
• Service 자체는 main thread에서 동작
• 서비스에는 크게 3가지로 나뉘는데 포그라운드, 백그라운드, 바운드로 나뉜다.

3가지 서비스:  foreground, background, bound

• 포그라운드(foreground) 서비스 : 
  • 안드로이드 포그라운드 서비스(Foreground Service)는 사용자에게 직접적인 알림을 제공하며, 중요한 작업을 수행하는 서비스입니다. 포그라운드 서비스는 사용자에게 눈에 잘 띄는 알림(Notification)을 통해 서비스가 실행 중임을 알려주고, 사용자의 주요한 관심과 상호작용을 필요로 할 수 있습니다.
  • 포그라운드 서비스는 백그라운드에서 실행되지만, 사용자와의 상호작용을 위해 포그라운드로 표시되는 상태를 유지합니다. 이를 통해 백그라운드에서 실행되는 서비스가 시스템에 의해 즉시 종료되는 것을 방지할 수 있습니다. 
  • 주요 예시로는 음악 재생 서비스나 GPS 위치 추적 서비스가 있습니다.

• 백그라운드(background) 서비스 : 
  • 사용자 인터페이스(UI)를 제공하지 않고, 백그라운드에서 실행되는 안드로이드 컴포넌트입니다.
  • 백그라운드 서비스는 애플리케이션의 일부로 실행되며, 오래 실행되는 작업을 처리하거나 백그라운드에서 동작해야 하는 작업을 수행합니다. 
  • 예: SNS앱. 카페에서 게시물을 공유하려고 할때 공유뿐만 아니라 다른 사람의 게시물을 보려고 한다면?? 공유 버튼을 누른 후 다른 화면으로 넘어가 다른 사람의 게시물들을 본다고 할때, 자신의 게시물을 공유하고 다른 화면으로 넘어가거나 앱을 종료해도 게시물 업로드가 종료되지 않고 백그라운드 서비스가 시작되어 업로드는 진행중이나 사용자 입장에서는 이런 사실에 대해 눈으로 직접 보진 못하죠. 
  • 그냥 Thread 따로 쓰면 되는거 아니야? 왜 서비스로 따로 사용할까? 
  • Thread의 문제점 : 안드로이드 컴포넌트가 아니므로 독자적인 생명주기도 없을 뿐더러 Main Thread가 아니기 때문에 앱을 나가면 프로세스가 유지되지 않는다. 또, 만약에 OOM Killer에 의해서 프로세스가 종료되면 다시 재시작 될 것이라는 보장도 없다. 하지만 Service는: 안드로이드 4대 컴포넌트 중 하나로서 독자적인 생명주기를 가지고 있고 Main Thread에서 동작하기 때문에 사용자가 앱을 나가도 프로세스가 유지된다. 만약 강제로 프로세스가 죽을 경우 다시 살아날 수도 있다. 즉, 앱이 비활성화되어도 지속되어야 하는 작업은 Service로, 앱이 활성화되었을때 필요한 작업은 Thread에서 수행하는것이 바람직함 

• 바운드(bound) 서비스 : 
  • 앱 내에서 서비스를 사용하여 간단한 클라이언트 - 서버 환경을 구성하는 것을 말함(특정 컴포넌트와 서비스간 상호작용) 이 서비스는 마치 클라이언트-서버 와 같이 동작합니다.  
  • 서비스가 서버 역할을 하는 겁니다. 이 서비스는 Activity가 클라이언트 역할을 하고, 서비스가 서버 역할을 한다. 액티비티는 서비스에 어떠한 요청을 할수 있고, 서비스로부터 어떠한 결과를 받을수 있습니다. 
  • 바운드 서비스는 주로 백그라운드에서 오래 실행되어야 하거나 비동기적인 작업을 수행해야 하는 경우에 사용됩니다. 예를 들어, 음악 재생 애플리케이션은 바운드 서비스를 사용하여 백그라운드에서 음악을 재생하고, 클라이언트 애플리케이션은 서비스에 재생, 일시정지, 정지 등의 명령을 보낼 수 있습니다.

3. Broadcast Receiver

단말기에서 발생하는 다양한 이벤트, 정보를 받고 반응하는 컴포넌트

Broadcast Receiver는 시스템이나 앱 등에서 이벤트 발생시 방송을 해주는 개념입니다. 여기서 방송은 안드로이드에서의 메시지(알람) 를 여러 객체에 전달하는 것을 의미합니다. 

 

안드로이드 시스템에서 어떤 이벤트가 발생했을때 시스템은 "system broadcast" 라는 메세지를 보낸다. 이때 특정 이벤트가 발생한 것을 내 앱에서 알고 싶을때 Broadcast Receiver 를 통해 메세지를 받을 수 있다.

 

예를들어 배터리부족, SMS문자메시지, 전화가온다거나 하는 일들을 방송알림 해준다. 

그리고 카카오톡에서 다른사람에게 카톡을 받았을 때 이 카톡을 카카오톡 앱에 알려줘야 한다면 브로드캐스팅으로 전달하면 됨. 

• 정적 리시버 : Manifest에 등록하여 리시버를 구현하는 형태인데 한 번 등록하면 해제할 수 없는 방식이다.
• 동적 리시버 : 클래스 파일에서 리시버를 등록, 해제할 수 있는 형태이기 때문에 앱에 부하를 줄 일 수 있다. 하지만 해제를 적절히 해주지 않는다면 메모리 릭이 발생할 수 있다.
• 너무 많은 작업, 시간이 오래걸리는 작업 X.   왜? 처리 지연시간이 길어진 경우 -> ANR이 발생한다.
• 너무 많은 작업, 시간이 오래걸리는 작업  -> 스레드를 별도로 생성해서 처리하도록 해야한다
• 리시버에는 간단한 일을 처리하도록 해야한다.

4. Content Provider

앱 간 데이터공유를 위한 클래스를 제공하는 컴포넌트

안드로이드 시스템에서는 각 어플리케이션마다 각각의 DB를 가질 수 있다. 그리고 어플리케이션 내부의 DB는 해당 어플리케이션만 접근이 가능하다. 다른 어플리케이션에게 DB가 전부 공개된다면 보안에 취약해 질 수 있기 때문이다. 하지만, 어플리케이션 DB 접근을 완전히 막는 것도 문제가 될 수 있다. 어플리케이션 사이에 데이터를 공유할 수 없게되기 때문이다. 

 

*안드로이드 시스템은 어플리케이션 내부 DB에 대해 해당 어플리케이션만 접근 가능한 보안성과 다른 어플리케이션에서도 DB에 접근할 수 있도록 유연함을 제공하기 위해 컨텐트 프로바이더 클래스를 제공하는 것이다.

 

• 예를 들면 현재 앱에 휴대폰에 저장된 연락처를 받아 오는것이나 앱에서 카메라 어플을 이용해 사진을 찍고 저장해주는 것 같은 역할함.
• 다른 앱의 데이터를 사용하고자 하는 앱에서는 URI를 이용하여 콘텐츠 리졸버(Content Resolver) 를 통해 다른 앱의 콘텐츠 프로바이더에게 데이터를 요청한다. 요청 받은 컨텐츠 프로바이더는 URI를 확인하고 내부에서 데이터를 꺼내어 컨텐츠 리졸버에게 전달한다.
• 앱에서 데이터 공유를 제공하기 위해서는 ContentProvider 클래스를 상속받는 클래스를 먼저 생성합니다. 자동으로 onCreate(), query(), insert(), delete(), update() 함수가 만들어지는데, 이것은 데이터베이스를 생각하면 쉽게 이해를 할 수 있습니다.

5. Intent

Intent는 컴포넌트(액티비티, 서비스, 브로드캐스트 리시버)간에 통신을 하기 위한 '메시지 객체'입니다.

 

Intent를 대표적 3가지 방법:

• 액티비티의 시작: startActivity(Intent), startActivityForResult(Intent, requestCode)
• 서비스의 시작: startService(Intent), bindService(Intent)
• 브로드케스트 전달: sendBroadcast(Intent), sendOrderedBroadcast(Intent), sendStickyBroadcast()

2가지 Intent 타입 : Explicit Intents (명시적), Implicit Intents (암시적).

1. Explicit Intents (명시적):

명시적 인텐트는 인텐트에 클래스 객체나 컴포넌트 이름을 지정하여 호출할 대상을 확실히 알 수 있는 경우에 사용한다. 시작할 컴포넌트 이름을 지정합니다

예를 들면 Activity들 간의 정보 전달시 명시적 Intent사용

Intent intent = new Intent(InputActivity.this, ResultActivity.class);
intent.putExtra("my_data", data);
startActivity(intent);

 

2. Implicit Intents (암시적):

특정 구성 요소의 이름을 대지 않지만, 그 대신 수행할 일반적인 작업을 선언하여 다른 앱의 구성 요소가 이를 처리할 수 있도록 해줍니다. 예를 들어 사용자에게 지도에 있는 한 위치를 표시하고자 하는 경우, 암시적 인텐트를 사용하여 해당 기능을 갖춘 다른 앱이 지정된 위치를 지도에 표시하도록 요청할 수 있습니다.

// 전화 거는 Intent
Intent intent = new Intent(Intent.ACTION_DIAL) 
// google page 트는 Intent
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com/"));

(명시적) 이름지정 VS (암시적) 행동지정 쯤으로 생각해도 될까나??

 

IntentFilter

인텐트 필터는 컴포넌트가 수신하려는 인텐트 유형을 지정하는 매니페스트 파일의 표현식이다.

안드로이드 시스템 내부에선 수많은 앱들에 의해 수많은 인텐트들이 발생한다. 이 중 자신에게 필요한 인텐트만을 받기 위해 인텐트 필터가 있는 것이다.

 

• 인텐트 필터는 암시적 인텐트 실행을 위해 필요한 요소다.
• 사용할 인텐트가 여러 종류면 그 개수만큼 인텐트 필터를 매니페스트에 만들어야 한다.

 

PendingIntent

Intent를 가지고 있는 클래스로, 기본 목적은 다른 애플리케이션(다른 프로세스)의 권한을 허가하여 가지고 있는 Intent를 마치 본인 앱의 프로세스에서 실행하는 것처럼 사용하는 것이다.

 

다른 앱을 사용중에 Intent를 사용한 Notification을 클릭했을때 동작을 안함. 그래서 PendingIntent를 통해 다른 프로세스 (앱) 에게 권한을 허가하여 Intent 를 마치 본인 앱에서 실행되는 것처럼 사용하게 하는 것이다. 때문에 특정 시점에 Intent 가 무조건 수행될 수 있도록 보장되는 것이다.

 

사용 예: 

• Notification (푸시알림) 으로 Intent 작업 수행시 사용
• 바탕화면 (런쳐) 위젯에서 Intent 작업 수행 시 사용
• AlarmManager 를 통해 지정된 시간에 Intent 작업 수행시 사용