01.JAVA/J2me2008. 11. 27. 13:09
반응형
SK 텔레콤 : 011 017 -->NATE WAP (최근 네이트ⓜ브라우저 개발)
LG 텔레콤 : 019 --> Ez-i WAP (LG 텔레콤 역시 조만간 업그레이드된 브라우저를 출시 예정)
KTF : 016 018 --> ME1.3 (최근 KUN 2002 개발)

http://www.magicn.com/kun
(KUN 2002 개발자 페이지)

http://phone.nate.com/devel/
(WAP GVM SK-VM SIS Wavelet MPEG4 개발자 페이지 )
------------------------------------------------------------------------------------------------
SK 텔레콤 : 011 017 --> SK-VM GVM WITOP
LG 텔레콤 : 019 --> JAVA-Station
KTF : 016 018 --> BREW MAP
앞으로 나오게 될 통일 플랫폼 : WIPI

신지소프트 GVM (Mini C)
개발 회사 : 신지소프트http://sinjisoft.co.kr
배포 사이트 :http://gvmclub.com
이미지 지원 : VDI 포맷(*.sbm)

XCE SK-VM (MIDP1.0 + SKVM API)
개발 회사 : XCEhttp://www.xce.co.kr/
배포 사이트 :http://www.developerzone.co.kr/
이미지 지원 : png, lbm, sis

SK텔레콤 WITOP (GVM + SK-VM + Thin Multimedia 수용 위해)
개발 회사 : SK 텔레콤
배포 사이트 :http://witop.sktelecom.com

LG텔레콤 JAVA-Station (MIDP + LGT API)
개발 회사 : LG텔레콤
배포 사이트 :http://java.ez-i.co.kr/
테스트 사이트 :http://joyworld.co.kr/
이미지 지원 : png, sis

퀄컴 BREW ( C/C++, 멀티팩)
개발 회사 : 퀄컴http://www.qualcomm.com
배포 사이트 :http://www.qualcomm.com/brew/kr/
이미지 지원 : Brew 2.0 bmp, sis, png, bci, jpg

모빌탑 MAP (C기반)
개발 회사 : 모빌탑http://www.mobiletop.co.kr/
배포 사이트 :http://www.mapcp.co.kr/cpadmin2/

표준플랫폼 WIPI (Clet + Jlet API)
개발 회사 : 아로마 소프트http://www.aromasoft.co.kr/
배포 사이트 :http://www.mobilejava.co.kr/
이미지 지원 : bmp, gif

------------------------------------------------------------------------------------------------
J2ME & BREW 관련사이트
http://www.joyworld.co.kr/
http://www.mobilejava.co.kr/
http://www.mobilelab.co.kr/
http://www.qualcomm.com/brew/kr/
http://www.mobilebrew.net/
http://www.brewsdk.co.kr/
http://brewis.co.kr/
http://cafe.daum.net/brew/

MIDP Source 해외 사이트
http://midlet.org/jsp/index.jsp
http://www.midlet.com/
http://www.midletcentral.com/
http://www.javamobiles.com/
http://www.microjava.com/(http://www.kvmworld.com/)
http://www.spruce.jp/freemidlets/
http://jshape.com/midp/
http://jshape.com/midp/forum/wood/
http://www.corej2me.com/
http://groups.yahoo.com/야후 구룹

http://www.anybil.com/무선 인터넷
http://www.mobilejava.co.kr/mj_home/sub_page/lecsub.jsp핵심강좌
http://wireless.java.sun.com/midp/samples/index.htmlSUN midp 예제
Posted by 1010
01.JAVA/J2me2008. 11. 27. 13:09
반응형
MIDP
사용자 삽입 이미지
MIDP는 모바일 인포메이션 디바이스(MID)를 목표로 CLDC 컨피규레이션을 기반으로 설계된 자바 클래스 라이브러리에 대한 명세이다. 그러므로, MIDP 명세는 CLDC의 명세를 확장하거나, 구체화 하거나, 변경을 가하고 있다. 우선 MIDP에서 좀 더 구체화된 하드웨어 디바이스들의 특징을 보자
 
사용자 삽입 이미지디스플레이 요구사항
    - 96x54 이상의 스크린 사이즈
  - 비트 이상의 디스플레이(모노크롬)
- 종횡비(aspect ratio)가 약 1:1에 근접
사용자 삽입 이미지입출력 요구사항
    - 한 손, 혹은 두 손으로 입력가능한 입출력 메커니즘
사용자 삽입 이미지메모리 요구사항
    - MIDP 컴포넌트를 위한 128K의 비휘발성 메모리 공간
    - 애플리케이션이 생성하는 데이터의 저장을 위한 8K의 비휘발성 메모리 공간
    - 자바 런타임을 위한 32K의 휘발성 메모리 공간
사용자 삽입 이미지네트워킹 요구사항
    - 양방향이고, 무선이며, 제한된 대역폭에, 간헐적으로 연결될 수 있음
그리고, MIDP 명세서는 다음과 같은 부분들을 정의하고 있다.

사용자 삽입 이미지애플리케이션 모델
사용자 삽입 이미지유저 인터페이스와 이벤트 핸들링
사용자 삽입 이미지영속적 저장공간
사용자 삽입 이미지네트워킹
사용자 삽입 이미지타이머 지원

사용자 삽입 이미지2.1 JAM과 신개념 애플리케이션 모델
  Application의 다운로드와 실행이라는 혁신적인 모델을 제시했던 Java언어의 특징을 한껏 살려서 자원이 적은 기기에서 실행모듈을 download하여 실행토록한다는 아이디어가 midlet이다. 이 프로그램방법은 applet과 유사한점이 많다.
MIDlet과 ‘애플리케이션 관리 소프트웨어’라는 개념은 초창기의 자바 애플릿 만큼이나 혁명적이다. 하지만, 지금은 많은 분들이 애플릿이라는 경험을 통해서 실행코드의 네트웍 이동성에 대해서는 이미 친숙해 진 상태일 것이므로, MIDlet이라는 새로운 애플리케이션 모델을 받아들이기에는 큰 무리가 없을 것 같다.
JAM(Java Application Manager)는 CLDC/MIDP 플랫폼의 새로운 애플리케이션 모델을 지원하기 위한 애플리케이션 관리 소프트웨어이다. JAM의 역할은 MIDP 애플리케이션, 즉, MIDlet을 다운로드하여 설치하고, 업그레이드하고, 실행하고, 삭제하는 것이다. <표 6>은 이러한 JAM의 기본 기능들을 정리한 것이다.

왜 JAM이라는 이해하기 쉽지 않은 새로운 애플리케이션 모델을 도입해야만 했을까? 필자가 사용하는 모 이동통신 단말기는 SMS 기반의 인터넷 기능이 디폴트로 내장되어 있다. 이 단말기로 WAP 서비스를 받기 위해서는 단말기 A/S 센터로 가서 소프트웨어 업그레이드를 해야 했다. 이 때, 서비스 매뉴얼에 충실한 직원이, “몇 개의 게임은 즐길 수 없게 되며, 전화번호 저장공간이 300개에서 200개로 줄어들게 됩니다. 그래도 업그레이드를 받으시겠습니까?”라고 물었다. 추측하건대, WAP 브라우저는 SMS 브라우저보다 메모리 풋프린트가 크고, 그 차이로 인해, 전화번호 저장공간 100개를 희생시키는 것이다.

여기서 우리는 세 가지의 개선점을 발견할 수 있다. 첫째는 고객이 굳이 소프트웨어 업그레이드를 받기 위해 A/S 센터를 찾는 번거로움을 없애준다면 좋을 것이다. 둘째는 게임과 같은 취향에 따라 다양한 선택의 폭을 가진 애플리케이션을 직접 고를 수 있도록 하면 좋을 것이다. 셋째는 이렇게 설치한 프로그램이 업그레이드되었을 경우, 자동적으로 업그레이드를 수행해 주면 좋을 것이다. JAM이 등장한 이유 중의 하나가 이런 것들을 가능하게 하기 위한 것이다.
기 능
통 신 방 법
추출(retrieval) 삭제(removal)
인스톨(installation) 추출한 MIDlet을 디바이스에 설치하는 기능.
실행(launching) MIDlet을 호출하는 기능.
버젼 관리 설치된 MIDlet을 새로운 버전으로 업그레이드 하는 기능.
삭제(removal) 설치된 프로그램을 삭제하는 기능
[ 표 5 - JAM의 기본 기능 ]

JAM의 구현은 주로 C와 같은 네이티브 언어로 작성된 소프트웨어 모듈로 이루어 지는 데, CLDC 1.0 베타와 MIDP Early Access 1에는 JAM을 통한 애플리케이션 관리를 기본으로 하고 있다. <그림 4>는 JAM을 통한 애플리케이션의 설치 과정에 대한 예이다. 실행과 업그레이드 및 삭제 과정은 일반적인 애플리케이션의 일종으로 보면 된다. 즉, 사용자 인터페이스를 통해 설치한 애플리케이션을 찾아서 수행하고, 업그레이드하고, 삭제하는 작업을 수행하는 하나의 애플리케이션이라고 생각하면 된다는 것이다.
사용자 삽입 이미지
[ 그림 4 - JAM을 통한 애플리케이션 설치과정 ]

이 글의 뒷부분에서 실제로 MIDlet을 개발하고, 배포하는 과정을 살펴보면서 좀 더 구체적으로 언급하겠지만, 우선은 여기서 JAM과 연관하여, MIDlet 수트(suite)의 구성과 애플리케이션 디스크립터, 애플리케이션 라이프 사이클에 대하여 알아 보도록 하자.
아래 그림에서 동작되는 순서를 정리해 보자
1. Descriptor file로 링크되어 있는 WML 문자열을 선택한다.
2. WAP browser로 부터startJAM 를 호출한다.
3. Descripter file을 다운로드한다.
4. JAR file과 icon file을 다운로드한다.
5. JAR file을 저장한다.
6. main class name이름으로 KVM 시작한다.
7. JAR file로 부터 class를 로딩한다.
8. 다운완료 메시지나 과금 작업을 호출한다.

사용자 삽입 이미지
[ 그림 5 - MIDlet배포시 흐름도 ]

사용자 삽입 이미지MIDlet 배포 파일 - JAR.
  앞에서 MIDP 애플리케이션, 즉 MIDlet은 JAR 파일의 형태로 배포되어야 한다고 얘기했다. 이 JAR 파일에는 MIDlet 수트의 패키지가 들어갈 수 있는데, MIDlet 수트의 패키지는 다음과 같은 세 가지의 구성요소를 가지고 있다.
사용자 삽입 이미지JAR 컨텐츠에 대한 설명을 담고 있는 매니페스트(manifest)
사용자 삽입 이미지MIDlet 클래스를 상속한 클래스들과 다른 공유 클래스들
사용자 삽입 이미지MIDlet이 사용하는 리소드 파일들(예를 들면 아이콘, 이미지 등)

매니페스트 파일에 포함되는 JAR 컨텐츠에 대한 설명은 MIDlet 애트리뷰트라고 하는 JAM이 사용할 애플리케이션에 대한 정보이다. 즉, JAM이 애플리케이션을 다운로드하여 설치하고, 업그레이드하고, 실행하고, 삭제하기 위해서는 애플리케이션의 이름, 버전, 제공자, 등의 정보가 반드시 필요하며, 이러한 MIDlet 애트리뷰트를 매니페스트를 통해 제공할 수 있다는 것이다. <표 7>은 MIDP 명세에서 정의된 MIDlet 애트리뷰트들이다. 이러한 애트리뷰트는 다음에 설명할 애플리케이션 디스크립터에서도 정의될 수 있으며, 만약, 애플리케이션 디스크립터와 매니페스트에서 동시에 정의되었을 경우에는 애플리케이션 디스크립터가 우선한다.

애트리뷰트 이름
설 명
MIDlet-Name
MIDlet 수트의 이름
MIDlet-Version MIDlet 수트의 버전 번호. major.minor.micro의 형태로 정의되며, JAM이 설치 및 업그레이드를 위한 정보로 활용.
MIDlet-Vendor MIDlet 수트의 제공자.
MIDlet-Description MIDlet 수트에 대한 설명
MIDlet-<n> JAR 파일안에 포함된 MIDlet의 표시이름, 아이콘, 클래스명. 하나의 JAR 파일에 여러 개의 MIDlet이 포함되어 있을 경우, 번호로 식별하게 되며, <n>은 최소값이 1이고, 반드시 순차적인 숫자를 사용하여야 한다
MIDlet-Jar-URL JAR 파일이 로딩될 URL
MIDlet-Jar-Size JAR 파일의 크기(바이트 단위)
MIDlet-Data-Size MIDlet이 필요로 하는 영속적 데이터의 크기(바이트 단위). 디바이스에서는 이에 따라 추가적인 스토리지를 제공해야 하고, 디폴트는 0이다.
MicroEdition-Configuration 시스템 프로퍼티의 microedition.configuration 값과 동일한 J2ME 컨피규레이션(예를 들어, “CLDC-1.0”)
MicroEdition-Profile 시스템 프로퍼티의 microedition.profiles 값과 동일한 J2ME 프로파일(예를 들어, “MIDP-1.0”)
[ 표 6 - MIDlet 애트리뷰트 ]

애플릿이 java.applet.Applet 클래스를 반드시 상속해야 하듯이, MIDlet도 javax.microedition.midlet.MIDlet 클래스를 반드시 상속해야 한다. JAM은 MIDlet 클래스를 통해 애플리케이션의 시작, 일시정지, 종료 등을 제어하기 때문이다. 그러므로, MIDlet 클래스를 상속한 클래스를 하나의 MIDP 애플리케이션(MIDlet)이라고 볼 수 있으며, 하나의 JAR 파일 안에는 여러 개의 MIDlet이 존재할 수 있다. 하나의 JAR 파일, 즉, 같은 MIDlet 수트에 포함된 MIDlet들은 리소스와 실행환경을 공유한다.
아이콘, 이미지 등의 리소스 파일은 여러 MIDlet들이 공유할 수 있으며, MIDlet 수트, 즉 JAR 파일 안에 함께 포함된다. 사용자가 특정 애플리케이션을 선택해서 실행하기 위해서는 JAM이 최소한의 애플리케이션에 대한 정보를 사용자에게 보여 주어야 하는데, 이는 MIDlet 애트리뷰트에 정의된 이름과 아이콘을 이용할 수 있다. 예를 들어, 다음 MIDlet 애트리뷰트는 ‘프로미 안녕?’이라는 애플리케이션의 이름과, promy.gif 파일 아이콘을 JAM이 사용자에게 보여 주고, 사용자가 선택할 수 있게 한다.

   사용자 삽입 이미지MIDlet-1 : 프로미 안녕?, promy.gif, promy.example.midp.HelloPromy

사용자 삽입 이미지
2.3 애플리케이션 디스크립터, JAD
  JAM이 네트웍을 통해 MIDP 애플리케이션을 다운로드하려면, 우선은 JAR 파일을 봐야 한다. JAR 파일을 추출하는 방법은 여러가지가 있겠지만, 가장 손쉬운 방법이 브라우저를 이용하는 것이다. 웹 브라우저이든, WAP 브라우저이든, 혹은 MME이든 상관없이 브라우저는 컨텐츠, 혹은 파일을 네트웍에서 찾아 다니는 가장 보편적이고 일반적인 방법이다. 그러므로, WAP 브라우저(혹은 MME)가 탑재된 브라우저를 통해 다운로드할 JAR 파일을 찾고, JAM이 그 파일을 다운로드하여, 설치하는 것은 가장 생각하기 쉽고, 구현하기 쉬운 모델이다. 브라우저와 JAM의 연동 문제는 이 글의 마지막 부분에서 다시 생각하기로 하자.

JAR는 인터넷에서 이미 보편화된 파일 포맷이다. 그러므로, 기존의 J2SE 기반의 JAR 파일과 앞에서 설명한 MIDP 수트를 포함한 JAR 파일을 구분할 방법이 없다. 그러므로, 브라우저가 올바르지 못한 J2SE 기반의 JAR 파일을 JAM으로부터 다운로드하게 만들 수 있다. MIDP 애플리케이션만 있는 웹사이트를 별도로 접속할 수 있도록 해서, 이러한 염려를 기우로 만들 수 있다고 해도, 문제는 또 있다. 이미 다운로드하여 설치한 애플리케이션의 JAR 파일을 다시 다운로드하여 설치하려고 했을 경우, 똑똑한 JAM이라면, 사용자에게 그것이 부질없는 일이라는 것을 알려주어야 할 것이다. 그런데, JAM이 앞에서 설명한 JAR 파일 내에 있는 매니페스트 정보를 통해서 애플리케이션에 대한 정보를 알아야 한다면, 일단은 그 JAR 파일을 다운로드하고 난 후에 비로소 이미 설치했던 프로그램임을 알 수 있다. 그렇게 되면, 아까운 통신비용을 회수할 수 있는 방법은 없는 것이다.

그러므로, 네트웍을 통해 JAM에게 MIDP 애플리케이션과 JAR 파일의 정보, 즉, MIDlet 애트리뷰트를 전송할 수 있는 효율적인 방법이 필요하고, JAD(Java Application Descriptor)라는 애플리케이션 디스크립터는 훌륭한 해결책이다. MIDP 명세에는 모든 JAR 파일은 그에 상응하는 JAD 파일을 가질 것을 명시하고 있으며, JAD 파일은 다음과 같은 MIME 타입을 가지고 있다.

     사용자 삽입 이미지MIME 타입 : text/vnd.sun.j2me.app-descriptor
     사용자 삽입 이미지확장자 : jad

