Antes de criticarmos ou falar que algo é ruim, é bom entendermos o motivo pelo qual aquilo existe.

Porque o CORS existe?

O CORS (do inglês cross-origin resource sharing) é um mecanismo que permite que os conteúdos de domínios diferentes sejam compartilhados. Ele existe para evitar que o conteúdo de um determinado domínio seja utilizado por outro sem a autorização do mesmo.

Exemplo: supondo que eu queira exibir os conteúdos do youtube em meu site, faço uma análise das requisições HTTP’s feitas pelo youtube, obtendo os parâmetros da chamada criaria uma UI para usar as informações do youtube, tirando assim proveiro dos dados deles. O CORS impediria que essa ação fosse executada na camada do navegador, ou seja é uma segurança para você!

Como funcionar o CORS?

O CORS vai analisar se o recurso que você tenta carregar está sob o mesmo domínio e porta. Com isso mesmo que você tenha sua API rodando no endereço “http://localhost:8080” e sua aplicação ionic/angular rodando em suas respectivas portas (8100/4200) ao chamar a API com toda certeza vai ter sua requisição bloqueada e vai receber a mensagem de CORS.

Quando você não está sob o mesmo domínio você vai notar na parte de redes que uma requisição http gera 2 outras chamadas. A primeira chamada usa o verbo http OPTIONS, ele é utilizado pelo navegador para perguntar ao  seu servidor/aplicação quais os tipos de requisição sua aplicação permite e é no OPTIONS que você deve informar suas configurações do CORS através de Headers.

Opções para o CORS

1. Access-Control-Allow-Origin: Header utilizado para informar quais domínios você permite que use o seu conteúdo.
2. Access-Control-Allow-Methods: Header utilizado para informar quais verbos http você permite a partir dos domínios liberados.
3. Access-Control-Allow-Headers: Header utilizado para informar quais “Headers” os domínios liberados podem enviar para você.
4. Access-Control-Max-Age: Header utilizado para informar quanto tempo é válido essas configurações de CORS.

O que não devo fazer?

[wp_ad_camp_3]

Bom acho que a primeira coisa que você deve se questionar é: Preciso realmente liberar o CORS em seu ambiente? Mesmo em aplicações ionic a liberação não é necessária. O mesmo para Angular, vendo que em produção o domínio será o mesmo (ou não rs).

Mas vamos lá, supondo que você chegou a conclusão que liberar o CORS é realmente necessário, não faça isso “Access-Control-Allow-Origin: *” ao fazer isso você está simplesmente tirando uma camada de segurança que foi criada para você. Caso você esteja rodando uma aplicação ionic (já compilada), não é necessário liberar o CORS mas caso queira liberar é necessário apenas  permitir o endereço http://localhost:8080/ que é o endereço que o ionic utiliza para carregar sua aplicação compilada ou seja a liberação correta (caso deseje fazer) é “Access-Control-Allow-Origin: http://localhost:8080“.

Outra coisa bem importante é o Access-Control-Max-Age geralmente nos tutoriais ninguém comenta sobre ele. Lembra aquela segunda requisição? A do tipo OPTIONS, então ela é feita quando expira o Access-Control-Max-Age então se você não falar para o navegador que essas definições só mudam de X em X tempos todo e qualquer request que você fizer o seu servidor vai receber duas requisições (cada browser tem seu tempo padrão). Em ambiente de desenvolvimento, geralmente desabilitamos os cache’s e com isso o Access-Control-Max-Age não vai fazer efeito. Mas em ambiente de produção é algo muito importante.

Como assim não preciso liberar o CORS para o ionic?

Sim é isso mesmo, não precisa! E já vou explicar o motivo. Quando você desenvolve seu aplicativo, você geralmente testa seu projeto seu navegador e ele implementa o Same-Origin-Policy por isso que você tem problemas com CORS e acaba fazendo tudo quanto é tipo de liberação. Porém quando o seu aplicativo é compilado para APK ou IPA o ionic de forma nativa consegue desabilitar o CORS da WebView (e eles já fazem isso).

