박종명의 아름다운 개발 since 2010.06

HTML5에 대한 개괄적인 내용들을 정리해 보았다
이 문서는 HTML5 & API 입문 이라는 책과 관련 블로그 및 온라인 자료를 바탕으로 작성되었다

따라서 순수 창작물이 아니라 정리 및 요약을 목적으로 작성되었으며 일부 개인적 의견이
덧붙여지기도 하였음을 밝혀둔다

HTML5 개요와 기술적 특징

2010.06.14

근래 HTML5에 대한 관심이 뜨겁다. 웹이 더 이상 문서 공유나 문서 표현만을 위한 것이 아니라 하나의 응용프로그램으로써의 면모를 점점 갖추어 나가고 있다. 플러그인 기술과 스크립트의 조화로 웹이 응용프로그램화 되어 왔지만 이는 표준적인 HTML 스펙을 벗어나는 기술의 복잡한 결합으로 가능한 것이었다

HTML5는 웹을 둘러싼 난무한 비 표준을 지양하고 지능적이고 실행가능 한 웹 구현을 위해 탄생한 차세대 웹 표준 기술이다. 본 문서에서는 현재 이슈가 되고 있는 HTML5의 개요와 기술적 특징에 대해 기술한다

HTML5 등장 배경

웹 문서에서 웹 응용프로그램으로의 진화

웹에서 문서를 표현하고 문서간 연결(하이퍼링크)을 주 목적으로 탄생한 HTML은 웹 환경이 보편화되고 발전함에 따라 표준적인 방식으로 구현되는 웹 응용프로그램 수준을 요구하는 시대적 흐름에 의해 탄생하게 되었다. 또한 방대하게 퍼져있는 웹 문서를 의미 있게 구조화하고 효과적으로 탐색, 해석 할 수 있는 시멘틱(semantic) 웹 실현을 위한 표준이기도 하다

HTML5 정의

HTML5는 HTML의 차기 주요 제안으로써 HTML 4.01, XHTML 1.0, DOM Level 2 HTML에 대한 차세대 표준안이다. 플래시나 실버라이트와 같은 별도의 플러그인 없이 웹에서 표준적인 방식으로 멀티미디어를 재생하고 로컬 자원을 이용하는 등의 응용프로그램 수준의 웹을 개발하기 위한 기술의 총칭이다

현재 W3C를 주축으로 한 애플, 모질라, 구글, 오페라, 마이크로소프트 등 모든 웹 브라우저 벤더가 참여하고 있는 산업 표준이기도 하다

HTML History

HTML은 1990년 초부터 지속적으로 업그레이드 되어 왔다

특히 시멘틱 웹의 실현을 목적으로 한 XHTML 추진과 HTML5로의 방향전환이 주목할 만한 업계의 트랜드를 말해 준다

 

	1990년 웹 창시자인 팀 버너스리에 의해 설계 및 개발 시작
	1993년 6월 IETF에 의해 버전 1.0 표준 채택
	1995년 11월 버전 2.0 RFC 표준화
	1997년 1월 W3C 버전 3.2 권고
	1997년 12월 W3C 버전 4.0 권고
	1999년 12월 W3C 버전 4.01 권고 (이후 W3C에서 HTML을 더 이상 업데이트 하지 않을 것을 선언)
	2000년 1월 ~ W3C 시멘틱 웹 실현을 위한 XHTML 1.0 개발추진. 이후 XHTML2 개발 2009년 7월 XHTML2 사양 제정 중지 선언
	2004년 6월 XHTML 보급 실패와 시대 흐름에 부응하기 위한 HTML 업데이트 제안 애플, 모질라, 오페라 제안 -> W3C 거절 -> WHATWG 결성 -> 웹 어플리케이션 1.0이라는 이름으로 세부 명세 작업 시작
	2007년 W3C에서 HTML W/G를 결성하고 WHATWG와 공동작업 시작 2008년 1월 W3C에 의해 HTML5 초안 공개 2009년 5월 Google I/O 개발자 콘퍼런스, ‘차세대 웹 표준’ 으로 적극 추천됨. (전 세계 개발자들의 주목을 받기 시작함) 2009년 10월 WHATWG가 최종심사청구를 선언하고 표준화 작업을 W3C로 넘김 W33C: HTML5 표준화 작업 진행 WHATWG: HTML 업데이트 작업 계속 진행 2010년 6월 현재 W3C의 표준화 프로세스 중 최종 초안 상태 2012년경 권고 후보 예정(실제 브라우저에 표준 전체 기능 적용 요청) 이후 정식 권고

