BRPI0720474A2 - Gerenciar uma multitela - Google Patents

Gerenciar uma multitela Download PDF

Info

Publication number
BRPI0720474A2
BRPI0720474A2 BRPI0720474-4A2A BRPI0720474A BRPI0720474A2 BR PI0720474 A2 BRPI0720474 A2 BR PI0720474A2 BR PI0720474 A BRPI0720474 A BR PI0720474A BR PI0720474 A2 BRPI0720474 A2 BR PI0720474A2
Authority
BR
Brazil
Prior art keywords
screen
display
hscreen
configuration
logical
Prior art date
Application number
BRPI0720474-4A2A
Other languages
English (en)
Inventor
Kwang-Kee Lee
Jong-Ho Lee
Sung-Wook Byun
Um-Gyo Jung
Glenn A Adams
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of BRPI0720474A2 publication Critical patent/BRPI0720474A2/pt
Publication of BRPI0720474A8 publication Critical patent/BRPI0720474A8/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/445—Receiver circuitry for the reception of television signals according to analogue transmission standards for displaying additional information
    • H04N5/45—Picture in picture, e.g. displaying simultaneously another television channel in a region of the screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4316—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for displaying supplemental content in a region of the screen, e.g. an advertisement in a separate window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Studio Circuits (AREA)
  • User Interface Of Digital Computer (AREA)

Description

MÉTODO PARA CONFIGURAR E GERENCIAR UMA MULTITELA ÁREA TÉCNICA
A presente invenção se refere a um método e aparelho para configurar uma tela, na qual uma pluralidade de serviços é exibida e, de modo particular, a um método e aparelho para configurar uma tela transmissora final incluindo uma pluralidade de telas, na qual uma pluralidade de serviços é apresentada ou exibida.
ANTECEDENTES DA INVENÇÃO De um modo geral, sistemas receptores de difusão
convencionais, tais como decodificadores de sinais digitais ou de televisão digital (TVs), fornecem apenas um elemento de conteúdo em um único dispositivo de exibição fisica, ou exibem ao mesmo tempo uma tela principal e uma subtela em um único dispositivo de exibição fisica. Porém, muito embora os sistemas receptores de difusão convencionais possam exibir ao mesmo tempo a tela principal e a subtela na mesma tela exibidora, eles somente podem dispor a tela principal e a subtela de uma quantidade limitada de maneiras. Além disso, existem tipos limitados de dispositivos de exibição capazes de combinar e retribuir serviços de várias fontes, tais como um transmissor, um disco digital versátil (DVD), e um dispositivo externo conectado a um terminal de entrada. Embora todos dentre um serviço de video, um serviço de áudio, e um serviço de dados possam ser exibidos na tela principal, um serviço de dados não pode ser exibido na subtela.
A fig. 1 ilustra configurações de tela formadas por um método convencional de imagem dentro de imagem (PiP). 0 método PiP convencional exibe uma tela principal e uma subtela em uma tela de exibição física. Os algarismos de referência 100, 110, 120, 130, 140 e 150 indicam telas de exibição física, e os algarismos de referência 105, 115, 125, 135, 142, 144, 152 e 154 indicam subtelas. De modo particular, visto que as posições ou tamanhos das subtelas 105, 115, 125, 135, 142, 144, 152 e 154 são restritos, existe uma limitação na implementação flexível do método PiP convencional.
Em um ambiente de programas interativos de aplicativos de TV, tal como a Plataforma Doméstica de Multimídia (MHP), Protocolo de Acesso para Configurações de Aplicativos (ACAP), e Plataforma Aberta de Aplicativos para Cabo (OCAP), é suposto que apenas uma tela seja emitida. No ambiente de programas interativos de aplicativos de TV, é adotada uma Interface de Usuário (UI) da Interface Doméstica de Áudio/ Visual (HAVi). De acordo com a HAVi UI, muito embora nenhuma restrição seja imposta acerca do número de telas exibidas num dispositivo de exibição física, somente uma tela é geralmente exibida. Além disso, programas de aplicativos compartilham somente uma tela que é exibida. Por conseguinte, o ambiente convencional de programas de aplicativos para serviço de difusão possui uma limitação na exibição de vários tipos de conteúdo de serviço numa tela dinamicamente configurada.
DESCRIÇÃO DOS DESENHOS
A fig. 1 ilustra configurações de tela formadas por um método PiP convencional.
A fig. 2 ilustra uma relação entre uma tela lógica, uma tela de exibição, e um mapeador de exibição, de acordo com uma modalidade da presente invenção.
A fig. 3 é um diagrama de blocos de um sistema de televisão digital (TV), que pode implementar um gerenciador de multitelas, acordo com uma modalidade da presente invenção.
A fig. 4 ilustra uma pluralidade de conteúdos
apresentados num sistema de TV digital, acordo com uma modalidade da presente invenção.
As figs. 5A e 5B ilustram respectivamente um serviço não-abstrato e um serviço abstrato, acordo com uma modalidade da presente invenção.
A fig. 6 ilustra uma relação entre um contexto de tela e vários métodos.
As figs. 7A e 7B ilustram resultados numa tela de exibição, de acordo com a ζ ordem de uma tela lógica. As figs. 8A e 8B ilustram associações entre um
contexto de serviço, uma tela lógica, e uma tela de exibição.
As figs 9A e 9B ilustram resultado numa tela de exibição, de acordo com áreas de exibição, para as quais uma tela lógica é mapeada.
A fig. 10 ilustra associações entre uma pluralidade
de serviços, uma pluralidade de telas lógicas, e uma tela de exibição.
A fig. IlA ilustra o registro das constantes de Java em Aorg.ocap.ui.MultiScreenConfigurableContext', acordo com uma modalidade da presente invenção.
A fig. IlB ilustra o registro das constantes de Java em ^org.ocap.ui.MultiScreenConfiguration', de acordo com uma modalidade da presente invenção.
A fig. IlC ilustra o registro das constantes de Java em ^org.ocap.ui.MultiScreenContext', de acordo com uma modalidade da presente invenção.
A fig. IlD ilustra o registro das constantes de Java em *org.ocap.ui.event.MultiScreenConfigurationEvent' , de acordo com uma modalidade da presente invenção. A fig. IlE ilustra o registro das constantes de
Java em Aorg.ocap.ui.event.MultiScreenContextEvent', de acordo com uma modalidade da presente invenção.
A fig. IlF ilustra o registro das constantes de Java em xorg.ocap.ui.event.MultiScreenEvent', de acordo com uma modalidade da presente invenção.
A fig. IlG ilustra o registro das constantes de Java em iOrg.ocap.ui.event.MultiScreenResourceEvent', de acordo com uma modalidade da presente invenção.
A fig. 12 ilustra uma interface e uma classe de um pacote de Java iOrg.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 13A ilustra a definição de uma interface ^MultiScreenConfigurableContext' do pacote iOrg.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 13B ilustra um campo da interface iMultiscnconfigurableContext' do pacote *org.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 13C ilustra um caso de uso de um campo N CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDERs .
As figs. 13D a 13F ilustram um método da interface iMultiScreenConfigurableContext' do pacote iOrg.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 14A ilustra a definição de uma interface iMultiScreenConfiguration' do pacote iOrg1Ocap-Ui', de acordo com uma modalidade da presente invenção. A fig. 14B ilustra um campo da interface
iMultiScreenConfiguration' do pacote iOrg-Ocap-Ui', de acordo com uma modalidade da presente invenção.
A fig. 14C ilustra um método da interface iMultiScreenConfiguration' do pacote iOrg-Ocap-Ui', de acordo com uma modalidade da presente invenção.
A fig. 15A ilustra a definição de uma interface 'MultiScreenContext' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 15B ilustra um campo da interface 'MultiScreenContext' do pacote iOrg.ocap.ui', de acordo com uma modalidade da presente invenção.
As figs. 15C a 15D ilustram um método da interface 'MultiScreenContext' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 16A ilustra a definição de uma classe 'MultiScreenManager' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 16B ilustra um construtor da classe 'MultiScreenManager' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção. As figs. 16C a 16F ilustram um método da classe
'MultiScreenManager' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
A fig. 17 ilustra uma interface e uma classe do pacote de Java 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 18A ilustra a definição de uma classe 'MultiScreenConfigurationEvent' do pacote
'org.ocap.ui.event', de acordo com uma modalidade da presente invenção. A fig. 18B ilustra um campo da classe
'MultiScreenConfigurationEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 18C ilustra um construtor da classe ^MultiScreenConfigurationEvent' do pacote
iOrg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 18D ilustra um método da classe 'MultiScreenConfigurationEvent' do pacote
'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 19A ilustra a definição de uma interface 'MultiScreenConfigurationListener' do pacote
'org.ocap.ui.event', de acordo com uma modalidade da presente invenção. A fig. 19B ilustra um método da interface
'MultiScreenConfigurationListener' do pacote
'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 20A ilustra a definição de uma classe 'MultiScreenContextEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 20B ilustra um campo da classe 'MultiScreenContextEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção. A fig. 20C ilustra um construtor da classe
'MultiScreenContextEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 20D ilustra um método da classe iMultiScreenContextEvent' do pacote iOrg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 21A ilustra a definição de uma interface
iMultiScreenContextListener' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 21B ilustra um método da interface iMultiScreenContextListener' do pacote iOrgiOCapiUi-Cvent', de acordo com uma modalidade da presente invenção.
A fig. 22A ilustra a definição de uma classe iMultiScreenEvent' do pacote iOrg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 22B ilustra um campo da classe iMultiScreenEvent' do pacote iOrg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 22C ilustra um construtor da classe iMultiScreenEvent' do pacote iOrg-Oeap-Ui-Cvent', de acordo com uma modalidade da presente invenção. A fig. 22D ilustra um método da classe
iMultiscreenResourceEvent' do pacote iOrg-OCap-Ui-Cvent', de acordo com uma modalidade da presente invenção.
A fig. 23A ilustra a definição de uma classe iMultiscreenResourceEvent' do pacote iOrg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 23B ilustra um campo da classe iMultiscreenResourceEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 23C ilustra um construtor da classe iMultiscreenResourceEvent' do pacote 'org.ocap.ui.event', de acordo com uma modalidade da presente invenção.
A fig. 23D ilustra um método da classe iMultiscreenResourceEvent' do pacote xorg.ocap.ui.event', de acordo com uma modalidade da presente invenção.
As figs. 24A a 24C ilustram precondições para alterar uma configuração de multitelas, de acordo com uma modalidade da presente invenção.
A fig. 24D ilustra um processo para alterar uma configuração de multitelas, acordo com uma modalidade da presente invenção. As figs. 25A a 25E ilustram pós-condições para
alterar uma configuração de multitelas, de acordo com uma modalidade da presente invenção.
As figs. 26A a 26D ilustram restrições para verificar invariáveis, acordo com uma modalidade da presente invenção.
A fig. 27 ilustra a definição de um método ^getNonDefaultScreensO', acordo com uma modalidade da presente invenção.
As figs. 28A e 28B ilustram a definição de um método ^etNonDefaultScreenDevicesO', acordo com uma modalidade da presente invenção. A fig. 29 ilustra uma pluralidade de métodos, acordo com uma modalidade da presente invenção.
A fig. 30A ilustra pseudocódigos de um tipo de Java xAppID', de acordo com as normas da plataforma aberta de aplicativos para cabo (OCAP).
A fig. 30B ilustra pseudocódigos de um tipo de Java xOcapAppID' para implementar um OCAP MSM, de acordo com uma modalidade da presente invenção.
A fig. 31 ilustra pseudocódigos para prestar suporte ao tipo de Java xOcapAppID' para implementar um Ocap MSM, de acordo com uma modalidade da presente invenção.
A fig. 32A ilustra pseudocódigos de um tipo de Java "lHSceneBinding', de acordo com as normas OCAP. A fig. 32B ilustra pseudocódigos do tipo de Java
xHSceneBinding' para implementar o OCAP MSM, de acordo com uma modalidade da presente invenção.
A fig. 33A ilustra pseudocódigos de um tipo de Java xHSceneChangeRequestHandler', de acordo com as normas OCAP. A fig. 33B ilustra pseudocódigos do tipo de Java
xHSceneChangeRequestHandler', para implementar o OCAP MSM, de acordo com uma modalidade da presente invenção.
A fig. 34A ilustra pseudocódigos de um tipo de Java xHSceneManager', de acordo com as normas OCAP. As figs. 34B e 34C ilustram pseudocódigos do tipo
de Java xHSceneManager' para implementar o OCAP MSM, de acordo com uma modalidade da presente invenção.
DIVULGAÇÃO
SOLUÇÃO TÉCNICA
A presente invenção apresenta um método e aparelho para configurar e gerenciar uma multitela, na qual uma pluralidade de conteúdos de serviço pode ser ao mesmo tempo exibida em posições desejadas e com tamanhos desejados.
A presente invenção também apresenta interfaces, que permitem o uso eficaz dos recursos de dispositivos oferecendo suporte a multitelas, e aplicativos inter- operáveis para gerenciamento da funcionalidade de multitelas. A presente invenção também apresenta uma interface padronizada para gerenciar funcionalidade de multitelas e um estado de multitelas, tal como uma tela de imagem dentro de imagem (PiP) , ou de imagem fora de imagem (PoP).
0 método e aparelho para gerenciar a multitela, de acordo com a presente invenção, controla dinamicamente o uso de recursos e ciclos de vida dos programas de aplicativo para cada tela, a fim de mostrar conteúdos de serviço numa pluralidade de telas lógicas independentes.
EFEITOS VANTAJOSOS
Visto que um ou mais conteúdos de serviço correspondem a uma ou mais telas de maneira many-to-many (múltipla) , e não de uma maneira de um para um (individual), um método e aparelho para configurar e gerenciar -uma multitela, de acordo com a invenção, pode configurar e emitir uma tela final, de maneira dinâmica. Além disso, graças às várias interfaces gerenciadoras de recursos, a funcionalidade gerenciadora de multitelas permite o uso eficaz dos recursos de um dispositivo principal prestando suporte a uma multitela.
Uma Extensão gerenciadora de multitelas (MSM) da
plataforma aberta de aplicativos de cabo (OCAP), de acordo
com uma modalidade da presente invenção, é uma extensão de
1
um perfil OCAP que inclui todas as interfaces dos programas de aplicativos (APIs) demandadas, conteúdos e formatos de dados, e protocolos, até o nivel dos aplicativos. Aplicativos desenvolvidos para a Extensão OCAP MSM serão executados em dispositivos host compatíveis com OpenCable. A Extensão OCAP MSM permite que os operadores via cabo implantem aplicativos interoperáveis para gerenciar funcionalidade de multitelas em dispositivos host compatíveis com OpenCable conectados nas suas redes. Esse perfil permite que os operadores via cabo possuem uma interface padronizada para gerenciar funcionalidade de multitelas e seu estado, tal como telas de imagem dentro de imagem (PiP) e imagem fora de imagem (PoP) em múltiplos fornecedores de dispositivos host. A Extensão OCAP MSM é aplicável a uma ampla
variedade de sistemas de hardware e operacionais para conceder flexibilidade de implementação aos fabricantes de Eletrônicos para Consumidor (CE). Um objetivo principal na definição da Extensão OCAP MSM é permitir implementações competitivas por parte do fabricante de CE, enquanto que mantendo uma interface programática compatível e inter- operável para uso por aplicativos definidos por operadores via cabo, bem como por aplicativos independentes da rede de cabos, que desejam estar cientes da funcionalidade de multitelas.
MELHOR MODO
De acordo com um aspecto da presente invenção, é apresentado um método para configurar e gerenciar uma multitela, um método compreendendo: recepção de um ou mais serviços de difusão; atribuição de uma ou mais serviços de difusão a uma tela; atribuição da tela a uma ou mais telas de exibição; e atribuição de uma ou mais telas de exibição a uma ou mais portas de saída.
0 método pode ainda compreender a associação de um contexto de serviço para a tela lógica a um contexto para uma ou mais telas de exibição, e alteração da associação entre os contextos.
O método pode ainda compreender a determinação de uma configuração de multitelas incluindo a tela lógica, uma ou mais telas de exibição, um contexto para o serviço, e informações sobre uma ou mais portas de saída, e alteração da configuração de multitelas. O método pode ainda compreender a observação das precondições e das pós-condições para alterar a configuração de multitelas.
0 método pode ainda compreender o informe de uma alteração da configuração de multitelas e dos conteúdos.
MODO PARA A INVENÇÃO
A presente invenção será agora descrita em mais detalhes com referência aos desenhos anexos, onde são mostradas modalidades exemplificantes da invenção. O gerenciamento de multitelas da presente invenção
será explicado com referência às figs. 2 a 34C.
O conceito de um sistema de multitelas e gerenciamento de multitelas introduzido na presente invenção será explicado com referência às figs. 2 a 10. Definições e funções de vários tipos de Java, de
acordo com as modalidades da presente invenção, serão explicadas com referência às figs IlA a 29.
Modificações ou alterações na norma da plataforma aberta de aplicativos de cabo (OCAP) existente para implementar as modalidades da presente invenção num ambiente OCAP serão explicadas com referências às figs. 30A a 34C.
Para uma melhor compreensão do relatório descritivo, abreviações e termos serão agora definidos. "HAVi" é uma abreviação da Interface Audiovisual
Doméstica. "MSM" é uma abreviação de Gerenciamento de Multitelas. "PiP" é uma abreviação de Imagem Dentro de Imagem. "PoP" é uma abreviação de Imagem Fora de Imagem. "AIT" é uma abreviação de Tabela de Informações sobre Aplicativos. "XAIT" é uma abreviação de Tabela de Informações Estendidas sobre Aplicativos.
"Tela Focalizadora de Áudio" é uma tela, cujas fontes de áudio são selecionadas para transferência a qualquer dispositivo de apresentação de áudio associado a quaisquer portas de saida de video ativadas, com que a tela é associada diretamente (no caso, ela é uma tela de exibição) ou indiretamente (no caso dela ser uma tela lógica mapeada).
"Mapeador de Exibição" é um processo lógico para compor o espaço de coordenadas normalizadas de uma tela lógica para o espaço de coordenadas normalizadas de uma tela de exibição (ou parte dessa) .
"Configuração das Multitelas de Exibição" é uma configuração de multitelas constituída somente das telas de exibição. Cada configuração de multitelas por plataforma é uma configuração de multitelas de exibição. Um tipo de configuração de uma configuração de multitelas de exibição é SCREEN_CONFIGURATION_DISPLAY, que será explicada mais tarde.
"Tela de Exibição" é um tipo de tela que modela uma composição final de saída de um dispositivo físico de exibição. A tela de exibição é associada a uma ou mais portas de saída de vídeo, que são por sua vez (1) ligadas a um mostrador integrado interno, ou (2) ligadas a um cabo físico da porta de saída para serem conectadas a um dispositivo mostrador externo através de uma interface bem definida, p. ex., a Interface Multimídia de Alta Definição (HDMI) ou o Insitute Of Electrical and Electronics Engineers (IEEE) 1394.
"Tela Geral" é uma tela lógica, que é atribuída a uma categoria de tela geral, que será explicada mais tarde.
Uma tela geral é tipicamente capaz de ser reconfigurada, de forma que ela possa servir a diferentes casos de aplicativos. Por exemplo, ela pode ser configurada como uma tela PiP em algum momento, mas como uma tela PoP em outro momento.
"Tela Lógica" é um tipo de tela, que não é
diretamente associada a um dispositivo mostrador físico, mas que pode ser mapeada através de um mapeador de exibição para uma tela de exibição. Uma tela lógica é mapeada ou não-mapeada. Se mapeada, ela é associada a uma tela de
exibição; se não-mapeada, ela não é associada a uma tela de exibição. Em casos excepcionais, uma tela lógica pode ser diretamente associada a uma porta de saída de vídeo, em cujo caso ela está servindo ao mesmo tempo como uma tela lógica e como uma tela semi-mostradora.
"Tela Principal" é uma tela de exibição ou uma tela
lógica, que é atribuída a uma categoria de tela principal, que será explicada mais tarde. Uma tela principal tem sempre a mesma extensão da tela inteira de um dispositivo mostrador (a não ser que em seguida mapeada pelo dispositivo mostrador em si sem o conhecimento do MSM).
"Contexto de Multitela Configurável" é uma extensão
de um contexto de multitela que fornece a capacidade para configurar (alterar) informações de estado relacionadas à funcionalidade gerenciadora de multitelas. O de Contexto de Configuração da Multitela é definido por uma interface λMultiScreenConfigurableContext' usada abaixo numa modalidade da presente invenção, e a interface ^MultiScreenConfigurableContext' no relatório descritivo é um tipo de Java para representar o Contexto de Multitela Configurável.
"Configuração de multitelas" é uma coleção
identificável de telas que apresentam ou são capazes de apresentar conteúdo, onde essa coleção pode (mas não precisa) ser um subconjunto exato de todas as telas acessáveis numa determinada implementação de plataforma, ou numa determinada tela de exibição. A qualquer dado momento, uma única configuração de multitelas se aplica a ambas, (1) à plataforma como um todo, em cujo caso as telas na configuração são telas de exibição, e (2) à cada tela de exibição, em cujo caso as telas na configuração são as telas de exibição em si ou um conjunto de telas lógicas mapeadas para essa tela de exibição. Uma determinada tela subjacente pode estar presente em configurações de multitelas múltiplas a um determinado momento.
A Configuração de Multitelas é definida por uma interface 'MultiScreenConfiguration' abaixo usada numa modalidade da presente invenção, e a interface 'MultiScreenConfiguration' é um tipo de Java para representar a Configuração de Multitelas.
"Tipo de Configuração de Multitelas" é uma caracterização de uma configuração de multitelas baseada essencialmente nas suas categorias de telas constituintes. O conjunto dos tipos de configuração de multitelas é ainda dividido em (1) um tipo de configuração de multitelas de exibição, conhecido como uma configuração de multitelas de exibição, e (2) todos os outros tipos de configuração de multitelas, conhecidas como configurações de multitelas sem exibição.
"Contexto de Multitelas" é um conjunto de informações sobre estado que estende uma Tela HAVI, a fim de permitir a interoperação numa plataforma que implemente telas múltiplas. 0 contexto inicial de multitelas fornece funcionalidade para descobrir (mas não alterar), essas informações sobre estado.
0 Contexto de Multitelas é definido por uma interface 'MultiScreenContext' abaixo usada numa modalidade da presente invenção, e a interface 'MultiScreenContext' no relatório descritivo representa o Contexto de Multitela. "Gerenciador de Multitelas" é um componente de gerenciamento único fornecido por uma implementação de plataforma que, através dos atributos definidos nesse relatório descritivo, permite o uso eficaz de telas múltiplas. 0 Gerenciador de Multitelas é também chamado de um gerenciador de telas múltiplas.
0 Gerenciador de Multitelas é definido por uma classe ^ultiScreenManager' abaixo usada numa modalidade da presente invenção, e a classe 'MultiScreenManager' é um tipo de Java para representar o Gerenciador de Multitelas.
"Tela de Sobreposição" é uma tela lógica, que é atribuída a uma categoria de telas de sobreposição, que será mais tarde explicada. A ordem ζ de uma tela de sobreposição coloca uma tela de sobreposição correspondente mais à frente do que todas as outras telas sem sobreposição.
"Configuração de Multitelas por Exibição" é uma configuração de multitelas sem exibição que define ou pode ser usada para definir o conjunto de telas ativas ou potencialmente ativas associadas a uma determinada tela de exibição. Cada tela de exibição subjacente na configuração de multitelas por plataforma atualmente ativa contém uma variável de estado para definir sua configuração de multitelas por exibição ativa. "Configuração de Multitelas por Plataforma" é uma
configuração de multitelas de exibição que define atualmente ou pode ser usada para definir o conjunto de telas ativas ou potencialmente ativas de exibição. A configuração de multitelas por plataforma atualmente ativa é uma variável de estado da instância singleton do gerenciador de multitelas.
"Tela PiP" é uma tela lógica, que é atribuída a uma categoria de telas PiP. Uma tela PiP se intercepta tipicamente como uma tela Principal, e aparece mais à frente (na ordem z) do que essa tela Principal. "Tela PoP" é uma tela lógica, que é atribuída a uma
categoria de telas PoP. Uma tela PoP é colocada tipicamente lado a lado com uma ou mais telas PoP distintas, a fim de preencher o espaço de uma tela de exibição.
"Tela" é um conjunto de recursos (lógicos e possivelmente físicos) que permitem a apresentação de certa combinação de uma coloração de fundo, uma imagem de fundo, vídeo, e gráficos. A cor de fundo, a imagem de fundo, o vídeo, e os gráficos são exibidos através de um HScreenDevice fornecido pela HAVI. A cor de fundo e a imagem de fundo podem ser exibidas com um HBackgroundDevice, o vídeo pode ser exibido com um HVideoDevice, e os gráficos podem ser exibidos com um HGraphicDevice. A Tela pode incluir um HBackgroundDevice, um HVideoDevice, e um HGraphicDevice. Uma tela é classificada por uma tela de exibição ou uma tela lógica.
"Tela Padrão" é uma tela mais altamente acessável dentre uma pluralidade de telas. "Dispositivo de Tela Padrão" é o dispositivo de tela mais altamente acessável dentre uma pluralidade de dispositivos de tela. 0 Dispositivo de Tela Padrão pode ser um dentre o HBackgroundDevice, HVideoDevice, e HGraphicDevice.
"Categoria de Telas" é um grupamento de telas, de acordo com suas características de uso ou de capacidade de configuração.
"Identificador de Telas" é uma designação de plataforma exclusiva de uma tela subjacente e de seus respectivos recursos, que permite a discriminação entre telas de diferentes categorias ou de telas dentro de uma única categoria.
"Tipo de Telas" é uma divisão de telas de alto nível em dois tipos: telas de exibição e telas lógicas.
"Serviço" é um conteúdo multimídia incluindo uma pluralidade de componentes de serviço.
"Componente de Serviço" é um elemento de serviço incluindo um componente de vídeo, um componente de áudio, e um componente de dados. 0 componente de dados inclui vários itens de informações para serviço e aplicativos executados numa plataforma.
"Contexto de Serviço" é um objeto incluindo recursos sobre serviços a serem implementados, dispositivos, informações sobre estado etc.
A Extensão OCAP MSM define uma coleção de funcionalidade e comportamentos para permitir o uso eficaz de exibições múltiplas e telas lógicas múltiplas sobre implementações de plataforma que suportem esses atributos.
"Ouvinte da Configuração de Multitelas" é usado para fornecer notificações a respeito de mudanças induzidas por sistema e aplicativo no estado global do caso MultiScreenManager ou do estado de certa HScreen de exibição com relação à configuração de multitelas por plataforma ou por certa exibição, respectivamente, ou de4 mudanças numa instância de MultiScreenConfiguration especifica. 0 Ouvinte da Configuração de Multitelas é definido por uma interface
'MultiScreenConfigurationListener' abaixo de uma modalidade da presente invenção, e a interface
'MultiScreenConfigurationListener' no relatório descritivo é um tipo de Java para representar o Ouvinte da Configuração de Multitelas.
"Ouvinte do Contexto de Multitelas" é usado para fornecer notificações a respeito de mudanças induzidas por sistema e aplicativo em um MultiScreenContext. 0 Contexto de Multitelas é definido por uma interface 'MultiScreenContextListener' abaixo de uma modalidade da presente invenção. A interface 'MultiScreenContextListener' no relatório descritivo é um tipo de Java para representar o Ouvinte do Contexto de Multitelas.
"Evento da Configuração de Multitelas" é usado para informar mudanças no estado global da instância MultiScreenManager ou no estado de certa HScreen de exibição com relação à configuração de multitelas por plataforma ou por certa exibição, respectivamente, ou mudanças em uma instância MultiScreenConfiguration especifica. O Evento da Configuração de Multitelas é definido por uma interface 'MultiScreenConfiguration' abaixo de uma modalidade da presente invenção. A interface xMultiScreenConfiguration' no relatório descritivo é um tipo de Java para representar o Evento da Configuração de Multitelas.
"Evento do Contexto de Multitelas" é usado para informar uma mudança de um MultiScreenContext a ouvintes interessados. O Evento do Contexto de Multitelas é definido por uma interface 'MultiScreenContextEvent' abaixo de uma modalidade da presente invenção. A interface 'MultiScreenContextEvent' no relatório descritivo é um tipo de Java para representar o Evento de Contexto de Multitelas.
"Evento de Multitelas" é uma classe de bases
abstratas usada para organizar códigos de identificação de eventos usados por tipos de eventos distintos relacionados à funcionalidade para gerenciamento de telas múltiplas. O Evento de Multitelas é definido por uma interface 'MultiScreenEvent' abaixo de uma modalidade da presente invenção. A interface 'MultiScreenEvent' no relatório descritivo é um tipo de Java para representar o Evento de Multitelas.
0 Evento dos Recursos de Multitelas é usado para informar mudanças a respeito do estado dos recursos de multitelas relacionados aos recursos. 0 Evento dos Recursos de Multitelas é definido por uma interface ^MultiScreenResourceEvent' de uma modalidade da presente invenção, que será mais tarde explicada. A interface ^MultiScreenResourceEvent' no relatório descritivo é um tipo de Java para representar o Evento dos Recursos de Multitelas.
0 nivel, em que uma implementação de plataforma especifica presta suporte a essa extensão, é determinado pelo fabricante do dispositivo e da plataforma, ou por outros perfis externos dessa extensão, e é tipicamente ditado pelo tipo e capacidade de configuração do hardware, incluindo o número de sintonizadores ou fontes de entrada independentes disponíveis, o número de canais decodificadores de vídeo disponíveis, o número de exibições integradas, o número de portas de saída de vídeo (e de áudio) independentes, a quantidade de memória disponível para armazenamento temporário de vídeo e dos gráficos, e outros recursos não especificados.
Um sistema de multitelas e gerenciamento de multitelas introduzidos na presente invenção serão explicados com referência às figs. 2 a 10. A fig. 2 ilustra uma relação entre uma tela lógica, uma tela de exibição, e um mapeador de exibição, de acordo com uma modalidade da presente invenção.
Uma tela em um gerenciamento de multitelas inclui 5 um conjunto de telas lógicas 210 e um conjunto de telas de exibição 230. O conjunto de telas lógicas 210 é associado ao conjunto de telas de exibição 230 através de um mapeador de exibição 220. O mapeador de exibição é um processo lógico para combinar o espaço de coordenadas normalizadas 10 de uma tela lógica com o espaço de coordenadas normalizadas de uma tela de exibição. Isso é, uma ou mais telas lógicas podem ser exibidas em posições desejadas numa tela de exibição através do mapeador de exibição 220.
Por exemplo, um sistema de gerenciamento de 15 multitelas, de acordo com uma modalidade da presente invenção, inclui o mapeador de exibição 220, uma pluralidade de telas lógicas 212, 214, e 216, e uma pluralidade de telas de exibição 240, 250, e 260. Pelo menos uma das telas lógicas 212, 214, e 216 é exibida em 20 cada uma das telas de exibição 240, 250, e 260 por meio do mapeador de exibição 220.
Isso é, devido ao mapeador de exibição 220, as regiões de tela 242 e 244 podem ser dispostas em paralelo dentro da tela de exibição 240. A tela lógica 212 é contraída e disposta na região de tela 242, e a tela lógica 214 possui também sua escala alterada e é disposta na região de tela 244. Da mesma forma, a tela lógica 214 é disposta na região mais traseira de tela 252 dentro da tela de exibição 250. A tela lógica 254 é disposta numa região de tela 254 da tela de exibição 250. A tela lógica 212 é 5 disposta numa região mais traseira de tela 262 da tela de exibição 260. A tela lógica 214 é contraída e disposta numa região de tela 264 da tela de exibição 260. A tela lógica 216 é contraída e disposta numa região de tela 266 da tela de exibição 260.
A fig. 3 é um diagrama de blocos de um sistema de
televisão (TV) digital 300, onde um gerenciador de multitelas pode ser implementado, de acordo com uma modalidade da presente invenção.
O sistema de TV digital 300 inclui uma unidade receptora de sinais de difusão 310, uma unidade processadora de sinais digitais 320, uma unidade processadora de serviços de multimídia 330, uma unidade de saída 340 e uma unidade de exibição 350.
A unidade receptora de sinais de difusão 310 recebe um sinal de difusão via cabo. De modo alternativo, uma unidade receptora de sinais de difusão 310 pode receber um sinal de difusão terrestre ou um sinal de difusão via satélite.
A unidade processadora de sinais digitais 320 reconfigura o serviço pelo uso de um componente de serviço recebido pela unidade receptora de sinal de difusão 310. A unidade processadora de sinais de multimídia 330 gera uma tela lógica para apresentar o serviço reconfigurado pela unidade processadora de sinais digitais 320 e transmite a tela lógica gerada para a unidade de saída 340.
A unidade de saída 340 gera uma tela de exibição, e mapeia a tela de exibição para a tela lógica. Isto é, a tela lógica é associada à tela de exibição, assim que o serviço da tela lógica é associado à tela de exibição. 10 Embora o serviço seja associado à tela lógica e, a seguir, à tela de exibição na fig. 3, a presente invenção não é limitada ao mesmo, e o serviço pode ser diretamente associado à tela de exibição.
Quando a unidade de saída 340 incluir uma ou mais portas de saída, as portas de saída podem ser associadas à tela de exibição.
A fim de que o sistema de TV digital 300 implemente a funcionalidade do gerenciamento de multitelas, associações entre a tela lógica, a tela de exibição, e as 20 portas de saída devem ser determinadas na unidade processadora de sinais de multimídia 330 e na unidade de saída 340. Uma pluralidade de telas pode ser gerada, quando uma plataforma for implementada, e a implementação da funcionalidade gerenciadora de multitelas, a saber, a 25 configuração, gerenciamento e alteração de multitelas fornecem uma interface de programação de aplicativo (API) para MSM, que será mais tarde explicada.
A unidade de exibição 350 inclui um dispositivo físico de tela de exibição, no qual a tela de exibição é exibida.
A fig. 4 ilustra uma pluralidade de conteúdos
apresentada num sistema de TV digital 400, de acordo com uma modalidade da presente invenção.
O sistema de TV digital 400 pode apresentar ao mesmo tempo um conteúdo de difusão terrestre 410, um 10 conteúdo de difusão via cabo 420, e um conteúdo de dados do gravador de vídeo pessoal (PVR) 430. Isto é, se o gerenciamento de multitelas da presente invenção puder ser implementado no módulo de TV digital/ Decodificador de Sinais (DTV/ STB), o conteúdo de difusão terrestre 410, o 15 conteúdo de difusão via cabo 420, e o conteúdo dos dados PVR 430 são respectivamente associados às telas lógicas, e cada tela lógica é exibida numa tela de exibição 450.
Visto que o gerenciamento de multitelas da presente invenção define associações entre uma ou mais telas lógicas 20 e uma ou mais telas de exibição, uma ou mais telas lógicas podem ser mapeadas para uma tela de exibição. Isto é, uma tela lógica 452 do conteúdo de difusão terrestre 410 é disposta numa região de tela 452 da tela de exibição 45, e uma tela lógica 456 do conteúdo de difusão via cabo 420 é 25 disposta numa região de tela 456 da tela de exibição 450. Além disso, devido ao módulo DTV/ STB, uma tela lógica 454 do conteúdo PVR 430 é disposta numa região de tela 454 da tela de exibição 450.
Isto é, as telas lógicas 452, 454, e 466 podem ter sua escala ajustada, e ser dispostas em várias posições da tela de exibição 450, numa ordem predeterminada.
As figs. 5A e 5B ilustram respectivamente um serviço não-abstrato e um serviço abstrato, de acordo com uma modalidade da presente invenção.
Na fig. 5A, um conjunto de serviços 510 é um conjunto de serviços não-abstratos. Na fig. 5B, um conjunto de serviços 550 é um conjunto de serviços abstratos. 0 conjunto de serviços não-abstratos 510 inclui um serviço de vídeo 520, um serviço de áudio 530, e um serviço de aplicativo 540. Em contraste, o conjunto de serviços abstratos 550 inclui um aplicativo de vídeo 560 e um aplicativo de áudio 570. Isto é, o conjunto de serviços abstratos 550 é um conjunto de serviços incluindo somente serviços de aplicativos, sem qualquer serviço de vídeo ou serviço de áudio, e o conjunto de serviços não abstratos 510 é um conjunto de serviços, incluindo outros serviços, bem como um serviço de aplicativo.
A fig. 6 ilustra uma relação entre um contexto de telas 600 e vários métodos.
Com referência à fig. 6, o contexto de telas 600 inclui uma ordem z 610, uma área de exibição 620, uma visibilidade 630, uma tela de exibição associada 640, e um contexto de serviços associados 650.
A ordem z 610 significa informações para determinar, em qual ordem, uma pluralidade de telas lógicas é exibida numa tela de exibição.
A área de exibição 620 é uma região, na qual o
espaço de coordenadas de tela normalizadas de uma tela lógica é mapeado para o espaço de coordenadas de tela normalizadas de uma tela de exibição.
A visibilidade 630 determina, se uma tela lógica deve ser exibida de forma visivel ou invisível numa tela de exibição.
A tela de exibição associada 640 é uma tela de exibição, à qual uma tela lógica é associada. O contexto de serviços associados 650 é um contexto de serviços conectado a uma tela lógica, ou a uma tela de exibição.
O contexto de telas 600 pode definir ou adicionar os atributos através de um método 'definir/ adicionar', e obter ou remover os atributos através de um método 'obter/ remover' . Isto é, o contexto de telas 600 pode definir e 20 alterar os atributos, pelo uso dos métodos 'definir/ adicionar' e 'obter/ remover'.
Embora não mostrado na fig. 6,· o contexto de telas 600 pode incluir, não apenas a ordem z, a região de exibição, a visibilidade, a tela de exibição associada, e o contexto de serviços associados, mas também pelo menos um dentre um enfoque de áudio associado à tela atual, uma fonte de áudio associada à tela atual, uma ordem z de um dispositivo de tela associado à tela atual, uma área de exibição associada à tela atual, e uma porta de saída de vídeo associada à tela atual.
As figs. 7A e 7B ilustram resultados numa tela de
exibição, de acordo com a ordem z de uma tela lógica.
Conforme a ordem z de um elemento correspondente aumenta, o elemento correspondente é disposto numa posição superior (mais à frente). Com referência à fig. 7A, quando 10 ordens z de uma tela lógica Ia 710 e uma tela lógica 2a 720, que são dispostas numa tela de exibição 700, forem respectivamente 1 e 2, a tela lógica 2a 720 é superior (mais à frente) do que a tela lógica Ia 710.
Da mesma forma, com referência à fig. 7B, quando ordens z de uma tela lógica Ib 7 60 e uma tela lógica 2b 770, que são dispostas numa tela de exibição 750, forem respectivamente 2 e 1, a tela lógica Ib 760 é superior (mais à frente) do que a tela lógica 2b 770.
O conceito e a seqüência das ordens z se aplica a dispositivos de tela, bem como a telas lógicas.
As figs. 8A e 8B ilustram associações entre um contexto de serviços, uma tela lógica, e uma tela de exibição.
Um método para associar, de forma direta/ indireta, serviços com uma tela de exibição, quando um serviço 810 incluindo um conteúdo de vídeo 812, um conteúdo de áudio 814, e um conteúdo de aplicativo 816 for recebido, será explicado.
Com referência à fig. 8A, quando o serviço 810 for associado a uma tela lógica vazia 820 e a uma tela lógica 5 80.3, com a qual o serviço 810 é associado a uma tela de exibição 840, o serviço 810 é exibido 850 numa tela de exibição 840. Isto é, a tela de exibição 840 e o serviço 810 são indiretamente associados entre si através das telas lógicas 820 e 830.
Com referência à fig. 8B, quando serviço 810 for
associado à tela de exibição vazia 840, o serviço 810 é exibido 860 na tela de exibição 840. Isto é, a tela de exibição 840 e o serviço 810 são diretamente associados entre si.
Por conseguinte, visto que o serviço 810 é
associado, de forma direta/ indireta, à tela de exibição 840, o serviço 810 pode ser exibido na tela de exibição 840, e quando finalmente associado a uma porta de saida, pode ser emitido.
As figs. 9A e 9B ilustram resultados numa tela de
exibição, de acordo com uma área de exibição, para a qual uma tela lógica é mapeada.
Com referência à fig. 9A, quando uma tela lógica 910 é mapeada para uma área global 930 de uma tela de
exibição 920 através de um mapeador de exibição 220, a tela lógica 910 é exibida 940 na área global 930 da tela de exibição 920.
Em contraste, com referência à fig. 9B, quando a tela lógica 910 é mapeada para uma área global 950 da tela de exibição 920 através do mapeador de exibição 220, a tela lógica 910 é exibida 960 na área 950 da tela de exibição 920.
Isto é, ao contrário de um método PiP convencional, uma tela de conteúdo exibida numa parte de uma tela global pode ser apresentada em escala.
A fig. 10 ilustra associações entre uma pluralidade
de serviços, uma pluralidade de telas lógicas, e uma tela de exibição.
Um aparelho para gerenciamento de multitelas, de acordo com uma modalidade da presente invenção, pode ao 15 mesmo tempo mapear uma primeira tela lógica 1030, com a qual um primeiro serviço 1010 é associado, e uma segunda tela lógica 1040, com a qual um segundo serviço 1020 é associado, a uma tela de exibição 1050. Quando a tela de exibição 1050, para a qual as primeira e segunda telas 20 lógicas 1030 e 1040 são mapeadas, for associada a uma porta de saída 1060, um resultado de saída final 1070 pode ser apresentado numa unidade de exibição.
Isto é, o aparelho de gerenciamento de multitelas pode incluir uma pluralidade de serviços, uma pluralidade de telas lógicas, uma pluralidade de telas de exibição, e uma pluralidade de portas de saída. Por conseguinte, o aparelho de gerenciamento de multitelas pode apresentar uma pluralidade de serviços e uma pluralidade de telas através de uma pluralidade de portas de saída.
Não só uma configuração de multitelas descrita com 5 referência às figs. 2 a 10, mas também um método e aparelho para gerenciamento de multitelas, de acordo com uma modalidade da presente invenção, definem operações para configuração, mudança e gerenciamento do estado de multitelas. Isto é, visto que o método e aparelho para 10 gerenciamento de multitelas são previstos com várias capacidades: obter, alterar, definir, e descobrir uma relação de mapeamento entre uma tela lógica e uma tela de exibição, associações entre um dispositivo de tela, um contexto de serviço, uma tela de exibição, e uma porta de 15 saída de vídeo, uma atribuição focalizadora de áudio, uma configuração de multitelas por exibição, e uma configuração multitelas por plataforma; para reservar recursos, e liberar e reserva de recursos; e monitorar e notificar várias mudanças, e várias capacidades para precondições e 20 pós-condições para várias mudanças, uma configuração de multitelas e gerenciamento de multitelas suave pode ser executado. Várias capacidades para a configuração de multitelas e gerenciamento de multitelas serão abaixo explicadas.
Um método e aparelho para gerenciamento de
multitelas aplicados a um sistema OCAP, de acordo com uma modalidade da presente invenção, serão agora explicados.
A presente invenção define uma extensão modulada para um Perfil OCAP para dispositivos Host OCAP, que prestam suporte à funcionalidade do Gerenciamento de 5 Multitelas, conforme definida por esse relatório descritivo. A funcionalidade do Gerenciamento de Multitelas é definida como uma interface de software padronizada para permitir que aplicativos OCAP interoperáveis usem com eficiência os recursos de um dispositivo Host que preste 10 suporte a telas múltiplas.
A Extensão OCAP MSM é uma extensão do Perfil OCAP que inclui todas as APIs, formatos de conteúdo e dados, e protocolos demandados, até o nível dos aplicativos. Aplicativos desenvolvidos para a Extensão OCAP MSM serão 15 executados nos dispositivos Host compatíveis com OpenCable. A Extensão OCAP MSM permite que os operadores via cabo implantem aplicativos interoperáveis para gerenciar funcionalidade de telas múltiplas nos dispositivos Host compatíveis com OpenCable conectados às suas redes.
Esse perfil permite que os operadores via cabo
tenham uma interface padronizada para gerenciar funcionalidade de multitelas e seu estado, tais como telas PiP e PoP entre múltiplos fornecedores de dispositivos Host.
A Extensão OCAP MSM é aplicável a uma ampla
variedade de sistemas de hardware e operacionais para permitir flexibilidade na implementação por parte dos fabricantes de Eletrônicos do Consumidor (CE). Um principal objetivo na definição da Extensão OCAP MSM é permitir implementações competitivas por parte dos fabricantes de 5 CE, enquanto que mantendo uma interface programática compatível e interoperável para uso por aplicativos definidos por operadores via cabo, bem como aplicativos independentes da rede via cabo, que desejam estar cientes da funcionalidade de multitelas.
Um método e aparelho de gerenciamento de multitelas
é uma Extensão para uma norma OCAP existente. A Extensão OCAP MSM assume o formato de mecanismos (descritores) de sinalização, APIsf comportamento (semântica) de plataformas, e limitações de uso dos aplicativos.
Nessa modalidade, as APIs definidas pelo relatório
descrito assumem o formato de extensões para funcionalidade existente e APIs definidas pela Interface de Usuário HAVI, conforme definido pelo pacote org.havi.ui. De modo particular, grande parte da funcionalidade aqui definida 20 assume o formato de interfaces implementadas pela classe concreta usada por uma plataforma para dar suporte à classe org.havi.ui.HScreen.
A instância HScreen é uma tela abaixo. Um tipo de Java ou um parâmetro é citado em inglês entre as marcas de aspas (") . Uma classe de Java é um conjunto de vários parâmetros e métodos para objetos dos mesmos tipos, e uma interface de Java especifica capacidade de objetos que
interoperam dentro de uma classe. Uma modalidade, de acordo
com a presente invenção, pode gerenciar e configurar uma
multitela, e alterar a configuração através de um método
definido por cada classe. Uma instância é um objeto gerado
a partir de uma classe.
t
Vários métodos, vários campos, e vários tipos de Java em modalidades de um gerenciamento de multitelas são definidos nas figs. IlA a 23D.
A Extensão OCAP MSM define um descritor opcional
usado para sinalizar comportamento relacionado a MSM para um aplicativo Xlet. Na ausência desse descritor, semânticas padrão são definidas.
A Extensão OCAP MSM estende o Perfil OCAP através 15 do descritor para uso de telas múltiplas, conforme abaixo definido. Um aplicativo OCAP sinalizado numa AIT ou numa XAIT pode incluir um, mas não mais de um, descritor para uso de telas múltiplas no enlace do descritor de aplicativos que se aplica ao aplicativo.
Se nenhum descritor para uso de telas múltiplas
estiver presente, no erilace do descritor de aplicativos de determinado aplicativo, então um dispositivo Host OCAP deve considerar isso, como sendo equivalente à presença de um descritor para uso de telas múltiplas, cujo sinalizador 25 terminate_on_condition é '0' limpo, cujo sinalizador dissalow_partial_display_graphics_mapping é Ό' limpo, e cujo sinalizador allow_default_device_reconfig é '0' limpo.
0 eifeito produzido pelo acima é tal que, por padrão, (1) ura plano de gráficos padrão de aplicativos pode ser ajustado em escala (em conjunto com seus planos de vídeo e d.e fundo padrão) para uma porção de uma tela de exibição através dos meios de uma tela lógica intermediária, (2) um dispositivo de tela padrão de aplicativo :não pode ser arbitrariamente reconfigurado ou ter seus recursos anulados, e (3) se essa última condição tiver que ser necessariamente mantida, então o aplicativo é suspenso, oiu se a suspensão não for possível, encerrado. No relatório deescritivo, o termo "suspender' é usado quando um aplicativo .interrompe temporariamente um processo, enquanto que usando continuamente um recurso. Além disso, o termo 'encerrar' é usado, quando um aplicativo fica sem recursos e finaliza, inteiramente um processo.
Um descritor para uso de telas múltiplas inclui o descriptor_tag, descriptor_length, terminate_on__condition, dissalow_partial_display_graphics_mapping, allow_default_ device_xeconfig, e reservado.
Descriptor_tag é um número inteiro não-assinado de 8 bits com um valor 0x6E que identifica esse descritor para uso de tel.as múltiplas.
De:scriptor_length é um número inteiro não-assinado de 8 bits„ que especifica o número de bytes imediatamente após esse.· campo. Para esse relatório descritivo, exatamente um byte deve se seguir ao campo descriptor_length.
Terminate_on_condition é um sinalizador de 1 bit indicando o efeito desejado nesse ciclo de vida do aplicativo, no caso do 'disallow_part ial__
display_graphics_mapping' ser definido como '1' ou allow_default_device_reconfig' for '0' limpo, e a condição especificada por um dos dois respectivos sinalizadores demandar a suspensão ou encerramento do aplicativo.
Se esse sinalizador for definido como '1', então a 10 plataforma OCAP deve encerrar (destruir) o aplicativo no início da condição de controle; de outra forma, se esse sinalizador for '0', então a plataforma OCAP deve tentar suspender o aplicativo e, se incapaz de suspendê-lo, deve encerrar o aplicativo no início da condição de controle.
Se um aplicativo for suspenso, como resultado desse
sinalizador ser falso, então quando nenhuma condição de controle for obtida, o aplicativo deve ser retomado, mas se a retomada não for possível, p. ex., devido a uma disponibilidade insuficiente de recursos, deve ser encerrado (destruído).
No presente contexto, o termo 'suspender' deve ser interpretado como equivalente a invocar o método 'pauseXset()' da instancia Xlet inicial do aplicativo afetado.
Disallow_partial_display_graphics__mapping é um
sinalizador de 1 bit, indicando que o aplicativo não pode continuar a rodar, quando mudanças ou contextos de serviço da configuração de multitelas forem trocados ou movidos entre telas, de modo que o plano de gráficos padrão do aplicativo (dispositivo de tela) deve ser ajustado em 5 escala para operar numa tela lógica, cuja área de tela não é mapeada para a extensão completa da tela de exibição.
Se o disallow_partial_display_graphics_mapping for ajustado em '1', então o aplicativo deve ser suspenso ou encerrado no início dessa condição, de acordo com o valor 10 do sinalizador 'terminate_on_condition' acima; de outra forma, se o disallow_partial_display_graphics_mapping for definido como '0', então o aplicativo não é suspenso ou encerrado no início dessa condição.
Allow_default_device_reconfig é um sinalizador de 1 bit, indicando que o aplicativo pode continuar a rodar, quando uma configuração de multitelas for alterada ou contextos de serviço forem trocados ou movidos entre telas, de forma que (1) um ou mais dos seguintes parâmetros de configuração do dispositivo de tela (HScreenConfiguration) de determinado dispositivo de tela padrão for alterado: a área da tela, resolução de pixels,ou relação de aspecto dos pixels; ou (2) os recursos subjacentes de um ou mais dispositivos de tela padrão, que foram apresentado antes da mudança de configuração ou troca/ deslocamento do contexto de serviços não estiver mais disponível apos a mudança da configuração ou a troca/ deslocamento do contexto de serviços.
Se o 'Allow_default_device_reconfig' for '0', então o aplicativo deve ser suspenso ou encerrado no início dessa condição, de acordo com o valor do sinalizador 5 ' terminate__on_condition' acima; de outra forma, se o 'Allow_default_device_reconfig' for ajustado para 'lr, então o aplicativo não é suspenso ou encerrado no início dessa condição.
Um aplicativo que sinalize o sinalizador 'allow_default_device_reconfig' na posição de estado '1' é previsto registrar ouvintes e processar tipos de Java HScreenConfigurationEvent e org.ocap.ui.MultiScreenEvent.
É reservado um campo que está reservado para padronização futura e deve ter um valor todo constituído de '1' .
Uma interface de programação de aplicativo para a Extensão OCAP MSM será agora explicada.
Uma modalidade da presente invenção será agora explicada com um tipo de Java. Porém, a presente modalidade 20 não é limitada ao tipo de Java, e deverá ser entendido pelas pessoas versadas na técnica que vários métodos podem ser usados para alcançar o objetivo e efeito da presente invenção.
A Extensão OCAP MSM define uma coleção de funcionalidade e comportamentos para permitir o uso eficaz de exibições múltiplas e telas lógicas múltiplas em implementações de plataforma que suportem esses atributos. A Extensão MSM estende o Perfil OCAP através da adição da funcionalidade de Gerenciamento de Telas Múltiplas especificada abaixo.
Dispositivos Host OCAP, que suportem a Extensão
OCAP MSM, devem implementar semânticas, como especificado pelas subseções a seguir.
MSM será agora explicado.
A HScreen padrão para um aplicativo OCAP é uma instância HScreen que representa o conjunto atualmente ativo dos dispositivos de tela subjacentes padrão e suas configurações de tela HAVi atualmente ativas.
Outras informações sobre uma HScreen padrão do aplicativo são descritas em detalhes num método de Atribuição de HScreen Padrão e
"MultiScreenManager.getDefaultHScreen()'.
Um dispositivo Host OCAP, que implementa a classe MultiScreenManager, deve fornecer uma instância HScreen lógica distinta para cada tela de visualização secundária e primária, que seja exposta à implementação OCAP, isto é, ambas as telas de visualização PiP e não-PiP.
As telas serão agora explicadas.
0 subsistema da Interface de Usuário HAVi (chamado como o modelo HAVi da linha de base) define a 'classe HScreen' , como sendo uma descrição "da composição de saída final de um dispositivo", e indica que "uma plataforma com duas exibições independentes deverão prestar suporte a duas instâncias dessa classe". Com a introdução da Extensão MSM, essa definição é estendida para introduzir uma distinção entre uma tela de exibição e uma tela lógica.
Em primeiro lugar, a classe 'HScreen' estendida a
partir da 'tela de exibição'' será agora explicada.
Uma tela, que modela uma "composição de saida final de um dispositivo de exibição fisico" é chamada pelo MSM como uma 'tela de exibição' . Em contraste, uma tela que é 10 mapeada para uma tela de exibição através de um processo de transformação do sistema de coordenação lógica, por hardware ou software, é chamada de uma 'tela lógica'.
Uma tela de exibição é associada a (mapeada para) zero ou mais portas de saída de vídeo, que podem ser 15 individualmente ativadas ou desativadas, conforme definido por VideoOutputPort. Se uma tela de exibição não for associada a qualquer porta de saída de vídeo, então qualquer apresentação, que esteja ativa no contexto da tela de exibição, não é processada por um dispositivo de 20 apresentação.
No contexto dó MSM, saídas de áudio e sua associação com uma tela de exibição, a fim de processar conteúdo de áudio, são consideradas como sendo implícitas pelas associações da porta de saída de vídeo da tela de exibição.
Uma tela de exibição designa a si própria ou uma das telas lógicas, que mapeiam para ela, como sendo sua 'tela focalizadora de áudio'. A 'tela focalizadora de áudio' é usada para determinar quais recursos de áudio são produzidos em quaisquer saídas de áudio (implícitas)
associadas às portas de saída de vídeo, para as quais a tela de exibição é mapeada. Na presente modalidade, as saídas de áudio podem ser saídas de áudio incorporadas. Essa distinção somente é necessária, quando houver múltiplas telas lógicas, que forem simultaneamente mapeadas 10 e apresentadas numa tela de exibição, tal como será o caso numa configuração de multitelas PiP ou PoP.
Se nenhuma tela lógica for mapeada para uma tela de exibição, ou focalização de áudio não for associada a uma tela lógica, então a focalização de áudio é atribuída à 15 tela de exibição propriamente dita. Nesse caso, quaisquer instâncias HScreenDevice associadas à tela de exibição se tornam candidatas em potencial como fontes de áudio.
Uma tela lógica é uma extensão natural do modelo HAVi final de uma HScreen, onde se lê "dispositivo" na 20 frase "a composição de saída final de um dispositivo" como um "dispositivo lógico", em oposição a um dispositivo físico. Essa extensão é diferente da noção normalmente entendida de um drive de disco lógico, onde uma porção de um drive de disco físico é vista, como se ela fosse um 25 drive de disco independente em si.
A partir da perspectiva de um aplicativo OCAP, uma tela lógica, para todas as intenções e finalidades, é a mesma que uma tela de exibição. Ela possui todos os atributos e comportamentos padrão de uma instância HScreen (não-multitela) existente: um conjunto de dispositivos de 5 fundo de tela, tela de vídeo e de gráficos padrão, um conjunto opcional de dispositivos de tela não padrão desses mesmos tipos, um ou mais conjuntos de configurações de dispositivos de tela coerentes, uma capacidade para modificar atomicamente um conjunto de dispositivos de tela, 10 a fim de estabelecer um conjunto coerente de configurações de tela para esses dispositivos, e um mecanismo para determinar a melhor configuração de um dispositivo de tela de um tipo específico, dado um gabarito de configuração do dispositivo de tela.
Cada tela lógica possui seu próprio espaço de
coordenadas de tela normalizadas, independentes, conforme definido pelo modelo HAVi da linha de base. Uma tela lógica é tipicamente associada a uma tela de exibição e a uma área de exibição naquela tela de exibição. Através dessa 20 associação, o espaço das coordenadas de tela normalizadas de uma tela lógica é mapeado para um retângulo de tela no espaço das coordenadas de tela normalizadas da tela de exibição. Embora uma área de exibição seja apresentada com o retângulo de tela aqui a seguir para fins de conveniência 25 de explicação, a presente invenção não é limitada ao retângulo. Esse retângulo de tela (aqui a seguir chamado de área de exibição) pode coincidir com toda a tela de exibição, em cujo caso o mapeamento é um mapeamento de identificação entre os dois espaços de coordenadas de tela normalizadas.
De modo alternativo, o retângulo de tela pode coincidir com uma porção da tela de exibição. Nesse caso, a área de exibição pode ser inteiramente contida dentro da região visível da tela de exibição, ou ela pode ficar 10 inteiramente fora da região visível da tela de exibição. Ou o retângulo de tela pode ser interceptado com as partes visíveis e não visíveis (externas) da tela de exibição.
Se alguma porção da área de exibição se estender para fora da área de exibição visível da tela de exibição 15 (isto é, retângulo de tela externo [0,0], [1,1] da tela de exibição) , então é uma opção de implementação, se as áreas são externamente vinculadas à região (nominalmente) visível da tela de exibição.
Cada tela lógica possui um conjunto de dispositivos 20 de tela padrão, cada qual representado como uma instância HScreenDevice de um subtipo específico: HBackgroundDevice, HVideoDevice, ou HGraphicsDevice . Além disso, similar ao modelo HAVi da linha de base, cada tela lógica pode possuir um conjunto de dispositivos adicionais de tela não padrão 25 de cada um desses subtipos.
Como no modelo HAVi da linha de base, cada recurso do dispositivo de tela subjacente utilizado por uma tela lógica é identificado por um subtipo padrão da classe HScreenDevice, e cada um desses dispositivos de tela possui seu próprio conjunto de parâmetro de configuração, conforme 5 definido pelo modelo HAVi final e representado por meio de um subtipo padrão da classe HScreenConfiguration.
Por exemplo, um desses parâmetros é moldado por uma preferência de modelo HScreenConfigurationTemplate. PIXEL_RESOLUTION,, e é acessável usando uma função de ajuda 10 'HScreenDevice,getPixelResolution()'. ■ Como no caso das instâncias HScreenDevice numa implementação de não- multitelas do modelo HAVi da linha de base, esse parâmetro está também presente e acessável através dos mesmos métodos, quando for feita referência a um dispositivo de 15 tela de uma tela lógica.
Porém, no caso de uma tela lógica, como aqui definido, a resolução de pixel se refere à resolução do dispositivo de tela no contexto do espaço de coordenadas normalizadas da tela lógica, e não da tela de exibição, 20 para a qual essa tela lógica é mapeada. Por último, a resolução em pixels de uma tela de exibição de uma tela lógica é mapeada, por meio de uma transformação do espaço de coordenadas de segunda ordem, para o espaço de coordenadas de tela normalizadas de uma tela de exibição. 25 Porém, um aplicativo, que estiver usando a tela lógica, não precisa estar ciente dessa transformação de segunda ordem, visto que a partir de uma perspectiva de processamento lógico, a tela lógica não é diferente de um sinal de saída final para um dispositivo de exibição física.
0 mapeamento entre um espaço de coordenadas 5 normalizadas da tela lógica e a área de exibição associada no espaço de coordenadas normalizadas da tela de exibição (transformação do espaço de coordenadas da segunda ordem acima citada), aqui a seguir chamado de um mapeamento de exibição, é definido como um processo de mapeamento lógico, 10 o que significa dizer que uma implementação MSM não precisa dedicar um componente de hardware específico a esse processo de mapeamento.
Por exemplo, uma opção de implementação é modelar (internamente) a união de todos os conjuntos dos 15 dispositivos de tela (com recurso atribuído) de todas as telas lógicas que são mapeadas para uma tela de exibição específica, como um único conjunto de dispositivos de tela nessa única tela de exibição, onde certas restrições a respeito da coerência dos pixels e da ordem z entre esse 20 conjunto de dispositivos de tela se aplicam.
De modo particular, se determinado conjunto de regras de coerência dos pixels se aplicar a um determinado (sub)conjunto de dispositivos de tela em determinada tela lógica, então essas regras de coerência dos pixels também 25 se aplicam, quando esse dispositivos de tela forem considerados parte integrante do conjunto maior dos dispositivos de tela (conceitualmente mapeados) na tela de exibição.
Da mesma forma, a ordem z dos dispositivos de tela (conceitualmente mapeados) na tela de exibição deve 5 respeitar (1) a ordenação z dos dispositivos de tela dentro de cada tela lógica, e (2) a ordenação z entre telas lógicas. Em outras palavras, os dispositivos de tela (conceitualmente mapeados) das diferentes telas lógicas não são intercalados.
Quer o processo de mapeamento de exibição (a partir
de uma tela lógica para uma exibição) seja realizado por meios lógicos ou físicos (hardware), a entidade que efetua esse processo é chamada de um mapeador de exibição para um determinado par de <tela lógica, tela de exibição>.
Uma associação da porta de saída de vídeo de uma
tela lógica será agora explicada.
Sob circunstâncias típicas, uma tela lógica é indiretamente associada a uma porta de saída de vídeo, em virtude de ser mapeada para uma tela de exibição, onde uma 20 tela de exibição é diretamente associada à porta de saída de vídeo. Porém, a fim de permitir mais flexibilidade, o a MSM permite que uma tela lógica seja diretamente associada a uma porta de saída de vídeo.
Uma tela lógica pode ser diretamente associada a uma porta de saída de vídeo em duas circunstâncias: (1) quando a tela lógica for órfã, i. e., não for mapeada para qualquer tela de exibição, mas estiver operando de modo independente, como se ela fosse uma tela de exibição (em cujo caso, ela pode ser diretamente associada a uma porta de saída de vídeo), e (2) quando a tela lógica for pai de 5 uma tela de exibição e, assim, for indiretamente associada às associações da porta de saída de vídeo da tela de exibição, e, ao mesmo tempo, estiver operando de modo independente, como se ela fosse uma tela de exibição e fosse, além disso, diretamente associada à outra porta de 10 saída de vídeo. Casos de uso, que incorporam essas duas circunstâncias, são descritos a seguir, respectivamente.
1. Uma tela lógica órfã é anexada a um contexto de serviço, cujo conteúdo está sendo gravado, p. ex. , por funcionalidade do gravador de vídeo digital (DVR), e for
desejado, mesmo tempo, emitir esse conteúdo para uma porta auxiliar de saída de vídeo, p. ex., uma 1394 ou uma porta composta NTSC.
2. Uma tela lógica for apresentada como uma tela PiP mapeada para uma tela de exibição numa configuração de
multitelas PiP (onde uma a tela Principal é também ao mesmo tempo apresentada) e essa tela de exibição for associada à porta primária de saída de vídeo; além disso, é desejado que essa tela PiP lógica seja emitida diretamente para uma porta auxiliar de saída de vídeo, p. ex., uma 1394 ou uma 25 porta composta NTSC.
Telas lógicas são indiretamente associadas às portas de saída de áudio, quer através de (1) associação indireta com uma porta de saída de vídeo, através - de mapeamento para uma tela de exibição, ou (2) associação direta com uma porta de saída de vídeo da mesma forma que a 5 associação da porta de saída de vídeo.
Quando múltiplas telas lógicas são mapeadas para uma tela de exibição, somente uma das telas lógicas contribui de modo específico com fontes de áudio para processamento em um determinado momento. Essa tela lógica 10 específica é chamada de tela focalizadora de áudio de uma tela de exibição, e é determinada pelo uso de um método 'MutiScreenConfigurable Context.assignAudioFocus'.
Devido ao fato. de uma única tela lógica poder ter múltiplas fontes de áudio, como derivado de suas instâncias 15 HScreenDevice padrão, bem como das instâncias não-padrão, é desejável controlar quais dessas instâncias contribuem para a saída de áudio combinada da tela lógica. Essas fontes são determinadas pelo uso dos métodos 'MultiScreenConfigurable Context.add,removeAudio Sources 20 Categorias de tela serão agora explicadas.
Cada tela numa configuração de multitelas é atribuída a uma das seguintes categorias predefinidas de tela ou uma categoria dependente da plataforma, cuja representação em cadeia começa com 'x-':
'None(SCREEN_CATEGORY_NONE) ' , 'Display(SCREEN_
CATEGORY DISPLAY)', 'Main(SCREEN CATEGORY MAIN)', 'Pi P(SCREEN_CATEGORY_PIP)', PoP(SCREEN_CATEGORY_POP)',
'Sobreposição(SCREEN_CATEGORY_OVERLAY)', e
'General(SCREEN_CATEGORY_GENERAL)'.
Essas categorias de tela são definidas formalmente como uma numeração em Cadeia extensível pelos campos acima especificados de MultiScreenConfiguration. Uma tela é categorizada como SCREEN_CATEGORY_NON, somente se uma categoria não mais específica for aplicada.
'Identificador de Tela' será agora explicado.
A cada conjunto identificável dos recursos de tela,
que representa coletivamente uma tela de exibição ou lógica, é atribuído um único identificador (cadeia), onde o escopo de exclusividade inclui todas as telas acessáveis através de todas as configurações de multitelas ativas em 15 um determinado momento. Uma implementação do MSM pode ampliar esse escopo de exclusividade para incluir todas as configurações de multitelas não-ativas em um determinado momento e, além disso, pode ampliar o escopo para incluir todas as durações contínuas de tempo, sobre as quais a 20 plataforma opera (entre ciclos de inicialização a frio).
Uma implementação do MSM, que suporta a adição dinâmica em tempo de execução das telas de exibição ou das telas lógicas, deve ser preparada para atribuir identificadores, no momento da adição, que mantêm as restrições acima num escopo mínimo de exclusividade.
Uma configuração de multitelas inclui uma configuração de multitelas de exibição por plataforma e a configuração de multitelas por exibição.
A qualquer dado momento, um subconjunto especifico (normalmente, mas não necessariamente adequado) de telas de 5 exibição está ativo no contexto de uma implementação MSM, no sentido de que essas telas de exibição, se marcadas como visíveis, estão ao mesmo tempo apresentando conteúdo, ou são capazes de apresentar conteúdo de uma ou mais telas lógicas. Tal subconjunto de telas de exibição é chamado de 10 configuração de multitelas de exibição por plataforma e é modelado pelo MSM usando um objeto que implementa a interface MultiScreenConfiguration, e onde o método getConfigurationType() dessa interface retorna MultiScreen Configuration.SCREEN_CONFIGURATION_ DISPLAY.
A configuração de multitelas por plataforma
atualmente ativa pode ser obtida com
'MultiScreenManager.getMultiScreenConfiguration() ' e
estabelecida com 'MultiScreenManager.setMultiScreen
Configuration()'.
Além disso, para cada tela de exibição, que
participe de uma configuração de multitelas de plataforma, existe um subconjunto específico (normalmente adequado) de telas lógicas (existentes), que é ativado no contexto daquela tela de exibição, assim que, se determinada tela 25 lógica for marcada como visível, então ela está ao mesmo tempo apresentando conteúdo, ou é capaz de apresentar conteúdo de um ou mais contextos de serviço ou media players. Tal subconjunto de telas lógicas é chamado de uma configuração de multitelas por exibição e é modelado por MSM usando um objeto que implemente a interface 5 MultiScreenConfiguration. O método getConfigurationType() da interface MultiScreenConfiguration retorna um valor diferente de MultiScreenConfiguration. SCREEN_C0NFIGURAT10N _D1SPLAY.
A configuração de multitelas por exibição 10 atualmente ativa de uma tela de exibição específica pode ser obtida com o método MultiScreenContext. getMultiScreenConfiguration() e estabelecida com Multi ScreenConfigurableContext.setMultiScreenConfiguration(). O conjunto de todas as configurações de multitelas por 15 exibição utilizáveis e acessáveis (que podem ser usadas com uma tela de exibição específica) pode ser obtido com Multi ScreenContext.getMultiScreenConfigurations().
O conjunto de todas as configurações de multitelas acessáveis (quer atualmente em uso ou não em uso, e quer uma configuração de multitelas por plataforma ou por exibição) pode ser obtido com MultiScreenManager. getMultiScreenConfigurations().
Para cada aplicativo OCAP não-encerrado, os recursos subjacentes de exatamente uma instância HScreen de determinada configuração de multitelas atualmente ativa de uma tela de exibição da configuração de multitelas por plataforma atualmente ativa deve ser a mesma que (equivalente a) os recursos subjacentes da tela padrão do aplicativo OCAP.
A cada conjunto de telas, que for modelado como uma configuração de multitelas, é atribuído um dos seguintes tipos de configuração predefinidos ou um tipo de configuração dependente da plataforma, cuja representação em cadeia começa com "x-".
0 tipo de configuração de multitelas inclui:
· Exibição (SCREEN_CONFIGURATION_DISPLAY),
• Não-PiP (SCREEN_CONFIGURATION_NON_PIP),
• PiP (SCREEN_CONFIGURATION_PIP),
• PoP (SCREEN_CONFIGURATION_POP), e
• Geral (SCREEN_CONFIGURATION_GENERAL).
Esses tipos de configuração são definidos
formalmente como uma enumeração de Cadeia extensível pelos campos acima especificados da interface MultiScreen Configuration.
Uma configuração de multitelas designa uma de suas 20 telas acessáveis, como sendo a tela de uma associação do contexto de serviço padrão. Essa tela é usada para determinar a associação padrão entre um contexto de serviço e uma tela na ausência de informações mais específicas de uma associação.
Cada tipo predefinido de configuração de multitelas
define uma tela específica, como sendo sua tela inicial de uma associação padrão do contexto de serviço. Após o tempo de inicialização da plataforma, a tela de uma associação do contexto de serviço padrão de uma configuração de multitelas pode ser alterada pelo uso de MultiScreenConfiguration.setDefaultServiceContext
Screen(..). A tela atual de uma associação padrão do contexto de serviço de uma configuração de multitelas pode ser obtida pelo uso de MultiScreenConfiguration.getDefault ServiceContext Screen(). A
Para mais informações, MultiScreenManager. setMulti
ScreenConfiguration(), MultiScreenConfigurable Context. setMultiScreenConfiguration() e, de modo particular, o parâmetro serviceContextAssociations desses métodos será agora explicado.
Uma configuração padrão de multitelas inclui uma
configuração padrão de multitelas por plataforma e uma configuração padrão de multitelas por exibição.
Após realizar uma inicialização a frio (ou reiniciação) de um Dispositivo Host OCAP que implementa a 20 Extensão MSM, a configuração padrão de multitelas por plataforma (inicialmente ativa) deve ser a mesma configuração de multitelas que estava previamente ativa para reiniciação a frio. Se nenhuma configuração prévia de multitelas por plataforma for conhecida, então a 25 configuração padrão de multitelas por plataforma deve ser a primeira configuração de multitelas retornada por MultiScreen Manager.getMultiScreenConfigurations (SCREEN_ CONFIGURATION_DISPLAY) , que é associada a uma tela de exibição, que, por sua vez, é associada a uma configuração de multitelas por exibição do tipo de configuração SCREEN_CONFIGURATION_NON_PIP.
Da mesma forma, a configuração padrão de multitelas por exibição (inicialmente ativa) de cada tela de exibição da configuração padrão de multitelas por plataforma deve ser a mesma configuração de multitelas que estava 10 previamente ativa para reiniciação a frio. Se nenhuma configuração prévia de multitelas por exibição for conhecida para determinada tela de exibição, então ela deve ser a primeira configuração de multitelas do tipo de configuração SCREEN_CONFIGURATION_NON_PIP, que é retornada 15 por Multi ScreenContext.getMultiScreenConfigurations (SCREEN_ CONFIGURATION_NON_PiP) naquela tela de exibição.
Ao realizar qualquer outro tipo de reiniciação, reinicialização, ou restauração (não-fria), de um Dispositivo Host OCAP ou ambiente OCAP que implemente a 20 Extensão MSM, então a configuração padrão de multitelas (inicialmente ativa) deve ser a mesma configuração de multitelas que estava previamente ativa para reiniciação, reinicialização, ou restauração não-fria de um ambiente.
A definição de um dispositivo de tela será agora explicada.
A instância HScreen representa um único sinal de saida de vídeo independente de um dispositivo. Dispositivos com múltiplos sinais de saída de vídeo independentes devem prestar suporte a múltiplas instâncias de uma classe HScreenDevice. Um sinal de saída de vídeo é criado pela 5 adição das contribuições dos dispositivos representados por um número de objetos herdados da classe HScreenDevice. Esses objetos podem ser objetos HGraphicsDevice, objetos HVideoDevice, e objetos HBackgroundDevice. Um determinado HScreen pode prestar suporte a qualquer número de qualquer 10 um desses objetos, na medida em que a API esteja envolvida. Porém, determinado formato de perfil pode restringir o número dos objetos. Na realidade atual, uma instância de cada é tudo que pode ser razoavelmente esperado, como estando presente.
Uma classe HBackgroundDevice representa o último
plano de fundo de uma tela, a saber, uma cor do plano de fundo e uma imagem do plano de fundo. 0 plano de fundo o mais detrás da pilha da composição de vídeo / gráficos. 0 plano de fundo pode cobrir potencialmente toda a área de 20 uma tela. Quando um dispositivo suporta múltiplos aplicativos na tela ao mesmo tempo (ou mesmo um gerenciador de janelas), o plano de fundo não é limitado por qualquer aplicativo ou janela particular. 0 direito para controle do plano de fundo de uma tela é um recurso escasso e 25 gerenciado como tal.
Uma classe HGraphicsDevice descreve os dispositivos gráficos de varredura que são disponíveis para um HScreen particular. Cada HGraphicsDevice possui um ou mais objetos HGraphicsConfiguration associados ao HGraphicsDevice.
Esses objetos especificam as diferentes configurações (definições), onde o HGraphicsDevice pode ser usado.
Uma classe HVideoDevice descreve os dispositivos lógicos de vídeo que podem contribuir para a aparência de uma tela particular. Cada HVideoDevice possui um ou mais 10 objetos HVideoConfiguration associados ao HVideoDevice. Esses objetos especificam as diferentes configurações (definições), onde o HVideoDevice pode ser usado. A classe HVideoDevice representa somente a apresentação de vídeo, e não fornece a seleção de qual vídeo deve ser apresentado.
A classe HscreenDevice, a classe HbackgroundDevice,
a classe HGraphicsDevice, e a classe HvideoDevice são definidas no pacote 'org.havi.ui' para a Interface de Usuário HAVi.
A classe public HBackgroundDevice estende uma HScreenDevice. A classe HBackgroundDevice descreve um dispositivo de plano de fundo representado por objetos herdados da classe HScreenDevice.
A classe public HGraphicsDevice estende uma HScreenDevice. A classe HGraphicsDevice descreve um dispositivo gráfico representado por objetos herdados da classe HScreenDevice. A classe public HVideoDevice estende o HscreenDevice. A classe HVideoDevice descreve um dispositivo de vídeo representado por objetos herdados da classe HScreenDevice.
A Alteração das Configurações de Multitelas será
agora explicada.
Uma configuração atual de multitelas pode ser alterada por um aplicativo privilegiado (para que um MonitorAppPermission("multiscreen.configuration") foi
concedido) por meio do método setMultiScreen Configuration(..) ou requestMultiScreenConfiguration
Change(..) da instância MultiScreenManager ou da interface MultiScreenConfigurableContext de determinada tela de exibição. Além disso, a configuração de multitelas atual 15 pode ser alterada pelo dispositivo Host propriamente dito, como resultado de outros eventos não definidos por esse relatório descritivo. Por exemplo, um fabricante pode fornecer uma tecla de controle remoto explícita, que faça com que a configuração de multitelas específica seja 20 ativada.
A despeito do que faça com que a configuração de multitelas atual seja alterada, as seguintes restrições devem ser aplicadas:
1. aplicar as precondições abaixo especificadas antes da alteração;
2. aplicar as etapas de processamento da alteração abaixo especificadas durante a alteração, durante cujo tempo as invariáveis de estado dinâmico abaixo especificadas são aplicadas; e
3. após a alteração, aplicar as pós-condições abaixo especificadas.
Para fins de melhorada interoperabilidade, um número dessas precondições e pós-condições é expresso em forma de pseudocódigo, na forma de declarações nas FIGS. 24A a 24C e 25A a 25E. As restrições expressas nas FIGS. 10 24A a 24C e 25A a 25E pretendem ser consistentes com o texto descritivo que aparece nas subseções a seguir. Para evitar dúvidas, o texto descritivo a seguir assumir prioridade sobre os códigos das FIGS. 24A a 24C e FIG. 25A a FIG. 25E no caso de uma discrepância ou cobertura parcial 15 pelo formato codificado. Apesar dessa priorização, as FIGS. 24A a 24C e FIGS. 25A a FIG. 25E devem ser aplicadas, para fins de determinação da conformidade de uma implementação interoperável da Extensão MSM.
Precondições para alteração das configurações de multitelas serão agora explicadas.
Antes de um evento MultiScreenConfigurationEvent. MULTI_SCREEN_CONFIGURATION_CHANGING, que é gerado como resultado de uma alteração da configuração de multitelas, as seguintes precondições ordenadas devem ser mantidas.
1. As Invariáveis de Estado Inativo abaixo
definidas devem ser satisfeitas. A Alteração das Etapas de Processamento será agora explicada.
A implementação MSM deve realizar as seguintes etapas ordenadas, a fim de efetuar uma alteração na configuração atual de multitelas.
1. Gerar um evento MultiScreenConfigurationEvent. MULTI_SCREEN_CONFIGURAT10N_CHANGING para distribuição de um aplicativo.
2. Iniciação nesse momento e até o tempo em que MultiScreenConfigurationEvent.MULTISCREENCONFIGURATION_
CHANGED for gerado, não permitir que um aplicativo OCAP (1) altere a configuração atual de multitelas, (2) reservar um HScreen ou um HScreenDevice e seus recursos subjacentes, ou (3) realize uma alteração na configuração do dispositivo de tela ou uma alteração no estado de contexto das multitelas.
3. Para cada aplicativo OCAP que tenha sido concedido MonitorAppPermission("multiscreen.configuration"), evocar o método notifyO de qualquer MultiScreenConfiguration Listener registrado, fornecendo
como argumento o MultiScreenConfigurationEvent.
MULTI_SCREEN_CONFIGURATION_ CHANGING acima gerado. Todos esses ouvintes registrados devem ser evocados antes da continuação para a próxima etapa. Porém, não é demandado que uma implementação MSM aguarde, para que qualquer ou 25 todos os ouvintes retornem do método notifyO antes da continuação. 4. Para qualquer instância HScreen, cujo estado MultiScreenContext acessável deve ou pode alterar, como resultado dessa alteração na configuração atual de multitelas, então, se a instância HScreen estiver
atualmente reservada por determinado aplicativo OCAP, diferente do aplicativo que evocou o método setMultiScreenConfiguration (..), ou reservado por qualquer aplicativo OCAP no caso dessa alteração ser um resultado de uma alteração iniciada pelo dispositivo Host (sem evocação 10 explícita desse método por um aplicativo OCAP), então, para cada HScreenDevice mencionado pela HScreen reservada, e, enquanto que adiando a notificação de quaisquer instâncias HScreenDeviceReleasedEvent geradas, evocar o método releaseDevice() e, se necessário, evocar o método release() 15 do ResourceClient que retém a reserva.
5. Para qualquer instância HScreenDevice, cujo estado HScreenConfiguration acessável for ou pode ser alterado, como resultado dessa alteração na configuração atual de multitelas, então, se a instância HScreenDevice
for atualmente reservada por determinado aplicativo OCAP diferente do aplicativo que evocou o método setMultiScreenConfiguration(..), ou reservada por qualquer aplicativo OCAP, no caso dessa alteração ser um resultado de uma alteração iniciada por dispositivo Host (sem 25 evocação explícita desse método por um aplicativo OCAP), então, para esse HScreenDevice, e, enquanto que adiando a notificação de quaisquer instâncias HScreenDeviceReleased Event geradas, evocar o método releaseDevice() , e, se necessário, evocar o método de release() do ResourceClient que retém a reserva.
6. Para qualquer instância HScreenDevice, cujo
estado HScreenConfiguration acessável for ou puder ser alterado, como resultado dessa alteração na configuração atual de multitelas, gerar, mas adiar a notificação de, a instância HScreenConfigurationEvent correspondente.
7. Para qualquer instância HScreen, cujo estado
MultiScreenContext acessável for ou puder ser alterado, como resultado dessa alteração na configuração atual de multitelas, gerar, mas adiar notificação de, uma instância MultiScreenContextEvent correspondente.
8. Se qualquer MultiScreenConfigurationListener,
cujo método de notifyO foi evocado na etapa (3) acima, não tiver ainda retornado, então aguardar até que (1) todos esses métodos de notifyO tenham retornado, ou (2) um período de tempo de pelo menos cinco segundos e não 20 superior a 30 segundos (em tempo real) tenha transcorrido desde que o primeiro desses métodos foi evocado.
9. Realizar todas as alterações necessárias para satisfazer as pós-condições abaixo especificadas.
10. Para cada instância HScreenDeviceReleasedEvent acima gerada e na ordem gerada, então, para cada aplicativo
OCAP, evocar o método statusChanged() de qualquer ResourceStatusListener registrado, fornecendo como argumento a instância HscreenDeviceReleasedEvent.
11. Para cada instância HScreenConfigurationEvent acima gerada e na ordem gerada, então, para cada aplicativo
OCAP, evocar o método report() de qualquer HScreenConfigurationListener registrado, fornecendo como argumento a instância HScreenConfigurationEvent.
12. Para cada instância MultiScreenContextEvent acima gerada e na ordem gerada, então, para cada aplicativo
OCAP, evocar o método notifyO de qualquer MultiScreenContextListener registrado, fornecendo como argumento a instância MultiScreenContextEvent.
13. Gerar um evento MultiScreenConfiguration Event.MULTI_SCREEN_CONFIGURATION_CHANGED para distribuição
de um aplicativo.
14. Para cada aplicativo OCAP, evocar o método notifyO de qualquer MultiScreenConfigurationListener registrado, fornecendo como argumento o MultiScreen ConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED acima
gerado.
Pós-condições de uma alteração na configuração de multitelas serão agora explicadas.
Após um evento MultiScreenConfigurationEvent. MULTI_SCREEN_CONFIGURATION_CHANGED, que é gerado como
resultado de uma alteração na configuração de multitelas, as seguintes pós-condições ordenadas devem ser mantidas. 1. As Invariáveis de Estado Inativo abaixo definidas devem ser satisfeitas.
2. A configuração atual de multitelas é a nova configuração.
3. A nova tela padrão deve ser a mesma instância
(de objeto), que a tela padrão antiga.
4. Se dispositivos de plano de fundo de tela padrão existirem na tela padrão, nas antiga e nova configurações de multitelas, então, a menos que o aplicativo sinalize allow_default_DEVICE_reconfig como '1',
a. o novo dispositivo de plano de fundo de tela padrão deve ser a mesma instância que o antigo dispositivo de plano de fundo de tela padrão, e
b. o novo dispositivo de plano de fundo - de tela padrão deve ter a mesma área de tela, resolução de pixels,
e taxa de proporção" de pixels, que ele tinha com o antigo dispositivo de plano de fundo de tela padrão.
Se o aplicativo sinalizar allow_default_DEVICE_ reconfig como '1' e o dispositivo de plano de fundo de tela 20 padrão existir na antiga configuração de multitelas, mas não na nova configuração de multitelas, então qualquer referência ao antigo dispositivo de plano de fundo de tela padrão deve ser restaurada, a fim de ser equivalente ao dispositivo de plano de fundo de tela vazia.
5. Se dispositivos padrão de tela de vídeo
existirem na tela padrão, nas antiga e nova configurações de multitelas, então, a menos que o aplicativo sinalize allow_default_DEVICE_reconfig como '1',
a. o novo dispositivo de tela de vídeo padrão deve ser a mesma instância, que o antigo dispositivo de
tela de vídeo padrão, e
b. o novo dispositivo de tela de vídeo padrão deve ter a mesma área de tela, resolução de pixels, e taxa de proporção de pixels, que ele tinha com o antigo dispositivo de tela de vídeo padrão.
Se o aplicativo sinalizar allow_default_DEVICE_
reconfig como '1' e um dispositivo de tela de vídeo padrão existir na antiga configuração de multitelas, mas não na nova configuração de multitelas, então qualquer referência ao antigo dispositivo de tela de vídeo padrão deve ser 15 restaurada, a fim de ser equivalente ao dispositivo de tela de vídeo vazia.
6. Se dispositivos de tela gráfica padrão existir na tela padrão, nas antiga e nova configurações de multitelas, então, a menos que o aplicativo sinalize allow_default_DEVICE reconfig como '1',
a. o novo dispositivo de tela gráfica padrão deve ser a mesma instância que o antigo dispositivo de tela gráfica padrão, e
b. o novo dispositivo de tela gráfica padrão deve ter a mesma área de tela, resolução de pixels, e taxa de
proporção de pixels, que ele tinha com o antigo dispositivo de tela gráfica padrão.
Se o aplicativo sinalizar allow_default_DEVICE_ reconfig como '1' e um dispositivo de tela gráfica padrão existir na antiga configuração de multitelas, mas não na 5 nova configuração de multitelas, então qualquer referência ao antigo dispositivo de tela gráfica padrão deve ser restaurada, a fim de ser equivalente ao dispositivo de tela gráfica vazia.
7. Para cada referência de tela não-padrão obtida antes da reconf iguração, não sendo mais uma tela não-
padrão, então ela deve ser equivalente a uma tela vazia; de outro modo, ela não devem ser equivalente a uma tela vazia.
8. Para cada referência de dispositivo de tela não- padrão obtida antes da reconfiguração, não sendo mais um
dispositivo de tela não-padrão, então ela deve ser equivalente a um dispositivo de tela vazia; de outro modo, ela não devem ser equivalente a um dispositivo de tela vazia.
Invariáveis de Estado Inativo serão agora definidas.
Antes de um evento MultiScreenConfigurationEvent. MULTI_SCREEN_CONFIGURATION_CHANGING e após um evento MultiScreen ConfigurationEvent.MULTI_SCREEN_CONFIGURATION_ CHANGED correspondente, as seguintes invariáveis ordenadas devem ser mantidas:
I. Deve haver um gerenciador de multitelas sem alteração, atual;
2. Deve haver uma configuração de multitelas por plataforma sem alteração, atual;
3. Deve haver uma configuração de multitelas por exibição sem alteração, atual, para cada tela de exibição;
4. Deve haver um conjunto não-vazio, sem alteração, de configurações de multitelas acessáveis;
5. A configuração atual de multitelas por plataforma deve ser uma configuração acessável (para um
aplicativo apropriadamente privilegiado);
6. Cada configuração atual de multitelas por exibição deve ser uma configuração acessável (para um aplicativo apropriadamente privilegiado);
7. Deve haver um conjunto de telas não-vazias, sem alteração, na configuração atual de multitelas por
plataforma;
8. Deve haver um conjunto de telas não-vazias, sem alteração, em cada configuração atual de multitelas por exibição;
9. As telas na configuração atual de multitelas por
plataforma não devem ser vazias;
10. As telas em cada configuração atual de multitelas por exibição não devem ser vazias;
11. Quaisquer duas entradas de tela distintas em qualquer configuração atual de multitelas não devem
representar os mesmo recursos; 12. Deve haver uma tela padrão atual;
13. A tela padrão atual não deve ser equivalente à a tela vazia;
14. Exatamente uma entrada de tela em determinada configuração atual de multitelas deve representar os mesmos
recursos que a tela padrão;
15. Deve haver um conjunto não-vazio de telas acessáveis;
16. A tela padrão atual deve ser um membro distinto do conjunto de telas acessáveis;
17. Qualquer dispositivo de plano de fundo de tela da tela padrão atual não deve ser equivalente ao dispositivo de plano de fundo de tela vazia;
18. Qualquer dispositivo de tela de vídeo da tela padrão atual não deve ser equivalente ao dispositivo de
tela de vídeo vazia;
19. Qualquer dispositivo de tela gráfica da tela padrão atual não deve ser equivalente ao dispositivo de tela gráfica vazia.
Invariáveis de Estado Dinâmico serão agora
definidas.
Após um evento MultiScreenConfigurationEvent. MULTI_SCREEN_CONFIGURATI0N_CHANGING e antes de um evento MultiScreenConfigurationEvent. MULTI_SCREEN_C0NFIGURATI0N_ CHANGED correspondente, as seguintes invariáveis ordenadas devem ser mantidas: 1. Deve haver um gerenciador de multitelas atual, sem alteração;
2. Deve haver uma configuração de multitelas atual, mas possivelmente alterada;
3. Deve haver um conjunto não-vazio, possivelmente
alterado, de configurações de multitelas acessáveis;
4. A configuração de multitelas atual deve ser uma configuração acessável;
5. Deve haver um conjunto de telas não-vazias, mas possivelmente alterado, na configuração atual de
multitelas;
6. As telas na configuração atual de multitelas não devem ser vazias;
7. Quaisquer duas entradas de tela distintas na configuração atual de multitelas não devem representar os
mesmo recursos;
8. Deve haver uma tela padrão atual, mas possivelmente alterável;
9. A tela padrão atual não deve ser equivalente à tela vazia;
10. Exatamente uma entrada de tela na configuração atual de multitelas deve representar os mesmos recursos que a tela padrão;
11. Deve haver um conjunto não-vazio, mas possivelmente alterável, de telas acessáveis;
12. A tela padrão atual deve ser um membro distinto do conjunto de telas acessáveis;
13. Qualquer dispositivo de plano de fundo de tela da tela padrão atual não deve ser equivalente ao dispositivo de plano de fundo da tela vazia;
14. Qualquer dispositivo de tela de vídeo da tela
padrão atual não deve ser equivalente ao dispositivo de tela de vídeo vazia;
15. Qualquer dispositivo de tela gráfica da tela padrão atual não deve ser equivalente ao dispositivo de tela gráfica vazia.
Extensões do Modelo HAVi da linha de base, às quais a presente invenção se aplica, serão agora explicadas.
O Gerenciador de Telas Múltiplas inclui o uso de certas extensões comportamentais e de utilização para o Modelo HAVi da linha de base e, de modo particular, para os seguintes tipos HAVi definidos, como abaixo descrito.
Como acima especificado, cada instância HScreen é caracterizada como uma tela de exibição ou uma tela lógica, conforme definido pelo Gerenciador de Telas Múltiplas.
Uma distinção é feita pelo Gerenciador de Telas
Múltiplas a respeito de uma instância HScreen e dos recursos subjacentes representados por essa instância. Em particular, o seguinte estado subjacente associado a uma instância HScreen pode sofrer alteração durante sua extensão temporal.
Em outras palavras, o número de dispositivos subjacentes de plano de fundo de tela, a configuração do dispositivo de tela (conjunto de parâmetros) desses dispositivos subjacentes de plano de fundo de tela, o dispositivo subjacente de plano de fundo de tela, que é associado à instância HBackgroundDevice padrão, o número de dispositivos subjacentes de tela de vídeo, a configuração do dispositivo de tela (conjunto de parâmetros) desses dispositivos subjacentes de tela de vídeo, o dispositivo de tela subjacente de vídeo que é associado à instância HVideoDevice padrão, o número de dispositivos subjacentes de tela gráfica, o dispositivo de tela subjacente gráfica que é associado à instância HGraphicsDevice padrão, a configuração do dispositivo de tela (conjunto de parâmetros) desses dispositivos subjacentes de tela gráfica pode sofrer alteração ao longo de sua extensão temporal.
Cada instância HScreen deve implementar a interface MultiScreenContext ou, se a instância HScreen representar recursos subjacentes de tela que forem configuráveis, de acordo com a funcionalidade definida por
MultiScreenConfigurableContext, então a instância HScreen deve implementar a interface MultiScreenConfigurable Context, ao invés de Multi ScreenContext (observe que a interface MultiScreen ConfigurableContext é uma subinterface da interface MultiScreenContext).
O método estático HScreen.getHScreens () deve
retornar o mesmo valor que MultiScreenManager.getlnstance ().getScreens.
O método estático HScreen.getDefault HScreenO deve retornar o mesmo valor que MultiScreen-
Manager.getlnstance().getDefaultScreen().
A Atribuição HScreen Padrão será agora explicada.
Quando um aplicativo for inicialmente executado, o aplicativo deve ser inicialmente associado a um conjunto de telas acessáveis, conforme seriam retornadas por HScreen.getHScreens0 e, em segundo lugar, ser atribuído um 10 HScreen padrão, de acordo com as seguintes regras, onde uma primeira regra que se aplica é usada, e as restantes são ignoradas:
1. Se o ServiceContext SC, a cujo Serviço selecionado o aplicativo é sinalizado, for associado
somente a uma tela (subjacente), então use essa tela como a
tela padrão.
/
2. De outro modo, se SC for associado a múltiplas telas (subjacentes), então se uma dessas telas for categorizada como uma tela principal, i. e.,
getScreenCategory0 retornar MultiScreenConfiguration. SCREEN_CATEGORY_MAIN, então use a primeira dessas telas principais aparecendo na matriz de telas retornada por HScreen.getHScreens() como a tela padrão.
3. De outro modo (associado a múltiplas telas, nenhuma delas for uma tela principal), use a primeira tela
aparecendo na matriz de telas retornada por HScreen.getHScreens() como a tela padrão.
MSM introduz uma instância HScreen especialmente definida, conhecida como uma HScreen vazia, que é uma única instância imutável de (uma sub-classe) da classe HScreen, 5 que é usada para fins de estabelecer um estado conhecido, bem definido, numa instância HScreen (nominalmente não- vazia).
A HScreen vazia, chamada de ES abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do
aplicativo, ES é uma única instância (de objeto);
2. ES implementa as seguintes interfaces: MultiScreenContext, MultiScreenConfigurableContext,
ResourceProxy, e ResourceServer;
3. ES.getDefaultHBackgroundDevice() deve retornar
um HBackgroundDevice, cujo estado é equivalente ao HBackgroundDevice vazio abaixo definido;
4. ES.getDefaultHVideoDevice() deve retornar um HVideoDevice, cujo estado é equivalente ao HVideoDevice
vazio abaixo definido;
5. ES.getDefaultHGraphicsDevice() deve retornar um HGraphicsDevice, cujo estado é equivalente ao HScreenDeviee vazio abaixo definido;
6. ES.getBestConfiguration(HBackground Config Template hbc) deve retornar ES.getDefaultBackground
Device().getBestConfiguration(hbc); 7. ES.getBestConfiguration(HVideoConfigTemplate hvc) deve retornar ES.getDefaultVideoDevice().getBest Configuration (hvc);
8. ES.getBestConfiguration(HGraphicsConfig Template hgc) deve retornar ES.getDefaultGraphics
Device().getBestConfiguration (hgc);
9. ES.getBackgroundDevices() deve retornar novo HBackgroundDevice[1] {ES.getDefaultHBackgroundDevice()};
10. ES.getVideoDevices() deve retornar novo HVideoDevice[1] {ES.getDefaultHVideoDevice()};
11. ES.getGraphicsDevices() deve retornar novo HGraphicsDevice[1]{ES.getDefaultHGraphicsDevice()};
12. ES.getCoherentScreenConfigurations(..) deve retornar nulo;
13. ES.setCoherentScreenConfigurations(.. ) deve
gerar HConfigurationException;
14. ((MultiScreenContext)ES).getScreenType() deve retornar MultiScreenContext.SCREEN_TYPE_LOGICAL;
15. ((MultiScreenContext)ES).getDisplayScreen() deve retornar nulo;
16. ((MultiScreenContext)ES).getDisplayArea() deve retornar nulo;
17. ((MultiScreenContext) ES) .getOutputPorts() deve retornar nulo;
18. ((MultiScreenContext)ES).getServiceContexts()
deve retornar novo ServiceContext[0]; 19. ((MultiScreenContext) ES) .getVisible() deve retornar falso;
20. ((MultiScreenContext) ES) .getZOrder() deve retornar -1;
21. ((MultiScreenContext) ES) .addSereenContext
ListenerO não deve produzir qualquer efeito colateral;
22. ((MultiScreenConfigurableContext)ES).setDisplay Screen(..) deve gerar IllegalStateException, a menos que SecurityException se aplique;
23. ((MultiScreenConfigurableContext)ES).set
DisplayArea(..) deve gerar IllegalStateException, a menos que SecurityException se aplique;
24. ((MultiScreenConfigurableContext)ES).set Visible (..) deve gerar IllegalStateException, a menos que
SecurityException se aplique;
25. ((MultiScreenConfigurableContext)ES).set ZOrder(..) deve gerar IllegalStateException, a menos que SecurityException se aplique;
26. ((MultiScreenConfigurableContext)ES).add
OutputPort(..) deve gerar IllegalStateException, a menos
que SecurityException se aplique;
27. ((MultiScreenConfIgurableContext)ES).add ServieeContext(..) deve gerar IllegalStateException, a menos que SecurityException se aplique;
28. ((ResourceProxy) ES) .getClient () deve retornar
nulo. Se duas instâncias HScreenDevice, SDl e SD2, forem equivalentes com relação a seus recursos subjacentes, i. e., se sameResources(SD1,SD2) retornar verdadeiro, então SDl.getIDstring() deve retornar o mesmo valor que 5 SD2.getIDstring(); de outro modo, SDl.getIDstring() deve retornar o mesmo valor que SD2.getIDstring().
Qualquer tentativa por parte de um aplicativo OCAP para reservar um HScreenDevice, cujos recursos subjacentes do dispositivo de tela não forem contidos inteiramente 10 dentro do conjunto de recursos subjacentes do dispositivo de- tela mencionado por uma configuração de multitelas atualmente ativa, deve fazer com que um HPermissionDeniedException seja gerado.
A restrição acima se destina a impedir que um 15 aplicativo reserve um recurso do dispositivo de tela, quando esse recurso não for incluído no conjunto de recursos subjacentes representados por determinada configuração de multitelas atualmente ativa. Tal situação pode se aplicar no caso de uma partição de recursos do 20 dispositivo de tela entre uma configuração de multitelas ativa e determinada configuração de multitelas não-ativa.
A Atribuição HScreenDevice padrão será agora explicada.
0 conjunto padrão dos dispositivos de tela acessáveis é atribuído a um aplicativo por atribuição de uma tela padrão, como acima descrito. Na atribuição padrão para HScreen S, os dispositivos de tela padrão atribuídos ao aplicativo devem ser determinados por:
S . getDefaultHBackgroundDevice() , S.getDefaultHVideo
DeviceO, e S.getDefaultHGraphicsDevice().
Se a tela padrão tiver mais de um dispositivo de
tela de um tipo específico, então o processo para determinar, qual desses dispositivos de tela é o dispositivo de tela padrão desse tipo específico para essa tela, deve permanecer dependente da plataforma, e tal 10 atribuição não deve ser dependente de um aplicativo interoperável.
0 MSM introduz um conjunto especialmente definido de instâncias HScreenDevice vazias dos sub-tipos definidos: HBackgroundDevice, HVideoDevice, e HGraphicsDevice. Essas 15 instâncias, chamadas de ED abaixo, devem satisfazer as seguintes restrições, além de suas restrições específicas de subtipo definidas sob os subtítulos subsequentes:
1. ED.getIDString() deve retornar a cadeia vazia"";
2. ED.getScreenAspectRatio0 deve retornar nova
2 0 Dimension();
3. ED.addMultiScreenConfigurationListener(..) não deve produzir qualquer efeito colateral;
4. ED.reserveDevice(ResourceClient) deve retornar
falso;
5. ED.releaseDevice0 não deve produzir qualquer
efeito colateral; 6. ED.getClient() deve retornar nulo.
O HBackgroundDevice vazio, chamado de EBD abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EBD é uma única instância (de objeto);
2. EBD deve satisfazer as restrições especificadas para HScreenDevice vazias acima;
3. EBD.getDefaultConfiguration () deve retornar o HbackgroundConfiguration vazio, como abaixo definido;
4. EBD.getCurrentConfiguration() deve retornar o
mesmo valor que EBD.getDefaultConfiguration();
5. EBD.getBestConfiguration(..) deve retornar o mesmo valor que EBD.getDefaultConfiguration();
6. EBD.getConfigurations() deve retornar nova HBackgroundConfiguration[1] {getDefaultConfiguration()};
7. EBD.setBackgroundConfiguration() deve gerar HConfigurationException, a menos que SecurityException ou HPermissionDeniedException se apliquem.
O HVideoDevice vazio, chamado de EVD abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EVD é uma única instância (de objeto);
2. EVD deve satisfazer as restrições especificadas para HScreenDevice vazio acima;
3. EVD.getDefaultConfiguration () deve retornar o
HVideoConfiguration vazio, como abaixo definido; 4. EVD.getCurrentConfiguration () deve retornar o mesmo valor que EVD.getDefaultConfiguration();
5. EVD.getBestConfiguration(..) deve retornar o mesmo valor que EVD.getDefaultConfiguration();
6. EVD.getConfigurations() deve retornar nova
HVideoConfiguration[1] {getDefaultConfiguration()};
7. EVD.setVideoConfiguration() deve gerar
HConfigurationException, a menos que SecurityException ou HPermissionDeniedException se apliquem.
O HGraphicsDeviee vazio, chamado de EGD abaixo,
deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EGD é uma única instância (de objeto) ;
2. EGD deve satisfazer as restrições especificadas para HScreenDevice vazio acima;
3. EGD.getDefaultConfiguration () deve retornar o HGraphicsConfiguration vazio, como abaixo definido;
4. EGD.getCurrentConfiguration () deve retornar o mesmo valor que EGD.getDefaultConfiguration();
5. EGD.getBestConfiguration(..) deve retornar o
mesmo valor que EGD.getDefaultConfiguration();
6. EGD.getConfigurations() deve retornar nova HGraphicsConfiguration[1} {getDefaultConfiguration () };
7. EGD.setGraphicsConfiguration() deve gerar HConfigurationException, a menos que SecurityException ou
HPermissionDeniedException se apliquem. O MSM introduz um conjunto de instâncias vazias HScreenConfiguration especialmente definidas dos sub-tipos definidos: HBackgroundConfiguration, HVideo Configuration, e HGraphicsConfiguration.
Uma instância de uma HScreenConfiguration vazia,
chamada de EC abaixo, deve satisfazer as seguintes restrições, além de suas restrições específicas de sub-tipo definidas sob os subtítulos subsequentes:
I. EC.convertTo(..) deve retornar nulo;
2. EC.getFlickerFilter() deve retornar falso;
3. EC.getinterlaced() deve retornar falso;
4. EC.getOffset(. .) deve retornar nova Dimension();
5. EC.getPixelAspectRatio() deve retornar nova Dimension();
6. EC.getPixelResolution () deve retornar nova
Dimension ();
7. EC.getScreenArea() deve retornar nova HScreenRectangle(0,0,0,0) .
A HBackgroundConfiguration vazia, chamada de EBC
abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EBC é uma única instância (de objeto);
2. EBC deve satisfazer as restrições especificadas para HScreenConfiguration vazia acima;
3. EBC.getDevice() deve retornar a instância
HBackgroundDevice vazia acima definida; 4. EBC.getConfigTemplate() deve retornar a BackgroundConfigTemplate vazia abaixo definida;
5. EBC.getColor() DEVE retornar nova Color(O,O,O);
6. EBC.setColor() DEVE gerar HConfiguration
Exption.
A HVideoConfiguration vazia, chamada de EVC abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EVC é uma única instância (de objeto);
2. EVC deve satisfazer as restrições especificadas
para HScreenConfiguration vazia acima;
3. EVC.getDevice() deve retornar a instância HVideoDevice vazia acima definida.
*
4. EVC.getConfigTemplate() deve retornar a HVideoConfigTemplate vazia abaixo definida.
A HGraphicsConfiguration vazia, chamada de EGC abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EGC é uma única instância (de objeto);
2. EGC deve satisfazer as restrições especificadas
para HScreenConfiguration vazia acima;
3. EGC.getDevice() deve retornar a instância HGraphicsDevice vazia acima definida;
4. EGC.getConfigTemplate() deve retornar a HGraphicsConfigTemplate vazia abaixo definida;
5. EGC . getAUFont s () deve retornar nova FontfO]; 6. EGC.getCompatiblelmage (Entrada de imagens, dicas de HImageHints) deve retornar a entrada;
7. EGC.getComponentHScreenRectangle(..) deve retornar nulo;
8. EGC.getPixelCoordinatesHScreenRectangle(..) deve
retornar novo Retângulo();
9. EGC.getPunchThroughToBackgroundColor ( ..) deve retornar nulo;
10. EGC.dispose(Color) não deve produzir qualquer efeito colateral.
0 MSM introduz um conjunto de instâncias HScreenConfigTemplate vazias especialmente defiaidas dos sub-tipos definidos: ' . HBackgroundConfigTemplate,
HVideoConfigTemplate, e HGraphicsConfigTemplate.
Uma instância de uma HScreenConfigTemplate vazia,
chamada de ET abaixo, deve satisfazer as seguintes restrições, além de suas restrições específicas de sub- grupo definidas sob os subtítulos subsequentes:
1. ET.getPreferenceObject(int) deve gerar IllegalArgumentException;
2. ET.getPreferencePriority(int) deve retornar HScreenConfigTemplate.DONT_CARE;
3. ET.setPreference(int, int) deve gerar uma IllegalArgumentException;
4. ET.setPreference(int,Object,int) deve gerar uma
IllegalArgumentException. A HBackgroundConfigTemplate vazia, chamada de EBT abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EBT é uma única instância (de objeto);
2. EBT deve satisfazer as restrições especificadas
para HScreenConfigTemplate vazia acima;
3. EBT.isConfigSupported(HBackground Configuration) deve retornar falso.
A HVideoConfigTemplate vazia, chamada de EVT abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EVT é uma única instância (de objeto);
2. EVT deve satisfazer as restrições especificadas para HScreenConfigTemplate vazia acima;
3. EVT.isConfigSupported(HVideoConfiguration) deve
retornar falso.
A HGraphicsConfigTempiate vazia, chamada de EGT abaixo, deve satisfazer as seguintes restrições:
1. Dentro do escopo de uma referência do aplicativo, EGT é uma única instância (de objeto);
2. EGT deve satisfazer as restrições especificadas para HScreenConfigTemplate vazia acima;
3 . EGT.isConfigSupported(HGraphicsConfiguration) deve retornar falso.
HvideoDevice será agora explicado.
Se o uso de determinado mecanismo definido por esse relatório descritivo permitir mais de um pipeline de vídeo (constituído de pelo menos um decodificador de vídeo e de um componente para conversão de formato do decodificador) a ser associado aos (mapeado para os) recursos subjacentes do 5 dispositivo da tela de vídeo reapresentados por uma instância HVideoDevice, então um desses pipelines é designado como o pipeline contribuidor de vídeo, e os restantes são designados como pipelines não-contribuidores de vídeo. Um pipeline não-contribuidor de ~vídeo não deve 10 contribuir com informações de vídeo ou informações de áudio relacionadas aos recursos subjacentes do dispositivo da tela de vídeo representados por qualquer instância HVideoDevice.
0 pipeline contribuidor de vídeo deve ser determinado, a partir de um grupo de pipelines de vídeo potencialmente -contribuidores, de acordo com as seguintes regras ordenadas:
1. se somente um pipeline de vídeo dentre os possíveis pipelines de vídeo for associado à cadeia
elementar de vídeo ativa de determinado serviço não- abstrato, então esse pipeline de vídeo é o pipeline contribuidor;
2. de outro modo, se mais de um pipeline de vídeo dentre de possíveis pipelines de vídeo for associado à
cadeia elementar de vídeo ativa de determinado serviço não- abstrato, então o pipeline de vídeo do serviço não-abstrato mais recentemente selecionado é o pipeline contribuidor;
3. de outro modo, se somente um pipeline de vídeo dentre os possíveis pipelines de vídeo for associado a um um media player controlado por determinado serviço não-
abstrato, então o pipeline de vídeo desse media player é o pipeline contribuidor;
4. de outro modo, se mais de um pipeline de vídeo dentre os possíveis pipelines de vídeo for associado a um media player de determinado serviço não-abstrato, então o
pipeline de vídeo do media player mais recentemente iniciado (ou reiniciado após ser pausado ou parado) é o pipeline contribuidor;
5. de outro modo, se somente um pipeline de vídeo dentre os possíveis pipelines de vídeo for associado a um
media player controlado por determinado serviço abstrato, então o pipeline de vídeo desse media player é o pipeline contribuidor;
6. de outro modo, se mais de um pipeline de vídeo dentre os possíveis pipelines de vídeo for associado a um
media player de determinado serviço abstrato, então o pipeline de vídeo do media player mais recentemente iniciado (ou reiniciado após ser pausado ou parado) é o pipeline contribuidor; e
7. de outro modo, a determinação de qual pipeline
de vídeo é o pipeline contribuidor não é definida por esse
relatório descritivo, e dependente de implementação. Quando uma modalidade da presente invenção for baseada em um dispositivo Host OCAP implementando a Extensão MSM OCAP, determinadas permissões necessárias para segurança de um aplicativo Xlet serão agora explicadas.
A evocação de certos métodos definidos por esse
relatório descritivo requer que o aplicativo tenha um (ou ambos) MonitorAppPermission("multiscreen.configuration") ou (e) MonitorAppPermission ("multiscreen.context"). Em dispositivos Host OCAP, que implementem a Extensão MSM 10 OCAP, as seguintes permissões adicionais são consideradas, para serem aplicadas à MonitorAppPermission.
multiscreen.configuration oferece possibilidade para acesso e modificação do estado de configuração de multitelas da plataforma. Aplicativos com essa permissão podem modificar a configuração de multitelas da plataforma, e descobrir e monitorar seu estado dinâmico.
multiscreen.context oferece possibilidade para modificar um estado de contexto de multitelas da tela. Aplicativos com essa permissão podem modificar o estado de contexto de multitelas das telas acessáveis.
Além disso, o tipo do valor token enumerado do atributo de nome do tipo de elemento
ocap:monitorapplication, definido pela Definição do Tipo de Documento (DTD), definida pelo Arquivo de Pedidos de Permissão (PRF), deve ser considerado como contendo os seguintes valores: multiscreen.configuration e multiscreen.context.
Visto que uma modalidade da presente invenção é baseada em um sistema Java, a Propriedade do Sistema será agora definida.
Se um dispositivo Host OCAP implementar a Extensão
MSM na presente modalidade, então a propriedade do sistema Java "ocap. api. option .msm" deve ser definida com um valor correspondente à versão implementada desse relatório descritivo, onde essa versão desse relatório descritivo é 10 "1.0.0". Em contraste, se um dispositivo Host definir a propriedade do sistema Java "ocap.api.option.msm", então o dispositivo Host deve implementar a versão desse relatório descritivo que corresponda ao valor da propriedade.
0 acesso de leitura a essa propriedade deve ser concedido a ambos os aplicativos, assinado e não assinado.
Modalidades para implementar um gerenciador de multitelas baseado em sistema Java, de acordo com uma modalidade da presente invenção, serão agora explicadas.
0 registro das Constantes de interface Java, de acordo com uma modalidade da presente invenção, será agora explicado com referência às FIGS. IlA a HG.
A FIG. IlA ilustra o registro das constantes de Java em org.ocap.ui.MultiScreenConfigurableContext, de acordo com uma modalidade da presente invenção. As constantes são definidas em MultiScreenConfigurableContext do pacote org.ocap.ui abaixo descrito com referência às FIGS. 13Α a 13F.
A FIG. IlB ilustra o registro das constantes de Java em 'org.ocap.ui.MultiScreenConfiguration', de acordo com uma modalidade da presente invenção. As constantes são 5 definidas em 'MultiScreenConfiguration' do pacote 'org.ocap.ui' abaixo descrito como referência às FIGS. 14A a 14C.
A FIG. IlC ilustra o registro das constantes de Java em 'MultiScreenContext' 'org.ocap.ui.MultiScreen Context', de acordo com uma modalidade da presente invenção. As constantes são definidas em
'MultiScreenContext' do pacote 'org.ocap.ui.' abaixo descrito com referência às FIGS. 15A a 15D.
A FIG. IlD ilustra o registro das constantes de 15 Java em 'org.ocap.ui.event.MultiScreenConfigurationEvent', de acordo com uma modalidade da presente invenção. As constantes são definidas em 'MultiScreenConfigurationEvent' do pacote 'org.ocap.ui.event' abaixo descrito com referência às FIGS. 18A a 18D.
A FIG. IlE ilustra o registro das constantes de
Java em 'org.ocap.ui.event.MultiScreenContextEvent', de acordo com uma modalidade da presente invenção. As constantes são definidas em 'MultiScreenContextEvent do pacote 'org.ocap.ui.event' abaixo descrito com referência às FIGS. 2OA a 20D.
A FIG. HF ilustra o registro das constantes de Java em 'org.ocap.ui.event.MultiScreenEvent', de acordo com uma modalidade da presente invenção. As constantes são definidas em 'MultiScreenEvent' do pacote
'org.ocap.ui.event' abaixo descrito com referência às FIGS.
22A a 22D.
A FIG. IlG ilustra o registro das constantes de Java em 'org.ocap.ui.event.MultiScreenResourceEvent', de acordo com uma modalidade da presente invenção. As constantes são definidas em 'Multi-ScreenResourceEvent' do 10 pacote 'org.ocap.ui.event' abaixo descrito com referência às FIGS. 23A a 23D.
0 comportamento (semântica) da plataforma para gerenciamento de multitelas, de acordo com uma modalidade da presente invenção, será agora explicado.
A extensão para o pacote org.ocap.ui da Interface
de Usuário HAVi será agora explicada com referência às FIGS. 12 a 16F.
A FIG. 12 ilustra uma interface e- uma classe do pacote de Java 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
Uma interface 1200 do pacote org.ocap.ui inclui uma interface MultiScreenConfigurableContext 1210, uma interface MultiScreenConfiguration 1220, e uma interface 'multiScreenContext' 1230.
A interface MultiScreenConfigurableContext 1210
será explicada com referência às FIGS. 13A a 13F, a interface MultiScreenConfiguration 1220 será explicada com referência às FIGS. 14A a 14C, e a interface MultiScreenContext 1230 será explicada com referência às FIGS. 15A a 15D.
A classe 1250 do pacote org.ocap.ui inclui uma
classe MultiScreenManager 1260. A classe MultiScreenManager 1260 será explicada com referência às FIGS. 16A a 16F.
A FIG. 13A ilustra a definição da interface MultiScreenConfigurableContext do pacote org.ocap.ui, de acordo com uma modalidade da presente invenção.
A interface MultiscreenconfigurableContext' 1210 possui MultiScreenContext e org.davic.resources.
ResourceProxy como superinterfaces. A interface public MultiScreenConfigurableContext estende MultiScreenContext, org.davic.resources.ResourceProxy.
A interface MultiScreenConfigurable Context 1210 fornece um conjunto de ferramentas para efetuar o seguinte:
1. modificar o mapeamento de HScreens lógicas para HScreens de exibição, incluindo a área (extensão) na
HScreen de exibição, onde aparece uma HScreen lógica, sua visibilidade, e sua ordem z (dentre outras HScreens);
2. modificar a ordem z de HScreenDevices dentro de um HScreen;
3. modificar o conjunto de ServiceContexts associados a um HScreen;
4. modificar a associação dos HScreens de exibição e as instâncias de VideoOutputPort correspondentes; 5. modificar o conjunto de HScreenDevices, cujo áudio gerado constitui o conjunto das fontes de áudio de um HScreen;
6. modificar a atribuição focalizadora de áudio atual de um HScreen de exibição;
7. reservar e liberar a reserva dos recursos subjacentes de tela e do dispositivo de tela;
8. obter uma referência para o cliente do recurso atual, que possui tela reservada e seus recursos subjacentes; e
9. estabelecer a configuração de multitelas por exibição atualmente ativa de um Hscreen de exibição.
Se uma instância HScreen puder ser exposta a um aplicativo OCAP, e se essa HScreen for configurável com relação à funcionalidade definida pela interface MultiScreenConfigurableContext 1210, então uma
implementação MSM deve prestar suporte à interface MultiScreen ConfigurableContext em cada uma dessas instâncias HScreen.
Uma implementação MSM pode prestar suporte à interface MultiScreenConfigurableContext 1210 numa instância HScreen, que não seja configurável com relação à funcionalidade definida por essa interface
MultiScreenConfigurableContext 1210.
Uma determinada implementação da interface MultiScreenConfigurableContext 1210 não é demandada para prestar suporte a qualquer uma ou todas as alterações de configuração definidas, mas pode, devido ao hardware ou outras restrições, prestar suporte somente para alterações de configuração específicas.
Se uma implementação da interface
MultiScreenConfigurableContext 1210 não prestar suporte à alteração de configuração específica, então uma tentativa para realizar essa alteração deve fazer com que uma IllegalStateException seja gerada, como descrito sob cadum método abaixo definido.
A interface MultiScreenConfigurableContext 1210 é aplicada a partir da versão MSM 101.
A FIG. 13B ilustra um campo da interface MultiScreenConfigurableContext do pacote org.ocap.ui, de acordo com uma modalidade da presente invenção.
Um campo 1300 da interface MultiScreen ConfigurableContext inclui pelo menos um dentre 'static int C0NFIGURABLE_SCREEN_PARAMETER_AUDI0_F0CUS 1302', 'static 20 int C0NFIGURABLE_SCREEN_PARAMETER_AUDI0_S0URCE 1304', 'static int' CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z _0RDER 1306', 'static int CONFIGURABLE_SCREEN_PARAMETER_
DISPLAY_AREA 1308', 'static int CONFIGURABLE_SCREEN_ PARAMETER_DISPLAY_SCREEN 1310', 'static int CONFIGURABLE_ SCREEN_PARAMETER_OUTPUT_PORT 1312', 'static int
CONFIGURABLE_SCREEN_PARAMETER_SERVICE CONTEXT 1314', 'static int CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY 1316', e 'static int CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER 1318'.
.Um campo 1320 herdado da interface org.ocap.ui.MultiScreenContext 1230 inclui pelo menos um dentre 'SCREEN_TYPE_DISPLAY' e 'SCREEN_TYPE_LOGICAL'.
0 campo static final int
CONFIGURABLE_SCREEN_PARAMETER_AUDIO_SOURCE 1304 é um parâmetro configurável identificando a configurabilidade da(s) fonte(s) de áudio.
A configuração da(s) fonte (s) de áudio de uma tela
é realizada pelo uso dos métodos addAudioSources(..) e removeAudioSources(..) definidos pela interface
org.ocap.ui.MultiscreenConfigurableContext 1210.
Se a instância HScreen mencionada pela interface 'org.ocap.ui.MultiscreenconfigurableContext' 1210 prestar suporte à configuração de sua(s) fonte(s) de áudio, então isConfigurableParameterCONFIGURABLE_SCREEN_PARAMETER_AUDI0_ SOURCE) deve retornar verdadeiro.
Se hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_
PARAMETER_AUDIO_SOURCE) retornar verdadeiro, então
getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_
AUDI0_S0URCE) deve retornar um valor de tipo HScreenDevice[], onde cada' entrada na matriz de valores é um dispositivo de tela acessável dessa tela, que pode servir como uma fonte de áudio para essa tela.
O campo CONFIGURABLE_SCREEN_PARAMETER AUDIO FOCUS 1304 se aplica a partir do MSM 101.
O campo static final int CONFIGURABLE_SCREEN_ PARAMETER_AUDIO_FOCUS 1302 é um parâmetro configurável identificando a configurabilidade do foco de áudio.
A configuração do foco de áudio de uma tela é
realizada pelo uso do método atribuir AudioFocus( . . ) definido pela interface 'org.ocap.ui.MultiScreen
ConfigurableContext' 1210.
Se a instância HScreen mencionada por essa interface prestar suporte à configuração de sua(s) fonte(s) de áudio, então isConfigurableParameter(C0NFIGURABLE_ SCREEN_PARAMETER_AUDI0_F0CUS) deve retornar verdadeiro.
Se hasDiscreteParameterSpace(C0NFIGURABLE_SCREEN_ PARAMETER_AUDI0_F0CUS) retornar verdadeiro, então getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_
AUDI0_F0CUS) deve retornar um valor de tipo HScreen[], onde cada entrada na matriz de valores é uma tela acessável, que pode servir como uma tela focalizadora de áudio.
Se essa tela for uma tela de exibição, então as 20 entradas retornadas devem ser restritas àquelas telas lógicas, que são atualmente mapeadas para essa tela de exibição que pode ser o foco de áudio atribuído. Devido ao fato de uma tela de exibição poder ser sempre diretamente o foco de áudio atribuído (ao contrário de atribuir o foco de 25 áudio a determinada tela lógica mapeada para a tela de exibição) , a tela de exibição não é em si incluída nas entradas retornadas.
Se essa tela for uma tela lógica e se essa tela lógica for mapeada para uma tela de exibição e for capaz de ser o foco de áudio atribuído, então a matriz retornada deve conter somente essa tela; de outro modo, a matriz retornada deve ser vazia.
0 campo CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ ORDER 1302 se aplica, a partir do MSM 101.
0 campo static final int CONFIGURABLE_SCREEN_ PARAMETER_DEVICE_Z_ORDER 1306 é um parâmetro configurável identificando a configurabilidade da ordem z dos dispositivos de tela.
A configuração da ordem z dos dispositivos de uma tela é realizada pelo uso do método
setZOrder(HScreenDevice[]) definido pela interface 'org.ocaui.MultiScreenContext' 1230.
Se a instância HScreen mencionada por essa interface prestar suporte à configuração da ordem z de seu(s) dispositivo(s) de tela, então isConfigurable Parameter(CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER) deve retornar verdadeiro.
Se hasDiscreteParameterSpace(CONFIGURABLE_SCREEN_ PARAMETER_DEVICE_Z_ORDER) retornar verdadeiro, então getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_
DEVICE_Z_ORDER) deve retornar um valor de tipo HScreenDevice[][], onde cada entrada na matriz de valores é uma matriz dos dispositivos de tela, cuja ordem corresponde a uma ordenação z assistida daqueles dispositivos de tela, onde uma primeira entrada de tal matriz dos dispositivos de tela é a mais recuada na ordem z (i.e., ordem z do dispositivo igual a zero).
A FIG. 13C ilustra um caso de uso do campo 'CONFIGURABLE_SCREEN_PARAMETER_DEVICE_Z_ORDER'.
Na FIG. 13C, as seguintes suposições se aplicam:
1. uma tela possui um dispositivo de plano de fundo BI, um dispositivo de vídeo VI, e dois dispositivos
gráficos Gl e G2; e
2. duas ordenações de dispositivos gráficos são assistidas: (1) B1<V1<G1<G2 e (2) B1<V1<G2<G1.
É confirmado através de S1330, que a ordem z do dispositivo de plano de fundo Bl é 0, a ordem z do dispositivo de vídeo Vl é 1, a ordem z do dispositivo gráfico Gl é '2', e a ordem z do dispositivo gráfico G2 é 3.
Da mesma forma, é confirmado através de S1340, que a ordem z do dispositivo de plano de fundo Bl é 0, a ordem z do dispositivo de vídeo é 1, a ordem z do dispositivo gráfico G2 é 2, e a ordem z do dispositivo gráfico Gl é 3.
O campo 'CONFIGURABLE_SCREEN_PARAMETER_DEVICE_ Z_0RDER' 1306 se aplica a partir do MSM 101.
O campo static final int CONFIGURABLE_SCREEN_
PARAMETER_DISPLAY_AREA 1308 é um parâmetro configurável identificando a configurabilidade da área de exibição associada à tela.
A configuração da área de exibição de uma tela (lógica) é realizada pelo uso do método 5 setDisplayArea(HScreenRectangle) definido pela interface org.ocap.ui.MultiScreenContext 12 30.
Se a instância HScreen mencionada pela interface org.ocap.ui.MultiScreenConfigurableContext 1210 for uma tela de exibição, então isConfigurableParameter 10 (CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA) deve retornar falso; de outro modo, se essa tela lógica prestar suporte à configuração de sua área de exibição, então isConfigurable Parameter(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA) deve retornar verdadeiro.
Se hasDiscreteParameterSpace(C0NFIGURABLE_SCREEN_
PARAMETER_DISPLAY_AREA) retornar verdadeiro, então getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_ DISPLAY_AREA) deve retornar um valor de tipo HScreenRectangle[] , onde cada entrada na matriz de valores é uma área de exibição assistida.
A CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_AREA 1308 se Iica a partir do MSM 101.
A 'final estatic int CONFIGURABLE_SCREEN_ PARAMETER_DISPLAY_SCREEN' é um parâmetro configurável identificando a configurabilidade da tela de exibição associada à tela. A configuração da tela de exibição de uma tela (lógica) é realizada pelo uso de 'setDisplayScreen (HScreen)' definido pela interface 'org.ocap.ui.MultiScreen Context' 1230.
Se o 'HScreen' mencionado pela interface
'org.ocap.ui.MultiScreenConfigurableContext' 1210 for uma tela de exibição, então 'isConfigurableParameter (CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_SCREEN)' deve
retornar 'falso'. De outro modo, se a tela lógica prestar 10 suporte à configuração da tela de exibição, então 'isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_ DISPLAY_SCREEN)' deve retornar 'verdadeiro'. Se o método 'hasDiscreteParameterSpace (CONFIGURABLE_SCREEN_PARAMETER_ DISPLAY_SCREEN)' retornar 'verdadeiro', então 'getDiscrete 15 ParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_
SCREEN)' deve retornar um valor de tipo 'HScreen[]', onde cada entrada na matriz de valores é uma tela de exibição acessável, para qual a tela lógica pode ser mapeada.
0 campo 'CONFIGURABLE_SCREEN_PARAMETER_DISPLAY_ SCREEN' 1310 foi aplicado, a partir da versão MSM 101.
O 'static final int
CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_PORT' é um parâmetro configurável identificando a configurabilidade da(s) porta (s) de saida associadas à tela.
A configuração da(s) porta(s) de saida de uma tela
é realizada pelo uso de 'addOutputPorts (..)' e 'removeOutputPorts(. . ) ' , que são definidas pela interface 'org.ocap.ui.MultiScreenConfigurableContext' 1210.
Se a instância 'HScreen' mencionada pela interface 'org.ocap.ui.MultiScreenConfigurableContext' 1210 prestar 5 suporte à configuração de sua(s) porta(s) de saída de vídeo, então 'isConfigurableParameter(C0NFIGURABLE_
φ SCREEN_PARAMETER_Ouput_Port)' deve retornar 'verdadeiro'.
Se 'hasDiscreteParameterSpace (CONFIGURABLE_SCREEN_
PARAMETER_0UTPUT_P0RT)' retornar 'verdadeiro',
'getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_
0UTPUT_P0RT) ' deve retornar um valor de um tipo 'VideoOutputPort[]', onde cada entrada na matriz de valores é uma porta de vídeo acessável, para qual a tela pode ser diretamente mapeada.
0 campo 'CONFIGURABLE_SCREEN_PARAMETER_OUTPUT_
PORT' 1312 foi aplicado a partir da versão MSM 101.
*
Um campo 'CONFIGURABLE_SCREEN_PARAMETER_SERVICE_ CONTEXT' 1314 é declarado como 'static final int CONFIGURABLE_SCREEN_PARAMETER_SERVICE_CONTEXT' e é um 20 parâmetro configurável identificando a configurabilidade do(s) contexto(s) de serviço associado(s) à tela.
A configuração do(s) contexto(s) de serviço de uma tela é realizada pelo uso de 'addServiceContexts(..)' e 'removeServiceContexts(..)' definidos pela interface 25 'org.ocap.ui.MultiScreenConfigurableContext' 1210, e pelo uso de 'swapServiceContexts(..)' e 'moveService Contexts(..)' definidos pelo 'MultiScreenManager'.
Se a instância 'HScreen' mencionada pela interface 'org.ocap.ui.MultiScreenConfigurableContext' 1210 prestar suporte à configuração de sua(s) porta(s) de saída, então 'isConfigurableParameter(CONFIGURABLE_SCREEN_
PARAMETER_SERVICE_CONTEXT) ' deve retornar 'verdadeiro' .
Se 'hasDiscreteParameterSpace(CONFIGURABLE_
SCREEN_PARAMETER_SERVICE_CONTEXT) ' retornar 'verdadeiro', então 'getDiscreteParameterSpace (CONFIGURABLE_SCREEN_ 10 PARAMETER_SERVICE_CONTEXT) ' deve retornar um valor de tipo 'ServiceContextf]', onde cada entrada na matriz de valores é um contexto de serviço acessável, que pode ser associado a essa tela.
0 campo 'CONFIGURABLE_SCREEN_PARAMETER_SERVICE_ CONTEXT' 1314 foi aplicado a partir da versão MSM 101.
Um campo 'CONFIGURABLE_SCREEN_PARAMETER_
VISIBILITY' 1316 é declarado como 'static final int CONFIGURABLE_SCREEN_PARAMETER_VISIBILITY', e é um parâmetro configurável identificando a configurabilidade de uma visibilidade da tela.
A configuração da visibilidade de uma tela é realizada pelo uso de 'setVisibie(boolean)' definido pela interface 'org.ocap.ui.MultiScreenConfigurableContext'
1210.
Se a instância 'HScreen' mencionada pela interface
'org.ocap.ui.MultiScreenConfigurableContext' 1210 prestar suporte à configuração de sua visibilidade, então 'isConfigurableParameter(CONFIGURABLE_SCREEN_PARAMETER_ VISIBILITY)' deve retornar 'verdadeiro', mas
. 'hasDiscreteParameterSpace (CONFIGURABLE_SCREEN_PARAMETER_ VISIBILITY)' retorna 'falso', significando que, se a visibilidade for configurável, então um espaço de parâmetro contínuo (i. e., ambos 'verdadeiro' e 'falso') é aplicado.
O campo 'CONFIGURABLE_SCREEN_PARAMETER_ VISIBILITY' 1316 foi aplicado a partir da versão MSM 101.
O 'static final int
CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER' é um parâmetro configurável identificando a configurabilidade de uma 'ordem z' da tela.
A configuração da 'ordem z' de uma tela é realizada pelo uso de ' setZOrder(int)' definido pela interface 'org.ocap.ui.MultiScreenConfigurableContext' 1210.
Se a instância 'HScreen' mencionada pela interface 'org.ocap.ui.MultiScreenConfigurableContext' 1210 prestar suporte à configuração de sua ordem z (com relação a outras 20 telas dentro sua configuração de multitelas), então 'isConfigurableParameter(CONFIGURABLE_SCREEN_' PARAMETER_Z_0RDER) ' deve retornar 'verdadeiro' .
Se 'hasDiscreteParameterSpace(C0NFIGURABLE_
SCREEN_PARAMETER_Z_ORDER) ' retornar 'verdadeiro', então 'getDiscreteParameterSpace(CONFIGURABLE_SCREEN_PARAMETER_Z_ ORDER)' deve retornar um valor de tipo 'inteiro[]', onde cada entrada de valor 'v' na matriz de valores é tal, que 'v.intValue()' retorna um índice de 'ordem z' assistido para essa tela no contexto dessa configuração de multitelas da tela.
O campo 'CONFIGURABLE_SCREEN_PARAMETER_Z_ORDER'
1318 foi aplicado a partir da versão MSM 101.
Φ O campo 'Fields inherited from interface
org.ocap.ui.MultiScreenContext' 1320 herdado do
'org.ocap.ui.MultiScreenContext' inclui 'SCREEN_TYPE_ 10 DISPLAY', 'SCREEN_TYPE_LOGICAL'.
As FIGS. 13D e 13F ilustram um método 1350 de uma interface 'MultiScreenConfigurableContext' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
0 método 1350 da interface
'Org-Ocap-Ui-MultiScreenCOntext' inclui pelo menos um dentre: um método 'void addAudioSources(org.havi.ui. HScreenDevice[] devices, boolean mix WithAudioFocus)' 1352; um método 'void addOutputPorts(org.ocap.hardware. 20 VideoOutputPort[] ports, boolean removeExisting)' 1354; um método 'void addServiceContexts(javax.tv.Service.selection. ServiceContext[] contexts, a boolean associateDefault Devices)' 1356; um método 'void assignAudioFocus' 1358; um método 'Boolean checkServiceContextCompatibility
25 (javax.tv.service.selection.ServiceContext context)' 1360; um método 'org.davic.resources.ResourceClientgetClient()' 1362; um método ' java.Iang.Object[] getDiscreteParameter Space(int parameter)' 1364; um método boolean hasDiscreteParameterSpace(int parameter)' 1366; um método 'boolean isConfigurableParameter(int parameter)' 1368; um 5 método 'void releaseScreen()' 1370; um método 'void removeAudioSources (org.havi.ui.HScreenDevice [ ] devices)' Φ 1372; um método 'void removeOutputPorts(org.ocap.
hardware.VideoOutputPort[] ports)' 137 4; um método 'void removeServiceContexts(j avax.tv.Service.selection.Service 10 Context [] contexts)' 1376; um método 'void requestMulti ScreenConfigurationChange (MuitiScreenConfiguration
configuration,j ava.util.Dictionary serviceContext
Associations)' 1378; um método 'boolean reserveScreen (org.davic.resources.ResourceClient client, java.lang. 15 Object requestData)' 1380; um método 'void setDisplayArea (org.havi.ui.HScreenRectangle rect)' 1382; um método 'void
%
setDisplayScreen(org.havi.ui.HScreen screen)' 1384; um método 'void setMultiScreenConfiguration(MultiScreen
Configuration configuration, java.util.Dictionary
20 serviceContext Associations)' 1386; um método 'void setVisible(boolean visible)' 1388; um método 'void setZOrder (org.havi.ui.HScreenDevice[] devices)' 1390; e um método 'void setZOrder(int order)' 1392.
Um método 1394 herdado da interface 25 'org.ocap.ui.MultiScreenContext' 1230 inclui pelo menos um dentre: 'addMultiScreenConfigurationListener', 'SddScreenContextLiStener', 'getAudioFocus',
'getAudioSources', 'getDisplayArea', 'getDisplayScreen', 'getID', método 'getMultiScreenConfiguration', método 'getMultiScreenConfigurations', método
'getMultiScreenConfigurations', 'getOutputPorts',
'getScreenCategory', 'getScreenType', 'getServiceContexts', Φ 'getVisible', 'getZOrder', 'getZOrder',
'removeMultiScreenConfigurationListener', e
'removeScreenContextListener' .
0 método 'isConfigurableParameter' 1368 é declarado
como 'boolean isConfigurableParameter(int parameter)', e determina se um parâmetro configurável é assistido como configurável (ao contrário do fixo) pela implementação de plataforma por determinada tela.
O parâmetro '‘parameter' é um valor de enumeração do
parâmetro de tela configurável, conforme acima definido. Se a implementação de plataforma prestar suporte a uma variação contínua ou discreta do 'parameter' especificado nessa tela, o método 'isConfigurableParameter' 1368 então 20 retorna 'verdadeiro'; de outro modo, ele retorna 'falso'.
0 método 'isConfigurableParameter' 1368 foi aplicado a partir da versão MSM 101.
0 método 'hasDiscreteParameterSpace' 1366 é declarado como 'boolean hasDiscreteParameterSpace(int 25 parameter)', e determina se um parâmetro configurável assistido possui um espaço de valor discreto ou continuamente variável.
No presente contexto, um parâmetro 'continuamente' configurável significa que a plataforma presta suporte a, ou pode aproximar, todos os valores do tipo de valor do 5 parâmetro, enquanto que "discreto" significa que somente certos valores enumeráveis do tipo de valor do parâmetro podem pode usados, como anunciados por
'getDiscreteParameterSpace(..)'.
0 parâmetro 'parameter' é um valor de enumeração do 10 parâmetro de tela configurável, conforme acima definido. Se a implementação de plataforma prestar suporte a um (sub)conjunto discreto de valores do espaço do tipo de valor do 'parameter' especificado nessa tela, então o método 'hasDiscreteParameterSpace' 1366 retorna
'verdadeiro'. De outro modo, o método
'hasDiscreteParameterSpace' 1366 retorna 'falso', em cujo caso todos os valores do espaço do tipo de valor são assistidos (ou aproximados).
Se o 'isConfigurableParameter(parameter)' 1368 retornar 'falso', o método 'hasDiscreteParameterSpace' 1366 gera 'java.lang.IllegalArgumentException'.
0 método 'hasDiscreteParameterSpace' 1366 foi aplicado, a partir da versão MSM 101.
0 método 'getDiscreteParameterSpace' 1364 é declarado como 'java.Iang.Object[] getDiscreteParameter Space(int parameter)', e obtém o (sub)conjunto discreto de valores do espaço do tipo de valor de um parâmetro configurável.
O tipo de tempo de execução real da matriz e os elementos da matriz retornados pelo método 5 'getDiscreteParameterSpace' 1364 devem ser conforme definidos para o parâmetro configurável especificado, como documentado por cada especificação do parâmetro configurável acima.
A menos que de outro modo indicado pela definição 10 de um parâmetro configurável específico, a ordem de entradas na matriz retornada pelo método
'getDiscreteParameterSpace' 1364 não é definida pelo presente relatório descritivo, e deve ser considerada dependente de implementação por um aplicativo 15 interoperável.
Um conjunto de parâmetros discretos assistidos pode
*
sofrer alteração para uma determinada tela e um determinado parâmetro configurável ao longo do tempo de vida de uma tela, com base no estado dinâmico dos recursos subjacentes 20 da tela. Porém, tal alteração, se ela ocorrer, não deve ocorrer fora do intervalo de tempo entre o término da distribuição de um evento 'MultiScreen
ConfigurationEvent.MULTI_SCREEN_C0NFIGURATI0N_CHANG1NG' e o término da distribuição do evento 'MultiScreen 25 ConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED'.
0 parâmetro 'parameter' é um valor de enumeração do parâmetro de tela configurável, conforme acima definido. 0 método 'getDiscreteParameterSpace' 1364 retorna uma matriz das instâncias de objeto, cada qual denotando um valor discreto do parâmetro especificado que é assistido (ou aproximável) pela plataforma.
Se o método 'hasDiscreteParameterSpace (parameter)' 1366 retornar 'falso', o método
'isConfigurableParameter(parameter) ' 1368, ou o método 'getDiscreteParameterSpace' 1364, devem gerar
'j ava.Iang.IllegalArgumentException' .
O método 'getDiscreteParameterSpace' 1364 foi aplicado a partir da versão MSM 101.
0 método 'setVisible' 1388 é declarado como 'void setVisible(boolean visible)', e define a visibilidade da tela.
Se essa tela for uma tela lógica, então a tela é marcada como visível (se previamente oculta), ou é marcada como oculta (se previamente visível) . Se a tela for uma tela de exibição, todas as telas lógicas mapeadas para a tela de exibição são marcadas como visíveis (se previamente ocultas), ou são marcada como oculta (se previamente visíveis).
0 parâmetro 'visible' é um valor Booleano, indicando se essa 'HScreen' lógica, ou as telas lógicas mapeadas para essa tela de exibição, devem ser tornadas visíveis ou ocultas (invisíveis) na sua 'HScreen' de exibição associada. Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("Multiscreen.context")', o método 'setVisible' 1388 gera 'java.Iang.SecurityException'.
Se a visibilidade para o 'HScreen' não puder ser alterada, p. ex., se a plataforma usar uma configuração de visibilidade permanente, o método 'setVisible'1388 gera 'java.lang.IllegalStateException'.
O método 'setVisible' 1388 foi aplicado a partir da versão MSM 101.
Se o método 'setZOrder(int)' 1392 for declarado como 'void setZOrder(int order)', ele define a 'ordem z' da tela.
O método ' setZOrder(int)' 1392 faz com que a 'HScreen' lógica altere sua 'z-order' dentre outras 'HScreen' lógicas mapeadas para a mesma 'HScreen' de exibição.
O parâmetro 'order' é um valor inteiro positivo indicando a nova 'z-order' a ser atribuída a essa 'HScreen' lógica.
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.context") ' , o método 'setZOrder(int)' 1392 gera 'java.Iang.SecurityException'. Se o tipo dessa 'HScreen' não for 'SCREEN_TYPE_LOGICAL', ou se a 'z-order' para o 'HScreen' não puder ser alterada, p. ex., se a plataforma usar uma configuração 'z-order' permanente, o método 'setZOrder(int)' 1392 gera 'j ava.Iang.IllegalStateException'.
O método 'setZOrder(int)' 1392 foi aplicado a partir da versão MSM 101.
0 método 'setZOrder(HScreenDevice[])' 1390 é declarado como 'void setZOrder(org.havi.ui.HScreenDevice[] devices)', e define uma 'z-order' para um dispositivo de tela dentro essa tela para um conjunto de dispositivos de tela.
0 método 'setZOrder(HScreenDevice[])' 1390 define, de forma atômica, a 'z-order' do conjunto especificado de 'HScreenDevice', onde umas seguintes restrições são aplicadas:
- se um 'HBackgroundDevice' estiver presente no conjunto especificado de dispositivos, (i) o
'HBackgroundDevice' precede qualquer 'HVideoDevice' contido no conjunto de dispositivos, e (ii) ele precede quaisquer 'HGraphicsDevice' contidos no conjunto de dispositivos.
se um 'HVideoDevice' estiver presente no conjunto especificado de dispositivos, o 'HVideoDevice' precede quaisquer 'HGraphicsDevice' contidos no conjunto de dispositivos.
Se nenhuma exceção for causada pelo método 'setZOrder(HScreenDevice[]) ' 1390, então o conjunto de instâncias 'HScreenDevice' especificadas deve ser ordenada, de forma que 'MultiScreen Context.getZOrder (HScreenDevice)', quando evocado nessa tela com qualquer um dos dispositivos especificados, retorne um índice de 'z- order' que preserva uma ordem relativa dos dispositivos especificados.
Se menos do que todo o conjunto de instâncias
'HScreenDevice'' associadas a essa tela for fornecido no argumento 'devices' , então a ordem relativa resultante dos dispositivos não-especifiçados com relação aos dispositivos especificados não é definida, exceto que restrições 10 definidas pelo 'MultiScreenContext.getZOrder (HScreen Device)' devem ser aplicadas a todas as ordenações de dispositivos nessa tela após o retorno do método 'setZOrder(HScreenDevice[])' 1390.
Os parâmetros 'devices' são uma matriz ordenada de instâncias 'HScreenDevice' associadas a essa tela.
Se ao thread de chamada não tiver sido concedida 'MonitorAppPermission("multiscreen.context")', o método 'setZOrder(HScreenDeviee[])' 1390 gera 'java.Iang.Security Exception' .
Se o dispositivo 'device' não for um
'HScreenDevice' dessa tela, o método
'setZOrder(HScreenDevice[])' 1390 gera 'java.Iang.Illegal ArgumentException'.
0 método 'setZOrder(HScreenDevice[])' 1390 deve gerar 'java.lang.IllegalStateException', quando (i) a 'z- order' para o 'HScreenDevice' especificado não puder ser alterada, p. ex., quando a plataforma usar uma configuração 'z-order' permanente para dispositivos de tela nessa tela, ou (ii) quando a ordem de dispositivos especificados não permitir a atribuição dos indices 'z-order', que satisfaçam the restrições acima.
O método 'setZOrder(HScreenDevice[]) ' 1390 foi aplicado a partir da versão MSM 101.
0 método addAudioSources' 1352 é declarado como 'void addAudioSources(org.havi.ui.HScreenDevice[] devices, 10 boolean mixWithAudioFocus)', e adiciona uma ou mais fonte (s) de áudio para essa tela. 0 método 'addAudioSources' 1352 adiciona uma ou mais instâncias 'HScreenDevice' ao conjunto das fontes de áudio, a partir do qual o áudio apresentado é selecionado (e combinado) 15 para fins de apresentação de áudio por parte dessa tela.
Se uma fonte de áudio especificada já tiver sido designada como uma fonte de áudio para essa tela, mas 'mixWithAudioFocus' diferir daquela especificada, quando ela for adicionada como uma fonte de áudio, então os novos valores de 'mixWithAudioFocus' são aplicados.
0 parâmetro 'devices' é uma matriz não-vazia de instâncias 'HScreenDevice', onde cada uma das instâncias 'HScreenDevice' contribui para uma apresentação de áudio combinada a partir dessa tela.
Se o parâmetro 'mixWithAudioFocus' for
'verdadeiro', então dispositivos especificados de tela contribuem com áudio, ou combinam áudio, com qualquer saída de áudio associada a qualquer porta de saída de vídeo, com que essa tela é associada (diretamente ou indiretamente), a despeito dessa tela ser, ou não, foco de áudio atribuído.
5 Se o parâmetro 'mixWithAudioFocus' for 'falso', então os dispositivos especificados de tela contribuem somente com to áudio, quando a essa tela for atribuído um foco de áudio.
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.context")', o método 10 'addAudioSources' 1352 gera 'java.Iang.SecurityException' .
Se o parâmetro '‘devices' não for uma matriz não- vazia ou determinada entrada de 'devices' não for um 'HScreenDevice' dessa tela, o método 'addAudioSources' 1352 gera 'java.lang.IllegalArgumentException'.
O método 'addAudioSources' 1352 deve gerar
'java.lang.IllegalStateException', quando (i) as fontes de áudio para essa 'HScreenDevice' não puderem ser alteradas, p. ex., quando a plataforma usar uma configuração de fonte de áudio permanente para dispositivos de tela 1 dessa tela, 20 ou (ii) quando múltiplas fontes de áudio forem especificadas e mixagem de áudio não for assistida.
O método 'addAudioSources' 1352 foi aplicado a partir da versão MSM 101.
0 método 'removeAudioSources' 1372 é declarado como 25 'void removeAudioSources (org.havi.ui.HScreenDevice[] devices)', e remove uma ou mais fontes de áudio. 0 método 'removeAudioSources'' 1372 remove todos ou alguns conjuntos não-vazios de instâncias 'HScreenDevice' específicas do conjunto de fontes de áudio dessa 'HScreen'. Se 'devices' possuir um valor 'nulo', então todas as fontes de áudio são 5 removidas.
0 parâmetro 'devices' indica o valor 'nulo' ou um to conjunto não-vazio de instâncias 'HScreenDevice' .
Se ao thread de chamada não tiver sido concedida 'MonitorAppPermission("multiscreen.context") ' , o método 10 'removeAudioSources' 1372 gera 'java.lang.Security Exception'.
Se 'devices' não for nulo e determinada entrada 'HScreenDevice' não for associada a essa instância 'HScreen', o método 'removeAudioSources' 1372 gera 15 'java.lang.IllegalArgumentException'.
Se um 'HScreenDevice' especificado, usado como uma fonte de áudio para esse 'HScreen', não puder ser alterado, p. ex., se a plataforma usar uma associação permanente de fontes de áudio com o 'HScreenDevice' especificado, o 20 método 'removeAudioSources' 1372 deve gerar
'java.lang.IllegalStateException'.
0 método 'removeAudioSources' 1372 foi aplicado a partir da versão MSM 101.
0 método 'assignAudioFocus' 1358 é declarado como 25 'void assignAudioFocus' , e atribui um foco de áudio a essa tela. A qualquer dado momento, uma tela de exibição deve atribuir um foco de áudio a si própria ou exatamente a uma tela lógica a ela mapeada (a tela de exibição) . Quando o foco de áudio for recentemente atribuído a uma tela lógica 5 de uma tela de exibição, e a tela lógica não possuir atualmente um foco de áudio a ela atribuído, então o foco % de áudio deve ser removido de qualquer outra tela lógica
mapeada para tela de exibição, e ser atribuído ao invés disso à tela lógica recentemente atribuída.
Se nenhuma tela lógica for mapeada para uma
determinada tela de exibição ou nenhuma tela lógica mapeada a uma determinada tela de exibição for o foco de áudio atribuído, então a tela de exibição deve atribuir a si própria o foco de áudio (por padrão) . O foco de áudio pode 15 ser explicitamente atribuído a uma tela de exibição pelo uso do método 'assignAudioFocus' 1358 numa instância da tela de exibição.
A tela focalizadora de áudio de uma tela de exibição é a tela, cujas fontes de áudio atualmente 20 selecionadas são atribuídas, para ser processadas em todos os dispositivos de apresentação de áudio (implícitos) de todas as portas de saída de vídeo, para as quais a tela de exibição foi mapeada. Se a tela, para qual o foco de áudio foi atribuído, não possuir uma fonte de áudio, i. e., se 25 ela possuir um conjunto vazio de fontes de áudio, então o áudio (conforme produzido, ou potencialmente produzido, pela plataforma OCAP) não deve ser processado por qualquer dispositivo de apresentação de áudio (implícito) de todas as portas de saída de vídeo, para as quais a tela de exibição foi mapeada.
Cada tela de exibição distinta pode possuir uma
tela lógica distinta, para qual o foco de áudio é atribuído % para fins de processamento de áudio da tela de exibição (e
sua coleção de telas lógicas mapeadas).
Se ao thread de chamada não tiver sido concedida 10 'MonitorAppPermission("Multiscreen.context") ' , o método 'assignAudioFocus' 1358 gera 'java.lang.SecurityException' .
Se o foco de áudio não puder ser atribuído a essa 'HScreen' ou o atual foco de áudio não puder ser alterado, o método 'assignAudioFocus' 1358 gera
15 'java.lang.IllegalStateException'.
O método 'assignAudioFocus' 1358 foi aplicado a
%
partir da versão MSM 101.
0 método 'addOutputPorts' 1354 é declarado como 'void addOutputPorts(org.ocap.hardware. VideoOutputPort[] 20 ports, boolean removeExisting)', e adiciona uma ou mais portas de saída de vídeo, para as quais uma tela é mapeada.
Se essa 'HScreen' for uma tela lógica, ao invés de uma tela de exibição, então a 'HScreen' deve ser considerada, como se comportando de modo equivalente a uma 25 tela de exibição, para fins de mapeamento para a(s) porta(s) de saída de vídeo especificada(s). A saber, a tela lógica é tratada, como se ela fosse uma tela principal de exibição por sua própria concordância.
0 parâmetro 'ports' é uma matriz não-vazia de instâncias 'VideoOutputPort. Se o parâmetro
'removeExisting' possuir um valor 'verdadeiro', então uma associação com a tela existente (se tal associação existir) deve ser removida, antes de ser adicionada a uma nova tela.
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.context")', o método 'addOutputPorts' 1354 gera 'java.lang.SecurityException'.
O método 'addOutputPorts' 1354 gera
'java.lang.IllegalStateException', quando (i) o
'VideoOutputPort' especificado já tiver sido associado a uma 'HScreen' diferente, e 'removeExisting' não for 15 'verdadeiro' , (ii) esse 'HScreen' não puder ser mapeado para determinada 'VideoOutputPort' especificada, devido a determinadas restrições de hardware específicas da plataforma, e (iii) quando o conjunto de instâncias 'VideoOutputPort', para as quais essa 'HScreen' foi 20 mapeada, não puder ser alterado, p. ex., quando a plataforma usar uma associação permanente com um conjunto específico de instâncias 'VideoOutputPort'.
O método 'addOutputPorts' 1354 foi aplicado a partir da versão MSM 101.
O método 'removeOutputPorts' 137 4 é declarado como
'void removeOutputPorts(org.ocap.hardware. VideoOutputPort[] ports)', e remove uma ou mais portas de saída de vídeo, para as quais uma tela é mapeada. O método 'removeOutputPorts' 1374 remove todos ou determinados conjuntos não-vazios de instâncias 'VideoOutputPortil 5 específicos do conjunto de portas de saída de vídeo, para as quais o 'HScreen' foi mapeado. Se o parâmetro 'ports' for 'nulo', então todas as associações das portas de saída de vídeo são removidas.
O parâmetro 'ports' é 'nulo' ou uma matriz não- vazia de instâncias VideoOutputPort'.
Se ao thread de chamada não tiver sido concedida 'MonitorAppPermission("multiscreen.context") ' , o método 'removeOutputPorts' 1374 gera 'java.lang.SecurityException'
' Se 'ports' não for nulo e determinada entrada de 'VideoOutputPort' não for associada a essa instância 'HScreen', o método 'removeOutputPorts' 1374 gera 'j ava.lang.IllegalArgumentException' .
Se um 'VideoOutputPort' especificado para essa 'HScreen' não puder ser alterado, p. ex., se a plataforma usar uma associação permanente com o 'VideoOutputPort' especificado, o método 'removeOutputPorts' 1374 deve gerar 'j ava.lang.IllegalStateException' .
O método 'removeOutputPorts' 1374 foi aplicado a partir da versão MSM 101.
O método 'setDisplayScreen' 1384 é declarado como
'void setDisplayScreen (org.havi.ui.HScreen screen)', e associa uma tela lógica a uma tela de exibição. Isto é, o método 'setDisplayScreen' 1384 associa esse 'HScreen' lógico a um 'HScreen' de exibição.
O parâmetro 'screen' é uma instância 'HScreen' de exibição ou é nulo. Se o parâmetro 'screen' for 'nulo', o método 'setDisplayScreen' 1384 é executado sem uma exceção, e o parâmetro 'screen' é retornado, então a 'HScreen' lógica não é mais associada a uma 'HScreen' de exibição.
Se ao thread de chamada não tiver sido concedida 'MonitorAppPermission(multiscreen.context")', o método 'setDisplayScreen' 1384 gera 'java.lang.SecurityException'.
0 método 'setDisplayScreen' 1384 gera 'java. lang.IllegalStateException', quando (i) o tipo do 'HScreen' não for 'SCREEN_TYPE_LOGICAL', (ii) o 'screen' especificado 15 não for 'nulo' e seu tipo de tela não for 'SCREEN_TYPE_DISPLAY', ou (iii) o 'HScreen' de exibição associado a essa 'HScreen' lógica não puder ser alterado, p. ex., quando a plataforma usar uma associação permanente com uma 'HScreen' de exibição especifica.
0 método 'setDisplayScreen' 1384 foi aplicado a
partir da versão MSM 101. 0 método 'setDisplayArea' 1382 é declarado como 'void setDisplayArea(org.havi.ui.HScreen Rectangle rect)', e define uma área de uma tela de exibição, para a qual uma tela lógica é mapeada. Isto é, o 25 método 'setDisplayArea' 1382 associa essa HScreen lógica a uma área (extensão) de sua HScreen de exibição associada. O parâmetro 'rect' é uma instância HScreenRectangle especificando a área na HScreen de exibição associada a essa HScreen lógica, que deve corresponder à extensão dessa HScreen lógica.
Se ao thread de chamada não tiver sido concedida
'MonitorAppPermission("multiscreen.context")', o método fe 'setDisplayArea' 1382 gera 'java.lang.SecurityException'.
O método 'setDisplayArea' 1382 gera
' java.lang.IllegalStateException', se (1) esse tipo de 10 HScreen não for SCREEN_TYPE_LOGICAL, ou (2) se a área do HScreen de exibição associada a essa HScreen lógica não puder ser alterada, p. ex., se a plataforma usar uma associação permanente com uma área específica da associada.
O método 'setDisplayArea' 1382 foi aplicado a 15 partir da versão MSM 101.
0 método 'checkServiceContext Compatibility' 1360 é
€
declarado como 'boolean checkServiceContextCompatibility (javax.tv.service.selection.ServiceContext context)', e testa a compatibilidade do contexto de serviço com uma 20 tela. Isto é, o método 'checkServiceContextCompatibility' 1360 determina se um aplicativo pode atribuir ServiceContext a esse HScreen e se o ServiceContext especificado é compatível com uma apresentação nessa HScreen.
0 parâmetro 'context' é uma instância
'ServiceContext' válida. O método 'checkServiceContext Compatibility' 1360 retorna um valor booleano, indicando se a instância ServiceContext especificada pode ser atribuída a essa HScreen. Se a instância ServiceContext especificada puder 5 ser atribuída, 'verdadeiro' é retornado; de outro modo, 'falso' é retornado.
^ Se ao thread de chamada não tiver sido concedida
'MonitorAppPermission("multiscreen.context")', o método 'checkServiceContextCompatibility' 1360 gera 'java.lang. 10 Security Exception'.
Se o 'ServiceContext' especificado não for válido, o método 'checkServiceContextCompatibility' 1360 gera 'j ava.lang.IllegalArgumentException'.
0 método 'checkServiceContextCompatibility' 1360 15 foi aplicado a partir da versão MSM 101.
0 método 'addServiceContexts' 1356 é declarado como 'void addServiceContexts(javax.tv.service.selection.
ServiceContext[] Contexts, boolean associateDefault Devices)' e adiciona contexto(s) de serviço a essa tela. 20 Isto é, o método 'addServiceContexts' 1356 adiciona uma ou mais instâncias ServiceContext ao conjunto de contextos de serviço associado a essa HScreen, a fim de permitir conteúdo de plano de fundo, vídeo, e gráficos a partir dessas instâncias ServiceContext, para serem apresentadas 25 nos respectivos dispositivos de tela do HScreen.
Se um contexto de serviço especificado já tiver sido associado à tela subjacente representada pela interface 'org.ocap.ui.MultiScreenContext', então esse contexto de serviço não é, de forma múltipla, associado a essa tela, mas à associação existente permanece intacta.
5 Isto é, um determinado contexto de serviço deve ser associado só uma vez a uma determinada tela (subjacente), % ou não deve ser nunca associado à mesma.
Se dois ou mais contextos não-abstratos de serviço forem associados a uma determinada tela, e fontes múltiplas 10 de video dos players baseados em plano de fundo desses múltiplos contextos não-abstratos de serviço forem associadas a uma determinada instância HVideoDevice da determinada tela, então o player baseado em plano de fundo desses múltiplos contextos de serviço, cujo conteúdo de 15 video deve ser exibido, é determinado de acordo com as seguintes regras ordenadas:
*
1. Se o aplicativo proprietário de um dos contextos não-abstratos de serviço associados contiver uma reserva sobre determinado HVideoDevice da tela, então o
20 conteúdo do player baseado em plano de fundo desse contexto de serviço é designado para apresentação nesse dispositivo de vídeo; e
2. De outro modo, o player baseado em plano de fundo do contexto não-abstrato de serviço associado, a cujo
25 aplicativo é atribuída a maior prioridade, é designado para apresentação nesse dispositivo de vídeo. Se, após aplicar as regras acima, múltiplos players baseados em plano de fundo de determinado aplicativo forem designados para apresentação num dispositivo de video, então ao player, que for mais recentemente iniciado, é 5 concedida prioridade para apresentação de video.
0 parâmetro 'contexts' é uma matriz não-vazia de % instâncias 'ServiceContext'. Se o parâmetro
'associateDefaultDevices' for 'verdadeiro' , então os dispositivos de tela padrão dessa tela são associados a 10 todas as ■instâncias ServiceMediaHandler atualmente associadas à instância ServiceContext especificada. De outro modo, se o parâmetro 'associateDefaultDevices' for 'falso', então essa associação com dispositivos de tela padrão não é realizada.
15 Se ao thread de chamada não tiver sido concedido
'MonitorAppPermission("Multiscreen. context")', o método 'addServiceContexts' 1356 gera 'java.lang.
SecurityException'
Se determinado ServiceContext especificado para 20 essa HScreen não puder ser alterado, p. ex., se a plataforma usar uma associação permanente com um ServiceContext especifico, o método 'addServiceContexts' * 1356 gera 'java.lang.IllegalStateException'.
0 método 'addServiceContexts' 1356 foi aplicado a 25 partir da versão MSM 101.
0 método 'removeServiceContexts' 137 6 é declarado como 'void removeServiceContexts(javax.tv.
service.selection.ServiceContext[] Contexts)', e remove contexto (s) de serviço de uma tela. Isto é, o método 'removeServiceContexts' 137 6 remove todos ou determinado 5 conjunto não-vazio de instâncias ServiceContext especificas do conjunto de contextos de serviço associado a essa HScreen. Se os contextos forem nulos, então todos os contextos de serviço são removidos.
O parâmetro 'contexts' é 'nulo', ou instâncias de matriz não-vazia de 'ServiceContexti' .
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.context")', o método 'removeServiceContexts' 1376 gera 'java.Iang.Security Exception'.
Se contexts não for 'nulo' e determinada entrada
ServiceContext não for associada a essa instância HScreen, o método 'removeServiceContexts' 137 6 gera
'java.Iang.IllegalArgumentException'.
Se ServiceContext não puder ser alterado, p. ex., se a plataforma usar uma associação permanente com um ServiceContext especificado, o método
'removeServiceContexts' 137 6 deve gerar
'j ava.Iang.IllegalStateException' .
O método 'removeServiceContexts' 137 6 foi aplicado a partir da versão MSM 101.
O método 'setMultiScreenConfiguration' 1386 é declarado como 'void setMultiScreen Configuration (MultiScreenConfiguration configuration, java.
util.Dictionary serviceContextAssociations)', e define uma configuração de multitelas atualmente ativa para essa tela de exibição. Isto é, um dentre o conjunto de subconjuntos de telas lógicas, que pode ser associado a essa tela de % exibição, é selecionado em um determinado momento.
Se a configuração especificada for a configuração atual for essa tela de exibição, então, a menos que 10 SecurityException seja aplicado, um valor é retornado a partir do método 'setMultiScreenConfiguration' 1386, sem produzir qualquer efeito colateral.
Se a configuração especificada não for a configuração atual para essa tela de exibição, e se 15 Security Exception, IllegalStateException, e
IllegalStateException não se aplicarem, então o
*
processamento síncrono de uma alteração na configuração de multitelas de exibição, definido no presente relatório descritivo, é realizado.
Se um argumento serviceContextAssociations for
especificado (i. e., se ele não for nulo), então qualquer instância ServiceContext, que for acessável para o aplicativo de chamada, não deve ser associada a nenhuma tela, ou à(s) tela(s) aplicável(eis) na (nova) configuração 25 de multitelas especificada. Se nenhuma associação corresponder a determinado ServiceContext acessável, se determinada instância de um ServiceContext acessável não estiver presente nas associações especificadas, ou se ela estiver presente, mas nenhuma dessas telas aplicáveis existir na nova configuração de multitelas, então a 5 instância ServiceContext deve ser associada à tela de uma associação do contexto de serviço padrão da configuração de % multitelas especificada, i. e., à tela retornada pela
configuration.getDefaultServiceContextScreen().
Para fins de correspondência das instâncias 10 ServiceContext acessáveis, cujas referências aparecem como chaves num dicionário serviceContextAssociations
especificado, o método virtual equals(Object)on dessas chaves deve ser usado, em cujo caso é suposto que o método 'setMultiScreenConfiguration' 1386 se comporte de forma 15 idêntica à implementação padrão do Object.equals(Object).
No contexto de uma determinada instância de um
%
aplicativo, a implementação do host MSM deve manter a relação um-por-um entre instâncias ServiceContext expostas a esse aplicativo e coleções de recursos subjacentes de 20 contexto de serviço. Se a implementação do host MSM deixar de manter essa relação, então ao consultar um dicionário serviceContextAssociations, a implementação MSM pode considerar duas coleções distintas de recursos subjacentes de contexto de serviço, como sendo o mesmo contexto de 25 serviço, p. ex. , se em diferentes momentos, uma única instância ServiceContext fizer referência a diferentes coleções de recursos subjacentes. Além disso, a implementação MSM pode considerar uma única coleção de recursos subjacentes de contexto de serviço, como sendo dois contextos distintos de serviço, p. ex., se em um 5 determinado momento, duas instâncias ServiceContext distintas fizerem referência à mesma coleção de recursos subjacentes.
O estado do componente de conversão de formato do decodificador (DFC) de um pipeline de video sendo usado 10 para processar vídeo associado a um contexto de serviço, que é implicitamente trocado ou movido entre telas pelo método 'setMultiScreenConfiguration' 1386, não deve ser afetado pelo desempenho do método 'setMultiScreen Configuration' 1386.
O parâmetro 'configuration' é uma instância
MultiScreenConfiguration a se tornar a configuração de multitelas por exibição atualmente ativa para essa tela de exibição. Se o parâmetro 'serviceContextAssociations' não for nulo, ele é uma instância Dictionary, cujas chaves são 20 instâncias ServiceContext, e cujos valores são instâncias String, onde os valores de cadeia são definidos como a seguir: (1) se o valor de cadeia for então nenhuma
tela é aplicada (em cujo caso um contexto de serviço correspondente não é associado a qualquer tela após a alteração da configuração), (2) de outro modo, se o valor de cadeia for então todas as telas da nova configuração de tela são aplicadas, (3) de outro modo, se o valor de cadeia for um identificador de tela, conforme retornado por MultiScreenContext.getID(), então que essa tela seja aplicada, (4) de outro modo, se o valor de cadeia 5 for uma categoria de tela, conforme retornada por MultiScreen Context.getScreenCategory(), então qualquer tela da nova configuração com essa categoria seja aplicada, (5) de outro modo, se o valor de cadeia for uma lista de identificadores de tela separados por ponto e vírgula, 10 então cada tela da nova configuração com um identificador de correspondência é aplicado, (6) de outro modo, se o valor de cadeia for uma lista de categorias de tela separadas por ponto e vírgula, então cada tela da nova configuração com uma categoria de correspondência é 15 aplicada, (7) de outro modo, se o valor de cadeia for uma lista de identificadores de tela, ou categorias de tela, separadas por ponto e vírgula, então cada tela da nova configuração com um identificador ou categoria de correspondência ,é aplicada, e (8) de outro modo, a tela de 20 uma associação do contexto de serviço padrão da nova configuração é aplicada.
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.configuration")', o
método 'setMultiScreenConfiguration' 1386 gera
' java.Iang.SecurityException' .
Se o parâmetro 'Configuration' não for uma dessas configurações de multitelas da tela (de exibição), conforme deveria ser retornada por MultiScreenContext.
getMultiScreenConfigurations(), o método 'setMultiScreen Configuration' 1386 gera 'java.Iang.IllegalArgument Exception'.
O método 'setMultiScreenConfiguration' 1386 gera 'java.Iang.IllegalStateException', se essa tela não for uma tela de exibição ou (1) se a implementação MSM não permitir a ativação da configuração de multitelas especificada, (2) 10 se o método 'setMultiScreenConfiguration' 1386 for previamente evocado, e as etapas de processamento da alteração não tiverem sido ainda completadas, ou (3) se ativação não for de outro modo permitida no momento da evocação do método.
0 método 'setMultiScreenConfiguration' 1386 foi
aplicado a partir da versão MSM 101.
0 método 'requestMultiScreenConfiguration Change' 1378 é declarado como 'void requestMultiScreen ConfigurationChange(MultiScreenConfiguration configuration, java.util.Dictionary serviceContextAssociations)', e
solicita que a configuração de multitelas atualmente ativa para essa tela de exibição seja alterada.
Se a configuração especificada for a configuração atual para essa tela de exibição, então, a menos que SecurityException seja aplicado, um valor é retornado pelo método 'requestMultiScreenConfiguration Change' 1378, sem produzir qualquer efeito colateral.
Se a configuração especificada não for a configuração de exibição atual, e se 'SecurityException', 'IllegalArgumentException', e 'IllegalStateException' não 5 forem aplicados, então uma alteração assíncrona na configuração atual de multitelas é inicializada, onde uma semântica de setMultiScreenConfiguration() é aplicada, exceto que esse método DEVE retornar imediatamente, após MultiScreenConfiguration.MULTI_SCREEN_CONFIGURATION_
CHANGING ser gerado (mas antes dele ser despachado).
O parâmetro 'configuration' é uma instância 'MultiScreenConfiguration' a se tornar a configuração de tela atualmente ativa.
O parâmetro 'serviceContextAssociations' é 'nulo' 15 ou uma instância Dictionary, cujas chaves são instâncias ServiceContext, e cujos valores são instâncias String, com base na semântica, conforme acima definido por
*
setMultiScreenConfiguration.
Se ao thread de chamada não tiver sido concedido 20 'MonitorAppPermission("multiscreen.configuration")', o
método 'requestMultiScreenConfigurationChange' 1378 gera 'java.lang.SecurityException' .
Se o parâmetro 'configuration' não for uma dessas configurações de multitelas da tela (de exibição), conforme 25 deve ser retornada por MultiScreenContext.
getMultiScreenConfigurations(), o método 'requestMulti ScreenConfigurationChange' 1378 gera 'java.Iang.Illegal ArgumentException'.
Se essa tela não for uma tela de exibição, ou (1) se a implementação MSM não permitir a ativação da 5 configuração de multitelas especificada, (2) se o método 'setMultiScreenConfiguration' 1378 for previamente evocado e as etapas de processamento da alteração não tiverem sido ainda completadas, ou (3) se ativação não for de outro modo permitida no momento da evocação do método, o método 10 'setMultiScreenConfiguration' 1378 gera 'java.lang.Illegal StateException'.
0 método 'requestMultiScreenConfiguration Change' 1378 foi aplicado a partir da versão MSM 101.
0 método 'getClient' 1362 é declarado como 'org.davic.resources.ResourceClientgetClient ()', e obtém o cliente de recurso que atualmente contém a reserva sobre a tela e os recursos de tela subjacentes associados a essa instância HScreen.
0 método 'getClient' 1362 é também especificado por 'getClient' da interface 'org.davic.resources.Resource Proxy'.
0 método 'getClient' 1362 retorna uma instância ResourceClient ou retorna 'nulo', se a tela e os recursos de tela subjacentes associados a essa HScreen não estiverem reservados.
0 método 'getClient' 1362 foi aplicado a partir da versão MSM 101.
O método 'reserveScreen' 1380 é declarado como 'boolean reserveScreen(org.davic.resources.ResourceClient client, java.Iang.Object requestData)', e reserva, de forma 5 atômica, os recursos subjacentes dessa tela.
Se reservar uma tela tiver que ser considerado equivalente a reservar todas as instâncias HScreenDevice
%
associadas à tela, exceto que, quando a tela for reservada usando-se o método 'reserveScreen' 1380, instâncias 10 HScreenDevice individuais não devem ser liberadas, sem primeiro liberar todas as instâncias HScreenDevice e todos os recursos de tela subjacentes dessa tela.
Se ao reservar uma tela, determinado HScreenDevice da tela já tiver sido reservado por outro aplicativo, então 15 essa reserva deve ser liberada com sucesso (pela implementação MSM), antes de conceder uma reserva à tela.
^ Se a reserva não for, ou não puder ser, liberada, então uma
tentativa para reservar a tela deve falhar. Isto é, o método 'reserveScreen' 1380 deve retornar 'falso'.
Se, ao reservar uma tela, determinado HScreenDevice
da tela já tiver sido reservado pelo aplicativo de reserva, então essa reserva deve ser implicitamente incluída pela reserva bem sucedida da tela inteira.
Se uma tentativa para reservar uma tela usando o 25 método 'reserveScreen' 1380 for bem sucedida, i. e., se o método 'reserveScreen' 1380 retornar 'verdadeiro', então getClient() de todas as instâncias HScreen Device da tela deve retornar o mesmo valor que o método getClient () 1362 definido pela interface 'org.ocap.ui.MultiScreen
ConfIgurableContext' 1210 (conforme implementado pela 5 implementação concreta de HScreen).
Se essa tela não for previamente reservada e a evocação do método 'reserveScreen' 1380 fizer com que a tela seja reservada, então, antes do retorno do método 'reserveScreen' 1380, um evento MultiScreenResource Event.MULTI_SCREEN_RESOURSE_SCREEN_RESERVED deve ser
gerado.
Se o aplicativo de chamada já possuir uma reserva nessa tela, e se os argumentos client e requestData especificados forem idênticos àqueles especificados, quando o aplicativo de chamada foi previamente concedido para reserva, então o método 'reserveScreen' 1380 não deve possuir nenhum efeito colateral e retornar 'verdadeiro' . Porém, se o aplicativo de chamada já possuir uma reserva nessa tela, mas um dos argumentos Client ou requestData especificados diferirem daquele especificado, quando o aplicativo de chamada foi previamente concedido para reserva, então (1) os argumentos client e requestData especificados devem ser substituídos por aqueles previamente especificados, (2) o aplicativo de chamada deve reter a reserva, e (3) o método 'reserveScreen' 1380 deve retornar 'verdadeiro'. O parâmetro 'client' é uma instância 'ResourceClient'. Se o parâmetro 'requestData' for 'nulo' ou uma instância Object que implemente a interface j ava.rmi.Remote.
O método 'reserveScreen' 1380 retorna 'verdadeiro',
se os recursos subjacentes de tela forem reservados com sucesso, e de outro modo retorna 'falso'.
0 método 'reserveScreen' 1380 foi aplicado a partir da versão MSM 101, e 'Remote' é indicado.
0 método 'releaseScreen' 1370 é declarado como
'void releaseScreen()', e libera de forma atômica os recursos subjacentes de tela.
Se o aplicativo de chamada não contiver uma reserva nessa tela, então o método 'releaseScreen' 1370 não deve possuir nenhum efeito colateral.
Se essa tela for previamente reservada e a evocação do método 'releaseScreen' 1370 fizer com que a tela não seja mais reservada (i. e., fique sem reserva), então, um evento MultiScreenResourceEvent.MULTI_SCREEN_
RESOURCE_SCREEN_RELEASED deve ser gerado, antes de um valor ser retornado pelo método 'releaseScreen' 1370.
O método 'releaseScreen' 1370 foi aplicado a partir da versão MSM 101.
A FIG. 14A ilustra a definição de uma interface 'MultiScreenConfiguration' do pacote 'org.ocap.ui', de um acordo com uma modalidade da presente invenção. A interface 'MultiScreenConfiguration' é declarada, como 'public interface MultiScreen Configuration'.
A interface MultiScreenConfiguration implementada por uma plataforma host OCAP fornece informações sobre uma diferente configuração de tela, bem como um mecanismo para monitorar alterações na configuração de tela.
Uma implementação MSM deve prestar suporte pelo menos a uma configuração de multitelas, cujo tipo de configuração é SCREEN_CONFIGURATION_DISPLAY.
E a implementação MSM deve prestar suporte pelo menos a uma configuração de multitelas, cujo tipo de configuração é SCREEN_CONFIGURATION_NON_PIP.
Se a implementação MSM implementar funcionalidade PIP e permitir a apresentação de uma tela PIP durante uma operação OCAP, então a implementação MSM deve prestar suporte à configuração de multitelas SCREEN_CONFIGURATION_ PIP.
Se a implementação MSM implementar funcionalidade POP e permitir a apresentação de uma tela POP durante a operação OCAP, então a implementação MSM deve prestar suporte à configuração de multitelas SCREEN_CONFIGURATION_ POP.
Se a implementação MSM implementar funcionalidade PIP, POP, ou OVERLAY numa configuração discreta não sendo explicitamente abaixo especificada por uma configuração não-geral de multitelas, então a implementação MSM deve prestar suporte a uma ou mais configurações de multitelas do tipo de configuração SCREEN_CONFIGURATION_GENERAL, que represente cada uma dessas configurações de multitelas.
A interface 'MultiScreenConfiguration' 1220 do pacote 'org.ocap.ui' foi aplicada a partir da versão MSM 101.
A FIG. 14B ilustra um campo 1400 de uma interface 'MultiScreenConfiguration' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
0 campo 1400 da interface 'MultiScreen
Configuration' do pacote 'org.ocap.ui' inclui pelo menos um dentre: um campo 'static java.Iang.String
SCREEN_CATEGORY_DISPLAY' 1402, um campo 'static java.Iang.String SCREEN_CATEGORY_GENERAL' 14 04, um campo 15 'static java.Iang.String SCREEN_CATEGORY_MAIN' 1406, um campo 'static java.Iang.String SCREEN_CATEGORY_NONE' 1408, um campo 'static java.Iang.String SCREEN_CATEGORY_OVERLAY' 1410, um campo 'static java.Iang.String
SCREEN_CATEGORY_PIP' 1412, um campo 'static
java.lang.String SCREEN_CATEGORY_POP' 1414, um campo 'static java.lang.String SCREEN_CON FIGURATION_DIS PLAY' 1416, um campo 'staticjava.lang.String
SCREEN_CONFIGURATION_GENERAL' 1418, um campo 'static java.lang.String SCREEN_CONFIGURATION_ NONPIP' 1420, um campo 'static java.lang.String SCREEN_CONFIGURATION_PIP' 1422, e um campo 'static java.lang.String SCREEN_CONFIGURATΙΟΝ_ΡΟP' 1424. O campo 'SCREEN_CONFIGURATION_DISPLAY' 1416 é declarado como 'static final java.lang.String
SCREEN_CONFIGURATION_DISPLAY'. Se 'MultiScreen
Configuration' for associada a uma ou mais telas de exibição, e for uma candidata a ser usada como uma configuração de multitelas por plataforma, então seu tipo de configuração é o campo SCREEN_CON FIGURATION_DIS PLAY 1416.
A tela padrão inicial do tipo de configuração do campo SCREEN_CONFIGURATION_DISPLAY 1416 deve ser uma primeira tela retornada por getScreens(SCREEN_CATEGORY_ MAIN). Se não houver nenhuma dessas telas categorizada na configuração, então a tela padrão inicial do tipo de configuração do campo SCREEN_CON FIGURATION_DIS PLAY 1416 deve ser a primeira tela retornada por getScrens().
O campo ' SCREEN_CONFIGURATION_DISPLAY' 1416 foi aplicado a partir da versão MSM 101.
0 campo 'SCREEN_CONFIGURATION_NON_PIP'1420 é declarado como 'static final java.lang.String SCREEN_ C0NFIGURATI0N_N0N_PIP'. Se uma MultiScreenConfiguration for associada exatamente a uma tela, cuja categoria é SCREEN_CATEGORY_MAIN, então seu tipo de configuração é SCREEN_CONFIGURATION_NON_PIP.
A tela padrão inicial do tipo de configuração do campo SCREEN CONFIGURATION NON PIP 1420 deve ser uma primeira tela retornada por getScreens(SCREEN_CATEGORY_ MAIN).
Uma instância MultiScreenConfiguration, que é categorizada como tendo o tipo de configuração do campo SCREEN_CONFIGURATION_NON_PIP 1420, não deve conter mais de uma tela de exibição.
0 campo 'SCREEN_CONFIGURATION_NON_PIP' 1420 foi aplicado a partir da versão MSM 101.
0 campo 'SCREEN_CONFIGURATION_PIP' 1422 é declarado como 'static final java.lang.String
SCREEN_CONFIGURATION_PIP'. Se uma MultiScreenConfiguration é (1) associada a uma tela lógica com ordem z padrão de zero mapeada para toda a área de uma única tela de exibição, e (2) associada a uma ou mais telas lógicas sem 15 interseção com ordem z padrão de uma delas mapeada para a mesma tela de exibição, então seu tipo de configuração é o campo SCREEN_C0NFIGURATI0N_PIP 1422.
A tela padrão inicial do tipo de configuração do
SCREEN_
0 campo CONFIGURATION_PIP 1422 deve ser uma
primeira tela retornada por getScreens(SCREEN_CATEG0RY_ MAIN), ou, se não houver nenhuma tela categorizada como o campo SCREEN_CATEGORY_MAIN 1406 na configuração, então a tela padrão inicial do tipo de configuração do campo 25 SCREEN_CONFIGURATION_PI P 1422 deve ser uma primeira tela retornada por getScreens(). Uma instância MultiScreenConfiguration, que é categorizada como tendo o tipo de configuração do campo SCREEN_CONFIGURATION_PIP 1422, não deve conter mais de uma tela de exibição.
0 campo 'SCREEN_CONFIGURATION_PIP' 1422 foi
aplicado a partir da versão MSM 101.
0 campo 'SCREEN_C0NFIGURATI0N_P0P' 1424 é declarado como 'static final java.lang.String
SCREEN_C0NFIGURATI0N_P0P'. Se uma MultiScreenConfiguration 10 for associada a duas ou mais telas lógicas sem interseção com ordem z padrão de zero, cujas áreas de exibição padrão (em união) colocam lado a lado toda a área de uma única tela de exibição, então seu tipo de configuração é o campo SCREEN_CONFIGURATION_POP 1424.
A tela padrão inicial do tipo de configuração do
campo SCREEN_CONFIGURATION_POP 1424 deve ser uma primeira tela retornada por getScreens(SCREEN_CATEGORY_ POP), ou, se não houver nenhuma tela categorizada como o campo 'SCREEN_CATEGORY_POP' 1414 na configuração, então a tela 20 padrão inicial do tipo de configuração do campo SCREEN__C0NFIGURATI0N_P0P 1424 deve ser uma primeira tela retornada por getScreens().
Uma instância MultiScreenConfiguration, que é categorizada como tendo o tipo de configuração do campo SCREEN_CONFIGURATI0N_P0P 1424, não deve conter mais de uma tela de exibição. O campo 'SCREEN_CONFIGURATION_POP' 1424 foi aplicado a partir da versão MSM 101.
O campo 'SCREEN_CONFIGURATION_GENERAL' 1418 é declarado como 'static final java.lang.String 5 SCREEN_CONFIGURATION_GENERAL'. Se uma MultiScreen Configuration não puder ser categorizada como um dos outros tipos predefinidos de configuração de tela, então seu tipo de configuração é o campo SCREEN__CONFIGURATION_GENERAL 1418 .
A tela padrão inicial do tipo de configuração do
SCREEN_CONFIGURATION_GENERAL 1418 deve ser uma primeira tela retornada por getScreens(SCREEN_CATEGORY_MAIN). Se não houver nenhuma tela categorizada para o campo SCREEN_CATEGORY_GENERAL 1404 na configuração, então a tela 15 padrão inicial do tipo de configuração do SCREEN_C0NFIGURATION_GENERAL 1418 deve ser uma primeira tela retornada por getScreens().
Uma instância MultiScreenConfiguration, que é categorizada como tendo o tipo de configuração do SCREEN_C0NFIGURAT10N_GENERAL 1418, não deve conter mais de uma tela de exibição.
0 campo 'SCREEN_C0NFIGURATI0N_GENERAL' 1418 foi aplicado a partir da versão MSM 101.
0 campo 'SCREEN_CATEGORY_NONE' 14 08 é declarado como 'static final java.lang.String SCREEN_CATEGORY_NONE'. Se uma instância HScreen não for associada a quaisquer outras categorias mais específicas, então sua categoria é o campo SCREEN_CATEGORY_NONE 1408.
Uma instância MultiScreenConfiguration, que é categorizada como tendo o tipo de configuração do campo SCREEN_CATEGORY_NONE 14 08, não deve conter mais de uma exibição.
0 campo 'SCREEN_CATEGORY_NONE' foi aplicado a partir da versão MSM 101.
0 campo 'SCREEN_CATEGORY_DISPLAY' 14 02 é declarado como 'static final java.lang.String
SCREEN_CATEGORY_DISPLAY'. Se uma instância HScreen de exibição for caracterizada como uma tela não-principal, então sua categoria é o campo SCREEN_CATEGORY_DISPLAY 1402. Uma tela de exibição atribuída a essa categoria não deve 15 ser ocupada por um HBackgroundDevice ou um HVideoDevice, mas pode ser ocupada por uma ou mais instâncias HGraphicsDevice, que sirvam como sobreposições.
Uma instância HScreen de exibição, que é categorizada como o campo SCREEN_CATEGORY_DISPLAY 1402, 20 possui a excepcional propriedade, de que suas instâncias HGraphicsDevice, se qualquer uma delas existir, devem se sobrepor a todas as telas lógicas mapeadas para a tela de exibição. Essa propriedade não deve ser mantida, quando MultiScreenContext.getZOrder() retornar '0' para qualquer 25 tela de exibição.
A excepcional propriedade acima descrita se destina a prestar suporte (1) a cenários de dispositivos herdados, onde uma sobreposição de legenda codificada aparece em todos os outros conteúdos, e (2) configurações onde, ao invés de tratar uma tela de sobreposição como uma tela 5 lógica separada, uma tela de sobreposição é considerada como um HGraphicsDevice integrante da tela de exibição.
0 campo 'SCREEN_CATEGORY_DISPLAY' 1402 foi aplicado Φ a partir da versão MSM 101.
O campo 'SCREEN_CATEGORY_MAIN' 1406 é declarado 10 como 'static final java.lang.String SCREEN_CATEGORY_MAIN'. Se uma instância HScreen de exibição ou lógica for caracterizada como uma tela principal, então sua categoria é o campo SCREEN_CATEGORY_MAIN 106. Uma tela lógica atribuída a essa categoria deve ser mapeada para a área 15 completa de determinadas telas de exibição, e deve ser atribuída uma ordem z padrão de 0.
O campo ' SCREEN_CATEGORY_MAIN' 14 0 6 foi aplicado a
%
partir da versão MSM 101.
O campo 'SCREEN_CATEGORY_PIP' 1412 é declarado como 20 'static final java.lang.String SCREEN_CATEGORY_PIP'. Se uma instância HScreen lógica for caracterizada como uma tela picture-in-picture (PIP) , então sua categoria é o campo SCREEN_CATEGORY_PIP 1412. Uma tela lógica atribuída a essa categoria não deve ser mapeada para toda a área de 25 determinadas telas de exibição, não deve ser atribuída uma ordem z de telas igual a O, e deve coexistir numa configuração, para qual determinadas telas são atribuídas à categoria SCREEN_CATEGORY_MAIN 1406.
O campo ' SCREEN_CATEGORY_PIP' 1412 foi aplicado a partir da versão MSM 101.
5 0 campo ' SCREEN_CATEG0RY_P0P' 1414 é declarado como
'static final java.lang.String SCREEN_CATEG0RY_P0P'. Se uma instância HScreen lógica for caracterizada como uma tela picture-outside-picture (POP), então sua categoria é o campo SCREEN_CATEGORY_POP 1414. Uma tela lógica atribuída a 10 essa categoria não deve ser mapeada para toda a área de determinadas telas de exibição, não deve coexistir numa configuração, para qual determinadas telas são atribuídas à categoria SCREEN_CATEGORY_MAIN 1406, e deve coexistir numa configuração, para qual determinadas outras telas são 15 atribuídas à categoria SCREEN_CATEGORY_POP 1414.
O campo 'SCREEN_CATEGORY_POP' 1414 foi aplicado a partir da versão MSM 101.
O campo 'SCREEN_CATEGORY_OVERLAY' 1410 é declarado como 'static final java.lang.String
2 0 SCREEN_CATEGORY_OVERLAY'. Se uma instância HScreen lógica for caracterizada como uma tela de sobreposição, então sua categoria é o campo SCREEN_CATEGORY_OVERLAY 1410. Uma tela lógica atribuída a essa categoria deve ser mapeada para toda a área de determinada tela de exibição, deve ser 25 atribuída a ordem z padrão superior a qualquer tela associada a uma das seguintes categorias: o campo SCREEN_CATEGORY_MAIN 1406, o SCREEN_CATEGORY_PIP 1412, e ο SCREEN_CATEGORY_POP 1414, e não deve conter um plano de fundo ou um plano de vídeo explícito (HVideoDevice).
Apesar do acima, uma tela de sobreposição pode fazer uso dos recursos de um plano de vídeo implícito (HVideoDevice), para fins de apresentar vídeo baseado em componentes em (um de) seus planos gráficos.
0 campo 'SCREEN_CATEGORY_OVERLAY' 1410 foi aplicado a partir da versão MSM 101.
0 campo 'SCREEN_CATEGORY_GENERAL 1404 é declarado
como 'static final java.lang.String
SCREEN_CATEGORY_GENERAI/ . Se uma instância HScreen lógica for capaz de ser configurada (p. ex., em termos de seu tamanho, posição, ou ordem z), de forma que ela possa 15 operar num modo, que deva possuir atribuição sugerida de duas ou mais das outras categorias de tela, então sua categoria pode ser o campo SCREEN_CATEGORY_GENERAL 1404. Uma tela lógica atribuída a essa categoria não deve ser limitada em tamanho, posição, ordem z, ou outras 20 propriedades configuráveis, exceto quanto à extensão em que o dispositivo terminal coloque limitações intrínseca sobre uma (ou mais) propriedades configuráveis.
0 campo 'SCREEN_CATEGORY_GENERAL' 14 04 foi aplicado a partir da versão MSM 101.
A FIG. 14C ilustra um método 1450 de uma interface
'MultiScreenConfiguration' do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
0 método 1450 da interface
'MultiScreenConfiguration' do pacote 'org.ocap.ui' inclui pelo menos um dentre: um método 'java.lang.String getConfigurationType()' 1452, um método
'org.havi.ui.HScreen getDefaultServiceContextScreen ()'
1454, um método 'org.havi.ui.HScreent]getScreens() 1456, um método 'org.havi.ui.HScreen[] getScreens(java.lang.String category)' 1458, um método 'boolean hasOverlayScreen()' 10 1460, um método 'boolean isScreenlnConfiguration (org.havi.ui.HScreen screen)' 1462, e um método 'void set DefaultServiceContextScreen' 1464.
0 método 'getConfigurationType' 1452 é declarado como 'java.lang.String getConfigurationType()', e obtém o 15 tipo de tela de configuração dessa configuração. Se mais de um tipo de configuração não-geral puder ser aplicado, ou se o tipo de configuração for desconhecido, ou não puder ser determinado, então o valor do método
SCREEN_CONFIGURATION_GENERAL 1418 deve ser retornado.
O método 'getConfigurationType' 1452 retorna uma
cadeia, que é (i) um elemento dentre o método 'SCREEN_CONFIGURATION_DISPLAY' 1416, o método
'SCREEN_CONFIGURATION_NON_PIP' 1420, o método
'SCREEN_CONFIGURATION_PIP' 1422, o método
'SCREEN_CONFIGURATION_POP' 1424, e o método
'SCREEN_CONFIGURATION_GENERAL', ou (ii) um valor de cadeia que denota um tipo de configuração dependente da plataforma e que começa com o prefixo "x-".
0 método 'getConfigurationType' 1452 foi aplicado a partir da versão MSM 101.
O método 'getScreens()' 1456 é declarado como 'org.havi.ui.HScreen[] getScreens(), e obtém o conjunto de telas acessáveis associado a essa configuração.
Os recursos subjacentes de uma determinada instância HScreen retornada pelo método 'getScreens()' 1456 podem ser compartilhados com uma instância HScreen incluida em outra configuração de multitelas. Porém, os recursos compartilhados devem ser ativos em não mais de uma configuração de multitelas em um determinado momento. A ordem de entradas na matriz retornada da instância HScreens é dependente de implementação.
Determinados os valores de quaisquer duas entradas distintas da matriz retornada, Sl e S2, e determinada a instância singleton do MultiScreenManager, MSM, então as seguintes restrições são aplicadas durante o intervalo entre o tempo, quando o método 'getScreens()' 1456 retorna, e o tempo, quando um evento
MultiScreenConfigurationEvent.MULTI_SCREEN_C0NFIGURATI0N_ CHANGING é gerado e despachado:
• MSM.isEmptyScreen(Sl) deve ser 'falso';
• MSM.isEmptyScreen(S2) deve ser 'falso';
• MSM.sameResources(Sl,S2) deve ser 'falso'; Se evocadas por um aplicativo, que não possua MonitorAppPermission ("multiscreen.configuration"), então as telas dessa configuração, que não forem associadas a uma instância ServiceContext acessável pelo aplicativo, não 5 devem ser retornadas; de outro modo, todas as telas acessáveis dessa configuração devem ser retornadas.
Ao durante o decurso do ciclo de vida de um
%
aplicativo, e exceto como abaixo limitado, uma implementação MSM pode adicionar telas um, ou remover telas 10 de, uma configuração de multitelas, em cujo caso ela deve gerar, respectivamente, um evento MultiScreenConfiguration Event. MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED ou Multi Screen ConfigurationEvent.MULTI_SCREEN_CONFIGURATION_
SCREEN_REMOVED.
Uma tela não deve ser adicionada a, ou removida de,
uma configuração de multitelas, que é a configuração de .Jl multitelas atualmente ativa por plataforma, ou determinada
configuração de multitelas por exibição atualmente ativa.
A implementação MSM deve aguardar até que uma 20 configuração de multitelas não seja mais a configuração de multitelas atualmente ativa, a fim de adicionar, ou remover, telas dessa configuração.
Durante qualquer intervalo de tempo, onde nenhum evento MultiScreenConfigurationEvent.MULTI_SCREEN_
25 CONFIGURATION_SCREEN_ADDED ou MultiScreenConfiguration Event.MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED for gerado, o conjunto de instâncias HScreen retornadas e a ordem dessas instâncias retornadas não devem ser alterados, a partir da perspectiva de um determinado aplicativo.
Uma implementação MSM não deve remover, nem gerar, um evento MultiScreenConfigurationEvent. MULTI_SCREEN_ CONFIGURATION_SCREEN_REMOVED, que possua o efeito de remover (ou' informar a remoção) dessa configuração de multitelas, uma instância HScreen, cujos recursos subjacentes representem os mesmos recursos subjacentes de determinada instância HScreen padrão do aplicativo não- destruído.
O método 'getScreens()' 1456 retorna uma matriz 'HScreen'. A matriz 'HScreen' retornada pode ser uma matriz vazia.
O método 'getScreens()' 1456 foi aplicado a partir da versão MSM 101.
0 método 'getScreens(String)' 1458 é declarado como 'org.havi.ui.HScreen[]getScreens(java.lang.String category)', e todas as telas acessáveis com uma determinada categoria.
0 método 'getScreens(String) ' 1458 deve funcionar de modo idêntico ao método getScreens() 1456, exceto como a seguir:
- se a categoria não for nula, então retornar somente aquelas telas atribuídas à categoria especificada, ou, se nenhuma dessas telas existir, então retornar uma matriz HScreen vazia; de outro modo, se a categoria for nula, então retornar o mesmo valor que o método getScreens() 1456.
0 parâmetro category é um dos seguintes valores: (1) nulo, (2) um elemento da seguinte numeração: {a SCREEN_CATEGORY_NONE 14 08, a SCREEN_CATEGORY_DIS PLAY 14 02, a SCREEN CATEGORY MAIN 1406, a SCREEN CATEGORY PIP 1412, a % "
SCREEN_CATEGORY_POP 1414, a SCREEN_CATEGORY_OVERLAY 1410, e a SCREEN_CATEGORY_GENERAL 1404}, ou (3) um valor de cadeia 10 dependente da plataforma não predefinido como uma categoria de tela, mas que pode ser retornado por getScreenCategory (HScreen).
O método 'getScreens(String)' 1458 retorna uma matriz 'HScreen'. A matriz 'HScreen' retornada pelo método 15 'getScreens(String)' 1458 pode ser vazia.
O método 'getScreens(String)' 1458 foi aplicado a ^ partir da versão MSM 101.
O método 'hasOverlayScreen()' 1460 é declarado como 'boolean hasOverlayScreen()', e determina se o conjunto de 20 telas associadas a essa configuração inclui uma tela de sobreposição, i. e., uma tela, cuja categoria é a SCREEN_CATEGORY_OVERLAY 1410.
O método 'hasOverlayScreen() 1460 retorna 'verdadeiro', se getScreens(SCREEN_CATEGORY_OVERLAY)
25 retornar uma matriz não-vazia; de outro modo, ele retorna 'falso'. O método 'hasOverlayScreen()' 1460 foi aplicado a partir da versão MSM 101.
O método 'getDefaultServiceContextScreen()' 1454 é declarado como 'org.havi.ui.HScreen
getDefaultServiceContextScreen() ' , e obtém o contexto de serviço padrão como tela de associação dessa configuração.
A tela de associação do contexto de serviço padrão
de uma configuração de multitelas é a tela, com que
instâncias ServiceContext são associadas, quando a
■b
configuração se tornar ativa, no caso de nenhuma informação mais específica estiver disponível, para determinar como associar uma instância ServiceContext a uma tela.
As seguintes restrições são aplicadas:
1. Se essa configuração de multitelas é a configuração de multitelas de exibição por plataforma, então a tela de associação do contexto de serviço padrão deve ser a tela associada à configuração de multitelas por exibição de determinadas telas de exibição associadas a essa configuração de multitelas;
2. de outro modo, se essa configuração de multitelas for uma configuração de multitelas por exibição, então a tela de associação do contexto de serviço padrão deve ser uma tela de exibição ou uma tela lógica associada a essa configuração de multitelas.
0 método 'getDefaultServiceContextScreen()' 1454 retorna uma instância HScreen que serve como uma tela de contexto de serviço padrão para essa configuração.
Se ao thread de chamada não tiver sido concedido MonitorAppPermission("multiscreen.configuration") , o método 'getDefaultServiceContextScreen()' 1454 gera 'java.lang.
5 SecurityException'.
O método 'getDefaultServiceContextScreen()' 1454 ^ foi aplicado a partir da versão MSM 101.
O método 'setDefaultServiceContextScreen' 1464 é declarado como 'void setDefaultServiceContextScreen 10 (org.havi.ui.HScreen screen)', e define a tela de associação do contexto de serviço padrão dessa configuração.
A tela de associação do contexto de serviço padrão de uma configuração de multitelas é a tela, com que instâncias ServiceContext são associadas, quando a configuração se tornar ativa, no caso de nenhuma informação H mais específica estar disponível para determinar como
associar a instância ServiceContext a uma tela.
0 parâmetro 'screen' é uma instância HScreen a ser designada como uma tela de associação do contexto de serviço padrão para essa configuração de multitelas.
Se ao thread de chamada não tiver sido concedido 'MonitorAppPermission("multiscreen.configuration")', o
método 'setDefaultServiceContextScreen' 1464 gera
25 'java.lang.SecurityException' . Se as restrições acima especificadas sob getDefaultServiceContextScreen() 1454 não forem satisfeitas, o método 'setDefaultService
ContextScreen' 1464 gera 'java.lang.IllegalArgument Exception'.
O método 'setDefaultServiceContextScreen' 1464 foi aplicado a partir da versão MSM 101.
0 método 'isScreenlnConfiguration(HScreen)' 1462 é declarado como 'boolean is ScreenInConfiguration (org.havi.ui.HScreen screen)'. O método
'isScreenlnConfiguration(HScreen)' 1462 determina, se os recursos subjacentes de uma tela especificada são representados por uma instância HScreen incluida no conjunto de telas associadas a essa configuração.
0 parâmetro 'screen' é um parâmetro 'HScreen'.
0 método 'isScreenlnConfiguration(HScreen)' 1462 retorna 'verdadeiro', se os recursos subjacentes da tela especificada forem representados por uma instância HScreen incluída nessa configuração; de outro modo, ele retorna 'falso'.
0 método 'isScreenlnConfiguration(HScreen)' 1462 foi aplicado a partir da versão MSM 101.
A FIG. 15A ilustra a definição da interface 'MultiScreenContext' 1230 do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
Todas Subinterfaces Conhecidas da interface 'MultiScreenContext' 1230 do pacote 'org.ocap.ui' incluem 'MultiScreenConfigurableContext', e são declaradas como 'public interface MultiScreenContext'.
A interface 'MultiScreenContext' 1230 fornece um conjunto de ferramentas para efetuar o seguinte:
1. distinguir entre instâncias HScreen, que são 5 diretamente associadas a uma VideoOutputPort, e aquelas que
são indiretamente associadas a uma VideoOutputPort através ^ um processo de mapeamento lógico; i. e., descobrir se uma
HScreen é uma tela de exibição ou uma tela lógica;
2. descobrir o único identificador de plataforma 10 de recurso subjacente de uma instância HScreen;
3. descobrir a categoria atribuída a uma HScreen dentro de sua MultiScreenConfiguration contida;
4. descobrir o mapeamento de HScreens lógicas para HScreens de exibição incluindo a área (extensão) na
15 HScreen de exibição, onde uma HScreen lógica aparece, sua visibilidade, e sua ordem z;
Ü 5. descobrir a ordem z dos HScreenDevices dentro
de uma HScreen;
6. descobrir o conjunto de ServiceContexts 20 associados a uma HScreen;
7. descobrir a associação das HScreens de exibição e das instâncias VideoOutputPort correspondentes;
8. descobrir o conjunto de HScreenDevices, cujo áudio gerado constitui o conjunto das fontes de áudio de
25 uma HScreen;
9. descobrir a atual atribuição focalizadora de áudio de uma HScreen de exibição; 10. obter notificação de alterações no estado dessa MultiScreenContext ou de certas alterações na instância HScreen que implementa essa interface;
11. obter notificação de alterações para a configuração de multitelas por exibição de uma tela de exibição;
12. descobrir o conjunto de configurações de multitelas por exibição, que pode ser usado com uma tela de exibição; e
13. obter a configuração de multitelas por exibição atualmente ativa de uma tela de exibição.
Se uma implementação OCAP não prestar suporte à Extensão do Gerenciador de Multitelas (MSM) OCAP e, de outro modo, não prestar suporte à interface 'MultiScreenContext' 1230, então um aplicativo OCAP pode assumir que o comportamento de uma HScreen é equivalente a uma instância HScreen que implementa essa interface, MultiScreenContext, cujos métodos se comportarão, como a seguir:
• getScreenType() retorna SCREEN_TYPE_DISPLAY;
• getID() retorna uma cadeia (possivelmente vazia) dependente da plataforma;
• getScreenCategory() retorna a cadeia "principal";
• getVisible() retorna 'verdadeiro'; • getZOrder() retorna '0';
• getZOrder(HScreenDevice device) retorna o índice de matrizes do dispositivo em uma matriz de instâncias HScreenDevice criadas por concatenação dos
resultados ordenados de chamada, nessa instância HScreen, dos métodos HScreen.getHBackgroundDevices(), em seguida HScreen.getHVideoDevices(), em seguida HScreen.getHGraphics Devices(), ou gera uma IllegalArgumentException, no caso do dispositivo não estiver presente nessa matriz;
· getAudioSources() retorna uma matriz de
instâncias HScreenDevice criadas por concatenação dos resultados ordenados de evocar, nessa instância HScreen, os métodos HScreen.getHBackground DevicesO, a seguir HScreen.getHVideoDevices(), a seguir HScreen.getHGraphics
Devices() ;
• getAudioFocus() retorna essa instância HScreen;
• getOutputPorts() retorna uma matriz contendo todas as VideoOutputPorts disponíveis na plataforma;
• getDisplayScreen() retorna essa instância
HScreen;
• getDisplayArea() retorna nova HScreenRectangle(0, 0,1,1) ;
• getContexts() retorna uma matriz contendo todos os ServiceContexts, que são acessáveis pelo atual
aplicativo;
Uma implementação MSM deve prestar suporte à interface MultiScreenContext 1230 em cada instância HScreen.
A interface 'MultiScreenContext' 1230 do pacote 'org.ocap.ui' foi aplicado a partir da versão MSM 101.
A FIG. 15B ilustra um campo 1500 da interface
'MultiScreenContext' 1230 do pacote 'org.ocap.ui', de ^ acordo com uma modalidade da presente invenção.
0 campo 1500 da interface 'MultiScreenContext' 1230 do pacote 'org.ocap.ui' inclui pelo menos um dentre o campo 'static int SCREEN_TYPE_DISPLAY' 1502 e o campo 'static int S C RE EN_T Y P E_L0GICAL 1504.
0 campo 'SCREEN_TYPE_DISPLAY' 1502 é declarado como 'static final int SCREEN_TYPE_DISPLAY'. Se uma HScreen for diretamente associada a uma VideoOutputPort e a extensão da HScreen for mapeada para a extensão da varredura de video produzida pela VideoOutputPort, então o tipo da HScreen é Ml SCREEN_TYPE_DISPLAY, e é chamada de uma HScreen de
exibição.
0 campo ' SCREEN_TY PE_DIS PLAY’ 1502 foi aplicado a 20 partir da versão MSM 101.
0 campo 'SCREEN_TYPE_LOGICAL' 1504 é declarado como 'static final int SCREEN_TYPE_LOGICAL'. Se uma HScreen não for diretamente associada à VideoOutputPort, ou a extensão da HScreen for mapeada para uma sub-região da varredura de 25 vídeo produzida por determinada VideoOutputPort, então o tipo de HScreen é SCREEN_TYPE_L0GICAL, e é chamado de uma HScreen lógica. Uma HScreen lógica pode ser associada a uma HScreen de exibição. Se uma HScreen lógica não for associada a uma HScreen de exibição, então uma manifestação visível ou audível não deve ser produzida por qualquer 5 ServiceContext associado à HScreen lógica.
Uma HScreen lógica, que não for associada à HScreen ^ de exibição, pode decodificar e usar conteúdo para
determinado fim diferente da apresentação. Por exemplo, a HScreen lógica pode gravar o conteúdo de um ServiceContext 10 para apresentação futura.
0 campo 'SCREEN_TYPE_LOGICAI/ 1504 foi aplicado a partir da versão MSM 101.
As FIGS. 15C e 15D ilustram um método 1550 da interface 'MultiScreenContext' 1230 do pacote 'org 15 ocap.ui', de acordo com uma modalidade da presente invenção.
fllf 0 método 1550 da interface 'MultiScreenContext'
1230 do pacote 'org.ocap.ui' inclui pelo menos um dentre: um método 'void addMultiScreenConfigurationListener 20 (MultiScreenConfigurationListener listener)' 1552, um método 'void addScreenContextListener(MultiScreenContext Listener listener)' 1554, um método 'org.havi.ui.HScreen getAudioFocus()' 1556, um método 'org.havi.ui.HScreen Device[] getAudioSources()' 1558, um método 'org.havi.ui. 25 HScreenRectangle getDisplayArea()' 1560, um método 'org.havi.ui.HScreen getDisplayScreen() -1562, um método 'java.lang.String getID()' 1564, um método 'MultiScreen Configuration getMultiScreenConfiguration ()' 1566, um método 'MultiScreenConfigurationf] getMultiScreen
ConfigurationsO' 1568, um método 'MultiScreenConfiguration 5 [getMultiScreenConfigurations(java.lang.String screen
ConfigurationType)' 1570, um método 'org.ocap.hardware.
I VideoOutputPort[] getOutputPorts()' 1572, um método
'java.lang.String getScreenCategory()' 1574, um método 'int getScreenType()' 1576, um método 'javax.tv.Service. 10 selection ServiceContext[] getServiceContexts()' 1578, um método 'boolean getVisible()' 1580, um método 'int getZOrder0 ' 1582, um método 'int getZOrder(org.havi.ui. HScreenDevice device)' 1584, um método 'void removeMulti ScreenConfigurationListener (MuitiScreenConfiguration
15 Listener listener)' 1586, e um método 'void removeScreen ContextListener(MultiScreenContextListener listener)' 1588.
0 método 'getScreenType()' 157 6 é declarado como 'int getScreenType()', e obtém o tipo dessa HScreen. 0 método 'getScreenType' 1576 retorna um valor inteiro 20 indicado por 'SCREEN_TYPE_DISPLAY' ou
'SCREEN_TYPE_LOGICAL'.
0 método 'getScreenType()' 157 6 foi aplicado a partir da versão MSM 101.
0 método 'getIDO' 1564 é declarado como 25 'java.lang.String getID()', e obtém um único identificador dependente da plataforma para a coleção de recursos subjacentes de tela indicada por essa tela, onde o escopo para exclusividade não é inferior ao conjunto de telas associadas à configuração de multitelas por plataforma atualmente ativa e todas as configurações de multitelas por 5 exibição ativas. Ele é dependente de implementação, quer o escopo para exclusividade do identificador de tela inclua, ou não, outras configurações de multitelas não-ativas.
Um identificador de tela não deve ser igual a qualquer categoria de tela retornada por
getScreenCategory().
Se Sl e S2 forem instâncias de HScreen no contexto do escopo de exclusividade implementado, e
MultiScreenManager.sameResources(SI, S2) retornar 'falso', então ((MultiScreenContext)Sl).getID() e ((MultiScreen 15 Context)S2).getID() não devem retornar a mesma cadeia (equivalente). Em contraste, se MultiScreenManager. sameResources (S1,S2) retornar 'verdadeiro', então ((MultiScreenContext) SI) .getID() e (MultiScreenContext)
S2).getID() devem retornar a mesma cadeia (equivalente).
Um valor de cadeia indicando a coleção de recursos subjacentes que essa instância HScreen representa no escopo de exclusividade implementado.
0 método 'getIDO' 1564 foi aplicado a partir da versão MSM 101.
0 método 'getScreenCategory()' 1574 é declarado como 'java.lang.String getScreenCategory()', e obtém a categoria de tela dessa instância HScreen. 0 método 'get ScreenCategoryO' 1574 pode ser uma cadeia, que é (1) um elemento da seguinte numeração de constantes definidas por 5 MultiScreenConfiguration: {o campo 'SCREEN_CATEGORY_ DISPLAY' 14 02, o campo 'SCREEN_CATEGORY_MAIN' 1406, o campo 'SCREEN_CATEGORY_PIP' 1412, o campo 'SCREEN_CATEGORY_POP' t 1414, o campo 'SCREEN_CATEGORY_OVERLAY' 1410, e o campo
'SCREEN_CATEGORY_GENERAL' 1404}, ou (2) um valor de cadeia 10 que indica uma categoria de tela dependente da plataforma, e que começa com o prefixo "x-".
0 método 'getScreenCategory' 1574 foi aplicado a partir da versão MSM 101.
0 método 'getVisible()' 1580 é declarado como 15 'boolean getVisible0', e obtém visibilidade da tela.
0 método 'getVisible ()' 1580 determina se essa HScreen é marcada como visível para apresentação em
m
determinadas HScreens de exibição, onde "visível" é definido como produzindo um sinal de varredura para uma 20 VideoOutputPort, a despeito de se a VideoOutputPort estiver habilitada ou desabilitada. Uma HScreen de exibição deve permanecer marcada como visível. A HScreen lógica pode ser visível ou oculta (não visível).
0 método 'getVisible()' 1580 retorna um valor 25 booleano, indicando se essa HScreen está marcada como visível, ou não, em determinadas HScreens de exibição. O método 'getVisible ()' 1580 foi aplicado a partir da versão MSM 101.
O método 'getZOrder()' 1582 é declarado como 'int getZOrder () ' e obtém uma ordem z de tela, isto é, ele determina a ordem z dessa HScreen. Uma HScreen de exibição deve sempre retornar uma ordem z de zero. A uma HScreen ^ lógica pode ser atribuída uma ordem z de 1 ou maior, a
menos que ela não seja associada a uma HScreen de exibição, em cujo caso sua ordem z é -I. Uma ordem z superior indica 10 uma ordem mais à frente (mais acima) dentre um conjunto de instâncias HScreen.
O método 'getZOrder' 1582 é a valor indicando a ordem z dessa HScreen ou '-1' . Se essa HScreen for uma HScreen lógica, que não for associada a uma HScreen de exibição, então '-1' deve ser retornada.
O método 'getZOrder()' 1582 foi aplicado a partir da versão MSM 101.
O 'getZOrder(HScreenDevice)' 1584 é declarado como 'int getZOrder (org.havi.ui.HScreenDevice device)', e obtém 20 uma ordem z do dispositivo de tela dentro essa tela. Isto é, o 'getZOrder(HScreenDevice)' 1584 determina a ordem z de um HScreenDevice especificado com um HScreen, onde as seguintes restrições são aplicadas:
• se um HBackgroundDevice estiver presente nessa 25 tela, então a ordem z do HBackgroundDevice mais traseiro (mais inferior) é zero; • se nenhum HBackgroundDevice estiver presente nessa tela, e se um HVideoDevice estiver presente nessa tela, então a ordem z do HVideoDeviee mais traseiro (mais inferior) é zero;
se nem HBackgroundDeviee, nem HVideoDevice, estiverem presentes nessa tela, e se um HGraphicsDeviee estiver presente nessa tela, então a ordem z do HGraphicsDeviee mais traseiro (mais inferior) é zero;
• a ordem z de um HVideoDeviee é superior à ordem z de qualquer HBackgroundDeviee nessa tela; e
• a ordem z de um HGraphicsDeviee é superior à ordem z de qualquer HVideoDeviee nessa tela.
A ordem z superior indica uma ordem mais à frente (mais acima) dentre um conjunto de instâncias HScreenDevice dentro de uma instância HScreen.
Cada conjunto distinto de dispositivos subjacentes de tela, representado como uma instância HScreen constitui uma ordenação z distinta. Isto é, determinadas instâncias múltiplas HScreen representando telas subjacentes distintas, o conjunto de valores de ordem z atribuído para os recursos subjacentes do dispositivo de tela dessas telas pode reutilizar os mesmos índices de ordem z.
O dispositivo device é um HScreenDevice, que é associado a essa tela.
O 'getZOrder(HScreenDevice)' 1584 retorna um valor não-negativo, indicando a ordem z do HScreenDevice especificado.
Se device não for um HScreenDevice dessa tela, o 'getZOrder(HScreenDevice) ' 1584 gera 'java.lang.Illegal ArgurmentExeeption'.
O 'getZOrder(HSereenDeviee)' 1584 foi aplicado a
partir da versão MSM 101.
^ 0 método 'getAudioSources()' 1558 é declarado como
'org.havi.ui.HScreenDevice[]getAudioSources()', e obtém fontes de áudio dessa tela. Isto é, o método 10 'getAudioSources()' 1558 obtém o conjunto de HScreenDevice, a partir do qual o áudio apresentado é selecionado (e combinado) para fins de apresentação de áudio a partir dessa tela.
0 conjunto padrão das fontes de áudio de uma tela 15 consiste de todas as instâncias HScreenDevice associadas à tela.
A ordem de entradas na matriz retornada pelo método 'getAudioSources()' 1558 não é definida pelo presente relatório descritivo, e deve ser considerada como 20 dependente de implementação.
0 método 'getAudioSources()' 1558 retorna uma referência a uma matriz (possivelmente vazia) de instâncias HScreenDevice, onde cada uma dessas instâncias contribui para uma apresentação de áudio combinada, a partir dessa 25 tela, ou, se essa tela não prestar suporte a áudio combinado, então pelo menos uma entrada estará presente na matriz retornada. 0 método 'getAudioSources() ' 1558 foi aplicado a partir da versão MSM 101.
O método 'getAudioFocus()' 1556 é declarado como 'org.havi.ui.HScreen getAudioFocus ()', e obtém uma tela focalizadora de áudio.
A tela focalizadora de áudio dessa HScreen é determinada, de acordo com as seguintes regras ordenadas, onde a primeira regra aplicada é usada e as outras são ignoradas:
I. Se essa HScreen for uma tela lógica, então aplicar as seguintes sub-regras ordenadas:
a. Se essa HScreen lógica for mapeada para uma tela de exibição, então aplicar as seguintes sub- regras :
i. Se a essa HScreen lógica for atualmente foco atribuído de áudio, no contexto de sua tela de exibição, então essa HScreen lógica é retornada.
ii. De outro modo (foco de áudio não atualmente atribuído na sua tela de exibição), 'nulo' é retornado.
b. De outro modo (não mapeada para uma tela de exibição), se essa HScreen lógica for diretamente mapeada para uma porta de saída de vídeo, então essa HScreen é retornada.
c. De outro modo (não mapeada para uma tela de exibição e não diretamente mapeada para uma porta de saída de vídeo), 'nulo' é retornado.
2. De outro modo (essa HScreen é uma tela de exibição), aplicar as seguintes sub-regras:
a. se determinadas telas lógicas mapeadas
para essa tela de exibição forem o foco de áudio atribuído, então essa HScreen lógica é retornada;
b. De outro modo (nenhuma tela lógica é mapeada para essa tela de exibição ou nenhuma tela lógica mapeada para essa tela de exibição é o foco de áudio atribuído), então retornar essa HScreen de exibição.
A tela focalizadora de áudio de uma tela de exibição é a tela, cujas fontes de áudio atualmente selecionadas são atribuídas para serem processadas em todos 15 os dispositivos de apresentação de áudio de todas as portas de saída de vídeo, para as quais a tela de exibição foi mapeada.
O método 'getAudioFocus()' 1556 retorna uma instância HScreen ou nulo, como acima descrito.
O método 'getAudioFocus()' 1556 foi aplicado a
partir da versão MSM 101
O método 'getOutputPorts()' 1572 é declarado como 'org.ocap.hardware.VideoOutputPorts[]getOutputPorts() , e obtém portas de vídeo, para as quais a tela foi mapeada. Isto é, o método getOutputPorts()' 1572 obtém o conjunto de VideoOutputPorts associado a essa HScreen. Se esse tipo de HScreen for SCREEN_TYPE_DISPLAY, então as instâncias VideoOutputPort associadas a essa tela de exibição devem ser retornadas. Se esse tipo de HScreen for SCREEN_TYPE_LOGICAL e essa HScreen for associada a uma 5 HScreen de exibição, então as instâncias VideoOutputPort associadas a essa HScreen de exibição devem ser retornadas. Se esse tipo de HScreen for SCREEN_TYPE_LOGICAL e essa HScreen não for associada a uma HScreen de exibição, então uma matriz vazia deve ser retornada.
0 método 'getOutputPorts()' 1572 retorna uma
referência a uma matriz de instâncias VideoOutpiitPort. Se a matriz retornada estiver vazia, então essa HScreen não é associada a qualquer VideoOutputPort.
0 método 'getOutputPorts() 1572 foi aplicado a partir da versão MSM 101.
0 método 'getDisplayScreen() ' 1562 é declarado como 'org.havi.ui.HScreen getDisplayScreen()', e obtém uma tela de exibição associada a essa tela. Isto é, o método 'getDisplayScreen()' 1562 obtém a HScreen de exibição associada a essa HScreen.
Se esse tipo de HScreen for SCREEN_T YPE_DI S PLAY, então uma referência a essa HScreen deve ser retornada. Se esse tipo de HScreen for SCREEN_TYPE_LOGICAL e essa HScreen for associada a uma HScreen de exibição, então essa HScreen 25 de exibição deve ser retornada. Se esse tipo de HScreen for SCREEN TYPE LOGICAL e essa HScreen não for associada a uma HScreen de exibição, então o valor nulo deve ser retornado.
0 método 'getDisplayScreen()' 1562 retorna uma referência a uma instância HScreen de exibição ou 'nulo' . Se 'nulo' é retornado, então essa HScreen não é associada a uma HScreen de exibição.
0 método 'getDisplayScreen() ' 1562 foi aplicado a partir da versão MSM 101.
O método 'getDisplayArea()' 1560 é declarado como 'org.havi.ui.HScreenRectangle getDisplayArea()', e obtém a área da tela de exibição, para a qual essa tela foi mapeada. O método 'getDisplayArea' 1560 obtém a área (extensão) dessa HScreen. Se esse tipo de HScreen for SCREEN_TYPE_DISPLAY, então um HScreenRectangle, cujo valor é igual ao HScreenRectangle(0,0,1,1), deve ser retornado. Se esse tipo de HScreen for SCREEN_TYPE__LOGICAL e essa HScreen for associada a uma HScreen de exibição, então a área (extensão) ocupada por essa HScreen lógica na sua HScreen de exibição associada deve ser retornada. Se esse tipo de HScreen for SCREEN_TYPE_LOGICAL, e essa HScreen não for associada a uma HScreen de exibição, então o valor 'nulo' deve ser retornado.
O método 'getDisplayArea()' 1560 retorna uma referênciá a uma instância HScreenRectangle ou 'nulo'. Se 'nulo' é retornado, então essa HScreen não é associada a uma HScreen de exibição.
O método 'getDisplayArea()' 1560 foi aplicado a partir da versão MSM 101.
O método 'getServiceContexts()' 1578 é declarado como 'j avax.tv.Service.selection.ServiceContext[]
getServiceContexts() e obtém contextos de serviço 5 associados a essa tela. Isto é, o método 'getServiceContexts ()' 1578 obtém o conjunto de
I ServiceContexts associado a essa HScreen, para qual é
concedido acesso ao aplicativo de chamada.
0 método 'getServiceContexts()' 1578 retorna uma 10 referência a uma matriz de instâncias ServiceContext. Se a matriz retornada estiver vazia, então essa HScreen não é associada a qualquer ServiceContext acessável.
0 método 'getServiceContexts()' 1578 foi aplicado a partir da versão MSM 101.
15 0 método 'addScreenContextListener (MultiScreen
ContextListener) ' 1554 é declarado como 'voidaddScreen ContextListener (MultiScreenContextListener listener)', e adiciona o ouvinte do contexto de tela. Isto é, o método 'addScreenContextListener (MultiScreenContextListener)'
20 1554 adiciona um ouvinte a ser notificado, na ocorrência de eventos de contexto de tela. Se um ouvinte tiver sido previamente adicionado e não subsequentemente removido, então uma tentativa para adicioná-lo novamente não deve produzir qualquer efeito colateral.
25 0 parâmetro listener é uma instância
MultiScreenContextListener. O método 'addScreenContextListener(MultiScreen ContextListener)’ 1554 foi aplicado a partir da versão MSM 101.
0 método 'removeScreenContextListener
(MultiScreenContextListener)' 1588 é declarado como 'void removeScreenContextListener(MultiScreenContextListener listener)' e remove o ouvinte do contexto de tela. Isto é, o método 'removeScreenContextListener(MultiScreenContext Listener)' 1588 remove um ouvinte previamente adicionado, a ser notificado na ocorrência de eventos de contexto de tela. Se o ouvinte especificado não for atualmente registrado como um ouvinte, então uma tentativa para removê-lo não deve produzir qualquer efeito colateral.
O parâmetro listener é uma instância MultiScreenContextListener.
O método 'removeScreenContextListener(Multi
ScreenContextListener)' 1588 foi aplicado a partir da versão MSM 101.
0 método 'addMultiScreenConfigurationListener (MultiScreen ConfigurationListener)' 1552 é declarado como 'void addMultiScreenConfigurationListener (MultiScreen ConfigurationListener listener)', e adiciona um ouvinte a ser notificado na ocorrência de eventos de configuração de multitelas, que são aplicados a essa tela, no caso dela ser uma tela de exibição. Se um ouvinte tiver sido previamente adicionado e não subsequentemente removido, então uma tentativa para adicioná-lo novamente não deve produzir qualquer efeito colateral.
Eventos de configuração, que são aplicados a uma tela de exibição, devem ser restritos àqueles que afetem o complemento de telas lógicas associadas a uma tela de exibição.
Se um evento definido por
MultiScreenConfigurationEvent for gerado, então a implementação MSM deve notificar, de maneira correspondente, cada ouvinte da configuração de telas registrado.
0 parâmetro listener é uma instância MultiScreenConfigurationListener.
Se o tipo dessa tela não for SCREEN_TYPE_DISPLAY, o método 'addMultiScreen ConfigurationListener
(MultiScreenConfigurationListener)' 1552 gera
'java.lang.IllegalStateException'.
O método 'addMultiScreenConfigurationListener (MultiScreenConfigurationListener) '' 1552 foi aplicado a partir da versão MSM 101.
0 método 'removeMultiScreenConfiguration Listener (MultiScreenConfigurationListener) ' 1586 é declarado como 'void.removeMultiScreenConfigurationListener (MultiScreen ConfigurationListenerlistener) ' , e remove um ouvinte 25 previamente adicionado a ser notificado na ocorrência de eventos de configuração de multitelas. Se o ouvinte especificado não for atualmente registrado como um ouvinte, então uma tentativa para removê-lo não deve produzir qualquer efeito colateral. '
0 parâmetro listener é uma instância MultiScreenConfigurationListener. O método 'removeMulti ScreenConfigurationListener (MuitiScreenConfiguration
Listener)' 1586 foi aplicado a partir da versão MSM 101.
0 método 'getMultiScreenConfigurations ()' 1568 é declarado como 'MultiScreenConfiguration[]
getMultiScreenConfigurations () e obtém o conjunto de todas as configurações de multitelas por exibição atualmente associadas a essa tela de exibição, onde o tipo de configuração de qualquer configuração de multitelas dessas não deve ser o campo 'SCREEN_CONFIGURATION_DISPLAY' 1416.
0 método 'getMultiScreenConfigurations ()' 1568
retorna uma matriz não-vazia de instâncias MultiScreenConfiguration.
Se ao thread de chamada não tiver sido concedida MonitorAppPermission("multiscreen.configuration") , o método 'getMultiScreenConfigurations()' 1568 gera
'java.lang.SecurityException'.
O método 'getMultiScreenConfigurations()' 1568 foi aplicado a partir da versão MSM 101.
0 método 'getMultiScreenConfigurations(String)' 1570 é declarado como 'MultiScreenConfiguration[ ] getMulti ScreenConfigurations(j ava.lang.String screenConfiguration Type)', e obtém configurações de multitelas por exibição de um tipo específico associado a essa tela de exibição.
0 parâmetro screenConfigurationType é (1) um elemento da seguinte numeração de constantes definidas pela 5 interface MultiScreenConfiguration: {o campo SCREEN_ CONFIGURATION_NON_PIP 1420, o campo SCREEN_CONFIGURATI0N_
I PIP 1422, o campo SCREEN_CONFIGURATION_POP 1424, e o campo
S C RE EN_C0N FIGURAT10N_GENERAL 1418}, ou (2) determinado outro valor dependente da plataforma não sendo predefinido 10 como um tipo de configuração de multitelas.
0 método 'getMultiScreenConfigurations(String)' 1570 retorna uma matriz de instâncias
MultiScreenConfiguration ou 'nulo', dependendo de se o tipo de configuração especificado é ou não assistido.
15 Se ao thread de chamada não tiver sido concedida
MonitorAppPermission("multiscreen.configuration"), o método At 'getMultiScreenConfigurations(String)' 1570 gera
' java.lang.SecurityException' .
Se screenConfigurationType for SCREEN_
20 CONFIGURATION_DISPLAY, não for definido, ou for de outro modo desconhecido para a implementação de plataforma, o método 'getMultiScreenConfigurations(String) ' 1570 gera 'java.lang.IllegalArgumentException' .
0 método 'getMultiScreenConfigurations(String)' 25 1570 foi aplicado a partir da versão MSM 101.
0 método 'getMultiScreenConfiguration' 1566 é declarado como 'MultiScreenConfiguration getMultiScreen ConfigurationO', e obtém a configuração de multitelas por exibição atualmente ativa para essa tela de exibição.
O método 'getMultiScreenConfiguration()' 1566 5 retorna a instância MultiScreenConfiguration, por exibição atualmente ativa, aplicada a essa tela de exibição.
I Se a 'HScreen' não for uma tela de exibição, o
método 'getMultiScreenConfiguration ()' 1566 gera
'java.lang.IllegalStateException'.
O método 'getMultiScreenConfiguration()' 1566 foi
aplicado a partir da versão MSM 101.
A FIG. 16A ilustra a definição da classe 'MultiScreenManager' 1260 do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
A classe 'MultiScreenManager' 1260 do pacote
'org.ocap.ui' é uma classe inferior de
' java.Iang.Object()', e todas as interfaces implementadas incluem 'org.davic.resources.ResourceServer'.
A classe 'MultiScreenManager' 1260 do pacote 20 'org.oeap.ui' é declarada como 'public abstract class MultiScreenManager', se estende para 'extends
java.Iang.Object', e é implementada como 'implements org.davic.resources.ResourceServer'.
A classe 'MultiScreenManager' 1260 é uma classe 25 abstrata, de gerenciamento singleton, implementada por uma plataforma host OCAP, que fornece serviços de gerenciamento de multitelas.
Outras restrições e comportamentos semânticos, que devem ser aplicados, serão descritos em detalhes no presente relatório descritivo.
A classe 'MultiScreenManager' 1260 do pacote
'org.ocap.ui' foi aplicada a partir da versão MSM 101.
I A FIG. 16B ilustra um construtor 1600 da classe
'MultiScreenManager' 1260 do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
O construtor 1600 da classe 'MultiScreenManager'
1260 é declarado como 'protected MultiScreenManager()', e um construtor padrão protegido.
Um 'MultiScreenManagerO' 1602 foi aplicado a partir da versão MSM 101.
As FIGS. 16C a 16F ilustram um método 1630 da
classe 'MultiScreenManager' 1260 do pacote 'org.ocap.ui', de acordo com uma modalidade da presente invenção.
O método 1630 da classe 'MultiScreenManager' 1260 do pacote 'org.ocap.ui' inclui pelo menos um dentre: um 20 método 'void addMultiScreenConfigurationListener (Multi ScreenConfigurationListener listener)' 1632, um método 'void addPlayerScreenDevices(javax.media.Player player, org.havi.ui.HScreenDevice[] devices)' 1634, um método 'void addResourceStatusListener (org.davic.resources.Resource
StatusListener listener)' 1636, um método 'org.havi.ui. HScreen[]findScreens(j avax.tv.Service.seIection.Service Context context) ' 1638, um método 'org.havi.ui.HScreen[] getCompatibleScreens (org.ocap.hardware.VideoOutputPort
port)' 1640, um método 'org.havi.ui.HScreen getDefault ScreenOf 1642, um método 'org.havi.ui.HScreen getEmpty Screen()' 1644, um método 'static MultiScreenManager getinstance()' 1646, um método 'MultiScreenConfiguration getMultiScreenConfiguration()' 1648, um método 'MultiScreen Configuration getMultiScreenConfiguration (org.havi.ui. HScreen screen) ' 1650, um método 'MultiScreen Configuration[] getMultiScreenConfigurations' 1652, um método 'MultiScreenConfiguration[] getMultiScreen
Configurations(java.lang.String screenConfigurationType) ' 1654, um método 'org.havi.ui.HScreen getOutputPortScreen (org.ocap.hardware.VideoOutputPort port)' 1656, um método 'org.havi.ui.HScreenDevice[] getPlayerScreenDevices (javax. media.Player player)' 1658, um método
'org.havi.ui.HScreen[] getScreens()' 1660, um método 'boolean isEmptyScreen(org.havi.ui.HScreen screen)' 1662, um método 'boolean isEmptyScreenDevice
(org.havi.ui.HScreenDevice device)' 1664, um método 'void moveServiceContexts(org.havi.ui.HScreen src, org.havi.ui. HScreen dst, um método javax.tv.service.selection. ServiceContext[] contexts)' 1666, um método 'void removeMultiScreen Configuration Listener(MultiScreen ConfigurationListener Iistener)' 1668, um método 'void removePlayerScreenDevices (jav ax.media.Player player, org.havi.ui.HScreenDevice[] devices)' 1670, um método 'void removeResourceStatus Listener(org.davic.resources.
ResourceStatusListener listener)' 1672, um método 'void requestMultiScreenConfigurationChange (MultiSereen
Configuration configuration, java.util.Dictionary
serviceContextAssociations)' 1674, um método 'boolean sameResources (org.havi.ui.HSereenDeviee devicel,
org.havi.ui.HSereenDeviee device2' 1676, um método 'boolean sameResources(org.havi.ui.HSereen screenl, org.havi.ui. HScreen screen2' 1678, um método 'boolean sameResources (javax.tv.service.selection.ServiceContext scl, javax.tv. service.selection.ServiceContext sc2' 1680, um método 'void setMultiScreenConfiguration(MultiScreenConfiguration configuration, java.util.Dictionary serviceContext
Associations)' 1682, e um método 'void
swapServiceContexts(org.havi.ui.HScreen screenl, org.havi. ui.HScreen screen2, javax.tv.service.selection.
ServiceContext[j exclusions)' 1684.
Métodos 1690 herdados da classe 'java.Iang.Object' incluem pelo menos um dentre 'clone', 'equals', 'finalize', 'getClass', 'hashCode', 'notify', 'notifyAll', 'toString', 'wait', 'wait', e 'wait'.
Métodos 1695 herdados da interface
'org.davic.resources.ResourceServer' incluem pelo menos um dentre 'addResourceStatusEventListener', e 'removeResource StatusEventListener'. O método 'getScreens()' 1660 é declarado como 'public org.havi.ui.HScreen[] getScreens()', e obtém o conjunto de instâncias 'HScreen' acessáveis.
O conjunto de instâncias HScreen retornadas deve 5 ser determinado, como a seguir.
Quando evocado por um aplicativo OCAP, que é ^ concedido MonitorAppPermission ("multiscreen.
configuration"), então uma instância HScreen deve ser retornada para cada tela de exibição e cada tela lógica 10 exposta através de qualquer instância
MultiScreenConfiguration acessável no momento da evocação desse método. De outro modo, uma instância HScreen deve ser retornada para cada tela de exibição e cada tela lógica, com que um ServiceContext acessável é associado 15 (diretamente ou indiretamente) para fins de apresentação, ou apresentação em potencial.
A primeira instância HScreen na matriz HScreen[] retornada deve ser igual a um valor retornado pelo método getDefaultScreen() 1642 da classe 'MultiScreen Manager' 20 1260. Elementos subsequentes à matriz retornada não seguem uma ordem preestabelecida, e um aplicativo não deve confiar na ordem desses elementos subsequentes.
0 conjunto de instâncias HScreens retornado pelo método 'getScreens()' 1660 pode sofrer alteração durante o 25 ciclo de vida de um aplicativo, tal como quando uma tela é adicionada ou removida de uma configuração acessável de multitelas. Porém, a referência de instância HScreen, que representa um aplicativo HScreen padrão, não deve permanecer constante durante o ciclo de vida do aplicativo. Isto é, a partir da perspectiva de uma determinada 5 instância de aplicativo, uma implementação MSM deve sempre retornar a mesma referência de instância HScreen, que o ^ primeiro elemento da matriz de instâncias HScreen
retornadas.
Qualquer instância HScreen retornada pelo método 10 'getScreens()' 1660 não deve ser equivalente à HScreen vazia durante o intervalo entre o tempo, quando o método 'getScreens()' 1660 retorna um valor, e o tempo, quando um evento MultiScreenConfiguration Event. MULTI_SCREEN_ C0NFIGURATI0N_CHANGING ou um evento Multi ScreenContext 15 Event.MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED é gerado e despachado.
^ Cada instância HScreen retornada pelo método
'getScreens()' 1660 pode retornar diferentes conjuntos de instâncias HScreenDevice daqueles retornados por seus 20 getHBackgroundDevices(), getHVideoDevices(), e getHGraphics DevicesO durante um ciclo de vida de um aplicativo. Porém, como abaixo descrito sob a definição do método getDefaultScreen (), o conjunto de instâncias
HBackgroundDevice, VideoDevice, e HGraphicsDevice padrão 25 retornadas por uma instância HScreen padrão via 'getHBackgroundDevices()' 'getHVideoDevices()', e 'getHGraphicsDevices()' deve permanecer constante durante o ciclo de vida de um aplicativo, enquanto que os recursos e configurações de dispositivo subjacentes dessas instâncias HScreenDevice padrão podem sofrer alteração.
Qualquer dispositivo de plano de fundo, de video,
ou de tela gráfica, i. e., HBackgroundDevice, HVideoDevice, ou HGraphicsDevice, de qualquer HScreen retornada pelo
*
método 'getScreens()' 1660 não deve ser equivalente ao HScreenDevice vazio de seu sub-tipo especifico durante o 10 intervalo entre to tempo, quando o método 'getScreens()' 1660 retorna um valor, e o tempo, quando um evento MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_ CHANGING ou evento MultiScreenContextEvent.MULTI_SCREEN_ CONTEXT_SERVICE_CONTEXT_CHANGED for gerado.
0 número de instâncias HScreenDevice retornadas por
getHBackgroundDevices, getHVideoDevices(), e
^ getHGraphicsDevices() de uma instância HScreen retornada
pelo método 'getScreens()' 1660 pode sofrer alteração durante o ciclo de vida dessa instância HScreen. Se elas 20 sofrerem alteração, então o evento MultiScreenContextEvent. MULTI_SCREEN_CONTEXT_DEVICES_CHANGED deve ser gerado e despachado a todas as instâncias MultiScreenContextListener registradas.
Se o número de instâncias HScreenDevice de um tipo 25 particular aumentar ou permanecer o mesmo (para uma determinada instância HScreen), então qualquer referência a uma instância HScreenDevice fora de padrão previamente retornada para um aplicativo deve permanecer viável, e deve, por opção da implementação MSM, (1) ser reusada para representar os novos recursos de dispositivo subjacentes desse tipo de dispositivo de tela, ou (2) ou ser restaurada para um HScreenDevice vazio do sub-tipo apropriado, conforme acima definido. No primeiro caso, a instância HScreenDevice reusada deve estar presente no conjunto de dispositivos de tela retornado por getHBackground Devices(), getHVideoDevices(), ou getHGraphicsDevices(), de acordo com seu tipo de dispositivo de tela. No último caso, a instância HScreenDevice, cujo estado foi restaurado para um estado HScreenDevice vazio, não deve estar presente no conjunto de dispositivos de tela retornado por getHBackgroundDevices() , getHVideoDevices(), ou get HGraphics Devices() .
Se o número de instâncias HScreenDevice de um tipo particular diminuir (para uma determinada instância HScreen), então qualquer referência a uma instância HScreenDevice fora do padrão previamente retornada para o aplicativo deve permanecer viável, deve ser restaurada para o estado de dispositivo de tela vazio, e não deve estar presente no conjunto de dispositivos de tela retornado pela instância HScreen.
0 efeito liquido do comportamento acima especificado é que um aplicativo, que acesse somente suas instâncias HScreen padrão e instâncias HScreenDevice padrão, pode continuar a acessar e usar aquelas instâncias, sem qualquer conhecimento da existência de funcionalidade MSM. Em contraste, um aplicativo que acesse instâncias 5 HScreen fora de padrão ou instâncias HScreenDevice fora de padrão precisa monitorar alterações para as atuais ^ configurações de multitelas por plataforma e por exibição,
bem como alterações para um conjunto de dispositivos de tela associado a uma tela não-padrão.
Se uma instância HScreen fora de padrão, que foi
previamente indicada por um aplicativo, for restaurada para um estado vazio de tela, como resultado de uma alteração na configuração de multitelas, o aplicativo pode detectar esse fato por comparação do conjunto de referências da instância 15 HScreen, que foram obtidas antes de um
MultiScreenConfigurationEvent apropriado, com aqueles obteníveis após o evento. Após esse evento, aquelas instâncias HScreen, que foram restauradas para o estado vazio, não estarão mais presentes na matriz de instâncias 20 HScreen retornadas pelo método 'getScreens ()' 1660. Além disso, aquelas instâncias HScreen previamente obtidas podem ser consultadas, quanto a se elas foram restauradas pelo uso de isEmptyScreen(HScreen) definida pela classe 'MultiScreenManager' 1260. Por último, se o aplicativo 25 continuar a fazer uso de tal instância HScreen restaurada, então seu comportamento é bem definido e imutável. Da mesma forma, se uma instância HScreenDevice fora de padrão, que foi previamente indicada por um aplicativo, for restaurada para um dispositivo de estado vazio de tela, como resultado de uma alteração na configuração de 5 multitelas, o aplicativo pode detectar esse fato por comparação do conjunto de referências da instância ^ HScreenDevice, que foram obtidas antes de um evento
MultiScreenContextEvent apropriado, com aqueles obteníveis após o evento. Após esse evento, aquelas instâncias HScreenDevice, que foram restauradas para um estado vazio, não mais serão acessáveis através do conjunto de instâncias HScreen acessáveis, retornadas pelo método 'getScreens()' 1660. Além disso, elas podem ser consultadas quanto a se elas foram restauradas pelo uso do método isEmptyScreenDevice(HScreenDevice) definido pela classe 'MultiScreenManager' 1260. Por último, se o aplicativo 41 continuar a fazer uso de tal instância HScreenDevice
restaurada, então seu comportamento é bem definido e imutável.
Se uma instância HScreen, S, não implementar a
interface MultiScreenConfigurableContext (p. ex., devido ao fato dela não ser configurável, ao ser criada, e a implementação MSM implementar seletivamente essa interface nas instâncias específicas de HScreen) , e se os novos 25 recursos subjacentes de tela forem configuráveis (e assim, essa interface ser implementada numa instância HScreen, que represente esse conjunto de recursos subjacentes de tela), então a implementação MSM não deve reusar S para representar um novo conjunto de recursos subjacentes de tela numa alteração na configuração de multitelas, mas 5 deve, ao invés disso, restaurar S para o estado vazio.
0 método 'getScreens()' 1660 retorna uma matriz não-vazia de instâncias HScreen, como acima descrito.
I
0 método 'getScreens()' 1660 foi aplicado a partir da versão MSM 101.
O método 'getDefaultScreen()' 1642 é declarado como
'public org.havi.ui.HScreengetDefaultScreen()', e obtém a instância HScreen padrão.
A instância HScreen retornada pelo método 'getDefaultScreen()' 1642 deve representar o conjunto 15 atualmente ativo de dispositivos subjacentes de tela padrão, e suas configurações de tela HAVi atualmente ativas. Além disso, a instância HScreen pode representar um conjunto de dispositivos subjacentes de tela fora de padrão atualmente ativos, e suas configurações.
A instância HScreen padrão retornada se destina a
ser o padrão, a partir da perspectiva do aplicativo de chamada ou do aplicativo, em cujo favor esse método é evocado. Se o método 'getDefaultScreen() ' 1642 for evocado pela implementação de plataforma num contexto que não 25 implique num aplicativo especifico, então o valor retornado não é definido e deve ser dependente de implementação, incluindo, p. ex., retorno 'nulo'.
Durante um ciclo de vida do aplicativo, a referência retornada pelo método 'getDefaultScreen()'1642 deve permanecer constante. Além disso, o conjunto de 5 instâncias HScreenDevice padrão retornadas por getDefautHBackground DeviceO, getDefaultHVideoDevice(), e getDefaultHGraphicsDevice0 dessa instância HScreen padrão deve da mesma forma permanecer constante durante o ciclo de vida do aplicativo. Apesar dessa constância de referência, 10 os recursos subjacentes de dispositivo e as configurações subjacentes desses recursos de dispositivo podem sofrer alteração durante um ciclo de vida do aplicativo.
Qualquer dispositivo de plano de fundo, de vídeo, ou de tela gráfica fora de padrão, i. e., 15 HBackgroundDevice, HVideoDevice, ou HGraphicsDevice, de qualquer HScreen retornada pelo método 'getDefauitScreen() ' 1642 não deve ser equivalente a um HScreenDevice vazio de seu sub-tipo específico durante o intervalo entre o tempo, quando esse método retorna, e o tempo, quando um evento 20 MultiScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_
CHANGING ou MultiScreenContextEvent.MULTI_SCREEN_ C0NTEXT_ SERVICE_CONTEXT_CHANGED é gerado.
Se qualquer parâmetro HScreenConfiguration (ou um parâmetro específico do tipo de dispositivo de tela derivado) de qualquer uma das instâncias HScreenDevice padrão retornada por 'getDefaultHBackgroundDevice()', 'getDefaultHVideoDevice()', e 'getDefaultHGraphicsDevice() ' se alterar durante o ciclo de vida de um aplicativo, então um HScreenConfigurationEvent apropriado deve ser gerado e despachado a todas as instâncias HScreenConfiguration 5 Listener registradas. Da mesma forma, se qualquer valor, que for retornado por qualquer um dos métodos de consulta (get*) da interface MultiScreenContext implementada por essa instância HScreen padrão se alterar, então um MultiScreenContextEvent apropriado deve ser gerado e 10 despachado a todas as instâncias MultiScreenContext Listener registradas.
Se qualquer instância HScreen retornada pelo método 'getDefaultScreen' 1642 implementar a interface MultiScreenConfigurableContext, então cada instância 15 HScreen retornada por esse método deve implementar a interface MultiScreenConfigurableContext, a despeito de se os recursos subjacentes de tela representados por qualquer instância HScreen retornada são, ou não, configuráveis.
O método 'getDefaultScreen' 1642 retorna uma instância HScreen, como acima descrito.
O método 'getDefaultScreen()' 1642 foi aplicado a partir da versão MSM 101.
O método 'findScreens(ServiceContext)' 1638 é declarado como 'public.org.havi.ui.HScreen[] findScreens (javax.tv.service.selection.ServiceContext context)', e localiza pelo menos uma tela acessável associada ao contexto de serviço específico. Um determinado contexto de serviço pode ser associado a zero, uma, ou múltiplas instâncias HScreen. Isto é, o método
'findScreens(ServiceContext)' 1638 localiza o conjunto de 5 instâncias HScreen acessáveis, às quais um ServiceContext especificado é associado. Uma instância HScreen é acessável (por determinados aplicativos), se o método getScreens() 1660 retornar (ou tiver que retornar) a instância HScreen (ao ser evocada pelo mesmo aplicativo, no momento em que 10 esse método for evocado).
O parâmetro 'context' é uma instância 'ServiceContext' .
O método 'findScreens(ServiceContext) ' 1638 retorna uma matriz de instâncias HScreen ou 'nulo'. Se o 15 ServiceContext especificado for associado à determinada HScreen acessável, então essa HScreen deve estar presente na matriz retornada, que não deve ser 'nula' e ser não- vazia. De outro modo, 'nulo' é retornado, indicando que o ServiceContext não é associado a qualquer HScreen.
O método 'findScreens(ServiceContext)' 1638 foi
t
aplicado a partir da versão MSM 101.
O método 'getOutputPortScreen(VideoOutputPort)" 1656 é declarado como 'public org.havi.ui.HScreen getOutputPortScreen(org.ocap.hardware.VideoOutputPort port) ' , e obtém uma tela associada a uma porta de saída. Determinada uma instância VideoOutputPort específica, o método 'getOutputPortScreen(VideoOutputPort)' 1656 obtém a instância HScreen, que é associada àquela porta para fins de apresentação.
O parâmetro port é uma instância VideoOutputPort.
O método 'getOutputPortScreen(VideoOutputPort 1656
retorna a instância HScreen associada à porta especificada, ou retorna 'nulo' se nenhuma associação existir.
O método , 'getOutputPortScreen(VideoOutputPort)' 1656 foi aplicado a partir da versão MSM 101.
0 método getCompatibleScreens(VideoOutputPort) 1640
é declarado como getCompatibleScreens
(org.ocap.hardware.VideoOutputPort port), e obtém o conjunto de telas acessáveis, que são compatíveis com uma porta de saída.
Determinada uma instância VideoOutputPort
específica, o método getCompatibleScreens (VideoOutputPort) 1640 obtém o subconjunto de instâncias HScreen (do maior conjunto retornado pelo método getScreens()), que pode ser associado a essa porta, para fins de apresentação.
Um parâmetro port é uma instância VideoOutputPort.
0 método getCompatibleScreens(VideoOutputPort) 1640 retorna uma matriz (possivelmente vazia) de instâncias HScreen, que podem ser associadas à porta especificada.
0 método getCompatibleScreens(VideoOutputPort) 1640
foi aplicado, a partir da versão MSM 101.
0 método getMultiScreenConfigurations() 1652 é declarado como public MultiScreenConfiguration[]
getMultiScreenConfigurations (), e obtém o conjunto de todas as atuais configurações de multitelas assistidas por essa plataforma, a despeito de seu tipo de configuração.
O conjunto de instâncias de configuração de
multitelas retornado pelo método getMultiScreen ^ Configurations() 1652 deve incluir todas as configurações
de multitelas por plataforma (compostas exclusivamente das telas de exibição) e todas as configurações de multitelas 10 por exibição (compostas de não mais de uma tela de exibição e qualquer número de telas lógicas).
A ordem das configurações de multitelas retornada pelo método getMultiScreenConfigurations() 1652 não é definida por esse relatório descritivo.
0 método getMultiScreenConfigurations() 1652
retorna uma matriz de instâncias MultiScreenConfiguration. ||k 0 método getMultiScreenConf igurations () 1652 deve
gerar java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida MonitorAppPermission 20 ("multiscreen.configuration") .
0 método getMultiScreenConfigurations() 1652 foi aplicado a partir da versão MSM 101.
0 método getMultiScreenConfigurations(String) 1654 é declarado como public MultiScreenConfiguration[] 25 getMultiScreenConfigurations(java.Iang.String screen
ConfigurationType), e obtém configurações de multitelas de um tipo específico de configuração.
Um parâmetro screenConfigurationType é um dos seguintes valores: (1) um elemento da seguinte numeração de constantes definidas por MultiScreenConfiguration: {SCREEN_ 5 C0NFIGURATI0N_DISPLAY 1416, SCREEN_C0NFIGURATI0N_N0N_PIP 1420, SCREEN_C0NFIGURATI0N_PIP 1422, SCREEN_C0NFIGURATI0N_ POP 1424, SCREEN_C0NFIGURATI0N_GENERAL 1418), ou (2) determinado outro valor dependente da plataforma não predefinido como um tipo de configuração de multitelas.
0 conjunto de instâncias de configuração de
multitelas retornado pelo método getMultiScreen Configurations(String) 1654 deve incluir todas as configurações de multitelas do tipo especificado, que aparece na matriz retornada pelo método
getMultiScreenConfigurations() 1652.
A ordem das configurações de multitelas retornada pelo método getMultiScreenConfigurations(String) 1654 não é definida por esse relatório descritivo.
0 método getMultiScreenConfigurations(String) 1654 retorna uma matriz de instâncias MultiScreen Configuration ou nula, dependendo de se o tipo de configuração especificado é ou não assistido.
0 método getMultiScreenConfigurations(String) 1654 gera java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida
MonitorAppPermission("Multiscreen.configuration"). O método getMultiScreenConfigurations(String) 1654 foi aplicado a partir da versão MSM 101.
O método getMultiScreenConfiguration(HScreen) 1650 é declarado como public MultiScreenConfiguration getMultiScreenConfiguration(org.havi.ui.HScreen screen), e obtém a configuração de multitelas de uma tela específica.
Uma determinada instância HScreen deve ser associada a zero ou exatamente a uma instância de configuração de multitelas; porém, visto que uma única tela subjacente pode ser potencialmente compartilhada (múltiplas vezes mencionada) por múltiplas instâncias HScreen, uma tela subjacente (e seus recursos constituintes) pode ser associada a mais de uma configuração de multitelas.
Um parâmetro screen é uma instância HScreen.
0 método getMultiScreenConfiguration(HScreen) 1650 retorna a instância MultiScreenConfiguration, de qual a HScreen especificada é uma tela constituinte ou nulo, se a HScreen especificada for órfã (i. e., não pertencente a uma configuração de multitelas, p. ex., conforme seria o caso, se ela fosse uma tela vazia).
0 método getMultiScreenConfiguration(HScreen) 1650 foi aplicado a partir da versão MSM 101.
0 método getMultiScreenConfiguration() 1648 é declarado como public MultiScreenConfiguration
getMultiScreenConfiguration() , e obtém uma configuração de multitelas de exibição por plataforma atualmente ativa. O método getMultiScreenConfiguration() 1648 retorna a instância MultiScreenConfiguration de exibição por plataforma atualmente ativa.
O método getMultiScreenConfiguration() 1648 foi aplicado a partir da versão MSM 101.
0 método setMultiScreenConfiguration() 1682 é declarado como public void setMultiScreenConfiguration (MultiScreenConfiguration configuration, java.util.
Dictionary serviceContextAssociations), e define a configuração de multitelas de exibição por plataforma atualmente ativa.
Se a configuração especificada for a atual configuração de multitelas de exibição por plataforma, então, a menos que SecurityException se aplique, o método setMultiScreenConfiguration() 1682 retorna um valor sem produzir qualquer efeito colateral.
Se a configuração especificada não for a atual configuração de multitelas de exibição por plataforma e se SecurityException, IllegalArgumentException, e
IllegalStateException não se aplicarem, então o método setMultiScreenConfiguration() 1682 executa o processamento de alteração síncrona da configuração de multitelas por plataforma definido pela especificação da Extensão do Gerenciador de Multitelas (MSM) OCAP.
Se o argumento serviceContextAssociations for
especificado (i. e., não nulo), então qualquer instância ServiceContext, que for acessável para o aplicativo de chamada, não deve ser associada a nenhuma tela, ou deve ser associada a tela(s) aplicável(eis) na (nova) configuração de multitelas por plataforma especificada (ou nas suas 5 configurações de multitelas por exibição). Se nenhuma associação corresponder a determinado ServiceContext acessável, se determinada instância ServiceContext acessável não estiver presente nas associações especificadas, ou se ela estiver presente, mas nenhuma 10 dessas telas aplicáveis existir na nova configuração de multitelas por plataforma (ou nas suas configurações de multitelas por exibição), então a instância ServiceContext deve ser associada à tela de associação do contexto de serviço padrão da configuração de multitelas especificada, 15 i. e., à tela retornada por configuration.getDefaultService ContextScreenO .
Para fins de correspondência das instâncias ServiceContext acessáveis, cujas referências aparecem como chaves num serviceContextAssociationsdictionary
especificado, o método virtual equals(Object) nessas chaves deve ser usado, em cujo caso é suposto que o método setMultiScreenConfiguration() 1682 se comporte de modo idêntico para a implementação padrão de um método Object.equals(0bject).
No contexto de uma determinada instância de
aplicativo, a implementação do host MSM deve manter uma relação um-por-um entre instâncias ServiceContext expostas àquele aplicativo e coleções de recursos subjacentes de contexto de serviço. Se a implementação do host MSM deixar de manter essa relação, então, ao consultar um serviceContextAssociations dicionary, a implementação MSM pode considerar duas coleções distintas de recursos subjacentes de contexto de serviço, como sendo o mesmo contexto de serviço, p. ex., se em diferentes momentos, uma única instância ServiceContext fizer referência a coleções distintas de recursos subjacentes, ou pode considerar uma única coleção de recursos subjacentes de contexto de serviço, como sendo dois contextos de serviço distintos, p. ex., se, em um determinado momento, duas instâncias ServiceContext distintas fizerem referência à mesma coleção de recursos subjacentes.
0 estado do componente de conversão de formato do decodificador (DFC) de a pipeline de vídeo sendo usado para processar vídeo associado a um contexto de serviço, que é implicitamente trocado ou movido entre telas pelo método setMultiScreenConfiguration() 1682, não deve ser afetado pelo desempenho do método setMultiScreenConfiguration() 1682.
Um parâmetro configuration é uma instância MultiScreenConfiguration a se tornar a configuração de multitelas de exibição por plataforma atualmente ativa.
Um parâmetro serviceContextAssociations é, se não nulo, uma instância Dictionary, cujas chaves são instâncias ServiceContext e cujos valores são instâncias String, onde os valores de cadeia são definidos, como a seguir: (1) se o valor de cadeia for então nenhuma tela é aplicada (em
5 cujo caso, um contexto de serviço correspondente não é associado a qualquer tela após a alteração da configuração), (2) de outro modo, se o valor de cadeia for
*
então todas as telas da nova configuração de tela se aplicam, (3) de outro modo, se o valor de cadeia for um 10 identificador de tela, conforme retornado por um método MultiScreenContext.getID(), então essa tela é aplicada, (4) de outro modo, se o valor de cadeia for uma categoria de tela, conforme retornada por um método
MultiScreenContext.getScreenCategory(), então qualquer tela 15 da nova configuração com essa categoria é aplicada, (5) de outro modo, se o valor de cadeia for uma lista de identificadores de tela separados por ponto e vírgula, então cada tela da nova configuração com um identificador de correspondência se aplica, (6) de outro modo, se o valor 20 de cadeia for uma lista de categorias de tela separadas por ponto e vírgula, então cada tela da nova configuração com uma categoria correspondente é aplicada, (7) de outro modo, se o valor de cadeia for uma lista de identificadores de tela ou categorias de tela separados por ponto e vírgula, 25 então cada tela da nova configuração com um identificador ou categoria de correspondência é aplicada, (8) de outro modo, a tela de associação do contexto de serviço padrão da nova configuração é aplicada.
0 método setMultiScreenConfiguration () 1682 gera java.Iang.SecurityException, se ao thread de chamada não 5 tiver sido concedida MonitorAppPermission
("multiscreen.configuration").
^ O método setMultiScreenConfiguration() 1682 gera
java.lang.IllegalArgumentException, se um parâmetro configuration não for uma configuração de multitelas por 10 plataforma, que será retornada por MultiScreenManager. getMultiScreenConfigurations(SCREEN_CONFIGURATION_DISPLAY).
O método setMultiScreenConfiguration () 1682 gera java.Iang.IllegalStateException, se a implementação MSM (1) não permitir a ativação da configuração de multitelas 15 especificada, (2) se o método setMultiScreenConfiguration() 1682 for previamente evocado, e as etapas de processamento da alteração não estiverem ainda concluídas, ou (3) se a ativação não for de outro modo permitida, no momento da evocação do método.
0 método setMultiScreenConfiguration() 1682 foi
aplicado a partir da versão MSM 101.
0 método requestMultiScreenConfigurationChange 1674 é declarado pela public void requestMultiScreen ConfigurationChange (MuitiScreenConfiguration
configuration, java.util.Dictionary serviceContext
Associations), e solicita alteração para uma configuração de multitelas de exibição por plataforma atualmente ativa.
Se a configuração especificada for a configuração atual, então, a menos que SecurityException se aplique, o método requestMultiScreenConfigurationChange 1674 retorna um valor sem produzir qualquer efeito colateral.
Se a configuração especificada não for a atual
configuração de multitelas de exibição por plataforma e se
SecurityException, IllegalArgumentException, e
\
IllegalStateException não se aplicar, então o método 10 requestMultiScreenConfigurationChange 1674 inicia uma alteração assincrona para a configuração atual de multitelas por plataforma, onde a semântica do método setMultiScreenConfiguration() 1682 se aplica, exceto que o método requestMultiScreenConfigurationChange 1674 deve 15 retornar imediatamente, após um evento MultiScreen Configuration.MULTI_SCREEN_CONFIGURATION_CHANGING ser
gerado (mas antes dele ser despachado).
Um parâmetro configuration é uma instância MultiScreenConfiguration a se tornar a configuração de tela 20 atualmente ativa. Um parâmetro serviceContextAssociations é nulo ou uma instância Dictionary, cujas chaves são instâncias ServiceContext, e cujos valores são instâncias String, com semântica, conforme definida por setMultiScreenConfiguration(..) acima.
0 método requestMultiScreenConfigurationChange 1674
gera java.lang.SecurityException, se ao thread de chamada não tiver sido concedida
MonitorAppPermission("multiscreen.configuration") .
O método requestMultiScreenConfigurationChange 1674 gera java.Iang.IllegalStateException (1), se a
5 implementação MSM não permitir a ativação da configuração de multitelas especificada, (2) se o método ^ requestMultiScreenConfigurationChange 1674 for previamente
evocado, e as etapas de processamento da alteração não estiverem ainda concluídas, ou (3) se a ativação não for de 10 outro modo permitida, no momento da evocação do método.
O método requestMultiScreenConfigurationChange 1674 foi aplicado a partir da versão MSM 101.
0 método addMultiScreenConfigurationListener 1632 é declarado como public void addMultiScreen
15 ConfigurationListener(MultiScreenConfigurationListener
listener), e adiciona um ouvinte a ser notificado, na ocorrência de eventos de configuração de multitelas. Se um ouvinte tiver sido previamente adicionado e não subsequentemente removido, então uma tentativa para 20 adicioná-lo novamente não deve produzir um efeito colateral.
Eventos de configuração, que se apliquem a essa instância MultiScreenManager singleton, devem ser restritos àqueles que afetem o complemento das telas de exibição 25 utilizáveis.
Se um evento definido por MultiScreen ConfigurationEvent for gerado, então a implementação MSM deve notificar cada ouvinte da configuração de telas registrada, de maneira correspondente.
Um parâmetro listener é uma instância MultiScreenConfigurationListener.
O método addMultiScreenConfigurationListener 1632 foi aplicado a partir da versão MSM 101.
O método removeMultiScreenConfiguration Listener 1668 é declarado como public void
removeMultiScreenConfigurationListener(MultiScreen
ConfigurationListener listener), e remove um ouvinte previamente adicionado, a ser notificado na ocorrência de eventos de configuração de multitelas. Se o ouvinte especificado não for atualmente registrado como um ouvinte, 15 então uma tentativa para removê-lo não deve produzir um efeito colateral.
Um parâmetro listener é uma instância MultiScreenConfigurationListener.
O método removeMultiScreenConfigurationListener 1668 foi aplicado a partir da versão MSM 101.
0 método addResourceStatusListener 1636 é declarado como public void addResourceStatusListener
(org.davic.resources.ResourceStatusListener listener), e adiciona um ouvinte do estado de recurso.
Um parâmetro listener é uma instância
ResourceStatusListener. O método addResourceStatusListener 1636 foi aplicado a partir da versão MSM 101.
O método removeResourceStatusListener 1672 é declarado como public void removeResourceStatusListener (org.davic.resources.ResourceStatusListener listener), e remove um ouvinte do estado de recurso.
Um parâmetro listener é uma instância ResourceStatusListener.
0 método removeResourceStatusListener 1672 foi aplicado a partir da versão MSM 101.
0 método swapServiceContexts 1684 é declarado como public void swapServiceContexts(org.havi.ui.HScreen
screenl, org.havi.ui.HScreen screen2, javax.tv.service. selection. ServiceContext [ ] exclusi.ons) , e permuta, de forma atômica, contextos de serviço entre duas instâncias HScreen.
0 método swapServiceContexts 1684 é um método de conveniência para dar suporte ao funcionamento comum da apresentação do conteúdo de permutação entre telas. Resultados similares obtidos pelo método
swapServiceContexts 1684 podem ser também alcançados pelo mecanismo mais genérico de remover e adicionar contextos de serviço a telas específicas acessáveis pelo uso dos métodos MultiScreenConfigurableContext.addService Context (..) e 25 MultiScreenConfigurableContext.removeService Context (..). Todavia, o uso do método mais genérico pode resultar em mais artefatos de transição de apresentação, do que o uso do método swapServiceContexts 1684, devido à semântica de troca atômica do método swapServiceContexts 1684.
0 estado do componente de conversão de formato do 5 decodificador (DFC) de um pipeline de video sendo usado para processar vídeo associado a um contexto de serviço, que está sendo trocado pelo método swapServiceContexts 1684, não deve ser afetado pelo desempenho do método swapServiceContexts 1684. ,
Um parâmetro screenl é uma instância HScreen, cujos
contextos de serviço devem ser trocados com aqueles do screen2.
Um parâmetro screen2 é uma instância HScreen, cujos contextos de serviço devem ser trocados com aqueles do screenl.
Um parâmetro exclusions, se não nulo, é então uma matriz não-vazia de instâncias ServiceContext a serem excluídas da operação de permuta, i. e., cujas associações de tela não devem ser afetadas pela permuta.
O método swapServiceContexts 1684 gera
java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida MonitorAppPermission
("multiscreen.configuration")
0 método swapServiceContexts 1684 gera java.Iang.IllegalStateException, se qualquer um do seguinte ocorrer: (1) vídeo está sendo apresentado como vídeo de componente, ao invés do vídeo de plano de fundo numa tela, ou (2) os ServceContexts para as telas especificadas não puderem ser alterados, p. ex., se a plataforma usar uma associação permanente com um ServiceContext específico e uma tela.
0 método swapServiceContexts 1684 foi aplicado a partir da versão MSM 101.
0 método moveServiceContexts 1666 é declarado como public void moveServiceContexts(org.havi.ui.HScreen src, org.havi.ui.HScreen dst, javax.tv.service.selection.
ServiceContext[] contexts), e move, de forma atômica, um conjunto de contextos de serviço específicos a partir de uma instância HScreen para outra instância HScreen.
0 método moveServiceContexts 1666 é um método de conveniência para dar suporte ao funcionamento comum de mover apresentações de conteúdo entre telas para um conjunto de determinados contextos de serviço. Resultados similares obtidos pelo método moveServiceContexts 1666 podem ser também alcançados, pelo mecanismo mais genérico de remover e adicionar o contexto de serviço à telas acessáveis específicas, pelo uso dos métodos MultiScreen Configurable Context.addServiceContexts(..) e MultiScreen ConfigurableContext.removeServiceContexts(..). Todavia, o uso do método mais genérico pode resultar em mais artefatos de transição de apresentação, do que o uso do método moveServiceContexts 1666, devido à semântica de movimento atômico do método moveServiceContexts 1666.
O estado do componente de conversão de formato do decodificador (DFC) de um pipeline de vídeo sendo usado para processar vídeo associado a um contexto de serviço, 5 que está sendo movido pelo método moveServiceContexts 1666, não deve ser afetado pelo desempenho do método moveServiceContexts 1666.
Um parâmetro src é uma instância HScreen, a partir da qual os contextos de serviço especificados devem ser movidos.
Um parâmetro dst é uma instância HScreen, para a qual os contextos de serviço especificados devem ser movidos.
Um parâmetro contexts é uma matriz não-vazia de instâncias ServiceContext, a ser movida de uma tela src para uma tela dst.
O método moveServiceContexts 1666 gera java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida MonitorAppPermission
("multiscreen.configuration").
0 método moveServiceContexts método 1666 gera java.Iang.IllegalArgumentException, se determinado
ServiceContext especificado não for atualmente associado à instância de origem HScreen, src.
0 método moveServiceContexts 1666 gera
java.Iang.IllegalStateException, se qualquer um do seguinte ocorrer: (1) video está sendo apresentado como vídeo de componente, ao invés do vídeo de plano de fundo numa tela; (2) determinado ServiceContext especificado para as telas especificadas não puder ser movido, p. ex., se a plataforma usar uma associação permanente com um ServiceContext específico e uma tela; ou (3) um ServiceContext não- abstrato já for associado à tela de destino, e a plataforma prestar suporte somente a um ServiceContext não-abstrato por tela.
0 método moveServiceContexts 1666 foi aplicado a partir da versão MSM 101.
O método getPlayerScreenDevices 1658 é declarado como public org.havi.ui.HScreenDevice[] getPlayer
ScreenDevices(javax.media.Player player), e obtém o conjunto de dispositivos de tela atualmente atribuídos para uso por um Java Media Framework (JMF) media player.
Um parâmetro player é uma instância JMF Player, para consulta por parte de seu conjunto de dispositivos de tela.
0 método getPlayerScreenDevices 1658 é uma matriz de instâncias HScreenDevice, que deve estar vazia, se, e somente se, não houver nenhum dispositivo de tela associado.
0 método getPlayerScreenDevices 1658 foi aplicado a partir da versão MSM 101.
0 método addPlayerScreenDevices 1634 é declarado como public void addPlayer ScreenDevices
(javax.media.Player player, org.havi.ui.HScreenDevice[] devices), adiciona dispositivo(s) de tela a um media player.
Um parâmetro player é uma instância JMF Player para
consulta pelo(s) dispositivo(s) de tela especificado(s). Um parâmetro devices é uma matriz não-vazia de instâncias HScreenDevice, para apresentar determinado tipo de conteúdo processado, através do media player especificado.
O método addPlayerScreenDevices 1634 gera
java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida MonitorAppPermission
("multiscreen.context").
0 método addPlayerScreenDevices 1634 gera 15 java.Iang.IllegalStateException, se qualquer um do seguinte ocorrer: (1) o player especificado não estiver em um estado parado; (2) o dispositivo de tela especificado não for compatível com o player especificado; (3) determinado dispositivo de tela subjacente de devices não estiver 20 disponível para uso por esse aplicativo, p. ex., devido a ser exclusivamente reservado por outro aplicativo; ou (4) determinado dispositivo de tela subjacente de devices já for associado a um media player, e esse dispositivo não prestar suporte à associação com múltiplos media players.
0 método addPlayerScreenDevices 1634 foi aplicado a
partir da versão MSM 101. Mais informações detalhadas sobre o método addPlayerScreenDevices 1634 são obtidas fazendo referência às instâncias HScreenDevice, Player.
0 método removePlayerScreenDevices 1670 é declarado como public void removePlayerScreenDevices(javax. media. Player player, org.havi.ui.HScreenDevice[] devices), e remove dispositivo(s) de tela de um media player. Em outras palavras, todas ou um conjunto não-vazio de instâncias HScreenDevice são removidas do conjunto de dispositivos de tela, no qual o media player especificado for apresentado (ou de outro modo associado para apresentação). Se devices for nulo, então todas as associações dos dispositivos de tela são removidas.
O método removePlayerScreenDevices 1670 gera java.Iang.SecurityException, se ao thread de chamada não tiver sido concedida MonitorAppPermission
("multiscreen.context") .
0 método removePlayerScreenDevices 1670 gera java.Iang.IllegalArgumentException, se devices não for nulo e determinada entrada de devices não for associada à instância do Player especificado.
0 método removePlayerScreenDevices 1670 gera java.Iang.IllegalStateException, se o player especificado não estiver em um estado parado.
0 método removePlayerScreenDevices 1670 foi aplicado a partir da versão MSM 101. O método getEmptyScreen() 164 4 é declarado como public org.havi.ui.HScreen getEmptyScreen(), e obtém a instância HScreen singleton vazia.
Usando essa HScreen vazia, o método getEmptyScreen() 1644 pode obter uma referência para a HScreenDevice vazia, HScreenConfiguration vazia, e HScreen ConfigTemplate vazia de cada sub-tipo disponível, p. ex., HBackgroundDevice, HVideoDevice, HGraphicsDevice, etc.
A presença do método getEmptyScreen 1644 é essencialmente destinada a dar suporte aos testes da funcionalidade MSM, tal como a semântica de isEmptyScreen(), isEmptyScreenDevice() , sameResources() , etc.
O método getEmptyScreen() 1644 retorna a HScreen singleton vazia. O método getEmptyScreen() 1644 foi aplicado a partir da versão MSM 101.
O método isEmptyScreen 1662 é declarado como public boolean isEmptyScreen(org.havi.ui.HScreen screen), e determina se uma instância de HScreen é equivalente, em termos de satisfação à restrição, a uma HScreen vazia.
Se screen não implementar
MultiScreenConfigurableContext, então aquelas restrições, que pertencerem ao MultiScreenConfigurableContext, devem ser consideradas como equivalentes.
Um parâmetro screen é uma instância HScreen.
O método isEmptyScreen 1662 retorna verdadeiro, se a tela especificada for equivalente à HScreen vazia.
0 método isEmptyScreen 1662 foi aplicado a partir da versão MSM 101.
O método isEmptyScreenDevice 1664 é declarado como public boolean isEmptyScreenDevice (org.havi . ui.
HScreenDevice device), e determina se uma instância de HScreenDevice é equivalente, em termos de satisfação à restrição, para o HScreenDevice vazio do sub-tipo especifico.
Um parâmetro device é uma instância HScreenDevice
de um dos seguintes sub-tipos: HBackgroundDevice, HVideoDevice, ou HGraphicsDevice.
0 método isEmptyScreenDevice 1664 retorna verdadeiro, se o dispositivo especificado for equivalente
ao HScreenDevice vazio do sub-tipo de correspondência.
0 método isEmptyScreenDevice 1664 foi aplicado a partir da versão MSM 101.
0 método sameResources(HScreen, HScreen) 1678 é declarado como public boolean sameResources(org.havi.ui.
HScreen screenl, org.havi.ui.HScreen screen2), e determina se duas instâncias HScreen representam os mesmos recursos subjacentes de plataforma e estado de recurso subjacente, i. e., são equivalentes com relação a esses recursos subj acentes.
Para fins de determinar equivalência, as seguintes
condições devem ser aplicadas: • se exatamente um dentre screenl e screen2 for equivalente à HScreen vazia, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se, para cada dispositivo de tela, BDl, retornado por screenl.getHBackgroundDevices(), não houver
exatamente um dispositivo de tela, BD2, retornado por screen2.getHBackgroundDevices(), de forma que sameResources (BD1,BD2) retorne verdadeiro, então as duas telas não são equivalentes com relação aos recursos subjacentes;
· se, para cada dispositivo de tela, VDl,
retornado por screenl.getHVideoDevices (), não houver exatamente um dispositivo de tela, VD2, retornado por screen2.getHVideoDevices(), de forma que sameResources (VD1,VD2) retorne verdadeiro, então as duas telas não são
equivalentes com relação aos recursos subjacentes;
• se, para cada dispositivo de tela, GDI, retornado por screenl.getHGraphicsDevices(), não houver exatamente um dispositivo de tela, GD2, retornado por screen2.getHGraphicsDevices(), de forma que sameResources
(GD1,GD2) retorne verdadeiro, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se, determinado um conjunto equivalente de argumentos de modelo, screenl.getBestConfiguration(..) e screen2.getBestConfiguration(..) não retornar conjuntos
(nominalmente não ordenados) de instâncias
HScreenConfiguration equivalentes, então as duas telas não são equivalentes com relação aos recursos subjacentes; se, determinado um conjunto equivalente de argumentos de configuração de tela, screenl.get CoherentScreenConfigurations(..) e screen2.getCoherent ScreenConfigurations(..) não retornarem conjuntos de instâncias HScreenConfiguration equivalentes, então as duas telas não são equivalentes com relação aos recursos subj acentes;
• se, determinado um conjunto equivalente de argumentos de configuração de tela, screenl.setCoherent ScreenConfigurations(..) e screen2.setCoherentScreen Configurations (..) não retornarem o mesmo valor, ou não modificarem o conjunto dos dispositivos de tela associados aos argumentos da configuração de tela especificada, de forma que aqueles dispositivos de tela permaneçam equivalentes, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se nenhuma das condições acima for aplicada, então screenl e screen2 são consideradas equivalentes com relação aos recursos subjacentes;
Os parâmetros screenl e screen2 são instâncias
HScreen.
Um valor verdadeiro é retornado, se as telas especificadas forem equivalentes, como descrito pelas condições acima.
0 método sameResources(HScreen, HScreen) 1678 foi aplicado a partir da versão MSM 101. 0 método sameResources(HScreenDevice,
HScreenDevice) 1676 é declarado como public boolean sameResources(org.havi.ui.HScreenDevice devicel,
org.havi.ui.HScreenDevice device2), e determina se duas instâncias HScreenDevice representam os mesmos recursos subjacentes de plataforma e estado de recurso subjacente, i. e., são equivalentes com relação a esses recursos subj acentes.
Para fins de determinar equivalência, as seguintes condições devem ser aplicadas:
• se devicel e device2 não forem do mesmo sub- tipo, HBackgroundDevice, HVideoDevice, ou HGraphicsDevice, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
• se exatamente um dos devicel e device2 for equivalente ao HScreenDevice vazio do sub-tipo apropriado, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
se devicel.getFlickerFilter() e
device2.getFlickerFilter() não retornarem o mesmo valor, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
• se devicel.getlnterlaced() e device2.getlnterlaced() não retornarem o mesmo valor, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
• se devicel.getPixelAspectRatio() e device2.getPixelAspectRatio() não retornarem valores equivalentes, então os dois dispositivos de tela não são
equivalentes com relação aos recursos subjacentes;
• se devicel.getPixelResolution() e ^ device2.getPixelResolution() não retornarem valores
equivalentes, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
· se devicel.getScreenArea() e
device2.getScreenArea() não retornarem valores
equivalentes, então os dois dispositivos de tela não são equivalentes com relação aos recursos subjacentes;
• se determinadas instâncias HScreenConfiguration 15 equivalentes, SCI e SC2, como argumentos,
devicel.getOffset(SCI) e device2.getOffset (SC2), não φ retornarem valores equivalentes, então os dois dispositivos
de tela não são equivalentes com relação aos recursos subj acentes;
· se determinadas instâncias HScreenConfiguration
equivalentes, SCI e SC2, e instâncias Point equivalentes, Pl e P2, como argumentos, devicel.convertTo(SCI,Pl) e device2.convertTo(SC2, P2 ) não retornarem valores
equivalentes, então os dois dispositivos de tela não são 25 equivalentes com relação aos recursos subjacentes;
• se devicel.getConfigurations() e device2.getConfigurations() não retornarem conjuntos (nominalmente não ordenados) de instâncias
HScreenConfiguration equivalentes, então as duas telas não são equivalentes com relação aos recursos subjacentes;
· se devicel.getCurrentConfiguration () e
device2.getCurrentConfiguration() não retornarem instâncias HScreenConfiguration equivalentes, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se devicel.getDefaultConfiguration() e device2.getDefaultConfiguration() não retornarem instâncias
HScreenConfiguration equivalentes, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se, determinado um argumento de modelo, ou conjuntos de argumentos de modelo equivalentes,
devicel.getBestConfiguration(..) e device2.getBest
Configuration(..) não retornarem conjuntos de instâncias HScreenConfiguration equivalentes, então as duas telas# não são equivalentes com relação aos recursos subjacentes;
• se devicel e device2 forem instâncias de HBackgroundDevice, e se devicel.set BackgroundConfiguration
(..) e device2.setBackgroundConfiguration(..) não
retornarem o mesmo valor, quando instâncias HBackgroundConfiguration equivalentes forem especificadas como argumentos, então as duas telas não são equivalentes com relação aos recursos subjacentes;
• se devicel e device2 forem instâncias de HVideoDevice, e se (1) devicel.setVideoConfiguration(..) e device2.setVideoConfiguration(..) não retornar o mesmo valor, quando instâncias HVideoConfiguration equivalentes forem especificadas como argumentos, (2)
devicel.getVideoSource() e devicel.getVideoSource() não retornar fontes de video nominalmente equivalentes, ou (3) devicel.getVideoController() e devicel.getVideoController() não retornar controladores de vídeo nominalmente equivalentes, então as duas telas não são equivalentes, com relação aos recursos subjacentes;
• se devicel e device2 forem instâncias de HGraphicsDevice, e se devicel.setGraphicsConfiguration(..) e device2.setGraphicsConfiguration(..) não retornarem o mesmo valor, quando instâncias HGraphicsConfiguration equivalentes forem especificadas como argumentos, então as duas telas não são equivalentes, com relação aos recursos subj acentes;
• se nenhuma das condições acima se aplicar, então devicel e device2 são considerados equivalentes com relação aos recursos subjacentes;
Os parâmetros devicel e device2 são instâncias HScreenDevice.
O método sameResources(HScreenDevice,
HScreenDevice) 1676 retorna verdadeiro, se as telas especificadas forem equivalentes, como descrito pelas condições acima. O método sameResources(HScreenDevice,
HScreenDevice) 167 6 foi aplicado a partir da versão MSM 101.
O método sameResources(ServiceContext,
ServiceContext) 1680 é declarado como public boolean sameResources(j avax.tv.service.selection.ServiceContext scl, javax.tv.service.selection.ServiceContext sc2), e determina se duas instâncias ServiceContext representam os mesmos recursos subjacentes de plataforma e estado de 10 recurso subjacente, i.e., são equivalentes com relação a esses recursos subjacentes.
Os parâmetros scl e sc2 são instâncias ServiceContext.
O método sameResources(ServiceContext,
ServiceContext) 1680 retorna verdadeiro, se os contextos de serviço especificados forem equivalentes (i. e., representarem os mesmos recursos subjacentes e estado de recursos) .
0 método sameResources(ServiceContext, Service Context) 1680 foi aplicado a partir da versão MSM 101.
0 método getInstance() 164 6 é declarado como public static MultiScreenManager getInstance(), e obtém a instância singleton do MultiScreenManager. A instância MultiScreenManager é retornada.
O método getInstance() 1646 foi aplicado a partir
da versão MSM 101. A FIG. 17 ilustra uma interface 1700 e uma classe 1710 de um pacote org. ocap. ui. event, de acordo com uma modalidade da presente invenção.
O pacote org.ocap.ui.event possui extensões para as classes de Evento da Interface de Usuário HAVi, incluindo eventos específicos OCAP de controle remoto e eventos ^ gerenciadores de multitelas.
A interface 1700 do pacote org.ocap.ui.event inclui pelo menos uma interface MultiScreenConfiguration Listener 1702, ou uma interface MultiScreenContextListener 1704.
A interface MultiScreenConfigurationListener 1702 é usada para fornecer notificações a respeito de alterações induzidas por sistema e aplicativo para um estado global da instância MultiScreenManager ou o estado de determinada 15 HScreen de exibição com relação à determinada configuração de multitelas por plataforma ou por exibição, φ respectivamente, ou de alterações numa instância
MultiScreenConfiguration específica.
A interface MultiScreenContextListener 1704 é usada para fornecer notificações a respeito de alterações induzidas por sistema e aplicativo num MultiScreenContext.
A classe 1710 do pacote org.ocap.ui.event inclui pelo menos uma dentre a classe MultiScreen ConfigurationEvent 1712, a classe MultiScreenContextEvent 25 1714, a classe MultiScreenEvent 1716, e a classe MultiScreenResourceEvent 1718. A classe MultiScreenConfigurationEvent 1712 é usada, para informar alterações no estado global da instância MultiScreenManager, ou no estado de determinada HScreen de exibição com relação ã determinada configuração 5 de multitelas por exibição ou por plataforma, respectivamente, ou alterações numa instância
k MultiScreenConfiguration especifica.
A classe MultiScreenContextEvent 1714 é usada para informar uma alteração num MultiScreenContext para ouvintes 10 interessados.
A classe MultiScreenEvent 1716 é uma classe básica abstrata, usada para organizar códigos identificadores de eventos usados por diferentes tipos de eventos relacionados a funcionalidade para gerenciamento de telas múltiplas.
A classe MultiScreenResourceEvent 1718 é usada para
informar alterações a respeito do estado de recurso dos φ recursos relacionados a telas múltiplas.
A FIG. 18A ilustra a definição da classe MultiScreenConfigurationEvent 1712 do pacote
20 org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 tipo Java da classe MultiScreenConfiguration Event 1712 do pacote org.ocap.ui.event é definido como um subnível de org.ocap.ui.event.MultiScreenEvent, que é um 25 subnivel de java.util.EventObject, que é um subnível de j ava.Iang.Obj ect. A classe MultiScreenConfigurationEvent 1712 do pacote org.ocap.ui.event inclui java.io.Serializable como Todas as Interfaces Implementadas, é declarada como public class MultiScreenConfigurationEvent, e estende o MultiScreenEvent.
A classe MultiScreenConfigurationEvent 1712 é usada para informar alterações num estado global da instância MultiScreenManager ou o estado de determinada HScreen de exibição com relação à determinada configuração de multitelas por exibição ou por plataforma, respectivamente, ou alterações em uma instância MultiScreenConfiguration específica.
Os seguintes tipos de alterações devem provocar a geração da classe MultiScreenConfigurationEvent 1712:
• A configuração de multitelas por plataforma atualmente ativa, conforme determinado pelas alterações de MultiScreenManager, a partir de uma configuração de multitelas para outra configuração de multitelas;
• A configuração de multitelas por exibição atualmente ativa, conforme determinado por determinadas alterações da HScreen de exibição, a partir de uma configuração de multitelas para outra configuração de multitelas;
O conjunto de telas associadas às alterações da MultiScreenConfiguration (i. e., uma tela é adicionada ou removida da configuração de multitelas);
A classe MultiScreenConfigurationEvent 1712 do pacote org.ocap.ui.event foi aplicada a partir da versão MSM 101.
A FIG. 18B ilustra um campo 1800 da classe
MultiScreenConfigurationEvent 1712 do pacote
I org.ocap.ui.event, de acordo com uma modalidade da presente
invenção.
0 campo 1800 da classe MultiScreenConfiguration 10 Event 1712 do pacote org.ocap.ui.event inclui pelo menos um dentre um campo static int MULTI_SCREEN_C0NFIGURATI0N_ CHANGED 1802, um campo static int
MULTI_SCREEN_C0NFIGURATION_CHANGING 1804, um campo static int MULTI_SCREEN_CONFIGURATI0N_LAST 1806, um campo static int MULTI_SCREEN_CONFIGURATION_SCREEN_ ADDED 1808, e um campo static int MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED Φ 1810.
Campos 1820 herdados da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event incluem pelo menos um 20 dentre MULTI_SCREEN_CONFIGURATION_FIRST e MULTI_SCREEN_ CONTEXT_FIRST.
Campos 1825 herdados de class java.util.EventObject incluem uma fonte.
O campo MULTI_SCREEN_CONFIGURATI0N_CHANGING 1804 é 25 declarado como public static final int
MULTI_SCREEN_CONFIGURATION_CHANGING. Uma alteração na determinada MultiScreenConfiguration por plataforma ou por exibição atualmente ativa, conforme determinada pelo MultiScreenManager, ou determinada HScreen de exibição tiver sido iniciada, em cujo caso o valor retornado por 5 getSource() deve ser MultiScreenManager ou HScreen de exibição afetado, e o valor retornado por getRelatedO deve
I ser o MultiScreenConfiguration subsequentemente ativo.
O campo MULTI_SCREEN_CONFIGURATION_CHANGING 1804 não deve ser despachado a um aplicativo, ao qual não tiver 10 sido concedida MonitorAppPermission("multiscreen.
configuration").
0 campo MULTI_SCREEN_CONFIGURATION_CHANGING 1804 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONFIGURATI0N_CHANGED 1802 é 15 declarado como public static final int
MULTLSCREEN_CONFIGURATION_CHANGED. A MultiScreen
Configuration por plataforma ou determinada MultiScreen Configuration por exibição atualmente ativa, conforme determinada pelo MultiScreenManager ou determinada HScreen 20 de exibição, foi alterada, em cujo caso o valor retornado por getSource() deve ser o MultiScreenManager ou HScreen de exibição afetado, e o valor retornado por getRelated() deve ser a MultiScreenConfiguration previamente ativa.
0 campo MULTI_SCREEN_CONFIGURATION_CHANGED 1802 foi 25 aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED 1808 é declarado como public static final int MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED. O conjunto de telas associadas a uma MultiScreenConfiguration foi alterado, com uma nova tela tendo sido adicionada, em cujo 5 caso o valor retornado por getSource() deve ser a MultiScreenConfiguration afetada, e o valor retornado por getRelated() deve ser a HScreen recentemente adicionada.
Exceto durante o intervalo entre a última distribuição do campo MULTI_SCREEN_CONFIGURATION_CHANGING 10 1804 e a geração do campo MULTI_SCREEN_CONFIGÜRATION_ CHANGED 1802, uma tela não deve ser adicionada, e o campo MULTLSCREEN_CONFIGURATION_SCREEN_ADDED 1808 não deve ser gerado para uma configuração de multitelas, que é a configuração atual de multitelas por plataforma, ou 15 determinada configuração atual de multitelas por exibição.
0 campo MULTI_SCREEN_C0NFIGURATI0N_SCREEN_ADDED 1808 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_C0NFIGURATI0N_SCREEN _REM0VED 1810 é declarado como public static final int 20 MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED. 0 conjunto de telas associadas a um MultiScreenConfiguration foi alterado, com uma tela existente tendo sido removida, em cujo caso o valor retornado por getSource() deve ser a MultiScreenConfiguration afetada, e o valor retornado por 25 getRelated() deve ser a HScreen recentemente removida.
Exceto durante ' o intervalo entre a última distribuição do campo MULTI_SCREEN_CONFIGURATION_CHANGING 1804 e a geração do campo MÜLTI_SCREEN_CONFIGURATION_ CHANGED 18 02, uma tela não deve ser removida de, e o campo MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED 1810 não deve ser 5 gerado para, uma configuração de multitelas, que é a atual configuração de multitelas por plataforma, ou determinada configuração atual de multitelas por exibição.
O campo MULTI_SCREEN_CONFIGURATION_SCREEN_ REMOVED 1810 foi aplicado a partir da versão MSM 101.
O campo MULTI_SCREEN_CONFIGURATION_LAST 1806 é
declarado como public static final int
MULTI_SCREEN_CONFIGURATION_LAST, e é um último
identificador de eventos atribuído aos identificadores de eventos MultiScreenConfigurationEvent.
O campo MULTI_SCREEN_CONFIGURATION_LAST 1806 foi
aplicado a partir da versão MSM 101.
A FIG. 18C ilustra um construtor 1830 da classe MultiScreenConfigurationEvent 1712 do pacote org.ocap.ui. event, de acordo com uma modalidade da presente invenção.
O construtor 1830 inclui MultiScreenConfiguration
Event(java.Iang.Objectsource, int id, java.Iang.Object related) 1832.
0 construtor 1830 é declarado como public MultiScreenConfigurationEvent(java.Iang.Object source, int id, java.lang.Object related), e constrói a classe MultiScreenConfigurationEvent 1712. Um parâmetro source é uma referência a uma instância MultiScreenManager, uma instância HScreen de exibição, ou uma instância MultiScreenConfiguration, de acordo com o evento específico, como acima especificado.
Um parâmetro id é o identificador de eventos desse evento, cujo valor deve ser um dos seguintes: MULTI_SCREEN_CONFIGURATION_CHANGING, MULTLSCREEN_
CONFIGURATION_CHANGED, MULTI_SCREEN_CONFIGURATION_SCREEN_ ADDED, ou MULTI_SCREEN_CONFIGURATION_SCREEN_REMOVED.
Um parâmetro related é uma referência a uma instância MultiScreenConfiguration, ou a uma instância HScreen, de acordo com o evento específico, como acima especificado.
O construtor 1830 da classe MultiScreen ConfigurationEvent 1712 foi aplicado a partir da versão MSM 101.
A FIG. 18D ilustra um método 1840 da classe MultiScreenConfigurationEvent 1712 do pacote
org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 método 1840 da classe
MultiScreenConfigurationEvent 1712 do pacote
org.ocap.ui.event inclui um método java.Iang.Object getRelatedQ 1842, métodos 1850 herdados da classe org.ocap.ui.event.MultiScreenEvent incluem getld, métodos 1852 herdados da classe java.util.EventObject incluem pelo menos um dos métodos getSource, toString, 1854 herdados da classe java.Iang.Object incluem pelo menos um dentre clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, e wait.
0 método getRelated() 1842 é declarado como public
java.Iang.Object getRelated( ), e obtém o objeto j relacionado desse evento. Isto é, o método getRelated()
1842 retorna a instância relacionada ao objeto desse evento, cujo valor deve ser um dos seguintes, conforme determinado pelo tipo de evento específico: uma referência a uma instância MultiScreenConfiguration ou uma referência a uma instância HScreen.
0 método getRelated() 1842 foi aplicado a partir da versão MSM 101.
A FIG. 19A ilustra a definição da interface
MultiScreenConfigurationListener 1702 do pacote
IpL org . ocap . ui . event, de acordo com uma modalidade da presente
invenção.
A interface MultiScreenConfigurationListener 1702 do pacote org.ocap.ui.event inclui java.util.EventListener como Superinterfaces, é declarada como public interface MultiScreenConfigurationListener, e estende java.util.Event Listener.
A interface MultiScreenConfigurationListener 1702 é usada para fornecer notificações a respeito das alterações induzidas por sistema e aplicativo no estado global da instância MultiScreenManager, ou no estado de determinada HScreen de exibição, com relação à determinada configuração de multitelas por exibição ou por plataforma, respectivamente, ou das alterações numa instância MultiScreenConfiguration especifica.
A interface MultiScreenConfigurationListener 1702 I foi aplicada a partir da versão MSM 101.
A FIG. 19B ilustra um método 1900 da interface MultiScreenConfigurationListener 1702 do pacote
org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 método 1900 da interface MultiScreen ConfigurationListener 1702 do pacote org.ocap.ui.event inclui um método void notify(MultiScreenConfiguration Event evt) 1910.
0 método void notify 1910 é declarado como void 4H notify(MultiScreenConfiguration Event evt). Quando um
MultiScreenConfigurationEvent é gerado, a implementação deve evocar o método void notify 1910 em todos os ouvintes registrados, a fim de comunicar informações de evento para cada ouvinte, conforme demandado por semântica de evento especifica.
No caso do evento ser MultiScreenConfiguration Event.MULTI_SCREEN_C0NFIGURATI0N_CHANGING, o método void notify 1910 não deve ser evocado, a menos que ao aplicativo, que registrou esse ouvinte, for concedida MonitorAppPermission("multiscreen.configuration"). Além
disso, uma implementação do método void notify 1910 deve limitar severamente a quantidade de processamento que pode ocorrer, visto que um limite de tempo absoluto é aplicado na evocação do método void notify 1910 para o conjunto de todos os ouvintes aplicáveis. ^ Um parâmetro evt é uma instância MultiScreen
ConfigurationEvent.
0 método void notify 1910 foi aplicado a partir da versão MSM 101.
A FlG. 20A ilustra a definição da classe MultiScreenContextEvent 1714 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
A classe MultiScreenContextEvent 1714 do pacote ■15 org.ocap.ui.event é definida como um subnivel de org.ocap.ui.event.MultiScreenEvent, que é um subnivel de ^ java.util.EventObject, que é um subnivel de
java.Iang.Object.
Todas as interfaces implementadas da classe MultiScreenContextEvent 1714 do pacote org.ocap.ui.event incluem java.io.Seriarizable, é declarado como public class MultiScreenContextEvent, e estende MultiScreenEvent.
A classe MultiScreenContextEvent 1714 é usada para informar uma alteração em um MultiScreenContext a ouvintes interessados.
Os seguintes tipos de alterações provocam a geração da classe MultiScreenContextEvent 1714:
• Alteração do ServiceContext associado;
• Alteração da HScreen de exibição associada;
• Alteração da atribuição da área (de extensão) da HScreen de exibição associada;
• Alteração do conjunto de VideoOutputPorts associadas;
• Alteração do foco de áudio de uma HScreen de
exibição;
· Alteração de visibilidade da tela;
• Alteração da ordem ζ da tela.
• Alteração do conjunto de HScreenDevices subjacentes, que contribuem com fontes de áudio para uma HScreen;
· Alteração do conjunto de instâncias
HScreenDevice subjacentes, p. ex. , devido à adição ou remoção de um HScreenDevice de uma HScreen;
• Alteração da ordem ζ das instâncias HScreenDevice subjacentes de uma HScreen;
A classe MultiScreenContextEvent 1714 do pacote
org.ocap.ui.event foi aplicada a partir da versão MSM 101.
A FIG. 20B ilustra um campo 2000 da classe MultiScreenContextEvent 1714 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 campo 2000 da classe MultiScreenContextEvent 1714
do pacote org.ocap.ui.event inclui pelo menos um dentre um campo static int MULTI_SCREEN_CONTEXT_AUDIO_ FOCUS_CHANGED 2002, um campo static int MULTI_SCREEN_
CONTEXT_AUDIO_SOURCES_CHANGED 2004, um campo static int MULTI_SCREEN_CONTEXT_DEVICES_CHANGED 2006, um campo static int MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED 2008, um campo static int MULT I_SCREEN_CONTEXT_DI S PLAY_AREA__CHANGED ^ 2010, um campo static int MULTI_SCREEN_CONTEXT_DIS PLAY_
SCREEN_CHANGED 2 012, um campo static int MULTI_SCREEN_ CONTEXT_OUTPUT_PORT_CHANGED 2014, um campo static int MULTI J3CREEN_CONTEXT_SERVICE_CONTEXT_CHANGED 2016, um campo static int MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED 2018, um campo static int MULTI SCREEN_CONTEXT_Z_ORDER_CHANGED 2020, e um campo static int MULTI_SCREEN_CONTEXTS_LAST 2022.
Campos 2030 herdados da classe
org.ocap.ui.event.MultiScreenEvent incluem pelo menos um dentre MULTI_SCREEN_CONFIGURATION_FIRST e MULTI_SCREEN_ * CONTEXT_FIRST. Campos 2035 herdados da classe
java.util.EventObject incluem uma fonte.
O campo MULTI_SCREEN_CONTEXT_DEVICES_CHANGED 200 6 é declarado como public static final int
MULTI_SCREEN_CONTEXT_DEVICES_CHANGED, e corresponde a um caso, quando o conjunto de instâncias HScreenDevice associadas à HScreen subjacente do MultiScreenContext da fonte for alterado. O campo MULTI_SCREEN_CONTEXT_DEVICES_CHANGED 2006
foi aplicado a partir da versão MSM 101. O campo MULTI_SCREEN_CONTEXT_DEVICES_ Z_ORDER_ CHANGED 2008 é declarado como public static final int MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED, e corresponde a um caso, quando a ordem ζ do conjunto de instâncias HScreenDevice associadas à HScreen subjacente do MultiScreenContext da fonte for alterado.
0 campo MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_ CHANGED 2008 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEEN_CONTEXT_SERVICE_CONTEXT_ CHANGED 2016 é declarado como public static final int MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED, e corresponde a um caso, quando o ServiceContext associado à HScreen subjacente do MultiScreenContext da fonte for alterado.
0 campo MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_ CHANGED 2016 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_
CHANGED 2012 é declarado como public static final int MULTI_SCREEN_CONTEXT_DIS PLAY_SCREEN_CHANGE D, e corresponde a um caso, quando a HScreen de exibição associada à HScreen subjacente do source code>MultiScreenContext for alterada.
O campo MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_ CHANGED 2012 foi aplicado a partir da versão MSM 101.
A MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED 2010 é declarada como public static final int
MULTI_SCREEN_CONTEXT_DIS PLAY_AREA_CHANGE D, e corresponde a um caso, quando a área (de extensão) da HScreen de exibição, para as quais a HScreen subjacente da MultiScreenContext da fonte é atribuída, for alterada.
A MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED 2010 foi aplicada a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONTEXT_OUTPUT_PORT_ CHANGED
2014 é declarado como public static final int I MULTI_SCREEN_CONTEXT_OUT PUT_PORT_CHANGE D, e corresponde ao
caso, quando o conjunto de portas de saída de vídeo associadas à HScreen subjacente do MultiScreenContext da fonte for alterado.
O campo MULTI_SCREEN_CONTEXT_OUTPUT_PORT_ CHANGED 2014 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED 2018 é declarado como public static final int MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED, e corresponde a um caso, quando a visibilidade da HScreen subjacente da fonte ^ MultiScreenContext for alterada.
0 campo MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED 2018 foi aplicado a partir da versão MSM 101. 0 campo MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED 2020 é
declarado como public static final int
MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED, e corresponde a um caso, quando a ordem ζ da HScreen subjacente do MultiScreenContext da fonte for alterada. O campo MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED 2020
foi aplicado a partir da versão MSM 101. O campo MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_ CHANGED 2004 é declarado como public static final int MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED, e corresponde a um caso, quando as fontes de áudio da HScreen subjacente da MultiScreenContext da fonte forem alteradas.
0 campo MULTI_SCREEN_C0NTEXT_AUDI0_S0URCES_ CHANGED ^ 2004 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED 2002 é declarado como public static final int MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED, e corresponde a um caso, quando a tela focalizadora de áudio da HScreen subjacente do MultiScreenContext da fonte for alterado. Quando a tela focalizadora de áudio de uma HScreen de exibição se alterar, então esse evento deve ser gerado duas vezes (após completar a alteração): em primeiro lugar para o MultiScreenContext da tela lógica, que possuir o foco de ^ áudio perdido (se tal tela lógica existir), e em segundo
lugar para o MultiScreenContext da tela de exibição. Em ambos os casos, o MultiScreenContext da fonte deve ser a tela de exibição.
0 campo MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED 2002 foi aplicado a partir da versão MSM 101.
O campo MULTI_SCREEN_CONTEXTS_LAST 2022 é declarado como public static final int MULTI_SCREEN_CONTEXTS_LAST, e é um último identificador de eventos atribuído a identificadores de eventos MultiScreenConfigurationEvent. O campo MULTI_SCREEN_CONTEXTS_LAST 2022 foi aplicado a partir da versão MSM 101.
A FIG. 20C ilustra um construtor 2040 da classe MultiScreenContextEvent 1714 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
O construtor 2040 inclui MultiScreenContextEvent (java.Iang.Object source. int id)(2042).
0 construtor 2040 é declarado como public MultiScreenContextEvent(java.lang.Object source, int id), e constrói a classe MultiScreenContextEvent 1714.
Um parâmetro source é uma referência a uma interface MultiScreenContext.
Um parâmetro id é o identificador de eventos desse evento, cujo valor deve ser um dos seguintes: o campo MULTI_SCREEN_CONTEXT_DEVICES_CHANGED 2006, o campo MULTI_SCREEN_CONTEXT_DEVICES_Z_ORDER_CHANGED 2008, o campo MULTI_SCREEN_CONTEXT_SERVICE_CONTEXT_CHANGED 2016, o campo MULTI_SCREEN_CONTEXT_DISPLAY_SCREEN_CHANGED 2012, o campo MULTI_SCREEN_CONTEXT_DISPLAY_AREA_CHANGED 2010, o campo MULTI_SCREEN_CONTEXT_OUTPUT_PORT_CHANGED 2014, o campo MULTI_SCREEN_CONTEXT_VISIBILITY_CHANGED 2018, o campo MULTI_SCREEN_CONTEXT_Z_ORDER_CHANGED 2020, o campo MULTI_SCREEN_CONTEXT_AUDIO_SOURCES_CHANGED 2004, e o campo MULTI_SCREEN_CONTEXT_AUDIO_FOCUS_CHANGED campo 2002. O construtor 2040 da classe MultiScreen
ContextEvent 1714 foi aplicado a partir da versão MSM 101. A FIG. 20D ilustra um método 2050 da classe MultiScreenContextEvent 1714 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
Métodos 2052 herdados da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event incluem getld, e métodos 2054 herdados da classe java.util.EventObject incluem pelo menos um dentre getSource e toString. Métodos 2056 herdados da classe java.Iang.Object incluem pelo menos um dentre clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, e wait.
A FIG. 2IA ilustra a definição da interface MultiScreenConfigurationListener 1702 do pacote
org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
A interface MultiScreenConfigurationListener 1702 do pacote org.ocap.ui.event inclui java.util.EventListener como Superinterfaces, é declarada como public interface MultiScreenContextListener, e estende java.util.
EventListener.
A interface MultiScreenConfigurationListener 1702 é usada para fornecer notificações a respeito de alterações induzidas por sistema e aplicativo a um MultiScreenContext.
A interface MultiScreenConfigurationListener 1702 foi aplicada a partir da versão MSM 101.
A FIG. 21B ilustra um método 2100 da interface MultiScreenConfigurationListener 1702 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 método 2100 da interface MultiScreen ConfigurationListener 1702 inclui um método void notify(MultiScreenContextEvent evt) 2102.
0 método void notify(MultiScreenContextEvent) 2102 t é declarado como void notify (MultiScreenContextEvent evt).
Quando uma implementação OCAP fizer qualquer alteração num MultiScreenContext, que provoque a geração de um MultiScreenContextEvent, então a implementação deve evocar o método void notify(MultiScreenContextEvent) 2102 em todos os ouvintes registrados, a fim de comunicar as informações da alteração ao ouvinte.
Se ao aplicativo, que registrou esse ouvinte, não tiver sido concedida MonitorAppPermission
("multiscreen.context") e o MultiScreenContext da fonte associada ao MultiScreenContextEvent especificado não for associado a nenhum ServiceContext, ou um Ser.viceContext que não seja acessável a esse aplicativo, então o método void notify(MultiScreenContext Event) 2102 não deve ser evocado nesse ouvinte; de outro modo, ele deve ser evocado nesse ouvinte.
Um ServiceContext é acessável a um aplicativo, se ele for retornado a partir de um método ServiceContext Factory.getServiceContexts() .
Um parâmetro evt é uma instância MultiScreenContextEvent.
0 método void notify(MultiScreenContextEvent) 2102 foi aplicado a partir da versão MSM 101.
A FIG. 22A ilustra a definição da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
A classe MultiScreenEvent 1716 do pacote org.ocap.ui.event é definida, como um subnivel de j ava. util. EventOb j-ect, que é um subnivel de java.Iang.Object.
A classe MultiScreenEvent 1716 do pacote org.ocap.ui.event inclui java.io.Serializable como Todas as Interfaces Implementadas, e inclui pelo menos um dentre MultiScreenConfigurationEvent e MultiScreenContextEvent, como Subclasses Diretas Conhecidas.
A classe MultiScreenEvent 1716 do pacote org.ocap.ui.event é declarada como public abstract class MultiScreenEvent, e estende java.util.EventObject.
Um MultiScreenEvent é uma classe básica abstrata usada para organizar códigos identificadores de eventos usados por diferentes tipos de eventos relacionados à funcionalidade para gerenciamento de telas múltiplas.
A classe MultiScreenEvent 1716 do pacote org.ocap.ui.event foi aplicada a partir da versão MSM 101. A FIG. 22B ilustra um campo 2200 da classe
MultiScreenEvent 1716 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 campo 2200 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event consiste de pelo menos um dentre o campo static int MULTI_SCREEN_CONFIGURATION_FIRST 2202 e o campo static int MULTI_SCREEN_CONTEXT_FIRST 2204. Campos 2210 herdados da classe java.util.EventObject incluem uma fonte.
0 campo MULTI_SCREEN_CONFIGURATION_FIRST 2202 é declarado como public static final int
MULTI_SCREEN_CONFIGURATION_FIRST, e é o primeiro identificador de eventos atribuído aos identificadores de eventos MultiScreenConfigurationEvent.
O campo MULTI_SCREEN_CONFIGURATION_FIRST 2202 foi aplicado a partir da versão MSM 101.
0 campo MULTI_SCREEN_CONTEXT_FIRST 2204 é declarado como public static final int MULTI_SCREEN_CONTEXT_FIRST, e é o primeiro identificador de eventos atribuído aos identificadores de eventos MultiScreenContextEvent.
0 campo MULTI_SCREEN_CONTEXT_FIRST 2204 foi aplicado a partir da versão MSM 101.
A FIG. 22C ilustra um construtor 2220 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
O construtor 2220 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event inclui pelo menos um MultiScreenEvent(java.lang.Object source, int id) protegido (2222) .
O construtor 2220 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event é declarado como MultiScreenEvent(java.lang.Object source int id) protegido, e é um construtor protegido para um MultiScreenEvent.
Um parâmetro source é uma referência a uma fonte de evento, conforme definida por uma subclasse concreta da classe MultiScreenEvent 1716.
Um parâmetro id é o identificador de eventos da classe MultiScreenEvent 1716.
0 construtor 2220 da classe MultiScreenEvent 1716 foi aplicado a partir da versão MSM 101.
A FIG. 22D ilustra um método 2230 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
O método 2230 da classe MultiScreenEvent 1716 do pacote org.ocap.ui.event inclui um método int getld() 2232. Métodos 2240 herdados da classe java.util.EventObject incluem pelo menos um dentre getSource e toString. Métodos 2245 herdados da classe java.Iang.Object incluem pelo menos um dentre clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, e wait.
0 método int getld() 2232 é declarado como public int getld(), e obtém o identificador de eventos associado à classe MultiScreenEvent.
0 identificador de eventos de MultiScreenEvent, para cuja visualização as sub-classes de MultiScreen Event: MultiScreenConfiguration Evento e MultiScreenContextEvent são retornadas.
O método int getld() 2232 foi aplicado a partir da versão MSM 101.
A FIG. 23A ilustra a definição da classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
A classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event é definida, como um subnivel de org.davic.resources.ResourceStatusEvent, que é um subnivel de java.util.EventObject, que é um subnivel de j ava.Iang.Obj ect.
A classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event indui java.io.Serializable como Todas as Interfaces Implementadas. A classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event é declarada, como public class MultiScreen ResourceEvent, e estende
org.davic.resources.ResourceStatusEvent.
A classe MultiScreenResourceEvent 1718 é usada para informar alterações a respeito do estado de recurso dos recursos relacionados a telas múltiplas.
A classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event foi aplicada a partir da versão MSM 101.
A FIG. 23B ilustra um campo 2300 da classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
A classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event inclui pelo menos um dentre um campo static int MULTI_SCREEN_RESOURCE_SCREEN_RELEASED 2302 e um campo static int MULTI_SCREEN_RESOURCE_SCREEN_RESERVED 2304. Campos 2310 herdados da classe java.util.EventObject ^ incluem uma fonte.
0 campo MULTI_SCREEN_RESOURCE_SCREEN_RELEASED 2302 é declarado como public static final int MULTI_SCREEN_RESOURCE_SCREEN_RELEASED. A reserva numa tela foi há pouco liberada, indicando que a tela (ou seus dispositivos constituintes de tela) pode agora ser reservada (i. e., elas estão agora sem reserva).
O campo MULTI_SCREEN_RESOURCE_SCREEN_RELEASED 2302 foi aplicado a partir da versão MSM 101.
O campo MULTI_SCREEN_RESOURCE_SCREEN_RESERVED 2304 é declarado como public static final int MULTI_SCREEN_RESOURCE_SCREEN_RESERVED. A reserva numa tela foi há pouco concedida a um aplicativo, indicando que a tela (incluindo seus dispositivos constituintes de tela) não estão mais sem reserva.
O campo MULTI_SCREEN_RESOURCE_SCREEN_RESERVED 2304 foi aplicado a partir da versão MSM 101.
A FIG. 23C ilustra um construtor 2320 da classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção. O construtor 2320 da classe MultiScreenResource Event 1718 inclui MultiScreenResourceEvent(java.Iang.Object source, int id) 2322.
0 construtor 2320 da classe MultiScreenResource Event 1718 é declarado como public
MultiScreenResourceEvent(java.lang.Object source, int id) , e é um construtor para um MultiScreenResourceEvent.
Um parâmetro source é uma referência a uma instância HScreen, cujo estado de recurso foi alterado.
Um parâmetro id é o identificador de eventos da classe MultiScreenResourceEvent 1718.
0 construtor 2320 da classe MultiScreenResource Event 1718 foi aplicado a partir da versão MSM 101.
A FIG. 23D ilustra um método 2330 da classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event, de acordo com uma modalidade da presente invenção.
0 método 2330 da classe MultiScreenResourceEvent 1718 do pacote org.ocap.ui.event inclui· pelo menos um dentre o método int getld() 2332 e o método java.lang.Object getSourceO 2334. Métodos 2340 herdados da classe java.util.EventObject incluem toString, e métodos 2345 herdados da classe java.lang.Object incluem pelo menos um dentre clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, e wait.
0 método getSourceO 2334 é declarado como public java.lang.Object getSourceO, e obtém o objeto de origem, que gerou esse evento.
0 método getSourceO 2334 substitui o getSource na classe org.davic.resources.ResourceStatusEvent. O método getSourceO 2334 retorna uma referência a uma instância HScreen, ou sua subclasse.
O método getSourceO 2334 foi aplicado a partir da. |> versão MSM 101.
0 método getId() 2332 é declarado como public int getld(), e obtém o recurso identificador de eventos associado à classe MultiScreenResourceEvent 1718.
0 identificador de eventos da classe MultiScreenResourceEvent 1718 é retornado, onde o identificador é um dos seguintes: {o campo MULTI_SCREEN_RESOURCE_SCREEN_RELEASED 2302, o campo MULTI_SCREEN_RESOURCE_SCREEN_RESERVED 2304}.
O método getId() 2332 foi aplicado a partir da ^ versão MSM 101.
Em seguida, restrições para uso de aplicativo para configuração de multitelas, de acordo com uma modalidade da presente invenção, serão descritas com referência às FIGS. 24A a 24D, 25A a 25E, 26A a 26D, 27, 28A e 28B, e 29.
De acordo com a presente modalidade, precondições (FIGS. 24A a 24C) e pós-condições (FIGS. 25A a 25E) para o processamento da alteração da configuração de multitelas, isto é, reconfiguração de multitelas deve ser satisfeita. Nesse caso, as precondições e as pós-condições devem ser satisfeitas com as seguintes suposições:
1. plataforma implementa MSM, conforme definido;
2. mais de uma configuração de multitelas distinta existe e é acessável;
3. chamador possui MonitorAppPermission
("multiscreen.configuration"); φ 4. nenhum evento MultiScreenConf igurationEvent.
MULTI_SCREEN_CONFIGURATION_CHANGING ou MultiScreen
ConfigurationEvent.MULTI_SCREEN_CONFIGURATION_CHANGED é gerado durante a execução de um método verifyConstraints() diferente de um resultado direto da evocação de setMultiScreenConfiguration() pelo método
verifyConstraints() ;
5. nenhum evento MultiScreenConfiguration Event.MULTI_SCREEN_CONFIGURATION_SCREEN_ADDED ou Multi
ScreenConfigurationEvent.MULTI_SCREEN_CONFIGURATION_SCREEN_ Itr REMOVED é gerado durante a execução do método
verifyConstraints() ;
6. aplicativo sinaliza allow_default_device _reconfig como 1 em descritor de uso de telas múltiplas;
7. a plataforma preserva os parâmetros básicos de configuração do dispositivo de tela padrão, de modo particular a área de tela, resolução de pixels, e taxa de proporção de pixels durante a alteração da configuração; i.
e., ela não tira vantagem do fato de que um aplicativo sinalizou allow_default_device_reconfig como 1, a fim de reconfigurar parâmetros do dispositivo de tela padrão (observe que esse processo de verificação pode ser expandido para cobrir um caso, onde a plataforma não preserve esses parâmetros, i. e., um
HScreenConfigurationEvent ou MultiScreenContextEvent apropriado pode ser ouvido e usado para observar que a plataforma não preserva esses parâmetros);
As FIGS. 24A a 24C ilustram precondições para alteração da configuração de multitelas, de acordo com uma modalidade da presente invenção.
Em S2410 da FIG. 24A, invariáveis são verificadas. De acordo com uma modalidade da presente invenção, invariáveis estáticas são verificadas como uma precondição. Nesse caso, um método verify InvariantConstraintsO para verificar invariáveis será mais tarde descrito com referência às FIGS. 26A a 26D. ^lT Na S2420 da FIG. 24A é gravada uma tela padrão.
Na S2430 da FIG. 24A são gravados parâmetros básicos de configuração e de um dispositivo de tela de plano de fundo padrão.
Na S2440 da FIG. 24B são gravados parâmetros básicos de configuração e de um dispositivo de tela de video padrão.
Na S2450 da FIG. 24B são gravados parâmetros básicos de configuração e de um dispositivo de tela gráfica padrão. Na S2460 da FIG. 24C são gravadas telas não-padrão.
Na S2470 da FIG. 24C são gravados dispositivos de tela fora de padrão.
Na S2480 da FIG. 24C é encontrada uma configuração distinta de uma configuração atual.
A FIG. 24D ilustra um processo para alterar configuração de multitelas, de acordo com uma modalidade da presente invenção.
Na S2490 é alterada uma configuração de multitelas. Isto é, a configuração de multitelas é alterada via MSM.setMultiScreenConfiguration (MSC2, nulo), e a geração dos eventos MULTI_SCREEN_CONFIGURATION_CHANGING e MULTI_SCREEN_CONFIGURATION_CHANGED são aguardados através de um método WaitForMultiScreenConfigurationChangingEvent() e um método WaitForMultiScreenConfigurationChangedEvent().
As FIGS. 25A a 25E ilustram pós-condições para alterar configuração de multitelas, de acordo com uma modalidade da presente invenção.
Na S2500 da FIG. 25A, invariáveis são verificadas. De acordo com uma modalidade da presente invenção, invariáveis estáticas são verificadas como uma pós- condição. Nesse caso, um método verifylnvariant ConstraintsO para verificar invariáveis será mais tarde descrito com referência às FIGS. 26A a 26D.
Na S2505 da FIG. 25A, a configuração atual de multitelas é a nova configuração. Na S2510 da FIG. 25A, a nova tela padrão deve ser a mesma instância que a antiga tela padrão.
Na S2515 de FIG. 25A, se ele existir, o novo dispositivo de plano de fundo da tela padrão deve ser a mesma instância que o antigo dispositivo de plano de fundo da tela padrão, se ele existir, a menos que o aplicativo I sinalize allow_default_device_reconfig como 1, em cujo caso
não é permitido que nenhum dispositivo de plano de fundo padrão seja disponível após a reconfiguração, em cujo caso o dispositivo de plano de fundo padrão anterior deve ser restaurado para um estado de dispositivo de tela vazia de plano de fundo.
No S2520 da FIG. 25B, se ele existir, o novo dispositivo de plano de fundo de tela padrão deve possuir a mesma área de tela, resolução de pixels, e taxa de proporção de pixels, que ele tinha com o dispositivo ^tr anterior de plano de fundo de tela padrão.
No S2525 da FIG. 25C, se ele existir, o novo dispositivo de tela de vídeo padrão deve ser a mesma instância, que o dispositivo antigo de tela de vídeo padrão, se ele existir, a menos que o aplicativo sinalize allow_def ault_device_reconf ig como 1, em cujo caso não é permitido que nenhum dispositivo de vídeo padrão esteja disponível após a reconf iguração, em cujo caso o dispositivo de vídeo padrão anterior deve ser restaurado para o estado do dispositivo de tela de vídeo vazia. No S2530 da FIG. 25C, se ele existir, o novo dispositivo de tela de video padrão deve possuir a mesma área de tela, resolução de pixels, e taxa de proporção de pixels, que ele tinha com o dispositivo de tela de video padrão anterior.
No S2535 da FIG. 25D, se ele existir, o novo p; dispositivo de tela gráfica padrão deve ser a mesma
instância, que o dispositivo antigo de tela gráfica padrão, se ele existir, a menos que o aplicativo sinalize
allow_def ault_device_reconf ig como 1, em cujo caso não é permitido que nenhum dispositivo gráfico padrão esteja disponível após a reconf iguração, em cujo caso o dispositivo gráfico padrão anterior deve ser restaurado para o estado do dispositivo de tela gráfica vazia.
No S2540 da FIG. 25D, se ele existir, o novo
dispositivo de tela gráfica padrão deve possuir a mesma área de tela, resolução de pixels, e taxa de proporção de pixels, que ele tinha com o dispositivo de tela gráfica padrão anterior.
No S2545 da FIG. 25E, para cada tela não-padrão
obtida antes da reconfiguração, não sendo mais uma tela não-padrão, então ele deve ser equivalente a uma tela vazia; de outro modo, ele não deve ser equivalente a uma tela vazia.
No S2500 da FIG. 25A, para cada dispositivo de tela
não-padrão obtido antes da reconfiguração, não sendo mais um dispositivo de tela não-padrão, então ele deve ser equivalente a um dispositivo de tela vazia; de outro modo, ele não deve ser equivalente a um dispositivo de tela vazia.
As FIGS. 26A a 26D ilustram restrições para
verificar invariáveis, de acordo com uma modalidade da presente invenção.
No S2605 da FIG. 26A, deve haver um gerenciador de multitelas.
No S2610 da FIG. 26A, deve haver uma configuração
atual de multitelas.
No S2615 da FIG. 26A, deve haver um conjunto não- vazio de configuração acessável de multitelas.
No S2620 da FIG. 26A, a configuração atual de
multitelas deve ser uma configuração acessável.
No S2625 da FIG. 26B, deve haver um conjunto de ^ft telas não-vazias na configuração atual de multitelas.
No S2630 da FIG. 26B, as telas na configuração atual de multitelas não devem ser vazias.
No S2635 da FIG. 26B, quaisquer duas entradas
distintas de tela na configuração atual de multitelas não devem representar os mesmos recursos.
No S2640 da FIG. 26C, deve haver uma tela padrão
atual.
No S2645 da FIG. 26C, a tela padrão atual não deve
ser equivalente à tela vazia. No S2650 da FIG. 26C, exatamente uma entrada de tela na configuração atual de multitelas deve representar os mesmos recursos que a tela padrão.
No S2655 da FIG. 26C, deve haver um conjunto não- vazio de telas acessáveis.
No S2660 da FIG. 26C, a tela padrão atual deve ser I um membro distinto do conjunto de telas acessáveis.
No S2665 da FIG. 26D, qualquer dispositivo de plano de fundo de tela do atual padrão de tela não deve ser equivalente ao dispositivo de tela vazia de plano de fundo.
No S2670 da FIG. 26D, qualquer dispositivo de tela de video da tela padrão atual não deve ser equivalente ao dispositivo de tela de video vazia.
No S2675 da FIG. 26D, qualquer dispositivo de tela gráfica da tela padrão atual não deve ser equivalente ao dispositivo de tela gráfica vazia. W1 A FIG. 27 ilustra a definição de um método
getNonDefaultScreens() , de acordo com uma modalidade da presente invenção. O método getNonDefaultScreens() obtém telas não-
padrão (SXlND) por retorno das telas não-padrão (SXlND) no Gerenciador de Multitelas(MSM).
As FIGS. 28A e 28B ilustram a definição de um método getNonDefaultScreenDevices(), de acordo com uma modalidade da presente invenção.
No S2810 da FIG. 28A, os números dos dispositivos de tela fora de padrão dos dispositivos de plano de fundo de tela, dispositivos de tela de video, e dispositivos de tela gráfica são checados em separado.
No S2820 da FIG. 28B, os dispositivos de tela fora de padrão dos dispositivos de tela de plano de fundo, dos dispositivos de tela de video, e dos dispositivos de tela gráfica são obtidos e retornados em separado.
A FIG. 29 ilustra uma pluralidade de métodos, de acordo com uma modalidade da presente invenção. No S2910, um estado de espera é mantido, até que um
evento MultiScreenConfigurationEvent.MULTI_SCREEN_
CONFIGURATION_CHANGING seja gerado.
No S2920, um estado de espera é mantido, até que um evento MultiScreenConfigurationEvent.MULTI_SCREEN_
CONFIGURATION _CHANGED seja gerado.
No S2930, uma falha de declaração é verificada e φ anunciada.
Em seguida, assuntos a serem alterados e adicionados, de acordo com normas OCAP, a fim de implementar a modalidade da presente invenção em um ambiente OCAP, serão descritos com referência às FIGS. 30A, 30B, 31, 32A, 32B, 33A, 33B, e 34A a 34C.
Um aplicativo 'OCAP não presta suporte, ou presta suporte muito restrito, a gerenciamento de múltiplas telas de exibição ou múltiplas telas lógicas, conforme definido pela classe HAVi HScreen, e, de modo particular, para um gerenciamento de telas, de funcionalidade Picture-In- Picture (PIP) e Picture-Outside-Picture (POP). De maneira correspondente, a fim de implementar um OCAP MSM, de acordo com a presente invenção, o aplicativo OCAP deve verificar a presença da propriedade do sistema Java
"ocap.api.option.msm". Se a propriedade do sistema Java ^ "ocap.api.option.msm" for verificada, o aplicativo OCAP
pode descobrir, configurar, usar e, de outro modo, manipular as seguintes capacidades de dispositivo: funções PIP, funções P0P, Exibições Múltiplas, e Mapeamento das Telas Principal, PIP, POP para Portas de Saída.
Em seguida, AppID para identificar aplicativos, que devem ser alterados para implementar um OCAP MSM, será descrito com referência às FIGS. 30A e 30B. A FIG. 30A ilustra pseudocódigos de AppID, de
acordo com normas OCAP. A FIG 30B ilustra pseudocódigos de 9 OcapAppID para implementar um OCAP MSM, de acordo com uma
modalidade da presente invenção.
Se uma implementação de plataforma OCAP prestar suporte à apresentação simultânea de múltiplos contextos de serviço (javax.tv.selection.ServiceContext), então é impossível distinguir entre duas instâncias de um aplicativo, que usam o mesmo identificador de organização e de aplicativo, conforme representado pela classe definida por MHP org.dvb.application.AppID, onde essas instâncias separadas estão rodando em diferentes contextos de serviço. Em decorrência disso, a funcionalidade da base de dados do aplicativo e das respectivas classes, que usam AppID, não é bem definida, i. e., é ambígua nesse caso de uso.
De acordo com uma modalidade da presente invenção,
identificadores de aplicativo são definidos como uma classe OcapAppID recentemente introduzida, ao invés da classe AppID, por alteração do S3010 da FIG. 30A em S3050 da FIG. 3 OB'.
Da mesma forma, os identificadores de aplicativo
são definidos como classe OcapAppID em S3055, S3060, S3065, e S3070 da FIG. 30B, ao invés da classe AppID em S3015, S3020, S3025, e S3030 da FIG. 30A.
A definição da classe OcapAppID será agora descrita com referência à FIG. 31.
A FIG. 31 ilustra pseüdocódigos de OcapAppID, de acordo com uma modalidade da presente invenção.
Em S3110, um OcapAppID permite a discriminação entre instâncias múltiplas do mesmo aplicativo, onde essas instâncias múltiplas são associadas a diferentes instâncias ServiceContext.
Aqui, o mesmo aplicativo significa que o aplicativo usa os mesmos identificadores de organização e de aplicativo. Implementações OCAP, que prestem suporte a instâncias múltiplas ServiceContext, apresentadas ao mesmo tempo, podem permitir instâncias múltiplas simultâneas do mesmo aplicativo.
Exceto para o caso, onde uma instância de org.dvb.application.AppId for construída por evocação explicita do construtor AppID(int,int) por um aplicativo OCAP, cada instância de AppID com aplicativo visível deve ser também uma instância de OcapAppID.
Se uma implementação OCAP ou um aplicativo OCAP se deparar com uma instância de AppID, evocar esse id, que não é uma instância de OcapAppID, então essa instância deve ser semanticamente tratada, como sendo equivalente a um OcapAppID construído como a seguir:
Em S3120, um construtor público a ser usado, quando a padronização do campo ServiceContext desse OcapAppID for definida. Em particular, a evocação dessa construção deve ser equivalente à evocação de um método OcapAppID (oid, aid, null).
Um parâmetro oid é um identificador de organização, que é compatível com o mesmo parâmetro citado do construtor de superclasse AppID(int oid, int aid).
Um parâmetro aid é um identificador de organização, que é compatível com o mesmo parâmetro citado do construtor de superclasse AppID(int oid, int aid).
Em S3130, é definido um construtor público a ser usado para especificar o campo ServiceContext desse OcapAppID.
Um parâmetro oid é um identificador de organização, que é compatível com o mesmo parâmetro citado do construtor de superclasse AppID(int oid, int aid).
Um parâmetro aid é um identificador de organização, que é compatível com o mesmo parâmetro citado do construtor de superclasse AppID(int oid, int aid).
Um parâmetro context é uma instância ServiceContext ou nulo. Se nulo, então a instância ServiceContext do padrão atual do aplicativo atual deve ser substituída pelo nulo, por ocasião da inicialização da instância ServiceContext.
Em S3140, o ServiceContext associado a essa instância OcapAppID é obtido. Uma instância ServiceContext não-nula é retornada, devido a um método getServiceContext().
Em seguida, um Gerenciador Hscene, de acordo com normas OCAP, que é alterado a fim de prestar suporte à extensão OCAP MSM, será descrito com referência às FIGS. 32A, 32B, 33A, 33B, e 34A a 34C.
Uma funcionalidade Gerenciadora de Cenas, definida por org. ocap.ui.HSceneManager e tipos relacionados, não prestam um suporte adequado aos seguintes casos de uso:
• uso de instâncias múltiplas HScene por um único aplicativo, onde diferentes instâncias são associadas a instâncias HGraphicsDevice distintas;
• capacidade de aplicativo de monitoração, ou de outro aplicativo privilegiado, para transferir o foco de uma HScene a outro independente do aplicativo proprietário;
• capacidade de aplicativo de monitoração, ou de outro aplicativo privilegiado, para alteração do foco HScene iniciada por plataforma ou aplicativo de monitoração
e/ou concessão/negação;
• capacidade de aplicativo de monitoração, ou de φ outro aplicativo privilegiado, para determinar se
instâncias HSceneBinding distintas se referem à mesma ou diferentes cenas subjacentes independentes do aplicativo proprietário;
• capacidade de aplicativo de monitoração, ou de outro aplicativo privilegiado, para manter um modelo de estado exato de todas as cenas visiveis, de seus índices z, e de seus locais de tela;
· capacidade de aplicativo de monitoração, ou de
outro aplicativo privilegiado, para especificar um índice ζ W alternativo, ordenando as cenas a serem usadas em resposta
a uma solicitação de reordenamento;
• alteração do tipo de valor de retorno HSceneManager.getHSceneOrder() ;
Além disso, a seguinte funcionalidade foi verificada ser mais bem expressa por refatoração através de mesclagem:
• mesclar HSceneChangeRequestHandler.testShow(..) into testOrder(..) por especificação de oldOrder como -1;
Essa Alteração de Engenharia aborda essas questões, como a seguir:
• adicionar HSceneBinding.getGraphicsDevice();
adicionar HSceneChangeRequestHandler.
testMoveFocus(HSceneBinding,HSceneBinding);
• adicionar HSceneChangeRequest Handler.focus Changed(HSceneBinding,HSceneBinding) ;
remover HSceneChangeRequestHandler.test
Show(..);
• alterar assinatura de HSceneChangeRequest Manipulador.testOrder(..) , retornar tipo de valor, e exceções declaradas;
• alterar assinatura de HSceneChangeRequest Manipulador.testMove(.. ) e exceções declaradas;
• adicionar HSceneManager.getAppDefaultHScene
(AppID);
• adicionar HSceneManager.getAppHScenes(AppID);
• adicionar HSceneManager.getAppHSceneLocation
(HScene);
• adicionar HSceneManager.getHSceneFocus();
• adicionar HSceneManager.getHSceneOrder (HGraphicsDevice);
adicionar HSceneManager.transferHScene
Focus(HSceneBinding) ;
• adicionar HSceneManager.sameScene (HScene Binding,HSceneBinding) ;
• alterar HSceneManager.getHSceneOrder(), retornar tipo de valor.
Além disso, as descrições textuais de HSceneManager, HSceneBinding, e HSceneChangeRequestHandler e de seus membros previamente existentes foram editorialmente melhoradas para fins de clareza e melhor compreensão.
I Em javax.tv.graphics.TVContainer, se
getRootContainer(XletContext ctx) for evocado por (ou a favor de) um aplicativo OCAP, ctx for o XletContext inicial do aplicativo de chamada, e uma instância for retornada, então essa instância deve ser idêntica da que será retornada ao mesmo tempo por org.havi.ui. HSceneFactory.getDefaultHScene.
OCAP estende DVB-GEM 1.0.2 através da adição da funcionalidade Gerenciadora de Cenas OCAP especifica abaixo especificada. Em particular, uma implementação OCAP deve 'Φ implementar org.ocap.ui.HSceneBinding, org.ocap.ui.
HSceneChangeRequestHandler, org.ocap.ui.HSceneManager e suas semânticas associadas, conforme mais tarde especificado com referência a 32B, 33B, 34B, e 34C.
Além disso, in org.havi.ui.HsceneFactory, não é demandado que um aplicativo OCAP use um método dispose(HScene) em uma HScene Sl previamente adquirida. Antes de adquirir outra HScene S2, desde que as primeira e última instâncias HScene Sl e S2 sejam associadas a diferentes instâncias HGraphicsDevice. Em Regras de Manipulação de Focos, a implementação deve manter uma lista global ordenada das instâncias HScene focalizáveis. Uma HScene focalizável é uma HScene visível e ativa, onde uma HScene é considerada como visível, se um método HScene.isVisible() retornar verdadeiro, e é considerada ativa, se (1) um método
HScene.setActive(boolean) nunca tiver sido evocado pelo aplicativo, ou (2) se um método HScene.setActive(boolean foco) for evocado pelo menos uma vez com foco igual a verdadeiro, após ter sido por último evocado com foco igual a falso.
A HScene focalizada é uma HScene focalizável, que é o foco de entrada atribuído. Existe somente uma HScene focalizada a qualquer dado momento, a despeito de quantas instâncias HGraphicsDevice ou instâncias HScreen estiverem ativas.
Quando uma HScene se torna focalizável, ela é adicionada ao final da lista de HScenes focalizáveis.
Quando uma HScene focalizável for o foco atribuído, ela é movida para o início da lista de HScenes focalizáveis.
Quando uma HScene não for mais focalizável, ela é removida da lista de HScenes focalizáveis.
Quando a HScene focalizada não for mais focalizável, a implementação deve extrair o foco da HScene focalizada e atribuir o foco de entrada a uma primeira HScene focalizável na lista de HScenes focalizáveis.
Quando a primeira HScene focalizável for inserida na lista de HScenes focalizáveis, a implementação não deve atribuir o foco de entrada automaticamente a ela.
A FIG. 32A ilustra pseudocódigos de HSceneBinding, de acordo com normas OCAP. A FIG. 32B ilustra pseudocódigos de HSceneBinding para implementar um OCAP MSM, de acordo com uma modalidade da presente invenção.
Em S3250 da FIG. 32B, uma interface HGraphicsDevice, que não existe nas normas OCAP da FIG. 32A, é além disso declarada.
Em S3260 da FIG. 32B, esse HSceneBinding é implementado por uma classe de plataforma definida, a fim de fornecer um meio para indicar certas propriedades de uma HScene, onde essa HScene pertence de modo especifico a outro aplicativo e, assim, um acesso direto a uma referência de HScene não é permitida.
m S3270 da FIG. 32B, o retângulo de tela da HScene indicado por esse HSceneBinding é obtido (retornado) no espaço de coordenadas normalizadas da HScreen, para as quais um método getGraphicsDevice() é mapeado.
Em S3280 da FIG. 32B, são obtidos (retornados) os atributos de aplicativo, com que a HScene indicada por esse HSceneBinding é associada.
Em S3290 da FIG. 32B, é obtido (retornado) o dispositivo gráfico, com que a HScene indicada por esse ■ HSceneBinding é associada.
A FIG. 33A ilustra pseudocódigos de HSceneChangeRequestHandler, de acordo com normas OCAP. A FIG. 33B ilustra pseudocódigos de HSceneChangeRequest Handler para implementar um OCAP MSM, de acordo com uma modalidade da presente invenção.
0 S3310 da FIG. 33A foi removido.
No S3330 da FIG. 33B, HSceneChangeRequestHandler é implementado por um aplicativo privilegiado, a fim de processar solicitações (1) para adicionar uma HScene não atualmente exibida, (2) remover uma HScene atualmente exibida, (3) alterar as posições das HScenes numa tela, (4) mover uma HScene na ordem ζ das HScenes de um HGraphicsDevice, (5) mover o foco AWT entre hierarquias de confinamento de HScenes, e (6) gerar notificações de alterações da atribuição do foco AWT a uma hierarquia de ^ confinamento de HScene.
No S3340 da FIG. 33B, é testado se uma solicitação para mover (ou alterar o tamanho) da HScene deve ser, ou não, permitida. Um método testMove (HSceneBinding move, HSceneBinding currentScenes[]) é evocado, quando uma HScene tiver que ser movida dentro da HScreen, ou ser redimensionada, i. e., se o HScreenRectangle da HScene representada terá sua posição ou tamanho alterado. Um parâmetro move é o HSceneBinding, que indica o
retângulo de tela da HScene afetada, e que deve ser uma entrada das currentScenes. Um parâmetro currentScenes são os HSceneBindings que correspondem às HScenes visíveis existentes (e a seus retângulos de tela atuais), incluindo a HScene afetada. Nesse contexto, uma HScene é considerada como visível, se o método HScene.isVisible() retornar verdadeiro.
0 método testMove retorna verdadeiro, se o movimento puder ser feito, de outro modo ele retorna falso.
No S3350 da FIG. 33B, é testado se uma solicitação de alteração da ordem ζ das HScenes pode ser, ou não, feito. testOrder ( HSceneBinding reorder, HSceneBinding currentScenes[], int currentOrder, int newOrder) é evocado, quando uma HScene tiver que ser movida na ordem z, ou adicionada ou removida da ordem z. No caso de uma HScene estar sendo removida da ordem ζ, o valor resultante do método testOrder pode ser ignorado pela implementação (p. ex., uma HScene do aplicativo está sendo removida, devido ao fato do aplicativo ser fechado).
As seguintes restrições devem ser aplicadas, para evocação do método testOrder:
• um (ou ambos) os currentOrder ou(e) newOrder não forem negativos;
• se currentOrder não for negativo, então ele é um índice válido da matriz mencionada por currentScenes;
· se currentOrder for um índice válido de
currentScenes, e se newOrder não for negativo, então ele é um índice válido da matriz mencionada por currentScenes.
Um parâmetro reorder é o HSceneBinding, que indica a HScene afetada. Se essa HScene já estiver presente na ordem ζ das HScenes, então ela deve aparecer como uma entrada de currentScenes; de outro modo, ela não deve estar presente nas currentScenes. 0 parâmetro reorder não é | considerado no método testOrder do S3320 da FIG. 33A, e a
ordem ζ pode ser verificada pelo parâmetro reorder, considerando que a HScene é influenciada pelo método testOrder da FIG. 33B.
Um parâmetro currentScenes são os HSceneBindings, que correspondem às HScenes visíveis existentes na ordem z, com a primeira entrada (0) sendo a HScene mais dianteira. Nesse contexto, uma HScene é considerada como visível, se o método HScene.isVisible() retornar verdadeiro.
Um parâmetro currentOrder é o valor -1, se a HScene
I
tiver que ser mostrada, devido à evocação de um método HScene.show() ou de um método HScene.setVisible(true), ou, se a HScene já tiver sido exibida, um número inteiro não- negativo indicando a posição existente na matriz currentScene da HScene a ser movida.
Um parâmetro newOrder é um número inteiro não- negativo, indicando a nova posição, para as quais a HScene afetada deve ser movida, ou -1, se a HScene afetada estiver sendo removida (inteiramente) da ordem ζ das HScenes. Se a HScene afetada estiver sendo adicionada à ordem ζ das HScenes, então newOrder indica a posição, na qual ela deve aparecer, com todas as outras HScenes atuais sendo movidas uma posição para baixo. Se currentOrder for -1, e o valor de newOrder for superior ao indice do último indice válido de currentScenes, então a HScene a ser adicionada está sendo solicitada, a ser colocada na posição mais traseira na ordem ζ das HScenes.
0 método testOrder retorna nulo, se a solicitação de reordenar (adicionar/remover) for permitida, como especificado pelos parâmetros. O valor do parâmetro currentScenes é retornado, se a solicitação não precisar ser realizada, como especificado.
Uma nova matriz de instâncias HSceneBinding, que é uma permutação do conjunto composto dos elementos em (a) currentScenes menos reordenar, se currentOrder não for negativo e newOrder for negativo, (b) currentScenes mais ^ reordenar, se currentOrder for negativo e newOrder não for
negativo, ou (c) currentScenes, se currentOrder e newOrder não forem negativos, é retornado. No S3360 da FIG. 33B, é testado, se a reatribuição
(ou remoção) do foco AWT para (de) uma HScene deve ser, ou não, permitida. Se um HSceneChangeRequest Handler for registrado, então uma implementação OCAP de plataforma deve evocar um método testFocusChange, sempre que o foco AWT for inicialmente atribuído a uma hierarquia de recipientes HScene, movido entre hierarquias de recipientes HScene, ou removidas de todas as hierarquias de recipientes HScene. Se o método testFocusChange retornar falso para determinada alteração de estado do foco, então a implementação de plataforma OCAP não deve completar essa alteração, e deve deixar inalterado o foco AWT.
Uma implementação de plataforma OCAP não deve evocar o método testFocusChange, ao mover o foco entre sub- recipientes ou componentes dentro de uma instância HScene.
Uma implementação de plataforma OCAP pode, mas não precisa, evocar (ou usar o valor de retorno de) o método testFocusChange, no caso de uma reatribuição de foco AWT HScene originada por plataforma; porém, nesse caso, a plataforma deve evocar, em todos os casos, um método focusChanged(..) para fornecer notificação da alteração do foco HScene originado por plataforma.
Ao evocar o método testFocusChange, um (ou ambos) entre newScene ou(e) oldScene não devem ser nulos como uma restrição.
Um parâmetro newScene é o HSceneBinding, que indica a HScene, à qual o foco deve ser atribuído, ou, nulo, em cujo caso o foco não deve ser atribuído a qualquer HScene, i. e., deve ser deixado sem atribuição.
Um parâmetro oldScene é o HSceneBinding, que indica a HScene, a partir do qual o foco deve ser removido, ou nulo, em cujo caso o foco não foi atribuído a qualquer HScene (imediatamente antes da evocação do método testFocusChange).
0 método testFocusChange retorna verdadeiro, se transferência (ou remoção) do foco puder ser feita, de outro modo retorna falso.
No S3370 da FIG. 33B, um manipulador de alterações
é notificado na atribuição atual do foco AWT. O método ^ focusChanged fornece notificação de alterações para a atual
atribuição de foco AWT para determinada HScene. A fim de designar tal HScene, um HSceneBinding é usado, que identifica exclusivamente uma cena, através da combinação de um aplicativo identificado, a partir de um método HSceneBinding.getAppAttributes(), e um dispositivo de tela gráfica, a partir de um método HSceneBinding. getGraphicsDevice() . Uma implementação de plataforma OCAP não deve
evocar um método focusChanged para mover o foco entre sub- 0? recipientes ou componentes dentro de uma instância HScene.
A única identificação acima citada é baseada na restrição de um determinado aplicativo não possuir mais do que uma HScene por HGraphicsDevice.
Um parâmetro newScene é (1) um HSceneBinding indicando indiretamente a nova HScene, para as quais o foco foi atribuído, ou (2) nulo, indicando que nenhuma HScene é o foco agora atribuído (nesse ambiente de aplicativo). Um parâmetro oldScene é (1) um HSceneBinding
indicando indiretamente a HScene antiga (anterior), a partir da qual o foco foi removido, ou (2) nulo, indicando que nenhuma HScene foi o foco previamente atribuído (nesse ambiente de aplicativo).
A FlG. 34A ilustra pseudocódigos de HSceneManager, de acordo com normas OCAP. As FIGS. 34B e 34C ilustram pseudocódigos de HSceneManager para implementar um OCAP -φ MSM, de acordo com uma modalidade da presente invenção.
No S3420 da FIG. 34B, HsceneManager representa um componente gerenciador de plataformas, que permite a um aplicativo privilegiado registrar um manipulador, para processar alterações de HScene solicitadas dentro de um HgraphicsDevice combinado com todas as HScenes (desse HGraphicsDevice). Além disso, a ordenação ζ das Hscenes, cena padrão, e atribuição do foco atual podem ser consultadas usando HsceneManager.
No S3430 da FIG. 34B é gerado um construtor padrão Ifc protegido.
No S3435 da FIG. 34B é obtida a instância singleton de HsceneManager, onde essa instância parece se comportar (a partir de uma perspectiva de estado acessável), como se ela fosse delimitada para a plataforma (e não para o aplicativo de chamada). 0 HsceneManager é retornado.
No S3440 da FIG. 34B, um método setHSceneChangeRequestHandler(HSceneChangeRequestHandler handler) permite que um aplicativo se estabeleça ele próprio como o manipulador para solicitação de alteração da HScene. Se um manipulador já estiver registrado, quando o método setHSceneChangeRequestHandler for evocado, o manipulador para solicitação de alteração de HScene é substituído pelo manipulador especificado.
Um parâmetro handler é (1) um
HSceneChangeRequestHandler a ser consultado a respeito de I alterações na ordenação ζ das HScenes, bem como alterações
a respeito da atribuição do foco padrão, ou (2) nulo, em cujo caso o manipulador atual é removido. SecurityException é gerado, se o chamador não
possuir MonitorAppPermission("handler.resource").
No S3445 da FIG. 34B, é obtido o conjunto de associações de cena, que corresponde às HScenes visíveis do HGraphicsDevice padrão do aplicativo de chamada. Quando comparado a public static OcapAppAttributes [] getHSceneOrder() no S3410 da FIG. 34A, as associações de Φ cena são retornadas por serem declaradas como um tipo
HSceneBinding[], ao invés de um tipo static OcapAppAttributes []. Se o aplicativo de chamada for atribuído a uma tela
gráfica padrão, então um método getHScene Order() deve retornar o mesmo valor que um método get HSceneOrder(HScreen.getDefaultHScreen().getDefaultHGraphics DeviceO); de outro modo, ele deve retornar uma matriz 2 5 vazia.
Uma matriz de instâncias HSceneBinding correspondentes às instâncias HScene visíveis do HGraphicsDevice padrão do aplicativo de chamada é retornada na ordem z, onde visible means scene.isVisible() retorna verdadeiro.
SecurityException é gerada, se o chamador não
possuir MonitorAppPermission("handler.resource"). φ O conjunto de associações de cena, que corresponde
às HScenes visíveis do HGraphicsDevice especificado, é obtido.
A matriz de associações de cenas de retorno é
ordenada, de forma que a primeira entrada (O) corresponda à HScene mais dianteira visível na ordem ζ das HScenes para o HGraphicsDevice especificado, e a última entrada corresponda à HScene mais traseira visível.
Se o dispositivo gráfico especificado for associado
a uma tela, que não seja associada a uma tela de exibição, 'Qt ou uma porta de saída for ou não habilitada para exibição
em uma porta de saída, então uma matriz vazia deve ser retornada.
Um parâmetro device é um HGraphicsDevice.
Uma matriz de instâncias HSceneBinding correspondente às instâncias HScene visíveis do HGraphicsDevice especificado é retornada na ordem z, onde visible means scene.is Visible() retorna verdadeiro.
SecurityException é gerada, se o chamador não
possuir MonitorAppPermission("handler.resource"). No S3455 da FIG. 34C, é obtido o local da HScene na ordem ζ para a HScene padrão do aplicativo de chamada. Aplicativos podem evocar um método getAppHSceneLocation(), para determinar onde, na ordem ζ de uma instância HGraphicsDevice, sua HScene padrão está localizada.
0 método etAppHSceneLocation() retorna o valor -1, φ se o aplicativo nunca tiver obtido uma referência para sua
HScene padrão (significando que o aplicativo não possui nenhuma interface de usuário); de outro modo, retorna o mesmo valor que getAppHSceneLocation(HSceneFactory .getDefaultHScene()).
No S3460 da FIG. 34C, o local da HScene na ordem ζ é obtido para a HScene especificada. Aplicativos podem evocar um método getAppHSceneLocation(HScene scene), para determinar onde, na ordem ζ de um HGraphicsDevice, uma HScene especifica está localizada.
& Um parâmetro scene é uma instância HScene, para
qual obter o local na ordem ζ dentro da instância HGraphicsDevice, com que a HScene é associada. 0 método getAppHSceneLocation(HScene scene) retorna
um número inteiro indicando o local das HScenes na ordem ζ para a HScene especificada. 0 valor é ordenado de modo crescente na ordem z, onde 0 é mais dianteiro e todos outros valores estão, na ordem crescente, abaixo da HScene mais dianteira. Um valor de -1 é retornado, se a HScene não tiver sido ordenada, ou se ela não for visivel, onde visível é definido como scene.isVisible () retornando verdadeiro.
No S3465 da FIG. 34C, um método getAppDefaultHScene(AppID id) obtém um HSceneBinding, que permite determinar a HScene padrão de um aplicativo identificado, se esse aplicativo possuir uma HScene padrão, g, A evocação do método getAppDefauitHScene (AppID id)
não deve provocar a criação ou associação de uma HScene padrão com um aplicativo. Um parâmetro id é uma instância AppID indicando um
aplicativo OCAP.
0 método getAppDefaultHScene(AppID id) retorna (1) um HSceneBinding (indiretamente) indicando a HScene padrão atribuída para um aplicativo identificado, ou (2) nulo indicando que o aplicativo não mais existe na base de dados do aplicativo, foi encerrado, ou não é (atualmente) φ atribuído a uma HScene padrão.
SecurityException é gerada, se o chamador não possuir MonitorAppPermission("handler.resource"). No S3470 da FlG. 34C, uma matriz de instâncias
HSceneBinding, que denotam as instâncias HScene atuais de um aplicativo identificado, é obtida por um método getAppHScenes(AppID id).
A evocação do método getAppHScenes(AppID id) não deve provocar a criação ou associação de uma HScene com um aplicativo. Um parâmetro id é uma instância AppID indicando um aplicativo OCAP.
Quer (1) uma matriz não-vazia de instâncias HSceneBinding que denotam (indiretamente) as instâncias HScene atribuídas para um aplicativo identificado, quer (2) nulo, indicando que o aplicativo não mais existe na base de dados do aplicativo, foi encerrado, ou não é (atualmente) atribuído a qualquer HScene, deve ser retornado pelo método getAppHScenes(AppID id). SecurityException é gerada, se o chamador não
possuir MonitorAppPermission("handler. resource").
No S3475 da FIG. 34C, um HSceneBinding, que permite determinar a HScene (desse ambiente de aplicativo), para as quais o foco AWT é atribuído, é obtido por um método getHSceneFocus().
Se ao aplicativo de chamada não tiver sido Φ concedida MonitorAppPermission("handler.resource"), então o
método getHSceneFocus() deve retornar nulo, se o foco AWT for atribuído a uma HScene, que não pertença ao aplicativo de chamada.
Quer (1) um HSceneBinding indicando (indiretamente) a HScene, para a qual o foco AWT é atribuído, quer (2) nulo, indicando que o foco AWT não é atribuído a qualquer HScene (nesse ambiente de aplicativo), ou o aplicativo de chamada não possuir
MonitorAppPermission(Hhandler.resource") nas circunstâncias acima descritas, deve ser retornado pelo método getHSceneFocus() .
No S3480 da FIG. 34C, a transferência (ou remoção) do foco AWT é solicitada a (por) uma HScene especifica (desse ambiente de aplicativo), através de um método transferHSceneFocus(HScene Binding binding).
Se essa solicitação de transferência (ou remoção) for atendida, então esse atendimento pode ser assincrono com relação à evocação do método transferHSceneFocus; além disso, o atendimento pode não ocorrer, se o estado da plataforma ou determinada outra condição impedir de outro modo a alteração do foco AWT.
Uma solicitação para atribuir o foco AWT a um aplicativo, que não esteja num estado de execução, ou a uma HScene, que não seja focalizável, não deve ser atendida.
Após a transferência (ou remoção) bem sucedida do foco para (de) determinada HScene pelo método transferHSceneFocus ou pela plataforma (de modo independente do método transferHScene Focus), um método focusChanged() não deve ser evocado numa instância HScene ChangeRequestHandler registrada.
Um parâmetro binding é (1) um HSceneBinding que identifica com exclusividade uma HScene, para as quais a atribuição do foco AWT é solicitada, ou (2) nulo, indicando que a atribuição do foco AWT é solicitada, para ser removida de todas as instâncias HScene (desse ambiente de aplicativo).
SecurityException é gerada, se o chamador não possuir MonitorAppPermission("handler.resource").
No S3485 da FIG. 34C, um método (HSceneBinding sbl, HSceneBinding sb2) determina, se duas instâncias HSceneBinding se referem a uma mesma cena subjacente. H Os parâmetros sbl e sb2 são instâncias
HSceneBinding.
O método (HSceneBinding sbl, HSceneBinding sb2) retorna verdadeiro, se sbl e sb2 denotarem as mesmas cenas subjacentes; de outro modo, retorna falso.
As modalidades da presente invenção podem ser gravadas como programas de computador, e podem ser implementadas em computadores digital para uso geral, que executam os programas, usando uma midia de gravação legível por computador. Exemplos de mídia de gravação legível por Φ computador incluem mídias de armazenamento magnético (p.
ex., ROM, disquetes, discos rígidos, etc.) mídias de gravação ótica (p. ex. , CD-ROMs, ou DVDs), e mídias de armazenamento, como ondas portadoras (p. ex., transmissão através da Internet).
Embora a presente invenção tenha sido particularmente apresentada e descrita com referência a suas modalidades exemplificantes, deverá ficar claro por parte das pessoas versadas na técnica, que várias alterações no formato e nos detalhes podem ser feitas na mesma, sem se afastarem do espírito e escopo da invenção, conforme definidos pelas reivindicações apensas. As modalidades exemplificantes devem ser consideradas somente num sentido descritivo, e não para fins de limitação.
5 Assim, o escopo da invenção é definido, não pela descrição detalhada da invenção, mas pelas reivindicações apensas, e Φ todas as diferenças dentro do escopo deverão ser
interpretadas, como estando incluídas na presente invenção.
ê

Claims (1)

1. MÉTODO PARA CONFIGURAR E GERENCIAR UMA MULTITELA, caracterizado pelo fato de compreender: recepção de um ou mais serviços de difusão; atribuição de um ou mais serviços de difusão a uma tela; atribuição da tela a uma ou mais telas de exibição; atribuição de uma ou mais telas de exibição a uma ou mais portas de saída.
BRPI0720474A 2006-12-18 2007-12-18 Método para configurar e gerenciar uma multitela BRPI0720474A8 (pt)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US87047106P 2006-12-18 2006-12-18
US60/870.471 2006-12-18
US91889407P 2007-03-20 2007-03-20
US60/918.894 2007-03-20
US94803807P 2007-07-05 2007-07-05
US60/948.038 2007-07-05
US97284607P 2007-09-17 2007-09-17
US60/972,846 2007-09-17
US97590607P 2007-09-28 2007-09-28
US60/975.906 2007-09-28
PCT/KR2007/006637 WO2008075880A1 (en) 2006-12-18 2007-12-18 Method and apparatus for multiscreen management for multiple screen configuration

Publications (2)

Publication Number Publication Date
BRPI0720474A2 true BRPI0720474A2 (pt) 2014-01-14
BRPI0720474A8 BRPI0720474A8 (pt) 2017-09-12

Family

ID=39536460

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0720474A BRPI0720474A8 (pt) 2006-12-18 2007-12-18 Método para configurar e gerenciar uma multitela

Country Status (8)

Country Link
US (1) US8054319B2 (pt)
EP (1) EP2095633A4 (pt)
KR (1) KR101476140B1 (pt)
CN (1) CN101632300B (pt)
BR (1) BRPI0720474A8 (pt)
CA (1) CA2672450A1 (pt)
MX (1) MX2009006596A (pt)
WO (1) WO2008075880A1 (pt)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9182937B2 (en) 2010-10-01 2015-11-10 Z124 Desktop reveal by moving a logical display stack with gestures
KR101204795B1 (ko) * 2007-10-23 2012-11-26 삼성전자주식회사 이종의 그래픽 시스템 기반 어플리케이션들의 화면 공유방법 및 그 장치
KR101463567B1 (ko) * 2008-07-02 2014-11-20 엘지이노텍 주식회사 디지털 텔레비전의 단일 튜너를 이용한 피아이피기능구현장치
US20100064251A1 (en) * 2008-09-05 2010-03-11 International Business Machines Corporation Toggling window display state by screen in a multi-screened desktop environment
EP2270658A1 (en) * 2009-06-22 2011-01-05 Clayster Asia Ltd. Method and computer system for introducing client devices into a client-server network
KR101700811B1 (ko) 2010-09-02 2017-02-01 주식회사 케이티 이동형 사용자 단말 위치에 기반한 콘텐츠 연속 이용 제공 방법 및 서버
US9372618B2 (en) 2010-10-01 2016-06-21 Z124 Gesture based application management
US9733665B2 (en) * 2010-10-01 2017-08-15 Z124 Windows position control for phone applications
US20120218202A1 (en) 2010-10-01 2012-08-30 Sanjiv Sirpal Windows position control for phone applications
US20120225694A1 (en) 2010-10-01 2012-09-06 Sanjiv Sirpal Windows position control for phone applications
JP6010036B2 (ja) 2010-10-01 2016-10-19 ゼット１２４Ｚ１２４ タッチセンサ式ディスプレイに画像を表示する方法及び通信デバイスならびにコンピュータ可読媒体
US9430122B2 (en) 2010-10-01 2016-08-30 Z124 Secondary single screen mode activation through off-screen gesture area activation
US20120225693A1 (en) 2010-10-01 2012-09-06 Sanjiv Sirpal Windows position control for phone applications
US9436217B2 (en) 2010-10-01 2016-09-06 Z124 Windows position control for phone applications
US9189018B2 (en) 2010-10-01 2015-11-17 Z124 Windows position control for phone applications
US9588545B2 (en) 2010-10-01 2017-03-07 Z124 Windows position control for phone applications
US20120220340A1 (en) * 2010-10-01 2012-08-30 Sanjiv Sirpal Windows position control for phone applications
US20120102403A1 (en) * 2010-10-22 2012-04-26 Robert Sanford Havoc Pennington Video integration
US11265510B2 (en) * 2010-10-22 2022-03-01 Litl Llc Video integration
US9582239B2 (en) * 2011-01-21 2017-02-28 Qualcomm Incorporated User input back channel for wireless displays
US10135900B2 (en) 2011-01-21 2018-11-20 Qualcomm Incorporated User input back channel for wireless displays
US9787725B2 (en) 2011-01-21 2017-10-10 Qualcomm Incorporated User input back channel for wireless displays
US9495012B2 (en) 2011-09-27 2016-11-15 Z124 Secondary single screen mode activation through user interface activation
CN103229511A (zh) 2011-10-26 2013-07-31 松下电器产业株式会社 广播接收装置、广播接收方法以及程序
US8799974B2 (en) * 2011-12-12 2014-08-05 Infosys Limited System and method for multi-standard browser for digital devices
US9395869B2 (en) 2012-02-02 2016-07-19 Apple Inc. Global z-order for windows
US9407961B2 (en) * 2012-09-14 2016-08-02 Intel Corporation Media stream selective decode based on window visibility state
KR102069547B1 (ko) 2013-04-19 2020-01-28 삼성전자주식회사 방송 통신 시스템에서 부가 정보를 송수신하는 방법 및 장치
KR20150004156A (ko) * 2013-07-02 2015-01-12 삼성전자주식회사 디스플레이 장치 및 그 방법
KR102099594B1 (ko) * 2013-10-23 2020-04-10 엘지전자 주식회사 Tv 및 그 동작 방법
US10275139B2 (en) * 2014-09-18 2019-04-30 Sony Interactive Entertainment LLC System and method for integrated user interface for electronic devices
KR101594105B1 (ko) 2015-03-06 2016-02-16 주식회사 와이젯 사용자 장치 간에 여러 화면을 분배하고 입력 인터페이스를 공유하는 멀티 스크린 구현 방법 및 장치
US10585869B2 (en) * 2015-05-22 2020-03-10 Open Text Holdings, Inc. System and method for generating, maintaining, and querying a database for computer investigations
KR101916728B1 (ko) * 2016-03-07 2018-11-08 엘지전자 주식회사 차량에 구비된 차량 제어 장치 및 그의 제어방법
WO2017155219A1 (en) 2016-03-07 2017-09-14 Lg Electronics Inc. Vehicle control device mounted in vehicle and control method thereof
CN106227594A (zh) * 2016-07-11 2016-12-14 中国人民解放军国防科学技术大学 一种基于分屏的多核cpu帧缓存显示优化方法
US10795630B2 (en) 2018-10-10 2020-10-06 International Business Machines Corporation Configuring computing device to utilize a multiple display arrangement by tracking eye movement
US11301456B2 (en) * 2020-05-07 2022-04-12 Sap Se Processing consistency validations of conditional foreign-key relations
CN114071199B (zh) * 2020-08-07 2024-03-12 惠州视维新技术有限公司 一种屏幕控制方法、终端设备以及存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5347624A (en) * 1987-03-05 1994-09-13 Hitachi, Ltd. Method and apparatus for display control
US5289574A (en) * 1990-09-17 1994-02-22 Hewlett-Packard Company Multiple virtual screens on an "X windows" terminal
JPH06268908A (ja) * 1993-03-10 1994-09-22 Toshiba Corp マルチ画面用枠信号発生回路
US6088005A (en) * 1996-01-11 2000-07-11 Hewlett-Packard Company Design and method for a large, virtual workspace
JP4541476B2 (ja) 1999-02-19 2010-09-08 キヤノン株式会社 マルチ画像表示システムおよびマルチ画像表示方法
JP2002335444A (ja) * 2001-05-08 2002-11-22 Canon Inc マルチ画面表示装置、マルチ画面表示方法、記録媒体、及びプログラム
EP1538929A4 (en) * 2002-03-20 2009-03-11 Eugene Science Inc POWDER MIXTURE OF VEGETABLE STEROL AND EMULSIFIANT, AND PROCESS FOR PREPARING THE SAME
JP2003309780A (ja) * 2002-04-18 2003-10-31 Matsushita Electric Ind Co Ltd 画像表示装置
JP2006049935A (ja) * 2003-04-17 2006-02-16 Fujitsu Ltd 映像制御機能を備える制御装置及びプログラム
CN1627765B (zh) 2003-12-10 2010-09-01 松下电器产业株式会社 便携式信息终端装置
KR100710301B1 (ko) * 2005-01-14 2007-04-23 엘지전자 주식회사 멀티-스크린 시스템 및 그 구현방법

Also Published As

Publication number Publication date
BRPI0720474A8 (pt) 2017-09-12
CA2672450A1 (en) 2008-06-26
CN101632300A (zh) 2010-01-20
CN101632300B (zh) 2012-07-04
US20090322714A1 (en) 2009-12-31
EP2095633A1 (en) 2009-09-02
WO2008075880A1 (en) 2008-06-26
US8054319B2 (en) 2011-11-08
KR20080057187A (ko) 2008-06-24
MX2009006596A (es) 2009-07-02
EP2095633A4 (en) 2014-04-16
KR101476140B1 (ko) 2014-12-24

Similar Documents

Publication Publication Date Title
BRPI0720474A2 (pt) Gerenciar uma multitela
US9489539B2 (en) Allowing first module of computer code received from vendor to make use of service provided by second module while ensuring security of system
US8201191B2 (en) Apparatus and methods for implementation of network software interfaces
US20070030390A1 (en) Apparatus for providing multiple screens and method of dynamically configuring screens
US8588580B2 (en) Playback device, recording medium, playback method and program
JP5123169B2 (ja) 対話型ユーザインターフェイスのためのアプリケーションおよび相補的機能の登録
EP1387593A2 (en) Information processing terminal and information processing method
WO2007113709A1 (en) Method and apparatus for assigning an application to a security restriction
WO2010109865A1 (ja) データ送信装置、データ受信装置、データ送信方法およびデータ受信方法
JP2004078936A (ja) 情報処理端末及び情報処理方法
KR20090100169A (ko) 다중-소스 스트리밍을 위한 오브젝트에 대한 정보 관리 및처리 방법 그리고 그 장치
WO2018133713A1 (zh) 一种线程管理方法及装置
US9681178B2 (en) Distributed presentation software for multiple instantiations in home network
TW200849990A (en) Method and apparatus for multiscreen management for multiple screen configuration
US8127313B2 (en) Method and system for providing services
CA2648597A1 (en) Apparatus and method for managing resource in multiple screens environment
Monnier MHP/OCAP iTV Applications in a Nutshell
WO2007114643A1 (en) Apparatus and method for managing resource in multiple screens environment
WO2007018388A1 (en) Apparatus for providing multiple screens and method of dynamically configuring multiple screens
CN117615197A (zh) 一种多窗口显示方法及显示设备
KR20070100110A (ko) 다중 스크린을 제공하는 장치 및 상기 다중 스크린의 동적구성 방법
JP2001027955A (ja) 複数の端末と、すべての端末に配布されるソフトウェアシステムとを有するネットワーク
Standard DTV APPLICATION SOFTWARE ENVIRONMENT LEVEL 1 (DASE-1) PART 4: APPLICATION PROGRAMMING INTERFACE

Legal Events

Date Code Title Description
B15K Others concerning applications: alteration of classification

Ipc: H04N 5/45 (2011.01)

B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 11A ANUIDADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2494 DE 23-10-2018 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.