Quantcast
PplWare Mobile

Linguagem Objective-c – Noções Básicas

                                    
                                

Este artigo tem mais de um ano


Autor: Edgar Clérigo


  1. António Mendes says:

    Boas,

    e quando se deve usar um método de gestão de memória vs o outro?

  2. Porreiro says:

    Ideia bastante interessante, a de terem uma espécie de rubrica sobre programação iOS. Gostei 😉

  3. Fernando Silva says:

    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

    • BV says:

      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

    • Daniel says:

      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

      • eduardo says:

        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.

      • Rui says:

        Não tenho MacOS logo não me serve de muito… 🙁

  4. Ricardo says:

    Peço desculpas: Extenção ou extensão?

  5. R. Peres says:

    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.

    • Filipe says:

      Olá R.Peres. Podes dar umas dicas sobre iOS?

      Cumps

    • lmx says:

      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

      • eduardo says:

        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!

        • lmx says:

          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

          • eduardo says:

            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!

          • lmx says:

            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

          • eduardo says:

            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.

      • R. Peres says:

        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.

  6. ZiLOG says:

    Esta linguagem é muito usada? Parece ser mais complicada do que o C e C++.

    E que tal uns tutoriais sobre Python?

    • eduardo says:

      estás no gozo, certo? é linguagem preferida para MacOS X, iOS

    • Hugo Clio says:

      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

    • lmx says:

      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

  7. João C. says:

    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!

    • eduardo says:

      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!

      • R. Peres says:

        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.

      • Joel Fernandes says:

        Dás-te conta que isso é por causa da virtual machine, certo? experimenta tentar portar objective-c para outros sistemas sem teres de recompilar…

        • eduardo says:

          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!

          • Joel Fernandes says:

            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.

          • eduardo says:

            É 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

    • Joel Fernandes says:

      “sempre achei que o Objective-C fosse uma linguagem inventada por macacos numa trip de ácido”

      Mil internetes para ti! 😀

  8. Filipe says:

    Excelente iniciativa! Venham mais tutoriais sobre iOS 😀

  9. Deus says:

    Gostei muito do tópico, podiam também falar um pouco do ide que é utilizado para isso.

  10. Sergio J says:

    sempre achei a sintaxe do Objective C muito feia. É de muito dificil leitura.

  11. RRtuga says:

    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.

  12. Tiago Ribeiro says:

    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!!

  13. Tripov says:

    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.

  14. João Dias says:

    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.

    • eduardo says:

      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.

  15. Ruben says:

    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

  16. José Carlos Reis says:

    Boas, a 2ª e 3ª imagens estão com erro.

Deixe uma resposta

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.