Últimas notícias do evento

Devo eu criar soluções mobile híbrido ou nativo?

Postado em Atualizado em

O que é um app mobile nativo?

Os aplicativos nativos são instalados e armazenados dentro do dispositivo mobile, baixados através de uma loja específica para cada plataforma (como iOs ou Android). Eles são feitos usando os SDKs e as linguagens nativas especificas de cada uma dessas plataformas, o que facilita o acesso a funcionalidades do sistema operacional e sensores como GPS e a câmera. Uma das grandes vantagens de concentrar o desenvolvimento em um aplicativo nativo é a facilidade de otimizar o código por tratar diretamente com as bibliotecas do sistema operacional do dispositivo. A desvantagem é que um aplicativo nativo custa mais caro, precisando de desenvolvedores com conhecimentos totalmente específico.

O que é um app mobile híbrido?

Aplicativos híbridos são feitos usando linguagens e tecnologias de web apps e usam wrappers ou frameworks para serem convertidos em um aplicativo instalável no dispositivo do usuário. Esse tipo de app também é publicado na loja e funciona de forma similar aos nativos. Sua grande vantagem é exigir apenas conhecimento de desenvolvimento web e, portanto, tem um custo muito menor de desenvolvimento. Alguns frameworks têm bibliotecas para facilitar a integração de aplicativos híbridos com várias funcionalidades de dispositivos. E a alternativa mais rápida e barata para garantir presença do seu aplicativo em todas as app stores. O produto mais usado desse segmento é o Cordova – https://cordova.apache.org.

Vejo muito “bla bla bla” por ai em torno desse assunto, hoje então gostaria de dar meu pitaco, baseado em minhas experiências no assunto, sempre é claro respeitando a sua.

1. Qual é melhor?

Vou começar falando mais uma vez, e já to cansado de falar isso, não existe solução melhor ou pior! Tudo tem seu valor e pode se encaixar dependendo do contexto em si. Voltamos ao assunto da Alice no país das maravilhas.

2. João disse: “Eu gosto do nativo”. Maria replicou: “Eu prefiro híbrido”

Segundo, essa escolha não é baseada em emoções, premonições ou gosto pessoal. É uma decisão puramente técnica! Do ponto de vista do seu usuário, não há diferença. Um aplicativo híbrido bem construído se integra à plataforma da mesma forma que um nativo. Sendo assim, essa decisão deve ser feito baseado em argumentos sistemáticos e não em opinião pessoal.

3. Híbrido é lento de mais

Mentira e frescura pura! Hibrido tem sim performance inferior ao nativo, mão não é nada lento. É muito bom e bem rápido. Você usando um bom controller JS e um kit de GUI HTML5 moderno ai de hoje, o uso fica bem acima do aceitável. Você já deve ter alguns ai no seu Smartphone e nem noto isso. Há diferenças de performance apenas em casos muito específicos que exijam realmente bastante processamento no dispositivo. Somente nesses casos, opte pelo nativo. Segue abaixo soluções reais, instale esses apps hibridos no seu smartphone e veja por sim mesmo:

4. Quando exatamente o nativo é melhor?

Aqui é aonde eu vejo o pessoal pecar muito. Nativo é melhor em casos como: games 3D complexos, ou em aplicações que precisem de multithreading. Não é recomendado também para apps que precisem ficar executando serviços em background. Só o ambiente nativo consegue fazer isso de forma realmente eficiente, sem consumir a bateria do usuário. Somente nesses casos, opte pelo nativo.

5. Experiencia única

Outro caso que também pode ser considerado, seria a questão de oferecer uma experiência única ao seu usuário no seu app.  Como o híbrido usa HTML e CSS para criar o visual, é comum acabarmos com um design comum a várias plataformas, apenas com pequenos ajustes. Mas se você quer algo que use os componentes nativos, nesses casos, opte pelo nativo. Mas eu te pergunto: Vai valer a pena o custo? tempo? e manutenção? Essa “suposta experiência” cobre tudo isso? É algo a ser pensando. O que eu vejo na prática é a necessidade de disponibilizar servições corporativos no mobile, sem frescuras de GUI.

