Overview   Package  Class  Use  Tree  Deprecated  Index  Help 
MID 프로필
 PREV PACKAGE   NEXT PACKAGE FRAMES    NO FRAMES    

Package javax.microedition.lcdui

UI API는 MIDP 응용 프로그램의 사용자 인터페이스 구현을 위한 기능 집합을 제공합니다.

See:
          Description

Interface Summary
Choice Choice는 미리 정의된 선택 항목 개수에서 선택 사항을 구현하는 사용자 인터페이스 구성 요소에 대한 API를 정의합니다.
CommandListener 이 인터페이스는 구현 시 높은 수준의 이벤트를 받아야 하는 응용 프로그램에서 사용합니다.
ItemCommandListener Item 객체에서 호출된 명령 통지를 받기 위한 수신기 유형.
ItemStateListener 이 인터페이스는 Form 화면에서 대화식 항목의 내부 상태 변경을 나타내는 이벤트를 받아야 하는 응용 프로그램에서 사용합니다.
 

Class Summary
Alert 경고는 다음 Displayable로 이동하기 전에 사용자에게 데이터를 표시하고 특정 시간 동안 대기하는 화면입니다.
AlertType AlertType은 경고의 특징을 표시합니다.
Canvas Canvas 클래스는 낮은 수준의 이벤트를 처리하고 디스플레이로 이동하기 위한 그래픽을 호출해야 하는 응용 프로그램을 작성하기 위한 기본 클래스입니다.
ChoiceGroup ChoiceGroup은 Form 내에 놓을 선택 가능한 요소 그룹입니다.
Command Command 클래스는 작업의 의미 정보를 캡슐화하는 구조입니다.
CustomItem CustomItem은 새로운 시각적 요소 및 대화식 요소를 Forms에 도입하기 위해 클래스 세분화를 통해 사용자 정의할 수 있습니다.
DateField DateField는 Form에 넣을 수 있는 날짜와 시간(달력) 정보를 나타내기 위한 편집 가능한 구성 요소입니다.
Display Display는 시스템의 입력 장치 및 디스플레이 관리자를 나타냅니다.
Displayable 디스플레이에 놓일 수 있는 기능을 보유한 객체입니다.
Font Font 클래스는 글꼴 및 글꼴 메트릭을 나타냅니다.
Form Form은 이미지, 읽기 전용 텍스트 필드, 편집 가능 텍스트 필드, 편집 가능 날짜 필드, 게이지, 선택 그룹 및 사용자 정의 항목 등의 임의 혼합을 포함하는 Screen입니다.
Gauge 정수 값의 그래픽 디스플레이(예: 막대 그래프)를 구현합니다.
Graphics 단순한 2D 기하 렌더링 기능을 제공합니다.
Image Image 클래스는 그래픽 이미지 데이터를 보관하는 데 사용됩니다.
ImageItem 이미지를 포함할 수 있는 항목입니다.
Item Form에 추가할 수 있는 구성 요소의 수퍼 클래스.
List 선택 목록을 포함하는 Screen.
Screen 고급 사용자 인터페이스 클래스의 공통 수퍼 클래스.
Spacer 설정 가능한 최소 크기를 가진 비어 있는 비대화식 항목.
StringItem 문자열을 포함할 수 있는 항목.
TextBox TextBox 클래스는 사용자가 텍스트를 입력하고 편집할 수 있는 Screen입니다.
TextField TextField는 Form에 들어갈 수 있는 편집할 수 있는 텍스트 구성 요소입니다.
Ticker 디스플레이에 텍스트의 일부가 계속하여 지나가는 "티커 테이프"를 구현합니다.
 

Package javax.microedition.lcdui Description

UI API는 MIDP 응용 프로그램의 사용자 인터페이스 구현을 위한 기능 집합을 제공합니다.

사용자 인터페이스

MIDP의 주된 개념은 모바일 정보 장치(예: 모바일 폰 및 호출기)를 기반으로 설계되었습니다. 이러한 장치는 특히 사용자가 장치와 상호 작용하는 방법을 포함하여 여러 면에서 데스크탑 시스템과는 다릅니다. 다음은 사용자 인터페이스 API를 설계할 때 중요한 UI 관련 요구 사항입니다.

MIDP를 구현할 장치의 기능과 위의 요구 사항을 고려하여, MIDPEG에서는 Abstract Windowing Toolkit (AWT)인 기존 Java UI의 단순한 하위 집합은 사용하지 않기로 했습니다. 그 이유는 다음과 같습니다.

