Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

KaYs3r

Programar para Android

Mensagens Recomendadas

KaYs3r

Boas,

Gostava de me iniciar a programar para Android. Alguém me pode dar umas dicas de por onde começar?

Sei programação básica em PHP e C

Obrigado

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Nazgulled

Onde começar?

Instalar o Android SDK, seguido do Eclipse + plugin ADT.

A partir daí?

Aprender Java e o paradigma POO (se é que já não conheces) e depois ler a documentação.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
IRX773

Programar para Android é Java?

Então quem programar para o Android também vai poder programar os .jar's para symbian 40

OFF-Topic: E para iPhone... também é java ou como se programa?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
zecapistolas

Programar para Android é Java?

Então quem programar para o Android também vai poder programar os .jar's para symbian 40

OFF-Topic: E para iPhone... também é java ou como se programa?

Sim, para criares programas para Android tens que programar em Java, apesar do Sistema Operativo não ter sido criado em Java, acho que é base Unix....

Para iPhone tens que saber Objective-C (é uma espécie de C++).... Já agora, alguém sabe o porque da Apple gostar tanto desta linguagem, afinal quais são reais vantagens?

cumps  :confused:

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
apocsantos

    Penso que tenha a ver com o facto de parte da API Cocoa da Apple ser baseada baseada na interface de objetos OpenStep. Objective-C é C, com algumas das coisas boas do Smaltalk. Como a NextStep fez uma boa parte do seu softwar em Objective-C, e dado que a NextStep enquanto existiu era do actual CEO da Apple, é natural que "velhas ideias ainda se usem" :thumbsup: Creio eu!.

      Isto junto ao facto de o OS X ser baseado no BSD-Unix, e haver suporte para Obective-C, desde o inico do OS X, parece-me logico que a Apple simplesmente se mantenha "fiel" à mesma linguagem em todos os seus produtos.

Cordiais cumprimentos


"A paciência é uma das coisas que se aprendeu na era do 48k" O respeito é como a escrita de código, uma vez perdido, dificilmente se retoma o habito"

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Sim, para criares programas para Android tens que programar em Java, apesar do Sistema Operativo não ter sido criado em Java, acho que é base Unix....

Também podes colocar código nativo em C, com o NDK.

Para iPhone tens que saber Objective-C (é uma espécie de C++).... Já agora, alguém sabe o porque da Apple gostar tanto desta linguagem, afinal quais são reais vantagens?

cumps  :)

Numa palavra? Porque é awesome B)

É mesmo o que o apocsantos disse. Muitas frameworks disponíveis no iPhone são praticamente as mesmas que as do Mac OS X, o que facilita para quem já fazia aplicações para Mac utilizando a linguagem nativa do sistema operativo.

A forma como se chamam funções de objectos é bastante mais legível que na maioria das outras linguagens:

[myArray insertObject: myObject
              atIndex: 2];

Delegates, selectors, key-value coding, protocols,... Mais as ferramentas que o XCode disponibiliza para o debugging de aplicações, fazem do ambiente de programação uma coisa fantástica :)


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bubulindo

[myArray insertObject: myObject
              atIndex: 2];

Isto é mais legível? Ou é apenas uma prova da subjectividade da palavra legível?


include <ai se te avio>

Mãe () {

}

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Sim. Um exemplo:

window.addNewControl("Title", 20, 50, 100, 50, true);

[window addNewControlWithTitle:@"Title"
                     xPosition:20
                     yPosition:50
                         width:100
                        height:50
                    drawingNow:YES];


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bubulindo

Sim. Um exemplo:

window.addNewControl("Title", 20, 50, 100, 50, true);

[window addNewControlWithTitle:@"Title"
                     xPosition:20
                     yPosition:50
                         width:100
                        height:50
                    drawingNow:YES];

E se fosse:

window.addNewControlWithTitle(@"Title", xPosition:20, yPosition:50, width:100, height:50, drawingNow:YES);

Não seria um pouco melhor?

É que nos meus teclados, o "." está logo ali e o "(" e ")" estão logo ali à distância dum shift. Mas os "[" e "]" só são acessíveis com um AltGr. Sim, eu sou um pouco OCD com estas cenas, mas que é um aborrecimento usar parêntesis rectos, é! Além de tornar o código menos legível se quiseres colocar uma funcão dentro de outra.

