Web Share API – Level 2

Recentemente fiz um post sobre Web Share API, um dos motivos foi a inclusão de suporte pela plataforma iOS a API na última versão 12.2. Nesse post vamos abordar alguns updates que estarão presentes na versão 75 do Chrome.

Os recentes updates são relevantes para aplicações web progressivas ou PWAs. Em meu canal do Youtube comecei uma série sobre como construir uma PWA, esse post serve como conteúdo complementar, caso queira saber mais sobre PWA assine meu canal:

Voltando ao tópico do post, Web Share API level 2 irá facilitar compartilhamento de arquivos entre apps. Agora aplicações web conseguem compartilhar arquivos entre aplicações web definidas na Web Share Target API.

Web share Target API

Permite definir como uma aplicações disponíveis no card de compartilhamento, este recursos está apenas disponível para plataforma Android como podemos ver na imagem a seguir:

Para habilitar Web Share target API precisamos implementar informações extra em nosso manifest.json e preparar nossa PWA interagir com o conteúdo recebido pelo app. Web Share Target API pode ser assunto que podemos abordar com mais detalhes em outro post.

Novo método canShare()

No post anterior sobre Web Share API utilizamos o “navigator.share()” para verificar se temos suporte a API e compartilhar uma url específica. Mas quando se trata de compartilhar um arquivo é mais complicado, mas agora podemos verificar se o sistema operacional suporta o compartilhamento por arquivo com a função canShare():

const shareData = { files: filesArray };
if (navigator.canShare && navigator.canShare(shareData)) {
  // Compartilhe o conteúdo aqui
} else {
  console.log('Seu sistema operacional não suporta compartilhamento de arquivos');
}

No código acima verificamos se o nosso browser tem suporte a função canShare e na sequência verificamos se o OS suporta compartilhamento de arquivos via Web apps. Agora que temos a verificação que podemos compartilhar nosso arquivo dentro da condicional invocamos nosso a função navigator.share

if (navigator.canShare && navigator.canShare( { files: filesArray } )) {
  navigator.share({
    files: files,
    title: 'Título do card',
    text: 'descrição do conteúdo',  })
  .then(() => console.log('Conteúdo compartilhado com sucesso'))
  .catch((error) => console.log('Falha no compartilhamento', error));
} else {
  console.log('Seu sistema operacional não suporta compartilhamento de arquivos');
}

Dependendo da aplicação em que você compartilhe o conteúdo, o título e o texto de descrição pode ser exibido ou não. Exemplo aplicativos de email o título e texto serão exibidos. Já aplicações de edição de images essas informações serão irrelevantes.

Utilizando localStorage para armazenar dados no Device

Esse post é um dos posts mais visualizados do blog, foi criado em 2013 mas vou dar uma atualizada no que aconteceu de lá pra cá. Armazenamento local com localStorage é umas das features mais úteis do HTML5 podemos utilizar para uma infinidade de ações agora com Progressive Web Apps esse recursos voltou a ficar evidência esta API, ela permite o armazenamento de strings com chave e valor e considerado cookies é uma forma mais segura de armazenamento. Recurso nativo no browser não necessita de plugin ou library externa.

Para aplicações mas complexas temos a opção de utilizar o IndexDB ou a mais nova opção de armazenamento KV Storage agora com suporte na versão 74 do Google Chrome. Mas um dos pontos fortes do localStorage é o suporte comparado a outras APIs ele é suportado por 93% dos browsers:

LocalStorage é um dos recursos do DOM Storage com ele podemos armazenar dados apenas em formato de texto, mas claro podemos contornar essa limitação. Vamos primeiro exemplo básico de armazenamento.

localStorage.setItem("key_da_propriedade","Valor armazenado");

No código acima adicionamos uma variável com nome “key_da_propriedade” que irá armazenar “Valor armazenado”. Quando esse código for armazenado pelo browser o usuário pode sair da aplicação, continuar navegando em outras aplicações quando ele voltar para nossa aplicação o dado continuará lá. Esse recurso será útil caso utilizarmos uma versão offline de nossa aplicação com PWA.

