어제, 오늘 그리고 내일

이번 포스팅은 Fragment 에 대하여 자세히 알아보도록 하겠습니다.

Fragment는 FragmentActivity 내의 어떤 동작 또는 사용자 인터페이스의 일부를 나타냅니다. 여러 개의 프래그먼트를 하나의 액티비티에 결합하여 창이 여러 개인 UI를 빌드할 수 있으며, 하나의 프래그먼트를 여러 액티비티에서 재사용할 수 있습니다. 프래그먼트는 액티비티의 모듈식 섹션이라고 생각하면 됩니다. 이는 자체적인 수명 주기를 가지고, 자체 입력 이벤트를 수신하고, 액티비티 실행 중에 추가 및 삭제가 가능합니다(다른 액티비티에 재사용할 수 있는 "하위 액티비티"와 같은 개념).

프래그먼트는 항상 액티비티 내에서 호스팅되어야 하며 해당 프래그먼트의 수명 주기는 호스트 액티비티의 수명 주기에 직접적으로 영향을 받습니다. 예를 들어 액티비티가 일시정지되는 경우, 그 안의 모든 프래그먼트도 일시정지되며 액티비티가 소멸되면 모든 프래그먼트도 마찬가지로 소멸됩니다. 그러나 액티비티가 실행 중인 동안(onResume 수명 주기 상태에 있을 경우)에는 각 프래그먼트를 추가 또는 제거하는 등 개별적으로 조작할 수 있습니다. 그와 같은 프래그먼트 트랜잭션을 수행할 때는 이를 액티비티가 관리하는 백 스택에도 추가할 수 있습니다. 각 백 스택 항목이 발생한 프래그먼트 트랜잭션의 기록이 됩니다. 이 백 스택을 사용하면 사용자가 프래그먼트 트랜잭션을 거꾸로 돌릴 수 있습니다(뒤로 이동). 이때 Back 버튼을 누르면 됩니다.

프래그먼트를 액티비티 레이아웃에 추가하면, 해당 프래그먼트는 액티비티의 뷰 계층 내에서 ViewGroup에 들어가고 자체적인 뷰 레이아웃을 정의합니다. 액티비티의 레이아웃 파일에서 <fragment> 요소로 프래그먼트를 선언하거나 기존 ViewGroup에 추가하는 방법으로 애플리케이션 코드에서 프래그먼트를 선언하면 액티비티 레이아웃에 프래그먼트를 삽입할 수 있습니다.

모범 사례 가이드를 포함한 수명 주기 처리에 대한 자세한 내용은 다음 참고 자료를 참조하세요.

▶ 수명 주기 인식 구성 요소로 수명 주기 처리

▶ 앱 아키텍처에 대한 가이드

▶ 태블릿 및 핸드셋 지원

Fragment 디자인 철학

Android가 프래그먼트를 처음 도입한 것은 Android 3.0(API 레벨 11)부터입니다. 기본적으로 태블릿과 같은 큰 화면에서 보다 역동적이고 유연한 UI 디자인을 지원하는 것이 목적이었습니다. 태블릿의 화면은 핸드셋 화면보다 훨씬 크기 때문에 UI 구성 요소를 조합하고 상호 교환할 공간이 더 많습니다. 프래그먼트는 개발자가 뷰 계층에 복잡한 변경 내용을 관리하지 않아도 이러한 디자인을 사용할 수 있도록 해줍니다. 액티비티의 레이아웃을 여러 프래그먼트로 나누면 런타임에서 액티비티의 외관을 수정할 수도 있고, 그러한 변경 내용을 해당 액티비티가 관리하는 백 스택에 보존할 수도 있습니다. 이제 프래그먼트는 Fragment suppoert library를 통해 폭넓게 제공됩니다.

예를 들어 뉴스 애플리케이션이라면 하나의 프래그먼트를 사용하여 왼쪽에 기사 목록을 표시하고, 또 다른 프래그먼트로 오른쪽에 기사 내용을 표시할 수 있습니다. 두 프래그먼트 모두 한 가지 액티비티에서 양쪽으로 나란히 나타나며, 각 프래그먼트에 나름의 수명 주기 콜백 메서드가 있고 각자 사용자 입력 이벤트를 따로 처리하게 됩니다. 따라서 사용자는 기사를 선택하는 데 하나의 액티비티를 쓰고 기사를 읽는 데 다른 액티비티를 선택하는 대신, 같은 액티비티 안에서 기사를 선택하고 읽는 과정을 모두 끝낼 수 있습니다.