브라우저 및 호환성

현재 HTML5가 초안(Working Draft) 상태이기는 하지만 많은 브라우저 업체들이 이미 HTML5 기능들을

지원하고 있다

2010년 현재 지원되는 브라우저 목록

파이어폭스 3.5 이상, 크롬 3.0 이상, 사파리 3 이상, 오페라 10.0 이상, IE 9 이상

미 지원 브라우저 처리

HTML5는 자체적으로 이 기술을 지원하지 않는 브라우저를 위해 Fall Back 장치를 두고 있다

(태그 무시, 대안 텍스트 표시)

브라우저 호환성 확인:

지원되는 브라우저 내에서도 HTML5 세부 지원 여부가 조금씩 상이하다. 다음의 URL에서 상세한
브라우저 호환성 확인이 가능하다 (참고: http://caniuse.com/)

HTML5 현황

전 세계적인 브라우저 업체들이 이미 HTML5 개발에 협력하고 있으며 자사의 브라우저에 HTML5를

지원하고 있다. 경쟁 기술인 실버라이트를 먼저 선보인 마이크로소프트에서도 HTML5 지원에 동참하고 있는 실정이다. 또한 플래시 개발사인 어도비에서도 자사의 웹 저작도구인 드림위버 신제품에 HTML5
편집 기능을 포함시켰다. 아래는 HTML5에 대한 업계의 관심과 공식적 행보의 예이다

애플: W3C HTML WG의 공동의장으로 활동하면서 HTML5 표준화에 적극 동참.

자사 제품에 플래시 배제. HTML5 적극 지원

사파리개발자센터를 통해 HTML5 데모 및 가이드 제공   

구글: 구글 기어스(Google Gears) 포기, HTML5 집중 선언, HTML5 기반 유투브 서비스 시작

마이크로소프트: IE9에 HTML5 지원 발표. IE3의 TestDrive 사이트에 HTML5 영역 제공

오페라: 오페라 개발자 센터를 통해 HTML5 데모 및 가이드 제공

사례 및 데모

퀘이크 2: http://www.youtube.com/watch?v=XhMN0wlITLk (플레이 동영상)

HTML5의 Canvas와 Audio 및 LocalStorage , WebSocket, WebGL등의 기술을 이용해
GWT(Google Web Tookit)팀에서 퀘이크 2를 HTML5로 포팅하여 에뮬레이션 한 것
 (웹 브라우저에서 초당 60프레임까지 가능)

오픈 소스: http://code.google.com/p/quake2-gwt-port/

이미지 편집기: http://mugtug.com/darkroom/
포토샵과 유사한 기능 제공. HTML5 Canvas 사용

HTML5는 2012년경 그 모습이 완성되어 나갈 것으로 예상되며 많은 기업에서 이를 기반으로 한 웹 응용프로그램을 출시하여 기술이 본격적으로 활성화 될 것으로 보인다

요즘 모바일 환경의 어플리케이션들이 인기다
특히 아이폰과 같은 스마트폰의 어플이 날개 돋친듯 팔리고(?) 있다

수익을 목적으로 하는 유료 어플도 많으며 대부분 다운로드 시 유/무료가 구분되고 있다
그러나 모바일 어플이 점점 다양해지고 관련 비즈니스도 점점 성장함에 따라 기존 데스크탑 환경과
같은 소액 결제나 부분유료화 모델의 요구가 늘어나고 있다

그러나 지금까지 부분유료화 모델의 가장 큰 걸림돌은 애플의 과금 정책이었다
애플은 기본적으로 자사의 플랫폼에서 서비스되는 콘텐트에 대해 신용카드 결제를 원칙으로 하고 있다
얼마전 음원 서비스 업체에서 별도의 휴대폰 과금을 적용했다가 앱스토어에서 퇴출되는 사건도 있었다

그러나 어플을 개발하는 업체 입장에서는 애플의 앱스토어라는 시장을 배제할 수도 없다
애플의 앱스토어에는 가장 많은 어플이 등록되어 있으며 거래 역시 굉장히 활성화 되어 있기 때문에
무시할 수 없는 시장인 것이다

물론 애플에서도 부분유료화 모델의 요구를 수렴해서 In App Purchase 라는 SDK를 내 놓았다
이제 앱스토어에서도 다운로드 시에는 무료, 콘텐트 이용 도중 (필요시)소액 결제와 같은 부분유료화
모델을 정책에 위반되지 않게 구현할 수 있게 되었다

문제는 우리가 구축해야 할 '플랫폼'이다
단위 어플을 개발하는 개발사 입장이 아닌 어플들의 통합 환경을 제공하는 플랫폼 입장에서는 애플의
정책에 여전히 걸림돌이 많은게 사실이다

플랫폼은 비단 애플 앱스토어 뿐만 아니라 안드로이드나 윈도우모바일과 같은 다른 환경도 흡수해야
한다. 애플의 폐쇄형 모델과 안드로이드의 개방형 모델의 차이를 하나의 플랫폼에서 녹여야 하며
다른 제조사 및 통신사의 정책에도 민감할 수 밖에 없다

즉 심플하고 통일되고 통합된 빌링 플랫폼을 설계할 때 정책의 상이함과 연동의 특수성이 걸림돌이
될 수 있는 것이다

한가지 예를 들어 과거 위피기반의 게임에서 주로 이용되었던 '정보 이용료' 와 같은 모델을 스마트폰 어플에 도입하고자 할 때 개방형 플랫폼에서는 가능하겠지만 애플의 정책과는 충돌하는 부분이다

그렇다면 두 가지 버전으로 갈 수 밖에 없다.
아니면 빌링 오픈 API를 상당 수준 추상화 하여 몇 단계 랩핑과정을 거쳐야 한다.
이것은 자칫 복잡도만 증가시키고 플랫폼이 오히려 어플의 걸림돌이 될 수 있음을 경고한다. 

어쨋던 모바일 플랫폼 프로젝트의 빌링 플랫폼을 고민하면서 모바일 환경에서의 결제 시스템을
조사해 봤고 어떻게 플랫폼화 시키는 지 고려해 보면서 느낀 몇 가지 사항들이다

이는 문서로 정리 되었으며 1차 자료조사 수준과 일부 의견을 남기는 것으로 하였다

모바일 결제 시스템 조사

개요

본 문서는 모바일 환경에서의 통합빌링 플랫폼 구축을 위한 사전 조사 단계로

모바일 결제시스템의 모델과 사례, 과금 방식 및 연동 방식 등을 러프(rough)하게 조사한 문서이다

따라서 이 문서에서는 어떠한 결론을 도출하지는 않으며 조사 및 일부 의견을 게재하는 것으로 한다

모바일 빌링

모바일 빌링이란 아이폰, 구글 폰과 같은 스마트 폰과 아이패드와 같은 타블렛 PC 등의 모바일 장치에서

서비스되는 컨텐츠의 결제, 과금, 정산 등의 일련의 프로세스 및 체계를 일컫는다

모바일 환경은 기존의 데스크 탑 환경에 비해 표준을 준수해야 하며 애플과 같은 모바일장치 공급업체

및 통신사의 정책에 매우 민감하다. 이러한 환경의 차이는 기술적 차이를 가져오며 이는 기존 데스크 탑

환경에서의 빌링 모델과 다른 접근법을 필요로 한다

(모바일) 통합빌링 플랫폼

통합빌링 플랫폼이란 결제, 과금, 정산, 환불, 수익 배분 등의 일련의 체계를 플랫폼 차원에서 구축하여
일관되고 통합된 시스템과 연동 API를 제공함으로써 CP(Content Provider)의 개별적 빌링 개발의 부담을
제거하고 결제, 환불, 정산, 배분 등 전체 빌링 활동을 통합되고 일관된 정책과 프로세스로 지원하는
소프트웨어 환경 및 비즈니스 시스템을 일컫는다

스마트 폰 결제 시스템 현황

스마트 폰 환경에서의 소액 결제 및 부분유료화를 위한 모델 및 기존 PG사가 제공하는 솔루션에
대해 정리한다

1) (WIPI 기반) 정보 이용료 및 3G 과금