Para visualizar a informação que foi salva, no Google Chrome para abrir o developer Tools vamos em “menu > View > developer > developer tools”, tecla de atalho ctrl+shift+i ou simples clique o com botão direito do mouse e selecionamos a opção “inspect”, com developer tools aberto vamos na aba Application, na sessão storage vemos a opções disponíveis. Quando clicamos em Local Storage vemos as aplicações separadas por url, meu teste estou rodando em localhost, clicando na url da nossa aplicação vemos os dados armazenados:

Agora que sabemos que a informação foi salva vamos resgatar esse valor com o seguinte código:

const minha_propriedade = localStorage.getItem('key_da_propriedade');
alert("Valor:" + minha_propriedade);

No código acima passamos a função getItem e como parâmetro passamos a key da informação que queremos resgatar, na linha seguinte apenas executamos um alert para exibir a informação.

Caso queria remover essa informação do localStorage utilizamos o seguinte código:

localStorage.removeItem('key_da_propriedade');

Agora vamos para um exemplo prático aplicando essas três funções que virmos acima, no caso: salvar, ler e excluir os dados no localStorage.

<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>LocalStorage tutorial</title>
	<script>
		window.addEventListener('load',() => {
			if(localStorage.getItem('name')){
				sayMyName()
			}else{
				whatsYourName()
			}
		});
		
		function whatsYourName(){
            document.body.innerHTML = '';
            // criando um input para cadastrar o nome;
            const inputName = document.createElement('input');
            inputName.type = 'text';
            inputName.placeholder = 'Digite seu nome';
            inputName.id = 'nome';
            document.body.appendChild(inputName);

            // criando saveButton
            const saveButton = document.createElement('button');
            saveButton.innerHTML = 'Salvar';
            document.body.appendChild(saveButton);
            
            // adicionando listener para salvar a informação
			saveButton.addEventListener('click', saveName);
		}
		
		
		function sayMyName(){
            document.body.innerHTML = '';
            // criando mensagem
            const welcomeMessage = document.createElement('h1');
            welcomeMessage.innerText = 'Olá' + localStorage.getItem("name");
            
            // criando removeButton
            const removeButton = document.createElement('button');
            removeButton.innerHTML = 'Excluir';
            document.body.appendChild(removeButton);
            
            // adicionando o listener para remover informação
			removeButton.addEventListener('click',removeName);
		}
		
		function removeName(){
			if(localStorage.getItem('name')){
				localStorage.removeItem('name');
				whatsYourName()
			}	
		}
		
		function saveName(){
			var nome = document.getElementById('nome').value;
			localStorage.setItem('name', nome) 
			sayMyName();
		}
	</script>
</head>
<body>
</body>
</html>

O Exemplo acima resumindo rapidamente ele verifica se tem o dado com a key “name” no localStorage, caso tenha, exibe o nome. Caso contrário adiciona um input para cadastrar o dado. Quando o nome é exibido também adicionamos um button para chamar a função de excluir os dados. Nos Exemplos anteriores apenas adicionamos e removemos algumas strings, para trabalhar com objetos no localStorage precisamos usar a Classe JSON, com ela é possível fazer a ponte entre textos e objetos.

		window.addEventListener('load',() => {
			if(localStorage.getItem('user')){
				const texto = localStorage.getItem("user");
				const objeto = JSON.parse(texto);
				document.body.innerHTML = `nome: <strong>${objeto.name}</strong> email: <strong>${objeto.email}<strong>`;
			}else{
				const user = { 
					name: 'Fellyph',
					email: 'fellyph@fellyph.com.br'
                }
				const userString = JSON.stringify(user);

				localStorage.setItem('user',userString);
				document.body.innerHTML = 'dados salvos';	
			}
		});

No código acima focamos apenas no javaScript, verificamos se existe um dado com uma key “user”, caso exista ele resgata a informação na variável “texto” em seguida convertemos o texto em objeto utilizando a método parse da classe JSON, assim temos um objeto como retorno e adicionamos o conteúdo no body do nosso arquivo, no código acima utilizamos string literals para concatenar o nosso conteúdo.