MIDP UI API의 구조

MIDP UI는 논리적으로 고급과 저급의 두 개 API로 구성되어 있습니다.

고급 API는 클라이언트 부분이 MID에서 실행되는 비즈니스 응용 프로그램용으로 개발되었습니다. 이러한 응용 프로그램의 경우 장치간 이식성이 중요합니다. 이식성을 확보하기 위해 고급 API에서는 추상화 수준을 높이고 모양 및 색감에 대한 제어는 거의 제공하지 않습니다. 이러한 추상화는 다음과 같은 방법으로 구체화됩니다.

즉, 고급 API를 사용하면 기본 구현 시 해당 장치의 하드웨어와 고유 UI 스타일에 필요한 적응 작업을 수행하는 것으로 가정합니다. 고급 API를 제공하는 클래스는 Screen의 서브 클래스입니다.

반면 저급 API는 추상화를 거의 제공하지 않습니다. 이 API는 정확한 배치와 그래픽 요소의 제어뿐만 아니라 저급 입력 이벤트에 대한 액세스를 필요로 하는 응용 프로그램을 위해 개발되었습니다. 일부 응용 프로그램은 장치별로 다른 특수한 기능에 액세스해야 할 때도 있습니다. 이러한 응용 프로그램의 일반적은 예로는 게임을 들 수 있습니다.

저급 API를 사용하면 응용 프로그램은 다음을 수행할 수 있습니다.

저급 API를 제공하는 클래스는 Canvas 및 Graphics입니다.

저급 API는 특정 장치에만 있는 세부 정보에 액세스할 수 있는 방법을 제공하므로 저급 API로 프로그램한 응용 프로그램은 이식성이 보장되지 않습니다. 응용 프로그램이 이러한 기능을 사용하지 않는 경우에는 이식 가능합니다. 응용 프로그램에서는 가능하면 저급 API의 플랫폼 독립적인 부분만을 사용하는 것이 좋습니다. 즉, 응용 프로그램은 Canvas 클래스에서 정의된 키 이외의 다른 키가 있다고 직접적으로 가정해서는 안되며 특정 화면 크기에 의존해서도 안 됩니다. 구체적 키가 아닌 응용 프로그램 게임 키 이벤트 매핑 기법을 사용해야 하며 응용 프로그램은 디스플레이의 크기를 조회하고 그에 따라 조정해야 합니다.

클래스 계층

MIDP UI 추상화의 핵심은 Displayable 객체이며, 이 객체는 사용자 입력을 사용하여 장치별로 다른 그래픽 렌더링을 캡슐화합니다. 한 번에 하나의 Displayable만 표시할 수 있으며 사용자는 해당 Displayable의 내용만을 보고 상호 작용할 수 있습니다.

Screen 클래스는 고급 사용자 인터페이스 구성 요소와의 모든 사용자 상호 작용을 다루는 Displayable의 서브 클래스입니다. Screen 서브 클래스는 응용 프로그램에 전달되는 고급 이벤트만을 사용하여 렌더링, 상호 작용, 순회, 스크롤을 처리합니다.

이렇게 설계한 이유는 MIDP 장치에 여러 가지 디스플레이와 입력 솔루션이 있기 때문입니다. 이러한 차이점은 구성 요소 레이아웃, 스크롤 및 초점 순회가 장치마다 다르게 구현된다는 것을 의미합니다. 응용 프로그램이 이러한 문제를 인식해야 한다면 이식성이 손상될 수 있습니다. 단순한 화면은 사용자 인터페이스를 관리 가능한 조각으로 구성하여 사용자 인터페이스를 사용하고 배우기 쉽게 해줍니다.

Displayable 객체에는 다음과 같은 3개의 범주가 있습니다.

각 Displayable에는 제목, Ticker 및 Command 집합을 연결할 수 있습니다.

Display 클래스는 각 활성 MIDlet에 대해 인스턴스화되는 디스플레이 관리자로 작동하며 장치의 디스플레이 기능에 대한 정보를 검색하는 메소드를 제공합니다. Displayable은 Display의 setCurrent() 메소드를 호출하여 표시할 수 있습니다. Displayable이 활성 상태가 되면 이전 Displayable을 대체합니다.

클래스 개요

대부분의 응용 프로그램은 List , TextBox 및 Alert와 같은 미리 정의된 구조를 사용하여 화면을 사용합니다. 이러한 클래스는 다음과 같은 방법으로 사용됩니다.