기존 위피 기반 환경에서의 소액 결제는 통신 요금(정보이용료)으로 부과된다

(각 통신사에서 위피 기반의 결제 모듈(API)를 제공하고 이를 게임에 연동하는 구조)

이 모델을 안드로이드와 같은 개방형 플랫폼에서는 응용 및 적용가능 한 것으로 파악된다

(애플 정책과 충돌되는 부분일 수 있음)

3G 과금을 부분유료화로 사용해도 될 듯 하며 다만 이통사의 수수료율이 꽤 높은 편이다(20~30%)

2) In App Purchase (by Apple)

아이폰 앱 부분 유료화 지원 시스템.

iTunes 에 등록된 신용카드를 이용한 결제 시스템(아이폰 OS 3.0부터 지원)

애플에서 연동 SDK 제공. 결제는 애플을 통해 이루어 지며 수익 배분은 7: 3 (개발자: 애플)

연동 사례>

컴투스 홈런 배틀 3D 아이템 구매에 적용, Gogo3D 네비게이션 지도 데이터 다운로드에 적용 등

In App Purchase 프로그래밍 가이드>

http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html

gogo3D의 In App Purchase 결제 시스템 Flow(UI 기준)>

3) INIPay Mobile for iPhone (by 이니시스)

PG사 이니시스에서 개발한 아이폰용 모바일 결제 시스템

