다른 분들이 쓰신 유용한 개발 팁을 링크해 둔 글입니다. 계속해서 업데이트 됩니다.



XML 레이아웃을 작성하다 보니 중복되는 내용도 많고, 한 파일에 너무 많은 코드가 들어가니 가독성도 떨어져서

XML 코드를 재사용할 수 있는 방법을 찾아봤다.


Include 태그를 활용하거나, styles.xml, themes.xml 파일을 활용하는 방법이 있다.


1. Include 태그 활용

Include 태그는 다른 XML 파일을 읽어와 레이아웃에 포함합니다. 자주 쓰는 XML 코드를 파일로 분리해두고

Include 태그를 이용하여 불러와 재사용할 수 있습니다.

제 경우에는 모든 액티비티의 상단에 타이틀 바를 두었는데, 이를 파일로 분리하고 불러와서 사용했습니다.

자세한 내용은 아래 링크를 참조하세요.

http://croute.me/435



2. Styles & Themes

values 폴더의 styles.xml파일과 themes.xml 파일에 스타일이나 테마를 추가하여 애트리뷰트에 대한 값을 지정하여 이를 스타일로 묶어 불러와 사용하는 방식입니다.

CSS에서 클래스를 정의해서 사용하는 것과 유사하다고 보시면 됩니다.

아래 링크는 안드로이드 개발자 사이트의 가이드입니다.

http://developer.android.com/guide/topics/ui/themes.html

안드로이드에서 EditText와 같은 뷰를 가진 액티비티가 시작되면 소프트 키보드가 항상 보이는 채로 시작된다.

키보드가 보이지 않는 채로 액티비티를 시작하고 싶다면

Activity를 상속받은 클래스에서 onResume 메서드를 아래와 같이 오버라이딩 한다.

@Override protected void onResume(){     super.onResume();     getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN); }


만약 특정 순간(이벤트 처럼) 후에 키보드를 감추거나 보이게 할 때는 아래와 같이 하면 된다.

// InputMethodManager를 가져옴 InputMethodManager imm =     (InputMethodManager) getSystemService(INPUT_METHOD_SERVICE); // 감출 때 imm.hideSoftInputFromWindow(ViewName.getWindowToken(), 0); // 보이게 할 때 imm.showSoftInput(ViewName, 0);



+ 2012.06.10 추가

애초에 포커스를 EditText로 주지 않는 방법도 있다.

해당 액티비티의 레이아웃 파일에서 레이아웃에 focusable, focusableInTouchMode 애트리뷰트를 추가하고

값을 true로 주고 requestFocus 태그를 추가한다.


<LinearLayout

        ... 다른 속성들

        android:focusable="true"

        android:focusableInTouchMode="true">

        <requestFocus/>


       ...

</LinearLayout>


이는 포커스를 가질 수 없는 레이아웃에 강제로 포커스를 가지게 하고 포커스를 줌으로써

EditText가 포커스를 가지지 않게하여 소프트 키보드를 보이지 않게 하는 방법이다.

구글링을 해서 소스코드를 검색하다 보면 StackOverflow 사이트에 괜찮은 내용이 꽤나 많다.

레퍼런스를 보는 것도 괜찮지만, 아무래도 사용자들의 의견이 오간 곳이기도 하니 질도 좋고 평가도 되어있다.


// 14dp를 픽셀 단위로 변환, 14에는 원하는 dp를 넣으면 됨.
Resources r = getResources();
float px = TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, 14, r.getDisplayMetrics());


다른 방법은

/**
 * This method convets dp unit to equivalent device specific value in pixels. 
 * 
 * @param dp A value in dp(Device independent pixels) unit. Which we need to convert into pixels
 * @param context Context to get resources and device specific display metrics
 * @return A float value to represent Pixels equivalent to dp according to device
 */
public static float convertDpToPixel(float dp,Context context){
    Resources resources = context.getResources();
    DisplayMetrics metrics = resources.getDisplayMetrics();
    float px = dp * (metrics.densityDpi/160f);
    return px;
}
/**
 * This method converts device specific pixels to device independent pixels.
 * 
 * @param px A value in px (pixels) unit. Which we need to convert into db
 * @param context Context to get resources and device specific display metrics
 * @return A float value to represent db equivalent to px value
 */