특수 클래스 Form은 미리 정의된 구조가 있는 화면이 충분하지 않은 경우에 정의됩니다. 예를 들어, 응용 프로그램은 2개의 TextField, 또는 TextField 하나와 단순 ChoiceGroup 하나를 가질 수 있습니다. 이 클래스(Form)를 사용하면 임의로 조합된 구성 요소를 작성할 수 있지만 개발자는 제한된 디스플레이 크기를 염두에 두고 단순 Form만을 작성해야 합니다.

Form은 소수의 밀접하게 연관된 UI 요소를 포함하도록 설계되었습니다. 이러한 요소는 Item의 서브 클래스이며 ImageItem, StringItem, TextField, ChoiceGroup, Gauge, CustomItem 등이 있습니다. ImageItem과 StringItem 클래스는 Form 및 Alert에 대한 특정 작업을 더 쉽게 해주는 일반 클래스입니다. CustomItem을 서브 클래스화하여 응용 프로그램 개발자는 새로운 시각적 표현과 대화식 요소가 있는 Item을 생성할 수 있습니다. 구성 요소가 화면에 완전히 맞지 않으면 구현 시 양식을 스크롤 가능하게 만들거나, 사용자가 편집할 때 일부 구성 요소는 새 화면에서 팝업되거나 확장되도록 구현할 수 있습니다.

응용 프로그램 관리자와의 상호 작용

API의 다른 자원처럼 사용자 인터페이스는 MIDP 응용 프로그램 관리 원칙에 따라 제어됩니다. UI는 응용 프로그램 관리 소프트웨어에서 다음 조건에 부합해야 합니다.

응용 프로그램 관리자는 응용 프로그램이 MIDlet 이벤트와 관련하여 다음과 같이 작동할 것으로 가정합니다.

이벤트 처리

사용자 상호 작용에 의해 이벤트가 발생하면 구현 시 해당 콜백을 만들어 응용 프로그램에 이벤트에 대해 통지합니다. UI 콜백에는 4가지 종류가 있습니다.

모든 UI 콜백은 일련화되므로 동시에 발생하지 않습니다. 즉, 다른 모든 콜백에 대한 이전 호출이 반환되기 전에는 새로운 콜백을 호출하지 않습니다. 이러한 특성으로 인해 응용 프로그램은 다음 이벤트를 전달하기 전에 이전의 사용자 이벤트 처리를 완료할 수 있습니다. 여러 UI 콜백이 보류 중이면 이전 UI 콜백이 반환된 직후에 다음 콜백을 호출합니다. 또한 callSerially() 호출에 의해 요청된 run() 호출은 보류 중인 모든 다시 그리기 요청이 충족된 후에 수행되도록 합니다.

콜백 일련화 규칙에는 한 가지 예외가 있는데 이는 Canvas.serviceRepaints 메소드가 호출될 때 발생합니다. 이 메소드는 Canvas.paint 메소드를 호출하며 이 메소드가 완료되기를 기다립니다. serviceRepaints의 호출자가 활성 콜백에 있는 경우에도 발생합니다. 다음은 이 문제에 대한 추가 논의 사항입니다.

다음 콜백은 서로 모두 일련화되어 있습니다.

Timer 이벤트는 UI 이벤트가 아닙니다. 같은 Timer에 예약된 TimerTask 콜백은 서로 일련화되지만 타이머 콜백은 UI 이벤트 콜백과 동시에 실행될 수 있습니다. 타이머를 사용하는 응용 프로그램은 타이머 스레드와 UI 이벤트 콜백이 데이터 구조에 동시에 액세스하지 않도록 해야 합니다. 또는 응용 프로그램은 타이머 콜백이 타이머 이벤트에 의해 트리거된 작업을 UI 이벤트 콜백과 함께 일련화할 수 있도록 Display.callSerially를 사용할 수도 있습니다.

추상 명령

MIDP UI는 매우 추상적이므로 소프트 버튼이나 메뉴와 같은 구체적인 사용자 상호 작용 기법을 지시하지는 않습니다. 또한 순회나 스크롤과 같은 저급 사용자 상호 작용은 응용 프로그램에 보이지 않습니다. MIDP 응용 프로그램은 Command를 정의하고 구현 시 소프트 버튼, 메뉴 또는 해당 장치에 적절한 모든 기법을 사용하여 이러한 명령을 명시할 수 있습니다.

Command는 Displayable 클래스의 addCommand 메소드를 사용하여 Displayable(Canvas 또는 Screen)에 설치됩니다.

