Screnshort embedded

Coloque prints para tira fotos de dentro de jogos e apps Baixar ir no jogo/apps e mudar para .zip depois vc abre o screen short e clica no final é só mudar para .jar denovo. A tecla de capitura e a pasta vc configura antes na hora que vc abrir o app vá em configurações


Download .zip

Download .jar

{ Read More }

Progamação .class j2me

Progamação .class parte 3 , Página 2 , Página 3

Progamação .class Parte 4,  Página 2, Ultima

{ Read More }

Novos Apps *unicos e raros

Novos apps pra vc se divertir no seu celular

Mega apps & Mega Apps 2 Varios aplicativos em apenas um para vc usar em seu aparelho ao mesmo tempo - Download Mega Apps - Download Mega Apps 2

Navegue em Mult Operas rapido lembre-se para trocar  aperte *(asterisco) - Download







Editor de imagens - Download





Editor de Jogos "nova verção" - Download

{ Read More }

Criador de jogos j2me pelo celular (100% garantido)

Criem Seus propios jogos e aplicativos para seu celular com esse incrivel aplicativo!

Casa tenha duvidas Olhem nossos outros post que pode ajudar!

{ Read More }

Criar o app Hello Word J2me

Dê o primeiro passo em direção a aprender como programar em Java 2, plataforma de Micro Edição (J2ME) com a famosa aplicação "Hello World" 

Conhecendo aplicação Hello Word

Criar o app Hello Word J2me

Parte 2

Java 2, Micro Edição (J2ME) dá aos desenvolvedores Java a oportunidade de aproveitar suas habilidades em programação numa grande variedade de dispositivos móveis, como telefones celulares, PDAs, etc.. Sem sombra de dúvida, dispositivos móveis são diversos em suas capacidades e poder de processamento. J2ME cria uma camada de abstração, minimizando estas diferenças ao definir configurações e interfaces, as quais, juntas, provêem uma plataforma completa e uma Interface para Programação de Aplicativos (API). Estas APIs possibilitam o desenvolvimento de aplicativos em qualquer dispositivo que possua suporte a estas.
A Configuração Limitada de Dispositivos Conectados (Connected Limited Device Configuration - CLDC) e o Perfil de Informações para Dispositivos Móveis (Mobile Information Device Profile - MIDP) combinados estão presentes na maioria de dispositivos móveis de baixo custo, como PDAs, telefones celulares e pagers two-way. Neste artigo, você terá a possibilidade de começar a aprender J2ME ao construir um pequeno aplicativo de teste.

Hello World!
O processo de fazer uma build, instalar, e rodar um aplicativo MIDP é bem diferente daquele utilizado normalmente em aplicativos Java. Isto é um tópico diferente, que virá num artigo futuro. Por enquanto, você terá de se contentar em examinar a estrutura de nosso aplicativo teste. Logo abaixo encontra-se o código para um aplicativo "Hello World" e logo abaixo a figura mostrando o resultado. 

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloJ2ME extends MIDlet implementsCommandListener

{

 private Display display;

 private TextField caixaDeTextoHello;

 private Command comandoDeSaida;

 private Form formularioPrincipal;

 public HelloJ2ME()

 {

  // Armazenar ponteiro para o objeto “Display”, passando a

  // instância deste aplicativo

  display = Display.getDisplay(this);

  //Criar o formulário principal (janela)

 formularioPrincipal = new Form("HelloJ2ME");

  //Criar o botão de comadno de saída do aplicativo

 comandoDeSaida = new Command("Exit", Command.SCREEN,1);

  //Create a single-line text field 15 characters long

  //with the label "Text"

 caixaDeTextoHello = newTextField("Text","Hello World!",15,TextField.ANY);

  //Adicionar os comandos do nosso aplicativoe

  //o nosso método que tratará dos comandos

  // Adicionar o comando de saída à nossa janela

  formularioPrincipal.addCommand(comandoDeSaida);

  // Adicionar a caixa de texto contendo o texto “Hello World”

  // à nossa janela

  formularioPrincipal.append(caixaDeTextoHello);

  // Registrar o método que tratará os comandos

  // com o sistema

  formularioPrincipal.setCommandListener(this); 

 }

 public void startApp()

 {

  // Setar meu formulário principal como

  // o objeto ativo. Em outras palavras: nossa

  // janela é a que aparece na tela!

  display.setCurrent(formularioPrincipal);

 }

 // Método que trata o comando de pausa vindo do sistema

 public void pauseApp()

 {

        /*aplicativo está sendo pausado*/

 }

 // Método que destroi o nosso aplicativo

 // O sistema chama este método quando precisa

 public void destroyApp(boolean incondicional)

 {

         /*nosso aplicativo está terminando aqui*/

 }

 public voidcommandAction(Command comando, Displayable s)

 {

  // Alguém clicou na janela

  // Vamos checar se clicaram no comando de saída

  if (comando == comandoDeSaida)

  {

     // Clicaram no comando de saída!

     // Temos de terminar nosso aplicativo manualmente

     // chamando o método “destroyApp”, passando argumento

     // booleano “falso”

     destroyApp(false);

     // Agora temos de notificar o gerente que nosso aplicativo

     // foi terminado

     notifyDestroyed();

  }

 }

}