App to App, App to Web, Web to App, Web to Web 방식 지원 (가맹점 to PG)

App to App 및 Web to App 방식>

이니시스 전용 앱을 아이폰에 설치되어야 함. 가맹점 App(Web)에서 PG App을 실행하는 구조.

App to Web 및 Web to Web 방식>

가맹점 App(Web)에서 HTTP Post 방식으로 PG 결제 페이지를 호출하는 구조

이니시스 결제 전용 앱 및 웹을 통한 결제 연동 모델 지원>

이니시스 전용 앱을 통한 결제 Flow(프로세스 기준)>

4) tMobile (by 다날)

휴대폰 전문 PG 사인 다날에서 개발한 스마트 폰 용 휴대폰 결제 시스템.

스마트 폰 장치 수준의 지원은 없음

(다날 결제 서버와 이와 연동하는 클라이언트 모듈만 제공하는 심플한 형태)

(가맹점의 서버를 필요로 하고 스마트폰 – 가맹점간 통신은 가맹점 몫)

자바기반 연동 API 제공. Server to Server 방식

다날 tMobile 결제 Flow>

5) 모빌리언스 스마트 폰 휴대폰 결제 시스템 (by 모빌리언스)

휴대폰 전문 PG 사인 모빌리언스에서 개발한 스마트 폰 용 휴대폰 결제 시스템

 HTTP Post 호출 방식 및 Socket 방식 지원

6) BC카드 ISP 앱 (by BC카드)

아이폰 용 모바일 안전결제 솔루션

신용카드 정보 일회 등록 후 ISP비밀번호 만으로 결제 가능

의견

폐쇄 및 개방형 플랫폼에 대한 이중적 고려

애플은 자사의 플랫폼에서 서비스되는 콘텐트에 대해 신용카드 결제를 원칙으로 하고 있다

이러한 애플의 폐쇄적 정책은 모바일 빌링 플랫폼 설계에 중요 변수로 작용할 것으로 보인다

기타 다른 개방형 플랫폼에서는 빌링 모델 설계의 자유도가 높을 것으로 예상된다

 

통합 가상 머니 도입

통합 가상 머니의 도입을 고려해 볼 만 하다 (개방형 플랫폼에 한해?)

심플한 모델 도출이 가능하며 빌링을 플랫폼화 시키기 가장 쉬운 구조이다

매끄러운 소액 결제?