JAD 파일의 내용으로는 <표 7>에서 살펴본 MIDlet 애트리뷰트가 들어간다. 여기서는 sun tech tip에서 제공하는 예제에서 하나를 보기로하자. 파일은 run.jad이다.

   사용자 삽입 이미지filename: Run.Jad
MIDlet-Name: SunSamples
MIDlet-Version: 1.0
MIDlet-Vendor: Sun Microsystems, Inc.
MIDlet-Description: Sample suite from MIDP early access workspace.
MicroEdition-Profile: MIDP-1.0
MicroEdition-Configuration: CLDC-1.0
MIDlet-Jar-URL: http://localhost/midp/examples.jar
MIDlet-Jar-Size: 111K
MIDlet-1: Sokoban, /icons/Sokoban.gif, example.sokoban.Sokoban
MIDlet-2: Tickets, /icons/Auction.gif, TicketAuction
MIDlet-3: Colors, /icons/ColorChooser.gif, example.Color
MIDlet-4: Stock, /icons/Stock.gif, example.stock.StockMIDlet
MIDlet-5: Tiles, /icons/Tiles.gif, example.tiles.Tiles
MIDlet-6: ManyBalls, /icons/ManyBalls.gif, example.ManyBalls
MIDlet-7: Sampler, /icons/App.gif, Sampler
MIDlet-8: Properties, /icons/App.gif, example.PropExample
MIDlet-9: HttpTest, /icons/App.gif, example.HttpTest

위의 jad파일을 실행하면 응용프로그램을 선택할수있는 메뉴 같은 것이 나오는데 그것은 MIDlet-<n>부분에 여러 개를 두었기 때문이다.
MIDlet Attribute 중에서 다음은 반드시 들어가야 하는 필수적인 애트리뷰트들이다.
사용자 삽입 이미지MIDlet-Name
사용자 삽입 이미지MIDlet-Version
사용자 삽입 이미지MIDlet-Vendor
사용자 삽입 이미지MIDlet-Jar-URL
사용자 삽입 이미지MIDlet-Jar-Size
사용자 삽입 이미지
IONETKOREAE&D 연구소 제공
사용자 삽입 이미지

 
사용자 삽입 이미지2.4 웹서버에 midp 응용프로그램을 설치.
사용자 삽입 이미지
웹서버에다가 개발된 코드를 올려놓아 폰으로 접근할 수 있게 만들어야 한다. 이 작업의 단계는 다음과 같다.

1. 웹서버에 mime type설정하기
2. jar파일과 jad파일을 웹서버에 올리기
3. 폰으로 접근하여 다운 받고 실행 또는 Emulator에서 실행.

이상의 단계를 거치면 우리의 응용프로그램이 폰 또는 midp 예물레이터에 다운된 후 실행이 되는 것이다.
그럼 각단계마다 자세히 보기로 하자.

1)웹서버에 mime type설정하기
  웹서버에 midp 응용프로그램을 올려놓고 실행하기 위해서는 우선 웹서버에 jad의 mime type을 설정하여 주어야 합니다....
아래의 내용을 아파치의 경우는 conf\mime.types라는 파일에 첨가 시키고 웹서버를 restart하여야 한다.

     사용자 삽입 이미지text/vnd.sun.j2me.app-descriptor jad

그러면 우리의 웹서버는 jad라는 파일을 인식하게 되는 것이다

2) jar파일과 jad 파일을 웹서버에 올리기
  이미 프로그램을 wireless tool kit이나 커맨드라인방식을 이용하여 작성, text하였다고 가정하면 class화일이 있을 텐데 wireless tool kit에서는 jar와 jad파일을 자동으로 만들어 준다. 그러나 커맨드라인 방식에서는 개발자가 손수 만들어 주어야 한다.

* midp-ea1인 경우
  jar cvf (jar파일명) (jar파일에 묶을 class 파일들)
  예) jar cvf test.jar test.class
* midp-fcs인 경우 (midp-fcs인 경우는 아래의 jad파일 생성를 먼저 하여야 한다)
  jar cvfm (jar파일명) (jad파일명) (jar파일에 묶을 파일명)
  예) jar cvfm test.jar test.jad test.class

위의 명령을 실행 하시면 test.jar라는 파일이 생성될것입니다...
.jad파일은 다음과 같이 만들고 적당한 값을 변경해서 넣어 주면 된다.
그럼. 위의 설명대로 jad를 만들어 두어야 한다.

웹서버에 우리가 만든 jar,jad파일을 적당한 곳에 올린다. 여기서는 midp경로아래에 놓았다고 가정하자.

3) 폰으로 접근하여 다운 받고 실행 또는 Emulator에서 실행
  폰에서 실행한다면 VM가능 폰에서 URL입력하는 Page를 찾은 다음 해당 URL을 입력한다.      사용자 삽입 이미지http://xxx.xxx.xxx.xxx/midp/run.jad
그러나 폰이 준비되어 있지 않다면 Emulator에서도 직접서버에 접근해서 프로그램을 down받을 수 있다.

     사용자 삽입 이미지midp -transient http://localhost/midp/run.jad

실행을 하게 되면 Emulator에서 프로그램이 실행되는 것을 볼 수 있다. 실제로 자신의 midp홈 아래에 instapps라는 디렉토리가 생기고 그속에 우리의 jar파일이 다운되어 있을 것이다.
사용자 삽입 이미지
IONETKOREAE&D 연구소 제공
사용자 삽입 이미지



 
3. Midlet
사용자 삽입 이미지
웹서버에다가 개발된 코드를 올려놓아 폰으로 접근할 수 있게 만들어야 한다. 이 작업의 단계는 다음과 같다.

1. 웹서버에 mime type설정하기
2. jar파일과 jad파일을 웹서버에 올리기
3. 폰으로 접근하여 다운 받고 실행 또는 Emulator에서 실행.

이상의 단계를 거치면 우리의 응용프로그램이 폰 또는 midp 예물레이터에 다운된 후 실행이 되는 것이다.
그럼 각단계마다 자세히 보기로 하자.

사용자 삽입 이미지3.1 MIDlet 애플리케이션 라이프사이클
  J2SE에서 자바 애플리케이션의 수행은 main() 메소드로부터 시작한다. MIDP 애플리케이션은 main() 메소드를 가지고 있지 않으며, 있다고 하더라도 JAM은 그것을 무시한다. 이것은 전혀 새롭지 않은 것이다. 자바 개발자라면 이미 애플릿을 통해 그러한 메커니즘에 익숙해져 있기 때문이다.
에플릿의 경우 main()메소드에서 시작하는 것이 아니라 init()에서 시작하는 것을 알고 있을 것이다.
물론, MIDlet은 애플릿과는 전혀 다른 라이프사이클을 가지고 있으며, 애플릿과는 달리, JAM이 MIDlet의 라이프사이클을 관리한다.
[그림 6]는 MIDlet의 라이프사이클에 대한 상태 다이어그램을 보여주고 있다.

사용자 삽입 이미지
[ 그림 6 - MIDlet 라이프사이클 ]

그림에서 보다시피, MIDlet은 다음과 같은 세 가지의 상태를 가지고 있다.

사용자 삽입 이미지Paused : MIDlet이 초기화되고, 정지된 상태. 공유 리소스를 점유하지 않는다.
사용자 삽입 이미지Active : MIDlet이 실행되는 상태.
사용자 삽입 이미지Destroyed : MIDlet이 종료한 상태. 공유 리소스를 해제한다.

JAM은 새로운 MIDlet의 인스턴스를 생성할 때, 이 객체의 디폴트 생성자(인자 없는 생성자)를 호출한다. 그리고, 생성자의 수행 이후에는 MIDlet이 Paused 상태로 있게 된다. 그리고, 그 이후의 상태들간의 전이를 위한 메소드들은 MIDlet 클래스의 추상 메소드들로 정의되어 있고, MIDlet 클래스를 상속한 클래스들은 반드시 이 메소드들을 구현하여야 한다. 각각의 메소드들에서 해야할 작업은 다음과 같다.

사용자 삽입 이미지startApp() : 필요한 리소스에 대한 점유 획득. Active 상태로 전이
사용자 삽입 이미지pauseApp() : 임시적인 리소스들에 대한 점유 해제. Pause 상태로 전이
사용자 삽입 이미지destroyApp() : MIDlet이 종료한 상태. 공유 리소스를 해제한다. Destoryed 상태로 전이

사용자 삽입 이미지
IONETKOREAE&D 연구소 제공
사용자 삽입 이미지



 
4. 주요 개발 스펙
사용자 삽입 이미지
사용자 삽입 이미지4.1 네트워킹
  네트워킹에 대해서는 CLDC의 커넥션 프레임웍에서 일부가 설명되었다. MIDP에서는 CLDC의 커넥션 프레임웍에 대해 확장된 네트워킹에 대한 정의와 구현을 제공한다. MIDP 1.0 명세서는 HTTP 1.1 프로토콜의 서브셋을 지원하고 있고, 이것은 TCP/IP 네트웍의 IP 프로토콜에 대한 구현과, WAP 및 iMode의 게이트웨이를 통한 비IP(non-IP) 프로토콜에 대한 구현을 포함하고 있다.

[그림 6]을 보자. 한 쪽은 WAP/iMode 게이트웨이를 통해서, 다른 한 쪽은 TCP/IP로 직접 ‘오리진 서버(웹 서버)’에 접속하고 있다. 클라이언트 프로그램이나 웹 서버는 이러한 연결 방법의 차이에 대해서 알아야 할 필요가 없다. 클라이언트 프로그램은 URL을 통해 네트웍 연결을 요청할 뿐이고, 웹 서버는 HTTP 요청에 대한 응답을 전송하는 고전적인 임무를 수행하면 된다. 무선망의 연결방법에 의한 차이는 MIDP의 구현자에 의해 해결해야 할 문제일 뿐, MIDP 애플리케이션 개발자는 네트웍 연결방법에 대해서는 고려하지 않아도 된다는 뜻이다.

사용자 삽입 이미지
[ 그림 7 - HTTP 네트웍 연결 ]

이제, HTTP의 실질적인 구현에 대해서 알아보자. MIDP는 다음과 같은 인터페이스를 통해 HTTP 연결을 지원한다.
      사용자 삽입 이미지javax.microedition.io.HttpConnection

이 인터페이스는 <그림 3>에서 본 커넥션 프레임웍의 계층도에서 제일 아래에 있는 ContentConnection을 상속한 인터페이스이다. 이 인터페이스에는 HTTP 프로토콜을 이용하기 위한 모든 상수와 메소드들이 정의되어 있다. 다음은 HttpConnection 인터페이스를 이용해서 HTTP POST 요청을 수행하는 예제이다.
사용자 삽입 이미지

이 예제는 인자로 주어진 URL의 HTTP 연결을 생성하고, HTTP POST를 통해 ‘사랑은 움직이는 거야’라는 메시지를 전달하고, 그 응답을 받는 과정을 구현하고 있다. 이 예제에서 굵은 글씨로 강조된 부분은 HTTP 헤더의 User-Agent와 Content-Language를 지정하고 있는데, 이는 MIDP에서 User-Agent 요청 헤더에 다음과 같은 시스템 프로퍼티의 정보를 포함할 것을 명시하고 있기 때문이다.

사용자 삽입 이미지microedition.profiles
사용자 삽입 이미지microedition.configuration
사용자 삽입 이미지microedition.locale

사용자 삽입 이미지4.2 영속 저장공간
  다음은, MIDP 애플리케이션이 데이터를 영속적으로 저장하고 사용할 수 있는 메커니즘을 제공해 주는 RMS(Record Management System)에 대해서 알아보자.

왜 RMS가 필요할까? 앞에서 CLDC/MIDP 디바이스들에는 파일시스템이 없음을 강조한 바 있다. 그렇다면, 애플리케이션이 실행중에 생성한 데이터는 어떻게 저장할까? 예를 들어, 50개의 스테이지를 가진 게임이 있는 데, 사용자가 49 스테이지를 돌파하고, 잠시 전화를 거느라 애플리케이션을 중단시켰다. 이 경우에 처음부터 새로 게임을 시작해야 한다면, 사용자는 차라리 그 애플리케이션을 JAM을 통해 삭제해 버리게 될 것이다. 그렇게 되지 않기 위해서는 조금 전에 보았듯이, HttpConnection을 통해 리모트 서버에 저장해 두는 방법을 생각할 수 있다. 하지만, 사용자의 현재 위치나, 1인용 테트리스 게임 애플리케이션의 최고기록과 같은 작은 데이터들을 항상 서버에서 가져와야 한다면, 상당히 불합리하다. 그러므로, 게임스코어 같은 데이터를 영속적으로 저장하고, 언제라도 이 데이터를 활용할 수 있는 저장공간이 필요하고, RMS는 이러한 기능을 제공해 주는 레코드 기반의 초소형 데이터베이스이다.
레코드는 바이트 배열로 구성되며, 레코드스코어는 여러 개의 레코드들로 구성된다. RMS는 이러한 영속적 저장공간 기능을 javax.microedition.rms 패키지를 통해 제공하고 있으며, <표 8>은 RMS 패키지가 제공하는 1개의 클래스와 4개의 인터페이스에 대한 설명이다.

클래스 및 인터페이스
설 명
RecordStore 바이트 배열로 이루어진 레코드들을 여러 개 가지고 있는 레코드스토어에 대한 구현 클래스
RecordComparator 두 개의 레코드를 비교하기 위한 Comparator 인터페이스
RecordEnumeration 레코드를 탐색하기 위한 Enumeration 인터페이스
RecordFilter 어떤 레코드가 조건을 만족하는 지 검사하기 위한 필터 인터페이스
RecordListener 레코드에 대한 추가/변경/삭제 이벤트를 감지하기 위한 리스너 인터페이스
[ 표7 - RMS 패키지 ]

사용자 삽입 이미지4.3 타이머 지원
  MIDP에는 javax로 시작하는 확장 API에 대한 정의가 대부분이지만, java.util 패키지에 포함되는 다음 두 가지의 클래스는 예외이다.

      사용자 삽입 이미지java.util.Timer
      사용자 삽입 이미지java.util.TimerTask

Timer 클래스는 애플리케이션에서 특정 작업을 백그라운드 쓰레드에서 스케쥴링할 수 있는 기능을 제공하고, TimerTask는 Timer를 통해서 스케쥴링할 수 있는 특정 작업에 대한 구현 클래스이다. 이 클래스들을 이용해서 특정한 작업을 일정한 시간을 지정해서 한 번만 실행하거나, 일정한 간격으로 여러 번 반복적으로 실행하도록 스케쥴링을 할 수 있다.

사용자 삽입 이미지4.4 유저 인터페이스
  자바는 아키텍처 중립적이다. 이 문장의 의미는 자바의 전통적인 그래픽 유저 인터페이스인 AWT(Abstract Window Toolkit)가 아키텍처에 대해서 중립적(neutral)이라는 것이다. AWT는 MS의 윈도우 시스템과 유닉스 계열의 X-윈도우 시스템에서 ‘비슷하게’ 나타나지만, ‘동일하게’ 보이지는 않는다. 그래서 ‘Abstract’인 것이다. 예를 들어, Button 컴포넌트를 생성하면, 서로 다른 GUI 시스템에서 그 버튼의 모양과 크기는 조금씩 다르다. 이것은 피어(peer)를 통한 컴포넌트의 생성으로 인해서 발생하는 문제이고, 스윙을 통해서 이러한 아키텍처에의 종속성은 해결되었지만, 아직도 GUI는 자바의 아킬레스 건이다.

CLDC/MIDP 플랫폼에서도 마찬가지다. 기존의 AWT를 사용하기에는 너무 무겁고, 서로 다른 다양한 입출력 메커니즘을 가지고 있는 디바이스들에 공통된 유저 인터페이스를 새로 설계하는 일도 녹녹하지 않은 작업이었다. kAWT 프로젝트와 같은 PalmOS 환경에서, AWT를 기반으로 한 유저 인터페이스를 설계하려는 시도가 있기는 하지만, MIDP에서는 결과적으로 전혀 새로운 유저 인터페이스가 설계되었다. lcdui라는 이 새로운 유저 인터페이스야말로 모바일 솔루션을 개발하기 위해 자바 개발자가 만나야 하는 가장 높은 벽이다. 필자 역시 아직 이 벽을 넘어 보지 못했으며, 상세하게 다루기에는 너무 방대한 내용이 될 것이므로, 실제 구현에 필요한 각각의 컴포넌트와 API들에 대해서는 다음 기회를 기약하기로 하고, 여기서는 lcdui의 설계와 그 뼈대를 이루는 구조에 대해서만 살펴보도록 하자.

MIDP는 다음과 같은 디자인 원칙에 입각하여 UI를 디자인하였다.
1. 한 손으로 입력가능해야 한다.
2. 작은 스크린 사이즈에 적용가능해야 한다.
3. 포인팅 디바이스가 없는 단말기에 적용가능해야 한다.
4. 기존의 입출력 방법과 통합되어야 한다.

