MIDP 2.0 e suas características - CAP. 02 - SCMAD

• Requisitos para a implementação do MIDP 2.0:

• Deve suportar MIDLets e MIDlet Suites MIDP 1.0 e MIDP 2.0
• Deve implementar a especificação provida pelo usuário OTA.
• Deve prover o suporte ao acesso a servidores HTTP 1.1.
• Deve prover o suporte para conexões seguras HTTP.
• Deve suportar transparência em imagens PNG.
• Deve suportar Geração de Tons no pacote de multimídia (Tone generation).
• Deve implementar os mecanismos necessários para suportar "Untrusted MIDlet Suites".
• Não Deve permitir que sejam feitas cópias de qualquer MIDlet suite a não ser que o dispositivo implemente um mecanismo de proteção de cópia.
  

• DataSource não está disponível no MIDP 2.0
• public boolean MIDlet.plataformRequest(String URL) throws ConnectionNotFoundException
• URL - O campo URL para a plataforma que será carregada. Uma string vazia (não null) cancela quaisquer requisições pendentes.
• Este método é non-blocking.
• E não permite múltiplas requisições.

• A maneira correta para achar a versão da especificação do MIDP implementado no aparelho:

• System.getProperty("microedition.profiles");
• Midlet.getAppProperty("MicroEdition-profile");
• microedition.hostname e get hostname
  

• startApp() e destroyApp() pode lançar uma MIDletStateChangeException.
• Uma exceção SecurityException é lançada se qualquer outra classe que não seja AMS (do próprio sistema) chamar o construtor sem argumentos de um MIDlet ou sua subclasse.
• Um aplicativo pode inicializar ligações telefônicas usando a aplicação nativa do telefone no dispositivo bastando inserir o número na forma de URL "tel://msisdn-number" usando a chamada ao método MIDlet.platformRequest().
• O método MIDlet.platformRequest() pode ser usado para atualizar uma aplicação MIDlet que está rodando.
• MIDlet.resumeRequest() pode ser usada pela aplicação para avisar ao AMS (KVM) que o aplicativo quer move seu estado para o estado ativo (Active state).
• Se uma conexão fechar durante a transferência, o MIDlet parcialmente transferido será deletado automaticamente.
• Apenas o protocolo HTTP é implementado pelo mecanismo de status report.
• Se um cookie foi retornado quando o application descriptor ou o MIDlet suite foi instalado, e o dominio e o o caminho dentro do cookie casar com o URL no atributo MIDlet-Install-Nofigy então o cookie deve ser incluído no cabeçalho de requisição para que o servidor possa identificar que a instalaçáo foi concluída.
• Dados persistentes de um MIDlet suite devem ser preservados quando for atualizado o MIDlet. O formato, conteúdo e versão dos RecordStores são responsabilidade do MIDlet suite individual.
• É necessário que os dispositivos suportem atualização de MIDlets.
• Se uma tentativa é feita para instalar um MIDlet que já está instalado no dispositivo, o usuário deve ser notificado.
• Durante o download de um MIDlet suite, os cabeçalhos de requisição HTTP usados para iniciar o download devem incluir o User-Agent, Accept-Language e Accept. Se disponível quando tiver sendo requisitado o MIDlet suite, este cabeçalho deve também incluir application/java e application/java-archive. Para fazer o download de application descriptors, este cabeçalho deve incluir: text/vnd.sun.j2me.app-descriptor.
  

• Se a plataforma tem capacidades apropriadas e recursos disponíveis, ele deve permitir que o usuário possa abrir um aplicativo nativo e interagir com ele enquanto faz com o MIDlet suite rode em background. Se a plataforma não tem esses rercursos disponíveis, ele pode esperar para lidar com o URL request depois que o MIDlet suite saia. Neste caso, quando o MIDlet suite sair, a plataforma deve trazer a aplicação requerida apropriada (se existir) para a tela ativa do aparelho para que o usuário possa interagir com a mesma.