| Autor |
Mensagem |
|
|
narukaioh wrote:o forum ta monotono.. :\ tem outro cara que a milhares de anos perguntou. A mesma coisa, e nada..
Já parou para pensar que talvez ninguém soubesse a resposta? E que as pessoas que vem até aqui ajudar, em sua esmagadora maioria, o fazem por boa vontade? Portanto cobrar não é de bom tom....
E se o objetivo é começar, que tal começar a aprender a usar o Google? Uma simples busca trouxe, como primeiro link, o próprio SDK do Android com informações que devem ser úteis a você. O segundo link é de um tutorial (para uma versão antiga do Android, mas como ponto de início está bom).
|
 |
|
|
Se você tem um aparelho em mãos, usá-lo para testes é a coisa mais fácil do mundo: vá nas configurações dele, seção aplicativos, opção desenvolvimento, e habilite "depuração USB".
Aí só vai precisar ligar o telefone via USB no computador, e lá no Eclipse dar um "run as android application". Se o seu SDK estiver corretamente instalado, o app será "magicamente" instalado no aparelho e começará a rodar, permitindo debugar inclusive.
Eu particularmente acho muito mais produtivo testar o app no celular do que no emulador.
|
|
|
|
A taxa de U$25.00 é paga uma única vez, no ato da inscrição.
Não há limite para a quantidade de aplicativos que podem ser colocados no market.
E caso o app não seja gratuito, 30% de cada venda fica com a Google. Você também pode alterar o preço do app à vontade. Só não pode passar a cobrar por um app que inicialmente era gratuito.
|
|
|
|
|
http://developer.android.com/guide/topics/data/data-storage.html#db
|
|
|
|
Luiz Aguiar wrote:Os produtos da Apple não rodam Java SE, na verdade nenhum dispositivo do mercado roda, alguns mais antigos rodam Java ME apenas.
Pequena correção: o Nokia N900 roda programas desenvolvidos em Java SE. E está no mercado.
Mas como é um aparelho sem futuro, é apenas uma pequena correção mesmo... 
|
|
|
|
Marky.Vasconcelos wrote:A APK é apenas uma WebView, eu não posso colocar algum botao para isso.
Eu acabei solucionando com uma Stack das URLs que foram chamadas e intercepto o 'return' para carregar o 'pop()' da Stack.
Mas eu não disse "colocar um listener para um botão", mas "colocar um listener para o botão"!
Foi exatamente o que você fez! 
|
|
|
|
|
Colocar um listener para o botão, capturá-lo, tratá-lo e evitar que seja propagado não rola?
|
|
|
|
pango wrote:
Z wrote:no meu note (core i3 com 4gb de ram) estou usando o ubuntu 11.04 (muito a contragosto). Abri mão de usar toda a memória (só reconhece 3,5Gb) pela compatibilidade (flash principalmente).
No Ubuntu você pode perfeitamente utilizar 32 bits e enxergar toda a sua memória, é só instalar um kernel PAE. Dá uma pesquisada no Google por Ubuntu + PAE.
Não apenas no Ubuntu, mas em QUALQUER Linux. Só que isso pode provocar uma queda de performance acentuada. Eu fiz o teste antes de me decidir por um sistema 64 bits puro, e a diferença de performance foi assustadora (comparando um sistema 64 com outro 32 com PAE, não comparando um 64 com outro 32 "puro").
|
|
|
|
juliocbq wrote:pelo que li no link não é o aplicativo que está infectado, e sim o próprio aplicativo é um trojan. E isso não é vírus, se você desinstalar o software resolve o problema.
Há casos em que o aplicativo está infectado, mas é uma infecção, digamos, diferente. Alguém pegou o programa original, o alterou colocando o código malicioso, e subiu de novo no Market, sob outro nome (lembrando que o nome no caso é o "package", não o nome fantasia).
Portanto o programa original contaminado continua funcionando, fazendo aquilo que deve, mas com surpresas.
|
|
|
|
Se a FedEx não aceitar o pacote sem indicação de valor, você vai pagar o imposto quando ele chegar no Brasil, pois via transportadora toda encomenda passa pela Receita (na verdade a própria transportadora calcula o imposto e cobra direto do destinatário).
Eu já fiz compras na Amazon e os produtos foram entregues no Brasil....mas claro: eram produtos que eles enviam para cá (que não é o caso do seu pedido).
Se quer correr poucos riscos e não pagar o imposto, pede pra alguém trazer.
|
|
|
|
Schuenemann wrote:Uma pergunta: na opinião de vocês, o que o Skype perderia com essa publicação e eventuais clientes alternativos?
É pra essa pergunta que eu estou buscando uma resposta desde que saiu a notícia, e não encontrei ainda.
Poderiam dizer que a empresa perderia receita. Como? Se pra entrar na rede do Skype você continua tendo que....oras....acessar a rede do Skype! E portanto a empresa continuaria vendendo os créditos e lucrando. Ela só perderia receita em banners.
Se o medo é que se crie uma rede alternativa, aí eu pergunto: de que adiantaria? Nessa rede alternativa você não conseguiria falar com o seu amigo que tem Skype "puro".
Uma coisa que pode fazer sentido é permitir capturar as conversas. Conhecendo o protocolo você poderia através de um sniffer pegar os pacotes. Mas até aí acredito que os dados sejam criptografados.....
Edição: não entro no mérito do russo estar certo ou errado, até porque acho que ele está errado. Para descobrir o protocolo ele teve que baixar o software, aceitando a licença de uso. Se na licença de uso está explícito que não pode usar engenharia reversa para descobrir coisas sobre a aplicação, cometeu no mínimo uma infração.
|
|
|
|
malconL wrote:
fenrir wrote:O processamento do programa não deveria ser reduzido, mas o processamento da tela sim (por que processar tela se ela está desligada?).
Quem disse que o processo em questão é responsável por atualizar a tela?
Tem razão....não é exatamente o processo responsável pela atualização de tela diretamente, mas por elementos que nela são apresentados, como a barra de notificação.
A tela em si pode não estar sendo atualizada, mas porque um elemento que só faz sentido quando ela está ligada é atualizado e fica consumindo recursos?
Vou tentar achar algo no bugtracker do Android.....
|
|
|
|
Marky.Vasconcelos wrote:Boa pergunta, na verdade quando está sem ser exibido os métodos de desenho não deveriam ser chamados (e acho que realmente não são).
Talvez no seu caso voce esteja realmente processando o que precisa na UI Thread.
Não tá não....tanto que quem está rodando é um serviço (android.app.Service) que tem como única interação com a tela (e com o usuário) a criação de uma notificação para mostrar o andamento do processo, exibida na área de notificação. Fiz o teste e se desabilito a atualização da notificação não ocorre processamento de UI alguma....já se deixo habilitado (apenas a sua atualização, pois criada ela é sempre) tá lá a UI processando (e consumindo).
Eu até concordaria em parte se fosse o caso da tela toda estar sendo alterada, pois assim se o usuário ligasse o aparelho a tela demoraria um pouco menos para ser apresentada, mas como se trata de uma notificação não vejo sentido! Sem contar que antes de exibir a tela é necessário passar pelo desbloqueio dela....tempo mais que suficiente para desenhá-la.
malconL wrote:
Mas o que a multi-tarefa tem a ver com a atualização da tela, se esta está desligada? Seria como deixar a cabeça de uma impressora indo pra lá e pra cá, mesmo sem ter nada pra imprimir.
Seria? Atualização de tela consome energia, mas CPU?
Alguém tem que mandar a tela se atualizar, não? E dizer exatamente com o que!
malconL wrote:Quando ao processamento, existe duas formas de pensar:
1) multi-tarefa real, portanto desligar a tela não deveria reduzir em nada o processamento.
O processamento do programa não deveria ser reduzido, mas o processamento da tela sim (por que processar tela se ela está desligada?).
malconL wrote:2) e o estilo iOS de multi-tarefa onde o app é de fato suspenso e não faz uso do processador (apesar de haver algumas exceções são consideradas).
Essa comparação não é válida para o caso, pois não é uma aplicação que está rodando, mas um serviço (em segundo plano, sem interação com o usuário). Sem contar que no Android é assim também (ao suspender a aplicação, o processamento dela para também).
|
|
|
|
Mas o que a multi-tarefa tem a ver com a atualização da tela, se esta está desligada? Seria como deixar a cabeça de uma impressora indo pra lá e pra cá, mesmo sem ter nada pra imprimir.
Ao meu ver é um gasto desnecessário de bateria! Só deveria acontecer atualização de tela quando ela estivesse ligada.
Eu percebi isso e vou alterar minha aplicação para que não atualize a área de notificação se a tela estiver desligada, poupando recursos. Mas e todos os outros programas que tenho instalados e rodando, será que fazem o mesmo? Quanto de bateria eu ganharia se houvesse essa preocupação ou esse cuidado no próprio sistema operacional?
|
|
|
|
Na minha aplicação eu uso uma notificação para mostrar o andamento do upload, e olhando no consumo de CPU durante o processo (através de um top no shell) constatei que o processo com.android.systemui é o que mais está consumindo recursos da CPU. Só há um detalhe: a tela está desligada, portanto não deveria haver processamento de UI.
O Android que não cuida disso (evitar processamento quando a tela não está ligada) e eu é que preciso evitar essas atualizações, ou é um bug do sistema operacional?
|
|
|
|