반응형

이번 포스팅은 Android에서 Intent Filter에 대하여 알아보도록 하겠습니다.


다른 앱이 자신의 Activity를 시작할 수 있도록 하기 위해서는 AndroidMenifest 파일에서 <activity> 요소에 대해 <intent-filter> 요소를 추가해야 합니다.

 <intent-filter> 요소를 추가하면 시스템이 Intent-Filter를 식별하고 설치된 모든 앱에서 지원하는 Intent의 내부 카달로그에 해당 정보를 추가합니다. 앱이 암시적 인텐트로 startActivity() 또는 startActivityForResult()를 호출하면 시스템은 그 인텐트에 응답할 수 있는 Activity(들)을 찾습니다.


Intent-Filter 추가



Activity가 처리 가능한 Intent를 올바르게 정의하려면 Activity가 받아들이는 데이터와 추가하는 인텐트 필터가 구체적이어야 합니다.

Activity의 Intent-Filter가 Intent 객체의 다음 기준을 충족할 경우, 시스템이 주어진 Intent를 해당 Activity에 보낼 수 있습니다.


Action

수행할 작업의 이름을 지정하는 문자열입니다. 일반적으로, 플랫폼에서 정의하는 값 중 하나입니다(예: ACTION_SEND 또는 ACTION_VIEW).

<action> 요소를 사용하여 Intent-Filter에 지정합니다. 이 요소에 지정하는 값은 API 상수 대신 작업의 전체 문자열 이름이어야 합니다(다음 예제 참조).


Data

인텐트와 관련된 데이터에 대한 설명입니다.

<data> 요소를 사용하여 Intent-Filter에 지정합니다. 이 요소에서 하나 이상의 속성을 사용하여 MIME 유형, URI 접두사, URI 구성표 또는 이들의 조합 그리고 수락된 데이터 유형을 나타내는 다른 요소들을 지정할 수 있습니다.


Category

인텐트를 처리하는 Activity의 특징을 지정할 수 있는 추가적인 방법을 제공합니다. 일반적으로 사용자 제스처 또는 이러한 제스처가 시작된 위치와 관련되어 있습니다. 시스템이 지원하는 카테고리는 여러 가지가 있지만 대부분은 거의 사용되지 않습니다. 하지만 모든 암시적 인텐트는 기본적으로CATEGORY_DEFAULT로 정의됩니다.

<category> 요소를 사용하여 Intent-Filter에 지정합니다.


Intent-Filter에서 Activity가 허용하는 기준을 선언할 수 있습니다. 이는 이러한 각각의 기준을  <intent-filter> 요소 내에 해당 XML 요소를 중첩하여 선언하면 가능합니다.

예를 들어, 다음은 데이터 유형이 텍스트 또는 이미지인 경우 ACTION_SEND 인텐트를 처리하는 인텐트 필터가 지정된 Activity입니다.

<activity android:name="ShareActivity">
   
<intent-filter>
       
<action android:name="android.intent.action.SEND"/>
       
<category android:name="android.intent.category.DEFAULT"/>
       
<data android:mimeType="text/plain"/>
       
<data android:mimeType="image/*"/>
   
</intent-filter>
</activity>

수신되는 인텐트는 각각 하나의 작업 및 하나의 데이터 유형만 지정합니다. 하지만 <intent-filter>의 <action><category> 및 <data> 요소에 대한 여러 인스턴스를 선언해도 문제가 되지는 않습니다.

action및 data의 두 쌍이 상호 배타적으로 동작할 경우, 어떤 데이터 유형과 페어링되었을 때 어떤 작업이 허용 가능한지를 지정하는 Intent-Filter를 각각 따로 생성해야 합니다.

예를 들어, Activity가 ACTION_SEND 및 ACTION_SENDTO 인텐트 모두에서 텍스트와 이미지 모두를 처리한다고 가정합니다. 이런 경우, 두 작업 각각에 별도의 인텐트 필터를 정의해야 합니다. 그 이유는 ACTION_SENDTO 인텐트는 데이터 Uri를 사용해서 send 또는 sendto URI 구성표를 사용하는 수신자 주소를 지정해야 하기 때문입니다.