게임 진행 도중 특별한 추가 정보나 웹 사이트를 열지 않고 자연스럽게 결제를 할 수 있는 모델로는

다음과 같은 것이 있을 수 있다

- 애플의 In App Purchase
- 3G 과금(기존 위피 기반 정보 이용료 부과 모델)
- 휴대폰 결제(기존 데스크 탑 환경과 거의 유사한 모델을 모바일 환경에서도 이용)

 

기타 현재 PG사에서 제공하는 모바일 결제 솔루션의 대부분은

APP TO APP 이나 APP TO WEB 과 같은 이중 호출 구조를 지니고 있어 매끄럽지 못하다
(빈번한 소액결제 모델에 부적합. 다만 가상 머니 일괄 충전개념으로는 도입할 만 함)

얼마전 참석했던 세미나에서 뷰포트(Viewport)에 대한 언급이 잠시 있었다

모바일 웹 UI 개발시 Display 영역 조절과 관련된 기술요소인듯 하였고 자세한 설명보다는
뷰포트 메타태그 기술방식 위주의 설명이여서 완전한 개념을 파악하기는 힘들었다

뷰포트에 간략히 조사해 보았다

뷰포트가 사파리 기술?
뷰포트를 조사하다 처음 든 의문은, 이것이 애플의 (모바일) 사파리 기술인가? 하는 것이었다

대부분의 인터넷 블로그에서 뷰포트를 소개하면서 아이폰 기반 모바일 웹을 대상으로 하였고
사파리 브라우저가 인식하는 메타태그로 설명하고 있었다

또 다른 자료에서는 아이폰과 안드로이드 심지어 오페라 모바일 등 다른 브라우저에서 권장하는
뷰포트 태그를 제시하기도 하였다

뭐지.. 이거? 뷰포트 태그가 모바일 사파리가 인식하는 개념처럼 하더니 다른 브라우저에서도
인식되나보네? .. 하면서 살짝 의문이 들기 시작했다

짧은 시간 의문을 품다 문득  떠 오른 생각은 바로 웹킷(WebKit) 이었다
웹킷은 아이폰에 있는 모바일 사파리의 핵심 엔진이며 안드로이드의 브라우저 기반이기도 하다
더불어 웹킷은 다른 모바일 브라우저에서도 사용되고 있는 기술이다
웹킷과 뷰포트의 연결고리가 더 자연스럽다는 생각이 들었다

그렇다. 뷰포트 메타태그는 웹킷 기반의 모바일 브라우저에서 인식 가능한,
표시영역 제어와 관련된 기술요소 였던 것이다

2013.01.15: 위 내용 수정합니다. xCoda 님이 댓글로 안내 해 주셨습니다
아래 댓글 내용 확인 바랍니다.

뷰포트(Viewport)란?
뷰포트라는 개념자체는 모바일 웹에 국한된 것은 아니다
DirectX 나 여타 그래픽, 디자인 관련 기술에 개념적으로 사용된 용어인 듯 하다
그러나 처음 나에게는 낯선 용어였다

뷰포트를 대략 정의하자면,
컴퓨터나 휴대 단말기 등 장치에 Display 요소가 표현되는 영역을 말한다
모바일 웹의 경우 아이폰 사파리 브라우저에서 웹 페이지가 표시되는 영역으로 해석할 수 있다

다음 두 애플의 자료에서 뷰포트에 대한 상세한 내용이 제공되고 있다
Configuring the Viewport
Supported Meta Tags 


뷰포트 설정 참고
포털 등 기 개발된 모바일 웹 사이트에서 설정한 뷰포트 태그를 참고해 보자

1) m.naver.com
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, target-densitydpi=medium-dpi" />

2) m.daum.net
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

3) m.nate.com
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

4) m.yahoo.com
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

5) m.aladdin.co.kr
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

어쩜 이렇게 모두 거의 동일할까?
이것이 최적의 구성인가... ㅎㅎ

가로 너비는 장치 너비를 지정하였으며 사용자에 의해 확대/축소가 되지 않도록 설정하고
초기 스케일은 1.0 즉 확대/축소 없는, 본 크기 그대로를 지정하였다