그리고, MIDP UI는 이러한 기준에 입각해서 다음과 같은 두 가지 레벨의 API를 정의하고 있다.
사용자 삽입 이미지상위 레벨 API : 비즈니스 애플리케이션과 같은,
높은 수준의 포터빌리티를 요구하는 애플리케이션의 제작에 사용될 API.
사용자 삽입 이미지하위 레벨 API : 게임 애플리케이션과 같은,
특정한 목적에 맞게 사용이 가능한 애플리케이션의 제작에 사용될 API.

이러한 MIDP의 유저 인터페이스 API는 javax.microedition.lcdui 패키지를 통해 제공되고 있다. <그림 7>은 핵심적인 유저 인터페이스 API의 클래스 계층도이다.

사용자 삽입 이미지
[ 그림 8 - 유저 인터페이스 클래스 계층도 ]

MIDP는 스크린 기반의 디자인을 가지고 있는데, 스크린은 사용자 입력을 렌더링하는 특정 디바이스 그래픽스를 캡슐화하는 객체라고 정의하고 있다. 이 난해한 정의를 풀어쓰면, 스크린이라는 것은 사용자에게 나타나는 화면이며, 사용자는 한 번에 하나의 스크린 만을 볼 수 있고, 사용자 입력에 대한 처리는 이 스크린에 의해서 이루어 진다고 할 수 있을 것이다.
[그림 7]에서는 두 종류의 스크린이 있음을 알 수 있는데, Screen 클래스와 Canvas 클래스가 그것이다. Canvas 클래스는 게임과 같은 하위 레벨 API를 사용하는 애플리케이션을 위한 스크린을 제공하고, Screen 클래스는 텍스트 박스, 리스트, 등의 상위 레벨 API를 위한 최상위 추상화를 제공한다. Screen 클래스를 상속하는 List, TextBox, Alert와 같은 클래스들은 사전에 정의된 구조를 사용할 수 있는 컴포넌트들이고, 이렇게 사전에 정의된 구조를 사용할 수 없는 TextField, ImageItem, Gauge 등의 클래스들은 Screen 클래스를 상속하는 Form 클래스를 상속하도록 설계되어 있다.

사용자 삽입 이미지4.5 Event처리
  이벤트 처리에서도 상위 레벨 API와 하위 레벨 API에 대한 구분이 있다. 이벤트 처리에서는 <그림 7>의 제일 윗쪽에 놓여진 Command 클래스로 구현된 추상 커맨드에 대한 이해가 필요하다. 대부분의 신형 단말기에는 <화면 2>의 타원 안에 있는 것과 같은 소프트 키가 있다. 그리고 이 소프트 키를 이용해서 스크린의 아래 부분에 있는 ‘About’이라는 커맨드를 선택하여 실행시키거나, 위 아래로의 화면 스크롤을 수행할 수 있다. 이렇게 추상 커맨드와 소프트 키를 통한 이벤트 처리는 상위 레벨 API을 통해 구현이 이루어진다.

void commandAction(Command c, Screen s);

사용자 삽입 이미지
[ 그림 9 - 소프트 키와 커맨드 ]

그러나, 게임 애플리케이션의 경우, 비행기가 8가지 방향으로 날아다니기 위해서는 그림에서와 같이 동서남북의 네 개 뿐인 소프트키를 이용할 수 없다. 그러므로, 이런 경우에는 숫자 키 패드 입력 같은 하위 레벨 API를 이용해서 애플리케이션을 작성할 수 있다.

      사용자 삽입 이미지public void keyPressed(int keyCode);

때로는 상위 레벨 API와 하위 레벨 API를 동시에 매핑하여 지원해야 할 경우도 있을 텐데, 예를 들어, 비행기가 8방향으로 날면서 레이저를 발사해야 하는데, 0번 키가 레이저를 발사하는 키로 매핑 되었다면, 어떤 사용자의 경우는 소프트 키를 이용해서 방향 이동을 하기를 원할 수도 있다. 이럴 경우에는 0번 키의 입력에 의한 하위 레벨 이벤트 처리와 소프트 키 입력에 의한 상위 레벨 이벤트 처리를 동일하게 레이저를 발사하도록 작성할 수도 있다는 것이다.

사용자 삽입 이미지4.6. MIDlet 프로그래밍
  자, 그럼, 이제 실제로 간단한 MIDlet을 개발하고, 배포하고, 테스트 해 보자. 다음은 MIDlet을 개발하는 데 거쳐야 하는 일반적인 순서이다.

1. 프로그램 작성
2. 컴파일
3. 사전검증
4. JAR 파일 생성
5. JAD 파일 작성 및 테스트
6. 웹 사이트 배포

제일 먼저 해야 할 일은 코딩을 하는 것이다. <리스트 2>는 간단한 MIDlet 프로그램인 HelloMIDlet이다. 이 예제는 TextBox 스크린을 하나 생성하고, 여기에 ‘종료’라는 추상 커맨드를 추가한 이후에 사용자가 종료 커맨드를 선택하면, 해당하는 이벤트에 대한 액션으로 프로그램의 수행을 종료하는 기본적인 기능만을 수행한다.

<리스트2> HelloMIDlet.java

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

 

/**

* MIDlet예제: HelloMIDlet

*/

public class HelloMIDlet extends MIDlet implements CommandListener {

  private Command exitCommand;

  private Display display;

  public HelloMIDlet() {

     display = Display.getDisplay(this);

     exitCommand = new Command("종료", Command.SCREEN, 2);

  }

  /**

   * startApp() : JAMMIDlet실행할호출한다.

   */

public void startApp() {

     TextBox t = new TextBox("안녕? MIDlet", "테스트", 256, 0);

     t.addCommand(exitCommand);

     t.setListener(this);

     display.setCurrent(t);

  }

   /**

   * pauseApp() : MIDlet일시정지할호출한다.

   */

  public void pauseApp() {

  }

   /**

   * destroyApp() : MIDlet정시시킬호출한다.

   */

  public void destroyApp(boolean unconditional) {

  }

   /**

   *커맨드이벤트에대한액션의처리,여기서는종료커맨드를

   *선택했을destroyApp()메소드를명시적으로호출한다.

   */

  public void commandAction(Command c, Displayable s) {

     if (c == exitCommand) {

        destroyApp(false);

        notifyDestroyed();

     }

  }

 }

 

 


작성된 소스 코드는 다음과 같은 명령으로 컴파일한다. -g:none 옵션은 디버깅 정보를 삭제해 주고, -bootclasspath 옵션은 시스템 클래스 파일을 midp.jar 파일에서 찾도록 지정해 준다. ?d 옵션은 클래스 파일이 classes 디렉토리 아래에 생기도록 지정한다. 디버깅 정보를 삭제하는 이유는 CLDC 클래스 파일 포맷에서 이 부분이 삭제될 것을 명시했기 때문이다.

D:\midp-ea1>javac -g:none -bootclasspath lib\midp.jar -d classes

다음은 classes 디렉토리에 생성된 HelloMIDlet.class 파일을 사전검증하는 것이다. 이 때, 주의할 점은 lib\midp.jar 파일의 압축을 해제해 두어야 한다는 것인데, 이것은 preverify.exe가 JAR 파일 포맷을 인식하지 못하는 것으로 생각되기 때문이다.

D:\midp-ea1\lib>jar xvf examples.jar
D:\midp-ea1>bin\preverify -classpath classes;lib -d preverfied classes

preverified 디렉토리에 사전검증된 클래스 파일이 생성되었으면, 이제 JAR 파일을 생성하도록 하자.

D:\midp-ea1\preverified>jar cvf ..\hello.jar .

이제, JAD 파일을 생성할 차례다. 다음은 hello.jad 파일에 포함될 MIDlet 애트리뷰트들이다.

MIDlet-Name: PromyWorks
MIDlet-Version: 1.0.0
MIDlet-Vendor: promy
MIDlet-Description: Working MIDP Examples
MicroEdition-Profile: MIDP-1.0
MicroEdition-Configuration: CLDC-1.0
MIDlet-Jar-URL: http://localhost/midp/hello.jar
MIDlet-1: HelloMIDlet, /icons/promy.gif, HelloMIDlet

모든 것이 준비되었다면, 다음 명령어를 통해 에뮬레이터를 실행해 보자. < 그림 10 >은 HelloMIDlet의 실행화면이다.

D:\midp-ea1>bin\midp -classpath hello.jar -descriptor hello.jad

사용자 삽입 이미지
[ 그림 10 - HelloMIDlet 실행화면 ]

Posted by 1010
01.JAVA/J2me2008. 11. 27. 13:08
반응형
download.asp?FileID=19154050
download.asp?FileID=19154049
download.asp?FileID=19154048
download.asp?FileID=19154047
download.asp?FileID=19154046
download.asp?FileID=19154045
download.asp?FileID=19154044
download.asp?FileID=19154043
download.asp?FileID=19154042
 
 
1. window - preferences 에서 다음과 같이 세팅해준다.
 
src는 소스를 담고 bin에는 클래스파일 및 jar파일을 담게된다.
 


 

 
 
2. file - new - project해서 새로 프로젝트를 만든다.
 
 
 
 
3. 프로젝트이름을 써넣고 next를 누른다.
 


 

 
 
4. libraries 탭을 선택한다.
 


 

 
 
5. 기존의 라이브러리를 선택하고 [1]번을 눌러 지운다음
[2]번을 눌러서 AromaWIPI\JavaAppDemo\lib\classes.zip을 추가시킨다.
finish버튼을 누른다.
 
 

 

 

6. file - new - class해서 새로운 클래스파일을 만든다.

원하는 클래스명을 적고 browse를 누른다.

 

 

 

 


 

 

 

7. choose a type에 'jlet'을 검색하여 선택한다.

finish버튼을 누른다.

 


 

 

 

8. 위피에 맞게 기본 자바파일이 만들어졌다.

 

 

 
 
9. 이제 실행세팅을 하면된다.
 
run - external tools -
 
하단의 new를 클리해서 세 개의 프로그램을 생성한다.
 
 
[1] wipi_compile - 컴파일해주는 프로그램이다.
 
lotation : C:\Program Files\Java\jdk1.5.0_06\bin\javac.exe
 
( browse file system을 눌러서 javac.exe를 찾아 선택해주면된다.)
 
working directory :  ${workspace_loc:/${project_name}/src}
 
arguments : -bootclasspath C:\Progra~1\AromaWIPI\JavaAppDemo\lib\classes.zip
 
(아로마위피의 classes.zip의 위치를 써주면된다.) ${resource_name}
 
 
[2] make_jar - jar파일을 생성해주는 프로그램이다.
 
lotation : C:\Program Files\Java\jdk1.5.0_06\bin\jar.exe
 
( browse file system을 눌러서 jar.exe를 찾아 선택해주면된다.)
 
working directory :  ${workspace_loc:/${project_name}/bin}
 
arguments : -cvf ${java_type_name}.jar *.*
 
 
[3] emulator - 위피를 실행하는 프로그램이다.
 
lotation : C:\Program Files\AromaWIPI\Emulator\WIPIEmul.exe
 
( browse file system을 눌러서 WIPIEmul.exe를 찾아 선택해주면된다.)
 
working directory :  C:\Program Files\AromaWIPI\Emulator
 
arguments : -HEAPSIZE=1024 -classpath ${workspace_loc:/${project_name}/bin}
 
\${java_type_name}.jar org.kwis.msp.lcdui.Main ${java_type_name}
 
 


 

 
 
 
 
 
 
 
 
-----------------------------------------------------------------------
 
 
 
 
이클립스하다가 위피때문에 editplus쓰려니까
 
답답해서 이클립스에서 위피하는 방법을 찾아 똑같이 설정했는데
 
실행되지 않고. 실행이 된다하면
 
실행할때마다 새로 입력해줘야하고.
 
그래서 이클립스를 뚫어져라 쳐다보면서 나에게 쉬운 방법을 찾았다!!
 
이제 속편히 게임짜러가야지. 훗훗
Posted by 1010
01.JAVA/J2me2008. 11. 27. 13:05
반응형
여러분은 자바 가상 머신을 메모리 용량이 적고 자원이 제한되어 있으며 네트워크로 연결된 환경에 적합하게 만들고 싶을 것이다. K 가상 머신 (KVM)의 중심에 특수한 자바 클래스가 있는데, MIDlet이 그것이다. 이 글에서 Soma Ghosh는 여러분에게 MIDlet 클래스의 장단점을 소개하고 여러분 자신의 J2ME 애플리케이션을 구축할 때 이를 활용하는 방법을 소개하겠다. 여러분은 MIDlet의 이론을 배우고 난 후 그녀가 구축하는 샘플 프로그램을 통해 그 기술이 실행되는 것을 확인하게 될 것이다.

이 주제에 대해 내가 작성한이전 글에서 나는 Java 2 Platform, Micro Edition (J2ME)의 기초 사항들에 대해 논의하였다. 그 글을 읽어보지 않은 분이라면 이 글을 읽기 전에 아마도 그것을 먼저 읽어 보아야 할 것이다. J2ME의 가장 중요한 구성 요소가 MIDlet이다. 여기서 우리는 MIDlet의 상태와 상태 애플리케이션 뿐 아니라 이벤트와 예외를 처리하기 위한 기법들을 검토하면서 MIDIet을 상세히 살펴보도록 하겠다. 또한 여기에서 설명된 개념들을 입증해 줄 간단한 애플리케이션을 구축해 봄으로써 결론을 짓도록 하겠다. 이 글을 끝낼 때쯤이면 여러분은 여러분 자신의 J2ME 애플리케이션을 작성하는 중일 것이다.

MIDlet이란 무엇인가?


Mobile Information Device Profile (MIDP)은 이동 전화나 기본적인 수준의 팜탑 장비와 같은 모바일 정보 장비를 타겟으로 하는 자바 API 세트이다. MIDlet은 MIDP 애플리케이션을 말한다. 이 글에서는MIDletMID 애플리케이션라는 용어가 교대로 사용된다. MIDlet은 J2ME 실행 환경의 구성 요소가 된다.

MIDlet은 모바일 장비에서 작동하도록 설계되었으며 자바 가상 머신의 핵심만 모은 버전인 K Virtual Machine (KVM)의 애플리케이션 관리자에 의해 실행되고 제어되도록 만들어졌다.javax.microedition.midlet.MIDlet클래스는 MIDlet과 애플리케이션 관리자 사이의 인터페이스로 작동한다. 이 클래스의 메소드는 애플리케이션 관리자가 MIDlet을 만들고 구동시키고 중지시키고 없애도록 해준다.

J2ME 애플리케이션은javax.microedition.midlet.MIDlet클래스를 확장해야 하는데, 이는 다음 작업들에 대한 프레임워크를 제공한다.:

  • 애플리케이션 관리자가 MIDlet 상태 변화를 통지하고 요청함으로써 MIDlet을 제어하도록 한다.

  • MIDlet이 애플리케이션 관리자가 관리하는 애플리케이션 레지스터리인애플리케이션 디스크립터 (application descriptor)로부터 특성을 검색할 수 있도록 한다.

그림 1은 MIDlet과 애플리케이션 관리자 간의 상호작용을 보여준다.


그림 1. MIDlet 환경
사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


MIDlet의 상태

MIDlet은 그 수명 주기 동안 다양한상태로 있을 수 있다. 이 상태들은 애플리케이션 관리자가 런타임 환경 내에서 여러 MIDlet들의 행동을 관리하도록 해 준다. 애플리케이션 관리자는 MIDlet들을 개별적으로 시작시키고 중지시킴으로써 주어진 시점에 어떤 MIDlet이 작동할지 선택할 수 있다. 애플리케이션 관리자는 또한 MIDlet의 상태를 유지보수한다. MIDlet은 다음 상태들 중 하나로 있을 수 있다.:

  • 작동 :MIDlet은 구동시에 작동 상태로 들어가고 일부 자원을 차지할 수 있다.
  • 중지 :중지 상태에서 MIDlet은 공유된 자원을 해제하고 정지한다.
  • 파기 :이것은 MIDlet의 종료 단계이다. 종료된 MIDlet은 모든 자원을 해제하고 애플리케이션 관리자에 어떤 영속적인 상태를 저장해야 한다.

그림 2는 MIDLet의 상태 변화를 보여주고 있다. 화살표는 허가된 상태 변화를 나타낸다. 예를 들어, 작동 상태의 MIDlet은 중지 상태나 파기 상태 중 하나로 이동할 수 있다.


그림 2. MIDlet의 상태 변화
사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


상태 구현 : 한 상태에서 다른 상태로 이동하기

애플리케이션 관리자는 상태를 바꾸기 위해 MIDlet에 특정 메소드를 호출한다. MIDlet은 이 메소드를 구현하여 자신의 내부 행동과 자원 활용을 애플리케이션 관리자가 지시하는대로 업데이트시킨다.:

  • startApp(): 이 메소드는 MIDlet에게 작동 상태로 들어간다는 신호를 보내며, MIDlet의 대화형 화면 환경을 설정하기 위한 초기화 절차들로 구성되어 있다.

  • pauseApp(): 이 메소드는 MIDlet에게 작동을 멈추고 중지 상태로 가라고 신호한다.

  • destroyApp(): 이 메소드는 MIDlet에게 작동을 종료하고 파기 상태로 가라고 지시한다.