O resultado: 

Com certeza, não é de impressionar, eu sei, mas bons exemplos raramente são. Como você pode ver, nosso exemplo J2ME estende ao aplicativo a classe base MIDP através da classe MIDlet e importa dois namespaces: javax.microedition.midlet e javax.microedition.lcdui. Um inclui a classe base MIDIlet para o nosso aplicativo, enquanto o outro provê a interface gráfica (Graphical User Interface - GUI), respectivamente.

A classe MIDlet provê três métodos abstratos que são usados pela aplicação. Estes métodos são chamados à partir do gerenciador de aplicações do dispositivo, e é usado para comunicar com os aplicativos que estão rodando. O método "startApp" é chamado imediatamente depois do construtor e cada vez que um aplicativo é ativado (está visível). Isto implica que este método não é chamado somente ao aplicativo ser iniciado. Uma aplicação pode fazer a transição entre os estados de ativa e inativa muitas vezes durante o tempo em que está sendo rodada, portanto você deve evitar colocar código de inicialização que só pode ser rodado uma única vez. Um bom exemplo é o código utilizado para inicializar a GUI, que deve ser colocado no construtor ao invés desse método.

O método "destroyApp" é chamado pelo gerencaidor de aplicativos para indicar que uma aplicação está prestes à ser terminada. Não como o método "startApp", este método será chamado uma única vez durante o tempo de execução de uma aplicativo, portanto é recomendado o uso de "código de limpeza" aqui. De fato, por causa do fato da MIDP não incluir em sua funcionalidade a capacidade de finalizar seus objetos, você terá de terá de fazer "a limpeza" aqui mesmo. Ao mesmo tempo, entretanto, um dispositivo móvel típico é bem menos estável que uma plataforma típica de desenvolvimento e será constantemente desligado e/ou reinicializado pelo usuário. Portanto, você não pode contar com a execução de "destroyApp" toda as vezes.

O método abstrato remanescente, "pauseApp", pode ser considerado um tanto quanto esquisito quando analisado pela primeira vez. Este método é utilizado para notificar o aplicativo que está rodando está para ser pausado porque o usuário acabou de começar a rodar um outro aplicativo ou está utilizando uma função do dispositivo que prevenirá seu aplicativo de continuar rodando. Por causa do fato da maioria dos dispositivos móveis não terem poder de processamento para estarem realmente "multitasking"(executando várias funções ao mesmo tempo), este método provavelmente será chamado com uma certa freqüência. Você também deve manter em mente que os recursos sendo utilizados pelo seu aplicativo devem ser liberados neste momento. Quando a sua aplicação volta à rodar, o método "startApp" será chamado pelo gerenciador de aplicativos.

Comunicando com o gerenciador de aplicações (application manager)

Claramente, toda comunicação tem que acontecer em ambas direções, ou seja, ir e vir, para ser eficiente. Aplicações MIDP não são exceção nenhuma. O MIDlet provê um conjunto de métodos que você pode usar para comunicar-se com o gerenciador de aplicações:
· NotifyDestroyed fala ao gerenciador que a sua aplicação quer ser terminada. Ao chamar este método, o resultado não será ter o método "destroyApp" ser executado, portanto você terá de chamá-lo manualmente.
· NotifyPaused notifica o gerenciador que a sua aplicação quer ser pausada.
· ResumeRequest solicita que o gerenciador volte a rodar a sua aplicação, se este estiver pausada.
· GetAppProperty busca as informações de configuração de uma aplicação. Tal informação pode ser acessada através do fornecimento de um manifesto ou um arquivo de descrição de um aplicativo (application descriptor file). Em outras palavras, este método dá acesso a um arquivo de inicialização privada.

Gerenciando a interface

O pacote javax.microedition.lcdui contém os elementos de interface gráfica utilizados por aplicativos MIDP.

Conheça a família

