85 addCommand(showAlert);
86
87 sayHi = new
88 Command(midlet.getResource("sayhi"),
89 Command.SCREEN, 1);
90 addCommand(sayHi);
91
92 cancel = new
93 Command(midlet.getResource("cancel"),
94 Command.SCREEN, 1);
95 addCommand(cancel);
96
97 exit = new
98 Command(midlet.getResource("exit"),
99 Command.SCREEN, 1);
100 addCommand(exit);
101
102 help = new
103 Command(midlet.getResource("help"),
104 Command.SCREEN, 1);
105 addCommand(help);
106
107 item = new
108 Command(midlet.getResource ("item"),
109 Command.SCREEN, 1);
110 addCommand(item);
111
112 ok = new
113 Command(midlet.getResource("ok"),
114 Command.SCREEN, 1);
115 addCommand(ok);
116
117 screen = new
118 Command(midlet.getResource("screen"),
119 Command.SCREEN, 1);
120 addCommand(screen);
121
122 stop = new
123 Command(midlet.getResource("stop"),
124 Command.SCREEN, 1);
125 addCommand(stop);
126 }
127
128 // Данный класс просто прослушивает активацию
129 // какой-либо команды. Экземпляр HelloForm
130 // устанавливает экземпляр данного класса как
131 // свой блок прослушивания команд. Экземпляр
132 // объекта не проверяет информацию команды,
133 // а просто отображает модальное Alert, показывающее,
134 // что экранная клавиша была активирована пользователем.
135 public class MyCommandListener
136 реализует CommandListener
137 {
138 public void commandAction(Command c,
139 Displayable d)
140 {
141 String title =
142 midlet.getResource("alert_title");
143 String msg = midlet.getResource("alert_text");
144
145 if (с == showAlert)
146 {
147 alert = new Alert(title,
148 msg,
149 null, AlertType.INFO);
150 alert.setTimeout(Alert.FOREVER);
151 display.setCurrent(alert, HelloForm2.this);
152 }
153 else if (c == sayHi)
154 {
155 alert = new Alert(title,
156 msg,
157 null, AlertType.INFO);
158 alert.setTimeout(Alert.FOREVER);
159 display.setCurrent(alert, HelloForm2.this);
160 }
161
162 if (c == exit)
163 {
164 I18NDemo.getInstance-(). destroyApp (true);
165 }
166 }
167 }
168 }
Наиболее проблематичным аспектом данного подхода является то, что вы, разработчик, должны создать инфраструктуру, которая позволит вашим приложениям считывать и анализировать файлы ресурсов. Также приложение должно создавать структуры внутренних данных, которые содержат локализованные ресурсы, считанные из файлов. Самым проблематичным аспектом создания этой инфраструктуры является предоставление адекватной обработки потоков, особенно обработки потоков для поддержки считывания значений строковых атрибутов. Метод MIDlet.getAppProperty(), использовавшийся в предыдущей схеме, основанной на файле JAD, извлекает информацию об обработке потоков. Но в данной схеме вы должны проделать всю эту работу самостоятельно.
Метод Class.getResourceAsStream(String name) является единственным способом, с помощью которого MID-лет может считывать файл из JAR приложения. Параметр имени представляет собой имя файла без информации о пути. Этот метод выдает объект java.io.InputStream, который является байтовым потоком.
Вы должны преобразовать этот байтовый поток в символьный для того, чтобы считывать значения строковых атрибутов в вашей программе. Единственный практичный способ преобразовать байтовые потоки в символьные — это использовать класс java.io.InputStreamReader. Вы создаете экземпляр данного класса, пересылая ваш объект InputStream в конструктор InputStreamReader. В строках с 137 до 154 листинга 9.5 символьный поток срздает определяемый приложением метод loadResources () .
Чтобы преобразовывать из байтов в символы, вы должны знать символьную кодировку файла ресурса, который вы считываете. В листинге 9.5 происходит преобразование из кодировки ISO8859-1 (используемой файлом en_US.txt) в уникод. При считывании символьных данных в программу конечной кодировкой всегда является уникод. Java всегда представляет символы и строки внутренне с помощью уникода.
Первая форма конструктора InputStreamReader, показанная в таблице 9.1 и использованная в листинге 9.5, преобразует из символьной кодировки, устанавливаемой платформой по умолчанию, в уникод. Если ваш файл ресурсов использует кодировку, отличную от кодировки, используемой платформой по умолчанию, вы должны использовать второй конструктор InputStreamReader, который принимает аргумент, указывающий- кодировку потока, считываемого вами.
Важным решением проектировки интернационализации и локализации является выбор символьной кодировки ваших файлов ресурсов. Значения строковых атрибутов локализованы и должны быть кодированы с помощью символьной кодировки, которая поддерживает язык локализации. Ключи атрибутов, однако, не локализуются, и они могут быть написаны с помощью ASCII. Варианты выбора кодировки должны учитывать следующее:
— ключи и значения атрибутов должны быть кодированы с помощью одной и той же символьной кодировки;
— все файлы ресурсов для всех региональных настроек должны использовать одну символьную кодировку.
Лучше всего использовать одну символьную кодировку для всего файла. В противном случае вам понадобится создать два символьных потока: один для анализа ключей атрибутов и второй для анализа значений. Подобная схема добавляет вашей обработке потоков ненужный уровень сложности.
Читать дальше