Isto para não falar do @...

De resto, e para ser justo relativamente ao Java, desenhar um interface gráfico é com uma perna às costas enquanto que no Java é algo muito parecido a um Sexta-Feira 13, mas sem muitos mortos. Se bem que, no android os objectos gráficos são definidos num ficheiro XML... o que pode tornar as coisas melhores, mas menos dinâmicas.

Quando sair o novo tablet da Samsung e/ou um que seja remotamente refinado como o iPad a um preco melhor (por favor, não confirmes a minha previsão de "nunca") digo-te alguma coisa. 


include <ai se te avio>

Mãe () {

}

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

window.addNewControlWithTitle(@"Title", xPosition:20, yPosition:50, width:100, height:50, drawingNow:YES);

Não seria um pouco melhor?

É que nos meus teclados, o "." está logo ali e o "(" e ")" estão logo ali à distância dum shift. Mas os "[" e "]" só são acessíveis com um AltGr. Sim, eu sou um pouco OCD com estas cenas, mas que é um aborrecimento usar parêntesis rectos, é! Além de tornar o código menos legível se quiseres colocar uma funcão dentro de outra.

Isto para não falar do @...

Shift + 8 vs Alt + 8? Quando postas no forum não costumas meter BBCode? Está cheio de parêntesis rectos. Eu até acho que a distância do Alt ao 8 e ao 9 é mais pequena que do Shift. No Windows é que o funcionamento do Alt é diferenciado, no Mac OS X isso não acontece (um Alt é um Alt, não há AltGr).

E o nome do método não é addNewControlWithTitle. É addNewControlWithTitle:xPosition:yPosition:width:height:drawingNow:. Facilita a leitura e inserção de variáveis num método, visto que cada uma das variáveis está descrita no nome da função com um placeholder apropriado. Nas outras linguagens, a notação "mais normal" de colocar todas as variáveis à balda dentro de parêntesis não me parece que se possa considerar legível. Obriga a que uma pessoa vá espreitar a declaração da função que, muitas vezes, está noutro ficheiro.

E não estou a ver porque achas que usar [] em vez de () torna o código menos legível. Se calhar também considerarias o Lisp muito pouco legível (se bem que depende de como a pessoa estrutura o código), e está cheio de (). A única diferença é que todos os níveis de código em Lisp são iniciados e teminados com (), enquanto que em Objective-C, os [] servem apenas para chamar um método de um objecto.

O @"" serve para distinguir as C strings das NSStrings da Foundation framework do Objective-C. A dot syntax no Objective-C serve para gets e sets de variáveis, contrariando a utilização "mais normal" de outras linguagens que a utilizam para chamar métodos de objectos.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bubulindo

Não usei Lisp...

Agora estou a pensar e são os parentesis rectos com o Alt e as chavetas com o ALT+Shift ou é ao contrário?

Quanto ao nome do método, tem calma. O que escrevi não é C, nem C++, nem Objective-C, nem Java... é apenas o que eu gostaria de ver em Objective-C, e como tal, a minha forma está correcta já que fui eu que a inventei. LOLOL Apenas queria dar um exemplo do que acharia mais confortável e legível aos meus olhos.

Concordo com o nome das variáveis na chamada da funcão, mas com o XCode, torna-se redundante e tens na mesma de ir ver quais os parâmetros que a funcão leva quanto mais não seja para os escreveres inicialmente. Ao fazer troubleshooting do código consegues é perceber o que cada parâmetro é sem teres de ver a definicão. Enfim, pormenores...

Quanto ao @, o compilador não podia distinguir por ele o que é uma C string do que é uma NSString? Eu tou a falar, mas é apenas o que acho sem ter mexido extensamente no XCode. Só segui uns tutoriais, alterei um programa para portas séries para fazer mais umas coisitas e comecar com definicões diferentes e ficou-se por aí.

Mas pelo menos agora já sei com quem falar quando me deparar com problemas nalguma coisa que faca. ;)


include <ai se te avio>

Mãe () {

}

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
KTachyon

