| Autor |
Mensagem |
|
|
Quando eu utilizo a task mencionada acima, ela adiciona estas 2 linhas extras no meu arquivo MANIFEST.MF:
Ant-Version: Apache Ant 1.7.0
Created-By: 1.6.0-b105 (Sun Microsystems Inc.)
Alguém sabe como impedir esta adição? Pode parecer algo simplório para se preocupar, mas eu estou utilizando essa task para produzir aplicações em Java ME, onde todos os bytes que precisam ser economizados. No momento estou precisando reduzir meu arquivo em 30 bytes para que ele funcione em meu dispositivo-alvo. A remoção dessas duas linhas leva junto 55 bytes. Eu poderia fazer isto manualmente, mas não se trata de um único arquivo, pois utilizo o Ant para gerar mais de trinta versões diferentes do mesmo arquivo, sendo que faço isso várias vezes ao longo do desenvolvimento, para testes funcionais, não apenas no fim deste.
Waocnek
|
 |
|
|
Fale mais sobre o erro que está ocorrendo. Até o momento, vejo dois problemas:
"Imagem"? Não seria "Image" em ambas as referências? Isto pode causar um erro de compilação.
Geralmente, eu coloco o "png" em maiusculo (como está no nome do arquivo). O código pode não está encontrando o arquivo por causa disso, ocasionando num erro de execução.
Nota: Trate a Exception para determinar se alguma coisa está acontecendo.
|
|
|
|
Creio que o significado desta afirmação seja que a chamada do método, ou seja, a invocação, deve ter uma lista de argumentos na chamada que seja idêntica, no sentido de tipo de variável, à encontrada na assinatura do método. Utilizando seu exemplo:
Está certo, mas qualquer coisa diferente, tal como:
Não irá funcionar. Isto é um pouco óbvio, mas é importante enfatizar no estudo, pois é a lista de argumentos que determina qual método de fato será chamado. Se bem me recordo, isto é determinado em tempo de compilação.
Pelo menos, esta é a minha interpretação do significado desta frase "A chamada deve ser do mesmo tipo que a lista de argumentos", posso estar enganado...
Waocnek
|
|
|
|
Não, ele está alterando o valor da variavel do tipo int denominada i da classe A, que NÃO É a variável (quase idêntica) presente na interface I. Confesso que quando vi esta questão, eu pensei que não iria compilar em razão desta linha:
System.out.print(obj.I);
Note que a classe A não possui nenhuma variável denominada I.
Waocnek
|
|
|
|
Pra descompilar .class eu prefiro o cavaj (javac ao contrário). Já encontrei a explicação muito bug estranho com ele. Depois eu irei testar esse outro, mas não acho que ele pode fazer tudo isso não. Inviabilidade prática.
Waocnek
|
|
|
|
Simples. Se A implementa I, você pode colocar um A numa referência do tipo I, mas não pode colocar um I numa referência do tipo A.
O código:
I i = new A();
É perfeitamente válido, mas:
printAll(i)
Não é válido! O método printAll espera um A, não um I. Apesar do A ser um I, outras classes podem ser um I também e elas não podem ter os mesmos métodos/variáveis que serão usadas para o método printAll, por isso a proibição. Um B pode ser colocado, por exemplo, pois ele é uma sub-classe de A, logo possuirá todos os métodos/variáveis disponíveis num A, obrigatoriamente. Note que, no exemplo, o objeto que a variável i está referenciado é de fato um A, mas o compilador não tem como saber isso durante sua compilação, por isso mesmo assim ocorre o erro.
Waocnek
|
|
|
|
Coesão é a capacidade de uma classe em cumprir seu papel. Se você cria uma classe bicicleta, ela deverá possuir todos os métodos e variáveis pertinentes à uma bicicleta, nem mais, nem menos. O que aconteceria se um método de roda ficasse na classe bicicleta? Código mais complicado e mais difícil de se entender.
Acoplamento é a dependência de uma classe com outra. Quanto mais dependente for uma classe de uma outra classe especifica, mais dificil fica a manutenção do código, pois uma alteração nesta última significa em mudanças também na sua dependente. Imagine que você irá utilizar uma estrutura de dados do tipo lista e resolva usar a ArrayList. Você conhece as limitações da ArrayList, limitações não expostas na interface pública dessa classe, logo realiza alguns truques pra contorná-las. Meses mais tarde, você recebe uma nota do cara do QA que seria bom utilizar a LinkedList... E agora? Mudança em todos os códigos... O ideal teria sido utilizar desde o início a interface List, mesmo senão houvesse a mudança, pois ela iria (1) limitar a quantidade de métodos disponíveis e (2) definir apenas o papel da classe que ali estaria, uma Collection do tipo List. Exatamente qual, não interressa, pois seu código apenas precisava disto em primeiro lugar.
Waocnek
|
|
|
|
Na prática (em termos de código) o que isso quer dizer?
Que você não pode acessar um membro protected de uma classe fora do pacote desta a menos que você seja uma sub-classe, mas isto apenas funciona caso você acesse via herança, por exemplo:
Tudo bem! Mas...
Erro! Ou seja, concordo como resposta para sua pergunta com o trecho do livro da Kethy que o eltonk postou.
Waocnek
|
|
|
|
Eu costumo utilizar apenas um Canvas e o Strategy design pattern. Basicamente, utilizando seu caso como exemplo, você possui uma interface "Fase", com diversas classes implementando ela, cada uma correspondendo à uma fase especifica dentro do jogo. O seu Canvas passa o processamento para uma dessas classes para criar a tela de jogo da fase em questão. Como mudar de fase? Colocando um outro objeto para o Canvas, no caso, uma instância da classe da nova fase.
De fato, utilizo esse pattern em N outras coisas dentro de um jogo. Desnecessário dizer que pode trazer alguns problemas de performance. É possível fazer tudo numa única classe, mas o código irá parecer uma "macarronada". Note que isto depende da fase do jogo em questão!! Em alguns casos, mudando alguns valores de um objeto, já fará a classe alterá bastante.
Waocnek
|
|
|
|
Eu não me recordo exatamente os valores, apenas do simulado do Green, pois ele é famoso em fazer simulados com mesmo nível de dificuldade do teste real, sendo que muitos alegam obter uma pontuação no teste semelhante ao do simulado. No meu caso, a pontuação foi a mesma 
Waocnek
|
|
|
|
Eu sou estudante universitário 
Entrei em contato com o Java no primeiro semestre (estou no último, agora) há quase quatro anos. Praticamente, "aprendi a fazer algoritmos". Apenas de julho do ano passado pra cá que eu venho me dedicado a trabalhar com o Java mesmo, em projetos dentro e fora da grade curricular de onde estudo. Depois de quase 1 ano, em junho, comecei a estudar pra certificação e aqui estou agora, com o SCJP, me preparando para obter o SCMAD semestre que vem
Minha pontuação por seção:
Declarations, Initialization and Scoping
100%
Flow Control
100%
API Contents
100%
Concurrency
87%
OO Concepts
80%
Collections / Generics
80%
Fundamentals
81%
Waocnek
|
|
|
|
Conseguir ontem fazer meu teste e passei facilmente. Estudei pelo livro 5.0 da Kathy por 4 meses e como simulados, utilizei apenas estes:
http://home.wanadoo.nl/mrzljak/en/biz/exam.html
http://www.examulator.com/phezam/login.php
http://www.javabeat.net/javabeat/scjp5/mocks/index.php
http://www.javablackbelt.com/ExamTaskListing.wwa (Testes da lista de "Java SE Certification" e de "OO")
Nota: Eu tirei 90% no segundo simulado, sendo que, se bem me recordo, foi feito pelo Marcus Green.
Também estudei pelos links presentes no JavaRanch, mas evitei assuntos relacionados com a prova 1.4. O teste não foi difícil, quando eu terminei e revisei o mesmo, ainda tinha 1 hora restante, das quase 3 horas pra fazer. Na minha revisão encontrei apenas 1 resposta errada. Infelizmente, não pude checar as questões de Drag'n'Drop, pois o sistema apagava as respostas anteriores. Creio que as 7 questões que errei são justamente as 7 questões de Drag'n'Drop em que estava em dúvida. O assunto que mais caiu foi Threads, foram dezenas de questões (errei apenas 2...).
A única "tensão" que houve foi que eu não tinha a menor idéia de como seria o resultado. Não sabia se fui bom o suficiente até sair na impressora a pontuação. Isso tinha acontecido durante os simulados, quando eles tinham mais de 50 questões, eu não tinha a menor idéia de como foi o resultado geral até ver as notas.
Waocnek
|
|
|
|
Se 'empacotar' significa criar o .jar, basta utilizar o procedimento convecional usando no Java SE, prestando atenção em colocar um MANIFEST correto. Lembre-se que ainda existe o .jad e que o código deve ser preverificado. Para maiores detalhes, sugiro procurar o livro Java 2 Micro Edition (J2ME). Pelo menos não me recordo de nenhuma explicação dele que não usasse o prompt de comando.
Waocnek
|
|
|
|
Isso ocorre porque você estava pintando a String e depois pintava o Layer por cima. Não é que ele não aparecia, mas havia algo sendo pintado por cima. A ordem da pintura é sempre importante, especialmente em jogos.
Waocnek
|
|
|
|
Você clica direto no botão ou primeiro executa uma configuração pra indicar qual o MIDlet e o emulador para serem rodados, para então clicar direto no botão?
Waocnek
|
|
|
|
|
|