public static float convertPixelsToDp(float px,Context context){
    Resources resources = context.getResources();
    DisplayMetrics metrics = resources.getDisplayMetrics();
    float dp = px / (metrics.densityDpi / 160f);
    return dp;

}


어느 블로그에서 필터링 없이 사용했는데 동작하지 않던 소스..

private static final float DEFAULT_HDIP_DENSITY_SCALE = 1.5f;

	/**
	 * 픽셀단위를 현재 디스플레이 화면에 비례한 크기로 반환합니다.
	 * 
	 * @param pixel
	 *            픽셀
	 * @return 변환된 값 (DP)
	 */
	public int DPFromPixel(int pixel) {
		float scale = getResources().getDisplayMetrics().density;

		return (int) (pixel / DEFAULT_HDIP_DENSITY_SCALE * scale);
	}

	/**
	 * 현재 디스플레이 화면에 비례한 DP단위를 픽셀 크기로 반환합니다.
	 * 
	 * @param DP
	 *            픽셀
	 * @return 변환된 값 (pixel)
	 */
	public int pixelFromDP(int DP) {
		float scale = getResources().getDisplayMetrics().density;

		return (int) (DP / scale * DEFAULT_HDIP_DENSITY_SCALE);
	}


NDEF 레코드에서 Text 레코드 타입의 정의입니다. 즉 NDEF Record가 Text 일때의 포맷입니다.

NDEF Message에 관한 전반적인 내용은 아래 링크된 글에서 참조 하시기 바랍니다.
NFC Data Exchange Format

1. NDEF Text Record
PAYLOAD의 레이아웃입니다. 표에서의 각 한칸은 1bit를 의미합니다.
7 6 5 4 3 2 1 0
UTF RFU Language code length
Language code (US-ASCII)
Actual text body

1) UTF - Text encoding
UTF 필드는 실제 텍스트 정보의 인코딩입니다.
UTF 값이 0이면 UTF-8 인코딩, 1인 경우 UTF-16 입니다.

2) RFU
RFU 필드는 Reserver for Future Use의 준말로써 아직 사용하지 않는 필드이며 예약된 필드 영역입니다. 이 값은 현재는 무조건 0으로 주시면 됩니다.

3) Language Code Length
텍스트 정보의 언어 코드 정보를 표현하는 필드의 길이입니다.
이 필드의 값에 따라 2번째 바이트에 위치한 Language Code 필드의 바이트 수가 정해집니다. Language code length의 값이 3 (2진수 000011) 인 경우 아래쪽 Language code 의 바이트 수(비트가 아닙니다 - 표에서의 한줄이 1byte 입니다.)는 3개가 되겠죠. 아래쪽에서 예제로 다시 설명하겠습니다.

4) Language code
텍스트 정보의 언어 코드 정보입니다. RFC 3066에 IATA의 형식으로 표기하시면 되고 인코딩은 US-ASCII입니다.
RFC 3066의 정보를 깔끔하게 정리해놓은 사이트가 있어 링크 걸어둡니다.
Using Language Identifier

5) Actual text body
실제 텍스트 정보가 들어가는 부분입니다. 텍스트의 길이에 따라서 복수의 byte를 가질 수 있습니다.



2. 간단한 예제
"안녕하세요 NFC 텍스트 레코드입니다." 라는 정보를 담는 텍스트 레코드를 만들어보는 예제입니다. NDEF Message의 헤더부분은 따로 쓰지 않겠습니다.

UTF-8로 인코딩하고 IATA 언어 코드는 "ko-KR"입니다.
따라서 UTF 필드는 0

RFU필드는 자동적으로 0 (사용하지 않는 필드이므로)

언어 코드의 길이(Language code length)는 ko-KR 이므로 십진수로 5이고 이진수로는 여섯 비트에 걸쳐 0 0 0 1 0 1 입니다.

언어코드는 "ko-KR"(한글)을 사용하므로 이를 아스키값으로 표현하면
0x6b,  0x6f,  0x2d,  0x4b,  0x52 입니다. 즉 표에서보면 5줄로 표현되며 각 줄에 위의 값이 표시됩니다.