<activity android:name="ShareActivity">
   
<!-- filter for sending text; accepts SENDTO action with sms URI schemes -->
   
<intent-filter>
       
<action android:name="android.intent.action.SENDTO"/>
       
<category android:name="android.intent.category.DEFAULT"/>
       
<data android:scheme="sms" />
       
<data android:scheme="smsto" />
   
</intent-filter>
   
<!-- filter for sending text or images; accepts SEND action and text or image data -->
   
<intent-filter>
       
<action android:name="android.intent.action.SEND"/>
       
<category android:name="android.intent.category.DEFAULT"/>
       
<data android:mimeType="image/*"/>
       
<data android:mimeType="text/plain"/>
   
</intent-filter>
</activity>

참고: 암시적 인텐트를 수신하려면 인텐트 필터 안에 CATEGORY_DEFAULT 범주를 반드시 포함해야 합니다. startActivity() 및 startActivityForResult() 메서드는 모든 인텐트를 마치 CATEGORY_DEFAULT 범주를 선언한 것처럼 취급합니다. Intent-Filter에서 이 범주를 선언하지 않으면 어떠한 암시적 인텐트도 Activity로 확인되지 않습니다.


Activity에서 Intent 처리



Activity를 시작하는 데 사용된 Intent를 읽어 Activity에서 취할 작업을 결정할 수 있습니다.

Activity가 시작되면, getIntent()를 호출하여 Activity를 시작한 Intent를 검색합니다. 이 작업은 Activity의 수명 주기 동안 언제든지 가능하지만, 일반적으로 onCreate() 또는 onStart()와 같은 초기 콜백 과정에서 수행합니다.



Reference

1. https://developer.android.com/training/basics/intents/filters?hl=ko

반응형

'Development > Android' 카테고리의 다른 글

[Android] Android ABI 관리  (0) 2019.09.22
[Android] Touch 이벤트 순서  (0) 2019.09.10
[Android] Flexable Fragment UI 구축  (0) 2019.09.06
[Android] App Fragment Test  (0) 2019.09.06
[Android] Fragment의 생성  (0) 2019.09.06
반응형

이번 포스팅은 바이너리 데이터 통신 시 많이 사용하는 Base64에 대하여 알아보도록 하겠습니다.

 

Base64의 개요


Base64란 Binary Data를 Text로 바꾸는 Encoding(binary-to-text encoding schemes)의 하나로써 Binary Data를 오직 공통 ASCII 영역의 문자로 Character Set에 영향을 받지 않는 이루어진 문자열로 바꾸는 Encoding입니다.

핵심은 "Base64 Encoding은 Binary Data를 Text로 변경하는 Encoding이다." 입니다.

Base64를 글자 그대로 직역하면 컴퓨터에게는 조금 특별한 64진법이라는 뜻입니다. 특별한 이유는 64가 2의 제곱수(64=2^6) 이며, 2의 제곱수에 기반한 진법 중 화면에 표시할 수 있는 ASCII 문자들로 나타낼 수 있는 가장 큰 진법이기 때문입니다. (ASCII에는 제어문자가 다수 포함되어 있기 때문에 화면에 표시되는 ASCII 문자는 128개가 되지 않습니다.)

 

Base64 변환 과정


 

Base64 색인표

문자

문자

문자

문자

0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /

 

변환하는 방식을 간략하게 설명하면 Binary Data를 6 bit씩 자른 뒤 6 bit에 해당하는 문자를 위의 Base64 색인표에서 찾아 치환합니다. (실제로는 Padding을 더해주는 과정이 추가됩니다.)

1. 문자열을 ASCII로 치환

   (M -> 77)

2. 치환한 ASCII 값을 binary 데이터로 치환

  (77 -> 01001101) (01001101는 십진수로 77)