MIDlet은 스스로 몇 가지 상태를 개시하고, 이 메소드들 중 하나를 호출하여 애플리케이션 관리자에게 이러한 상태 변화들을 통지할 수 있다.:

  • notifyDestroyed(): 자신이 파기 상태로 들어갔음을 애플리케이션 관리자에게 통지하기 위해 MIDlet이 사용하는 메소드이다.

  • notifyPaused(): 이 메소드는 MIDlet이 작동 상태로 있고 싶지 않으며 중지 상태로 가고 싶다고 애플리케이션 관리자에게 통지한다.

  • resumeRequest(): 이 메소드는 MIDlet이 작동 상태로 가고 싶어함을 표시하는 메커니즘을 제공한다. 이 메소드에 대한 호출은 애플리케이션 관리자가 사용하는데, 어떤 애플리케이션이 작동 상태로 갈지를 결정한다. 애플리케이션 관리자가 한 MIDlet을 활성화하기로 결정하면 그 MIDlet의startApp()메소드를 호출할 것이다.

MIDlet은 애플리케이션 관리자로부터 지정된 특성들을 검색하는 메커니즘을 받았다.getAppProperty()메소드가 그것이다. MIDlet 배치의 일부분으로 제공되는 이 특성들은 애플리케이션 디스크립터 파일과 manifest가 조합된 것으로부터 얻어진다.

startApp()혹은pauseApp()동안 런타임 예외가 발생하면 MIDlet은 즉시 파기될 것이다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


MIDlet의 이벤트 처리

사용자가 MIDlet과 상호작용할 때,이벤트가 생성된다. MIDlet은 자신의 이벤트 처리 메커니즘의 일부분으로 특정 인터페이스들을 제공하여 애플리케이션이 이벤트를 통지받고 이에 대해 응답할 수 있도록 한다. 각 인터페이스는콜백 (callback) 이라고 알려진 메소드를 제공하는데, 이것은 이벤트에 응답하여 애플리케이션이 실행시키는 프로그래머 정의 메소드를 호출하는 것이다.

MIDlet이 실행되고 있는 동안 생성되는 이벤트들은 다음과 같다. :

  • 화면에서 입력되는 명령문
  • 화면 아이템의 내부 상태의 변화
  • MIDlet과 관련된 폰 데이터베이스의 내부 상태의 변화

MIDlet 이벤트 처리 메커니즘은listener모델에 기반하고 있다. 각 객체는 이벤트를 통지받고 여기에 응답할 수 있도록 Listener를 구현해야 한다. 이를 위해 MIDlet은ItemStateListener,CommandListener,RecordListener라는 세 인터페이스를 제공한다. 각각을 상세하게 살펴 보자.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


CommandListener

CommandListener는 화면 출력될 수 있는 아이템 (예 : 화면에 입력되는 명령어)들에서 생성되는 이벤트를 MID 애플리케이션에게 통지하는 책임을 가진다.CommandListener는 listener를 확장하는 객체가 구현해야 하는commandAction(Command c, Displayable d)메커니즘을 제공한다. 이 메소드는 명령어 이벤트가Displayable d에 발생했음을 가리킨다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


ItemStateListener

ItemStateListener는 화면 아이템 (예 : 화면에 있는TextField의 값)의 내부 상태 변화를 MID 애플리케이션에게 통지하며, 아이템의 내부 상태가 사용자에 의해 변경되었을 때 호출되는itemStateChanged(Item I)메소드를 제공한다. 내부 상태의 변화는 사용자에 의해 발생한다.:

  • ChoiceGroup에서 선택된 값들 변경하기

  • 대화형Gauge의 값 조정하기

  • TextField에 값을 입력하거나 수정하기

  • DateField에 날짜나 시간 입력하기

여러분은 내가 작성한이전 글에서 이들 화면 아이템에 관해 더 배울 수 있다.

아이템에 언제 새 값을 입력해야 하는지의 결정은 장비에 달려 있다. 예를 들어,TextField내에 텍스트 편집을 구현하는 것은 장비에 따라 아주 다양하다.

ItemStateListener는 애플리케이션이 대화형 아이템의 값을 변경한 경우에는 호출되지 않는다. 사용자가 변경했을 때만 호출된다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


RecordListener

RecordListener의 책임은 애플리케이션과 연관되어 있는 레코드 스토어에서 레코드 변경과 관련된 이벤트를 받는 것이다. 이것을 사용하려면 애플리케이션은RecordListener가 제공하는 다음 메소드들을 구현해야 한다. :

  • recordAdded(): 레코드가 레코드 스토어에 추가되었을 때 호출된다.

  • recordDeleted(): 레코드 스토어의 레코드가 변경된 후에 호출된다.

  • recordChanged(): 레코드 스토어에서 레코드가 삭제된 후 호출된다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


Listener와 객체 연결시키기

MIDlet이 실행될 때 객체들이 이벤트에 응답할 수 있도록 Listeners가 이들 객체들에 연결되어야 한다. MIDlet 클래스는 이벤트 listener를 객체와 연결시키기 위한 특정 메소드들을 제공한다.:

  • setCommandListener(): 이 메소드는 모든 명령어에 대한 listener를Displayable에 설정하며, 이전의CommandListener를 바꾼다

  • setItemStateListener(): 이 메소드는 화면 아이템에 대한 아이템 상태 listener를 설정하며, 이전의itemStateListener를 바꾼다.

  • addRecordStateListener(): 이 메소드는 레코드 스토어에 레코드 상태 listener를 추가한다.

그림 3은 MIDlet 이벤트 처리 모델이다.


그림 3. MIDlet 이벤트 처리
사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


MIDlet의 예외

MIDlet은예외 처리 기능을 사용해 예외적인 상황을 처리할 수 있다.예외란 프로그램이 실행되는 동안 정상적인 명령의 흐름을 혼란시키는 이벤트를 말한다. MIDlet은 자바 예외 처리 메커니즘의 모델을 보존하고 있다. 그러한 에러가 메소드에 발생했을 때, 메소드는 예외 객체를 만들어 이를 런타임 시스템에 넘겨 준다. 예외 객체는 예외의 유형 및 예외가 발생했을 때 프로그램의 상태 등 예외에 관한 정보를 가지고 있다. 그러면 런타임 시스템은 에러를 처리하기 위해 몇 가지 코드를 발견해야 한다. 자바 전문 용어에서, 예외 객체를 만들어 이를 런타임 시스템에 넘겨 주는 것은예외를 던진다(throwing an exception)라고 불린다.

앞에서 살펴 보았듯이, MIDlet은 수명 주기 동안 다양한 상태로 있을 수 있다. MIDlet은 요청된 MIDlet 상태 변화가 실패했음을 함축적인MIDletStateChangeException을 던짐으로써 알려준다.

자바 예외 처리에 관한 상세 정보는 아래의참고 자료부분을 참조한다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


예제 : 전화기 이미지 애플리케이션

이번 섹션에서 우리는 다양한 단계에서의 MIDlet의 역할을 보여주는 J2ME 이미지 애플리케이션을 개발할 것이다. 이 애플리케이션은 또한 이벤트 처리 메커니즘을 통해 종료하는 기능도 가질 것이다.

PhoneImage애플리케이션은 자신의 MIDIet 메소드에 대한 호출에 대응하여 하나의 생성자를 불러온다. 이 생성자는 전화기 화면 환경, 전화기 화면 아이템, 애플리케이션을 종료시키기 위한 화면 명령어를 생성하여 초기화 절차를 수행한다.

전화기 화면 환경은Display클래스에 의해 표시된다. MIDlet당 정확히 하나의Display인스턴스가 있고,PhoneImage생성자는getDisplay()메소드를 호출함으로써 그 인스턴스에 대한 참조를 얻는다.:

display = Display.getDisplay(this);

이 애플리케이션의 UI 측면은 그래픽 이미지 데이터를 보유하기 위해 사용되는javax.microedition.lcdui.Image클래스이다.Image객체들은 화면 장치와 독립적으로 존재한다. 그들은 화면과 무관한 메모리에만 존재하며, 애플리케이션이 명시적인 명령어(Canvaspaint()메소드에서처럼)를 발행하지 않는 한 혹은Image객체가Form화면이나Alert화면 내에 위치하고 그 화면이 갱신되기 전까지는 화면에 표시되지 않을 것이다.

이미지는 그들이 만들어진 방식에 따라가변일 수도 있고불변일 수도 있다. 불변 이미지는 일반적으로 자원 번들, 파일 혹은 네트워크에서 이미지 데이터를 로딩함으로써 만들어진다. 이들은 한 번 만들어지면 수정할 수 없다. 가변 이미지는 화면과 무관한 메모리에서 만들어진다. 애플리케이션은 이를 위해Graphics객체를 명확하게 생성한 후 이들을 표시할 수 있다.Alert,Choice,Form혹은ImageItem객체에 있는 이미지는 불변이어야 한다. 런타임 환경이 애플리케이션에게 통지하지 않고 언제든지 화면을 업데이트하기 위해 이들을 사용할 수 있기 때문이다.

PhoneImage애플리케이션은javax.microedition.lcdui.Image클래스의createImage(String resourceName)메소드를 호출함으로써 불변 이미지 아이템을 생성한다. 이 메소드는 지정된 자원에서 얻어지는 해독된 이미지 데이터들로부터 불변 이미지를 생성하는데, 이 데이터들은 장비 구현에 따라 자원 번들 내에 혹은 파일 시스템상에, 혹은 네트워크상에 존재할 수 있다.resourceName은 지원되는 이미지 포맷 중 하나로 된 이미지 데이터를 포함하고 있는 자원의 이름을 표시하고 있다. 구현은 PNG (Portable Network Graphics) 포맷 v.1.0에 저장되어 있는 이미지들을 지원해야 한다.

자원 명이 null일 경우 메소드는NullPointerException을 던진다. 자원이 존재하지 않거나 데이터를 로딩할 수 없거나 이미지 데이터를 해독할 수 없는 경우에는IOException을 던진다. Listing1은 이 모든 것이 어떻게 작동하는지 보여준다.


Listing 1.이미지 생성하기
try     {              image = Image.createImage("/img/JavaPowered-8.png");                         }     catch (java.lang.NullPointerException exc)     {          exc.printStackTrace();     }     catch (java.io.IOException ioExc)     {          ioExc.printStackTrace();     }startApp

PhoneImage애플리케이션은startApp()메소드를 호출함으로써 작동 상태로 들어간다.Image아이템은Form객체 (Listing 2 참조)에 내장되어 있다. 구현은 화면 배치, 순환 및 스크롤링을 처리한다.Form역시 화면 명령어와 연결되어 있다.


Listing 2.전화기 화면에 이미지 추가하기
displayForm = new Form("Image");displayForm. append(                new ImageItem("Default Layout",                image,                ImageItem.LAYOUT_DEFAULT,                "Image Cannot be shown"));displayForm.addCommand(exitCommand);

startApp()메소드는 Listing 3과 같이 각 명령어를 listener에 연결하고Form을 현재 표시 가능한 아이템으로 정의함으로써 이벤트 처리 메커니즘을 설정한다.


Listing 3. 화면에 사용자 상호작용 특성 추가하기
displayForm.setCommandListener(this);displayForm.setItemStateListener(this);

애플리케이션 관리자가pauseApp()메소드를 호출하면PhoneImage애플리케이션이 정지 상태로 들어간다. 이는 백그라운드 작업이 없거나 레코드 스토어가 종료되었을 때 사용하는 무연산 메소드이다.destroyApp()메소드는PhoneImage애플리케이션의 종료 단계를 시작시킨다. 이 메소드는 모든 자원을 해제하는 책임을 가지고 있다.

commandAction메소드 (Listing 4 참조)는PhoneImageMIDlet이 명령에 응답하도록 하며, 모든 화면 명령어 작업시 호출된다.exitCommand가 호출되었을 때 MIDlet을 종료시키는exitCommand의 핸들러가 정의된다.


Listing 4. 명령어 콜백 구현하기
public void commandAction (  Command c, Displayable s) {    if (c == exitCommand) {            destroyApp(false);            notifyDestroyed();    }   }

Listing 5는PhoneImage애플리케이션의 전체 소스 코드이다. :


Listing 5. PhoneImage
// Import of API classesimport javax.microedition.midlet.*;import javax.microedition.lcdui.*;import java.util.*; //A first MIDlet with simple text and a few commands.public class PhoneImage extends MIDlet                implements CommandListener, ItemStateListener { //The commandsprivate Command exitCommand;//The display for this MIDletprivate Display display;// Display items e.g. Form and ImageForm displayForm;Image image;public PhoneImage() {            display = Display.getDisplay(this);               exitCommand = new Command("Exit", Command.SCREEN, 1);               try                 {                   image = Image.createImage("/img/JavaPowered-8.png");                                   }               catch (java.io.IOException ioExc)               {                    ioExc.printStackTrace();               }   }  // Start the MIDlet by creating the Form and  // associating the exit command and listener.  public void startApp() {                  displayForm = new Form("Image");                     displayForm. append(                new ImageItem("Default Layout",                                image,                                ImageItem.LAYOUT_DEFAULT,                                "Image Cannot be shown"));                    displayForm.addCommand(exitCommand);                     displayForm.setCommandListener(this);                     displayForm.setItemStateListener(this);                     display.setCurrent(displayForm);  }    public  void itemStateChanged(Item item)  {   }    // Pause is a no-op when there is no background  // activities or record stores to be closed.  public void pauseApp() { }   // Destroy must cleanup everything not handled   // by the garbage collector.  public void destroyApp (boolean unconditional) { }   // Respond to commands. Here we are only implementing  // the exit command. In the exit command, cleanup and  // notify that the MIDlet has been destroyed.  public void commandAction (  Command c, Displayable s) {    if (c == exitCommand) {            destroyApp(false);            notifyDestroyed();    }   } }

그림 4는 장치 에뮬레이터상에서 실행되는 애플리케이션이다.


그림 4. PhoneImage 애플리케이션
사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


결론


모든 이동 전화나 호출기에서 작동하는 무선 애플리케이션의 작성이 MIDlet으로 훨씬 쉬워졌다. MIDlet의 잘 정의된 아키텍처는 광범위한 기능을 제공하지만 요약된 아키텍처를 유지하는 잘 정의된 메소드 세트를 기반으로 구축되었다. 나는 이 글이 여러분 자신의 MIDlet 구축에 착수하는데 도움이 되기를 바란다.


사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
위로


참고자료

Posted by 1010
01.JAVA/J2me2008. 11. 27. 12:59
반응형
이클립스에서 J2ME를 사용하려면 플러그인을 설치해야 한다.

일단 이클립스를 실행하고, 업데이트를 하자

메뉴>도움말>소프트웨어 갱신>찾기 및 설치 (한글 플러그인 설치 기준)
사용자 삽입 이미지

설치할 새 기능에 대한 검색
사용자 삽입 이미지

기본으로는 이클릅스ME를 지원 안하닌 새 원격 사이트를 눌러 업데이트 사이트를 등록한다.

이름은 아무렇게나 입력해도 된다.
자기만 알아볼 수 있으면~
주소는 http://www.eclipseme.org/updates/
 
사용자 삽입 이미지

이렇게 입력하고 방금 등록한 사이트를 체크하고 완료를 누르면 새 창이 뜬다.

사용자 삽입 이미지

elipseME를 선택하고 다음

사용자 삽입 이미지

승인하고 다음

사용자 삽입 이미지

모두설치하고 이클립스를 다시 시작하면 된다.

사용자 삽입 이미지
새 프로젝트 추가에 J2ME가 생겼다.

하지만 바로 실행이 불가능하다.
디바이스를 추가해야 한다.

환경설정으로 가서 디바이스를 추가하자.

메뉴>창>환경설정

J2ME>Device Management

사용자 삽입 이미지

import 버튼 클릭

사용자 삽입 이미지

새로나온창에서 브라우즈 버튼을 클릭해
wtk(wireless tool kit)가 깔린 폴더를 선택하자.

그리고는 refresh 버튼을 누르면 알아서 에뮬레이터들이 검색된다.(다른 에뮬을 깔았으면 알아서 그쪽을 선택하시길~)

완료하고 확인하면 이제부터 eclipseME를 사용할 수 있다.
Posted by 1010
01.JAVA/J2me2008. 11. 27. 12:56
반응형

Java의 모든 원천 기술은 Sun Microsystems에서 갖고 있으며 다음과 같이 총 3가지 스펙으로 나누어 집니다.  

   ① J2EE (Java 2 Platform, Enterprise Edition)
   ② J2SE (java 2  Platform, Standard Edition)
   ③ J2ME (Java 2 Platform, Micro Edition)

입니다.

그 중에 J2ME는 엔터프라이즈급을 위한 J2EE와, 일반 PC를 위한 J2SE에 바탕을 두고
정의되었으며, 휴대폰이나 PDA 셋톱박스처럼 휴대용의 작은 기기에 적합한, 동적인 네트웍크
기반의 어플리케이션을 개발 할 수 있도록 설계되었습니다.

그러면 이제 J2ME를 세분화 해 보도록 하겠습니다.
J2ME를 세분화 하면 다음과 같이 총 3 가지로 세분화 할 수 있습니다.

   ① CVM
   ② KVM
 
  ③ Card VM

위와 같이 3가지로 세분화 시켜놓은 것은 VM(Virtual Machine) 에 따라서 구분을 해 놓은 것입니다.

다시 위의 3가지를 자세하게 설명하면 다음과 같습니다.

   ▣ CVM (Classic Virtual Machine)
CVM은 디지털 셋탑박스, TV등을 위한 컨피규레이션인 CDC(Connected Device Configuration)Personal Profile, Foundation Profile, Personal Basis Profile 로 구성됩니다.CVM은 32비트 이상의 프로세서를 가진 디바이스에서 사용됩니다.