Há basicamente três famílias de componentes GUI definidos no pacote "lcdui", que são agrupados baseados em suas classes base: Componentes de tela; Componentes de item; e Componentes diversos de display.

Componentes de tela 

Os componentes de tela são descendentes da classe abstrata "Screen" e provêem os widgets de interface gráfica em forma de janela. O objeto "Form" (formulário) usado no exemplo "HelloJ2ME" é um descendente da classe "Screen", que contém e forma controles de interface gráfica. Outros componentes de "Screen" incluem alertas (Alert), caixas de diálogo (dialog box), listas (List) e caixas de texto (TextBox), sendo esta última uma forma de entrada de texto que suporta múltiplas linhas.

Componentes de item

Os componentes de item são controles tradicionais, como o campo de texto "Hello World!" na nossa aplicação exemplo. Estes controles todos são descendentes da classe "Item". Esta classe provê uma API uniforme para colocar-se etiquetas de nome, tratamento de eventos, e exibição de controles. ChoiceGroup, DateField, Gauge, ImageItem e StringItem são outros componentes da classe Item.

Componentes diversos de display

Todos os componentes diversos de display são, na sua grande maioria, descendentes da classe de hierarquia mais alta e abstrata "Displayable". Este grupo inclui componentes como a classe "Command", que integra os botões de comando; "Ticker", que integra as caixas de texto rolantes; "Graphics", que exibe os gráficos; e "Choice", que é uma interface de manipulação de seleções pré-definidas, que, por sua vez, não se encaixam em qualquer outra categoria.

Esta figura ilustra a hierarquia destes componentes. 

Os membros do pacote "lcdui" 

Toda a parafernália gráfica é gerenciada por um objeto "Display", à partir do qual, cada aplicação tem acesso à uma única e privada instancia. Esta instancia pode ser obtida através do método estático "Display.getDisplay". É de costume manter uma única referência à esta instância em uma variável, da mesma maneira que é feita no construtor do nosso exemplo "HelloJ2ME". Além dos métodos para concentrar o foco da tela em um elemento em particular (setCurrent) e descobrir qual o elemento com o foco (getCurrent), a classe "Display " também expõe vários outros métodos muito úteis para obtenção de informação sobre as capacidades do display do dispositivo. Entre estas capacidades estão a detecção de suporte à cores (isColor) e quantas cores são suportadas (numColors).

Coisas para lembrar-se

Vamos terminar este tutorial com uma curta lista de coisas para manter em mente ao desenvolver aplicações em Java para uma plataforma móvel. Primeiro, você terá que lidar com uma biblioteca de classes bem limitada: sem refletir, JNI, ou, como mencionado antes, suporte à finalizações. Segundo, você terá que lidar com altíssimas restrições quanto ao uso de memória, já que a maioria dos dispositivos rodando MIDP terá menos de 100K de memória dinâmica disponíveis. Como resultado, você terá de ser bem cuidadoso com a memória utilizada pelos algoritmos que costuma usar. Finalmente, tenha em mente que qualquer conectividade com redes será limitada em largura de banda e, provavelmente, esporádica. 

{ Read More }

Conhecendo a interface java

Como Editar/Criar Jogos J2me Conhecendo a interface java

Parte 1

 O Que é J2ME?

A plataforma Java 2 Micro Edition (J2ME) implementa a linguagem Java para vários dispositivos tais como telefones celulares, PDAs, Internet screenphones, settop boxes digitais para TV, sistemas de navegação automotiva, comutadores e roteadores de rede, componentes para automação residencial, etc. 

A plataforma J2ME consiste de máquinas virtuais (KVM) e APIs especificadas em "documentos de configuração" ("Configuration" – CDC e CLDC) em conjunto com perfis ("Profiles" - MIDP) para uma determinada aplicação ou mercado. Tudo está disposto em camadas de software como segue no diagrama abaixo:

                             

                               

Camadas de software do J2ME

O desenvolvimento de Configurações e Perfis se dá de acordo com processos estabelecidos pela “Comunidade Java”. Nesse processo, similar aos do IETF, podem participar o setor privado, público, “neutro”, ou mesmo indivíduos. Há votações para a aprovação de uma determinada especificação que só se torna pública uma vez que aprovada pela maioria.

Maiores detalhes podem ser obtidos no site da SUN:

http://java.sun.com/products/cldc

http://java.sun.com/products/midp

A versão suportada na maioria dos dispositivos celulares no Brasil é a CLDC 1.0 e o MIDP 1.0. O suporte comercial ao MIDP 2.0 está previsto para o final de 2003, quando deverão ser lançados os primeiros modelos baseados nessa nova versão do perfil.