Vale lembrar que para o iOS o ionic sempre usou o UIWebView só que agora eles migraram para o MKWebView e no iOS eles não conseguem desabilitar o CORS nessa webview em especifico =/. Então ou você faz um downgrade da webview, ou você libera o CORS para a origem “http://localhost:8080” ai é uma decisão pessoal, basta acessar a documentação com as melhorias propostas pela MKWebView e colocar na balança.

Para fazer o downgrade da WebView basta colocar o conteúdo abaixo em seu config.xml para a plataforma iOS:

<preference name="CordovaWebViewEngine" value="CDVUIWebViewEngine" />

E meu ambiente de desenvolvimento, como faço?

Então para você desabilitar a checagem do CORS em seu ambiente de desenvolvimento você pode fazer uso de uma extensão do google chrome mas eu não recomendo, tive muitos problemas com essa extensão. Ela liberou o CORS mas sempre me trouxe problema com encodings em outros sites que eu acessava.

Não quer usar a extensão?

Então vamos lá, o ionic e o angular tem um recurso bem interessante e muito pouco conhecido que tem exatamente essa função (impedir problemas com CORS) são os proxies.  É algo bem simples, mas eles são apenas para ambientes de desenvolvimento. Então não se esqueça de criar uma configuração para seu endpoint  🙂

O que é um proxy? Como ele funciona?

Um proxy basicamente é um serviço intermediário entre você e seu servidor de aplicação, ele recebe sua requisição e repassa ela para o servidor original.