즉 CVM 은 밑에서 설명할 KVM을 사용하는 디바이스 보다 덜 제한적인, 즉 조금 더 큰 용량의 디바이스에서 이용될 수 있습니다.

   ▣ KVM (Kilobyte Virtual Machine)  
소형 컴퓨팅 장비들을 위한 J2ME 의 가상 머신입니다. 이 KVM은 휴대폰 이나 PDA , 페이져 등을 위한 컨피규레이션인 CLDC(Connected, Limited Device Configuration)와  MIDP(Mobile Information Device Profile)로 이루어져 있습니다.

   ▣ Card VM
자바 카드를 위한 VM 입니다.

자 ~ ! 위와 같이 정리를 해 놓고 보니 이제 J2ME 라는 녀석이 한눈에 들어오는 느낌이 드실겁니다. 그러면 이제는 우리가 앞으로 집중적으로 공부를 해야할 KVM에 대해서 조금만 더 알아봅시다.

KVM은 휴대폰을 위한 스펙으로 J2ME를 대표하는 솔루션으로 세계 무선 인터넷 플랫폼 시장에서 그 위치가 확고하다고 볼 수 있습니다. 우리나라에서도 SK 텔레콤과 LG텔레콤을 통해 제공되고 있으며, 또한 우리나라에서 독자적으로 개발한 "대한민국 무선 인터넷 플렛폼 "WIPI" 와도 100 % 호환됩니다.

즉 한번 작성한 J2ME 어플리케이션은 자바를 지원하는 전 세계의 대부분의 폰에서 그대로 작동되는 이점을지니고 있다는 겁니다.

CLDC와 MIDP 에 대한 간단한 설명은 다음과 같습니다

CLDC 는 Connected Limited Device Configuration 의 약자 입니다.

여기서 맨 마지막 단어인 Configuration 은 비슷한 특성을 가지는 디바이스들이
가져야될 최소한의 요구사항에 대한 정의 라고 할 수 있습니다.

즉 J2ME자체가 모바일과 같은 제한된 환경의 디바이스들을 위한 표준 스펙이라고 한다면, 다시 그 J2ME 내부에서도 핸드폰과 같은 아주 극한된 환경을 가지고 있는 디바이스들이 가져야 될 최소한의 요구사항을 정의하는 Configuration을 CDDC 라고 하고, 핸드폰보다는 좀 더 여유로운 환경을 가지고 있는 셋톱박스와 같은 디바이스 내에서  가져야 할 최소한의 요구사항을 정의하는 Configuration을 CDC 라고 합니다.

이제 CLDC를 좀 더 살펴보도록 하겠습니다.

CLDC가 대상으로 하는 디바이스에는 핸드폰 이나 PDA, 양방향페이져 등이 있습니다.
이들은 모두 네트워크에 연결될 수 있고, 극히 제한적인 리소스를 가진 디바이스라는
공통점이 있습니다. 하지만 이러한 공통점 만으로 이들을 하나의 범주로 묶을 수는 없습니다.
예를 들면 핸드폰과 양방향 페이져 등은 디스플레이 창의 크기도 다르며, 사용자의 입력을
처리하는 방법도 천차만별입니다.

즉 공통적인 특성을 가진 디바이스라 할지라도 특정 부분에 대해서는 다른 특성을 가진다는
사실은 어쩔 수 없는 것입니다. 즉 이러한 차이점을 Profile 인 MIDP가 맡게 되는 겁니다.

다시한번 말씀드린다면 Configuration은 최소한의 정의만 하고, 실제 구현이나 확장은
Profiles 에서 담당한다고 할 수 있는 겁니다.

Posted by 1010
01.JAVA/J2me2008. 11. 27. 12:55
반응형
1. CLDC 소개
1.1 CLDC 개요
  CLDC(connected limited device configuration)는 앞서 본 바대로 성능이 제한된 CPU나 메모리가 한정적인 시스템을 대상으로 하는 spec이다. CLDC 관련 library는 시스템에 독립적인 고수준의 API 그리고 네트웍관련 API로 되어 있다. 크게 두 가지로 나눌 수 있는데 J2SE에 포함되어 있는 부분과 CLDC에만 있는 부분이다.
J2SE에 포함된 부분
  java.lang
java.util
java.io
CLDC에만 관련된 부분
  javax.microedition.io.*

다음은 CLDC에서 주목해야할 몇 가지 특징들이다.
부동 소수점을 지원하지 않는다.
마무리(finalization)을 지원하지 않는다.
에러 처리가 제한적이다.
JNI(Java Native Interface)를 지원하지 않는다.
리플렉션을 지원하지 않는다.
쓰레드 그룹과 데몬 쓰레드를 지원하지 않는다.
사용자 정의 클래스 로더를 생성할 수 없다.
약한 참조(weak reference)를 지원하지 않는다.
클래스 검증과정이 오프디바이스와 온디바이스로 2단계로 나뉘어 졌다.
클래스 파일 포맷이 다르고, 클래스 룩업, 클래스 로딩과 링킹 방법이 다르다.
모래상자 보안 모델을 사용한다.
전혀 다른 네트워킹 및 입출력 모델을 가지고 있다.
새로운 애플리케이션 모델을 가정하고 있다.

이러한 특징들은 프로그램밍과 시스템의 설계에 있어서 중요한 항목일 경우가 많다. 따라서 하나하나가 의미하는 바를 잘 알아두어야 한다.

1.2 CDC와 CLDC
  CDC, CLDC가 J2ME에서 configuration이라는 것은 이미 배웠다. 두가지 Configuration의 차이를 아래의 표에서 정리하였다.
구 분
CDC
(Connected Device Configuration)
CLDC
(Connected, Limited Device Configuration)
Processor
32bit 또는 64bit 16bit 또는 32bit
네트웍
신뢰성 있는 고속 통신망을 사용하고 대개 TCP/IP를 사용한다. 때로는 끊어지기도 하는 저속 통신망을 사용하고 종종 TCP/IP를 사용하지 않는다.
메모리
1MB - 10MB 32KB - 512KB
가상머신
Java Virtual Machine
또는 Classic Virtual Machine
K Virtual Machine
목표시장
같이 사용하고 고정되어 있으며 상호 연결된 정보 기기들이다. 개인적이고 이동중에 사용하며 상호 연결된 정보 기기들이다.
적용 예
PDA, 스크린폰, 셋탑박스 휴대폰, 무선호출기, 스마트폰, POS 단말기
[ 표 1 - CLDC와 CDC비교 ]

아래의 그림은 이러한 차이를 좀더 그래픽하게 표현하였고 Profile종류도 나타나 있다.
[ 그림 1 - CDC와 CLDC 하드웨어 스펙 ]
1.3 CLDC의 제약
1) 부동소수점을 지원하지 않는다.
  CLDC는 부동소수점을 지원하지 않는다. 이것은 J2SE full spec과 가장 현격한 차이점이기도 하다. 이유는 CLDC 타겟 디바이스가 하드웨어적으로 부동소수점을 지원하지 않기 때문인데, 소프트웨어적으로 부동소수점을 지원하는 것은 너무 큰 부하가 있다. 그래서 언어적인 측면과 가상머신에서 부동소수점은 지원하지 않는다고 명세서에 명시되어 있다. 그러므로, float, double 형과, 부동소수점 리터럴,부동소수점 연산은 사용할 수 없다.
만일 반드시 부동소수점 연산을 해야 한다면 하드웨어 업체가 제공한 OEM spec에서 기능을 찾아보아야 한다. 만일 거기에도 없다면 소프트웨어적으로 처리해야 한다. 다행스럽게도 이러한 Package가 나와 있는데 정수형 타입으로 부동 소수점형 연산을 시뮬레이션 해주는 것이다. MathFP라고 부르는 이 Package는 다음 URL에서 구할 수 있다. SKVM에서는 이 부분을 아예 OEM Spec에 포함하여 출시하고 있다.
http://home.rochester.rr.com/ohommes/MathFP

2) Finalization과 가비지 컬렉션
  CLDC 라이브러리의 Object 클래스에는 finalize() 메소드가 없다. 그러므로, CLDC 가상머신은 클래스 인스턴스를 가비지 컬렉트할 때 finalization을 수행하지 않는다. KVM은 크기가 작고 메모리를 효율적으로 사용하는 가비지 컬렉터를 위해서, 마크-청소(mark-sweep) 알고리즘을 사용하고, 비복사(non-copying), 비압축(non-compacting) 가비지 컬렉터를 사용한다.

3) 에러 처리
  Java에서는 Error 와 Exception 두가지의 예외상황을 처리하는데 Error는 복구할 수 없는 것이고 Exception은 복구가능한 것이다. CLDC는 예외 처리는 지원하지만 에러 처리는 제한적으로 지원한다. 아래와 같이 두가지 Error처리만을 수행하는데 이렇게 대부분의 에러처리가 빠져 버린 이유는
하나는 에러처리가 대부분 하드웨어에서 처리되기 때문이다. 에러 처리가 일관성이 없는 임베디드 환경에서 대부분의 디바이스들은 에러가 발생했을 때, 그냥 리셋을 해 버린다. 다른 하나는 복구할 수 없는 에러를 처리하기 위해서는 매우 힘이 들기 때문이다. 너무 심한 오버헤드를 초래할 가능성이 높다.

java.lang.Error
java.lang.VirtualMachineError
java.lang.OutOfMemoryError

4) JNI(Java Native Interface)
  CLDC는 JNI를 지원하지 않는다. 네이티브 함수를 호출하는 방법은 CLDC의 구현에 의존적이다. 즉, CLDC를 구현하는 사람에게 달려있다는 것이다. JNI는 덩치가 크기도 하지만, CLDC의 제한적인 보안 모델로 인해, 네이티브 함수의 호출 자체가 위험할 수 있기 때문에 지원하지 않는다.

5) 리플렉션
  리플렉션은 런타임시에 자바 프로그램이 가상머신 내부의 클래스, 인터페이스, 객체 인스턴스들을 조사할 수 있게 하는 자바가상 머신의 특징이다. CLDC에서는 이러한 리플렉션 기능을 지원하지 않는다. 따라서 리플렉션 기능에 의존적인 여러가지 기능들을 지원할 수 없다. RMI, 객체 직렬화, 디버깅 인터페이스(JVMDI), 프로파일러 인터페이스(JVMPI) 등이 그것이다. 한가지 아쉬운 것은 RMI가 지원되지 않으므로, CLDC/MIDP 플랫폼에 지니를 올릴 수 없다는 것이다. 지니가 핸드폰에 탑재되기를 기대하시던 분들에게는 실망스러운 소식일 것이다. 무선 지니 디바이스에 관심이 있는 분이라면, RMI 프로파일이 포함된 CDC/퍼스널 프로파일 플랫폼을 탑재한 단말기를 기대하셔야 할 것 같다.
1.4 주요 특징들
1) 보안 모델
  CLDC 타겟 디바이스에는 J2SE 플랫폼의 정책기반(policy-based) 보안 모델을 적용하기 어렵다. 왜냐하면, CLDC 구현보다 보안 모듈이 훨씬 더 큰, ‘배 보다 배꼽이 더 큰’ 형국이 될 것이기 때문이다. CLDC에서 정의된 보안 관련사항은 다음과 같은 두 가지 수준의 보안에 대한 지원이다.
동적인 애플리케이션의 다운로드가 가능하다.
    어떤 방법으로든 가상머신 내부에서 동작하는 애플리케이션은 디바이스에 위해한 행위를 할 수 없다.
  클래스 파일 검증기에 의해 검증되어야 한다.
애플리케이션 레벨 보안
    모래상자 보안 모델의 적용

보안에 관한 한 CLDC는 원시적인 자바의 모습으로 퇴화했는데, CLDC 모래상자 보안 모델은 다음과 같은 요구사항을 만족해야 한다.
자바 클래스 파일은 유효한 자바 애플리케이션임이 검증되고 보장되어야 한다.
애플리케이션 프로그래머는 사전에 미리 정의된 자바 API만을 사용해야 한다.
자바 애플리케이션의 다운로드와 관리는 네이티브 코드수준에서만 가능하다. 클래스 로딩 메커니즘과 가  상머신의 시스템 클래스를 오버라이딩할 수 없다.
네이티브 함수를 호출하는 새로운 라이브러리를 사용해서 애플리케이션을 작성할 수 없다.

2) 클래스 검증 과정
  J2SE의 virtual Machine과 같이, KVM에서도 class file의 수행전에 verify하는 과정을 거쳐야 할 필요가 있다. 하지만 JVM의 class file 검증은 과도한 static / dynamic foot print를 사용하기 때문에 좀 더 단순하고, 효율적인 검증과정이 필요로 하게 되었다. 그 solution으로 제시된 것이 OFF-Line 사전검증 과 ON-Line 검증으로 나누어 검증하는 것이다.

J2SE의 Java Virtual Machine에서 일반적으로 검증기(verifier)는 runtime시 50KB의 binary code space와 30~100 KB의 동적 RAM을 필요로 한다. 게다가 CPU역시 실행 시 반복이 많은 data flow 알고리즘을 가지므로 많은 over head를 가지게 된다. 검증(verify)은 프로그램코드의 이동성을 보장하는 Java VM의 제어장치라고 할 수 있을 것이다. 검증기는 프로그램이 검증을 거쳐서 특정한 규칙을 따르고 있으며, 이 어플리케이션이 실행됨으로써 다른 어플리케이션 및 device의 안전을 보장하는 것이다. 반드시 필요한 반면 위에서 설명하다시피 embedded device에서는 과도한 performance를 요구하게 된다.. 그래서 나눈 것이 사전검증(pre-verify)과 실행 시 검증(verify)이다. 즉 OFF-Line 사전검증 과 ON-Line 검증인 것이다.

<그림 2>를 보도록 하자. MyApp.java라는 애플리케이션을 작성한 후에 컴파일을 수행하면, MyApp.class라는 클래스 파일을 얻을 수 있다. 이 클래스 파일은 자바 가상머신 명세서에 정의된 클래스 파일 포맷을 따른다. 이 클래스 파일을 사전검증기(preverifier)를 통해 사전검증을 하게 되면, 변경된 MyApp.class 파일을 얻게 된다. 이 때, 이 클래스 파일은 CLDC 명세서에 정의된 클래스 파일 포맷을 따르게 된다. 이렇게 사전검증된 클래스 파일을 디바이스에서 다운로드하여 로딩한 후에는 온-디바이스 검증을 수행한다.

[ 그림 2 - 클래스 파일 검증 과정 ]

검증 과정은 프로그램 코드의 네트웍 이동성을 보장하는 자바 가상머신의 안전장치이다.
즉, 검증 과정을 통해서 자바 가상머신은 애플리케이션이 특정한 규칙을 따르고 있음을 확인하고, 이 애플리케이션의 수행이 안전함을 보장할 수 있다. 이것은 애플리케이션이 허락되지 않은 위험한 작업을 수행하지 못하도록 함으로써, 시스템의 안정성을 확보하고, 바이러스 등의 위해한 애플리케이션의 등장을 방지할 수 있게 해 준다. 그러나, 검증 알고리즘을 구현하는 것은 약 50K 정도의 코드 공간이 필요하고, 기존의 검증 과정은 실행시 오버헤드도 크다. 그래서, 사전검증과 실행시 검증이라는 새로운 방법을 CLDC에서 도입한 것이다.
이러한 검증방법을 안전하고 유효하게 만들기 위해서는 몇가지 복잡한 고려를 해야 한다. 그 중에서도 가장 중요한 것은 클래스 파일포맷의 변화이다. 온-디바이스 검증기가 정상적으로 검증을 수행하기 위해서는 사전검증기가 이에 필요한 추가정보를 클래스 파일에 포함시켜야 하고, ‘스택 맵 애트리뷰트’라고 불리는 이러한 추가적인 애트리뷰트를 통해 온-디바이스 검증기는 효율적인 검증을 수행할 수 있다. 추가적인 애트리뷰트로 인해 클래스 파일의 크기는 약 5% 정도 늘어나게 되지만, 온-디바이스 검증기의 크기를 효과적으로 줄일 수 있고, 검증시에 재귀적인 검증을 하지 않고, 1패스 검증을 할 수 있다는 측면에서는 상당한 향상이 있었다고 평가할 수 있다.

다음은 위에서 설명한 사전검증과 실행시 검증으로 분리된 검증방법의 특징들이다.
오프-디바이스에서 공간절약적인 처리(스택 맵 생성, 복잡한 바이트코드 제거)
온-디바이스에서 정확성 체크 : 스푸핑이 불가능
코드 사이닝이 필요없음(원시적인 모래상자 보안모델 사용)
온-디바이스 풋프린트 약 10K 요구, 런타임시 상수 공간 100바이트 이하 필요, 선형 처리(재귀적이지
  않은 1패스 처리)를 통한 검증시간 절약

3) 클래스의 로딩과 링킹
  CLDC 명세는 JAR(Java ARchive) 파일 포맷을 지원을 강제하고, MIDP 명세는 클래스 파일의 배포를 반드시 JAR(Java ARchive) 파일을 통해서만 이루어 지도록 하고 있다. 이것은 JAR 파일의 사용이 약 30~40% 정도의 대역폭 절감 효과가 있기 때문이다. 물론, 이 때 배포되는 JAR 파일에 포함된 클래스 파일들은 사전검증기에 의해 사전검증이 된 클래스 파일이어야 함은 당연하다.