장치의 고유 스타일에 따라 특정 유형의 명령이 정해진 위치에 배치됩니다. 예를 들어, "go-back" 작업은 항상 오른쪽 소프트 버튼으로 매핑될 수 있습니다. Command 클래스를 사용하면 구현 시 이러한 의미를 전달하여 표준 매핑이 유효하게 됩니다.

구현 시 Command의 의미를 실제로 구현하지는 않습니다. Command의 속성은 이를 사용자 인터페이스에 매핑하는 데에만 사용됩니다. Command의 실제 의미는 항상 응용 프로그램에 의해 CommandListener에서 구현됩니다.

Command 객체에는 다음과 같은 속성이 있습니다.

장치에서 제공하는 작업

많은 고급 UI 클래스에는 사용자 인터페이스에서 사용할 수 있는 몇몇 추가 작업도 있습니다. 추가 작업은 응용 프로그램에는 보이지 않고 최종 사용자에게만 보입니다. 사용할 수 있는 작업 집합은 특정 장치의 사용자 인터페이스 설계에 따라 전적으로 다릅니다. 예를 들어, ITU-T 키패드만 있는 장치에서는 사용자가 영숫자와 숫자 간에 텍스트 입력 모드를 변경할 수 있는 작업이 필요합니다. 보다 복잡한 입력 시스템에서는 추가 작업이 필요합니다. 사용 가능한 몇몇 작업은 응용 프로그램이 정의한 명령과 같은 방법으로 사용자 인터페이스에 제공되어 있습니다. 최종 사용자는 어떤 작업을 응용 프로그램에서 제공하고 어떤 작업을 시스템에서 제공하는지 알 필요가 없습니다. 모든 작업을 모든 구현에서 사용할 수 있는 것은 아닙니다. 예를 들어, 단어 조회 기반 텍스트 입력 구조를 사용하는 시스템에서는 일반적으로 TextBox 클래스 내에 추가 작업을 제공합니다. 이러한 입력 방법이 부족한 시스템에는 해당하는 작업도 부족하게 됩니다.

일부 작업은 모든 장치에서 사용할 수 있지만 작업이 구현되는 방법은 장치마다 크게 다를 수 있습니다. 이러한 작업의 종류에는 List 요소와 Form 항목 간의 이동에 사용되는 기법, List 요소의 선택, 텍스트 편집기 내에서 삽입 위치를 이동하는 작업 등이 있습니다. 일부 장치에서는 Item 값을 직접 편집할 수 없으며 대신 사용자가 오프스크린 편집기로 전환해야 합니다. 이러한 장치에서는 오프스크린 편집기를 호출하는 데 사용할 수 있는 전용 선택 작업이 있어야 합니다. 예를 들어, List 요소의 선택은 전용 "Go" 또는 "Select" 또는 기타 유사한 키를 사용하여 구현할 수 있습니다. 일부 장치에는 전용 선택 키가 없으므로 다른 방법을 사용하여 요소를 선택해야 합니다.

전용 선택 키를 사용하여 선택 작업을 수행하는 장치에서는 이 키에 표시되는 레이블이 없을 때도 있습니다. 구현 시 키의 의미가 명확한 때에만 이 키를 사용하는 것이 좋습니다. 예를 들어, 사용자에게 상호 배타적인 옵션 집합이 제공되는 경우 선택 키는 반드시 이러한 옵션 중 하나를 선택하게 됩니다. 그러나 전용 선택 키가 없는 장치에서는 레이블을 필요로 하는 소프트 키를 사용하여 선택 작업을 수행하게 될 수도 있습니다. 응용 프로그램이 이 작업에 레이블을 설정하고 이 작업이 발생하면 통지를 받을 수 있도록 IMPLICIT 유형의 List에 선택 명령을 설정하는 기능과 Item에 기본 명령을 설정하는 기능이 제공됩니다.

이벤트용 고급 API

고급 API에서 이벤트 처리는 수신기 모델을 기반으로 합니다. Screen 및 Canvas는 명령에 대한 수신기를 가질 수 있습니다. 수신기가 되려고 하는 객체는 하나의 메소드가 있는 CommandListener 인터페이스를 구현해야 합니다.


    void commandAction(Command c, Displayable d);

응용 프로그램에서는 Screen 또는 Canvas가 Command와 연결되고 등록된 수신기가 있는 경우 이러한 이벤트를 받게 됩니다. Screen 또는 Canvas는 유니캐스트 버전의 수신기 모델이 사용되는 경우 한 번에 하나의 수신기만 가질 수 있습니다.