각 프래그먼트는 모듈식이고 재사용 가능한 액티비티 구성 요소로 디자인해야 합니다. 다시 말해, 각 프래그먼트가 자체적인 수명 주기 콜백으로 레이아웃과 동작을 정의하기 때문에 한 프래그먼트를 여러 액티비티에 포함할 수 있습니다. 그러므로 다시 사용할 것을 염두에 두고 디자인하고 하나의 프래그먼트를 다른 프래그먼트에서 직접 조작하는 것은 삼가야 합니다. 이것이 특히 중요한 이유는 모듈식 프래그먼트를 사용하면 프래그먼트 조합을 여러 가지 화면 크기에 맞춰 변경할 수 있기 때문입니다. 태블릿과 핸드셋을 모두 지원하는 애플리케이션을 디자인하는 경우, 사용 가능한 화면 공간을 사용자 환경에서 최적화하도록 프래그먼트를 여러 레이아웃 구성에 재사용할 수 있습니다.

여러 가지 화면 구성에 맞게 여러 가지 프래그먼트 조합으로 애플리케이션을 디자인하는 법에 대한 보다 더 자세한 내용은 화면 호환성 개요에 대한 가이드를 참조 부탁드립니다.

Reference

1. https://developer.android.com/guide/components/fragments

이번 포스팅은 전자서명에 대하여 알아보도록 하겠습니다.

전자 서명 ( Digital Signature )

전자서명은 내가 얻은 메시지가 어떤 사람이 작성한 것인지를 확인하는 인증 작업입니다. 즉, 메시지와 메시지를 생성한 사람과의 인증입니다. 다시 말해 계약서에 이름을 적고 도장을 찍거나 사인을 함으로써 그 사람이 계약서를 작성한 것이 맞다는 것을 인증하는 것과 같습니다.  

 

 

계약서에 도장을 찍거나 사인을 해서 그 사람이 계약서의 내용을 작성했다는 것을 인증하는 것처럼 전자 데이터로 되어있는 메시지에도 도장 또는 사인처럼 전자적인 사인을 할 수 있습니다. 이것을 전자 서명 (Digital Signature) 이라고 합니다. 전자 서명은 계약서에 쓰여진 사인과 같은 역할을 하게 됩니다.

 

 

 

  

전자 서명 알고리즘

---

전자 서명을 가능하게 한 것은 공개키 암호화 알고리즘입니다. 이 공개키 암호화를 사용하여 할 수 있는 것들은 다음의 두 가지였습니다.

 

▶ 메시지를 암호화하고, 복호화 할 수 있는 기밀성을 제공

▶ 비밀키를 안전하게 교환 

 

다시 말해, 공개키로 메시지를 암호화하여 전달하고, 받은 암호문을 개인키로 복호화 함으로써 기밀성을 제공 할 수 있었습니다. 그리고 공개키로 비밀키를 암호화해서 전달한 후, 개인키로 복호화하는 방법으로 비밀키를 안전하게 교환 할 수 있었습니다.

 

이번에는 공개키로 할 수 있는 또 다른 중요한 기능인 전자 서명에 대해 알아보겠습니다.

 메시지에 전자 서명을 하고, 이 전자 서명을 통해 전자 인증을 할 수 있는 기능을 제공

위에서 전자 인증이라는 것은 지금까지 설명한 메시지와 메시지를 작성한 사람과의 인증입니다.

 

전자 서명은 앞에서도 설명하였듯이, 계약서의 도장이나 사인과 같은 역할을 합니다. 단지 물리적인 종이가 아니라 전자적인 데이터에 찍히는 도장 혹은 사인입니다. 그럼, 전자 서명은 어떻게 만들까요?

 

전자 서명을 만드는 열쇠는 공개키 암호화 알고리즘입니다. 다음 그림을 보시길 바랍니다.

  

 

 

앨리스는 메시지를 자신의 개인키로 암호화하여 암호문을 생성합니다. 앨리스에게는 원본 메시지와 자신의 개인키로 암호화 한 암호문이 있습니다. 이 두 개를 밥에게 보냅니다.

  

 

 

밥은 앨리스에게 받은 메시지와 메시지가 암호화된 암호문을 받습니다. 그리고 밥은 쉽게 구할 수 있는 앨리스의 공개키로 암호문을 복호화 합니다. 암호문은 원본 메시지를 암호화 한 것이므로, 암호문을 복호화 하면 원본 메시지를 얻을 수 있을 것입니다. 밥은 앨리스에게 받은 원본 메시지와 자신이 복호화 해서 만든 메시지를 비교합니다. 만약 이 두 개가 같다면, 메시지는 엘리스가 보낸 것이 확실하다고 생각 할 수 있습니다.

 

 

 

 

앞에서도 설명하였듯이 앨리스의 개인키로 암호화 한 메시지를 복호화 할 수 있는 것은 오직 앨리스의 공개키 뿐입니다.  다른 사람의 공개키로 복호화를 했다면, 원래 암호화 한 메시지와는 다른 엉뚱한 값이 생성될 것입니다. 따라서 앨리스가 보낸 암호화 하기 전의 메시지와, 앨리스가 같이 보낸 암호문을 앨리스의 공개키로 복호화하여 생성한 메시지가 같다면, 메시지는 앨리스가 보낸 것이라고 확신 할 수 있습니다.

 