윈폼 닷넷(Windows Form .NET)  응용프로그램 개발 할 때 폼(Form) 안에 웹브라우저 컨트롤을
삽입하여 윈폼에서 웹 브라우징 프로그램을 만들 수 있었다

안드로이드 역시 프로그램 안에 웹 브라우징을 할 수 있는 일종의 컨트롤이 제공된다
닷넷에서는 컨트롤이라고 표현하지만 안드로이드에서는 위젯이라고 표현한다

바로 WebView 위젯이다

안드로이드 OS의 웹 브라우저는 웹킷(WebKit) 엔진에 기반을 두고 있다
웹 킷은 안드로이드 뿐만 아니라 애플의 사파리 브라우저의 기반이기도 하다

WebView 위젯 역시 안드로이드 라이브러리에서 제공하는 웹킷 기반 브라우저 위젯이다
이 웹뷰를 이용해 안드로이드 앱 안에 브라우저를 내장해서 사이트를 탐색해 보자

다음과 같이 main.xml 파일에 WebView 위젯을 정의한다

그리고 자바소스 파일에서 다음과 같이 WebView 를 통해 특정 사이트를 검색해 본다

주의할 것은 권한문제이다
웹 뷰를 통해 인터넷 사이트를 탐색하기 위해서는 인터넷 접근 권한이 요구된다
메니페스트파일에 권한 정보를 명시해야 하는데 그렇지 않다면 프로그램 실행 시 다음과 같은
오류를 만나게 될 것이다

음.. 뭔가 개인적인 오해가 있는 듯 하다

폰갭이라는 프레임워크를 접한지 채 이틀이 되지 않은 이 시점, 나의 착각이 하나 있는 듯 하다

처음 폰갭 컨셉을 접했을 때는 순수 웹 환경인 줄 알았다
즉 단순히 폰갭 스크립트 파일을 참조하여 일반적인 웹 페이지를 개발해서 웹 서버에 올려 두면
폰에 내장된 (사파리와 같은) 웹 브라우저를 통해 서비스 되는 방식인 줄 알았다

그런데 프로그램의 구조를 살펴 보니,
안드로이드 네이티브 앱 환경에 포함되어 웹 페이지가 실행되는 구조인 듯 하다
다시말해, 안드로이드 마켓에 앱을 등록하는 네이티브 환경인 것 같다

물론 한번 등록하면 웹 리소스만 변경하면 되기 때문에 업데이트는 웹 환경인 것은 맞는 것 같지만..

결국 폰갭은 웹 리소스를 포함하는 컨테이너 역할을 하는 네이티브 앱 인가 ???

만일 그렇다면 초기 나의 생각과는 다르지만,
결국 각 환경에 맞는 컨테이너만 (아이폰, 안드로이드, 심비안 등) 따로 만들고 내부 웹 리소스는 
HTML, JavaScript, CSS 등을 이용하여 동일하게 개발할 수 있는, 웹의 장치 독립성의 장점은
그대로 일 것이다

PhoneGap 개발환경을 구축하고 샘플 프로젝트를 생성하여 시뮬레이터에서 띄워 보았다
또한 이클립스를 이용해 안드로이드 프로젝트로 불러와서 실행해 보았다

자동으로 생성된 샘플 프로젝트이 코드 구조를 대략 살펴 보았다

phonegap.jar 라이브러리
폰갭 프로젝트는 phonegap.jar 라는 압축 형태의 클래스 모음인 라이브러리가 포함된다
안드로이드 프로젝트가 각 버전에 맞는 android.jar 가 필요하듯이 미리 정의된 폰갭 클래스들을
위한 라이브러리가 필요하다

웹 리소스
폰갭 프로젝트를 만들면 index.html 파일과 css, js 파일 등의 웹 리소스가 자동 생성 되는데,
이 파일들은 프로젝트의 assets 폴더에 위치하게 된다

보통 안드로이드 프로젝트의 경우 assets 폴더의 역할은 컴파일 되지 않는 큰 리소스를 담는 용도이다
프로그램은 코드와 리소스로 구분되는데 리소스는 또 컴파일 되는 경량의 리소스와 원본 그대로 저장하는 큰 리소스로 구분된다

