Linguagem Objective-c – Noções Básicas
A linguagem Objective-C, nasceu na empresa NeXT antiga empresa criada pelo Steve Jobs quando este saiu da Apple. Quando em 1996 a Apple compra a empresa NeXT começa a desenvolver então na linguagem Objective-C.
Esta linguagem é orientada a objectos, é uma extensão à linguagem C e case-sensitive.
Há dois tipos de ficheiros em objective-c o ficheiro .h (interface) e o ficheiro source o ficheiro .m.
Header file (.h)
No ficheiro .h inicia-se com o @interface seguido do nome da classe e do nome da classe Pai. Como mostra a figura, declaramos os tipos das variáveis e os nomes e no final declaramos os métodos da nossa classe.
Como podemos ver na figura, temos duas diferenças na declaração dos metodos, o primeiro metodo inicia-se com o sinal de “-” e o segundo metodo inicia-se com o sinal de “+”, o que quer dizer que os metodos inicializados com o sinal de “-” são metodos da instancia e metodos inicializados com o sinal de “+” são metodos da classe.
Métodos:
Os metodos em obj-c declaram-se da seguinte maneira:
Mais detalhadamente, como já foi referido acima, o “Method type Identifier” é o sinal de “-” ou o sinal de “+”. O tipo de retorno da nossa função.
As keywords são como o nome diz as keywords que irão aparecer quando chamarmos o nosso metodo para seguido do sinal de “:” indicarmos qual o objecto a mandar por parametro.
O “Parameter type” é o tipo da variavel esperada para a keyword e o “Parameter names” são os nomes depois que vão ser utilizados para manipular mos os dados quando formos programar no ficheiro .m o que vai fazer o nosso metodo, processo semelhante ao Java.
Propriedades:
As propriedades são utilizadas para substituir os metodos de acesso as váriaveis, ou seja, declaramos uma variavel e ele automáticamente cria os getters e os setters para ir buscar os valores das variaveis e atribuir valores as variaveis, se assim o quisermos.
Exemplo da uma declaração de uma propriedade:
@property (readonly) UIView *rootView; // Declare only a getter method. |
As propriedades permitem definir o tipo de acesso a váriavel, a duração da variavel em memória.
Como podemos ver no exemplo, a variavel é readonly, ou seja, só vai ser construido automáticamente o getter à variavel para se conseguir ir buscar os dados do objeto.
Os outros tipos de parametros para o property são:
Em ARC (Automatic Reference Counting)
- strong / weak : Duração da variavel em memória;
- readwrite/readonly: Escrita e leitura da variavel ou só leitura da variavel;
- nonatomic / atomic.
Sem ARC:
- retain / assign.
No ficheiro .m para aceder a propriedade utiliza-se o @synthesize.
Utilizando o exemplo acima, no nosso ficheiro .m, só teriamos que escrever @synthesize rootView;
Gestão de memória:
A gestão de memória em objective-c pode ser feita de duas maneiras, através do ARC (Automatic Reference Counting), em que o utilizador não necessita de se preocupar com a gestão de variaveis instanciadas ou então atraves de MMR (“Manual Retain-Release) em que neste caso o utilizador tem que fazer “release” das variaveis que já não necessita para não estarem a ocupar espaço em memória.
Exemplo de uma classe:
@implementation MyClass - (id)initWithString:(NSString *)aName { self = [super init]; if (self) { name = [aName copy]; } return self; } + (MyClass *)createMyClassWithString: (NSString *)aName { return [[[self alloc] initWithString:aName] autorelease]; } @end |
Referências: Learning Objective-C: A Primer
Este artigo tem mais de um ano
Boas,
e quando se deve usar um método de gestão de memória vs o outro?
Tu é que escolhes. Mas por exemplo, queres fazer uma aplicação que suporte iOS inferior a 4.2, não podes usar ARC.
:S
Podes usar o ARC, não tens é o ARC a funcionar como é descrito aqui!
Mas pergunto, quem é que vai fazer uma aplicação nova no iOS para suportar a versão 4.2 ou anterior – é menos de 5% da plataforma? Isto não é o Android que precisa de manter o suporte para um SO com mais de 2 anos por ser a maioria da base instalada!
Penso que programar para iOS é “obrigatório” fazer uma MMR (Manual Retain-Release), uma vez que o sistema não o faz sozinho. Uma má gestão da memória na programação pode ser um dos motivos que leve à não aprovação da apps na App Store.
No Mac OS, o próprio sistema faz a gestão da memória, não sendo por isso obrigatória a MMR.
ARC is supported in Xcode 4.2 for OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in OS X v10.6 and iOS 4.
fonte: http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html
Pois, não sabia.
Quando li o livro de Objective-C o iOS ainda devia ir na versão 3 ou 4.
Desde a versão 5 do iOS há suporte completo para o ARC, de modo que não é “obrigatório” fazer MRR – só quem queira fazer uma optimização “extraordinária” é que necessita de enveredar por esse caminho!
Não tenho muita experiência, mas tal vai depender do que estás a fazer! Podes usar os dois métodos ao mesmo tempo e há circunstâncias em que o ARC não funciona e outras em que é conveniente fazer manualmente
http://www.informit.com/articles/article.aspx?p=1829415&seqNum=7
Ideia bastante interessante, a de terem uma espécie de rubrica sobre programação iOS. Gostei 😉
Não é só programação para iOS 😉
É.
Mac OS X também.
Muito bom artigo!
Era muito interessante ter tutoriais para objective-c. À imagem de outros aqui no forum onde se começa a construir exemplos básicos e depois cabe a cada um aprofundar mais ou menos o tema.
Se conhecerem alguns tutoriais para objective-c bons e que queiram disponibilizar agradecia imenso.
Cumps
Antes de maisbobrigado pela iniciativa ao pplware.
Sobre tutoriais sobre Objective-C aconselho o uso do iTunes U onde existe um tutorial, a meu ver excepcional, da universidade de Stanford (se nao estou enganado o Professor trabalhou na Apple)
Cumprimentos, BV
Boas, essas aulas são brutais para que está a aprender.
Que Ide usar ?
So existe 1 ide possivel para programar para Objective-C. Precisas do Xcode que so corre no MacOS.
Resumindo so com um computador MAC é que consegues programar para iOS ou para MacOS.
Cumprimentos
Não é bem assim!
Tens outro IDE que te permite programar para Mac ou iOS em Objective-C – JetBrains AppCode – embora o Xcode seja sempre necessário nalgum ponto do projecto!
Há outros IDE para Objective-C noutros sistemas, mas não creio que suportem programação para Mac e iOS.
Não tenho MacOS logo não me serve de muito… 🙁
Peço desculpas: Extenção ou extensão?
strong / weak : Duração da variavel em memória;
Isto é dúbio. Uma property do tipo strong, mantêm uma relação a um objecto, mesmo que ele cesse de existir. Enquanto que do tipo weak, fará com que a relação seja nil, após o objecto que referenciamos deixe de existir. Mais, já não é necessário @synthesize no ficheiro .m.
Olá R.Peres. Podes dar umas dicas sobre iOS?
Cumps
Viva Filipe, podes seguir o meu blog por exemplo codeplease[dot]wordpress[dot]com. Ou então podes-me encontrar no stackoverflow aqui => http://stackoverflow.com/users/491239/jacky-boy
mas…
strong…
se o objecto já não existe o teu ponteiro aponta para onde??
sera’essa referencia algo identica aquilo que o java faz com o garbage colector??
cmps
a referência é semelhante na classificação, mas isto não tem nada de parecido com um garbage collector.
Com o ARC o IDE vai completar o teu código como se tivesse uma gestão manual de memória. Não há nenhum processo extra a gerir a memória do programa!
mas…
depois de saires do ide…ou seja quando correres a aplicação directamente. alguém tem que gerir a memoria…
Nessa altura quem toma conta dos objectos que ja não existem/não são necessarios?
cmps
Não há nada extra a gerir o espaço de memória do programa – por este método – fica tal como em gestão manual com “reference count”. Ao compilar o código são inseridas as instruções necessárias para manter ou libertar “objectos”, optimizado para o que foi escrito. São necessários alguns cuidados, mas liberta o programador desta tarefa. De certa maneira fica com o melhor dos dois mundos – numa visão simplista!
Boas…
Não sei se percebi…mas o IDE faz a gestão da memoria do programa…e quando compilas o programa ele mete lá o codigo extra para a gestão da memoria da Aplicação…é isso??
Se for é fantastico.
Obrigado pela info 😉
cmps
sim! creio que podes descrever mais ou menos desse modo, é sempre pelo compilador que a coisa funciona – a Apple investiu bastante no LLVM.
Pode dar mais algum trabalho que o garbage collection, mas de uma maneira geral dará melhor gestão da memória com a vantagem do comportamento do programa ser muito mais previsível, o que poderá facilitar no debugging.
Não, ARC funciona de maneira diferente. Tens que ter cuidado com o que fazes (circular referencing for example). Se o objecto original desapareceu e o segundo objecto existe, como é strong, vai continuar a existir.
Esta linguagem é muito usada? Parece ser mais complicada do que o C e C++.
E que tal uns tutoriais sobre Python?
estás no gozo, certo? é linguagem preferida para MacOS X, iOS
usado na construcao de programas para dispositivos ios e osx
se souberes trabalhar em c tambem possii suporte alias,e alfo que ando ultimamente interessado,a dica em relacao a python merece tambem meu apoio pois e ima linguagem muito interesante
cumprimentos
mais complicada não C sem duvida, mais complicada que C++ não sei, mas…é sem duvida diferente daquilo a que programadores de aplicações estavam habituados…
cmps
Tendo aprendido a programar em Java e C sempre achei que o Objective-C fosse uma linguagem inventada por macacos numa trip de ácido, a syntax disso é horrível. Mas enfim, dada a popularidade do iOS é algo que uma pessoa tem que engolir, calar e aprender.
Mas bom artigo!
Concordo!!
O Java é posterior ao Objective-C, donde foi buscar alguma inspiração! O Objective-C tem várias vantagens sobre o Java, pois vai além de ser só uma linguagem por objectos, e isso vê-se facilmente na diferença de performance em aplicações optimizadas com ambas as linguagens!
Não se trata de “vai para além de ser só uma linguagem por objectos”… Objective-c é uma linguagem que acrescenta Smalltalk-style messaging a C, daí conseguires tirar mais performance comparativamente a Java.
é basicamente o que queria dizer fazendo um contraponto com a natureza do Java!
Dás-te conta que isso é por causa da virtual machine, certo? experimenta tentar portar objective-c para outros sistemas sem teres de recompilar…
O ganho de performance advém do nível de optimização que é possível por ser uma linguagem, tal como o R. Peres comentou, “construída em cima” da linguagem C. Com o Objective-C facilmente se usa código em C ou mesmo C++, e sim, não se tem a desvantagem de correr numa “virtual machine”.
Quanto a portar para outros sistemas, se o teu interesse for só uma plataforma é preferível usar a linguagem preferida dessa plataforma, não? Para além de que o Java necessita duma VM bem oleada para cada plataforma alvo. Aliás esse argumento, neste momento, nem faz grande sentido, pois grande parte das ferramentas capazes de criar código para as diversas plataformas móveis não usam a linguagem Java!
Correcto, passa pelo html/css/javascript. É o futuro, apesar de estar ainda verde a capacidade de criar algo que verdadeiramente aceite tudo.
E para todos os efeitos o java é lento, tem uma VM horrível (comparando por exemplo com a do .NET) mas suporta várias plataformas, é free, é isto, é aquilo e devia falcer.
Mas ainda vai ficar por enquanto, isso garanto 😉
Precisamente porque é free, et cetera e et cetera. Mas acima de tudo: é fácil, é minimamente intuitivo e qualquer pessoa se lança nisso sem grandes pré-requisitos e não tem de aprender uma sintaxe (atenção que nem estou a falar de linguagem, mas sim de sintaxe) completamente diferente de tudo o que alguma vez conheceu.
E com todo o mal que o java tem, há que admitir: isso importa.
É uma parte do futuro. Não vai haver uma linguagem ou modelo a dominar os outros, é essa a tendência actual – há cada vez mais variedade de linguagens e soluções – embora se note que se aposta mais em maiores níveis de abstracção.
Mas o engraçado é que os sistemas móveis vieram mostrar as fragilidades de maiores níveis de abstracção já implementados, daí a Apple ter tido vantagem com o uso do Objective-C
“sempre achei que o Objective-C fosse uma linguagem inventada por macacos numa trip de ácido”
Mil internetes para ti! 😀
Excelente iniciativa! Venham mais tutoriais sobre iOS 😀
Gostei muito do tópico, podiam também falar um pouco do ide que é utilizado para isso.
sempre achei a sintaxe do Objective C muito feia. É de muito dificil leitura.
Penso que este não é o nome mais correcto: “o ficheiro .h (interface)” é melhor chamares de Header como fazes depois.
O ficheiro .h não contem só a Interface, imagina que a tua classe tem protocols.
Vais ter o @interface mas tambem o @protocol.
Se bem que ha que prefira criar os protocols em ficheiros separadas, mas mesmo separados continuam a ser ficheiros .h.
Em relação às propriedades:
“readwrite/readonly: Escrita e leitura da variavel ou só leitura da variavel;
nonatomic / atomic.”
Estes parametros também funcionam sem ARC!!
A linguagem Objective-C não nasceu nem foi inventada na NeXT. Foi criada nos anos 80. No entanto foi popularizado pela NeXT do falecido Jobs.
O Objective-C foi pensado para ser lido como um bloco de texto e não interpretado. Opiniões à parte, é dess ideia que provêm nomes grandes como textFieldShoudReturn ou cellForRowAtIndexPath (e estes são pequenos). Felizmente o Xcode fornece suporte para autocomplete, senão seria complicado.
Na empresa onde trabalho todas as nossas aplicações para iOS (incluindo iOS 5 e 6) são feitas sem recurso ao ARC ou ao Interface Builder.
Dessa forma conseguimos ter todo o controlo da aplicação. Não é que haja algum problema com o interface builder, mas o storyboard é um pedaço inserido no XCode que ajuda muita gente a iniciar o desenvolvimento (bem como o ARC), mas que atrapalha o desenvolvimento quando queremos saber como resolver problemas de memória. É um bocado mais minucioso, mas acho que a metodologia acaba sempre por compensar.
Sou o designer das aplicações, portanto até deveria ser eu a promover (e tentei) o uso de interfaces visuais para a construção das vistas, mas acabei também eu por admitir que se consegue um melhor desempenho na versão manual.
Gostei muito desta análise, eu estou neste momento a desenvolver uma aplicação para o meu projecto final de licenciatura de eng. informática, e vi-me “obrigado” a usar o storyboard e o ARC por uma questão de tempo. Acho que para quem vem de outras linguagems (Java, C++, C#..) é complicado chegar a objective-c e manusear todo o desempenho a nível de memória manualmente.
Agora a minha dúvida, a minha app é para ser comercial e não só para propósitos académicos, eu num futuro poderei optimizar a app mesmo estando toda construida de raiz com o ARC e a Interface Builder?
Obrigado pelo comentário, gostei mesmo de ler uma opinião mais profissional sobre este assunto.
Não percebo porquê evitar o ARC! É sempre possível usar os dois modelos no mesmo projecto, caso o ARC dê algum problema com alguma parte do código, por este ou aquele motivo.
Boas
Estou a tentar dar os primeiros passos no Objective C, mas o meu mac só suporta o X code 3.2 .
Pois o meu mac não suporta o OXS Lion Mountain.
Devo de começar pelo X code 3.2 ou o mais avançado. Exisre muitas diferenças?
Obrigado
Boas, a 2ª e 3ª imagens estão com erro.
Obrigado pelo reparo. Já está corrigido !