6. Na dúvida deve eu escolher nativo?

Muito errado! Como a maioria das apps não se encaixa exatamente nas categorias 3, 4, e 5, um híbrido é suficiente! E o que pesa em seu favor é o menor custo de desenvolvimento. Um único projeto, um único código serve todas as plataformas. Não é necessário ter equipes específicas programando Android, iOS, Windows Mobile e outras, por exemplo. Isso reflete diretamente no custo, tempo, cronograma e manutenção. Esses são os principais argumentos que pesam em favor do híbrido. Outro fator é que se você já tem uma equipe com conhecimentos de HTML, CSS e JS, a curva de aprendizado para o híbrido é bem pequena. E se não sabe, aprender uma única plataforma baseado em W3C é infinitamente mais rápido e barato de acontecer e manter.

7. Mas se eu optar pelo híbrido e depois precisar acessar código nativo?

Soluções híbridas hoje te da acesso a vários serviços nativos com grande cobertura. Conforme o tempo avança, novos serviços são disponibilizados em novas versões. A chance de você fazer uma coisa extremamente especifica e que não seja coberta pelo serviços hibrido é baixa. Infelizmente poucos sabem que as decisões técnicas devem ser feitas baseadas nas necessidades reais e não em especulações ou bola de cristal.

8. Já fiz uma solução hibrida, já esta produção e agora eu tenho que fazer algo realmente nativo e específico. O que fazer?

Qual é problema disso? Nenhum! Isso é desenvolvimento de software brother! Mudança sempre! Você fez exatamente o que deveria fazer, começou com uma app híbrida para cobrir rapidamente o maior número de plataformas, e depois se precisar, se realmente surgir ou emergir necessidades não existentes na híbrida, você pode então custear a produção de uma versão nativa, agora realmente embasado em uma decisão técnica, substituindo a versão hibrida. O Facebook começou assim, todo em HTML5, e hoje tem aplicações nativas em várias plataformas (além de um excelente site mobile). O grande erro aqui é começar bancando vários nativos sem necessidade nenhuma e ao longo de vários anos, não emergir nada que justificasse ter a solução em nativo, virando desperdício total por parte da gestão.

O post fica aberto para você nos dar sua opinião. Até a próxima pessoal!

“Como dizem as Escrituras Sagradas: “Rios de água viva vão jorrar do coração de quem crê em mim” João 7:38

Feedback Ead – Java F4 – Programação Java Avançado 2

Postado em Atualizado em

“O curso Java F4 – Programação Java Avançado 2 supriu todas as minhas expectativas, o conteúdo proposto pelo instrutor Fernando Franzini foi apresentado de forma direta e objetiva, com uma ótima didática para lá de diferenciada, deixando claramente exposto a grande diferença desse curso para os “cursos de Java grátis” encontrados pela internet a fora. É visível a diferença que um instrutor certificado com anos de experiência como ele possa proporcionar na escolha de um curso e este é o principal quesito na hora de escolher. Gostaria de destacar como o Fernando sabe usar toda sua experiência, com ótimas dicas durante o decorrer do curso.”

Deivid Willyan, Londrina – PR.

Serialização – Item 77

Postado em Atualizado em

Para o controle de instâncias, prefira tipos enum a readResolve

O recurso do readResolve contorna aparentemente a possível criação de outro objeto de um singleton serializado, mas na verdade ainda fica aberto para erros caso algum invasor retenha uma referência ao abjeto antes de seu método readResolve ser invocado. Portando, use tipos enum para a imposição de invariáveis de controle de instância. Dessa forma existira uma garantia solida que não haverá instâncias além das constantes declaradas, gerenciados automaticamente pela própria JVM.

Para todas as informações, veja o post inicial.

“Eu sou a videira, e vocês são os ramos. Quem está unido comigo e eu com ele, esse dá muito fruto porque sem mim vocês não podem fazer nada.” João 15:5

Características de um Arquiteto de Software #4

Postado em Atualizado em

wellroundedarchitect-1024x574-1Ter um foco na solução