실제 텍스트 부분입니다. UTF-8로 인코딩하여 byte값을 얻어보면
0xec  0x95  0x88  0xeb  0x85 
0x95  0xed  0x95  0x98  0xec 
0x84  0xb8  0xec  0x9a  0x94 
0x20  0x4e  0x46  0x43  0x20 
0xed  0x85  0x8d  0xec  0x8a 
0xa4  0xed  0x8a  0xb8  0x20 
0xeb  0xa0  0x88  0xec  0xbd 
0x94  0xeb  0x93  0x9c  0xec 
0x9e  0x85  0xeb  0x8b  0x88 
0xeb  0x8b  0xa4  0x2e
네.. 좀 기네요 길이는 49입니다. 그럼 Actual text body는 총 49바이트 (표에서 49줄)의 정보를 가지게 되고 각 줄에 위의 바이트 값들을 가지게 되겠죠

여기서 혹시나 알아채신 분이 있다면 실제 텍스트의 길이는 어떻게 구하느냐 인데. 이 글에서 표현하는 정보는 Payload에 국한되어있습니다. Payload의 길이는 자기자신이 가진게 아니라 Message에서 가지고 있으므로 Message에서 가진 Payload의 길이에서 Actual text body 부분을 제외한 바이트 수를 빼면 Actual text body의 길이가 됩니다.

[결과]
7 6 5 4 3 2 1 0
0 0 0 0 0 1 0 1
Language code (US-ASCII encoding ) : "ko-KR" to bytes
0x6
0x6f
0x2d
0x4b
0x52
Actual text body contents : "안녕하세요 NFC 텍스트 레코드입니다." to bytes
0xec
0x95
0x88
0xeb
0x85
0x95
0xed
0x95
0x98
0xec
0x84
0xb8
0xec
0x9a
0x94
0x20
0x4e
0x46
0x43
0x20
0xed
0x85
0x8d
0xec
0x8a
0xa4
0xed
0x8a
0xb8
0x20
0xeb
0xa0
0x88
0xec
0xbd
0x94
0xeb
0x93
0x9c
0xec
0x9e
0x85
0xeb
0x8b
0x88
0xeb
0x8b
0xa4
0x2e



[참고자료]
NFC Forum Text Record Type Definition
세부사항 미작성

대략적인 메커니즘

1. NFC 디바이스를 사용하기 위해서 퍼미션을 추가한다.

2. NFC 메시지를 처리할 액티비티에 intent-filter 추가

3. 액티비티로 돌아가서 Parcelabel Extra를 얻는다

4. Parcelable 배열이 null이거나 길이가 0일경우 빈 레코드 처리

5. 그렇지 않은 경우 Ndef 배열로 변환

6. NDEF Message 파싱

7. NDEF Message to NDEF Records

8. NDEF Records to byte array

9. NDEF Record 포맷에 맞춰 byte array 파싱

10. 원하는 포맷인지 체크하고 그에 따라 처리.



최종 작성 11.08.16. AM 5:00
- Message나 Record의 포맷부터 정확히 알아야 식별자를 만들 수 있을 듯 하다..
[참고 자료]
Android example NFC Test
우선 NDEF 를 간략하게 정의하면 디바이스와 태그를 위한 공용 포맷이다. 원문을 다 해석하긴 무리이기도 하고 해석해서 한글로 써놨는데 의미를 모를 것 같기도 해서 중요한 내용만 옮깁니다. 