Vamos criar o seguinte cenário: Tenho a url (http://localhost:8888/) rodando um backend, então vamos criar um mapeamento para informar que tudo que for chamado na uri /api seja passado para o backend.

Vamos supor que você esteja desenvolvendo em uma aplicação ionic, ao digitar o endereço http://localhost:8100/api/criar-usuario ele vai redirecionar internamente no processo do ionic serve a requisição para http://localhost:8888/criar-usuario então sua aplicação vai estar chamando uma URL que está no mesmo domínio e na mesma porta assim a Same-Origin-Policy não vai ser aplicada e você pode seguir seu desenvolvimento sem necessidade de liberar o CORS para desenvolver.

Configurando o proxy no ionic

[wp_ad_camp_2]

Para configurar o proxy no ionic basta abrir o arquivo ionic.config.json e criar uma nova propriedade chamada proxies e nela definir seus paths.

Exemplo:

{
	"name": "app-meuapp",
	"app_id": "",
	"type": "ionic-angular",
	"proxies": [{
		"path": "/api",
		"proxyUrl": "http://localhost:8888/"
	}],
	"integrations": {
		"cordova": {}
	}
}

Configurando o proxy no Angular

Para fazer a configuração de seu proxy no Angular o processo é semelhante. Para isso é necessário criar um arquivo JSON com as configurações os paths desejados. Então vamos criar o arquivo proxy.conf.json e vamos colocar o conteúdo abaixo. Após isso basta você inicializar seu projeto com o comando ng serve –proxy-config proxy.conf.json.

Observação: Recomendo que coloque esse comando na chave start do package.json assim você só vai precisar rodar o comando npm start

Conteúdo para o proxy.conf.json

{
  "/api": {
    "target": "http://localhost:8888",
    "secure": false
  }
}

Conclusão

[wp_ad_camp_1]

O CORS é um recurso de segurança muito importante e precisamos gerenciar ele de acordo com as necessidades do nosso projeto, fazendo o uso das técnicas mencionadas nesse post é possível trabalhar sem dor de cabeça e claro ter um desenvolvimento saudável e seguro.

The post Ionic & Angular: Fazendo o CORS seu amigo appeared first on Hiago Silva Souza.

Vamos lá!

[wp_ad_camp_3]

Com a chegada do iOS 11.3, a Apple adicionou silenciosamente os o suporte ao conjunto básico de novas tecnologias por trás da ideia dos “Progressive Web Apps” (PWA’s). Agora é hora de ver como elas funcionam, quais são seus recursos e desafios, e o que você precisa saber caso já tem um PWA publicado.

Se você veio até aqui e ainda não sabe o que é um PWA, vamos começar dizendo que não há uma definição única ou precisa. Mas é um aplicativo criado com tecnologias da Web que, sem empacotar ou assinar, pode funcionar offline e pode, opcionalmente, ser instalado no sistema operacional, onde ele será exibido e funcionará como qualquer outro aplicativo.

Não há nenhum processo de “Lojas para Aplicativos” envolvido na maioria das plataformas – somente o Edge / Windows 10 está atualmente forçando os PWA’s a estarem na loja.

Então você está certo, agora você pode instalar aplicativos no iOS sem a aprovação da App Store. Esse é provavelmente um dos motivos pelos quais a Apple não mencionou nada sobre essa novo recurso; eles podem não querer confundir os usuários. Nem mesmo as notas de lançamento do Safari mencionam as tecnologias.

A Apple não foi a criadora de PWAs?

[wp_ad_camp_2]

Vamos ser honestos aqui; enquanto o Google, com a equipe do Google Chrome, cunhou o termo PWA, a ideia estava inicialmente disponível no Safari no iPhone OS original. Em 2007, Steve Jobs anunciou “mais uma coisa” na WWDC: como desenvolver aplicativos para o iPhone original e, surpreendentemente, aplicativos da web! A App Store não estava no roteiro original e o SDK nativo não estava disponível durante o primeiro ano do dispositivo. Do ponto de vista da Apple, os PWA’s até hoje são apenas “aplicativos da web na tela inicial”, e o ícone é algo chamado de WebClip.

Também é verdade que a ideia não recebeu muita atenção há 11 anos e a Apple se esqueceu de atualizar essa plataforma, por isso, embora ainda estivesse lá há mais de 10 anos, era problemática e inconsistente. Alguns anos mais tarde, outras plataformas clonaram a ideia, incluindo o MeeGo Browser no Nokia N9 e o Chrome no Android.

O Chrome ajudou a desenvolver as tecnologias para oferecer uma experiência melhor, principalmente com os Service Workers e as especificações do Manifest do Web App. A partir do iOS 11.3 sexta-feira (30 de março de 2018), a Apple está combinando o Chrome, o Firefox, a Samsung Internet, o UC Browser e o Opera (principalmente no Android) suportando essas duas especificações. Outros navegadores na área de trabalho suportam os Trabalhadores de Serviços, mas o suporte ao Manifest da Web App está em andamento neste ano.

Espere aí, por isso, o aplicativo não passou no teste de qualidade da App Store, certo? ?

Sim esta correto. No entanto, o aplicativo será executado somente sob o modelo de segurança e execução do navegador ou da Web Platform. Isso significa que você pode “publicar” aplicativos que não são aprovados na loja, como um aplicativo interno para os funcionários da sua empresa (e sim, também conteúdo adulto), mas não é possível acessar recursos nativos puros, como a ID Facial no iPhone X ou ARKit para realidade aumentada. Ou, pelo menos, você precisa esperar que a Plataforma Web capture esses novos recursos.

O PWA pode ser executado dentro do Safari como qualquer site ou no modo autônomo, como qualquer outro aplicativo no sistema. Se você estiver se perguntando se os PWA’s estão usando a Web View, esse não é o caso do Safari ou do ícone instalado, mas será o caso durante a navegação em outros navegadores ou no Facebook com o navegador In-App.

Funcionalidades dos PWA’s no iOS

Com a Plataforma Web no iOS, você pode acessar:

• Geolocalização
• Sensores (Magnetômetro, Acelerômetro, Giroscópio)
• Câmera
• Saída de áudio
• Síntese de fala (somente com fones de ouvido conectados)
• Apple Pay
• WebAssembly, WebRTC, WebGL, bem como muitos outros recursos experimentais sob uma bandeira.

Limitações em comparação com aplicativos iOS nativos

• O aplicativo pode armazenar dados e arquivos offline de até 50 Mb.
• Se o usuário não usar o aplicativo por algumas semanas, o iOS liberará os arquivos do aplicativo. O ícone ainda estará lá na tela inicial e, quando acessado, o aplicativo será baixado novamente
• Sem acesso a alguns recursos, como Bluetooth, serial, Beacons, Touch ID, ID de Face, ARKit, sensor de altímetro, informações sobre bateria
• Nenhum acesso para executar código enquanto estiver em segundo plano
• Sem acesso a informações privadas (contatos, local em segundo plano) e também sem acesso a aplicativos sociais nativos
• Sem acesso ao In App Payments e muitos outros serviços baseados na Apple
• No iPad, sem acesso para trabalhar com visualizações laterais ou divididas compartilhando a tela com outros aplicativos, os PWA’s sempre ocuparão a tela inteira
• Sem notificações push, sem badge icon ou integração com a Siri

O que os PWA’s podem fazer no Android e não no iOS

• No Android você pode armazenar mais de 50 Mb
• O Android não exclui os arquivos se você não usa o aplicativo, mas pode excluir os arquivos sob pressão de armazenamento. Além disso, se instalado ou usado muito pelo usuário, o PWA pode solicitar Armazenamento Persistente
• Acesso Bluetooth para dispositivos BLE
• Web Share para acessar o diálogo de compartilhamento nativo
• Speech Recognition
• Sincronização em Segundo Plano e Notificações por Push via Web
• Banner do aplicativo Web para convidar o usuário a instalar o aplicativo
• Você pode personalizar (um pouco) a tela inicial e as orientações que você quer
• Com o WebAPK e o Chrome, os usuários não podem instalar mais de uma instância de um PWA
• Com o WebAPK e o Chrome, os PWAs aparecem em Configurações e você pode ver o uso de dados; no iOS tudo aparece no Safari
• Com o WebAPK e o Chrome, o PWA gerencia as intenções de seu URL, portanto, se você obtiver um link para o PWA, ele será aberto no modo independente e não na janela do navegador.

O que os PWA’s podem fazer no iOS e não no Android

• Os usuários podem alterar o nome do ícone antes de instalá-lo
• Eles podem ser configurados em um perfil de configuração, para que os usuários corporativos possam receber atalhos do PWA da empresa (que é muito bom!). O Safari usa o termo WebClip para esse recurso; no entanto, parece que não está lendo o manifest do aplicativo Web (de acordo com a documentação)

Mas se não houver App Store, como você instala um PWA?

Esse é um dos desafios mais significativos no iOS, pois não haverá prompt’s ou convites do Safari (conhecidos como Banners de Aplicativos da Web no Android). Portanto, o usuário precisa ir até a URL do PWA de alguma forma dentro do Safari e, em seguida, pressionar manualmente o ícone Compartilhar e, em seguida, “Adicionar à tela inicial”. Não haverá indicação de que um site que você está visitando seja um PWA.

Além disso, pseudo-navegadores adicionais disponíveis na App Store, como o Chrome, o Firefox, o Brave ou o Edge, não poderão instalar um PWA ou usar os Service Workers.

Depois de instalado, será exibido como qualquer outro ícone na tela inicial. Não haverá menu 3D Touch para ele. E se você instalar o mesmo PWA novamente, você terá outro ícone apontando para o mesmo PWA (felizmente, os arquivos instalados serão compartilhados).

Além disso, muitos aplicativos da Web têm um link para instalar o aplicativo nativo a partir da App Store, e isso ainda está sendo exibido mesmo dentro do PWA, como o exemplo do Tinder:

[wp_ad_camp_1]

Eu já tenho um PWA, ele funcionará no iOS imediatamente?

Seu PWA estará disponível para instalação imediatamente após os usuários atualizarem para o iOS 11.3. Você não precisa ativar o iOS. Cada PWA está disponível para instalação. Mas isso não significa que tudo funcionará como esperado.

O que não vai funcionar

• O display: tela cheia e display: o minimal-ui não funciona no iOS; fullscreen irá disparar standalone, e minimal-ui será apenas um atalho para o Safari. Você pode obter algo semelhante ao fullscreen (a barra de status existirá, mas sobre o seu aplicativo) usando a extensão de viewport cover-fit ou uma metatag descontinuada.
• Se você confia no Background Sync, você deve ter uma implementação de backup
• Não há maneira de bloquear a orientação do seu PWA
• A cor do tema para estilizar a barra de status não funciona; você pode usar a meta tag reprovada para barras de status pretas ou brancas ou usar um truque de CSS / HTML para emular uma cor de tema.
• Se o seu PWA não tiver gestos posteriores ou botões na interface do usuário do aplicativo, o usuário não poderá navegar entre as telas
• Seu ícone Android pode parecer péssimo no iOS, pois a Apple não oferece suporte a ícones transparentes, por isso, confira.
• Além disso, o iOS não está tirando os ícones do Manifest do Aplicativo da Web, mas do link do ícone do Apple-touch. Se você não fornecer a tag de link, uma captura de tela será usada para o ícone (consulte o exemplo do Google Keep PWA)
• Não há tela inicial, portanto, a maioria das propriedades de cores do manifesto é ignorada
• Nenhum evento de manifest será acionado. Portanto, se você estiver acompanhando a instalação por esses canais, não funcionará no iOS (mas você poderá verificar navigator.standalone).

O que ter em mente

• Seu PWA não manterá estado entre as sessões, se o usuário sair de um PWA, ele será reiniciado ao voltar, portanto, se você precisar que o usuário valide um email, SMS ou faça uma autenticação de dois fatores, tenha isso em mente para oferecer uma solução adequada.
• Os PWAs na história não têm nenhuma captura de tela, então todos parecem telas brancas, infelizmente ?
• Existem erros quando o aplicativo é executado no modo autônomo. Não confie no Safari para testes.

• Se você quiser usar a área de entalhe do iPhone X para o seu aplicativo, precisará fazer algumas alterações no HTML e no CSS. Se você não fizer certo, coisas estranhas podem acontecer
• Às vezes, você adiciona à tela inicial e o manifest não é usado, então apenas um atalho é instalado
• O Safari e o atalho da tela inicial compartilham o mesmo registro do Service Worker (mas não a instância) e os arquivos em cache. O Safari View Controller (como o In-App Browser no Twitter) suporta Service Worker e o cache, mas parece que está excluindo todos os dados depois que a sessão é fechada.
• Cada pseudo-navegador, como o Chrome ou o Firefox, e cada aplicativo que usa o WebView, como o navegador In-App do Facebook, não suporta Service Workers (estava funcionando durante os betas), portanto, nenhum arquivo será instalado. Meu palpite é que uma API pode ser necessária para o WKWebView permitir que o proprietário do aplicativo decida o que fazer com os Service Workers, mas… quem sabe.
• Para depurar os Service Workers no iOS, você precisa instalar o Safari Technology Preview ou o Safari 11.1 disponível com as atualizações do macOS 10.11.5, 10.12.6 e 10.13.4.

• Service Workers podem ser desativados nas configurações em Tecnologias experimentais (ativado por padrão)
• Às vezes, quando você abre muitos PWAs ao mesmo tempo, a barra de tarefas do iOS fica louca, mostrando aplicativos “fantasmas” sem ícone ou título no histórico

Então é isso ai pessoal, acredito que estamos caminhando para a era dos PWA’s e logo logo teremos muitas outras novidades sobre o assunto.

Vou estar compartilhando mais conteúdos sobre o PWA e você vai poder conferir aqui!

Esse post é uma tradução do Maximiliano no Meredium, segue link original em inglês: https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7

Obrigado e até mais

The post PWA: Progressive Web Apps no iOS chegaram ? appeared first on Hiago Silva Souza.