Caso o usuário não tenha nenhuma informação salva com a key “user”, o código irá criar um objeto e em seguida converter em texto, assim temos a possibilidade de salvar os dados no em nosso localStorage. Esse exemplo não é muito funcional apenas exemplifica como é salvar um objeto em nosso localStorage.

Agora vamos partir para um exemplo mais funcional, vamos montar uma todo-list utilizando localStorage, desta vez vamos separar o código no arquivo todo-list.html, js/app.js e css/style.css. O exemplo a seguir utiliza ES2015 caso queira dar uma olhada no exemplo em EcmaScript 5 só da uma olhada no gitHub no seguinte link: https://github.com/fellyph/Tutorial-bbUI/tree/master/localstorage

Nosso HTML:

<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Todo List</title>
	<link rel="stylesheet" href="css/style.css">
	<script src="js/app.js"></script>
</head>
<body>
	<h1>todo-list</h1>
	<div id="tasks-output"></div>
	<form id="form-task">
		<input type="text" name="descricao" placeholder="adicione uma nova task" required>
		<input type="submit" value="Salvar">
	</form>
</body>
</html>

Nosso CSS:

#tasks-output li {
	cursor: pointer;
}

#form-task {
	border-top: 1px solid #ddd;
	padding: 10px 0;
	margin: 10px 0;
}

#tasks-output li[data-done="true"] {
	text-decoration: line-through;
}

Detalhe para o ultimo seletor que trata quando o item da lista possui o atributo data-done igual a true, ele vai adicionar uma linha sobre o texto.

let todoList;
let todoOutput;

function formatDate(date) {
  // formata a data para o formato DD/MM/YYYY
  const time = new Date(date);
  return `${time.getDate()}/${time.getMonth()}/${time.getFullYear()}`;
}

function showList() {
  // mostra a lista de todo
  if (todoList.length > 0) {
    const htmlTemp = `<ul>
      ${todoList.map(todoItem => `<li data-id="${todoItem.id}" data-done="${todoItem.done}">${todoItem.descricao} - ${formatDate(todoItem.date)}</li>` )}
      </ul><button>Limpar tarefas realizadas</button>`;
    todoOutput.innerHTML = htmlTemp;
  } else {
    todoOutput.innerHTML = 'Nenhuma tarefa cadastrada';
  }
}

function saveList() {
  // converte os dados em string e salva no local storage
  localStorage.setItem('tasks', JSON.stringify(todoList));
}

function clearList() {
  // varre a lista a procura de tarefas realizadas
  for (let i = 0; i < todoList.length; i += 1) {
    if (todoList[i].done === 'true') {
      // remove 1 elemento na posição i;
      todoList.splice(i, 1);
      // voltando o indice no array para validar novamente a lista
      i = 0;
    } else {
      todoList[i].id = i;
    }
  }
  showList();
  saveList();
}

function clickList(e) {
  // somente fazer algo quando clicar em um item li
  if (e.target.localName === 'li') {
    e.target.dataset.done = !e.target.dataset.done === 'true';
    todoList[e.target.dataset.id].done = e.target.dataset.done;
    saveList();
  } else if (e.target.localName === 'button') {
    clearList();
  }
}


function onSubmit(e) {
  const task = {};

  // pego o valor cadastrado no primeiro input do meu form
  task.descricao = e.target[0].value;
  task.date = new Date();
  task.id = todoList.length;
  task.done = 'false';

  // adicionando a task na lista
  todoList.push(task);
  saveList();
  showList();
  // utiliza o preventDefault para evitar do form realizar o reload da página
  e.preventDefault();
}


window.addEventListener('load', () => {
  // guarda em uma variável o elemento tasks-output
  todoOutput = document.getElementById('tasks-output');
  if (localStorage.getItem('tasks')) {
    todoList = JSON.parse(localStorage.getItem('tasks'));
    showList();
  } else {
    todoList = [];
  }

  if (todoList.length === 0) {
    todoOutput.innerHTML = 'Nenhuma tarefa cadastrada';
  }
  // adiciona o listener para o evento submit, utilizei form para usar o required do input HTML
  document.getElementById('form-task').addEventListener('submit', onSubmit);
  todoOutput.addEventListener('click', clickList);
});