안드로이드 프로젝트이 res 폴더는 경량의 리소스를 위한 폴더이며 assets 는 큰 리소스를 위한 폴더이다. HTML 파일이나 동영상과 같은 큰 데이터를 위한 공간이 assets 인 셈이다

폰갭 프로그램의 사용자 화면에 해당하는 html 파일과 Device 기능 호출을 위한 js 파일 등 웹 리소스가assets 폴더에 위치하고 있다

글 작성일: 2010/02/10 , 옮긴 날: 2010/07/13

안드로이드 SDK를 설치하면 샘플 프로젝트가 같이 설치되는데요

아래 위치에 샘플이 있습니다
안드로이드 SDK 설치폴더 -> platforms -> 각 버전별 폴더(ex: android-2.1) -> samples

android2.1의 샘플은 총 16개 있네요
이 샘플 프로젝트 중 하나를 이클립스에 불러와 보겠습니다
이클립스의 상단 메뉴에서  File -> New -> Project 선택한 후, Android Project 타입을 선택합니다
그리고 Next를 하면 아래 창이 나오는데요

이미 만들어진 샘플 프로젝트를 불러오는 것이니까, Create project from existing source 를
선택합니다. 그리고 Location 에 샘플 프로젝트 중 하나를 지정해 주는데요, 저는 ApiDemos 라는 샘플을 지정했습니다. 그러면 나머지는 자동으로 입력되구요.. Next->Finish 하면 완료됩니다

 

• Application framework: 소프트웨어 컴포넌트의 재사용과 재배치를 가능하게 함
• Dalvik virtual machine: 모바일 장치에 최적화된 자바 가상 머신. 구글에서 Sun과의 지적재산권
  문제를 피하기 위해 개발
• Integrated browser: WebKit 엔진 기반의 브라우저 제공
• Optimized graphics: SGL기반의 2D, OpenGL ES 1.0기반의 3D 그래픽 라이브러리
• SQLite: 모바일 장치를 위한 데이터 저장 장치
• Media support: 오디오, 비디오, 이미지 포맷 지원
• GSM Telephony (hardware dependent)
• Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
• Camera, GPS, compass, and accelerometer (hardware dependent)
• Rich development environment: 장치 에뮬레이터, 디버깅 툴, 메모리, 성능 프로파일링,
  이클립스 플러그인 제공

• 컴포넌트의 재사용을 간단하게 하기 위한 역할. 어플리케이션이 자신의 기능을 공개하면 다른
  어플리케이션에서 해당 기능을 사용할 수 있게 함
• Content Providers: 다른 어플리케이션의 데이터에 접근할 수 있는 방법을 제공
• Resource Manager: 스트링, 그래픽, layout 파일등 코드가 아닌 파일에 접근할 수 있게 함
• Notification Manager: 어플리케이션이 사용자에게 경고를 할 수 있게 함
• Activity Manager: 어플리케이션의 lifecycle을 관리하고 어플리케이션의 네이게이션을 backstack을 관리

• C/C++ 기반의 라이브러리를 포함하고 있고, 이는 application framework를 통해 제공
• System C library: 리눅스 기반의 임베디드 장치에 특화된 표준 C 라이브러리
• Media Libraries: PacketVideo's OpenCORE기반의 비디오, 오디오, 이미지 라이브러리
• Surface Manager: 디스플레이 접근 관리 라이브러리
• LibWebCore: 웹 브라우저 엔진
• SGL: 2D 그래픽 엔진
• 3D libraries: OpenGL ES 1.0 API기반의 라이브러리, 3D 하드웨어 가속또는 최적화된 3D
  소프트웨어 래스터라이저를 사용
• FreeType: 비트맵과 벡터 폰트 렌더링 엔진
• SQLite: 가볍고 강력한 관계형 데이터베이스 엔진

• http://developer.android.com/guide/basics/what-is-android.html
  

글 작성일: 2010/01/21 , 옮긴 날: 2010/07/13

어제 구입한 책  을 저녁에 집에서 한 챕처 훓어 봤습니다
안드로이드 소개와 비전 그리고 개발 프레임워크, 특징 등을 개괄적으로 기술하고 있더군요