O CLDC (Connected Limited Device Configuration) contem uma API mínima para poder rodar aplicativos em dispositivos móveis com limites de processamento e memória, tais como, telefones celulares, smartphones, pagers e PDAs. 

Em oposição temos a CDC (Connected Device Configuration) que supõe dispositivos com mais capacidade tais como settop boxes digitais, screen-phones, Nokia Communicator e alguns PDAs mais poderosos.

No que diz respeito ao CLDC para aparelhos celulares, temos as seguintes características:

·  Hardware requerido: mínimo de 160KB de memória para Java, um processador de no mínimo 16 bits com baixo consumo (adequado a baterias típicas de um celular) e conexão de rede (neste caso wireless – 9.6Kbps, 144Kbps ou 2Mbps).

·  Software que inclua suporte a um subconjunto da linguagem Java e a um subconjunto da máquina virtual Java que definam um núcleo de funções que permitam o desenvolvimento de aplicações móveis.

A segurança, que a CLDC define, está baseada no chamado “Sandbox Security Model”, isto é, a máquina virtual terá um espaço de memória independente do restante das aplicações do celular (tais como agenda, tons, imagens, configura ção, browser WAP, etc). 

Nesse modelo de segurança restringe-se as operações que podem ser executadas a um conjunto de funções da API tão somente. Nenhuma outra operação é permitida. Com isso a aplicação não pode acessar a área de memória do calendário ou agenda de contatos do aparelho celular. Outro ponto importante no que tange ao Java é o fato que não é permitido carga de classes definidas pelo usuário de forma a garantir a segurança de qualquer aplicação desenvolvida com a API CLDC.

Essa é uma diferença significativa em relação ao BREW que não define limites à aplicações que por sua vez podem acessar áreas de memória de qualquer parte do celular, compartilhar dados com outros aplicativos, alterar áreas de código também. 

O fato do C/C++ permitir acesso via apontadores a memória, o que o Java não permite, ajuda o BREW a ser mais flexível, porém exige que o programador saiba o que está fazendo. 

Por esse motivo o custo de desenvolvimento no BREW é mais alto, pois toda aplicação tem que ser testada e certificada pela Qualcomm para garantir que não se introduza na rede aplicações “mal intencionadas ou simplesmente mal feitas” e com isso ponha-se em risco toda a c redibilidade da plataforma BREW.

O J2ME corta esse risco pela raiz, o que o faz ser mais limitado, porém seguro e com custos de desenvolvimento menores. Em cada plataforma há suas vantagens e seus “trade-offs”.

No topo da camada de CLDC temos a camada de software chamada Profile. O Profile, ou Perfil, especifica um conjunto de APIs que moldam-se a um determinado tipo de dispositivo.

A diferença entre Configuração e Perfil é que a Configuração descreve de forma geral uma família de dispositivos, enquanto o Perfil fica mais específico para um tipo particular de aparelho em uma dada família. 

O Perfil tão somente acrescenta funcionalidades àquele particular aparelho. 

O Perfil MIDP contem, por exemplo, APIs para aparelhos celulares enquanto o CLDC aborda APIs para dispositivos móveis de pouca capacidade de processamento, dentre os quais temos celulares, pagers etc.

O CLDC define em sua API os pacotes java.io, java.lang, java.util e javax.microedition.io (conexão e interfaces). Notem que não há suporte a ponto flutuante, suporte completo à classe Error do J2SE, a referências fracas, verificação de arquivos de classes (há no lugar uma ferramenta de “pré-verificação”), finalização - Object.finalize(), JNI (Java Native Interface), reflection, thread groups/ daemons e user-defined class loaders.

O MIDP define tudo o que há no CLDC com a adição aos pacotes javax.microedition.lcdui (interface com o usuário), javax.microedition.rms (sistema de gerência de registros para persistência de informa ções), javax.microedition.midlet (suporte para aplicações MIDP, os chamados midlet s).

Vários fabricantes adicionam ao MIDP algumas outras APIs, tais como suporte a uma forma simplificada de AWT (Abstract Window Toolkit) e controles de vibração, som e display. 

Cada fabricante adiciona livremente o que considerar importante. Isso torna difícil muitas vezes portar aplicações entre fabricantes, a menos que se use sempre o conjunto mínimo especificado no MIDP 1.0. 

Com o MIDP 2.0, haverá um conjunto mínimo que incluirá controles de vibração, som e display entre outras capacidades. Dessa forma haverá mais portabilidade entre os vários modelos e fabricantes.

De onde baixar ferramentas de desenvolvimento?