Tentei comentar os pontos mais importantes do código, na listagem utilizo um map para montar nossa lista caso não esteja familiarizado só conferir a versão anterior desse código no git ou conferir os posts relacioanos a ecmaScript 2015, mas o código acima o usuário pode cadastrar as tasks que serão vinculadas uma data, quando o usuário clica no item da lista a propriedade “data-done” muda entre true ou false. caso o usuário queira limpar sua listas de task clica no botão “Limpar tarefas…” o código irá varrer da lista os itens com valor da propriedade data-done igual a true e retirar da lista.

Além do LocalStorage temos o SessionStorage, a diferença entre os dois é que o sessionStorage como o nome sugere ele guarda as informações apenas na seção ou seja, quando o aplicação é finalizada a informação é removida.

Fechamos por aqui e até o próximo tutorial

Media queries para Progressive Web Apps

Se você me segue no Twitter já viu que estou criando uma série sobre Progressive Web Apps, neste mini curso estou abordando os principais recursos na construção de um PWA. Para esse post vamos falar sobre um conteúdo complementar como adicionar um estilo específico através media queries para identificar uma PWA.

Se você ainda não ouviu falar sobre Progressive web apps ou aplicações web progressivas, PWA não é uma biblioteca ou framework, mas uma filosofia. Uma definição rápida seria o desenvolvimento de uma aplicação com uso de técnicas e recursos para proporcionar progressivamente uma melhor experiência para o usuário com foco em três pontos:

  • Confiabilidade
  • Velocidade
  • Engajamento

Quer saber mais acesse acompanhe a playlist do mini curso:

Também me siga no youtube para acompanhar mais vídeos

Voltando ao tema principal, quando construímos nossa PWA utilizamos o manifest.json, arquivo responsável por configurar nossa PWA, nome da aplicação(name e short_name), URL de inicialização(start_url), ícones(icons) e modo de exibição(display). O modo de exibição é o ponto chave deste tutorial e ele possui os seguintes modos:

  • fullscreen – como o nome sugere exibe em modo full screen sem nenhum elemento de interface do browser
  • standalone – Exibe como uma aplicação independente do browser, mas dependendo do sistema operacional podendo exibir alguns elementos de controle de navegação, por exemplo, iOS não exibe itens de navegação mas permite o controle de navegação através de gestos.
  • minimal-ui – Esse modo é exibido como uma aplicação independente mas forca a exibição de elementos de navegação
  • browser – Esse modo exibe como um browser convencional

Fullscreen e standalone

Agora que a gente teve uma introdução sobre os modos disponíveis, dois modos precisam de atenção especial fullscreen e standalone eles precisam prover uma navegação dentro da aplicação pois os elementos de navegação do browser são removidos, com isso o usuário pode ficar preso em sua aplicação e isso não é uma boa experiência.

Para isso podemos implementar media query para controlar a exibição controle de navegação ou apenas estilizar nossa aplicação. Atualmente temos um seletor para display-mode dentro de media queries, com isso podemos implementar media queries para diferentes modos, mas lembrando que a media query precisa seguir o parâmetro definido em seu manifest.json.

Media query para desktop e mobile

//media query para o modo de exibicao standalone presente tanto em mobile e desktop 
@media (display-mode: standalone) {
 
}

No código acima temos uma media query para o formato standalone, suportado por PWAs que rodam no desktop ou mobile, mas poderíamos utilizar um dos quatros padrões que vimos anteriores.

Um fato relevante neste momento até a versão 12.2 do iOS não temos suporte ao web app manifest em outras palavras iOS não utiliza o manifest.json, a definição de ícones e títulos para nossa PWA é feito através de meta tags dentro de nosso HTML, e elas apenas suportam o formato standalone.

Caso utilize um formato diferente de standalone precisamos ter duas media queries uma para android e outra para iOS

//media query para MacOS e iiOS
@media (display-mode: standalone) {
 
}