물론 안드로이드가 주제인 책인만큼, 좋은 글.. 상당히 많죠
살짝 홍보성 느낌이 있을지언정, 아주 매력적입니다

많은 내용 중 안드로이드의 특징에 대해 요약해 봅니다
일단 안드로이드 폰에 탑재되는 기본 기능에 대한 차별성은 역시 구글 자체 컨텐츠와의 긴밀한
통합입니다. 예를 들어 G메일 호환, 구글 캘린더, 연락처 등의 개인 온라인 서비스, 구글 검색등을
들 수 있습니다

개발환경의 특징으로 보면,
자바 기반 개발 환경을 지원하며 기존 자바가상머신(JVM)이 아닌 모바일 전용 자바가상머신인 Dalvik
위에서 된다고 하네요. 물론 자바통합개발환경인 이클립스와의 연동도 가능하구요

참고로 전 닷넷 개발자인데요, 자바개발자들이 부럽군요. 익숙한 개발 환경으로 인한 진입장벽이 저 보다는 낮을테니깐요. 그러나 뭐 자바면 어떻습니까? 개발이야 다 비슷하죠

마지막으로 책에 기술된 내용중, 안드로이드에만 있는 것이 소개되어 있군요

- 구글 맵 어플리케이션
구글 맵은 유명하죠. 우리가 만드는 어플리케이션에서 사용할 수 있도록 컨트롤 형태로 제공된다고 합니다. 구글 맵을 응용한 다양한 컨텐츠를 개발할 수 있겠네요

- 백그라운드 서비스
폰에서 다른 기능을 이용하고 있는 중에도 이벤트를 발생시켜 백그라운드에서 돌아가는 어플리케이션을 만들 수 있습니다

- 공유 데이터와 프로세스 간 통신
안드로이드에 기본 탑재되는 네이티브 어플리케이션의 데이터를 공유할 수 있고 그 기능을 이용할 수 있다고 하네요

- 네이티브 플랫폼에 대한 접근 허용
안드로이드는 네이티브 어플리케이션과 서드파티 어플리케이션을 차별하지 않는다고 합니다
이는 폰에 기본 제공되는 기능을 서드파티 대체물로 전부 교체할 수 있도록 허용한다고 하네요
장치가 가진 룩앤필을 바꾸는 전례없는 능력이 제공됩니다

- P2P 메시징
폰 대 폰, 어플 대 어플간 P2P 메시징을 지원하다고 합니다


이러한 특징들을 조합하면 다앙한 컨텐츠가 개발될 수 있겠네요
책에도 언급되어 있는 것 처럼, 친한 친구가 몇 m내에 있으면 알림을 한다던가 근처 주요 장소를 알려
준다던가..

생각만 해도 재미있네요...

PhoneGap 이라는 것이 도대체 어떤 식으로 구성되고 어떤 식으로 개발되는지 알아보기 위해 환경 구추을 해보기로 했다

오늘 환경 구축을 하고 샘플 프로젝트도 돌려 봤지만.... 음.. 여전히 낯설다
일단 PhoneGap 개발 환경을 셋팅하는 것을 정리 해 본다

1. 안드로이드 개발 환경 구축
PhoneGap 는 각 모바일 플랫폼 별로 개발환경이 셋팅되는 듯 하다
음.. 이건 좀 의외다. 단순히 기본 웹 개발 환경에서 적당히 갖다 붙이기만 하면 될 줄 알았는데,
각 개발환경과 유기적으로 결합된 느낌이다. 물론 설치 후에는 웹 개발 하듯 하면 되는 것 같다

안드로이드 기반 PhoneGap 를 설치하기 위해서 먼저 안드로이드 개발환경이 구축되어 있어야 한다
다음 글을 참고해서 안드로이드 개발 환경을 구축한다

http://mobilepp.tistory.com/18

2. Apach ANT 설치
이것은 뭣에 쓰는 물건인고? 음.. 필요 하다고 하니, 일단 설치 해 보자
다음 사이트로 이동해서 압축파일을 다운 받아서 압축해제 한다

http://ant.apache.org/bindownload.cgi