Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Входной SPI механизма метода включает разработке входных методов в языке программирования Java, который может использоваться с любым Java 2 среды выполнения. Насколько входная платформа метода затрагивается, входной метод состоит из двух классов, реализовывая InputMethodDescriptor и InputMethod интерфейсы, упакованные с некоторой дополнительной информацией как расширение и установленный в Среду выполнения Java. Спецификации для java.awt.im.spi пакет, и InputMethodDescriptor и InputMethod интерфейсы предоставляют базовую информацию, это необходимо, чтобы реализовать входной метод. Это учебное руководство обеспечивает дополнительную информацию, которая делает эту задачу немного легче и помогает избежать проблем совместимости между различными реализациями Java 2 платформы.
Прежде, чем входная платформа метода может начать использовать входной метод, она должна знать о его возможностях. Необходимая информация предоставляется входной реализацией метода InputMethodDescriptor class. Эта информация используется в выборе входных методов.
Список доступных локалей, возвращенных getAvailableLocales должен только возвратить языки, для которых действительно разрабатывается входной метод. Например, китайский входной метод Системы транслитерации китайских иероглифов, который производит символы упрощенного китайского, должен только возвратиться SIMPLIFIED_CHINESE, даже если у этого есть режим, который просто позволяет ключевым событиям проходить и таким образом также позволяет писать по-английски или малайский язык. InputMethod.setLocale метод с другой стороны может возвратить true для большего набора языков. Причина - это getAvailableLocales используется, чтобы решить, загрузиться ли и переключиться на входной метод, который только стоит, если входной метод обрабатывает язык хорошо, в то время как setLocale используется, чтобы решить, переключиться ли далеко от входного метода, который только стоит, если входной метод не обрабатывает язык вообще.
Когда входной экземпляр метода создается, он получает InputMethodContext экземпляр через setInputMethodContext. Этот экземпляр предоставляет этому всю функциональность, которую это должно передать с входной платформой метода, клиентским компонентом, или окном состава. Это позволяет входному методу отправлять информацию о составленном и фиксировавшем тексте, используя dispatchInputMethodEvent метод. И это позволяет входному методу запрашивать информацию от клиентского компонента, используя методы, которые это наследовало от InputMethodRequests интерфейс.
Входная платформа метода предоставляет входному методу среду, которая заставляет это казаться, что это всегда связывается с активным клиентским компонентом, используя входной стиль на месте. Если фактический клиентский компонент не является активным клиентом, или если различный входной стиль используется, то платформа перенаправляет события и запросы как необходимый.
Входной метод никогда не должен пытаться получить доступ к клиентскому компоненту непосредственно, поскольку выполнение так конфликтовало бы с функциональностью переключения и перенаправления платформы. Вместо этого входной метод должен всегда использовать методы, обеспеченные его входным контекстом метода.
Входные методы могут использовать много различных окон, чтобы связаться с пользователем. Windows, обычно используемый входными методами, включает:
Отметьте: На некоторых других платформах входные методы могут также обеспечить окно состава, которое показывает составленный текст. Во входной платформе метода Java составленный текст всегда не выводится на экран клиентским компонентом или входной платформой метода, никогда входным методом.
Полезно рассмотреть три группы окон:
Вот то, как эти группы окна могут быть обработаны входными методами, записанными для Java 2 платформы:
InputMethodContext.createInputMethodWindow, обычно с attachToInputContext набор к истине. Они открываются любой во входной реализации метода activate, или позже при необходимости ответить на ввод данных пользователем. Они закрываются во входных реализациях метода deactivate или hideWindows, или ранее если они больше не необходимы. InputMethodContext.createInputMethodWindow, с attachToInputContext набор ко лжи. Они обычно открываются во входной реализации метода activate и закрытый во входной реализации метода hideWindows.Отметьте что поведение фокуса окна, создаваемого createInputMethodWindow является зависящим от реализации. Это никогда, возможно, не получает фокус, это может получить фокус, когда первоначально сделанный видимым, или это может получить фокус, когда пользователь щелкает в это. Входной метод должен быть в состоянии обработать любой случай.
К окнам позиции (таким как окно поиска) автоматически относительно составленного текста, входной метод может использовать входной контекст метода getTextLocation метод. К окнам позиции (таким как окно состояния) автоматически относительно окна, содержащего текущий клиентский компонент, входной метод может зарегистрироваться для уведомлений о расположении того окна и состоянии, используя входной контекст метода enableClientWindowNotification метод; это тогда должно реализовать notifyClientWindowChange метод, чтобы получить уведомления.
Входные методы должны вызвать Window.dispose для всех окон, которые они создают, когда они больше не необходимы. Это гарантирует, что JVM выходит, когда приложение завершается, весь недемон распараллеливает это, запускался. Пожалуйста, отошлите к AWT Распараллеливающие Проблемы для получения дополнительной информации.
Основная задача входного метода интерпретирует пользовательские действия в создании текстового ввода. Пользовательские действия могут вводить на клавиатуре, используя мышь, почерк, или разговор.
activate и deactivate методы указывают к входному методу, имеет ли клиентский компонент фокус и поэтому является целью текстового ввода. Обычно входные методы только обрабатывают события, чтобы составить текст, в то время как они являются активными.
Когда входной метод является активными, определенными типами событий, диспетчеризируются входному методу, используя dispatchEvent метод прежде, чем они будут обработаны клиентским компонентом. Входной метод решает для каждого события, хочет ли это обработать это. Если это делает, это отмечает событие как использовано так, чтобы это не было обработано клиентским компонентом.
Отметьте: Для ключевых событий входные методы должны использовать только события KEY_TYPED, чтобы получить информацию о символах, вводимых, и использовать события KEY_PRESSED ИЛИ KEY_RELEASED только, чтобы получить информацию о функциональных клавишах, которые не приводят к событиям KEY_TYPED. Отображение от нажатий клавиш до символов зависит от платформ, аппаратных средств, локалей, и возможно других факторов, и лучше всего оставляется базовой операционной системе.
Поскольку текст составляется и фиксируется, входной метод должен сообщить клиентскому компоненту обо всех изменениях так, чтобы клиентский компонент мог перерисовать текст. Входной метод делает это при использовании InputMethodContext.dispatchInputMethodEvent создать и диспетчеризировать входные события метода клиентскому компоненту. В зависимости от текущей модели потока события входная платформа метода может перенаправить события к своему окну состава. Диспетчеризация входных событий метода является единственным путем к входным методам Java, чтобы составить выведенный на экран текст.
Составленный текст обычно повышается со стилями выделения, которые указывают на текущее состояние преобразования. Это выполняется, добавляя атрибуты к тексту, используя TextAttribute.INPUT_METHOD_HIGHLIGHT ключ и экземпляры InputMethodHighlight как значения. Обычно входные методы только определяют абстрактные выделения (использующий состояние и выбранные свойства входного выделения метода) и оставляют отображение на конкретные стили к системе рендеринга. Однако, при желании, входные методы могут добавить конкретную информацию о стиле к выделению, используя свойство стиля. Это - хорошая идея разработать конкретные стили как изменения стилей, обеспеченных возвращенными Toolkit.mapInputMethodHighlight.
И клиентский компонент и входная платформа метода могут распознать ситуации, где текущий состав должен быть закончен и весь составленный текст, или фиксировавший или отмененный. Они сообщают входному методу об этой потребности, используя endComposition метод. Отметьте это endComposition может быть вызван, в то время как входной метод не активный.
Клиентские компоненты могут влиять на состав, используя несколько методов. InputContext.setCharacterSubsets метод позволяет им ограничивать подмножество набора символов Unicode, который входному методу позволяют ввести. Входные методы не должны обычно создать персонажи за пределами указанных подмножеств, и могут переключиться на различный режим ввода, который особенно поддерживает указанные символьные подмножества. InputContext.setCompositionEnabled и isCompositionEnabled методы, которым позволяют их управлять и исследовать, включается ли текущий входной метод для состава. InputContext.reconvert метод позволяет им инициировать обратное преобразование.
Некоторые входные методы могут хотеть обеспечить функциональность для клиентских компонентов, которые не могут быть сделаны доступными через входной API платформы метода. Это возможно через входные объекты управления метода. Входной разработчик метода должен опубликовать интерфейс для этих объектов, и экземпляры возврата через InputMethod.getControlObject. Клиентские компоненты, которые хотят использовать в своих интересах дополнительную функциональность, могут тогда вызвать InputContext.getInputMethodControlObject, проверьте, является ли возвращенный объект экземпляром известного объекта управления class, и если это, вызовите его методы.
Входные методы упаковываются как установленные расширения с определенным контентом как описано во "Входном разделе" Методов Упаковки спецификации SPI. Один важный аспект, чтобы рассмотреть - то, что все расширения, установленные в среде приложения Java, совместно используют то же самое пространство имен. Чтобы избежать коллизий имени, входные методы должны следовать за соглашениями о присвоении имен пакета как описано в Спецификации языка Java. Подобные соглашения должны быть применены к именованию non-class файлы, которые упаковываются во входном файле JAR метода, таком как словари.
Городской Входной Метод является простым входным методом, который показывает, как использовать интерфейсы, обеспеченные входным SPI механизма метода.