No site da SUN Microsystems podem ser encontradas ferramentas que permitem gerar os arquivos necessários para rodar aplicações em aparelhos compat íveis com o J2ME. 

Entre as ferramentas há um gerenciador de projetos bem simples e um emulador genérico de terminais com MIDP, tudo faz parte do J2ME Tool Kit.

Nesse Tool Kit não há um IDE (Integrated Development Environment), portanto poderá ser necessário editar o código fonte em ferramentas próprias, compilar, pré-verificar e empacotar usando as ferramentas do Kit para , em seguida, emular o resultado e depurar o código. 

É um ciclo comum em ambientes como UNIX, usando-se por exemplo Makefile.

Porém, para facilitar as coisas, a SUN disponibilizou um IDE livre chamado Forte for Java ou SUN One Studio, nome que atualmente é usado. Existem outras opções tais como o NetBeans IDE ou a versão comercial do JBuilder da Borland.

Para instalar um ambiente de desenvolvimento para J2ME, o primeiro passo é baixar e instalar o J2SE SDK e JRE da SUN. Sem os quais não é possível se fazer nada.

É necessário ter o sistema operacional Windows NT ou 2000. Existem versões para Linux e Solaris, caso se prefira ambiente UNIX.

Caso o objetivo seja apenas poder rodar aplicações de demonstração, é necessário apenas o J2SE JRE (Java Runtime Environment). 

Se o objetivo é desenvolver aplicações são necessários ambos o J2SE JRE e SDK (Software Development Kit).

Para obter o Java2 SDK, Standard Edition (J2SE SDK) e/ou o Java 2, Standard Edition Runtime Environment (J2SE JRE) na versão mínima - 1.3 (atualmente está disponível a versão 1.4.1) vá para:http://java.sun.com/j2se/1.4.1/download.html

Escolha o sistema operacional, língua, etc.

Após baixar o JRE e/ou SDK, instale cada qual, preferencialmente o JRE primeiro. 

Em seguida baixe o J2ME Wireless Toolkit versão 1.0.4 _01 pelo link abaixo:

http://java.sun.com/products/j2mewtoolkit/download.html

Instale o J2ME toolkit. 

Com isso já será possível criar aplicações J2ME e testá-las no simulador que está incluído nas ferramentas. 

Caso esteja usando Windows NT ou 2000, as ferramentas estarão disponíveis na barra de ferramentas no botão “Start” ou “Início”.

Aos que não gostam de usar Makefiles ou .bats em conjunto com NotePads para editar ou Edit do “MS DOS Prompt”, existe a opção de se baixar um JDE (Java IDE) da própria SUN, o SUN One Studio 4 update 1, Mobile Edition no link abaixo:

http://wwws.sun.com/software/sundev/jde/buy/index.html

Apesar de ter uma referência a “buy” na URL acima, na verdade é possível baixar o IDE gratuitamente. 

Note que a parte que trata sobre o SUN One Studio Mobile Edition está bem ao final da página na WEB. 

Baixe o arquivo e instale-o.

Com isso temos um conjunto de ferramentas sem custo algum que permite que se desenvolva e teste aplicativos que poderão ser executados em qualquer aparelho com suporte a J2ME. 

Na próxima sessão será abordado o primeiro programa em J2ME, um tutorial sobre o midlet “Hello World!”.

(Continua)

{ Read More }

Minhas super criações para editar java

® Editor_de_java- Link direto
® Editor_de_java - Link direto Zip
Mult_Editor_java_Upload - Link Direto
Mult_Editor_java_Upload - Link Direto Zip
Mult_Editor_Java_Re-Upado(Paint) - Link Direto
Mult_Editor_Java_Re-Upado(Paint) - Link Direto Zip
Mult_Edito_Java_Re-Upado - Link Direto
Mult_Edito_Java_Re-Upado -Link Direto Zip

{ Read More }

Meus APP para celular j2me

Meus App
Mult Editor De java - link direto

Essa é a evolução da minha ultima postagem de Mult Editor deJava com a possibilidade de editar texto com o moby explore juntar vários java em um com o MultMIDletMake mudar a resolução de jogos com o screensize e até tirar fotos de jogos e app! eh vc pode tirar foto de dentro do seu jogos com o screenshort Embemed tbem pode traduzir jogos e apps com o lang edition e para vc não ter que sair tbem coloquei o lite ftp! é isso pessoal espero que gosem(se tiverem problemas ou duvidas é só falar!:-D Baixem tbem a outra verção http://www.jogosparacelular.com.br/jogosparacelular/jogo/22311/mult-editor-dejava 

{ Read More }