앨리스가 원본 메시지와 함께 보낸 암호문이 바로 전자 서명입니다.

 

하지만 실제의 전자 서명 알고리즘에서는 원본 메시지를 그대로 개인키로 암호화 하지 않고, 메시지 압축 함수로 압축 한 후에 그 값을 개인키로 암호화합니다. 이것이 보통의 전자 서명 입니다. 압축해서 암호화하는 이유는 메시지의 크기가 너무 클 수 있기 때문에 암호화와 복호화에 걸리는 시간이 너무 길어질 수 있기 때문입니다. 다음에 설명할 RSA 전자 서명 알고리즘과 DSA 전자 서명 알고리즘에서 메시지 압축 함수를 전자 서명을 위해 사용 하는 것을 볼 수 있을 것입니다.

 

전자 서명의 3요소 (무. 부. 인)

---

무결성

전자 서명을 통해 메시지가 변경되지 않았다는 것을 알 수 있습니다. 원본 메시지가 변경되었다면, 메시지와 메시지의 전자 서명 값이 서로 일치되지 않을 것입니다.

 

인증

전자 서명을 함으로써 메시지를 보낸 사람의 인증을 할 수 있다는 것은 계속 설명 했던 내용입니다.

 

부인 방지

앨리스의 전자 서명은 오직 앨리스의 개인키로만 만들 수 있습니다. 따라서, 앨리스가 나중에 자신이 보낸 메시지가 아니라고 부인해도 상관 없습니다. 앨리스의 전자 서명은 오직 앨리스만이 만들 수 있기 때문입니다.

 

그럼 이제 전자 서명 알고리즘으로 가장 많이 사용 되는 RSA 전자 서명 알고리즘과, DSA 전자 서명 알고리즘을 살펴 보겠습니다.

 

RSA 전자 서명 알고리즘

---

RSA 전자 서명 알고리즘은 앞에서 설명한 앨리스와 밥의 전자 서명 교환, 그리고 인증 과정과 같습니다. 다만 다른 것은 메시지를 원본 그대로 개인키로 암호화 하여 전자 서명 값을 만들지 않고, 원본 메시지를 메시지 압축 함수로 압축 한 후, 그 압축 해시값을 암호화 하여 전자 서명 값을 만듭니다.

 

인증 시에는 받은 메시지를 메시지 압축 함수로 압축하고, 받은 전자 서명 값을 복호화 합니다. 그리고 이 둘의 값을 비교 하여 인증을 하게 됩니다. 만약 같다면 인증 할 수 있습니다.

 

다음 그림을 보면 이해가 쉽게 되실 것입니다.

 

 

 

 

DSA 전자 서명 알고리즘

---

DSA 는 (Digital Standard Algorithm) 의 약자입니다. 이 DSA 알고리즘도 RSA 전자 서명 알고리즘처럼 많이 쓰이는 전자 서명 인증 알고리즘 입니다.

 

DSA 알고리즘도 메시지를 압축하고, 그 압축 값을 개인키로 암호화 해서 전자 서명 값을 만드는 것은 RSA와 같습니다. 그러나 인증 방법이 약간 다릅니다. 위에서 설명한 RSA 전자 서명 알고리즘은 메시지를 인증 할 때 메시지를 압축 해시값으로 만들고, 복호화한 전자 서명 값과 비교하여 인증을 했지만, DSA 알고리즘은 검증 결과가 바로 예 또는 아니오로 나오게 되어 있습니다. 이 것은 DSA가 전자 서명/인증만을 위한 알고리즘 이기 때문입니다.

 

 

이번 포스팅은 Android에서 Button 위젯의 배경을 투명하게 하는 방법에 대하여 알아보도록 하겠습니다.

1. 첫번째 방법은 android:background="#00ff0000" 으로 xml에 적용하는 것입니다.

2. 두번째 방법은 Android 내부에 이미 선언된 transparent color를 사용하는 것입니다.

위의 첫번째 방법과 두번째 방법이 있지만 두번째 방법의 경우 Theme 에 따라 투명도가 정상적으로 작동하지 않을 수도 있으니 참고 하시기 바랍니다.

여기에서 첫번째 방법에 사용한 "#00ff0000" 값에 대하여 궁금하신 분도 계실 수도 있어 간단하게 설명드리도록 하겠습니다.

"#" 이하부터 "00ff0000" 라는 총 8자리 문자열을 00 / ff / 00 / 00 두 자리씩 나눕니다.

- 첫번째 문자열 "00" 은  투명도를 나타냅니다. 

- 두번째 문자열 "ff" 는  적색을 나타냅니다.

- 세번째 문자열 "00" 은 녹색을 나타냅니다.

- 네번째 문자열 "00" 은 청색을 나타냅니다.

적색과 녹색, 청색의 조화로 인해 새로운 Color 가 나타나게 됩니다.