//media query para Android caso definido no manifest.json
@media (display-mode: fullscreen) {
 
}

Media query para iOS

Mas o código acima pode perder sua funcionalidade quando iOS começar a suportar web app manifest, mas caso queiramos ter uma estilização estritamente para iOS, por simples motivo cada sistema operacional tem seu guia de interface, por exemplo, Android geralmente exibe seus items de navegação na base da tela enquanto iOS exibe os elementos de navegação no topo da aplicação.

Com media query podemos incluir mais uma regra dentro de nosso media query o “@supports” com ele podemos realizar filtros através de features suportada pelo browser, por exemplo, suporte a display grid podemos utilizar o seguinte código:

@supports (display: grid) {
  div {
    display: grid;
  }
}

Agora que sabemos desse recurso como podemos implementar essa regra com PWA? Temos algumas features apenas suportada pelo iOS no caso temos “-webkit-overflow-scrolling” presente apenas no safari mobile. Com isso podemos da seguinte forma:

/* 
 - podemos utilizar display mode em: standalone, fullscreen, minimal-ui e browser
*/

@media (display-mode: standalone) {
  /*To das as pwas instaladas desktop e mobile */
}

@media (max-width: 576px) and (display-mode: standalone) {
  /* Filtro para pwas instalada apenas em dispositivos moveis */
  
  @supports (-webkit-overflow-scrolling: touch) {
    /* PWAs instaladas apenas no iOS */
  }
  
  @supports not (-webkit-overflow-scrolling: touch) {
    /* PWAs instaladas em dispositivos não iOS */
  }
}

Com o código acima cobrimos os principais casos para PWA, em breve estarei postando um vídeo sobre esse assunto. Caso tenha alguma dúvida só deixar um comentário.

Web Share api

Web Share API permite o usuário compartilhar conteúdo através do card de compartilhamento nativo do sistema operacional em que está sendo executado, nos dispositivos Android esse suporte surgiu na versão 61 do Chrome em 2017, já para para iOS o suporte foi incluído no Safari em 2019 na versão 12.2 do iOS.

Para fazer a chamada no card nativo de compartilhamento chamamos a função navigator.share() em nosso browser, esse método faz parte da Web Share API, ele dá o controle ao usuário de como ele quer compartilhar esse conteúdo. Seu uso é baseado em Promise, o método aceito um objeto com as informações de título, texto de descrição e url como podemos ver no código abaixo:

if (navigator.share) {
  navigator.share({
      title: 'Blog Fellyph Cintra',
      text: 'Como compartilhar conteúdo com web share API',
      url: 'https://blog.fellyph.com.br/',
  })
    .then(() => console.log('Compartilhamento realizado com sucesso'))
    .catch((error) => console.log('Erro no compartilhamento', error));
}

No exemplo acima, inicialmente utilizamos uma condicional para verificar se o suporte a web share api existe, caso positivo definimos o conteúdo que será compartilhado e adicionamos um then para tomar uma ação caso o compartilhamento seja realizado com sucesso ou catch em caso de error.

Requisitos

Para invocar o card nativos precisamos de alguns requisitos:

  • A URL deve ser servida por HTTPS
  • O método share deve ser invocado por uma resposta do usuário, por exemplo, um evento de click. Você não pode chamar a share API em um evento de page load.
  • Você só pode compartilhar uma URL dentro do escopo da aplicação
  • Sempre verifique se o usuário tem suporte a essa feature antes de chamar o método

Resultado

No lado esquerdo temos o resultado no iOS e a versao Android no lado direito

Na imagem acima temos dois exemplos de como o card de compartilhamento será exibido no Android e iOS. Para a plataforma iOS o recurso está disponível para Chrome e Safari. Vamos finalizamos por aqui caso tenha alguma dúvida só deixar um comentário.

Criando páginas single para cada categoria (Single templates) no WordPress – 2019

Esse post originalmente era de 2011, dei uma atualizada no conteúdo com alguns novos recursos e correções. Trabalhando com WordPress você tem um arquivo para cada situação específica, por exemplo, o arquivo responsável pela página de categoria é o arquivo category.php, ou page.php para uma página, ou 404.php quando o conteúdo não for encontrado.