Não usei Lisp...

Agora estou a pensar e são os parentesis rectos com o Alt e as chavetas com o ALT+Shift ou é ao contrário?

Pelo menos aqui é alt para [], alt+shift para {}. Nos teclados de programador (pelo menos num que já tive), o normal é haver uma tecla para fazer cada um dos parêntesis rectos e, com shift, as chavetas ;)

Quanto ao nome do método, tem calma. O que escrevi não é C, nem C++, nem Objective-C, nem Java... é apenas o que eu gostaria de ver em Objective-C, e como tal, a minha forma está correcta já que fui eu que a inventei. LOLOL Apenas queria dar um exemplo do que acharia mais confortável e legível aos meus olhos.

Sim, eu percebi, mas a questão é que nada te impede de colocares  /* comments */ para indicares qual é a função da variável. Só que para além de se poder tornar feio, isso não é "reforçado", ao contrário do Objective-C.

Por outro lado, também ninguém te impede de declarares métodos em Objective-C sem colocares os nomes. Apenas colocando : entre cada variável (em vez de vírgulas). Mas como ninguém o faz e a linguagem não o torna óbvio, ninguém faz isso. É segredo, não digam a ninguém :)

Concordo com o nome das variáveis na chamada da funcão, mas com o XCode, torna-se redundante e tens na mesma de ir ver quais os parâmetros que a funcão leva quanto mais não seja para os escreveres inicialmente. Ao fazer troubleshooting do código consegues é perceber o que cada parâmetro é sem teres de ver a definicão. Enfim, pormenores...

Nem por isso. A questão é que, quando o XCode te faz o auto-complete da função, coloca-te também os placeholders para as variáveis com a indicação do tipo. A única questão é se o nome da função não for exactamente fácil de interpretar, mas para isso é sempre necessário ir ler a documentação em qualquer caso :)

Quanto ao @, o compilador não podia distinguir por ele o que é uma C string do que é uma NSString? Eu tou a falar, mas é apenas o que acho sem ter mexido extensamente no XCode. Só segui uns tutoriais, alterei um programa para portas séries para fazer mais umas coisitas e comecar com definicões diferentes e ficou-se por aí.

O @ é utilizado em várias partes do código. É raro desenvolver código em Objective-C em que em qualquer ficheiro não hajam pelo menos 3 @. Tens o interface e a implementação (ficheiros .h e .m, respectivamente), que começam com @interface e @implementation e acabam com @end. Tens @property para definires o modo de operação dos gets e sets genéricos das variáveis de um objecto, o @synthesize para mandares gerar os gets e sets para essas variáveis, tens o @selector para executares uma função by name...

De qualquer forma, é um Alt+2. Tudo bem que uma NSString obriga a, pelo menos 3 keystrokes (@"") e vindo de outras linguagens pode levar a erros, mas é uma questão de hábito, e o XCode ajuda muito, colocando warnings e propondo correcções enquanto se desenvolve o código. E, ninguém te obriga a utilizar NSStrings. Se te sentires mais à vontade com C strings também podes utilizar, bem como qualquer função em C. Quando se programa em Cocoa, apenas é necessário que os controladores e o app delegate sejam desenvolvidos em Objective-C. De resto pode ser tudo C (e C++) all the way.


“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bubulindo

O @ é utilizado em várias partes do código. É raro desenvolver código em Objective-C em que em qualquer ficheiro não hajam pelo menos 3 @. Tens o interface e a implementação (ficheiros .h e .m, respectivamente), que começam com @interface e @implementation e acabam com @end. Tens @property para definires o modo de operação dos gets e sets genéricos das variáveis de um objecto, o @synthesize para mandares gerar os gets e sets para essas variáveis, tens o @selector para executares uma função by name...

Referia-me apenas aos @ das Strings.

De qualquer forma, é um Alt+2. Tudo bem que uma NSString obriga a, pelo menos 3 keystrokes (@"")

Gostei da análiste teclistíca... LOL

Nem acredito que estão a discutir isto..  ;)

É a discussão entre FDB e STL transposta para o Mundo das linguagens de alto-nível. LOL


include <ai se te avio>

Mãe () {

}

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.