Form에는 Item의 상태 변경에 대한 수신기 인터페이스도 있습니다. 


    void itemStateChanged(Item item);

위 메소드는 ItemStateListener 인터페이스에 정의되어 있으며 대화식 Gauge, ChoiceGroup 또는 TextField의 값이 변경될 때 호출됩니다. 값이 변경될 때마다 매번 수신기가 호출되는 것은 아닙니다. 그러나 항목의 값이 변경되면 다른 항목에 대한 호출이 수행되기 전이나 Form의 CommandListener에 명령이 전달되기 전에 해당 변경에 대한 수신기가 호출됩니다. 따라서 최소한 필드에서 초점(또는 이에 상응하는 것)을 잃은 후에는 변경 수신기를 호출하는 것이 좋습니다. 수신기는 필드 값이 실제로 변경된 경우에만 호출해야 합니다.

이벤트용 저급 API

저급 그래픽과 이벤트에는 저급 키 이벤트를 처리하기 위한 다음과 같은 메소드가 있습니다. 


    public void keyPressed(int keyCode);    
    public void keyReleased(int keyCode);    
    public void keyRepeated(int keyCode);

마지막 호출인 keyRepeated는 모든 장치에서 사용 가능할 필요는 없습니다. 응용 프로그램은 Canvas의 다음 메소드를 호출하여 반복 작업의 사용 가능성을 확인할 수 있습니다.


    public static boolean hasRepeatEvents();