3. binary 데이터 값을 이은 후 6bit씩 자른 후 Base64 색인표에 나와 있는 데이터로 치환

  (01001101 -> 010011 01.....(다음 데이터와 이어짐)

  (010011 -> T (19)

 

아래 그림을 보시면 자세히 설명이 되어 있습니다.

 

 


Text content M a n
ASCII 77 97 110
Bit pattern 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0
Index 19 22 5 46
Base64-Encoded T W F u

 

 

 

Base64 인코딩을 사용하는 이유

 


Base64 Encoding을 하게되면 전송해야 될 데이터의 양도 약 33% 정도 늘어납니다. 그 이유는 6bit당 2bit의 Overhead가 발생하기 때문입니다.  Base64 Encoding 전 대비 33%나 데이터의 크기가 증가하고, Encoding과 Decoding에 추가 CPU 연산까지 필요한데 우리는 왜 Base64 Encoding을 하는 걸까요?

문자를 전송하기 위해 설계된 Media(Email, HTML)를 이용하여 Binary Data(이미지나 오디오)를 전송 할 때, ASCII로 Encoding하여 전송하게 되면 여러가지 문제가 발생할 수 있습니다. 

ASCII는 7 bits Encoding인데 나머지 1bit를 처리하는 방식이 시스템 별로 상이

▶ 일부 제어문자 (e.g. Line ending)의 경우 시스템 별로 다른 코드값을 갖음

 

위와 같은 문제로 ASCII는 시스템간 데이터를 전달하기에 안전하지 않습니다.

따라서 ASCII 중 제어문자와 일부 특수문자를 제외한 64개의 안전한 출력 문자만 사용하는 Base64를 사용하는 것입니다.

(* 안전한 출력 문자는 문자 코드에 영향을 받지 않는 공통 ASCII를 의미합니다).

 

다시 말해 

 

Base64는 HTML 또는 Email과 같이 문자를 위한 Media에 Binary Data를 포함해야 될 필요가 있을 때, 포함된 Binary Data가 시스템 독립적으로 동일하게 전송 또는 저장되는걸 보장하기 위해 사용한다” 

 

라고 정리 할 수 있을 것 같습니다.

 

Base64 FLAG


 NO_PADDING ~ 출력 끝에서 패딩 '=' 문자를 생략하는 인코더 플래그 비트(있는 경우)

NO_WRAP ~ 모든 라인 터미네이터를 생략하는 인코더 플래그 비트(즉, 출력이 하나의 긴 라인에 있을 것입니다). 인코딩시 인코딩 된 문자열이 76자가 넘으려고 하면 "\n" 개행문자를 삽입합니다. 장문의 데이터 시에는 문제가 될 것이 없지만, 개행문자를 기반으로 한 인자 값 전달 등의 경우에 문제가 될 여지가 있습니다. 따라서 Android에서 Base64 인코딩 시에 개행문자를 삽입하지 않는 옵션은 NO_WRAP입니다.

▶ URL_SAFE ~ Base64의 "URL 및 파일 이름 안전" 변형을 사용하여 나타내는 인코더/디코더 플래그 비트입니다(RFC 3548 섹션 4 참조). 여기서 - 및 _는 + 및 / 대신 사용됩니다.

   ( '-' -------> '+',     '_' -------> '/' )

▶ DEFAULT ~ 인코더/디코더 플래그의 기본값. (PADDING  & WRAP 적용)

 

 

Reference

 

1. https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464

2. https://beankhan.tistory.com/28

반응형
반응형


이번 포스팅은 Android Build 오류에 대하여 알아보도록 하겠습니다.


< Error>

FAILURE: Build failed with an exception.

[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 

[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong:

[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Execution failed for task ':app:kaptDebugKotlin'.


< Solution > 

이 Build 오류에 대하여 단일 원인은 없습니다. 

또한 항상 kotlin 과 관련이 있는 것은 아닙니다 .

원인에 대한 명확한 정보 는 Android Studio 의 Gradle Console 에서 로그를 확인하십시오 

실패에 대한 실마리를 찾을 수 있습니다.


build clean를 하거나 buld.gradle에서 compile dependency를 implementation dependency로 바꾸거나 다양한 해결방법이 있습니다.

자세한 오류의 원인 해결은 Gradle Console 로그를 확인하시기 바랍니다.

반응형

+ Recent posts