Os desenvolvedores experientes sabem que o código é apenas um aspecto do software real. Para tornar o código executável, um desenvolvedor experiente entende que existem outros atributos de qualidade importantes necessários para que o código funcione bem no ambiente de produção. Eles consideram aspectos como desempenho, segurança, escalabilidade, localidade, disponibilidade, confiabilidade, processos de implantação e testes automatizados. Os desenvolvedores simplesmente focam no código, mas o arquiteto no entanto, se concentrará na compreensão não apenas do código, mas também dos atributos de qualidade necessários para atender às muitas necessidades de diferentes partes interessadas. O bom arquiteto se concentra em encontrar soluções que possam satisfazer tantas dessas diferentes necessidades das partes interessadas, em vez de escolher uma ferramenta ou abordagem otimizada para as preferências ou o estilo de um único contribuinte. Para qualquer dúvidas, veja o post inicial dessa série.

“Procure descobrir, por você mesmo, como o SENHOR Deus é bom. Feliz aquele que encontra segurança nele!” Salmos 34:8

Novo Spring 4.3.7 Lançado

Postado em

Foi lançado uma nova versão do spring framework 4.3.7 com varias correções de bugs e melhorias. Veja o jira oficial nesse link.

“Confiem sempre no SENHOR, pois ele é o nosso eterno abrigo.” Isaías 26:4

Treinamento Completo de Programador Java EAD

Postado em Atualizado em

Objetivos

Objetivo deste pacote de cursos é dar formação completa para um programador profissional Java. Esse pacote agrupa total de 7 cursos de JSE, gradualmente e didaticamente sequenciados, desde os recursos do Java1 até a versão do Java8, oferecendo capitação completa com 20% de desconto sobre o valor total de todos os cursos individuais.

Público Alvo

Estudantes que almejem se tornar programadores profissionais Java, se capacitando para o mercado de trabalho.

Investimento

R$ 984,00

Pré-requisitos

  • Lógica de programação ou conhecimentos em alguma linguagem de programação.
  • Pc contendo no mínimo de 2 GB RAM com Windows VISTA/WIN7/WIN10.

Exercícios

Total de 185 exercícios, 10 minutos em média de tempo para cada um.

Tempo de Aula

  • +- 48h30 de videos em aulas.
  • +- 31h30 de exercícios práticos.
  • Total aproximado de 80h00 de horas em aula.

Disponibilidade

Acesso por 1 ano a partir da matrícula.

Grade

Segue abaixo todos os cursos que compõe esse pacote. Acesse cada um para ver sua respectiva grade:

  1. Java SE F1 – Fundamentos de Programação Java Básico
  2. Java SE F2 – Programação Orientada a Objetos com Java
  3. Java SE F3 – Programação Java Avançado 1
  4. Java SE JDBC – Banco de Dados Relacionais com Java
  5. Java SE F4 – Programação Java Avançado 2
  6. Java SE F5 – Desenvolvedor Funcional Java 8
  7. AQT M1 – Introdução a Arquitetura de Software com Java

Vantagens desse pacote

  • Os cursos são ministrados gradualmente sequenciados, proporcionando um aprendizado didaticamente correto e adequado.
  • Acesso por 1 ano, podendo rever qualquer aula de qualquer curso.
  • Pagamento parcelado em até 12 x.
  • Desconto de R$ 246,00, sendo que o valor total de todos o cursos fica em R$ 1.230,00.
  • Novos cursos serão adicionados sem custo adicional para alunos ativos nesse pacote.

Acesse – Java SE P1 – Pacote Programador Profissional Java

“Com um coração sincero eu te louvarei à medida que for aprendendo os teus justos ensinamentos.” Salmos 119:7

Para quem não sabe para onde vai, qualquer caminho serve

Postado em Atualizado em

574eeb8b9af513-13393298alice-no-pais-das-maravilhas-dublado-1080pHá uma cena que quero comentar na obra “Alice no país das maravilhas” o encontro de Alice com o gato. Na cena, Alice está perdida, e de repente, vê no alto da árvore o gato. Ela olha para ele lá em cima e diz assim:

Alice: “Você pode me ajudar?”
Gato: “Sim, pois não.”
Alice: “Para onde vai essa estrada?”
Gato: “Para onde você quer ir?”
Alice: “Eu não sei, estou perdida.”
Gato: “Para quem não sabe para onde vai, qualquer caminho serve.”

Muitas vezes vejo essa cena se repetir com o pessoal de desenvolvimento perguntando nos fóruns, e-mails e listas algo como:

“Qual melhor framework jA ou jB? Qual a melhor plataforma A , B, C? Qual melhor arquitetura em fazer C, D ou F? Qual framework web usar jWeb1, jWeb2 ou jWeb3?”

Como alguém poderia decidir por exemplo em usar JSF ou VRaptor ou ExtJ se não sabe os detalhes relacionados aos requisitos, contexto, ambiente e restrições da solução? A resposta seria igual ao do gato:

“Para quem não sabe para onde vai, qualquer caminho serve”.

Ou até pior, os céticos poderiam detonar uma opção e exaltar a outra ou pode aparecer aqueles “amantes emocionais” de tecnologia dizendo “usa aquela opção que é legal, eu gosto muito”.

O responsável por essa decisão, normalmente um arquiteto, deveria fazer suas escolhas arquiteturais e tecnológicas baseadas em justificativas coerentes no próprio cenário de requisitos existente a ser alcançado, características, restrições e outros limitadores corporativos externos como: custo, investimento, capacitação, curva de aprendizado, produtividade, gestão de equipe, cronograma e etc, e não em gosto, preferência, opiniões sem contexto ou qualquer outra coisa sem fundamentos lógicos e coerente.

As características da solução irão inevitavelmente se contradizer, alguma decisão deverá ser tomada, não será possível endereçar solução a todas as situações, mas algum caminho precisará ser traçado. Um exemplo comparativo simples, seria algo assim:

Exemplo 1

Contexto: Preciso viajar de Curitiba para São Paulo
Soluções: moto? carro? caminhão? avião?
Decisão: carro.
Justificativa: moto demora, não tenho carteira para caminhão e não tenho dinheiro para passagem de avião.

Exemplo 2

Contexto: Preciso viajar de Curitiba para São Paulo e levar uma geladeira
Soluções: moto? carro? caminhão? avião?
Decisão: caminhão.
Justificativa: moto não resolve, carro não resolve, e não tenho dinheiro para passagem de avião.

Exemplo 3

Contexto: Preciso viajar de Curitiba para São Paulo, levar uma geladeira e participar de uma reunião de negocio daqui 2 horas.
Soluções: moto? carro? caminhão? avião?
Decisão: sou obrigado a gastar com avião.
Justificativa: moto não resolve, carro não resolve, caminhão não resolve.

Como pode ser percebido, se existir um requisito tal de produtividade, talvez o framework A pode ser a melhor que o B, mas caso exista outro requisitos relacionado com segurança que pese mais que outras características, o framework B pode mais adequado que o A.

Não existe framework Java melhor ou pior, tudo esta relacionado em abrir um ponto de visão baseado em conhecer as opções, suas vantagens, desvantagens, virtudes, fraquezas e contrastar com os pesos das caraterísticas dos requisitos! Java é fantástico possuindo vários opções de framework para fazer diferente a mesma coisa. Então querido, seja livre, seja Java! Não se limite! Seja maduro e não tenha sentimentos para frameworks, use o que precisar, quando precisar! Toda produto/framework tem seu valor!

Com este ponto de vista, dizemos que a arquitetura emerge destas informações. Uma vez que o projeto começa a andar e pequenas fatias de releases começam a ser entregues, a solução pode passar mudanças de requisitos, características, ambientes e restrições precisando então ser melhorada e evoluída para um próximo nível, necessitando ou não a troca das opções de frameworks feitas anteriormente. Outra arquitetura emerge então destas novas informações respondendo, rapidamente a necessidades e cenários emergentes.

“O céu e a terra desaparecerão, mas as minhas palavras ficarão para sempre.” Mateus 24:35