로딩이란 애플리케이션에서 사용하고자 하는 클래스 파일들을 자바 가상머신으로 전달하는 과정을 말한다. CLDC에서는 JAR 파일의 형태로 네트웍을 통해 전송된 클래스 파일들이 시스템 클래스 로더에 의해 로딩된다. 링킹은 로딩된 클래스 파일, 즉, 바이너리 코드가 자바 가상머신에 의해서 수행될 수 있는 상태로 만드는 과정이다. 이 과정은 로딩된 클래스가 올바른 클래스 포맷을 가지고 있는 지 실행시 검증을 하는 검증(verification) 과정과, 메모리 영역의 할당 등의 예비 과정(preparation), 심볼릭 참조 주소를 직접 참조 주소로 변환하는 결정 과정(resolution) 등으로 세분화할 수 있다. 이 때, 보안상의 이유와 애플리케이션 관리 소프트웨어의 존재로 인해 클래스 파일의 룩업순서가 조금 다르며, 사용자 정의 클래스 로더를 만들 수 없다는 것도 CLDC의 특징이다.

여기서 한가지 강조하고 싶은 문제는 CLDC 디바이스는 대부분 파일시스템이 없다는 것이다. 그러므로, CLDC 명세도 파일시스템에 대한 고려를 하지 않고 있다. 즉, 플래시 메모리를 주 저장장치로 사용하는 CLDC 디바이스의 경우에, 저장공간은 ROM이 아니면 RAM이라는 것이다. 일반적으로 파일 시스템이 보조 기억장치로서 존재하는 PC 시스템의 경우, 자바 가상머신이 수행될 때, 먼저 자바 가상머신이 파일 시스템으로부터 메모리로 올려 진다. 그리고, 클래스 로더가 필요한 시스템 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그리고 나서, 필요한 사용자 정의 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그런데, CLDC 디바이스에서는 가상머신과 시스템 클래스 파일들이 이미 메모리에 존재한다. 그런데, 굳이 로딩과 링킹, 초기화라는 불필요한 절차를 거칠 필요가 있을까? 로마이징(ROMizing)은 이처럼 특정 클래스들을 사전에 미리 로딩하고 링킹해 놓음으로써 애플리케이션의 속도 향상을 가져올 수 있는 기법을 의미한다. CLDC 명세에서는 사전로딩/사전링킹을 통한 로마이징을 구현에 의존적인 기능으로 정의하고 있다.

4) CLDC 라이브러리
  자바와 관련한 신기술이 발표될 때 마다, 함께 쏟아져 나오는 API들은 늘 신선함과 함께 부담감으로 작용한다. 필자는 개인적으로 선이 이룩한 가장 기념비적인 업적 중의 하나가 javadoc이라는 문서화 툴의 확산이라고 생각한다. 만일, 그토록 많은 API들의 홍수 속에 살면서, javadoc에 의한 편리하고, 보편적인 문서화가 이루어지지 않았다면, 많은 사람들이 자바를 외면했을 것이라는 생각을 해 본다. 그럼에도 불구하고, 매번 새로운 API를 접하는 것은 상당히 부담스러운 일이다. 그러므로, CLDC에서도 가능하면 모든 API들이 기존의 J2SE API의 서브셋이기를 바라는 것이 자바 개발자들의 공통된 요구일 것이다. 하지만, MIDP를 통해서 더욱 확실히 느끼게 되겠지만, 기존 API와의 호환성은 잊어버리는 게 좋을 정도로 많은 API들이 재정의되었다. 재사용 가능한 API들이라고는 다음 세 가지의 패키지들 중에서도 일부일 뿐이다. 각각의 패키지에 포함된 클래스들은 [표 2]에 정리하였다.

java.lang 패키지
java.util 패키지
java.util 패키지
시스템 클래스
java.lang.Object
java.lang.Class
java.lang.Runtime
java.lang.System
java.lang.Thread
java.lang.Runnable
java.lang.String
java.lang.StringBuffer
java.lang.Throwable

데이터 타입 클래스

java.lang.Boolean
java.lang.Byte
java.lang.Short
java.lang.Integer
java.lang.Long
java.lang.Character

수학 클래스
java.lang.Math
컬렉션 클래스
java.util.Vector
java.util.Stack
java.util.Hashtable
java.util.Enumeration

날짜관련 클래스
java.util.Calendar
java.util.Date
java.util.TimeZone

유틸리티 클래스
java.util.Random

입출력 클래스
java.io.InputStream
java.io.OutputStream
java.io.ByteArrayInputStream
java.io.ByteArrayOutputStream
java.io.DataInput
java.io.DataOutput
java.io.DataInputStream
java.io.DataOutputStream
java.io.Reader
java.io.Writer
java.io.InputStreamReader
java.io.OutputStreamWriter
java.io.PrintStream
[ 표 2 - CLDC 라이브러리 ]

5) 프로퍼티
  [표 2]에서 java.util.Properties를 찾아 보면 찾을 수 없을 것이다. 즉, CLDC에서는 프로퍼티 기능을 지원하지 않는다는 것이다. 다만, System.getProperty(String key) 메소드를 통해서 시스템 프로퍼티에 접근할 수는 있다. 하지만, setProperty() 메소드는 지원되지 않는다는 것을 확인하기 바란다. 그러므로, 애플리케이션 개발자는 시스템 프로퍼티를 변경하거나 새로운 프로퍼티를 생성할 수는 없다. [표 3]은 CLDC에서 정의하는 시스템 프로퍼티들이다. MIDP에서는 지역화를 고려하여 locale 프로퍼티를 추가하였다.

명세서
프로퍼티 키
설 명
CLDC
microedition.platform 호스트 플랫폼 혹은 디바이스의 이름 BI-Generic
CLDC
microedition.encoding 디폴트 캐릭터 인코딩 EUC-KR
CLDC
microedition.configuration 지원 컨피큐레이션 이름-버전 CLDC-1.0
CLDC
microedition.profiles 지원 프로파일 이름-버전 MIDP-1.0
MIDP
microedition.locale 디바이스의 현재 로캘 ko-KR
[ 표 3 - 시스템 프로퍼티 ]

6) 국제화/지역화
  국제화/지역화의 지원은 아직 CLDC/MIDP에서는 제대로 지원을 보장하지 못하고 있다. CLDC에서 유니코드 문자를 바이트로 변환해 주는 변환기를 제한적으로 지원할 뿐이다. 이러한 국제화 지원은 Reader와 Writer를 통해서 이루어지고, 각각에 대해서는 다음과 같은 생성자에서 두 번째 인자로 인코딩 방법을 지정함으로써 코드 변환을 할 수 있다.

    new InputStreamReader(InputStream is, String name)
    new OutputStreamWriter(OutputStream os, Striing name)

ISO8859_1 이외의 인코딩 방법에 대해서는 기본적으로 CLDC/MIDP 구현자에게 의존적이며, 날짜, 시간, 통화 등의 포맷에 관련한 지역화에 대해서도 MIDP 구현에 의존적이다. 국제화/지역화 문제는 <표 3>에서와 같이 시스템 프로퍼티에 한글 인코딩과 한국의 로캘을 지정하고, 코드 변환기와 포맷 변화기가 완전히 구현되어야 한다. 선 마이크로시스템즈의 CLDC 1.0 베타와 MIDP Early Access 1에서는 한글 및 지역화 지원이 완벽하지 않다고 한다. 그러나 조만간에 이 문제는 해결이 될 것이라 생각된다.

7) 애플리케이션 관리 메커니즘
  이 글의 서두에서 모바일 솔루션으로서의 자바의 특장점 중의 하나가 애플리케이션의 동적인 다운로드 기능이라고 했다. 자바 애플릿을 떠올린 분들이 많으실텐데, 이것은 커다란 오해다. CLDC/MIDP 플랫폼에서는 완전히 새로운 애플리케이션 모델을 제시하고 있다. ‘애플리케이션 관리 소프트웨어’라고 불리는 새로운 소프트웨어의 등장은 애플릿과 애플리케이션의 혼합, 혹은 자바 플러그-인의 확장이라고 할 수 있는, 새롭지만, 그리 낯설지 않은 애플리케이션의 배포와 관리 메커니즘을 제공하고 있다. CLDC는 단지 이러한 애플리케이션 관리 소프트웨어의 존재에 대해서만 가정하고 있으며, 실질적인 애플리케이션 모델에 대한 정의는 MIDP에서 이루어 지고 있으므로, 나중에 이 부분을 자세히 살펴보도록 하자.

8) Generic Connection Framework
  CLDC에서는 확장 패키지에 포함될 클래스를 정의하는 부분이 있다. javax.microedition.io 패키지가 그것인데, 여기에는 Generic Connection Framework(이하, 커넥션 프레임웍)이라고 이름이 붙은 네트워킹과 입출력에 대한 상위 수준의 프레임웍에 대한 인터페이스 정의가 포함되어 있다.

왜 전혀 새로운 네트워킹과 입출력 프레임웍을 정의해야만 했는가? 이에 대한 해답은 다시 메모리의 제약으로 돌아간다. 기존의 java.net 패키지와 java.io 패키지는 덩치가 너무 크다. 100개 이상의 클래스와 200K 이상의 크기를 가진 이 패키지들은 CLDC 디바이스들에는 적합하지 않다. 게다가, TCP/IP, WAP, iMode, IrDA, Bluetooth라는 새로운 통신방법에 대한 지원과, 파일 시스템이 존재하지 않는 입출력 메커니즘을 하나로 통합할 필요성이 존재했다. 그리고, 그 방법으로 새로운 프레임웍의 정의를 선택한 것이다. 다음은 커넥션 프레임웍의 설계목표이다.
서로 다른 형태의 입출력 형태를 일관성있게 지원한다.
서로 다른 형태의 프로토콜을 일관성있게 지원한다.
애플리케이션의 포터빌리티를 향상시킨다.
표준 자바 클래스 라이브러리와의 상위 호환성을 가진다.
더 작은 메모리 풋프린트를 가진다.

CLDC의 커넥션 프레임웍은 네트웍과 입출력을 포함한 모든 연결의 생성에 대해서 다음과 같은 형태의 일관성을 제공한다.

Connector.open(“<protocol>:<address>”);

이 일관성의 핵심은 Connector 클래스만으로 모든 연결을 생성할 수 있으며, open() 메소드의 인자를 변경함으로써 연결의 형태를 바꿀 수 있다는 데에 있다. 연결이 성공적이었다면, open() 메소드는 커넥션 프레임웍의 인터페이스들을 구현한 클래스의 인스턴스를 리턴한다. <그림 3>은 커넥션 프레임웍의 계층도에 대해 보여주고 있다. 그리고, <표 5>는 Connector 클래스를 이용해서 여러 프로토콜의 연결을 생성하는 예를 보여주고 있다.
통신 방법
연결 예제
HTTP 레코드 Connector.open(“http://www.javaline.co.kr”)
FTP 레코드 Connector.open(“ftp://www.javaline.co.kr”);
소켓 Connector.open(“socket://10.1.7.1:9192”)
커뮤니케이션 포트 Connector.open(“comm:9600:18N”)
데이터그램 Connector.open(“datagram://10.1.7.1”)
파일 Connector.open(“file:/maso.doc”)
네트웍 파일 시스템 Connector.open(“nfs:/10.1.7.1/maso.doc”)
적외선 통신
Connector.open(“irda://”)
[ 표 4 - 프로토콜별 연결생성 예 ]

한 가지 분명히 해 두어야 할 것은 CLDC는 Connector 클래스를 포함해서, 어떠한 실제 구현에 대한 명세도 포함하지 않는다는 점이다. 커넥션 프레임웍은 단지 프레임웍만을 제공할 뿐, 실질적으로 지원할 프로토콜에 대한 정의와 구현은 프로파일의 몫이며, MIDP에서는 HTTP 프로토콜의 지원에 대해서 정의하고 있다. MIDP의 HTTP 지원은 나중에 다시 살펴보도록 하자.
IONETKOREA E&D 연구소 제공 
Posted by 1010
01.JAVA/J2me2008. 11. 27. 12:54
반응형
1년전에 J2ME 회사에서 일할 때, PSP에 KVM을 포팅하고자 시도하려고 했던 적이 있었습니다.
시작하려고 보니 정말 해줄것이 하나 두개가 아니더군요..
덕분에 키보드에 손도 못올려보고 포기했었는데...
어제 Sun Developer Day 2008-2009에서 J2ME 섹션에서 아래 사이트를 소개해주시면서 PSP로 데모를 보여주시더군요..
눈이 번쩍띄었습니다.
당분간 심심하지 않을 놀이거리가 생겼어요.. ^^
영어가 그리 어렵지 않아 모두들 걍 보실 수 있으시겠지만 한번 써봅니다.
더 좋은 정보 알고 계신분 feedback 부탁드릴께요~


원문 : http://www.pspkvm.com/

주의 : 이 글은 제 마음대로 직역, 오역, 의역이 적절히 섞여있습니다 ^^;;
         제가 덧붙인 글은 덧) 이라고 썼습니다.  (만.. 번역한거나 덧붙인거나 사실 제 맘대로 쓴건 똑같습니다.)


PSP에서 J2ME 어플리케이션을 구동하기 위한 KVM을 소개합니다.

메인 페이지는 아래와 같습니다.
  http://www.pspkvm.org (둘중 아무거나 선택해서 들어오세요)


설치법은 "PSPKVM" 폴더를 가지고 계신 PSP 메모리 스틱내의 /PSP/GAME 폴더나 /PSP/GAME150 폴더에 복사하시면 됩니다.
(전 GAME150에 넣었습니다.)

덧) 다운로드 사이트 URL은 http://sourceforge.net/projects/pspkvm/ 입니다.
상단의 Download를 누르시고 package명이 pspkvm인 것의 오른쪽 끝에 보면 Download가 또 있습니다.
이걸 누르시면 다섯개가 쭉 뜹니다.
자신의 PSP 커널에 맞게 1.5 커널이면 150 이라고 써진것을 받으시고요..
3.xx 버전이시면 oe라고 써진것을 받으시면 됩니다.
그리구 allinone은 처음 설치하시는 분 꺼고, upgrade는 기존 사용자 분것입니다.
속편하게 1.5 커널이신분은 pspkvm-bin-0.4.2-150-allinone.zip 를 받으시고요..
3.xx 커널이신 분은 pspkvm-bin-0.4.2-oe-allinone.zip를 받으세요.
(http://www.pspkvm.org/Download.html 이곳에서도 되는군요..)


사용법은 아래와 같습니다.

1) AMS에서 제일 위에 있는 "Find Application"을 선택한다.
    덧) AMS : Application Management Software 의 약자로 J2ME에서 구동되는 어플리케이션을 설치, 제거, 관리하는 Software를 의미한다.
2) "Install from memory stick (ms0:/)"를 선택한다.
3) 메모리 스틱내에 실행시킬 jar 파일이나 jad 파일을 선택합니다.
    덧) J2ME에서 구동되는 어플리케이션은 jar 파일과 jad 파일로 구성됩니다. jar 파일(Java Archiv)은 컴파일된 소스들의 모임이고 jad 파일(Java Application Descriptor)은 해당 어플리케이션의 정보를 담고 있습니다. J2ME에서는 이러한 어플리케이션을 Midlet이라 쓰고 미들릿 이라 읽습니다.
4) jar나 jad 선택 후에 자동으로 해당 어플리케이션이 설치되고 구동됩니다. 다음부터는 AMS 첫 화면에서 지금 설치한 어플리케이션을 바로 실행할 수 있습니다.

덧) 즉, 어플리케이션 설치를 위해서 jar나 jad를 선택하면 알아서 설치된다.
그리고 설치된 어플리케이션은 AMS 첫 화면에 나오니까 실행하고 싶은 것을 선택하면 실행된다는 말씀.

더 자세한 정보를 얻고 싶으면 여기(Getting Started Guide)를 선택하세요


기본 키 매핑은 다음과 같습니다.
NUM0  :    Cross
NUM1  :    Square
NUM2  :    UP
NUM3  :    Triangle
NUM4  :    LEFT
NUM5  :    Shift+Circle
NUM6  :    RIGHT
NUM7  :    Shift+Square
NUM8  :    DOWN
NUM9  :    Shift+Triangle
*   :       Shift+SELECT
#   :       Shift+START
CLEAR  :   Shift+Cross
SELECT  :   Circle
Left Soft :   SELECT
Right Soft :   START
UP/DOWN/LEFT/RIGHT:  Analog joy stick
("Shift"라고 쓴것은 Left Trigger 나 Right Trigger를 누른 상태를 의미)
Left Trigger + Right Trigger + Triangle: 멀티 테스킹 키 (실행중인 미들릿을 백그라운드로 보내고 AMS로 돌아갑니다.)
Left Trigger + Right Trigger + Cross:    현재 실행중인 미들릿에서 빠져나갑니다.