API를 사용하려면 ITU-T 키패드(0-9, *, #)에 대한 표준 키 코드가 있어야 하지만 키패드 레이아웃을 필요로 하지는 않습니다. 구현 시 추가 키를 제공할 수도 있지만 이러한 키에 의존하는 응용 프로그램은 이식이 불가능합니다.

또한 Canvas 클래스에는 추상 게임 이벤트를 처리하기 위한 메소드가 있습니다. 구현 시 이러한 모든 키를 장치에 있는 적합한 키에 매핑합니다. 예를 들어, 4방향 이동과 중앙에 선택 키가 있는 장치에서는 이러한 키를 사용할 수 있지만 더 단순한 장치에서는 숫자 키패드(예: 2, 4, 5, 6, 8)에서 특정 키를 사용할 수도 있습니다. 이러한 게임 이벤트를 사용하면 저급 이벤트를 사용하는 이식 가능한 응용 프로그램을 개발할 수 있습니다. API는 UP, DOWN, LEFT, RIGHT, FIRE, GAME_A, GAME_B, GAME_C 및 GAME_D와 같은 추상 키 이벤트 집합을 정의합니다.

응용 프로그램은 다음 메소드를 호출하여 키 이벤트를 추상 키 이벤트로 매핑할 수 있습니다. 


    public static int getGameAction(int keyCode);

응용 프로그램의 논리가 이 메소드에서 반환된 값을 기반으로 하는 경우 응용 프로그램은 이식 가능하며 키패드 설계와 상관없이 실행됩니다.

다음 메소드를 사용하여 추상 이벤트를 키에 매핑할 수도 있습니다.


    public static int getKeyCode(int gameAction);

여기서, gameAction은 UP, DOWN, LEFT, RIGHT, FIRE 등입니다. 일부 장치에서는 둘 이상의 키가 동일한 게임 작업에 매핑되는데 이러한 경우 getKeyCode 메소드는 이 중 하나만 반환합니다. 제대로 작성된 응용 프로그램은 키 코드를 추상 키 이벤트에 매핑하고 그 결과에 따라 결정을 내려야 합니다.

키와 추상 이벤트 간의 매핑은 게임을 실행하는 동안에는 변경되지 않습니다.

다음 예는 응용 프로그램이 게임 작업을 사용하여 키입력을 해석하는 방법을 보여 줍니다.

 
    class MovingBlocksCanvas extends Canvas {
        public void keyPressed(int keyCode) {
            int action = getGameAction(keyCode);    
            switch (action) {
            case LEFT:
                moveBlockLeft();
                break;
            case RIGHT:
                ...
            }
        }
    }

저급 API는 또한 포인터 이벤트를 지원하지만 모든 장치에서 다음과 같은 입력 기법을 제공하는 것은 아니기 때문에 일부 장치에서는 다음과 같은 콜백 메소드를 호출해서는 안 됩니다. 


    public void pointerPressed(int x, int y);
    public void pointerReleased(int x, int y);
    public void pointerDragged(int x, int y);

응용 프로그램은 Canvas 클래스의 다음 메소드를 호출하여 포인터의 사용 가능 여부를 확인할 수 있습니다. 


    public static boolean hasPointerEvents();
    public static boolean hasPointerMotionEvents();

고급 명령과 저급 API의 상호 작용

저급 이벤트와 그리기에 사용되는 Canvas 클래스는 Displayable의 서브 클래스이며 응용 프로그램은 여기에 Command를 연결할 수 있습니다. 이 명령은 게임 중간에 옵션 설정 Screen으로 이동하는 데 유용합니다. 또 다른 예로는 맵 기반 이동 응용 프로그램을 들 수 있으며, 이 경우 키는 맵에서 이동하는 데 사용하지만 명령은 고급 작업에 사용됩니다.

일부 장치에는 Canvas와 저급 이벤트 기법이 사용 중일 때 명령을 호출할 수 있는 방법이 없을 수도 있습니다. 이런 경우에는 구현 시 명령 모드로 전환하고 다시 되돌릴 수 있는 방법을 제공할 수 있습니다. 이 명령 모드는 Canvas의 내용 위에 메뉴를 팝업할 수 있습니다. 이런 경우 Canvas 메소드인 hideNotify() 및 showNotify()는 각각 Canvas를 숨기거나 표시할 때를 나타내기 위해 호출됩니다.

Canvas에는 Screen 객체와 같이 제목과 Ticker가 있을 수 있습니다. 그러나, Canvas에는 전체 화면 모드도 있는데 이 모드에서는 제목과 Ticker가 표시되지 않습니다. Canvas가 실제 디스플레이를 가능한 많이 차지하도록 할 때 이 모드를 설정합니다. 이 모드에서는 구현 시 제목을 팝업 메뉴의 제목으로 다시 사용할 수 있습니다. 전체 화면이 아닌 일반 모드에서는 응용 프로그램이 저급 Canvas 객체와 고급 Screen 객체 간에 전환할 때 시각적 연속성이 유지될 수 있도록 Canvas 모양이 Screen 클래스의 모양과 유사해야 합니다.

저급 API의 그래픽 및 텍스트

다시 그리기 방법

다시 그리기는 모든 Screen에서 자동으로 수행되지만 Canvas에서는 그렇지 않습니다. 그러므로 저급 API를 사용하는 개발자는 다시 그리기 방법을 이해해야 합니다.

저급 API에서는 여러 개의 다시 그리기 요청이 하나의 호출 내에서 최적으로 구현될 수 있도록 Canvas 다시 그리기가 비동기적으로 수행됩니다. 즉, 응용 프로그램은 Canvas 클래스의 repaint() 메소드를 호출하여 다시 그리기를 요청하는 데 실제 그리기는 Canvas 서브 클래스가 제공하는 paint() 메소드에서 수행되므로 repaint()와 동기적으로 발생할 필요가 없습니다. 실제 그리기는 나중에 발생할 수도 있고 여러 개의 다시 그리기 요청이 한 번의 paint()를 호출할 수도 있습니다. 응용 프로그램은 serviceRepaints()를 호출하여 다시 그리기 요청을 플러시할 수 있습니다.

예를 들면, 응용 프로그램이 너비가 wid이고 높이가 ht인 박스를 x1,y1 좌표에서 x2,y2 좌표로 이동한다고 가정합니다(여기서 x2>x1 및 y2>y1). 


    // move coordinates of box
    box.x = x2;
    box.y = y2;
    
    // ensure old region repainted (with background)    
    canvas.repaint(x1,y1, wid, ht);
    
    // make new region repainted
    canvas.repaint(x2,y2, wid, ht);
    
    // make everything really repainted
    canvas.serviceRepaints();

마지막 호출에 의해 다시 그리기 스레드가 예약됩니다. 다시 그리기 스레드는 이벤트 대기열에서 2개의 요청을 발견하고 다시 그리기 영역의 합집합인 해당 영역을 다시 그립니다. 


    graphics.clipRect(x1,y1, (x2-x1+wid), (y2-y1+ht));      
    canvas.paint(graphics);

이와 같이 구현의 보이지 않는 부분에서 canvas.paint() 호출이 응용 프로그램이 정의한 paint() 메소드를 호출합니다.

그리기 모델

기본적인 그리기 작업은 픽셀을 다시 배치하는 작업이며 선과 직사각형과 같은 형상 렌더링 작업에 사용됩니다. 오프스크린 이미지를 사용할 때에는 완전 투명도가 지원되어야 하며 부분 투명도(알파 블렌딩)의 지원은 선택적입니다.

24비트 컬러 모델은 빨간색, 녹색 및 파란색의 색상 구성 요소에 대해 각각 8비트가 제공됩니다. 모든 장치가 24비트 컬러를 지원하는 것은 아니므로 응용 프로그램이 요청한 색상을 장치에 사용 가능한 색상으로 매핑하게 됩니다. 색상의 사용 가능 여부 및 사용 가능한 회색 수준 수와 같은 장치 특성을 얻기 위한 기능이 Display 클래스에 제공됩니다. 그러면 응용 프로그램은 장치 독립성을 손상시키지 않고도 장치에 이러한 동작을 적용할 수 있습니다.

그래픽은 디스플레이 또는 오프스크린 이미지 버퍼에 직접 렌더링될 수 있습니다. 렌더링된 그래픽의 대상은 그래픽 객체의 원본에 따라 다릅니다. 디스플레이에 렌더링할 그래픽 객체는 Canvas 객체의 paint() 메소드에 전달됩니다. 이것은 대상이 디스플레이인 그래픽 객체를 구하기 위한 유일한 방법입니다. 또한 응용 프로그램은 paint() 메소드의 지속 시간 동안에만 이 그래픽 객체를 사용하여 그리기를 수행할 수 있습니다.

오프스크린 이미지 버퍼에 렌더링할 그래픽 객체는 원하는 이미지에서 getGraphics() 메소드를 호출하여 얻을 수 있습니다. 응용 프로그램은 이러한 객체를 무기한으로 보유할 수 있으며 이러한 객체에 대해 언제든지 요청을 실행할 수 있습니다.

Graphics 클래스에는 setColor() 메소드를 사용하여 현재 색이 설정되어 있습니다. 선, 직사각형 및 호를 포함한 모든 형상 렌더링은 현재 색을 사용합니다. 현재 색을 표현하는 픽셀은 이러한 작업에서 대상 픽셀을 교체합니다. 배경색은 없습니다. 배경 그리기는 응용 프로그램이 setColor()와 렌더링 호출을 사용하여 명시적으로 수행합니다.

완전 투명도가 지원되어야 하며 부분 투명도(알파 블렌딩)의 지원은 선택적입니다. 투명도(완전 및 부분 모두)는 PNG 파일이나 ARGB 데이터 배열에서 로드되는 오프스크린 이미지에만 존재합니다. 이러한 방식으로 작성된 이미지는 응용 프로그램이 이 이미지에 포함된 픽셀 데이터를 변경할 수 없으므로 변경 불가능합니다. 렌더링은 모든 렌더링 작업의 대상이 항상 완전히 불투명 픽셀로만 구성되는 방법으로 정의됩니다.

좌표계

사용 가능한 그리기 영역과 이미지의 원점 (0,0)은 디스플레이의 왼쪽 상단 모서리에 있습니다. X-좌표의 숫자 값은 왼쪽에서 오른쪽으로 단순 증가하며 Y-좌표의 숫자 값은 위에서 아래로 단순 증가합니다. 응용 프로그램은 좌표계의 가로와 세로 거리가 실제 장치 디스플레이의 동일한 거리를 표현하는 것으로 가정합니다. 장치의 픽셀 유형이 정방과 많은 차이가 나면 UI 구현 시 필요한 좌표 변형을 수행합니다. 좌표계의 원점을 변환하기 위한 기능이 제공됩니다. 모든 좌표는 정수로 정의됩니다.

좌표계는 픽셀 자체가 아니라 픽셀 간의 위치를 표현합니다. 그러므로 디스플레이의 왼쪽 상단 모서리에 있는 첫 번째 픽셀은 (0,0), (1,0), (0,1), (1,1) 좌표로 둘러싸인 정사각형에 놓여 있습니다.

응용 프로그램은 Canvas의 다음과 같은 메소드를 호출하여 사용 가능한 그리기 영역에 대해 질문할 수 있습니다. 


    public static final int getWidth();
    public static final int getHeight();

글꼴 지원

응용 프로그램은 아래에 지정된 글꼴 속성 중 하나를 요청할 수 있습니다. 그러나 기본 구현 시 지정된 속성의 하위 집합을 사용할 수 있습니다. 따라서 요청한 글꼴과 가장 닮은 글꼴을 반환하도록 구현해야 합니다.

시스템의 각 글꼴은 개별적으로 구현됩니다. 프로그래머는 새 Font 객체를 인스턴스화하는 대신 정적 getFont() 메소드를 호출합니다. 이 패러다임은 일반적으로 글꼴의 사용과 연관된 가비지가 생기지 않도록 해줍니다.

Font 클래스는 글꼴 메트릭에 액세스하는 호출을 제공합니다. Font 클래스에서 글꼴을 요청하는 데 다음과 같은 속성을 사용할 수 있습니다.

동시 처리

UI API는 스레드를 사용할 수 있도록 설계되었습니다. 이 메소드는 TimerTasks 콜백이나 응용 프로그램이 작성한 다른 스레드에서 호출될 수 있습니다. 또한 구현 시 일반적으로 응용 프로그램에 가시적인 객체에 대해 어떠한 잠금도 보유하지 않습니다. 즉, 응용 프로그램의 스레드는 스스로 동기화되거나 응용 프로그램이 정의한 동기화 정책에 따라 객체를 잠그는 방법으로 이벤트 콜백과 동기화될 수 있습니다. 이 규칙에 대한 한 가지 예외는 Canvas.serviceRepaints 메소드를 사용할 때 발생합니다. 이 메소드는 paint 메소드를 호출하고 완료하기를 기다립니다. 엄밀히 말하자면, serviceRepaints는 paint를 직접 호출하는 것이 아니라 다른 스레드가 paint를 호출하도록 만듭니다. 어떤 경우든지, serviceRepaints는 paint가 반환될 때까지 차단됩니다. 이는 다음과 같은 경우 때문에 매우 중요합니다. serviceRepaints의 호출자가 paint 메소드에서도 필요한 잠금을 보유하고 있다고 가정해 봅니다. paint는 또 다른 메소드에서 호출될 수도 있기 때문에 해당 스레드는 잠금을 얻기 위해 차단됩니다. 그러나 이 잠금은 serviceRepaints의 호출자가 보유하고 있으며 이 메소드는 paint가 반환되기를 기다리며 차단되어 있습니다. 결과적으로 교착 상태가 됩니다. 교착 상태를 피하려면 serviceRepaints 호출자가 paint 메소드에서 필요로 하는 잠금을 보유해서는 안 됩니다.

UI API에는 또한 이벤트 스트림을 사용하여 작업을 일련화하는 다른 UI 툴킷과 유사한 방법도 포함되어 있습니다. Display.callSerially 메소드는 Runnable 객체의 run 메소드가 호출되고 이벤트 스트림으로 일련화되도록 요청합니다. serviceRepaints()를 사용하는 코드는 일반적으로 callSerially()를 사용하기 위해 다시 작성됩니다. 다음 코드는 이 기법을 보여 줍니다. 


    class MyCanvas extends Canvas {    
        void doStuff() {
            // <code fragment 1>    
            serviceRepaints();
            // <code fragment 2>    
        }
    }

다음 코드는 같은 기능을 구현하는 또 다른 방법입니다.


    class MyClass extends Canvas 
       implements Runnable {            
        void doStuff() {
            // <code fragment 1>
            callSerially(this);
        }

        // called only after all pending repaints served    
        public void run() {
            // <code fragment 2>;
        }
    }

구현 노트

List 또는 ChoiceGroup의 구현 시 선택 요소의 초점과 선택을 위한 바로 가기 키를 포함할 수 있지만 응응 프로그램에는 이러한 바로 가기 키의 사용이 보이지 않습니다.

일부 구현에서는 Screen 및 Item과 같은 UI 구성 요소가 고유 구성 요소를 기반으로 합니다. Java 객체가 더 이상 필요하지 않을 때는 사용했던 자원을 해제하도록 구현해야 합니다. 가능한 구현 시나리오 중 하나는 KVM의 가비지 컬렉터에 후크를 사용하는 것입니다.

Since:
MIDP 1.0
Overview   Package  Class  Use  Tree  Deprecated  Index  Help 
MID 프로필
 PREV PACKAGE   NEXT PACKAGE FRAMES    NO FRAMES    
의견이나 제안 사항 보내기 MID 프로필 사양 버전 2.0
Java는 미국 및 다른 국가에서 Sun Microsystems, Inc.의 상표 또는 등록 상표입니다. Copyright 1993-2002 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. 모든 권리는 저작권자의 소유입니다.