Contents tagged with Desenvolvimento

  • Offline Storage for Progressive Web Apps


    Offline Storage for Progressive Web Apps

    The Progressive Web App uses IndexedDB for application state and the Pokemon data set while the Cache API is used for URL addressable resources.

    2016 will hopefully be the year we build for network resilience.

    Internet connections can be flakey or non-existent on the go, which is why offline support and reliable performance are common features in Progressive Web Apps. In this post, I’ll summarize some ideas around offline data storage for PWAs — think the JSON payloads, images and general static data required to provide a meaningful experience offline.

    A recommendation for storing data offline:

    For URL addressable resources, use the Cache API (part of Service Worker). For all other data, use IndexedDB (with a Promises wrapper).

    Some quick answers to common questions on why:

    • Both APIs are asynchronous (IDB is event based and the Cache API is Promise based). They also work in Web Workers, Window and Service Workers.
    • IDB is available everywhere. Service Workers (and the Cache API) are available in Chrome, Firefox, Opera and are in development for Edge.
    • While IDB doesn’t support Promises, several strong libraries giving us Promise wrappers exist. See below for recommendations. The API has mandatory complexity (transactions, schema versioning) that these libraries also try to smooth over where possible.
    • Native support for IDB Promises has been proposed as have observers.
    • How much can you store? In Chrome and Opera: Your storage is per origin (rather than per API). Both storage mechanisms will store data until the browser quota is reached. Apps can check how much quota they’re using with the Quota Management API. Firefox: no limits, but will prompt after 50MB data stored. Mobile Safari: 50MB max, Desktop Safari: unlimited (prompts after 5MB), IE10+ maxes at 250MB and prompts at 10MB. PouchDB track IDB storage behavior. Future facing: For apps requiring more persistent storage, see the on-going work on Durable Storage.
    • Safari 10 has fixed many long-standing IDB bugs in their latest Tech Previews. That said, some folks have run into stability issues with Safari 10’s IDB and PouchDB have found it to be a little slow. Until more research has been done here, YMMV. Please do test and file browser bugs so the folks @webkit and related OSS library authors can take a look. LocalForage, PouchDB, YDN and Lovefield use WebSQL in Safari by default due to UA sniffing (there wasn’t an efficient way to feature-test for broken IDB at the time). This means these libraries will work in Safari 10 without extra effort (just not using IDB directly).
    • URL addressable resources are typically static resources that at a URL. For PWAs, you could cache the static files composing your application shell (JS/CSS/HTML files) in the Cache API and fill in the offline page data from IndexedDB. There are no hard and fast rules around this however. Some applications might be sufficiently simple that they can just use the Cache API alone while others may find it valuable to partially cache their JSON payloads in IDB so that in browsers without Cache API support you still get the benefit of some local caching during the session.
    • Debugging support for IndexedDB is available in Chrome (Application tab), Opera, Firefox (Storage Inspector) and Safari (see the Storage tab). Debugging IDB is not currently supported in Edge (however, it is possible to debug the underlying JetDB) — vote here for built in support.

    IndexedDB Libraries worth checking out

    • localForage(~8KB, Promises, good legacy browser support)
    • idb-keyval (<500 bytes, Promises, use if only need key-value support)
    • idb (~1.7KB, Promises, also does iteration, indexing)
    • Dexie (~16KB, Promises, complex queries, secondary indices)
    • PouchDB (~45KB (supports custom builds), synchronization)
    • Lovefield(relational)
    • LokiJS (in-memory)
    • ydn-db(dexie-like, works with WebSQL)

    Service Worker Libraries worth checking out

    • sw-toolbox (offline caching for dynamic/runtime requests)
    • sw-precache (offline precaching for static assets/application shells)
    • Webpack users can directly use the above or offline-plugin

    What about other storage mechanisms?

    • Web Storage (e.g LocalStorage) is synchronous, has no Web Worker support and is size-limited (only strings). Although ideas for async LS have been kicked around in the past, current focus is on getting IndexedDB 2.0in a good state. I would personally use IDB + a library.
    • Cookies have their uses but are synchronous, lack Web Worker support and are size-limited. In previous projects I’ve used js-cookie for handling cookies via JS (~800bytes gzipped). Support for an Async Cookies API is being sketched out right now with a polyfill in the works.
    • WebSQL is asynchronous (callback-based), however it also has no Web Worker support and was rejected by Firefox and Edge but is in Chrome and Safari.
    • File System API is asynchronous too (callback-based) and does work in Web Workers and Windows (albeit with a synchronous API). Unfortunately it doesn’t have much interest outside of Chrome and is sandboxed (meaning you don’t get native file access).
    • File API is being improved over in the File and Directory Entries API and File API specs. A File API library exists and for file-saving, I’ve been using FileSaver.js as a stop-gap. The writable-files proposal may eventually give us a better standards-track solution for seamless local file interaction.

    Current and future offline storage work

    If offline storage interests you, the below efforts are worth keeping an eye on. I’m particularly excited about Promises support in IndexedDB being possible without the need for a library.

    IDB with some sweet await goodness.


    Offline storage isn’t quite magical and an understanding of the underlying APIs will go far in helping you make the most out of what we now have available. Whether you prefer to directly use these APIs or work with an abstraction library, take some time to get familiar with your options.

    Hopefully this will help craft an offline experience that makes your PWA ✨

    With thanks to Nolan Lawson, Joshua Bell (whose work on Open Web Storage and BlinkOn talk heavily inspired this article), Jake Archibald, Dru Knox and others for their previous work in the web storage space.

    Update September 2nd 2016 with some more FAQ:

    What eviction gotchas exist for IndexedDB and the Cache API? Is it possible to currently guarantee that a response will always be available offline?

    An origin is given an amount of space to do with as it pleases. This free space is shared across all forms of origin storage (IndexedDB, Cache API, localStorage etc). This amount given isn’t specified and will vary depending on device and storage conditions (e.g if the device is already pretty constrained).

    When web storage is low (under pressure), a UA will clear storage to make space available. This can suck for offline apps and so the recently updated Storage spec defines a “persistent” and “best effort” strategy here with “best effort” being the default. “best effort” means the storage can be cleared without interrupting the user, but means it is less durable for long-term or super critical data. IndexedDB and the Cache API fall into the “best effort” bucket today.

    “persistent” storage is not automatically cleared when storage is low and the user will need to manually clear out this storage (via browser settings) themselves. Chrome has been experimenting with support for Persistent Storage under an origin trial, and the latest news suggests it will be shipping in Chrome 55.

    How can I tell how much storage space my app is using?

    The Quota Management API lets you query for the size of storage space currently used and how much is available to the application. It also enables requesting for more storage if needed. A newer Storage Quota Estimate APItries to make it even easier to discover how much quota an origin is using with support for Promises.


  • - erro 404 (not found) ao tentar clonar um repositório


    Para quem está com problemas sobre não conseguir clonar um repositório do GitLab fica a dica.

    Resumindo: o problema é sobre a credencial salva no Windows não aceita pelo GitLab.

    Abaixo a tela de erro após tentar clonar pelo TortoiseGit (com qualquer aplicativo daria problema):

    Mesmo após tentar configurar as credenciais avulsas o Git insistia em buscar a configuração que estava gravada no Windows (10):

    Esse era o motivo, a credencial salva no Windows estava sendo aplicada mesmo eu indicando outra, no caso do GitLab a mensagem de erro retornada não é nada sugestiva diga-se de passagem, sendo retornado um erro HTTP 404, sendo que o erro é de credencial inválida.

    No meu caso eu preferi editar a credencial existente com o usuário e senha corretos:

    Após a correção o processo de clonagem do repositório funcionou sem problemas:



  • ASP.NET MVC - Retornando um erro 500 com mensagem (explicando quando ocorre status code = 0)


    Em desenvolvimento web podemos (devemos!) trabalhar com código protegido no lado do servidor (entre try...catch), para então - também - trabalharmos com mensagens amigáveis ao usuário, para isso para uma exceção gerada no servidor retornamos também a mensagem de erro tratada.

    O exemplo abaixo é só um snippet no contexto MVC considerando método POST no Controller com retorno do tipo ActionResult:

    ​Então no bloco catch temos:


    return new HttpStatusCodeResult(HttpStatusCode.InternalServerError, mensagem);  

    Sendo que a variável mensagem tem o valor de "ERROR FORÇADO NO SERVIDOR".

    Como resultado da chamada temos o seguinte retorno:

    Tudo certo, mensagem retornada, status code = 500.




    Em uma outra simulação.


    return new HttpStatusCodeResult(HttpStatusCode.InternalServerError, mensagemMuitoGrande);



    Digamos então que a variável mensagemMuitoGrande tenha um valor grande (não sei precisar o limite), pode ser um log mais completo do erro, não sei, qualquer conteúdo string que extrapole o limite.


    Você então irá se deparar com um problema que está relacionado ao tamanho do response e com isso a interceptação da exceção gerada terá um status code = 0, ao invés de 500, e nada de mensagem retornada.

    A informação mais completa no rastreamento da rede (fico devendo a imagem) exibe como "aborted", ou seja, o tal limite atingido faz com que o retorno do request seja "cancelado/abortado".



  • Tabela de acentos em JavaScript


    Quem trabalha com desenvolvimento em Javascript de vez em sempre precisa utilizar frameworks de terceiros (ExtJS, Bootstrap, Jquery, AngularJS, DevExtreme e outras) ou mesmo construir uma própria código nativo.

    Sobre acentuação, em alguns casos a meta tag charset pode não ser suficiente para corrigir problemas de textos exibidos ao usuário com caracteres estranhos.

    Para a situação citada você pode substituir os acentos por códigos.

    Abaixo uma tabela com os tais caracteres e os seus substitutos:

    á = \u00e1

    à = \u00e0

    â = \u00e2

    ã = \u00e3

    ä = \u00e4

    Á = \u00c1

    À = \u00c0

    Â = \u00c2

    Ã = \u00c3

    Ä = \u00c4

    é = \u00e9

    è = \u00e8

    ê = \u00ea

    ê = \u00ea

    É = \u00c9

    È = \u00c8

    Ê = \u00ca

    Ë = \u00cb

    í = \u00ed

    ì = \u00ec

    î = \u00ee

    ï = \u00ef

    Í = \u00cd

    Ì = \u00cc

    Î = \u00ce

    Ï = \u00cf

    ó = \u00f3

    ò = \u00f2

    ô = \u00f4

    õ = \u00f5

    ö = \u00f6

    Ó = \u00d3

    Ò = \u00d2

    Ô = \u00d4

    Õ = \u00d5

    Ö = \u00d6

    ú = \u00fa

    ù = \u00f9

    û = \u00fb

    ü = \u00fc

    Ú = \u00da

    Ù = \u00d9

    Û = \u00db

    ç = \u00e7

    Ç = \u00c7

    ñ = \u00f1

    Ñ = \u00d1

    &amp; = \u0026

    ' = \u0027


  • Monitorando ataques a aplicações Web em ASP.NET


    As aplicações que desenvolvi para clientes possuem um mecanismo de log que implementei que também detecta erros na requisição de rotas ASP.NET MVC além de erros de aplicação, validações, regras de negócio e outros.

    Inicialmente quando pensei em fazer isso não imaginava que seria útil para outrs fins, de vez em quando recebo e-mails de requisições de tentativas fúteis em encontrar falhas de segurança na aplicação baseadas em requests lançados a esmo por crackers querendo invadir sites nem que seja apenas para defacing.

    Fúteis pois são como tiro no escuro numa sala vazia, ou seja, nunca acertará nada no meu caso pelo menos, tentam explorar falhas de frameworks ou aplicações em Javascript, JSP ou PHP.

    Uma pequena lista de falhas que tenta explorar:

    • Error: The controller for path '/testproxy.php' was not found or does not implement IController.
    • Error: The controller for path '/menuBcm.js' was not found or does not implement IController.
    • Error: The controller for path '/web-console/ServerInfo.jsp' was not found or does not implement IController.
    • Error: The controller for path '/modules/simpleslideshow/uploadimage.php' was not found or does not implement IController.
    • Error: The controller for path '/license.php' was not found or does not implement IController.
    • Error: The controller for path '/wp-login.php' was not found or does not implement IController.
    • Error: The controller for path '/AdServer/UCookieSetPug' was not found or does not implement IController.

    Estou pensando em realmente entrar na brincadeira simulando a página como a que tentam acessar para extrair a informação que estão tentando submeter.

  • LINQ :: Select().Max() considerando retorno que pode ser nulo


    Para quem desenvolve sistemas e trabalha com LINQ e banco de dados, pode existir uma situação em que seja necessário fazer o que utilizando SQL convencional seria um SELECT MAX(campo), sendo que normalmente campo uma chave primária (particularmente eu trabalho com PKs identity ou sequences).

    O objetivo é simples, encontrar o maior valor para um determinado campo.

    A sugestão utilizando LINQ é algo como:

    decimal consultaId = ContextoBD.Query&lt;TipoDominio&gt;()     .Select(x =&gt; (decimal?)x.Id)     .Max() ?? 0; var maiorId = (consultaId + 1); return (int)maiorId;

    Mas então a pergunta, "qual o detalhe do código, não seria óbvio só utilizar o método Select() e então Max() diretamente para uma variável Int?".
    Só que isso não funciona em todos os casos!
    O detalhe no código acima está em utilizar um tipo decimal como retorno com um cast nulável da coluna alvo (Id) e um operador de coalescência nula garantindo 0 como retorno.
    O motivo por tal manobra é que o LINQ irá falhar caso exista algum valor nulo (ou coleção vazia) e tentará retornar um valor nulo para um tipo Int, mesmo que você determinei que possa aceitar Int?, pra mim isso é um bug, mas enfim, o código garantirá um valor zero nas condições que de maneira convencional daria um erro em tempo de execução, sim, porque em tempo de compilação não daria erro.

  • IIS Express - resolver problemas de cache


    Quem desenvolve com o Visual Studio deve, em algum momento, ter esbarrado com algum comportamento estranho do IIS Express após alguma mudança de arquivos do projeto fora do contexto do Visual Studio.

    A solução que encontrei foi a exclusão do site no IIS Express para que seja posteriormente criado pelo Visual Studio, assim como da primeira vez.

    $appCmd = "C:\Program Files (x86)\IIS Express\appcmd.exe"
    $result = Invoke-Command -Command {&amp; $appCmd 'list' 'sites' '/text:SITE.NAME' }
    for ($i=0; $i -lt $result.length; $i++)
        Invoke-Command -Command {&amp; $appCmd 'delete' 'site'  $result[$i] }

    Esse snippet exclui todos os sites, mas pode ser facilmente adaptado para um apenas.

  • Login em uma URL com redirecionamento para outra após a autenticação


    A necessidade é bem simples, autenticar num site web e então após isso redirecionar para outra URL.

    O fato esperado é que após ocorrer o submit para a URL da action o contexto da página corrente não existe mais, claro, então rotinas colocadas por exemplo no evento "onsubmit" do form não funcionarão. Pelo mesmo motivo quaisquer rotinas a serem executadas por um setTimeout() na página também não serão executados, que foi um caso que tentei, um timer local considerando que se passaram X segundos e que nesse período a autenticação ocorreu.

    Além desse problema de contexto alterado houve ainda problemas sobre CORS quando tentei utilizar um código mais limpo com XMLHttpRequest fazendo o POST para a URL da action, então a solução mais simplista e funcional foi:

    1. Copiar o HTML original da página de autenticação.
    2. Pré-preencher os valores de usuário e senha.
    3. Simular o clique no botão, na verdade não o método click, mas o método submit.
    4. Meta tag para fazer o redirecionamento para a página destino desejada.
    Mas o segredo mesmo para se manter no contexto foi o "target" do form ser um iframe, nesse caso usar a Metatag foi só para evitar mais um script, eu poderia usar um setTimeout(), mesmo o onsubmit funcionaria.

    Abaixo a solução para o mundo ideal (usuário e senha corretos por exemplo).
    Veja que a solução é HTML+Javascript puro, nada de JQuery ou outra framework.

    <meta http-equiv="refresh" content="5; url=http://URL_APOS_AUTENTICAR">
    <form action="http://URL_DE_AUTENTICA" method="post" name="acesso" id="acesso" target="logado" hidden="hidden">
        <input name="nome" type=text size=30 maxlength=30 value='usuário'>
        <input name="senha" type=password size=30 maxlength=30 value='senha'>
        <input type="submit" name="Entrar" id="Entrar" value="Entrar">
    <iframe name="logado" id="logado" hidden="hidden"></iframe>
    <h2>Executando processo de autenticação, aguarde...</h2>
        // autentica para o iframe escondido.

  • Microsoft abraça o Open Source de verdade no desenvolvimento de aplicações


    Após um bom tempo apenas cozinhando Open Source, parece que a Microsoft resolveu definitivamente abraçar a causa.

    .NET Foundation Projects

    Projects under the stewardship of the .NET Foundation currently include the .NET Compiler Platform ("Roslyn") as well as the ASP.NET family of projects, both of which were open sourced by Microsoft Open Technologies, Inc. (MS Open Tech). Xamarin has contributed several open source .NET projects, including the very popular Mailkit and Mimekit projects. We’re actively engaged in bringing many more projects into the foundation, see our blog for the latest announcements.

    Pick a project below to learn more about it and how to contribute:


  • Problema de rolagem de HTML em iframe no iOS


    O "Causo"

    Recentemente tive um problema que, consultando vários fóruns, confirmei que realmente existe uma situação única de problema de rolagem de conteúdo HTML em um iframe em qualquer browser executado no iOS.

    Como é que funciona?

    Os browsers em dispositivos móveis adequam a rolagem de conteúdo com aquela forma elástica que ocorre quando a gente segura a tela com o dedo e arrasta para cima ou para baixo e então soltando o conteúdo vai rolando na direção que soltou sozinho até parar.

    Nessa condição a scrollbar padrão, aquela feiura antiquada, dá lugar a outra, e o comportamento de clique muda também para se comportar da maneira citada, toque, segura e solta.

    Essa mudança de visual e funcionamento difere da execução em desktop em que aparece a barra de rolagem e o conteúdo rola apenas ao clicar na barra lateral ou com teclas de atalho (page down, up e etc), e se segurar o cursor do mouse com o clique em algum ponto irá marcar texto (alguns browser permitem mudar esse comportamento para tipo o estilo mobile).

    Sim, mas e daí?

    Esbarrei pelo problema usando o Ext.Net (ExtJS), na verdade não é culpa dele, mas sim do iframe em que o conteúdo HTML é embutido. O funcionamento do sistema era abrir rotas/URLs em janelas dentro da principal simulando o funcionamento de janelas do Windows por exemplo, mas para isso a parte interna das janelas é um iframe.

    O fato apenas ocorre no iOS, em qualquer Android funciona, no caso não havia a mudança para o estilo mobile, continuava o HTML com rolagem estilo desktop.

    Então depois de algumas pesquisas em fóruns, vários indicavam a pequena

    Basicamente o funcionamento é o de se colocar uma DIV dentro de outra DIV, cada uma com o seu devido CSS aplicado (tem tudo no site), e no onLoad() da página instanciar um objeto da iScroll (bastante sugestivo o prefixo do nome).

    Na minha aplicação passei por mais problemas, pois trabalhando com o ExtJS vi que não poderia utilizar os Ext.Panels padrões pela injeção de HTML indesejado, cheguei até a testar mas não funcionou, de qualquer maneira consegui contornar usando o iScroll na forma mais simples, pelos próprios exemplos do site dele.

    Eu cheguei a ver algumas soluções baseadas em ExtJS mas achei muito, mas muito complexas, exageradamente...criação de componentes com herança, eventos e etc, muita ladainha para uma necessidade mais direta de aplicar, e olha que no meu caso eu tinha alguns poréns a mais:

    1. Store é atualizada disparando evento DataChanged...
    2. ...DataView atrelada à Store renderiza conteúdo...
    3. ...captura do HTML renderizado na DataView...
    4. ...injeção do HTML dentro da DIV mais interna usada pelo iScroll.

    Só serve para isso?


    Existem algumas outras funções bastante interessantes como zoom, scroll infinito (carga de HTML por demanda) e outras, que um dia irei explorar, o importante é saber que há como fazer e o iScroll é a solução atual mais simples e leve de aplicar.

    Mas lembre-se!

    Apenas para ficar ciente, o comportamento do scroll de conteúdo passará a ser "estilo" mobile mesmo em browser no desktop, ou seja, para rolar tem-se que clicar, segurar e jogar o cursor para uma direção, prático como se utiliza um tablet e celular, mas pode ser que alguns usuários estranhem no desktop.