Quando tratamos de post o arquivo mais específico é o single.php, por que o mais específico? Caso o single.php não exista o index.php será responsável por exibir o conteúdo da single ou o mais novo arquivo de template singular.php ele foi introduzido na versão 4.3 do WordPress para exibir o conteúdo de um post ou uma página. A imagem abaixo representa a ordem de carregamento:

Mas além dessas opções também podemos criar uma arquivo para a single de cada categoria, mas isso só é possível com trabalhando com três métodos diferentes: trabalhando com filtros , trabalhando com plugin ou trabalhando com condicional tags.

Carregando diferentes templates com add_filter

A primeira forma é adicionando um filtro para isso devemos adicionar-lo dentro do functions.php, o código ficará da seguinte forma:

add_filter('single_template', 'create_single_template');

function create_single_template( $template ) {
	global $post;

	$categories = get_the_category();
	// caso não tenhamos categoria retornamos o template default.
	if ( ! $categories )
			return $template; 

	//resgatando o post type
	$post_type = get_post_type( $post->ID );

	$templates = array();

	foreach ( $categories as $category ) {
			// adicionando templates por id e slug
			$templates[] = "single-{$post_type}-{$category->slug}.php";
			$templates[] = "single-{$post_type}-{$category->term_id}.php";
	}

	// adicionando os templates padrões
	$templates[] = "single-{$post_type}.php";
	$templates[] = 'single.php';
	$templates[] = 'singular.php';
	$templates[] = 'index.php';

	return locate_template( $templates );
}

Explicando código acima, aplicamos um filtro quando o WordPress chama o template para exibir um post, esse código é maior que a versão anterior desse post(2011), por duas razões continuamos retornando uma comportamento padrão e segundo realizamos um tratamento para não sobrescrever a single de um post type, exemplo, caso tenhamos uma categoria filme e um post type filme não termos conflito pois a single da categoria ‘filmes’ será single-post-filmes.php e a single do post type ‘filmes’ será single-filmes.php.

Carregando diferentes templates com Plugin

Alterar functions.php de forma errada pode afetar o funcionamento do todo o seu tema, para evitar problemas caso não domine muito programação a segunda forma é utilizando plugin, ainda sim você precisará de noções de programação para criar o novo template a diferença que qualquer erro afetará somente a página single que você estará criando.

Temos várias opções de plugins os passos serão bem parecidos, vou listar o plugin com atualizações mais recentes o Custom Post Template By Templatic:

  1. Baixe o plugin e instale o plugin em sua aplicação.
  2. Ative o plugin
  3. Crie um novo template para sua página single com um comentário no início do seu arquivo:
<?php
/*
PostType Page Template: [Nome para descrever seu template]
Description: [Essa parte é opcional]
*/
?>

Esse comportamento é bem parecido como template pages, nesse caso o nome do arquivo é irrelevante pode ser qualquer um. Feito isso se tudo ocorrer bem um dropdown irá aparecer na sua página de edição de posts para selecionar o template desejado.

A terceira forma é trabalhando com tags condicionais, elas são funções que funcionam como perguntas lógicas que retornam true ou false, para nossa solução iremos trabalhar com “in_category()”, para o nosso código não ficar extenso podemos dentro de nosso loop utilizar get_template_part como no exemplo abaixo:

// dentro do loop
if ( in_category( 'filmes' ) ) {
	get_template_part( 'template-parts/content', 'filmes' );
} else {
	get_template_part( 'template-parts/content', 'post' );
}

O código acima inserimos dentro de nosso single.php não criamos um template novo para toda nossa single e sim um pequeno bloco que será incluído pela função get_template_part, caso o post seja da categoria “filmes” ele ira buscar dentro da pasta template-parts o arquivo “content-filmes.php” nele você irá realizar a customização que você deseja, caso contrário carregamos o arquivo content-post.php um trecho genérico para outras categorias.

Mais infos sobre conditional tags : http://codex.wordpress.org/Conditional_Tags

Até o próximo post pessoal!