Features: - 여긴 어려운 내용이 없으니 별 내용없는건 건너 뛰어요~
    MIDP 2.0
    Nokia UI APIs (partial)
    WMA1.1(JSR120) stub - 덧) 미디어 관련 API로 여러 어플들이 이 API를 사용하기 때문에 일단 껍데기만 구현한듯 싶네요
    Networking (By PSP's WIFI)
    Java AMS with MVM supporting - 덧) Multiple VM입니다. 컴퓨터처럼 한번에 여러 어플을 실행할 수 있다는 것이죠
    Several input methods: QWERTY/Abc/Symbol/... - 여러 입력 방법을 제공한답니다
    Directly browse and run from local jad/jar file, and auto-install without interrupting
    - 메모리 스틱의 jar, jad를 선택하면 한큐에 설치해준다는 말이네요
    Jpeg support
    MIDI & Wave audio playback support
    Device emulation. You can choose device type to emulate for different screen sizes and key codes, either at installation time or from "Select device" menu
    - 사용자가 화면 사이즈와 키 코드 등을 프로그램을 설치할 때나 "Select device" 메뉴를 통해 선택할 수 있다.
    Change default key assignment for specific application.
    - 특정 어플을 위해 키 매핑을 바꿀 수 있다.
    JSR75(File Connection) - 덧) 파일을 읽고 쓰기 위한 API 입니다.
    Virtual Keyboard Input
    Chinese Input - 덧) Korean Input이면 얼마나 좋을까요..,
    JSR179(Location API) - 덧) Location이 들어간다면 map도 가능하겠네요..
    Freetype2 font rendering - 덧) 예쁜 폰트를 그릴 수 있겠는데요~


모바일 자바쪽으로 유명한 게임회사인 gameloft에서 출시한 게임과의 compatible list도 나와있군요..

일단 읽어보고 할만한게 있으면 Getting Start도 한번 해볼까 합니다.
Posted by 1010
01.JAVA/J2me2008. 9. 24. 15:23
반응형
이클립스에서 J2ME를 사용하려면 플러그인을 설치해야 한다.

일단 이클립스를 실행하고, 업데이트를 하자

메뉴>도움말>소프트웨어 갱신>찾기 및 설치 (한글 플러그인 설치 기준)
사용자 삽입 이미지

설치할 새 기능에 대한 검색
사용자 삽입 이미지

기본으로는 이클릅스ME를 지원 안하닌 새 원격 사이트를 눌러 업데이트 사이트를 등록한다.

이름은 아무렇게나 입력해도 된다.
자기만 알아볼 수 있으면~
주소는 http://www.eclipseme.org/updates/
 
사용자 삽입 이미지

이렇게 입력하고 방금 등록한 사이트를 체크하고 완료를 누르면 새 창이 뜬다.

사용자 삽입 이미지

elipseME를 선택하고 다음

사용자 삽입 이미지

승인하고 다음

사용자 삽입 이미지

모두설치하고이클립스를 다시 시작하면 된다.

사용자 삽입 이미지
새 프로젝트 추가에 J2ME가 생겼다.

하지만 바로 실행이 불가능하다.
디바이스를 추가해야 한다.

환경설정으로 가서 디바이스를 추가하자.

메뉴>창>환경설정

J2ME>Device Management

사용자 삽입 이미지

import 버튼 클릭

사용자 삽입 이미지

새로나온창에서 브라우즈 버튼을 클릭해
wtk(wireless tool kit)가 깔린 폴더를 선택하자.

그리고는 refresh 버튼을 누르면 알아서 에뮬레이터들이 검색된다.(다른 에뮬을 깔았으면 알아서 그쪽을 선택하시길~)

완료하고 확인하면 이제부터 eclipseME를 사용할 수 있다.
Posted by 1010
01.JAVA/J2me2008. 9. 24. 15:21
반응형
htt;://sava.sun.com

다운로드 > Java ME

제일위의 최신버전 다운로드

최종 url
https://sdlc2a.sun.com/ECom/EComActionServlet/DownloadPage:~:com.sun.sunit.sdlc.content.DownloadPageInfo;jsessionid=F03563D44F79D5B2037536A1FE7569A1;jsessionid=F03563D44F79D5B2037536A1FE7569A1

사용자 삽입 이미지
Posted by 1010
01.JAVA/J2me2008. 9. 24. 14:29
반응형
1. CLDC 소개
1.1 CLDC 개요
  CLDC(connected limited device configuration)는 앞서 본 바대로 성능이 제한된 CPU나 메모리가 한정적인 시스템을 대상으로 하는 spec이다. CLDC 관련 library는 시스템에 독립적인 고수준의 API 그리고 네트웍관련 API로 되어 있다. 크게 두 가지로 나눌 수 있는데 J2SE에 포함되어 있는 부분과 CLDC에만 있는 부분이다.
J2SE에 포함된 부분
  java.lang
java.util
java.io
CLDC에만 관련된 부분
  javax.microedition.io.*

다음은 CLDC에서 주목해야할 몇 가지 특징들이다.
 부동 소수점을 지원하지 않는다. 
 마무리(finalization)을 지원하지 않는다. 
 에러 처리가 제한적이다. 
 JNI(Java Native Interface)를 지원하지 않는다. 
 리플렉션을 지원하지 않는다. 
 쓰레드 그룹과 데몬 쓰레드를 지원하지 않는다. 
 사용자 정의 클래스 로더를 생성할 수 없다. 
 약한 참조(weak reference)를 지원하지 않는다. 
 클래스 검증과정이 오프디바이스와 온디바이스로 2단계로 나뉘어 졌다. 
 클래스 파일 포맷이 다르고, 클래스 룩업, 클래스 로딩과 링킹 방법이 다르다. 
 모래상자 보안 모델을 사용한다. 
 전혀 다른 네트워킹 및 입출력 모델을 가지고 있다. 
 새로운 애플리케이션 모델을 가정하고 있다.

이러한 특징들은 프로그램밍과 시스템의 설계에 있어서 중요한 항목일 경우가 많다. 따라서 하나하나가 의미하는 바를 잘 알아두어야 한다.

1.2 CDC와 CLDC
  CDC, CLDC가 J2ME에서 configuration이라는 것은 이미 배웠다. 두가지 Configuration의 차이를 아래의 표에서 정리하였다.
구 분
CDC
(Connected Device Configuration)
CLDC 
(Connected, Limited Device Configuration)
Processor
32bit 또는 64bit 16bit 또는 32bit
네트웍
신뢰성 있는 고속 통신망을 사용하고 대개 TCP/IP를 사용한다. 때로는 끊어지기도 하는 저속 통신망을 사용하고 종종 TCP/IP를 사용하지 않는다.
메모리
1MB - 10MB 32KB - 512KB
가상머신
Java Virtual Machine 
또는 Classic Virtual Machine
K Virtual Machine
목표시장
같이 사용하고 고정되어 있으며 상호 연결된 정보 기기들이다. 개인적이고 이동중에 사용하며 상호 연결된 정보 기기들이다.
적용 예
PDA, 스크린폰, 셋탑박스 휴대폰, 무선호출기, 스마트폰, POS 단말기
[ 표 1 - CLDC와 CDC비교 ]

아래의 그림은 이러한 차이를 좀더 그래픽하게 표현하였고 Profile종류도 나타나 있다.
[ 그림 1 - CDC와 CLDC 하드웨어 스펙 ]
1.3 CLDC의 제약
1) 부동소수점을 지원하지 않는다.
  CLDC는 부동소수점을 지원하지 않는다. 이것은 J2SE full spec과 가장 현격한 차이점이기도 하다. 이유는 CLDC 타겟 디바이스가 하드웨어적으로 부동소수점을 지원하지 않기 때문인데, 소프트웨어적으로 부동소수점을 지원하는 것은 너무 큰 부하가 있다. 그래서 언어적인 측면과 가상머신에서 부동소수점은 지원하지 않는다고 명세서에 명시되어 있다. 그러므로, float, double 형과, 부동소수점 리터럴,부동소수점 연산은 사용할 수 없다. 
만일 반드시 부동소수점 연산을 해야 한다면 하드웨어 업체가 제공한 OEM spec에서 기능을 찾아보아야 한다. 만일 거기에도 없다면 소프트웨어적으로 처리해야 한다. 다행스럽게도 이러한 Package가 나와 있는데 정수형 타입으로 부동 소수점형 연산을 시뮬레이션 해주는 것이다. MathFP라고 부르는 이 Package는 다음 URL에서 구할 수 있다. SKVM에서는 이 부분을 아예 OEM Spec에 포함하여 출시하고 있다. 
http://home.rochester.rr.com/ohommes/MathFP 

2) Finalization과 가비지 컬렉션
  CLDC 라이브러리의 Object 클래스에는 finalize() 메소드가 없다. 그러므로, CLDC 가상머신은 클래스 인스턴스를 가비지 컬렉트할 때 finalization을 수행하지 않는다. KVM은 크기가 작고 메모리를 효율적으로 사용하는 가비지 컬렉터를 위해서, 마크-청소(mark-sweep) 알고리즘을 사용하고, 비복사(non-copying), 비압축(non-compacting) 가비지 컬렉터를 사용한다.

3) 에러 처리
  Java에서는 Error 와 Exception 두가지의 예외상황을 처리하는데 Error는 복구할 수 없는 것이고 Exception은 복구가능한 것이다. CLDC는 예외 처리는 지원하지만 에러 처리는 제한적으로 지원한다. 아래와 같이 두가지 Error처리만을 수행하는데 이렇게 대부분의 에러처리가 빠져 버린 이유는 
하나는 에러처리가 대부분 하드웨어에서 처리되기 때문이다. 에러 처리가 일관성이 없는 임베디드 환경에서 대부분의 디바이스들은 에러가 발생했을 때, 그냥 리셋을 해 버린다. 다른 하나는 복구할 수 없는 에러를 처리하기 위해서는 매우 힘이 들기 때문이다. 너무 심한 오버헤드를 초래할 가능성이 높다. 

 java.lang.Error 
 java.lang.VirtualMachineError 
 java.lang.OutOfMemoryError

4) JNI(Java Native Interface)
  CLDC는 JNI를 지원하지 않는다. 네이티브 함수를 호출하는 방법은 CLDC의 구현에 의존적이다. 즉, CLDC를 구현하는 사람에게 달려있다는 것이다. JNI는 덩치가 크기도 하지만, CLDC의 제한적인 보안 모델로 인해, 네이티브 함수의 호출 자체가 위험할 수 있기 때문에 지원하지 않는다.

5) 리플렉션
  리플렉션은 런타임시에 자바 프로그램이 가상머신 내부의 클래스, 인터페이스, 객체 인스턴스들을 조사할 수 있게 하는 자바가상 머신의 특징이다. CLDC에서는 이러한 리플렉션 기능을 지원하지 않는다. 따라서 리플렉션 기능에 의존적인 여러가지 기능들을 지원할 수 없다. RMI, 객체 직렬화, 디버깅 인터페이스(JVMDI), 프로파일러 인터페이스(JVMPI) 등이 그것이다. 한가지 아쉬운 것은 RMI가 지원되지 않으므로, CLDC/MIDP 플랫폼에 지니를 올릴 수 없다는 것이다. 지니가 핸드폰에 탑재되기를 기대하시던 분들에게는 실망스러운 소식일 것이다. 무선 지니 디바이스에 관심이 있는 분이라면, RMI 프로파일이 포함된 CDC/퍼스널 프로파일 플랫폼을 탑재한 단말기를 기대하셔야 할 것 같다.
1.4 주요 특징들
1) 보안 모델
  CLDC 타겟 디바이스에는 J2SE 플랫폼의 정책기반(policy-based) 보안 모델을 적용하기 어렵다. 왜냐하면, CLDC 구현보다 보안 모듈이 훨씬 더 큰, ‘배 보다 배꼽이 더 큰’ 형국이 될 것이기 때문이다. CLDC에서 정의된 보안 관련사항은 다음과 같은 두 가지 수준의 보안에 대한 지원이다.
 동적인 애플리케이션의 다운로드가 가능하다.
    어떤 방법으로든 가상머신 내부에서 동작하는 애플리케이션은 디바이스에 위해한 행위를 할 수 없다.
  클래스 파일 검증기에 의해 검증되어야 한다.
 애플리케이션 레벨 보안
    모래상자 보안 모델의 적용

보안에 관한 한 CLDC는 원시적인 자바의 모습으로 퇴화했는데, CLDC 모래상자 보안 모델은 다음과 같은 요구사항을 만족해야 한다. 
 자바 클래스 파일은 유효한 자바 애플리케이션임이 검증되고 보장되어야 한다.
 애플리케이션 프로그래머는 사전에 미리 정의된 자바 API만을 사용해야 한다.
 자바 애플리케이션의 다운로드와 관리는 네이티브 코드수준에서만 가능하다. 클래스 로딩 메커니즘과 가  상머신의 시스템 클래스를 오버라이딩할 수 없다.
 네이티브 함수를 호출하는 새로운 라이브러리를 사용해서 애플리케이션을 작성할 수 없다.

2) 클래스 검증 과정
  J2SE의 virtual Machine과 같이, KVM에서도 class file의 수행전에 verify하는 과정을 거쳐야 할 필요가 있다. 하지만 JVM의 class file 검증은 과도한 static / dynamic foot print를 사용하기 때문에 좀 더 단순하고, 효율적인 검증과정이 필요로 하게 되었다. 그 solution으로 제시된 것이 OFF-Line 사전검증 과 ON-Line 검증으로 나누어 검증하는 것이다. 

J2SE의 Java Virtual Machine에서 일반적으로 검증기(verifier)는 runtime시 50KB의 binary code space와 30~100 KB의 동적 RAM을 필요로 한다. 게다가 CPU역시 실행 시 반복이 많은 data flow 알고리즘을 가지므로 많은 over head를 가지게 된다. 검증(verify)은 프로그램코드의 이동성을 보장하는 Java VM의 제어장치라고 할 수 있을 것이다. 검증기는 프로그램이 검증을 거쳐서 특정한 규칙을 따르고 있으며, 이 어플리케이션이 실행됨으로써 다른 어플리케이션 및 device의 안전을 보장하는 것이다. 반드시 필요한 반면 위에서 설명하다시피 embedded device에서는 과도한 performance를 요구하게 된다.. 그래서 나눈 것이 사전검증(pre-verify)과 실행 시 검증(verify)이다. 즉 OFF-Line 사전검증 과 ON-Line 검증인 것이다. 

<그림 2>를 보도록 하자. MyApp.java라는 애플리케이션을 작성한 후에 컴파일을 수행하면, MyApp.class라는 클래스 파일을 얻을 수 있다. 이 클래스 파일은 자바 가상머신 명세서에 정의된 클래스 파일 포맷을 따른다. 이 클래스 파일을 사전검증기(preverifier)를 통해 사전검증을 하게 되면, 변경된 MyApp.class 파일을 얻게 된다. 이 때, 이 클래스 파일은 CLDC 명세서에 정의된 클래스 파일 포맷을 따르게 된다. 이렇게 사전검증된 클래스 파일을 디바이스에서 다운로드하여 로딩한 후에는 온-디바이스 검증을 수행한다.

[ 그림 2 - 클래스 파일 검증 과정 ]

검증 과정은 프로그램 코드의 네트웍 이동성을 보장하는 자바 가상머신의 안전장치이다. 
즉, 검증 과정을 통해서 자바 가상머신은 애플리케이션이 특정한 규칙을 따르고 있음을 확인하고, 이 애플리케이션의 수행이 안전함을 보장할 수 있다. 이것은 애플리케이션이 허락되지 않은 위험한 작업을 수행하지 못하도록 함으로써, 시스템의 안정성을 확보하고, 바이러스 등의 위해한 애플리케이션의 등장을 방지할 수 있게 해 준다. 그러나, 검증 알고리즘을 구현하는 것은 약 50K 정도의 코드 공간이 필요하고, 기존의 검증 과정은 실행시 오버헤드도 크다. 그래서, 사전검증과 실행시 검증이라는 새로운 방법을 CLDC에서 도입한 것이다. 
이러한 검증방법을 안전하고 유효하게 만들기 위해서는 몇가지 복잡한 고려를 해야 한다. 그 중에서도 가장 중요한 것은 클래스 파일포맷의 변화이다. 온-디바이스 검증기가 정상적으로 검증을 수행하기 위해서는 사전검증기가 이에 필요한 추가정보를 클래스 파일에 포함시켜야 하고, ‘스택 맵 애트리뷰트’라고 불리는 이러한 추가적인 애트리뷰트를 통해 온-디바이스 검증기는 효율적인 검증을 수행할 수 있다. 추가적인 애트리뷰트로 인해 클래스 파일의 크기는 약 5% 정도 늘어나게 되지만, 온-디바이스 검증기의 크기를 효과적으로 줄일 수 있고, 검증시에 재귀적인 검증을 하지 않고, 1패스 검증을 할 수 있다는 측면에서는 상당한 향상이 있었다고 평가할 수 있다. 

다음은 위에서 설명한 사전검증과 실행시 검증으로 분리된 검증방법의 특징들이다.
 오프-디바이스에서 공간절약적인 처리(스택 맵 생성, 복잡한 바이트코드 제거)
 온-디바이스에서 정확성 체크 : 스푸핑이 불가능
 코드 사이닝이 필요없음(원시적인 모래상자 보안모델 사용)
 온-디바이스 풋프린트 약 10K 요구, 런타임시 상수 공간 100바이트 이하 필요, 선형 처리(재귀적이지 
  않은 1패스 처리)를 통한 검증시간 절약

3) 클래스의 로딩과 링킹
  CLDC 명세는 JAR(Java ARchive) 파일 포맷을 지원을 강제하고, MIDP 명세는 클래스 파일의 배포를 반드시 JAR(Java ARchive) 파일을 통해서만 이루어 지도록 하고 있다. 이것은 JAR 파일의 사용이 약 30~40% 정도의 대역폭 절감 효과가 있기 때문이다. 물론, 이 때 배포되는 JAR 파일에 포함된 클래스 파일들은 사전검증기에 의해 사전검증이 된 클래스 파일이어야 함은 당연하다. 