1. 용어
NDEF application - 응용, 애플리케이션
NDEF를 사용하는 NFC 포럼의 장비의 논리적인 상위 계층에서의 응용
NDEF message - 메시지
이 스펙에서 정의되어 만들어진 기본적인 메시지, 하나의 NDEF 메시지는 하나 또는 이상의 NDEF 레코드를 포함한다.
NDEF record - 레코드
NDEF record는 타입, 길이, 선택적인 식별자에 관한 정보를 가지고 있는 payload를 포함하고 있다.
NDEF short record - 숏 레코드
SR 플래그가 1로 설정된 NDEF record. short record 내의 PAYLOAD_LENGTH 필드는 single octet이 적재되거나 255byte 이상 적재되도록 묶을 수 있게 한다.? (single octet은 8bit? byte? 8진수? 아예 상관자체가 없는건가..?)
NDEF record chunk - 레코드 묶음
꽉찬 payload보다 payload의 묶음을 포함한 NDEF record, 각각의 record chunk는 묶인 payload의 부분을 전달한다. 예외적으로 각각의 묶인 페이로드의 마지막 레코드는 CF 플래그가 1로 설정되어 있다.
NDEF payload - 페이로드
전달된 NDEF 레코드에 있는 응용 데이터
NDEF chunked payload
CF 플래그가 1인 마지막 레코드를 제외한 레코드들에서 각각의 분리된 NDEF 레코드에서 전달된 부분적인 다중 묶음들을 가진 응용 데이터
NDEF payload length
단일 NDEF 레코드의 페이로드에서 octet의 수를 가리키는 수
NDEF payload type
페이로드의 타입을 가리키는 식별자.  이 상세에서는 URI도 지원한다 또한 NFC 상세 레코드 타입 식별자에서도 지원한다.
NDEF payload identifier
페이로드를 식별하기 위해 사용할 수 있는 선택적인 URI
NDEF generator
애플리케이션에서 정의된 NDEF 메시지의 페이로드를 캡슐화하는 개체나 모듈
NDEF parser
NDEF 애플리케이션에 상관없이 페이로드나 NDEF 메시지를 분석하는 개체나 모듈
User Application
NDEF를 사용하는 응용 = NDEF Application



NDEF Encapsulation Constructs
Message(메시지)
NDEF 메시지는  하나 이상의 NDEF 레코드로 구성되어있다. 첫번째 레코드는 MB(Message Begin)라고 표기하고 마지막 레코드는 ME(Message End)라고 쓴다.  최소 메시지 길이는 하나의 NDEF 레코드인데 이때는 MB와 ME가 같은 레코드에 들어간다. 달리 말하자면 페이로드 묶음을 인코드하기 위해서는 적어도 둘 이상의 레코드 묶음이 필요하다는 얘기다.  
NDEF 메시지에 전달될 수 있는 NDEF 레코드의 최대 수는 제한이 없다.
NDEF 메시지는 중첩되지 않는다. 이것은 MB나 ME 플래그가 NDEF 메시지와 중첩되지 않는다는 것을 뜻한다. NDEF 메시지는 레코드의 페이로드로 꽉찬 메시지 인 경우에는 중첩될 수도 있다.

 NDEF Message
R1 MB=1  ...  Rr  ...  Rs  ... Rt ME=1 
[레코드 집합과 NDEF 메시지의 예]



Octet 1
Octet 2 Octet 3
Octet 4  
Octet 5  
[NDEF Octet Ordering]


7 6 5 4 3 2 1 0
MB  ME  CF  SR  IL  TNF
 TYPE LENGTH
 PAYLOAD LENGTH 3
 PAYLOAD LENGTH 2
 PAYLOAD LENGTH 1
 PAYLOAD LENGTH 0
 ID LENGTH
 TYPE
 ID
 PAYLOAD
[NDEF Record Layout]


7 6 5 4 3 2 1 0
MB  ME  CF  1 IL  TNF
 TYPE LENGTH
 PAYLOAD LENGTH
 ID LENGTH
 TYPE
 ID
 PAYLOAD
[NDEF Short-Record Layout (SR=1)]

SR = Shorted Record
IL = ID Length
TNF = Type Name Format
 Type Name Format Value 
 Empty  0x00 
 NFC Forum well-known type [NFC RTD]  0x01
 Media-type as defined in RFC 2046 [RFC 2046]  0x02
 Absolute URI as defined in RFC 3986[RFC 3986]  0x03
 NFC Forum external type [NFC RTD]  0x04
 Unknown  0x05
 Unchanged  0x06
 Reserved  0x07
 

(설명으로 봐서는 필드 한칸이 1bit 인것 같다. 고로 single octet은 1bit 란 얘긴데.. octet은 8을 뜻하는..?? 엉?? 바이튼가? 뭐지??)
single octet = 1 byte... 구글링 : octet equals to byte?



영어 독해 능력이 절실하다.. 쓰면서도 무슨 말인지 모르겠어......... ㅠㅠ

최종 수정일 11. 8. 14

[참고 자료]
1. NFC Data Exchange Format Specification, NFC Forum 2006
2. NFC Record Type Definition (RTD) Specification", NFC Forum 2006 

+ Recent posts