Arquivo Discussoes de Programacao e Tecnologia Esse mês estarei comprando um mac air, e estou em dúvida se vale a pena
aprender a linguagem objective c da apple, junto com seu framework cocoa.
Alguém do guj poderia dizer como anda o mercado de objective c no brasil ?
se tem vagas ? a curva de aprendizado é a mesma do java ?
Eu não me arrependo nem um pouco em ter estudado Objective-C, pois mais que possa parecer que tenha uma syntax estranha e tudo mais, é uma linguagem bacana, eu gosto.
O mercado mundial de apps para iOS é grande e bem diversificado, e ainda teria a possibilidade de aplicativos nativos pra Mac, mas que tem demanda bem menor.
Em São Paulo pelo menos sempre tem vaga pra iOS developer, e se tem trabalhos remotos tbm, como freela ou não.
Se vc já sabe java, tem uma noção de C/C++, não terá dificuldade em aprender não.
[]s
acho que sim! só pelo fato de você poder programar para iOS já é um ganho, pois pode desenvolver suas aplicações e comercializá-las pela App Store - Quanto a linguagem me parece que ela é mais próxima de C ou C++ e a curva de aprendizado acho que é igual para todas as linguagens
Boa Sorte!
Esse mês estarei comprando um mac air, e estou em dúvida se vale a pena
aprender a linguagem objective c da apple, junto com seu framework cocoa.
A verdade é que não. Vc disse tudo é da apple.
A menos que você esteja planejando um negocio em cima do hardware e os da apple, esqueça.
E mesmo assim existem outras opções como o Mono (C#.net) que roda em Ios
Acho que vale a pena. Para desenvolvedores a appstore pode ser bem lucrativa.
Esse mês estarei comprando um mac air, e estou em dúvida se vale a pena
aprender a linguagem objective c da apple, junto com seu framework cocoa.
A verdade é que não. Vc disse tudo é da apple.
A menos que você esteja planejando um negocio em cima do hardware e os da apple, esqueça.
E mesmo assim existem outras opções como o Mono (C#.net) que roda em Ios
Esse mês estarei comprando um mac air, e estou em dúvida se vale a pena
aprender a linguagem objective c da apple, junto com seu framework cocoa.
A verdade é que não. Vc disse tudo é da apple.
A menos que você esteja planejando um negocio em cima do hardware e os da apple, esqueça.
E mesmo assim existem outras opções como o Mono (C#.net) que roda em Ios
E C# não é praticamente todo ligado ao Windows e a M$?
Não. Isso é um “missconception”. A M$ influencia bastante, mas não é dona do C#. O C# , assim como o javascript são um padrão ECMA.
O Mono não é da M$ e eles estão abrindo uma frente muito interessante que a M$ não enxergou: multiplataforma.
Sim, aprender é muito bom, mas estudar objective-c durante meses para fazer 1 app não compensa. Porque se vc não quiser fazer apps, tá na roça. Se vc aprender C# pelo menos tem mais para onde ir se os apps não derem certo. É uma questão de economia e opções e não e é bom e bonito aprender.
Claro, se o cara já decidiu que irá devotar sua vida à apple, ai sim vale a pena. Mas para aprender só por aprender, então é melhor aprender algo mais útil e mais abrangente e com mais saida. Senão estavamos todos aprendendo assembler just for fun.
particularmente considero que empatados em primeiro lugar eu colocaria em importância java e c#.
em seguida eu colocaria a importância empatada também entre objetive c e android.
Nessa ordem por que os dois primeiros são para agora e os outros dois são para o futuro relativamente próximo.
entre as que eu falei, considero empatadas por que acredito que entre java ou c# e entre objetive c e android, depende do gosto pessoal de cada um (sei que ios não é só no dispositivo móvel). O meu gosto pessoal entre os empatados fica na ordem que falei…rs
desta forma ainda acho mais interessante aprender c# do que objetive c ou android, mas claro que isso é só uma opinião minha.
Só vale investir se você tiver algum objetivo real em vista com isso, senão vá pra praia.
Se você é programador front-end e precisa de uma interface moderna e não aquela porcaria de javascript, sem dúvida deve aprender objective-c e seu framework cocoa. A boa notícia é que não é tão complicado.
Eu levei 1 semana pra fazer minha primeira app.
Não. Isso é um “missconception”. A M$ influencia bastante, mas não é dona do C#. O C# , assim como o javascript são um padrão ECMA.O Mono não é da M$ e eles estão abrindo uma frente muito interessante que a M$ não enxergou: multiplataforma.
Sim, aprender é muito bom, mas estudar objective-c durante meses para fazer 1 app não compensa. Porque se vc não quiser fazer apps, tá na roça. Se vc aprender C# pelo menos tem mais para onde ir se os apps não derem certo. É uma questão de economia e opções e não e é bom e bonito aprender.
Claro, se o cara já decidiu que irá devotar sua vida à apple, ai sim vale a pena. Mas para aprender só por aprender, então é melhor aprender algo mais útil e mais abrangente e com mais saida. Senão estavamos todos aprendendo assembler just for fun.
E porque a proposição de ser multiplaforma é interessante?
Não. Isso é um “missconception”. A M$ influencia bastante, mas não é dona do C#. O C# , assim como o javascript são um padrão ECMA.O Mono não é da M$ e eles estão abrindo uma frente muito interessante que a M$ não enxergou: multiplataforma.
Sim, aprender é muito bom, mas estudar objective-c durante meses para fazer 1 app não compensa. Porque se vc não quiser fazer apps, tá na roça. Se vc aprender C# pelo menos tem mais para onde ir se os apps não derem certo. É uma questão de economia e opções e não e é bom e bonito aprender.
Claro, se o cara já decidiu que irá devotar sua vida à apple, ai sim vale a pena. Mas para aprender só por aprender, então é melhor aprender algo mais útil e mais abrangente e com mais saida. Senão estavamos todos aprendendo assembler just for fun.
E porque a proposição de ser multiplaforma é interessante?
Por razões económicas. A cada base de código que vc tem que construir, é dinheiro que vc gasta. Se vc tem um produto, digamos um ERP, por exemplo, e digamos que é em java. ai o windows muda para uma interface que só pode ser feita com .net e não aceita java mais. Vc vai reescrever o ERP inteiro ? Mesmo que seja só o cliente, vc vai reescrever inteiro ? Vc pode, mas essa é a solução mais cara. Se vc simplesmente pudesse usar o codigo java que já tem e compilar em .net seria o ideial. Mais barato e não tem que programar nada de novo, logo, menos erros e bugs. A IKVM permite isto. Claro que não é tão simples como eu descrevi, mas é muito mais simples e rápido (2 dias máximo) do que escrever o cliente em .NET.
A multiplataforma é sempre uma vantagem. O Java mostrou isso. Só que a plataforma Java implementou uma linguagem e N targets de runtime. O .net implementou um target ( o windows) e N linguagens. Hoje é óbvio que o bom é N linguagens e M targets.
Mas ai vei o omobile, os pads da vida e todos quiserem forçar o seu modelo fechado (por causa das stores, que a M$ tb tem ono windows 8) E agora ? voltamos atrás nos anos 80 quando não existia multiplataforma ? E vamos aprender N linguagens diferentes ? Hoje isso não é mais um bom modelo económico. Por isso que coisas como o PhoneGap têm mercado. Claro, não resolve todos os problemas, mas resolver uma grande maioria deles, o suficiente para ser viável. O PhoneGap usa HTML5 e javascript, ou seja, o Brwoser já é uma plataforma que roda em cima de outra plataforma, então embora cada ambiente mobile seja diferente, todos têm um browser e isso é que permite realizar aplicações cross. E com o HTML , usar o canvas para fazer 3D é muito mais trivial que antes porque o html 5 comanda que o canvas tenha acesso nativo à GPU.
Levando este mesmo conceito para desktop e servidores, o objetivo é ter uma linguagem e uma API que possa ser compilada para qualquer plataforma. Aqui, plataforma significa :Plataforma fisica (OS) Plataforma Virtual (java, .net, ruby, python, etc…) e mesmo Browser. então se o seu ERP é construido nesta meta-plataforma que suporta todas as outras, a sua base de código não está em perigo e vc só tem que se preocupar em compilar esse mesmo código contra uma API padrão que é provida por um VM em cada uma dessas plataformas que falei, ou até mesmo com compilação nativa para essas plataformas (assembler para exe, byte-code para java, etc… ) . E o que as novas plataformas como Gosu, Fantom, etc, mostram é que é possível.
O único problema é que nem sempre as sintaxes das novas plataformas agradam e também ainda tem um questão de confiança. Será que eu aposto em criar meu codigo de ERP em Fantom ?
Hoje a resposta mais conservadora ainda é : vai para web, usa javascript e sê feliz. E ai entram outras opções como Draft que compilam para javascript. Porque para fazer aplicações complexas end-to-end em javascript é muito complicado. javascript tem herança e tudo isso, mas ser fracamente tipado atrapalha e não haver uns construtoros mais simples para criar a herança, tb.
Não é por acaso que as grandes estão apostanto em novas linguagens que oferecem novas plataformas. É porque é mais barato assim. Quem enxergar isso primeiro e se aproveitar disso primeiro, vai ganhar o mercado primeiro.
Se você é programador front-end e precisa de uma interface moderna e não aquela porcaria de javascript, sem dúvida deve aprender objective-c e seu framework cocoa. A boa notícia é que não é tão complicado.Eu levei 1 semana pra fazer minha primeira app.
Eu tenho algumas aplicações publicadas no google play e vou começar a publicar algumas na appstore. O google play dá bastante cliques em aplicações mais baratas. Na appstore o público já não se importa tanto então imagino ser mais rentável.
Além do mais é muito fácil escrever objective c como você mesmo postou aí.
Se quer desenvolver pra IOS vale a pena…
Eu prefiro bem mais Android pelo simples fato do custo beneficio ser bem melhor. Com o dinheiro investido em algo da apple da para comprar algo bem mais potente de outra marca (samsung por exemplo). Quem compra produtos da Apple acaba pagando mais pela marca do que pelo hardware e software propriamente dito…
Agora olhando o mercado dificilmente acho alguma vaga para desenvolver para IOS até mesmo para Android. Infelizmente no Brasil tem poucas empresas que investem em software para mobile…
Se quer desenvolver pra IOS vale a pena…
Eu prefiro bem mais Android pelo simples fato do custo beneficio ser bem melhor. Com o dinheiro investido em algo da apple da para comprar algo bem mais potente de outra marca (samsung por exemplo). Quem compra produtos da Apple acaba pagando mais pela marca do que pelo hardware e software propriamente dito…
Agora olhando o mercado dificilmente acho alguma vaga para desenvolver para IOS até mesmo para Android. Infelizmente no Brasil tem poucas empresas que investem em software para mobile…
Aqui tem bastante campo pra android. As empresas que desenvolvem hardware estão usando android embarcado. Um pequeno arm com todo os tipos de entradas e saídas.
Por razões económicas. A cada base de código que vc tem que construir, é dinheiro que vc gasta. Se vc tem um produto, digamos um ERP, por exemplo, e digamos que é em java. ai o windows muda para uma interface que só pode ser feita com .net e não aceita java mais. Vc vai reescrever o ERP inteiro ? Mesmo que seja só o cliente, vc vai reescrever inteiro ? Vc pode, mas essa é a solução mais cara. Se vc simplesmente pudesse usar o codigo java que já tem e compilar em .net seria o ideial. Mais barato e não tem que programar nada de novo, logo, menos erros e bugs. A IKVM permite isto. Claro que não é tão simples como eu descrevi, mas é muito mais simples e rápido (2 dias máximo) do que escrever o cliente em .NET.
Você pode rodar um programa Desktop nos pads da vida. Não quer dizer que seja uma boa idéia.
A multiplataforma é sempre uma vantagem. O Java mostrou isso. Só que a plataforma Java implementou uma linguagem e N targets de runtime. O .net implementou um target ( o windows) e N linguagens. Hoje é óbvio que o bom é N linguagens e M targets.Mas ai vei o omobile, os pads da vida e todos quiserem forçar o seu modelo fechado (por causa das stores, que a M$ tb tem ono windows 8) E agora ? voltamos atrás nos anos 80 quando não existia multiplataforma ? E vamos aprender N linguagens diferentes ? Hoje isso não é mais um bom modelo económico. Por isso que coisas como o PhoneGap têm mercado. Claro, não resolve todos os problemas, mas resolver uma grande maioria deles, o suficiente para ser viável. O PhoneGap usa HTML5 e javascript, ou seja, o Brwoser já é uma plataforma que roda em cima de outra plataforma, então embora cada ambiente mobile seja diferente, todos têm um browser e isso é que permite realizar aplicações cross. E com o HTML , usar o canvas para fazer 3D é muito mais trivial que antes porque o html 5 comanda que o canvas tenha acesso nativo à GPU.
Levando este mesmo conceito para desktop e servidores, o objetivo é ter uma linguagem e uma API que possa ser compilada para qualquer plataforma. Aqui, plataforma significa :Plataforma fisica (OS) Plataforma Virtual (java, .net, ruby, python, etc…) e mesmo Browser. então se o seu ERP é construido nesta meta-plataforma que suporta todas as outras, a sua base de código não está em perigo e vc só tem que se preocupar em compilar esse mesmo código contra uma API padrão que é provida por um VM em cada uma dessas plataformas que falei, ou até mesmo com compilação nativa para essas plataformas (assembler para exe, byte-code para java, etc… ) . E o que as novas plataformas como Gosu, Fantom, etc, mostram é que é possível.O único problema é que nem sempre as sintaxes das novas plataformas agradam e também ainda tem um questão de confiança. Será que eu aposto em criar meu codigo de ERP em Fantom ?
Eu não culpo as pessoas por desconfiarem de soluções como phonegap, e outros que se dizem multiplataforma.
Se nem mesmo gigantes como google, apple e ms conseguiram unificar suas próprias plataformas em torno de uma “metaplataforma” (ChromeOS e Android, OSX e iOS, Windows 8 e Windows 8 RT, todos existem como plataformas distintas), qual a chance dos programadores Mono conseguirem? :lol:
Hoje a resposta mais conservadora ainda é : vai para web, usa javascript e sê feliz. E ai entram outras opções como Draft que compilam para javascript. Porque para fazer aplicações complexas end-to-end em javascript é muito complicado. javascript tem herança e tudo isso, mas ser fracamente tipado atrapalha e não haver uns construtoros mais simples para criar a herança, tb.
Acho que não existe uma resposta padrão, depende do tipo de aplicação.
Se for algo simples e sem muita sofisticação ainda vai, mas qualquer coisa que requer processamento mais intensivo (ou que precisa acessar recursos do aparelho) JavaScript ou Java não tem nenhuma chance. Nesse caso nativo é o único caminho.
Não é por acaso que as grandes estão apostanto em novas linguagens que oferecem novas plataformas. É porque é mais barato assim. Quem enxergar isso primeiro e se aproveitar disso primeiro, vai ganhar o mercado primeiro.
A não ser o Facebook que tentou fazer isso e quebrou a cara.
A não ser o Facebook que tentou fazer isso e quebrou a cara.
Tem um texto dele falando que se arrependeu de fazer a aplicação do facebook como sistema híbrido. A melhor alternativa sempre seria nativo de plataforma.
A não ser o Facebook que tentou fazer isso e quebrou a cara.Tem um texto dele falando que se arrependeu de fazer a aplicação do facebook como sistema híbrido. A melhor alternativa sempre seria nativo de plataforma.
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?
Facebook não ganha dinheiro quando programadores compilam código mais rápido.
Tudo depende do caso mesmo, mas nunca passei por um caso de ter a necessidade de ser nativo. O maior erro é fazer algo nativo sem necessidade.
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?Facebook não ganha dinheiro quando programadores compilam código mais rápido.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/
Tudo depende do caso mesmo, mas nunca passei por um caso de ter a necessidade de ser nativo. O maior erro é fazer algo nativo sem necessidade.
Sim, do ponto de vista do esforço do programador. Mas do ponto de vista do Facebook foi ter achado que não era necessário fazer nativo.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/
Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.
Não sei se o corte é assim tão limpo e as gigantes não estão correndo atrás.
O Dart é uma unificação para toda a parte Web do google e muitos dos aplicativos do Google (como o Google+) é feito com Dart. É meio que obvio que não é possivel criar uma aplicação rica com as do google com javascript puro e nem com jquery. É preciso mais. Certo que o Dart não roda no android, como disse antes, as metaplataformas são uma coisa nova que ainda está sendo explorada. Contudo o GWT que compila para javascript e o Dart que compila para javascript e a V8 do crome sendo a melhor VM de ajavascript , fala muito sobre o Google. Para eles o que interessa é o browser e não é por acaso que tudo acaba em javascript. Inclusive o android tem uma component de browser que roda javascript. A integração está lá.
A microsoft tem o .net. O Windows 8 é suporto ser o mesmo para qualquer plataforma, mas com dois modos de operação. Pelo menos a plataforma de dev é a mesma : .net
A Apple aposta no objective-c ou melhor no Xcode, que é um IDE completo tanto para ios como OSX.
Cada uma dentro de casa adota uma politica que no fim se resume a unificar. O ponto é que nenhuma delas tem interesse em que haja uma meta-plataforma que permite às pessoas serem independentes deles. É a volta ao antigo bordão “o codigo é meu, se queres copilar, usa as minhas ferramentas”. E por isso que o java sofre , em certa medida o flash também. Porque eles sempre foram “roda em qualquer coisa”. Mas agora, os grandes não querem mais se preocupar com isso. E querem as pessoas se fidelizem. Ou seja, se vc aprende .net é para microsoft e pronto. A microsoft não está interessada em correr .net no linux, quanto mais no OSX e assim vai.
Mas quem não pertence nas grandes precisa do mesmo fator de economia que as grandes utilizam. Por isso começam a surgir cada vez mais meta-plataformas. Mas o negocio ainda não está afinado. Esta batalha foi ganha pelos nativos, mas a guerra ainda não acabou. Um outro ramo que também gerou algum incentivo foi o ramo financeiro e cientifico em geral. Com experiencias como as do cern com baldes e baldes de dados avuslsos é preciso alguma coisa que seja eficiente em termos de performance e moldável em termos de modelo de dados para dar vazão a essas analises - o famoso big data. Então aparece o NoSQL e linguagens como scala que trazem paradigmas diferentes para resolver problemas novos. Este é um problema com que as grandes não lidam e nem têm mercado, mas tem muita gente ai precisando.
Fora do mobile e como plataformas Java e .NET não deixam espaço para ninguém neste momento. E é muito interessante olhas a historia destas plataformas e como as escolhas foram feitas e aconteceu a evolução.
Mas ai vemos um monte de linguagens tentado rodar nestas plataformas. Scala sendo a mais relevante no momento. Mas para R e Python têm alguma coisa a dizer ainda e quando ha calculos envolvidos cai-se muitas vezes no .net + python , por exemplo.
Nos mobiles ainda temos - tirando os esquemas tipo PhoneGap - o nativo comandando. Mas acho que não é assim tão relevante para a industria como um todo, pois para cada App existe um server e esse server não corre em android nem OSX. Corre em java ou .net qual alguma linguagem Z que nem importa muito, porque no servidor o que mais importa é o framework. Pode até ser um Rails… O que quero dizer com isto, é que não serão as linguagens mobile que irão mudar o mundo. Pelo menos enquanto essa mesma linguagem não existir fora do mobile. O JME 3 e O FX eram/são a aposta da Oracle para retomar os ganhos nesse mercado e eles estão chegando lá. Talvez quando isso for uma realidade ao alcance de qualquer um de nós, essa papo de ir para nativo vai mudar. É o mesmo que antes quando o pessoa dizia “se quer performance use C++ em vez de java”, hoje o java supera a performance do C++. Dizer hoje, vá para nativo porque o HTML 5 não dá performance é a mesma coisa.
Hoje a resposta mais conservadora ainda é : vai para web, usa javascript e sê feliz. E ai entram outras opções como Draft que compilam para javascript. Porque para fazer aplicações complexas end-to-end em javascript é muito complicado. javascript tem herança e tudo isso, mas ser fracamente tipado atrapalha e não haver uns construtoros mais simples para criar a herança, tb.
Acho que não existe uma resposta padrão, depende do tipo de aplicação.
Se for algo simples e sem muita sofisticação ainda vai, mas qualquer coisa que requer processamento mais intensivo (ou que precisa acessar recursos do aparelho) JavaScript ou Java não tem nenhuma chance. Nesse caso nativo é o único caminho.
Não é por acaso que as grandes estão apostanto em novas linguagens que oferecem novas plataformas. É porque é mais barato assim. Quem enxergar isso primeiro e se aproveitar disso primeiro, vai ganhar o mercado primeiro.
A não ser o Facebook que tentou fazer isso e quebrou a cara.[/quote]
É considerado quase um fato que seja lá o que for o “próximo Facebook”, vai ser puro mobile.
Ou seja, não só é relevante pra indústria, como está mudando substancialmente a forma como construímos software no servidor (+ APIs restful para servir clientes nativos, - Flash).
GWT já foi descontinuado e Dart não passa de um hobby de algum programador do google. Não sei porque alguém perderia seu tempo com isso.
Tudo depende do caso mesmo, mas nunca passei por um caso de ter a necessidade de ser nativo. O maior erro é fazer algo nativo sem necessidade.Sim, do ponto de vista do esforço do programador. Mas do ponto de vista do Facebook foi ter achado que não era necessário fazer nativo.
sim; pelo simples fato de você poder vender o sistema que você fizer sem burocracia; também investi em um mac apenas para aprender objective c, e poder vender o meu trabalho mais facilmente; mas ainda estou na fase dos estudos da linguagem, não me arrependo e acredito que seja muito promissor;
Claro, o facebook, com todos os recursos e programadores que dispõe, não conseguiu fazer uma app usável, mas com você vai ser diferente. :roll:
A não ser o Facebook que tentou fazer isso e quebrou a cara.Tem um texto dele falando que se arrependeu de fazer a aplicação do facebook como sistema híbrido. A melhor alternativa sempre seria nativo de plataforma.
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?
Desculpa, não especifiquei. Ele quis dizer referente a plataforma android. Diz que a solução web não foi a mais adequada comparada com a nativa.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Sérgio, sobre o esquema do html5 o problema não é performance mas o custo(relacionado com energia, etc…) em dispositivos móveis.
Aqui o mark critica. A aplicação nativa é mais vantajosa
Sobre o dart, ele também pode rodar na dartvm que é 28% mais rápida que o v8. :shock:
E é verdade, tenho estudado dart nas horas vagas e é uma grande realidade já.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat? 
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Você leu o tópico que esta respondendo?
Os usuários não estavam debandando por problemas na infraestrutura do Facebook, e sim porque a interface das apps não eram intuitivas.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat? :P
É isso aí. Eu postei logo atrás que era sobre a plataforma android mas ninguém deu importância.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.
Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura.
http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat? :P
É, mistuturei as coisas. Mas acima no tópico falaram de aplicação híbridas e de alguma forma eu associei com um sistema rodando em várias linguagens. Viajei total. Desculpem desviar o assunto.
Venda de tablets irá superar de PCs ainda este ano.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
Mas não ha que tomar a parte pelo todo. O fracasso do facebook foi do facebook, não da tecnologia em geral nem da ideia base. E como alguém já disse o fracaso foi relacionado à UX e não à tecnologia.
Tudo é uma questão de economia. Se for mais economico ir para o nativo, força. Mas na maior parte das situações onde vc quer ambrangencia e não profundidade ( ou seja, quer ter presença e não performance) a solução hibrida é melhor.
E coisas como o PhoneGap dão acesso às mesmas API que o nativo (GPS, sensores, etc;…) porque são aplicações nativas no final de contas. São “adapters”. Então a performance vai ser a mesma que uma aplicação nativa. O que difere é que no HTML o cara poderá ter mais dificuldade de fazer uma app com a cara nativa. Por outro lado é mais facil criar uma com uma cara diferente. Tem uma palestra sobre isto que achei interessante com exemplo de aplicações relativamente avançadas com html5 rodando no PhoneGap.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
Mas não ha que tomar a parte pelo todo. O fracasso do facebook foi do facebook, não da tecnologia em geral nem da ideia base. E como alguém já disse o fracaso foi relacionado à UX e não à tecnologia.
Tudo é uma questão de economia. Se for mais economico ir para o nativo, força. Mas na maior parte das situações onde vc quer ambrangencia e não profundidade ( ou seja, quer ter presença e não performance) a solução hibrida é melhor.
E coisas como o PhoneGap dão acesso às mesmas API que o nativo (GPS, sensores, etc;…) porque são aplicações nativas no final de contas. São “adapters”. Então a performance vai ser a mesma que uma aplicação nativa. O que difere é que no HTML o cara poderá ter mais dificuldade de fazer uma app com a cara nativa. Por outro lado é mais facil criar uma com uma cara diferente. Tem uma palestra sobre isto que achei interessante com exemplo de aplicações relativamente avançadas com html5 rodando no PhoneGap.
Depende, porque aí no caso a plataforma da aplicação que usa html5 não é o android mas sim os mais diversos browsers. O que eu li sobre o assunto é que o chrome no android consome muita bateria, gera muito calor etc…
Dependendo da aplicação é mais vantajoso usar o html5 sim, mas quando for criar um cliente que esteja remoto. Daí simplifica bem o desenvolvimento. No caso das aplicações nativas você tem o ganho de não ter todas as funcionalidades do chrome por exemplo na sua aplicação(não pagar pelo que não usa).
Acho que o ponto que o mark falou foi esse. Até pouco tempo atras o facebook era a pior aplicação de redes sociais que já usei no android(lento, esquenta o telefone, gasta a bateria, etc…).
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
Mas não ha que tomar a parte pelo todo. O fracasso do facebook foi do facebook, não da tecnologia em geral nem da ideia base. E como alguém já disse o fracaso foi relacionado à UX e não à tecnologia.
Tudo é uma questão de economia. Se for mais economico ir para o nativo, força. Mas na maior parte das situações onde vc quer ambrangencia e não profundidade ( ou seja, quer ter presença e não performance) a solução hibrida é melhor.
E coisas como o PhoneGap dão acesso às mesmas API que o nativo (GPS, sensores, etc;…) porque são aplicações nativas no final de contas. São “adapters”. Então a performance vai ser a mesma que uma aplicação nativa. O que difere é que no HTML o cara poderá ter mais dificuldade de fazer uma app com a cara nativa. Por outro lado é mais facil criar uma com uma cara diferente. Tem uma palestra sobre isto que achei interessante com exemplo de aplicações relativamente avançadas com html5 rodando no PhoneGap.
Meu problema com a forma que expõe é que quando você diz que tudo é uma questão de economia assume que o termo “econômico” pode ser definido igualmente em termos de tecnologias com propósitos diferentes, ou seja, é tão útil quanto não dizer nada.
A questão na verdade é, qual a tecnologia melhor indicada pra cada caso.
No caso de software que roda no cliente, ser mais econômico muitas vezes significa proporcionar engajamento com o usuário. Se considerar que 99,9% das pessoas que vão interagir com o seu software não liga a mínima se aquele mesmo pedaço de software roda em outras plataformas, é possível deduzir o valor de uma proposição híbrida para esse caso, é quase zero.
Quanto a soluções hibridas como PhoneGap, não tenho nada contra, mas acho que elas já estão no auge do seu ciclo de vida. Na medida que a indústria for sendo dominada pelos pads da vida a demanda por programadores nativos vai ser ainda maior que atual, de fato, ela vai explodir.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
Mas não ha que tomar a parte pelo todo. O fracasso do facebook foi do facebook, não da tecnologia em geral nem da ideia base. E como alguém já disse o fracaso foi relacionado à UX e não à tecnologia.
Tudo é uma questão de economia. Se for mais economico ir para o nativo, força. Mas na maior parte das situações onde vc quer ambrangencia e não profundidade ( ou seja, quer ter presença e não performance) a solução hibrida é melhor.
E coisas como o PhoneGap dão acesso às mesmas API que o nativo (GPS, sensores, etc;…) porque são aplicações nativas no final de contas. São “adapters”. Então a performance vai ser a mesma que uma aplicação nativa. O que difere é que no HTML o cara poderá ter mais dificuldade de fazer uma app com a cara nativa. Por outro lado é mais facil criar uma com uma cara diferente. Tem uma palestra sobre isto que achei interessante com exemplo de aplicações relativamente avançadas com html5 rodando no PhoneGap.
Meu problema com a forma que expõe é que quando você diz que tudo é uma questão de economia assume que o termo “econômico” pode ser definido igualmente em termos de tecnologias com propósitos diferentes, ou seja, é tão útil quanto não dizer nada.
A questão na verdade é, qual a tecnologia melhor indicada pra cada caso.
No caso de software que roda no cliente, ser mais econômico muitas vezes significa proporcionar engajamento com o usuário. Se considerar que 99,9% das pessoas que vão interagir com o seu software não liga a mínima se aquele mesmo pedaço de software roda em outras plataformas, é possível deduzir o valor de uma proposição híbrida para esse caso, é quase zero.
Quanto a soluções hibridas como PhoneGap, não tenho nada contra, mas acho que elas já estão no auge do seu ciclo de vida. Na medida que a indústria for sendo dominada pelos pads da vida a demanda por programadores nativos vai ser ainda maior que atual, de fato, ela vai explodir.
O tempo dirá se será assim. Eu acho que não.
Em relação ha economia, me referia a custo mesmo. O custo de ter equipes em cada linguagem vs uma equipe em uma linguagem + uma ferramenta de conversão. Os usuários podem não ligar se roda em outro fone, mas a empresa sim, porque é sua estratégia. Imagine que o Facebook ou outro qualquer tem app para uma plataforma, mas não para a outra. Isso é excluir potenciais usuários (e claro, estou suponto uma aplicação generica que faça sentido ter nos dois) e isso não é bom para marketing.
O motivo que programadores objective-c estão bem cotados hoje é porque existem fortes chances de iOS se tornar a plataforma dominante na categoria de tablets.
Ou seja, vai ser igual a década de 90 onde programadores MS foram os grandes privilegiados pelo surgimento de uma plataforma dominante.
Na época, com as estações de trabalho dando lugar a novos computadores desktop pessoais baseados nos processadores 386, a grande atividade comercial foi em torno do Windows/DOS, e não das demais plataformas existentes (UNIX, OS/2, híbridas).
Agradeço a todas as respostas, e realmente objective c é uma linguagem boa, desde que voltado ao mundo IOS…
essa será uma linguagem que pretendo estudar no futuro, como hobby, mas na minha situação vale mais a pena continuar
os estudos no c++ pois tem mais campo de trabalho.
Abobrinha. O aplicativo mais rentável do Google continua sendo feito e mantido em GWT, a saber, Ad Words.
Caro, vc perde seu tempo com q?
Só uma dúvida…
Estou pensando em pegar um iphone 5 fora do brasil para brincar com o sdk do ios…
Mas gostaria de saber se é possivel desenvolver algum app no Xcode e testar diretamente no iphone
em vez do simulador.
Estou perguntando porque vi em algumas noticias antigas que era preciso se cadastrar na apple, pagando para eles,
para assim poder testar algum app meu no meu próprio aparelho… é isso verdade ?
ou desenvolver em ios é igual android em que se pluga o aparelho no notebook e já se consegui testar, sem precisar pagar nada…
Pesquisando, vi que realmente se precisa pagar 100 dolares para poder fazer deploy do próprio
app no próprio aparelho. 
Isso devia ser de graça, igual ao android… por isso a Apple está abarrotada de dinheiro, faz de tudo para lucrar…