로딩이란 애플리케이션에서 사용하고자 하는 클래스 파일들을 자바 가상머신으로 전달하는 과정을 말한다. CLDC에서는 JAR 파일의 형태로 네트웍을 통해 전송된 클래스 파일들이 시스템 클래스 로더에 의해 로딩된다. 링킹은 로딩된 클래스 파일, 즉, 바이너리 코드가 자바 가상머신에 의해서 수행될 수 있는 상태로 만드는 과정이다. 이 과정은 로딩된 클래스가 올바른 클래스 포맷을 가지고 있는 지 실행시 검증을 하는 검증(verification) 과정과, 메모리 영역의 할당 등의 예비 과정(preparation), 심볼릭 참조 주소를 직접 참조 주소로 변환하는 결정 과정(resolution) 등으로 세분화할 수 있다. 이 때, 보안상의 이유와 애플리케이션 관리 소프트웨어의 존재로 인해 클래스 파일의 룩업순서가 조금 다르며, 사용자 정의 클래스 로더를 만들 수 없다는 것도 CLDC의 특징이다. 

여기서 한가지 강조하고 싶은 문제는 CLDC 디바이스는 대부분 파일시스템이 없다는 것이다. 그러므로, CLDC 명세도 파일시스템에 대한 고려를 하지 않고 있다. 즉, 플래시 메모리를 주 저장장치로 사용하는 CLDC 디바이스의 경우에, 저장공간은 ROM이 아니면 RAM이라는 것이다. 일반적으로 파일 시스템이 보조 기억장치로서 존재하는 PC 시스템의 경우, 자바 가상머신이 수행될 때, 먼저 자바 가상머신이 파일 시스템으로부터 메모리로 올려 진다. 그리고, 클래스 로더가 필요한 시스템 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그리고 나서, 필요한 사용자 정의 클래스 파일들을 파일시스템으로부터 메모리로 로딩한다. 그런데, CLDC 디바이스에서는 가상머신과 시스템 클래스 파일들이 이미 메모리에 존재한다. 그런데, 굳이 로딩과 링킹, 초기화라는 불필요한 절차를 거칠 필요가 있을까? 로마이징(ROMizing)은 이처럼 특정 클래스들을 사전에 미리 로딩하고 링킹해 놓음으로써 애플리케이션의 속도 향상을 가져올 수 있는 기법을 의미한다. CLDC 명세에서는 사전로딩/사전링킹을 통한 로마이징을 구현에 의존적인 기능으로 정의하고 있다. 

4) CLDC 라이브러리
  자바와 관련한 신기술이 발표될 때 마다, 함께 쏟아져 나오는 API들은 늘 신선함과 함께 부담감으로 작용한다. 필자는 개인적으로 선이 이룩한 가장 기념비적인 업적 중의 하나가 javadoc이라는 문서화 툴의 확산이라고 생각한다. 만일, 그토록 많은 API들의 홍수 속에 살면서, javadoc에 의한 편리하고, 보편적인 문서화가 이루어지지 않았다면, 많은 사람들이 자바를 외면했을 것이라는 생각을 해 본다. 그럼에도 불구하고, 매번 새로운 API를 접하는 것은 상당히 부담스러운 일이다. 그러므로, CLDC에서도 가능하면 모든 API들이 기존의 J2SE API의 서브셋이기를 바라는 것이 자바 개발자들의 공통된 요구일 것이다. 하지만, MIDP를 통해서 더욱 확실히 느끼게 되겠지만, 기존 API와의 호환성은 잊어버리는 게 좋을 정도로 많은 API들이 재정의되었다. 재사용 가능한 API들이라고는 다음 세 가지의 패키지들 중에서도 일부일 뿐이다. 각각의 패키지에 포함된 클래스들은 [표 2]에 정리하였다. 

java.lang 패키지
java.util 패키지
java.util 패키지
시스템 클래스 
java.lang.Object 
java.lang.Class 
java.lang.Runtime 
java.lang.System 
java.lang.Thread 
java.lang.Runnable 
java.lang.String 
java.lang.StringBuffer 
java.lang.Throwable 

데이터 타입 클래스
 
java.lang.Boolean 
java.lang.Byte 
java.lang.Short 
java.lang.Integer 
java.lang.Long 
java.lang.Character 

수학 클래스 
java.lang.Math
컬렉션 클래스 
java.util.Vector 
java.util.Stack 
java.util.Hashtable 
java.util.Enumeration 

날짜관련 클래스 
java.util.Calendar 
java.util.Date 
java.util.TimeZone 

유틸리티 클래스 
java.util.Random 

입출력 클래스 
java.io.InputStream 
java.io.OutputStream 
java.io.ByteArrayInputStream 
java.io.ByteArrayOutputStream 
java.io.DataInput 
java.io.DataOutput 
java.io.DataInputStream 
java.io.DataOutputStream 
java.io.Reader 
java.io.Writer 
java.io.InputStreamReader 
java.io.OutputStreamWriter 
java.io.PrintStream
[ 표 2 - CLDC 라이브러리 ]

5) 프로퍼티
  [표 2]에서 java.util.Properties를 찾아 보면 찾을 수 없을 것이다. 즉, CLDC에서는 프로퍼티 기능을 지원하지 않는다는 것이다. 다만, System.getProperty(String key) 메소드를 통해서 시스템 프로퍼티에 접근할 수는 있다. 하지만, setProperty() 메소드는 지원되지 않는다는 것을 확인하기 바란다. 그러므로, 애플리케이션 개발자는 시스템 프로퍼티를 변경하거나 새로운 프로퍼티를 생성할 수는 없다. [표 3]은 CLDC에서 정의하는 시스템 프로퍼티들이다. MIDP에서는 지역화를 고려하여 locale 프로퍼티를 추가하였다. 

명세서
프로퍼티 키
설 명
CLDC
microedition.platform 호스트 플랫폼 혹은 디바이스의 이름 BI-Generic
CLDC
microedition.encoding 디폴트 캐릭터 인코딩 EUC-KR
CLDC
microedition.configuration 지원 컨피큐레이션 이름-버전 CLDC-1.0
CLDC
microedition.profiles 지원 프로파일 이름-버전 MIDP-1.0
MIDP
microedition.locale 디바이스의 현재 로캘 ko-KR
[ 표 3 - 시스템 프로퍼티 ]

6) 국제화/지역화
  국제화/지역화의 지원은 아직 CLDC/MIDP에서는 제대로 지원을 보장하지 못하고 있다. CLDC에서 유니코드 문자를 바이트로 변환해 주는 변환기를 제한적으로 지원할 뿐이다. 이러한 국제화 지원은 Reader와 Writer를 통해서 이루어지고, 각각에 대해서는 다음과 같은 생성자에서 두 번째 인자로 인코딩 방법을 지정함으로써 코드 변환을 할 수 있다. 

    new InputStreamReader(InputStream is, String name) 
    new OutputStreamWriter(OutputStream os, Striing name) 

ISO8859_1 이외의 인코딩 방법에 대해서는 기본적으로 CLDC/MIDP 구현자에게 의존적이며, 날짜, 시간, 통화 등의 포맷에 관련한 지역화에 대해서도 MIDP 구현에 의존적이다. 국제화/지역화 문제는 <표 3>에서와 같이 시스템 프로퍼티에 한글 인코딩과 한국의 로캘을 지정하고, 코드 변환기와 포맷 변화기가 완전히 구현되어야 한다. 선 마이크로시스템즈의 CLDC 1.0 베타와 MIDP Early Access 1에서는 한글 및 지역화 지원이 완벽하지 않다고 한다. 그러나 조만간에 이 문제는 해결이 될 것이라 생각된다. 

7) 애플리케이션 관리 메커니즘
  이 글의 서두에서 모바일 솔루션으로서의 자바의 특장점 중의 하나가 애플리케이션의 동적인 다운로드 기능이라고 했다. 자바 애플릿을 떠올린 분들이 많으실텐데, 이것은 커다란 오해다. CLDC/MIDP 플랫폼에서는 완전히 새로운 애플리케이션 모델을 제시하고 있다. ‘애플리케이션 관리 소프트웨어’라고 불리는 새로운 소프트웨어의 등장은 애플릿과 애플리케이션의 혼합, 혹은 자바 플러그-인의 확장이라고 할 수 있는, 새롭지만, 그리 낯설지 않은 애플리케이션의 배포와 관리 메커니즘을 제공하고 있다. CLDC는 단지 이러한 애플리케이션 관리 소프트웨어의 존재에 대해서만 가정하고 있으며, 실질적인 애플리케이션 모델에 대한 정의는 MIDP에서 이루어 지고 있으므로, 나중에 이 부분을 자세히 살펴보도록 하자.

8) Generic Connection Framework
  CLDC에서는 확장 패키지에 포함될 클래스를 정의하는 부분이 있다. javax.microedition.io 패키지가 그것인데, 여기에는 Generic Connection Framework(이하, 커넥션 프레임웍)이라고 이름이 붙은 네트워킹과 입출력에 대한 상위 수준의 프레임웍에 대한 인터페이스 정의가 포함되어 있다. 

왜 전혀 새로운 네트워킹과 입출력 프레임웍을 정의해야만 했는가? 이에 대한 해답은 다시 메모리의 제약으로 돌아간다. 기존의 java.net 패키지와 java.io 패키지는 덩치가 너무 크다. 100개 이상의 클래스와 200K 이상의 크기를 가진 이 패키지들은 CLDC 디바이스들에는 적합하지 않다. 게다가, TCP/IP, WAP, iMode, IrDA, Bluetooth라는 새로운 통신방법에 대한 지원과, 파일 시스템이 존재하지 않는 입출력 메커니즘을 하나로 통합할 필요성이 존재했다. 그리고, 그 방법으로 새로운 프레임웍의 정의를 선택한 것이다. 다음은 커넥션 프레임웍의 설계목표이다. 
 서로 다른 형태의 입출력 형태를 일관성있게 지원한다.
 서로 다른 형태의 프로토콜을 일관성있게 지원한다.
 애플리케이션의 포터빌리티를 향상시킨다.
 표준 자바 클래스 라이브러리와의 상위 호환성을 가진다.
 더 작은 메모리 풋프린트를 가진다.

CLDC의 커넥션 프레임웍은 네트웍과 입출력을 포함한 모든 연결의 생성에 대해서 다음과 같은 형태의 일관성을 제공한다. 

Connector.open(“<protocol>:<address>”); 

이 일관성의 핵심은 Connector 클래스만으로 모든 연결을 생성할 수 있으며, open() 메소드의 인자를 변경함으로써 연결의 형태를 바꿀 수 있다는 데에 있다. 연결이 성공적이었다면, open() 메소드는 커넥션 프레임웍의 인터페이스들을 구현한 클래스의 인스턴스를 리턴한다. <그림 3>은 커넥션 프레임웍의 계층도에 대해 보여주고 있다. 그리고, <표 5>는 Connector 클래스를 이용해서 여러 프로토콜의 연결을 생성하는 예를 보여주고 있다.
통신 방법
연결 예제
HTTP 레코드 Connector.open(“http://www.javaline.co.kr”)
FTP 레코드 Connector.open(“ftp://www.javaline.co.kr”);
소켓 Connector.open(“socket://10.1.7.1:9192”)
커뮤니케이션 포트 Connector.open(“comm:9600:18N”)
데이터그램 Connector.open(“datagram://10.1.7.1”)
파일 Connector.open(“file:/maso.doc”)
네트웍 파일 시스템 Connector.open(“nfs:/10.1.7.1/maso.doc”)
적외선 통신
Connector.open(“irda://”)
[ 표 4 - 프로토콜별 연결생성 예 ]

한 가지 분명히 해 두어야 할 것은 CLDC는 Connector 클래스를 포함해서, 어떠한 실제 구현에 대한 명세도 포함하지 않는다는 점이다. 커넥션 프레임웍은 단지 프레임웍만을 제공할 뿐, 실질적으로 지원할 프로토콜에 대한 정의와 구현은 프로파일의 몫이며, MIDP에서는 HTTP 프로토콜의 지원에 대해서 정의하고 있다. MIDP의 HTTP 지원은 나중에 다시 살펴보도록 하자.
IONETKOREA E&D 연구소 제공 
Posted by 1010
01.JAVA/J2me2008. 9. 24. 14:27
반응형

Java의 모든 원천 기술은 Sun Microsystems에서 갖고 있으며 다음과 같이 총 3가지 스펙으로 나누어 집니다.   

   ① J2EE (Java 2 Platform, Enterprise Edition)
   ② J2SE (java 2  Platform, Standard Edition)
   ③ J2ME (Java 2 Platform, Micro Edition) 

입니다.

그 중에 J2ME는 엔터프라이즈급을 위한 J2EE와, 일반 PC를 위한 J2SE에 바탕을 두고 
정의되었으며, 휴대폰이나 PDA 셋톱박스처럼 휴대용의 작은 기기에 적합한, 동적인 네트웍크 
기반의 어플리케이션을 개발 할 수 있도록 설계되었습니다.

그러면 이제 J2ME를 세분화 해 보도록 하겠습니다.
J2ME를 세분화 하면 다음과 같이 총 3 가지로 세분화 할 수 있습니다.

   ① CVM
   ② KVM
 
  ③ Card VM

위와 같이 3가지로 세분화 시켜놓은 것은 VM(Virtual Machine) 에 따라서 구분을 해 놓은 것입니다.

다시 위의 3가지를 자세하게 설명하면 다음과 같습니다.

   ▣ CVM (Classic Virtual Machine)
CVM은 디지털 셋탑박스, TV등을 위한 컨피규레이션인 CDC(Connected Device Configuration)와 Personal Profile, Foundation Profile, Personal Basis Profile 로 구성됩니다.CVM은 32비트 이상의 프로세서를 가진 디바이스에서 사용됩니다.

즉 CVM 은 밑에서 설명할 KVM을 사용하는 디바이스 보다 덜 제한적인, 즉 조금 더 큰 용량의 디바이스에서 이용될 수 있습니다.

   ▣ KVM (Kilobyte Virtual Machine)   
소형 컴퓨팅 장비들을 위한 J2ME 의 가상 머신입니다. 이 KVM은 휴대폰 이나 PDA , 페이져 등을 위한 컨피규레이션인 CLDC(Connected, Limited Device Configuration)와  MIDP(Mobile Information Device Profile)로 이루어져 있습니다.

   ▣ Card VM
자바 카드를 위한 VM 입니다.

자 ~ ! 위와 같이 정리를 해 놓고 보니 이제 J2ME 라는 녀석이 한눈에 들어오는 느낌이 드실겁니다. 그러면 이제는 우리가 앞으로 집중적으로 공부를 해야할 KVM에 대해서 조금만 더 알아봅시다.

KVM은 휴대폰을 위한 스펙으로 J2ME를 대표하는 솔루션으로 세계 무선 인터넷 플랫폼 시장에서 그 위치가 확고하다고 볼 수 있습니다. 우리나라에서도 SK 텔레콤과 LG텔레콤을 통해 제공되고 있으며, 또한 우리나라에서 독자적으로 개발한 "대한민국 무선 인터넷 플렛폼 "WIPI" 와도 100 % 호환됩니다.

즉 한번 작성한 J2ME 어플리케이션은 자바를 지원하는 전 세계의 대부분의 폰에서 그대로 작동되는 이점을지니고 있다는 겁니다.

CLDC와 MIDP 에 대한 간단한 설명은 다음과 같습니다

CLDC 는 Connected Limited Device Configuration 의 약자 입니다.

여기서 맨 마지막 단어인 Configuration 은 비슷한 특성을 가지는 디바이스들이 
가져야될 최소한의 요구사항에 대한 정의 라고 할 수 있습니다.

즉 J2ME자체가 모바일과 같은 제한된 환경의 디바이스들을 위한 표준 스펙이라고 한다면, 다시 그 J2ME 내부에서도 핸드폰과 같은 아주 극한된 환경을 가지고 있는 디바이스들이 가져야 될 최소한의 요구사항을 정의하는 Configuration을 CDDC라고 하고, 핸드폰보다는 좀 더 여유로운 환경을 가지고 있는 셋톱박스와 같은 디바이스 내에서  가져야 할 최소한의 요구사항을 정의하는 Configuration을 CDC 라고 합니다.

이제 CLDC를 좀 더 살펴보도록 하겠습니다.

CLDC가 대상으로 하는 디바이스에는 핸드폰 이나 PDA, 양방향페이져 등이 있습니다.
이들은 모두 네트워크에 연결될 수 있고, 극히 제한적인 리소스를 가진 디바이스라는
공통점이 있습니다. 하지만 이러한 공통점 만으로 이들을 하나의 범주로 묶을 수는 없습니다.
예를 들면 핸드폰과 양방향 페이져 등은 디스플레이 창의 크기도 다르며, 사용자의 입력을
처리하는 방법도 천차만별입니다.

즉 공통적인 특성을 가진 디바이스라 할지라도 특정 부분에 대해서는 다른 특성을 가진다는
사실은 어쩔 수 없는 것입니다. 즉 이러한 차이점을 Profile 인 MIDP가 맡게 되는 겁니다.

다시한번 말씀드린다면 Configuration은 최소한의 정의만 하고, 실제 구현이나 확장은
Profiles 에서 담당한다고 할 수 있는 겁니다.

Posted by 1010