Ao imprimir aplicativos da Windows Store no JavaScript, você encontra construções chamadas de promessas assim que você faz algo que envolva uma API assíncrona. E também não leva muito tempo para que cadeias de promessa de gravação para operações assíncronas sequenciais se tornem algo como uma segunda pele.

No entanto, durante seu trabalho de desenvolvimento, você provavelmente encontrará outros usos de promessas em que não ficará totalmente claro o que está acontecendo. Um bom exemplo disso é a otimização de funções de renderização de item para o controle de um ListView como mostrado na amostra de desempenho de otimização do ListView em HTML. Exploraremos isso em uma postagem subsequente. Ou considere essa joia que Josh Williams mostrou em sua palestra Deep Dive into WinJS em //build 2012 (ligeiramente modificada):

list.reduce(function callback (prev, item, i) {
    var result = doOperationAsync(item);
    return WinJS.Promise.join({ prev: prev, result: result}).then(function (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Este trecho reúne as promessas de operações assíncronas paralelas e fornece seus resultados sequencialmente, de acordo com a ordem na lista. Se você puder olhar para esse código e entender imediatamente sua função, fique à vontade para ignorar esta postagem! Caso contrário, vamos observar melhor o funcionamento de promessas e sua expressão no WinJS (a Biblioteca do Windows para JavaScript) para que possamos compreender esses tipos de padrão.

O que é uma promessa? Os relacionamentos entre promessas

Vamos começar por uma verdade fundamental: uma promessa nada mais é do que uma construção de código ou, se você achar melhor, uma convenção de chamadas de função. Como tal, as promessas não têm relacionamentos inerentes com as operações assíncronas, elas só são muito úteis nesse aspecto! Uma promessa é simplesmente um objeto que representa um valor que pode estar disponível em algum momento no futuro, se já não estiver. Dessa forma, uma promessa tem o mesmo significado do uso da palavra em relacionamentos humanos. Se eu disser, “Prometo te dar uma dúzia de donuts”, com certeza não preciso ter esses donuts no momento, mas certamente suponho que terei em algum momento no futuro. E quando tiver, vou te dar.

Portanto, uma promessa indica um relacionamento entre dois agentes: a origem que faz a promessa de fornecer algumas mercadorias e o consumidor, que é o destinatário dessa promessa e das mercadorias. A maneira como obterá essas mercadorias é de responsabilidade da origem. Da mesma maneira, o consumidor pode fazer o que quiser com a própria promessa e as mercadorias fornecidas. Ele pode até compartilhar a promessa com outros consumidores.

Entre a origem e o consumidor também há dois estágios desse relacionamento: criação e cumprimento. Tudo isso é mostrado no diagrama a seguir.

Esses dois estágios do relacionamento são o motivo pelo qual as promessas funcionam bem com o fornecimento assíncrono, como podemos ver se seguirmos o fluxo do diagrama. A parte principal é que uma vez que o consumidor obtiver a confirmação da solicitação, a promessa, ele poderá seguir sua vida (de forma assíncrona) em vez de esperar (de forma síncrona). Isso significa que o consumidor pode realizar outras tarefas enquanto espera a promessa ser cumprida, como responder a outras solicitações, que é o principal objetivo das APIs assíncronas. E se as mercadorias já estiverem disponíveis? Então a promessa será imediatamente cumprida, fazendo com que todo o processo se torne um tipo de convenção de chamadas de função.

Obviamente, esse relacionamento é composto por outros elementos que devemos considerar. Com certeza você já fez promessas na sua vida e já fizeram promessas para você também. Embora muitas dessas promessas tenham sido cumpridas, a realidade é que muitas promessas não são. É possível que o entregador de pizza sofra um acidente no caminho para a sua casa! Promessas que não são cumpridas são mais um fato da vida e temos que aceitar isso em nossas vidas pessoais e de programação assíncrona.

No relacionamento de promessas, portanto, isso significa que a origem precisa de uma forma de dizer “desculpe, mas não vou conseguir cumprir essa promessa” e o cliente precisa de uma maneira de saber quando esse for o caso. Em segundo lugar, como consumidores podemos, às vezes, ser um pouco impacientes com promessas feitas para nós. Portanto, se a origem puder controlar seu progresso no cumprimento da promessa, o consumidor também precisará de uma maneira de receber essas informações. Em terceiro lugar, o consumidor também pode cancelar o pedido e dizer para a origem que não precisa mais da mercadoria.

Adicionando esses requisitos ao diagrama, podemos ver o relacionamento completo:

Vamos ver como esses relacionamentos são manifestados em códigos.

A construção da promessa e cadeias de promessa

Na verdade, existem várias propostas ou especificações diferentes para promessas. As usadas no Windows e WinJS são chamadas de Common JS/Promessas A, que dizem que uma promessa (o que é retornado por uma origem para representar um valor a ser fornecido no futuro) é um objeto com uma função chamada de then. Os consumidores se inscrevem para o cumprimento da promessa chamando then. (As promessas no Windows também dão suporte a uma função similar chamada de done usada em cadeias de promessas, como veremos em breve.)

Para essa função, o consumidor passa até três funções opcionais como argumentos, nesta ordem:

1. Um manipulador completo. A origem chama esta função quando o valor da promessa está disponível e se esse valor já estiver disponível, o manipulador completo será chamado imediatamente (sincronamente) de dentro da função then.
2. Um manipulador de erros opcional chamado em caso de falhas para adquirir o valor prometido. Para qualquer promessa, o manipulador completo nunca será chamado se o manipulador de erros tiver sido chamado.
3. Um manipulador de progresso opcional chamado periodicamente com resultados intermediários, se a operação der suporte. (No WinRT, isso significa que a API tem um valor de retorno de IAsync[Action | Operation]WithProgress; aquelas com IAsync[Action | Operation] são diferentes.)

Observe que você pode passar como nulo para qualquer um desses argumentos, como quando você quiser anexar somente um manipulador de erros e não um manipulador completo.

Em outro aspecto do relacionamento, um consumidor pode inscrever quantos manipuladores quiser para a mesma promessa chamando then várias vezes. Ele também pode compartilhar a promessa com outros consumidores que também podem chamar then quando quiserem. Isso é totalmente permitido.

Isso significa que uma promessa precisa gerenciar listas dos manipuladores recebidos e invocá-los nos momentos apropriados. As promessas também precisam permitir o cancelamento, como descrito no relacionamento completo.

O outro requisito da especificação Promessas A é que o próprio método then retorna uma promessa. A segunda promessa é cumprida quando o manipulador completo dado para o primeiro promise.then é retornado, com o valor de retorno fornecido como resultado dessa segunda promessa. Considere este trecho do código:

var promise1 = someOperationAsync();
var promise2 = promise1.then(function completedHandler1 (result1) { return 7103; } );
promise2.then(function completedHandler2 (result2) { });

A cadeia de execução aqui é o início de someOperationAsync, retornando a promise1. Enquanto a operação estiver em andamento, chamaremos a promise1.then, que retornará a promise2 imediatamente. Esteja ciente de que o completedHandler1 não será chamado a menos que o resultado da operação assíncrona já esteja disponível. Vamos supor que ainda estamos esperando, então seguimos diretamente para a chamada da promise2.then e, novamente, o completedHandler2 não será chamado nesse momento.

Algum tempo depois, a someOperationAsync será concluída com um valor de, digamos, 14618. A promise1 já foi cumprida, portanto, chamará o completedHandler1 com esse valor, de forma que o result1 seja 14618. Agora, o completedHandler1 será executado, retornando o valor 7103. Neste momento, a promise2 é cumprida, portanto, chama o completedHandler2 com result2 equivalente a 7103.

E se um manipulador completo retornar outra promessa? Esse caso é resolvido de forma diferente. Digamos que o completedHandler1 do código acima retorne esta promessa:

var promise2 = promise1.then(function completedHandler1 (result1) {
    var promise2a = anotherOperationAsync();
    return promise2a;
});

Nesse caso, o result2 no completedHandler2 não será a própria promise2a, mas o valor de cumprimento da promise2a. Ou seja, como o manipulador completo retorna uma promessa, a promise2 como retornada da promise1.then, será cumprida com os resultados da promise2a.

Essa característica é exatamente o que torna possível o encadeamento de operações assíncronas sequenciais, em que os resultados de cada operação na cadeia é alimentado na próxima. Sem variáveis intermediárias ou manipuladores nomeados, normalmente, você encontra esse padrão para cadeias de promessas:

operation1().then(function (result1) {
    return operation2(result1)
}).then(function (result2) {
    return operation3(result2);
}).then(function (result3) {
    return operation4(result3);
}).then(function (result4) {
    return operation5(result4)
}).then(function (result5) {
    //And so on
});

Cada manipulador completo, claro, provavelmente fará mais com os resultados recebidos, mas essa estrutura principal é comum a todas as cadeias. O que também acontece é que todos os métodos then aqui são executados em sequência, já que tudo que estão fazendo é economizar o manipulador completo e retornar outra promessa. Portanto, até chegarmos ao final desse código, somente a operation1 terá sido iniciada e nenhum manipulador completo terá sido chamado. Mas várias promessas intermediárias de todas as chamadas then foram criadas e ligadas umas as outras para gerenciar a cadeia como o progresso de operações sequenciais.

Vale a pena observar que a mesma sequência pode ser obtida pelo aninhamento de cada operação subsequente dentro do manipulador completo. Nesse caso, você não terá todas as declarações de returno. No entanto, esses aninhamentos se tornam um pesadelo de recuo, principalmente se você começar a adicionar manipuladores de progresso e erros a cada chamada para then.

Falando nisso, um dos recursos das promessas no WinJS é que os erros que ocorrem em qualquer parte da cadeia são automaticamente para o final da cadeia. Isso significa que você pode simplesmente anexar um único manipulador de erros na última chamada para then em vez de ter manipuladores em todos os níveis. O problema, no entanto, é que por vários motivos sutis, esses erros são engolidos se o último link na cadeia for uma chamada para then. Por isso, o WinJS fornece um método done nas promessas. Este método aceita os mesmos argumentos de then, mas indica que a cadeia está completa (ele retorna indefinido em vez de outra promessa). Qualquer manipulador de erros anexado ao done será chamado em caso de erros em toda a cadeia. Além disso, sem um manipulador de erros, o done enviará uma exceção para o nível do aplicativo, onde poderá ser manipulado pelo window.onerror de eventos WinJS.Application.onerror. Resumindo, todas as cadeiras deveriam terminar, idealmente, em done para garantir que exceções sejam exibidas e manipuladas corretamente.

É claro que se você escrever uma função com objetivo de retornar a última promessa de uma longa cadeia de chamadas then, você ainda usará then ao final: a responsabilidade de manipulação de erros, então, pertence ao chamados que pode usar essa promessa em outra cadeia totalmente diferente.

Criação de promessas: a classe WinJS.Promise

Embora você sempre possa criar suas próprias cadeias de promessa com base na especificação Promessas A, na verdade, isso é muito trabalhoso e pode ser realizado melhor por uma biblioteca. Por isso, o WinJS fornece uma classe de promessas eficiente, bem testadas e flexíveis chamada de WinJS.Promise. Isso permite que você crie facilmente promessas com base em valores e operações diferentes sem precisar gerenciar os detalhes dos relacionamentos de origem/consumidor ou o comportamento de then.

Quando necessário, você pode (e deve) usar o novo WinJS.Promise, ou uma função de ajuda adequada, como observado na próxima seção, para criar promessas com base em operações e valores existentes (síncronos) da mesma maneira. Lembre-se de que uma promessa é apenas uma construção de código: não há requisitos que exijam que uma promessa tenha que englobar uma operação assíncrona ou qualquer outro aspecto assíncrono. Da mesma maneira, o simples ato de englobar alguma parte de código em uma promessa não faz com que ele seja executado assincronamente. Você ainda precisa fazer esse trabalho.

Como um exemplo simples do uso direto de WinJS.Promise, digamos que queremos executar uma longa computação (adição de vários números de um para algum valor máximo), mas de forma assíncrona. Poderíamos inventar nosso próprio mecanismo de retorno de chamada para essa rotina, mas se englobarmos isso dentro de uma promessa, permitiremos que ela seja encadeada ou combinada a outras promessas de outras APIs. (Parecido com isso, a função WinJS.xhr engloba a XmlHttpRequest assíncrona do JavaScript dentro de uma promessa para que você não precise lidar com a estrutura de eventos dela.)

Também podemos usar um trabalho do JavaScript para uma computação longa, é claro, mas devido à ilustração, vamos mantê-lo no thread da interface e usar o setImmediate para dividir a operação em etapas. Veja como podemos implementá-lo em uma estrutura de promessas usando WinJS.Promise:

function calculateIntegerSum(max, step) {
    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum);
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);
                setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    });
}

Ao chamar o novo WinJS.Promise, o único argumento para sua construção em uma função de inicializador (nesse caso, anônimo). O inicializador encapsula a operação a ser executada, mas esteja ciente de que esta função sozinha é executada de forma síncrona no thread de interface. Então se executarmos um longo cálculo aqui sem usar o setImmediate, bloquearíamos o thread de interface para todo esse tempo. Novamente, a colocação de um código dentro de uma promessa não faz com que ela seja automaticamente síncrona, a função de inicializador precisa configurar isso.

Para argumentos, a função de inicializador recebe três distribuidores para os casos completos, de erro e progresso que recebem suporte das promessas. Como você pode ver, chamamos esses distribuidores em momentos apropriados durante a operação com os argumentos apropriados.

Chamo eles de “distribuidores” de função, porque eles não são iguais aos manipuladores que os consumidores inscrevem no método then da promessa (ou done, mas já falei sobre isso). Nos bastidores, o WinJS está gerenciando matrizes desses manipuladores, que é o que permite que qualquer número de consumidores se inscreva em qualquer número de manipuladores. Quando você invoca um desses distribuidores, o WinJS reitera por meio de sua lista interna e invoca todos esses manipuladores em seu nome. O WinJS.Promise também garante que seu then retorne outra promessa, como exigido para o encadeamento.

Resumindo, o WinJS.Promise fornece todos os detalhes ao redor de uma promessa. Isso permite que você se concentre na operação principal representada pela promessa, que é incorporada na função do inicializador.

Ajuda na criação de promessas

A função principal da ajuda para criar uma promessa é o método estático WinJS.Promise.as, que engloba qualquer valor em uma promessa. Esse wrapper em um valor já existente simplesmente volta ao início e chama qualquer manipulador completo para then. Especificamente, isso permite que você trate valores conhecidos arbitrários como promessas de tal forma que você possa fazer misturas e composições (juntando ou encadeando) com outras promessas. Usando da mesma forma que uma promessa existente apenas retorna essa promessa.

A outra função de ajuda estática é WinJS.Promise.timeout, que fornece um wrapper conveniente com base em setTimeout e setImmediate. Você também pode criar uma promessa que cancele uma segunda promessa se essa segunda não tiver sido cumprida em um determinado número de milissegundos.

Observe que as promessas tempo de espera com base em setTimeout e setImmediate são cumpridas com indefinido. Uma pergunta comum é “como elas podem ser usadas para fornecer um resultado diferente após o tempo de espera?” A resposta usa o fato de que then retorna outra promessa cumprida com o valor de retorno do manipulador completo. Esta linha de código, por exemplo:

var p = WinJS.Promise.timeout(1000).then(function () { return 12345; });

cria a promessa p que será cumprida com o valor 12345 depois de um segundo. Em outras palavras, WinJS.Promise.timeout(…).then(function () { return <value>} ) é um padrão para fornecer <value> após o determinado tempo de espera. E se o próprio <value> for outra promessa, isso significa fornecer o valor de cumprimento dessa promessa em algum momento após o tempo de espera.

Cancelamento e geração de erros de promessa

No código que acabamos de ver, você deve ter percebido duas deficiências. A primeira é que não há como cancelar a operação depois que ela é iniciada. A segunda é que não fazemos um trabalho muito bom lidando com erros.

O truque nesses dois casos são funções de produção de promessa, como a função calculateIntegerSum que deve sempre retornar uma promessa. Se uma operação não for concluída ou não for iniciada em primeiro lugar, essa promessa fica no que chamamos de estado de erro. Isso significa que a promessa não tem e nunca terá um resultado que possa passar para qualquer manipulador completo: só sempre chamará seus manipuladores de erros. De fato, se um consumidor chamar then em uma promessa, que já está no estado de erro, a promessa invocará imediatamente (de forma síncrona) o manipulador de erro fornecido para then.

Um WinJS.Promise insere o estado de erro por dois motivos: o consumidor chama seu método cancelar ou o código na função de inicializador chama o distribuidor de erros. Quando isso acontece, os manipuladores de erro recebem qualquer valor de erro que tenha sido pego ou propagado na promessa. Se você estiver criando uma operação em uma WinJS.Promise, também pode usar uma instância de WinJS.ErrorFromName. Esse é apenas um objeto do JavaScript que contém uma propriedade name que identifica o erro e uma propriedade message com mais informações. Por exemplo, quando uma promessa é cancelada, os manipuladores de erros recebem um objeto de erro com nome name e message configurado para “Cancelado”.

Mas e se você não conseguir nem iniciar a operação? Por exemplo, se você chamar calculateIntegerSum com argumentos ruins (como 0, 0), ele não deve nem tentar iniciar a contagem e, em vez disso, deve retornar a promessa no estado de erro. Esse é o objetivo do método estático WinJS.Promise.wrapError. Isso exige uma instância de WinJS.ErrorFromName e retorna uma promessa no estado de erro, que retornaríamos nesse caso, em vez de uma nova instância WinJS.Promise.

O outro lado disso tudo é que embora uma chamada para o método cancelar da promessa coloque-a no estado de erro, como interrompemos a operação assíncrona que está em andamento? Na implementação de calculateIntegerSum anterior, ele continuará chamando setImmediate até que a operação seja concluída, independentemente do estado da promessa criada. Na verdade, se a operação chamar o distribuidor completo depois que a promessa tiver sido cancelada, ela ignorará essa conclusão.

O necessário, então, é uma maneira de a promessa dizer para a operação que não precisa mais continuar seu trabalho. Por isso, a construção WinJS.Promise precisa de um segundo argumento de função que será chamado se a promessa for cancelada. Nesse exemplo, uma chamada para essa função precisaria evitar a próxima chamada para setImmediate, interrompendo a computação. Veja como isso ocorre, juntamente com a manipulação de erro adequada:

function calculateIntegerSum(max, step) {
    //Return a promise in the error state for bad arguments
    if (max < 1 || step < 1) {
        var err = new WinJS.ErrorFromName("calculateIntegerSum", "max and step must be 1 or greater");
        return WinJS.Promise.wrapError(err);
    }

    var _cancel = false;

    //The WinJS.Promise constructor's argument is an initializer function that receives 
    //dispatchers for completed, error, and progress cases.
    return new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
        var sum = 0;

        function iterate(args) {
            for (var i = args.start; i < args.end; i++) {
                sum += i;
            };

            //If for some reason there was an error, create the error with WinJS.ErrorFromName
            //and pass to errorDispatch
            if (false /* replace with any necessary error check -- we don’t have any here */) {
                errorDispatch(new WinJS.ErrorFromName("calculateIntegerSum (scenario 7)", "error occurred"));
            }

            if (i >= max) {
                //Complete--dispatch results to completed handlers
                completeDispatch(sum); 
            } else {
                //Dispatch intermediate results to progress handlers
                progressDispatch(sum);

                //Interrupt the operation if canceled
                if (!_cancel) {
                    setImmediate(iterate, { start: args.end, end: Math.min(args.end + step, max) });
                }
            }
        }
            
        setImmediate(iterate, { start: 0, end: Math.min(step, max) });
    },
    //Cancellation function for the WinJS.Promise constructor
    function () {
        _cancel = true;
    });
}

De forma geral, a criação de instâncias de WinJS.Promise tem muitas utilidades. Por exemplo, se você tiver uma biblioteca que interaja com um serviço da Web por meio de outro método assíncrono, você pode englobar essas operações dentro de promessas. Você também pode usar uma nova promessa para combinar várias operações assíncronas (ou outras promessas!) de fontes diferentes em uma única promessa onde você queira controlar todos os relacionamentos envolvidos. Dentro do código de um inicializador de WinJS.Promise, você pode ter seus próprios manipuladores para outras operações assíncronas e suas promessas. Você pode usá-los para encapsular mecanismos de nova tentativa automáticos para tempos de espera e rede e afins, depender de uma interface de atualizador de progresso genérico ou adicionar registros ou análises dos bastidores. De todas essas formas, o resto do código nunca precisa saber os detalhes e pode lidar apenas com promessas do lado do cliente.

Parecido com isso, é relativamente direto encapsular um trabalho do JavaScript em uma promessa de forma que ela tenha a aparência e se comporte como outras operações assíncronas no WinRT. Os trabalhos, como você deve saber, fornecem seus resultados por meio de uma chamada de postMessage que cria um evento message no objeto de trabalho do aplicativo. Portanto, o código a seguir vincula esse evento a uma promessa que será cumprida com os resultados fornecidos nessa mensagem:

// This is the function variable we're wiring up.
var workerCompleteDispatch = null;

var promiseJS = new WinJS.Promise(function (completeDispatch, errorDispatch, progressDispatch) {
    workerCompleteDispatch = completeDispatch;
});

// Worker is created here and stored in the 'worker' variable

// Listen for worker events
worker.onmessage = function (e) {
    if (workerCompleteDispatch != null) {
        workerCompleteDispatch(e.data.results); /* event args depends on the worker */
    }
}

promiseJS.done(function (result) {
    // Output for JS worker
});

Para expandir esse código para lidar com erros do trabalho, você precisaria salvar o distribuidor do erro em outra variável, fazer com que o manipulador de eventos da mensagem busque por informações do erro em seus argumentos de evento e chamar o distribuidor de erros em vez do distribuidor completo, como seria apropriado.

Combinação de promessas paralelas

Como as promessas normalmente são usadas para englobar operações assíncronas, é totalmente possível ter várias operações ocorrendo em paralelo. Nesses casos, talvez você queira saber quando um grupo ou uma promessa é cumprida ou quando todas as promessas no grupo são cumpridas. As funções estáticas WinJS.Promise.any e WinJS.Promise.join fornecem isso.

Ambas as funções aceitam uma variedade de valores ou um objeto com propriedades de valores. Esses valores podem ser promessas, e todos os valores que não são de promessas são englobados com WinJS.Promise.as, de forma que toda a matriz ou objeto é composto de promessas.

Veja as características de any:

• any cria uma única promessa que é cumprida quando uma das outras é cumprida ou quando ocorrem falhas com um erro (um OU lógico). Em essência, o any anexa manipuladores completos a todas essas promessas, e assim que um manipulador completo é chamado, ele chama todos os manipuladores completos que a própria promessa de any recebeu.
• Depois que a promessa de any tiver sido cumprida (ou seja, depois que a primeira promessa na lista tiver sido cumprida), as outras operações na lista continuarão sendo executadas, chamando quaisquer manipuladores completos, de erros ou progresso atribuídos a essas promessas individualmente.
• Se você cancelar a promessa de any, todas as promessas na lista serão canceladas.

Já no caso de join:

• join cria uma única promessa que é cumprida quando todas as outras são cumpridas ou quando ocorrem falhas com um erro (um E lógico). Em essência, join anexa manipuladores completos e de erros a todas essas promessas e aguarda até que eles sejam chamados antes de chamar todos os manipuladores completos que ele mesmo recebe.
• A promessa de join também relata progressos para todos os manipuladores de progresso fornecidos. O resultado intermediário nesse caso é uma gama de resultados dessas promessas individuais que já foram cumpridas até o momento.
• Se você cancelar a promessa de join, todas as outras promessas ainda pendentes serão canceladas.

Além de any e join, existem dois outros métodos estáticos do WinJS.Promise a serem considerados que podem ser úteis:

• is determina se um valor arbitrário é uma promessa, retornando um booliano. Ele basicamente garante que seja um objeto com uma função chamada de “then”; não faz testes para “done”.
• theneach aplica manipuladores completos, de erros e progresso a um grupo de promessas (usando then), retornando os resultados como outro grupo de valores dentro de uma promessa. Todos os manipuladores podem ser nulos.

Promessas paralelas com resultados sequenciais

Com WinJS.Promise.join e WinJS.Promise.any, temos a capacidade de trabalhar com promessas paralelas, isto é, com operações assíncronas paralelas. A promessa retornada por join, novamente, são cumpridas quando todas as promessas em uma matriz são cumpridas. No entanto, essas promessas provavelmente serão concluídas de forma aleatória. E se você tiver um conjunto de operações que possam ser executadas dessa maneira, mas quer processar seus resultados de forma bem definida, isto é, a ordem em que suas promessas são exibidas em uma matriz?

Para fazer isso, você precisa combinar todas as promessas subsequentes ao join de todas as anteriores, e a parte do código com que iniciamos esta postagem faz exatamente isso. Veja o código novamente, mas reescrito para explicitar as promessas. (Suponha que a lista seja uma matriz de valores de algum tipo usada como argumentos para uma chamada assíncrona de produção de promessas hipotética doOperationAsync):

list.reduce(function callback (prev, item, i) {
    var opPromise = doOperationAsync(item);
    var join = WinJS.Promise.join({ prev: prev, result: opPromise});

    return join.then(function completed (v) {
        console.log(i + ", item: " + item+ ", " + v.result);
    });
})

Para compreender este código, primeiro precisamos entender como o método reduce da matriz funciona. Para cada item na matriz, reduce chama o argumento da função, chamado aqui de callback, que recebe quatro argumentos (e apenas três deles são usados no código):

• prev O valor retornado da chamada previous para callback (este é nulo para o primeiro item).
• item O valor atual da matriz.
• i O índice de itens na lista.
• source A matriz original.

Para o primeiro item da lista, obteremos uma promessa que chamarei de opPromise₁. Como o anterior ainda está nulo, combinaremos [WinJS.Promise.as(null), opPromise₁]. Mas observe que não retornaremos join. Em vez disso, anexaremos um manipulador completo (que chamei de completo) à este join e ele retornará a promessa de seu then.

Lembre-se de que a promessa retornada de then será cumprida quando o manipulador completo retornar. Isso significa que estamos retornando de callback uma promessa que não será concluída até que o manipulador completo do primeiro item tenha processado os resultados de opPromise₁. E se você observar o resultado de uma combinação, ele terá sido cumprido com um objeto que contém os resultados de promessas da lista original. Isso significa que o valor de cumprimento v conterá uma propriedade prev e uma propriedade result, em que a última é o resultado de opPromise₁.

Com o próximo item na lista, callback recebe um prev que contém uma promessa do join.then anterior. Depois disso, criaremos uma combinação de opPromise₁.then com opPromise₂. Como resultado, essa combinação não será concluída até que as duas opPromise₂ tenham sido cumpridas e o manipulador completo de opPromise₁ tenha sido retornado. Pronto! O manipulador completo₂ que anexaremos agora a esta combinação não será chamado até que completed₁ tenha sido retornado.

As mesmas dependências continuam sendo criadas para cada item na lista, a promessa de join.then para o item n não será cumprida até que o completed_n seja retornado. Isso garante que os manipuladores completos sejam chamados na mesma sequência que a lista.

Resumo

Nesta postagem vimos que as promessas são apenas uma construção de código ou convenção de chamadas de função, embora muito eficiente, para representar um relacionamento específico entre uma origem, que tem os valores a serem fornecidos em um momento posterior arbitrário e um consumidor que precisa saber quando esses valores estarão disponíveis. Como tal, as promessas trabalham muito bem para representar resultados de operações assíncronas e são usadas extensivamente em aplicativos da Windows Store escritos em JavaScript. A especificações de promessas também permite que operações assíncronas sejam encadeadas juntas, com cada resultado intermediário fluindo de um link para o próximo.

A Biblioteca do Windows para JavaScript, WinJS, fornece uma implementação eficiente de promessas que você pode usar para englobar qualquer tipo de operação. Ela também fornece ajuda para cenários comuns, como a combinação de promessas para operações paralelas. Com elas, o WinJS possibilita o trabalho com operações assíncronas de forma eficiente e eficaz.

Kraig Brockschmidt
Gerente de programas, equipe de ecossistema do Windows
Autor, Programming Windows 8 Apps in HTML, CSS, and JavaScript (Programando aplicativos do Windows 8 em HTML, CSS e JavaScript)

Para muitos aplicativos da Windows Store escritos em JavaScript , que trabalham com coleções, colaborar bem com o controle WinJS ListView é essencial para o bom desempenho do aplicativo. Isto não é nenhuma surpresa: quando se está lidando com o gerenciamento e a exibição de, possivelmente, milhares de itens, qualquer otimização que você fizer com esses itens conta. Ainda mais importante é como cada um desses itens é renderizado, o que significa, como — e quando — cada item no controle ListView é construído no DOM e se torna uma parte visível do aplicativo. Na verdade, a parte quando dessa equação se torna um fator crucial quando um usuário realiza uma panorâmica com rapidez em uma lista e espera que aquela lista mantenha o ritmo.

A renderização de itens em um ListView acontece por meio de um modelo declarativo, definido em HTML ou por meio de uma função de renderização personalizada do JavaScript que é exigida para cada item na lista. Embora o modelo declarativo seja o método mais simples, ele não oferece muita margem para o controle específico sobre o processo. Por outro lado, uma função de renderização o permite personalizar a renderização por cada item e possibilita diversas otimizações demonstradas na amostra de desempenho de otimização do ListView em HTML. Essas otimizações são:

• A possibilidade de entregas assíncronas de dados dos itens e um elemento renderizado, com o suporte das funções básicas de renderização.
• Separação da criação do formato de um item dos seus elementos internos, o que é necessário para o layout geral de um ListView. Este processo é possível por meio de um renderizador de espaço reservado.
• Reutilização de um elemento de item previamente criado (e dos seus filhos) substituindo os seus dados, evitando a maioria das etapas de criação de elemento, possibilitado por meio de um renderizador de reciclagem de espaço reservado.
• Adiar operações visuais caras, como carregamento e animação de imagens, até que um item se torne visível e um ListView não esteja sendo pesquisado panoramicamente, o que é realizado por meio de um renderizador de várias etapas.
• Agrupar essas mesmas operações visuais para minimizar a novas renderizações do DOM, por meio de um renderizador de agrupamento de várias etapas.

Nesta postagem analisaremos todas essas etapas e aprenderemos como elas cooperam com o processo de renderização de item do ListView. Como você pode imaginar, otimizações relacionadas a quando renderizar um item envolvem muitas operações assíncronas e, portanto, muitas promessas. Portanto, durante o processo, também aprenderemos muito sobre as próprias promessas, adicionando ao artigo anterior All about promises (Tudo sobre promessas) neste blog.

Uma observação geral, que se aplica a todos os renderizadores: é sempre importante manter o tempo de renderização do seu item principal (sem contar as operações adiadas) ao mínimo. Como o desempenho final do ListView depende muito de como as suas atualizações estão alinhadas com os intervalos de atualização da tela, uns poucos milissegundos gastos em um renderizador de item pode aumentar o tempo geral de renderização do ListView no curso do intervalo de atualização seguinte, resultando em quadros eliminados e falhas na imagem. Em outras palavras, os renderizadores de item são um lugar onde otimizar o seu código JavaScript realmente conta.

Renderizadores básicos

Vamos começar com rápida análise do que é uma função de renderização de item — que chamarei simplesmente de renderizador. Um renderizador é uma função designada por você à propriedade itemTemplate do ListView, em vez de um nome do modelo, e essa função será utilizada, conforme necessário, para itens que o ListView quer incluir no DOM. (Observe que as informações básicas para renderizadores podem ser encontradas na página itemTemplate, mas é a amostra que realmente apresenta as otimizações.)

Você pode esperar que uma função de renderização de item seria simplesmente designada a um item a partir da fonte de dados do ListView. Ela, então, criaria os elementos HTML necessários para aquele item específico e retornaria o elemento raiz que o ListView pode adicionar ao DOM. Basicamente, é isto que acontece, mas existem duas considerações adicionais. Primeiro, os próprios dados do item podem ser carregados de forma assíncrona, portanto, faz sentido associar a criação do elemento à disponibilidade daqueles dados. Além disso, o próprio processo de renderização do item pode envolver trabalhos assíncronos, como carregar imagens de URIs remotos ou a leitura de dados em outros arquivos identificados nos dados do item. Os diferentes níveis de otimização que analisaremos, na verdade, permitem um volume arbitrário de trabalho assíncrono entre a solicitação dos elementos do item e a entrega, de fato, desses elementos.

Portanto, repito, você pode confiar que promessas estarão envolvidas! Primeiro porque o ListView não fornece ao renderizador apenas os dados do item diretamente, ele fornece uma promessa para esses dados. Em vez da função retornar diretamente ao elemento raiz do item, ela retorna uma promessa para aquele elemento. Isto permite que o ListView agrupe diversas promessas de renderização de item e aguarde (de forma assíncrona) até que a página inteira de itens tenha sido renderizada. Na verdade, ele faz isso para gerenciar, de maneira inteligente, como ele constrói as diferentes páginas. Primeiro, construindo a página de itens visíveis. Depois, construindo duas páginas não exibidas na tela, para frente e para trás, onde é mais provável que os usuários façam uma panorâmica para avançar. Além disso, ter todas estas promessas nos devidos lugares significa que o ListView pode cancelar facilmente a renderização de itens inacabados, caso o usuário deixe de fazer a panorâmica, evitando assim, a criação desnecessária de elementos.

Podemos ver como essas promessas são usadas na função simpleRenderer da amostra:

function simpleRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        var element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img src='" + item.data.thumbnail +
            "' alt='Databound image' /><div class='content'>" + item.data.title + "</div>";
        return element;
    });
}

Este código primeiro anexa um manipulador concluído ao itemPromise. O manipulador é chamado quando os dados do item estão disponíveis e efetivamente cria os elementos em resposta. Observe, novamente, que não estamos retornando o elemento diretamente. Estamos retornando uma promessa que é cumprida com esse elemento. Ou seja, o valor de retorno do itemPromise.then() é uma promessa que é cumprida com o element se e quando o ListView precisar dele.

Retornar uma promessa nos permite realizar outras tarefas assíncronas, se necessário. Neste caso, o renderizador pode simplesmente encadear estas promessas intermediárias, retornando a promessa da última then na cadeia. Por exemplo:

function someRenderer(itemPromise) {
    return itemPromise.then(function (item) {
        return doSomeWorkAsync(item.data);
    }).then(function (results) {
        return doMoreWorkAsync(results1);
    }).then(function (results2) {
        var element = document.createElement("div");
        // use results2 to configure the element
        return element;
    });
}

Observe que, o dele é um caso onde não usamos done no final da cadeia, porque estamos retornando uma promessa da última chamada then. O ListView se responsabiliza por lidar com qualquer erro que possa surgir.

Renderizadores de espaço reservado

A próxima etapa da otimização do ListView utiliza um renderizador de espaço reservado que divide a construção do elemento em duas etapas. Isto permite que o ListView solicite apenas as partes de um elemento que são necessárias para definir o layout geral da lista, sem ter que construir todos os elementos dentro de cada item. Consequentemente, o ListView pode completar o seu cálculo de layout rapidamente e continuar a responder eficazmente a mais entradas. Ele pode, então, solicitar o restante do elemento mais tarde.

Um renderizador de espaço reservado retorna um objeto com duas propriedades, em vez de apenas uma promessa:

• element O elemento de nível superior na estrutura do item, que basta para definir o seu tamanho e forma, e que não depende dos dados do item.
• renderComplete Uma promessa que é cumprida quando o restante dos conteúdos do elemento são construídos, ou seja, retorna a promessa de qualquer cadeia que você tenha iniciado com o itemPromise.then, como anteriormente.

O ListView é inteligente o bastante para verificar se o seu renderizador retornou uma promessa (o caso básico anterior) ou um objeto com propriedades element e renderComplete (casos mais avançados). Portanto, o renderizador de espaço reservado equivalente (na amostra) para o simpleRenderer anterior é o seguinte:

function placeholderRenderer(itemPromise) {
    // create a basic template for the item that doesn't depend on the data
    var element = document.createElement("div");
    element.className = "itemTempl";
    element.innerHTML = "<div class='content'>...</div>";

    // return the element as the placeholder, and a callback to update it when data is available
    return {
        element: element,

        // specifies a promise that will be completed when rendering is complete
        // itemPromise will complete when the data is available
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            element.querySelector(".content").innerText = item.data.title;
            element.insertAdjacentHTML("afterBegin", "<img src='" +
                item.data.thumbnail + "' alt='Databound image' />");
        })
    };
}

Observe que a atribuição element.innerHTML pode ser movida dentro do renderComplete porque a classe itemTempl no arquivo de amostra css/scenario1.css especificou diretamente a largura e a altura do item. A razão para ela estar incluída na propriedade element é porque ela fornece o padrão de texto “…” no espaço reservado. Você também poderia facilmente utilizar um elemento img que se refira a um pequeno recurso no pacote que é compartilhado por todos os itens e, portanto, seja renderizado rapidamente.

Reciclar renderizadores de espaço reservado

A próxima otimização, reciclar renderizadores de espaço reservado não adiciona nada de novo no que se refere às promessas. Ela adiciona o reconhecimento de um segundo parâmetro para o renderizador chamado recycled, que é o elemento raiz de um item que foi anteriormente renderizado, mas não está mais visível. Ou seja, o elemento reciclado já possui os seus elementos filho nos devidos lugares, para que você possa substituir os dados ou talvez alterar alguns desses elementos. Isto evita a maioria das solicitações caras de criação de elementos, necessárias para um item totalmente novo, economizando um tempo significativo no processo de renderização.

O ListView pode fornecer um elemento reciclado quando o seu loadingBehavior estiver configurado para "randomaccess". Se recycled for fornecido, você pode simplesmente limpar dados do elemento (e dos seus filhos), retorná-lo ao seu espaço reservado e, então, preencher os dados e criar filhos adicionais (se necessário) dentro do renderComplete. Se um elemento reciclado não for fornecido (como acontece quando o ListView é criado pela primeira vez ou quando o loadingBehavior for "incremental"), você criará o elemento novamente. Aqui está o código da amostra para esta variação:

function recyclingPlaceholderRenderer(itemPromise, recycled) {
    var element, img, label;
    if (!recycled) {
        // create a basic template for the item that doesn't depend on the data
        element = document.createElement("div");
        element.className = "itemTempl";
        element.innerHTML = "<img alt='Databound image' style='visibility:hidden;'/>" +
            "<div class='content'>...</div>";
    }
    else {
        // clean up the recycled element so that we can reuse it 
        element = recycled;
        label = element.querySelector(".content");
        label.innerHTML = "...";
        img = element.querySelector("img");
        img.style.visibility = "hidden";
    }
    return {
        element: element,
        renderComplete: itemPromise.then(function (item) {
            // mutate the element to include the data
            if (!label) {
                label = element.querySelector(".content");
                img = element.querySelector("img");
            }
            label.innerText = item.data.title;
            img.src = item.data.thumbnail;
            img.style.visibility = "visible";
        })
    };
}

Na opção renderComplete, certifique-se de verificar a existência de elementos não criados para um novo espaço reservado, como por exemplo label, e crie-os aqui, se necessário.

Se você deseja livrar-se de itens reciclados de forma mais generalizada, é possível fornecer uma função à propriedade resetItem do ListView. Esta função pode conter código similar ao mostrado acima. O mesmo vale para a propriedade resetGroupHeader , já que você pode usar funções modelo para cabeçalhos de grupo e também para itens. Não nos referimos muito a isto porque os cabeçalhos de grupos são em número muito menor e, normalmente, não têm as mesmas implicações no desempenho. Não obstante, a funcionalidade existe.

Renderizadores de várias etapas

Isto nos trás à penúltima otimização, o renderizador de várias etapas. Ele estende o renderizador de reciclagem de espaço reservado para atrasar o carregamento de imagens e outras mídias, até que o resto do item esteja completamente presente no DOM. Ele também atrasa efeitos, como animações, até que o item esteja realmente na tela. Isto reconhece que os usuários frequentemente fazem panorâmica bem rápidas no ListView. Portanto, faz sentido adiar as operações mais caras até o ListView ter chegado a uma posição estável.

O ListView fornece os ganchos necessários conforme os membros no item resultem do itemPromise: uma propriedade chamada ready (uma promessa) e dois métodos, o loadImage e o isOnScreen, retornam (ainda mais!) promessas. Ou seja:

renderComplete: itemPromise.then(function (item) {
    // item.ready, item.loadImage, and item.isOnScreen available
})

Aqui está como usá-los:

• ready Retorna esta promessa a partir do primeiro manipulador concluído na sua cadeia. Essa promessa é cumprida quando a estrutura completa do elemento foi renderizada e está visível. Isto significa que você pode encadear um outro then com um manipulador concluído no qual você executa tarefas após a visibilidade, como, por exemplo carregar imagens.
• loadImage Baixa uma imagem de um URI e a exibe no elemento img designado, retornando uma promessa que é cumprida com esse mesmo elemento. Você anexa um manipulador concluído à esta promessa e ele mesmo retorna a promessa da isOnScreen. Observe que o loadImage criará um elemento img caso ele não seja fornecido e entregue a seu manipulador concluído.
• isOnScreen Retorna uma promessa cujo valor de cumprimento é uma parâmetro booliano indicando se o item está visível ou não. Nas implementações correntes, este é um valor conhecido, portanto, a promessa é cumprida de forma síncrona. Entretanto, encapsulando-o em uma promessa, ele pode ser usado em uma cadeia mais longa.

Pode-se observar tudo isto na função multistageRenderer da amostra, onde a conclusão do carregamento da imagem é usada para dar início a uma animação de fade-in. Aqui estou apenas mostrando o que foi retornado da promessa renderComplete:

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Embora haja muita coisa acontecendo, ainda temos apenas uma cadeia de promessas básica. A primeira operação assíncrona no renderizador atualiza partes simples da estrutura do elemento do item, tais como texto. Ela, então, retorna a promessa em item.ready. Quando a promessa é cumprida — ou, mais precisamente, se a promessa é cumprida — utilizamos o método assíncrono loadImage do item para dar início ao download de uma imagem, retornando a promessa item.isOnScreen daquele manipulador concluído. Isto significa que o sinalizador de visibilidade onscreen é passado para o manipulador concluído final na cadeia. Quando e se aquela promessa isOnScreen é cumprida — o que significa que o item está realmente visível — podemos executar operações relevantes como, por exemplo, animações.

Enfatizo a parte "se", porque pode ser que, novamente, aquele usuário esteja fazendo uma panorâmica dentro do ListView enquanto isto está acontecendo. Ter todas estas promessas encadeadas torna possível para o ListView cancelar operações assíncronas, sempre que estes itens não estejam visíveis e/ou desativados de uma página com buffer. Basta dizer que, o controle do ListView passou por muitos testes de desempenho!

Também é importante lembrar, novamente, que estamos usando o then em todas estas cadeias, porque ainda estamos retornando uma promessa da função de renderização dentro da propriedade renderComplete. Nunca somos o final da cadeia destes renderizadores, portanto, nunca usaremos o done no final.

Agrupamento de miniaturas

A última otimização é, verdadeiramente, o coup de grace para o controle do ListView. Na função chamada batchRenderer, encontramos esta estrutura para o renderComplete (com a maior parte do código omitido):

renderComplete: itemPromise.then(function (item) {
    // mutate the element to update only the title
    if (!label) { label = element.querySelector(".content"); }
    label.innerText = item.data.title;

    // use the item.ready promise to delay the more expensive work
    return item.ready;
    // use the ability to chain promises, to enable work to be cancelled
}).then(function (item) {
    // use the image loader to queue the loading of the image
    if (!img) { img = element.querySelector("img"); }
    return item.loadImage(item.data.thumbnail, img).then(function () {
        // once loaded check if the item is visible
        return item.isOnScreen();
    });
}).then(function (onscreen) {
    if (!onscreen) {
        // if the item is not visible, don't animate its opacity
        img.style.opacity = 1;
    } else {
        // if the item is visible, animate the opacity of the image
        WinJS.UI.Animation.fadeIn(img);
    }
})

Isto é quase o mesmo que o multistageRenderer com exceção da misteriosa solicitação para a inserção de uma função chamada thumbnailBatch entre a solicitação item.loadImage e a verificação do item.isOnScreen. O posicionamento do thumbnailBatch na cadeia indica que o seu valor de retorno deve ser um manipulador concluído, que retorna uma outra promessa.

Confuso? Não se preocupe, chegaremos ao fundo disto! Mas antes precisamos de um pouco mais de informações sobre o que estamos tentando fazer.

Se tivéssemos apenas um ListView, com um único item, várias otimizações de carregamento não seriam percebidas. Mas os ListViews normalmente têm vários itens e a função de renderização é necessária para cada um deles. Na opção multistageRenderer da seção anterior, e renderização de cada item dá início a uma operação assíncrona item.loadImage para baixar a sua miniatura de um URI arbitrário, e cada operação pode levar um período de tempo arbitrário. Portanto, para a lista completa, poderemos ter uma série de solicitações simultâneas de loadImage ocorrendo, com a renderização de cada item aguardando a conclusão da sua miniatura específica. Até aqui, tudo bem.

Entretanto, uma característica importante que não está visível no multistageRenderer é que o elemento img para a miniatura já está no DOM, e a função loadImage configura o atributo src daquela imagem assim que o download tiver concluído. Por sua vez, isto aciona uma atualização no mecanismo de renderização assim que retornarmos do restante da cadeia de promessas que, depois disso, é essencialmente síncrona.

É possível, então, que uma série de miniaturas possam voltar ao thread da interface do usuário dentro um curto período de tempo. Isso causará excesso de rotatividade no mecanismo de renderização e um fraco desempenho visual. Para evitar essa rotatividade o que queremos é criar por completo estes elements img antes deles estarem no DOM, e depois adicioná-los em lotes, de tal maneira que sejam todos manipulados em uma única passagem de renderização.

A amostra realiza isto por meio de um código de promessa mágico, uma função chamada createBatch. createBatch é solicitado apenas uma vez para todo o aplicativo e o seu resultado — uma outra função — é armazenado na variável chamada thumbnailBatch:

var thumbnailBatch;
thumbnailBatch = createBatch();

Uma solicitação à esta função thumbnailBatch , como a chamarei daqui para frente, é novamente inserida na cadeia de promessa de renderizador. O propósito dessa inserção, dada a natureza do código de loteamento, como logo veremos, é agrupar um conjunto de elementos img carregados, liberando-os para mais processamento em intervalos adequados. Repetindo, apenas ao olhar para a cadeia de promessa no renderizador, uma solicitação ao thumbnailBatch() deve retornar uma função concluída de manipulador que retorna uma promessa, e o valor de cumprimento dessa promessa (analisando a próxima etapa na cadeia) deve ser um elemento img que pode ser adicionado ao DOM. Ao adicionar estas imagens ao DOM, após o loteamento ter sido concluído, combinamos todo este grupo para a mesma passagem de renderização.

Esta é uma importante diferença entre o batchRenderer e o multistageRenderer da seção anterior: no último o elemento da miniatura img já existe no DOM e é passado ao loadImage como um segundo parâmetro. Portanto, quando loadImage configura o atributo src da imagem, uma atualização de renderização é acionada. Entretanto, dentro do batchRenderer, este elemento img é criado separadamente dentro do loadImage (onde o src também é configurado), mas o img ainda não está no DOM. Ele só é adicionado ao DOM após a conclusão da etapa do thumbnailBatch , tornando-o parte de um grupo dentro daquele cálculo de layout único.

Agora, vamos ver como funciona este loteamento. Aqui está a função createBatch completa:

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

Novamente, o createBatch é solicitado apenas uma vez e o resultado do seu thumbnailBatch é solicitado para cada item renderizado na lista. O manipulador concluído que o thumbnailBatch cria é, então, solicitado sempre que uma operação loadImage é concluída.

Este manipulador concluído poderia também ter sido diretamente inserido na função de renderização, mas o que estamos tentando fazer aqui é coordenar atividades em vários itens em vez de um item de cada vez. Esta coordenação é obtida por meio de duas variáveis criadas e inicializadas no início do createBatch: batchedTimeout, inicializado como uma promessa vazia e batchedItems, inicializado como uma matriz de funções que, inicialmente, está vazia. createBatch também declara uma função completeBatch, que simplesmente descarta os batchedItems, solicitando cada função na matriz:

function createBatch(waitPeriod) {
    var batchTimeout = WinJS.Promise.as();
    var batchedItems = [];

    function completeBatch() {
        var callbacks = batchedItems;
        batchedItems = [];
        for (var i = 0; i < callbacks.length; i++) {
            callbacks[i]();
        }
    }

    return function () {
        batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

        var delayedPromise = new WinJS.Promise(function (c) {
            batchedItems.push(c);
        });

        return function (v) {
            return delayedPromise.then(function () {
                return v;
            });
        };
    };
}

Agora, vejamos o que acontece dentro do thumbnailBatch (a função retornada do createBatch), que é novamente solicitada para cada item sendo renderizado. Primeiro, cancelamos qualquer batchedTimeout existente e imediatamente o recriamos:

batchTimeout.cancel();
        batchTimeout = WinJS.Promise.timeout(waitPeriod || 64).then(completeBatch);

A segunda linha mostra o padrão futuro de entrega/cumprimento que discutimos na postagem All About Promises <TODO: link>: ele diz para solicitar o completeBatch após um atraso de waitPeriod milissegundos (com um padrão de 64ms). Isto significa que enquanto o thumbnailBatch estiver sendo solicitado novamente dentro do waitPeriod de uma solicitação anterior, o batchTimeout será redefinido para um outro waitPeriod. E, como o thumbnailBatch só é solicitado após que uma solicitação item.loadImage seja concluída, estamos, na verdade dizendo que quaisquer operações loadImage que forem concluídas dentro do waitPeriod da anterior, será incluída no mesmo lote. Quando existe uma lacuna maior do que o waitPeriod, o lote é processado — imagens são adicionadas ao DOM — e o próximo lote começa.

Após manipular este tempo de espera, o thumbnailBatch cria uma nova promessa que simplesmente envia a função despachante concluída para dentro da matriz batchedItems:

var delayedPromise = new WinJS.Promise(function (c) {
         batchedItems.push(c);
     });

Lembre-se do All About Promises <TODO: link> que uma promessa é apenas uma construção de código e isso é tudo o que temos aqui. A nova promessa criada não possui um comportamento assíncrono por si própria: estamos apenas adicionando a função despachante concluída c, para o batchedItems. Obviamente, não fazemos nada com o despachante até que o batchedTimeout seja concluído de forma assíncrona, portanto, existe de fato, um relacionamento assíncrono aqui. Quando acontece o tempo de espera e limpamos o lote (dentro do completeBatch), invocaremos quaisquer manipuladores concluídos que tenham sido dados ao delayedPromise.then.

Isto nos traz às últimas linhas de código no createBatch, que é a função retornada pelo thumbnailBatch. Essa função é exatamente o manipulador concluído que é inserido dentro de toda a cadeia de promessa do renderizador:

return function (v) {
           return delayedPromise.then(function () {
               return v;
           });
       };

Na verdade, vamos inserir este código diretamente na cadeia de promessa para vermos os relacionamentos resultantes:

return item.loadImage(item.data.thumbnail);
          }).then(function (v) {
              return delayedPromise.then(function () {
                  return v;
              });
          ).then(function (newimg) {

Agora, podemos ver que o argumento v é o resultado do item.loadImage, que é o elemento img criado para nós. Se não quiséssemos fazer o loteamento, bastaria dizer return WinJS.Promise.as(v) e a cadeia inteira ainda funcionaria: v seria, então, passado de forma assíncrona e seria exibido como newimg na etapa seguinte.

Entretanto, em vez disso, estamos retornando a promessa do delayedPromise.then que não será cumprida — com v — até que a atual batchedTimeout seja cumprida. Neste momento — quando houver novamente uma lacuna de waitPeriod entre as conclusões do loadImage —, estes elementos img serão entregues à etapa seguinte na cadeia, onde serão adicionados ao DOM.

E é isso!

Conclusão

As cinco diferentes funções de renderização demonstradas na amostra de desempenho de otimização do ListView em HTML têm uma coisa em comum: elas mostram como o relacionamento assíncrono entre o ListView e o renderizador — expressado por meio de promessas — possibilita uma enorme flexibilidade ao renderizador sobre como e quando ele produz elementos para os itens na lista. Ao escrever os seus próprios aplicativos, a estratégia a ser usada para a otimização do ListView depende muito do tamanho da sua fonte de dados, da complexidade dos próprios itens e do volume de dados que você está obtendo de forma assíncrona para esses itens (como baixar imagens remotas). Com certeza, você desejará manter os renderizadores de itens o mais simples que puder, para ainda atender os seus objetivos de desempenho. Em todo caso, você agora tem todas as ferramentas de que precisa para ajudar o ListView e o seu aplicativo a alcançarem o melhor desempenho.

Kraig Brockschmidt
Gerente de programas, equipe de ecossistema do Windows
Autor, Programming Windows 8 Apps in HTML, CSS, and JavaScript (Programando aplicativos do Windows 8 em HTML, CSS e JavaScript)

Os jogos são uma classe de aplicativos fundamental na Windows Store. Se você deseja criar um jogo para a Windows Store, gostaríamos de ajudá-lo com evento virtual sobre criação de jogos. O evento é gratuito e estará aberto para os novos desenvolvedores de jogos e também para os profissionais.

Usaremos o GameMaker: Studio da YoYo Games, para mostrar a você como criar e publicar jogos de alta qualidade em menos tempo. O GameMaker: Studio possui muitas opções internas de criação e ferramentas de arrastar e soltar que ajudam você a começar, mesmo que não tenha uma ideia para um jogo ou experiência em criação. No entanto, se você for um desenvolvedor mais experiente, as ferramentas avançadas o ajudarão a criar uma experiência de jogo única.

Os eventos online começarão no sábado, 15 de junho, às 10 da manhã (Horário de Verão do Pacífico), com uma sessão de lançamento e um chat ao vivo. Você aprenderá sobre tipos diferentes de jogos e como adicionar elementos gráficos, fases e sons durante a criação de um jogo, além de explorar maneiras de deixar o jogo do seu jeito. O suporte continuará durante a semana com assistência individual por meio dos fóruns do GameMaker.

Para você que é um estudante, um desenvolvedor de primeira viagem ou um profissional experiente, este evento será o seu ponto de partida para criar, carregar e publicar jogos na Windows Store. Descubra mais, inscreva-se e confira as ferramentas e os recursos gratuitos em http://msdnevents.com/gameon/.

--Robert Rodriguez-Lawson, gerente de publicação de conteúdo sênior, conteúdo para desenvolvedores do Windows

Você ainda não ouviu falar sobre o Cofre de Credenciais que está disponível para os aplicativos da Windows Store? Então, está mais do que na hora. Por quê? Porque ele não apenas simplifica a tarefa de armazenar e recuperar as credenciais do usuário, ele as armazena de forma segura, e as credenciais acompanham os usuários "gratuitamente" com a conta da Microsoft.

Vamos supor que você tenha um aplicativo que se conecte a um serviço para acessar recursos protegidos, como arquivos de mídia, rede social etc. O seu serviço exige informações de logon para cada usuário. Portanto, você incorporou a interface do usuário no seu aplicativo, que obtém o nome de usuário e a senha para o usuário, que são usados para fazer o logon do usuário no serviço. Tudo funciona perfeitamente.

Agora você deseja facilitar mais as coisas para os usuários e armazenar suas informações de logon de forma segura para que não precisem fazer logon toda vez que usarem o seu aplicativo. Insira o Cofre de Credenciais. Com apenas algumas chamadas simples para a API do Cofre de Credenciais, você pode armazenar o nome de usuário e a senha para o usuário e recuperá-los facilmente para fazer o logon do usuário na próxima vez que ele abrir o seu aplicativo.

Armazenamento seguro

A excelente vantagem que o Cofre de Credenciais oferece ao seu aplicativo é armazenar as credenciais do usuário em um local seguro, e essas informações são criptografadas quando armazenadas em disco. Você com certeza poderia armazenar as credenciais dos seus usuários em um arquivo no armazenamento local do seu aplicativo, mas armazená-las em texto sem formatação apresenta uma falha de segurança considerável. Se o sistema de um usuário for comprometido de alguma forma, o nome de usuário e senha dele poderão ser facilmente acessados e manipulados. Armazenando o nome de usuário e a senha com o Cofre de Credenciais, o máximo que uma fonte mal-intencionada poderia conseguir capturar seria um arquivo criptografado.

O Cofre de Credenciais é exclusivo para cada usuário do PC do Windows, e o acesso a uma credencial é limitado ao aplicativo armazenado nela. Isto é, você somente pode recuperar uma credencial que tiver armazenado para o seu aplicativo. Da mesma forma, nenhum outro aplicativo poderá obter as credenciais que o seu aplicativo tiver armazenado no cofre.

Credenciais móveis

Um benefício adicional para os seus usuários é que, quando você armazena o nome de usuário e a senha dele usando o Cofre de Credenciais, as credenciais armazenadas acompanham a conta da Microsoft dele em qualquer outro computador confiável usado por ele com essa conta da Microsoft. Isso torna o seu aplicativo seguro ainda mais prático para os seus usuários porque o seu aplicativo fará o logon deles automaticamente — sem solicitar as credenciais novamente — de qualquer computador confiável em que eles tiverem instalado o seu aplicativo e associado a sua conta da Microsoft.

As coisas funcionam um pouco diferente em contas de domínio. Se houver credenciais armazenadas com a sua conta da Microsoft e você associar essa conta a uma conta de domínio (como a conta que você usa no trabalho), as suas credenciais serão transferidas para essa conta de domínio. No entanto, quaisquer novas credenciais adicionadas enquanto o usuário estiver conectado com a conta de domínio não serão transferidas. Isso garante que as credenciais privadas do domínio não sejam expostas fora do domínio.

Armazenando as credenciais do usuário

Armazenar as credenciais do usuário no Cofre de Credenciais é um processo rápido de duas etapas. Primeiro, você obtém uma referência para o Cofre de Credenciais usando o objeto PasswordVault no namespace Windows.Security.Credentials. Depois, você cria um objeto PasswordCredential com um identificador do seu aplicativo, o nome de usuário e a senha, e transfere isso para o método PasswordVault.Add() para adicionar a credencial ao cofre.

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.add(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Recuperando as credenciais do usuário

Há várias opções para recuperar as credenciais do usuário do Cofre de Credenciais depois de obter uma referência ao objeto PasswordVault.

• Você pode recuperar todas as credenciais fornecidas pelo usuário para o seu aplicativo no cofre com o método PasswordVault.RetrieveAll().
• Se souber o nome de usuário das credenciais armazenadas, você poderá recuperar todas as credenciais desse nome de usuário com o método PasswordVault.FindAllByUserName().
• Se souber o nome do recurso das credenciais armazenadas, você poderá recuperar todas as credenciais do nome desse recurso com o método PasswordVault.FindAllByResource().
• Se souber o nome de usuário e o nome do recurso de uma credencial, você poderá recuperar apenas essa credencial com o método PasswordVault.Retrieve().

Vejamos um exemplo em que armazenamos o nome do recurso globalmente em um aplicativo e fazemos o logon do usuário automaticamente se localizarmos uma credencial para ele. No caso de localizarmos várias credenciais do usuário, solicitamos que o usuário selecione uma credencial padrão para usar ao fazer logon.

C#

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    var loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }

    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}


private Windows.Security.Credentials.PasswordCredential GetCredentialFromLocker()
{
    Windows.Security.Credentials.PasswordCredential credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.FindAllByResource(resourceName);
    if (credentialList.Count > 0)
    {
        if (credentialList.Count == 1)
        {
            credential = credentialList[0];
        }
        else
        {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, then display UI to have the user select
            // a default username.

            defaultUserName = GetDefaultUserNameUI();

            credential = vault.Retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

var resourceName = "My App";
var defaultUserName;

function login() {
    var loginCredential = getCredentialFromLocker();

    if (loginCredential != null) {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.retrievePassword();
    } else {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = getLoginCredentialUI();
    }

    // Log the user in.
    serverLogin(loginCredential.userName, loginCredential.password);
}


function GetCredentialFromLocker() {
    var credential = null;

    var vault = new Windows.Security.Credentials.PasswordVault();
    var credentialList = vault.findAllByResource(resourceName);
    if (credentialList.length > 0) {
        if (credentialList.length == 1) {
            credential = credentialList[0];
        } else {
            // When there are multiple usernames,
            // retrieve the default username. If one doesn’t
            // exist, display UI to have the user select
            // a default username.

            defaultUserName = getDefaultUserNameUI();
            credential = vault.retrieve(resourceName, defaultUserName);
        }
    }

    return credential;
}

Excluindo credenciais do usuário

Excluir as credenciais do usuário no Cofre de Credenciais também é um processo rápido de duas etapas. Novamente, você obtém uma referência para o Cofre de Credenciais usando o objeto PasswordVault no namespace Windows.Security.Credentials. Depois, você passa a credencial que deseja excluir para o método PasswordVault.Remove().

C#

var vault = new Windows.Security.Credentials.PasswordVault();
vault.Remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

JavaScript

var vault = new Windows.Security.Credentials.PasswordVault();
vault.remove(new Windows.Security.Credentials.PasswordCredential(
    "My App", username, password));

Fácil e seguro

Como você pode ver, o Cofre de Credenciais é um recurso fácil de usar que simplifica a sua tarefa de autenticar usuários e armazenar as credenciais deles para uso futuro, tudo de uma forma altamente segura.

Outros tópicos de autenticação de aplicativos do Windows 8 incluem o agente de autenticação da Web, que você pode usar para recuperar um token de autenticação de um site (por exemplo, OAuth) e a personalização do seu aplicativo com base na conta da Microsoft de um usuário.

Para obter mais informações, consulte

• Gerenciando informações de usuários (JavaScript)
• Managing user info (Windows Store apps using C#/VB/C++ and XAML) (Gerenciando as informações do usuário (aplicativos da Windows Store usando C#/VB/C++ e XAML))
• Exemplo de Cofre de Credenciais
• Windows.Security.Credentials

--Doug Rothaus, desenvolvedor de conteúdo sênior, Conteúdo para desenvolvedores do Windows

Agradecimentos especiais para Yashar Bahman por sua ajuda e contribuições para esta postagem.

Ao experimentar em conjunto a localização de um usuário com a lógica de negócios do seu aplicativo, você pode fornecer facilmente aos usuários do aplicativo detalhes sobre a previsão do tempo, cupons, eventos esportivos ou concertos para sua localização atual. Você pode usar as funcionalidades de geolocalização do Windows 8, juntamente com o SDK do Mapas Bing, para criar ótimos aplicativos da Windows Store com reconhecimento de local.

Vejamos como seu aplicativo pode usar o serviço de localização para fornecer aos usuários informações específicas do local com um endereço IP, uma rede WiFi ou dados de GPS. Após saber a localização, você poderá usar o SDK do Mapas Bing para mostrar ao usuário onde ele está.

Recuperando sua localização

O namespace Windows.Devices.Geolocation é usado para recuperar sua localização. Se você usará o GPS, uma rede WiFi ou um endereço IP para recuperar a localização de um usuário dependerá de dois fatores básicos:

1. O nível de precisão solicitado. Este é o nível de precisão ideal para atender as necessidades do seu aplicativo.
2. A disponibilidade dos dados de localização. Nem todos os dispositivos têm GPS interno. Ou talvez não haja uma rede ou conexão Wi-Fi disponível quando a localização for solicitada.

Precisão desejada

Ao solicitar uma localização, seu aplicativo deve especificar a precisão desejada para que os dados de localização possam ser retornados o mais rápido possível no intervalo determinado. Cada um dos tipos de local tem um grau de precisão:

• GPS – o GPS fornece a maior precisão, até aproximadamente 10 metros. No entanto, se o sensor do GPS precisar ser ativado e adquirir dados de satélite para em seguida fazer a triangulação dos dados, ele poderá levar um ou dois minutos para retornar os detalhes da localização. Mas após o GPS adquirir as conexões de satélite, será possível obter o próximo ponto de localização com mais rapidez. Obviamente que quanto mais o GPS for usado, mais energia consumirá. A propriedade Geolocator.DesiredAccuracy deve ser definida como High (Alta) para permitir que o GPS adquira os dados.
• Wi-Fi – uma conexão Wi-Fi pode fornecer uma precisão entre 300-500 metros. Se houver uma conexão, os dados de localização serão retornados mais rapidamente do que um GPS poderá obter dados de satélite. Defina a propriedade DesiredAccuracy como Default (Padrão) para obter a localização com Wi-Fi.
• IP – a resolução no nível do IP pode fornecer uma precisão dentro de 1 quilômetro, aproximadamente. Se houver uma conexão de rede, os dados de localização serão retornados mais rapidamente do que um GPS poderá obter uma conexão de satélite. Você também define a propriedade DesiredAccuracy como Default (Padrão) para obter a localização com IP. O serviço de localização retorna a maior precisão possível e permite que você saiba o grau de precisão na propriedade Geocoordinate.Accuracy.

Preste atenção ao valor de precisão desejado. Ele pode afetar o desempenho e o consumo de energia do seu aplicativo. Por exemplo, se o seu aplicativo fornecer previsões de tempo, você raramente precisará da alta precisão do GPS. Além disso, não deixe de indicar a precisão dos seus dados exibindo o radius de erro baseado na precisão dos dados retornados. Aqui está o código C# para definir a precisão desejada:

C#

Geolocator geolocator = new Geolocator();
geolocator.DesiredAccuracy = Windows.Devices.Geolocation.PositionAccuracy.High;

C#

Geoposition pos = await geolocator.GetGeopositionAsync().AsTask(token);

Aqui está o código JavaScript que cria uma instância da classe Geolocator, define a precisão desejada e obtém a localização atual. Observe que a variável "promise" abaixo é um objeto WinJS.Promise – você precisará usar o método done para acessar os dados da chamada para getGeopositionAsync.

JavaScript

var geolocator = Windows.Devices.Geolocation.Geolocator();
geolocator.desiredAccuracy =
Windows.Devices.Geolocation.PositionAccuracy.high;

// Get the geoposition, capturing the request in a 'promise' object.
var promise = geolocator.getGeopositionAsync();

Mapas Bing

O aplicativo Mapas Bing é um bom exemplo de um aplicativo que se adapta à precisão dos dados de localização disponíveis. Em um PC desktop, que em geral não tem um GPS ou Wi-Fi, ele acha a localização com base no endereço IP e a amplia para um nível de região ao mapear o local atual. Em um laptop, que normalmente tem uma placa sem fio, o aplicativo usa a conexão Wi-Fi para obter uma localização mais precisa e a amplia ainda mais ao mostrar a localização atual. Se o usuário ampliar mais ainda, o ícone da localização atual mostrará um radius de erro. Em um dispositivo com GPS, o Mapas Bing obtém os dados de localização de maior precisão do GPS e exibe uma localização mais precisa.

Bing Meteorologia

Como mencionado acima, um aplicativo como o Bing Meteorologia precisa somente das informações de região. Por isso, ele pode especificar a necessidade apenas da menor precisão, permitindo a obtenção rápida de um valor de localização. Isso aumenta a capacidade de resposta do aplicativo para o usuário. Outros exemplos de aplicativos que podem precisar somente das informações de nível regional incluem guias de estações de rádio, ofertas de compras ou feeds de notícias locais.

Exibindo dados de localização com o SDK do Mapas Bing

Após obter as informações de localização de sua chamada para GetGeopositionAsync, você desejará exibi-las em um mapa.

• Primeiro, converta a Geoposição em uma Localização que possa ser usada com o Mapas Bing, use o código a seguir:

C#

Location location = new Location(pos.Coordinate.Latitude, pos.Coordinate.Longitude);

JavaScript:

promise.done(
  function (pos) {
    // Get the coordinates of the current location.
    var coord = pos.coordinate,
    location = new Microsoft.Maps.Location(coord.latitude, coord.longitude);
 
  },
  function (err) {
    // Handle the error.
  });

• Em seguida, exiba sua localização usando o Mapas Bing. Você pode obter o SDK do Mapas Bing aqui. Você também precisará obter uma chave do Mapas Bing fazendo o registro no Portal do Mapas Bing e seguindo as instruções para Obter uma Chave do Mapas Bing. Ao se registrar, não deixe de ver as restrições de uso para cada tipo de chave e escolha uma que seja apropriada para seu aplicativo.
  Adicione um controle do Mapas Bing ao seu designer e insira sua chave nas credenciais.

<Page
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:SimpleMapping"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:Maps="using:Bing.Maps"
    x:Class="SimpleMapping.MainPage"
    mc:Ignorable="d">

    <Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
        <Maps:Map x:Name="Map" Margin="0,120,0,0" Credentials="Insert Your Bing Maps Key Here"/>
    </Grid>
</Page>

• Agora você já pode usar o código a seguir na página do aplicativo em que o mapa é exibido. Isso define o nível de zoom do mapa e mostra a localização. Saiba mais sobre o nível de zoom em Como exibir sua localização em um Mapa Bing:

C#

double zoomLevel = 13.0f;

Map.SetView(location, zoomLevel);

<script type="text/javascript" 
   src="ms-appx:///Bing.Maps.JavaScript//js/veapicore.js">
/script>

Em seguida, você precisará criar uma marca <div>para conter o mapa, configurando o atributo de id para que possa acessá-lo.

<div id=’map-div’></div>

Por fim, será necessário inicializar o controle do mapa na página em HTML. Veja aqui alguns códigos JavaScript que fazem isso:

// Load the Microsoft.Maps.Map module and then call getMap when the 
// module has loaded.
function initMap() {
  Microsoft.Maps.loadModule('Microsoft.Maps.Map', 
    { 
      callback: getMap, 
      culture: "en", 
      homeRegion: "US" 
  });
}

// Get the div to contain the map from the interface of the app.
function getMap() {

  // Create a new instance of the Map class, passing in the app ID.
  var map = new Microsoft.Maps.Map(
    document.getElementById(mapDivId), 
    { credentials: “Insert your credentials here” });

  // Set the initial zoom level and type of map.
  map.setView({
    mapTypeId: Microsoft.Maps.MapTypeId.road,
    zoom: 3
  });
}

• Qualquer aplicativo que usa localização deve respeitar as configurações das permissões do usuário, que podem ser alteradas a qualquer momento. O aplicativo Meteorologia usa a localização para obter a previsão do tempo para o local atual. Mas a qualquer momento, o usuário poderá acessar as Configurações e desativas as permissões de Localizações. Seu aplicativo deve sempre lidar com a possibilidade de que a permissão de Localização esteja desabilitada. Nesse caso, o aplicativo Meteorologia exibe uma mensagem "Não é possível encontrar sua localização. Altere suas permissões para que o Meteorologia possa usar sua localização". Consulte as diretrizes de experiência do usuário em Diretrizes para aplicativos com reconhecimento de local para obter exemplos de como lidar com permissões de localização.
  

Para obter todos os detalhes de como usar a geolocalização e o SDK do Mapas Bing, temos um novo vídeo, tópico de como fazer e exemplo de código que explica as etapas de como adquirir de forma assíncrona sua localização e usar o SDK do Mapas Bing para mostrar onde você está visualmente. O vídeo, o tópico de como fazer e o exemplo guiam você sobre como habilitar a funcionalidade de localização, como obter a localização assincronamente, como configurar o mapa para um determinado local e como configurar o ícone de localização baseado na precisão dos dados de localização. Você também pode encontrar mais informações em Mapas Bing para aplicativos da Windows Store.

Resumindo

A localização pode ser um recurso poderoso e ágil para adicionar ao seu aplicativo. Você pode fornecer ao usuário mais informações pertinentes baseado em onde ele está. Seja uma lista de estações de rádio locais, ofertas de compras, informações de trânsito ou do tempo, o controle para ajustar essas informações de acordo com a localização pode tornar seu aplicativo mais útil. A capacidade de fazer isso acontecer automaticamente, sem a interação do usuário, economiza tempo e aumenta a probabilidade de uso do seu aplicativo.

--Ross Heise, desenvolvedor de conteúdo sênior, Conteúdo para desenvolvedores do Windows

   Agradecimentos especiais a Jon Kay e Eric Schmidt pela ajuda e contribuições para esta postagem.

Desde o lançamento do Centro de Desenvolvimento do Windows em outubro de 2011, temos trabalhado de perto com desenvolvedores e designers do mundo todo para saber como podemos oferecer a melhor orientação, inspiração e amostras para criadores de aplicativos. Com milhares de visitantes e os seus comentários, temos avaliado o que tem funcionado bem e quais experiências podem ser aprimoradas.

Novidades

A equipe do Windows está focada em cultivar um ecossistema de aplicativos vibrante e crescente. Isso se manifesta de três formas: ótimos aplicativos, ótima economia e ótima oportunidade de alcance. O novo Centro de Desenvolvimento conecta criadores de aplicativos, designers e empresas aos recursos necessários para obterem sucesso no desenvolvimento de ótimos aplicativos e na criação de um negócio com o Windows.

Para dar suporte a essas metas, estas áreas do Centro de Desenvolvimento foram desenvolvidas:

1. O modelo de navegação foi alterado para que você possa localizar o conteúdo relevante à etapa do ciclo de vida do desenvolvimento de aplicativos
2. O site cria tarefas de destaque, cenários e novo conteúdo

Além do conteúdo, amostras e downloads que os desenvolvedores desejam; facilitamos o acesso a recursos para designers e empresas.

Dependendo do que estiver criando, você pode acessar uma destas quatro áreas: Aplicativos da Windows Store, Internet Explorer, Windows desktop e Hardware. Cada uma delas apresenta uma nova experiência que aborda os pontos mencionados acima. Nesta postagem, veremos detalhadamente as alterações específicas feitas para os aplicativos da Windows Store.

O conteúdo certo para a sua função

O site mais informativo deixa de ser útil se a pessoa não conseguir encontrar o que procura. Com centenas de milhares de tópicos no Centro de Desenvolvimento, a organização e a capacidade de descobrir conteúdo é crítica. Para o desenvolvimento de aplicativos da Windows Store, isso significa um foco mais estrito, com base na função e no cenário, desde colocar tudo o que você precisa para começar em um lugar até dar um melhor suporte a designers e empresas. Aqui estão alguns dos destaques.

Desenvolvedores

Simplificamos o conteúdo de que você precisa para criar ótimos aplicativos da Windows Store. Ao acessar a home page dos aplicativos da Windows Store, você verá:

• “Principais tarefas e conteúdo” em destaque para ajudá-lo a acessar rapidamente o conteúdo de que você precisa. Os eventos locais na sua região são destacados, bem como novos recursos que acabamos de incluir no site.
• Downloads para ajudá-lo a acessar diretamente a codificação, todos os recursos necessários para você começar e orientação detalhada sobre como colocar o seu aplicativo na Windows Store.
• Exemplos de código importantes são realçados, e orientações passo a passo têm uma navegação mais fácil tendo em foco o ciclo de vida do desenvolvimento.
• “Os vídeos rápidos para o desenvolvedor” encontrados em todo o site oferecem uma visão geral de como adicionar recursos ao seu aplicativo.

Designers

Fizemos algumas modificações na seção de design do site para facilitar seu uso e torná-la mais abrangente. Você pode localizar downloads úteis e ativos de design reutilizáveis mais facilmente, e, com os estudos de caso e ideias de design, você tem as ferramentas necessárias para criar uma experiência exclusiva no Windows. Tudo o que você precisa para criar um lindo aplicativo que se destaque dos outros está ao alcance das suas mãos, com um design de página voltado para o toque e fácil de usar.

Empresas

A oportunidade da Windows Store para as empresas é significativa, com um modelo econômico melhor do que o das plataformas competitivas e flexibilidade que permite criar o negócio que desejar. A nova seção sobre mercado do site oferece ótimas dicas para comercializar os seus aplicativos, avaliar dados telemétricos e obter a certificação de aplicativos. Aprendemos muito sobre como facilitar a certificação e melhoramos o conteúdo para ajudá-lo a passar pelo processo mais rapidamente.

Muitos de vocês, obviamente desempenham várias funções. Acreditamos que a nova organização do site dê suporte a isso também. De entusiastas e agências publicitárias às grandes empresas desenvolvedoras de software, a nova organização do site ajudará todos a realizarem seus projetos e a alcançarem suas metas de negócios com o Windows.

Há muito mais por vir. O seu feedback é importante.

Com o BUILD 2013 daqui a pouco mais de um mês, teremos muito o que falar. Estamos trabalhando muito para criar novo conteúdo para ser compartilhado no evento deste ano. Além de acompanhar este blog, estas são outras maneiras de você ficar conectado: seguir @windevs no Twitter e assinar o Boletim informativo da Windows Store.

Conforme apresentamos mais conteúdo para ajudá-lo a criar, desenvolver e comercializar os seus aplicativos da Windows Store, desejamos continuar aperfeiçoando a sua experiência no Centro de Desenvolvimento! Para facilitar o seu feedback, agora oferecemos duas novas opções de comentários na parte inferior de cada página. Faça comentários. Eles são lidos e estamos sempre trabalhando para atender às suas necessidades.

Keith Boyd, gerente de publicação de conteúdo, Conteúdo do desenvolvedor do Windows

Na postagem Compartilhando de seu aplicativo, apresentamos a ideia de compartilhar conteúdo do aplicativo de exemplo Food with Friends com vários aplicativos de destino que permitem ao usuário executar cenários completos e sofisticados. Os aplicativos no Windows 8 oferecem um conteúdo interessante que os seus clientes desejarão compartilhar com os amigos e outros aplicativos. Com um compartilhamento de destino atraente e bem projetado, o seu aplicativo pode ser o centro de uma experiência conectada e social.

Nesta postagem, veremos como você pode usar o contrato de Compartilhamento de Destino nos seus aplicativos, especialmente aqueles como o Food with Friends. Usando esse contrato, o seu aplicativo pode receber conteúdo de outros aplicativos e usar esse conteúdo para melhorar sua qualidade. Desejamos ajudá-lo a tornar o seu aplicativo o melhor de sua categoria!

O aplicativo de destino é criado usando o contrato de Compartilhamento de Destino e é desenvolvido para proporcionar uma experiência rápida e fácil. Nem todo aplicativo no Windows será um compartilhamento de destino, mas se o seu aplicativo puder publicar, transformar, armazenar ou agregar valor, de alguma forma, ao conteúdo que receber de outro aplicativo, haverá benefícios na criação de um compartilhamento de destino.

• O seu aplicativo sempre aparecerá na lista de aplicativos de destino. Ele é conectado instantaneamente e relevante a outros aplicativos que podem compartilhar dados desejados por você.
• O contrato de compartilhamento cria uma ponte entre o seu aplicativo e qualquer aplicativo de origem sem que seja necessário que nenhum dos dois tenha uma integração um-para-um.
• Como o botão Compartilhar está sempre presente e disponível no sistema operacional, isso proporciona ao aplicativo de destino uma presença no sistema operacional que vai além das fronteiras do seu aplicativo. Isso poderá direcionar mais clientes para o seu aplicativo!

Recebendo conteúdo compartilhado

Vejamos alguns exemplos que mostrarão como você pode oferecer experiências atraentes por meio de um aplicativo de compartilhamento de destino.

Talvez você já esteja familiarizado com os aplicativos Email e Pessoas do Windows 8. O Email cria uma experiência de compartilhamento de destino fácil e pessoal para receber e compartilhar conteúdo com um ou mais amigos. O aplicativo Pessoas permite compartilhar conteúdo com uma audiência maior nas suas redes sociais. Além do compartilhamento em redes sociais, você pode ir além com o compartilhamento entre aplicativos. Aplicativos de produtividade, como o SkyDrive, podem receber arquivos de qualquer lugar do Windows e armazená-los na nuvem; os aplicativos de anotação podem receber texto, links e, possivelmente, dados em uma grande variedade de formatos diferentes e arquivá-los para futura referência. Também há bastante espaço para a criatividade.

Veja como as duas imagens abaixo mostram o fluxo de compartilhamento ao compartilhar uma foto do aplicativo Fotos com o PuzzleTouch, um aplicativo de jogo que transforma uma imagem em um quebra-cabeça visual.

Figura 1: Aplicativo de origem à esquerda, lista de aplicativos de destino que podem receber fotos no painel Compartilhar à direita.
O PuzzleTouch é um dos compartilhamentos de destino que podem receber uma imagem do aplicativo Fotos.

Figura 2: À direita, a visualização do aplicativo de destino permite ao usuário selecionar o tipo de quebra-cabeça que
deseja criar. O quebra-cabeça fica pronto quando o usuário volta ao aplicativo.

O que é um aplicativo de compartilhamento de destino?

Uma experiência de compartilhamento completa no Windows tem dois componentes. Temos um aplicativo de origem que torna o conteúdo disponível em diferentes formatos para o Windows. Temos também um aplicativo de compartilhamento de destino que se registra para reconhecer determinados formatos e atua como o destino para o conteúdo compartilhado. Usando o contrato de Compartilhamento, o aplicativo de origem e o aplicativo de compartilhamento de destino se comunicam entre si.

Ao pensar sobre a experiência de compartilhamento para o seu aplicativo, considere que o aplicativo de compartilhamento de destino é renderizado na janela Compartilhar hospedada. Projete a experiência para que o seu usuário possa visualizar seu conteúdo rapidamente e confirmar o compartilhamento nessa exibição. Este exemplo mostra a exibição do aplicativo de compartilhamento de destino Email que permite a um usuário compartilhar rapidamente um link do navegador com um de seus contatos do Email.

Figura 3: Compartilhando um link do aplicativo Fotos usando o aplicativo de destino Email

Cenários do Food with Friends

Agora, vamos considerar como o Food with Friends cria uma experiência atraente de aplicativo de compartilhamento de destino. Se você estiver familiarizado com o aplicativo, você verá duas ações principais que um usuário pode realizar no Food with Friends – criando um plano e adicionando um restaurante à sua lista de desejos. É claro que há outras ações, como escrever uma opinião, postar um comentário, exibir listas de desejos dos seus amigos etc., mas essas experiências somente fazem sentido dentro do contexto do aplicativo principal. Nos dois cenários básicos que se destacam, vamos fazer uma verificação de integridade rápida para ver se podem ser realizados efetivamente pelo aplicativo de destino Food with Friends.

Criar o plano desta noite

Embora seja o cenário básico do aplicativo principal, ele não é o melhor cenário para uma experiência de compartilhamento de destino. Veja o motivo: A experiência de compartilhamento de destino tem o objetivo de ser rápida e fácil. A criação de um plano é uma tarefa muito mais complexa: o usuário poderia desejar saber quais outros restaurantes seus amigos desejam experimentar, comparar alguns restaurantes da lista de desejos, examinar classificações etc. Como o planejamento envolve o aproveitamento de detalhes cuja apresentação é melhor na exibição do aplicativo principal, condensar essa funcionalidade em um aplicativo de compartilhamento de destino não é atraente.

Adicionar à lista de desejos

Esse cenário funciona realmente bem como uma tarefa curta e direcionada no compartilhamento de destino. Alguns destaques nessa experiência do aplicativo:

• As pessoas veem restaurantes em outros aplicativos, sejam aplicativos de planejamento de viagens, aplicativos da cidade local com recomendações, blogs sobre comida etc. O Food with Friends é um ótimo destino para agregar restaurantes na seção "My Wishlist" (Minha lista de desejos).
• A exibição do aplicativo de destino de um aplicativo é criada para que um usuário aja rapidamente no contexto de um aplicativo diferente. Portanto, a adição de um restaurante na lista de desejos é uma excelente opção para emergir no compartilhamento de destino.
• Embora certamente seja possível ao usuário fazer a alternância entre aplicativos, repetir a pesquisa para localizar o restaurante e adicionar o restaurante à lista de desejos, tocar rapidamente em Compartilhar é muito mais fácil.

A lista de desejos do Food with Friends parece ser uma ótima experiência de aplicativo de compartilhamento de destino que desejamos projetar e compilar. Veja o cenário completo que temos em mente:

Ao navegar em um aplicativo que mostre caminhões de comida local, encontro recomendações desses caminhões que parecem interessantes. Desejo adicionar o caminhão de comida desse aplicativo na minha lista de desejos do Food with Friends para ajudar no planejamento depois.

Figura 4: Navegando em um aplicativo que mostra caminhões de comida local e recomenda lugares de interesse

Essa imagem mostra a exibição do aplicativo de compartilhamento de destino que desejamos usar:

Figura 5: Exibição do aplicativo de compartilhamento de destino

Realizando a ação de compartilhamento na exibição do aplicativo de destino, os usuários podem ver os restaurantes do Food with Friends sem alternar o contexto da experiência de imersão do aplicativo atual.

Implementando um compartilhamento de destino

Agora que você viu alguns exemplos de quando implementar um compartilhamento de destino, vejamos como implementar um compartilhamento de destino. Primeiro, decida quais formatos de dados o seu aplicativo poderá receber.

A quais formatos de dados você deve dar suporte?

Com o Compartilhar, você pode dar suporte tanto a formatos de dados padrão, como texto, URI, HTML, bitmaps, arquivos ou formatos de dados personalizados, como os listados em http://schema.org . O Windows filtra aplicativos de destino por formatos de dados a que dão suporte para exibir a lista de aplicativos de destino filtrada no painel Compartilhar. O seu aplicativo deve dar suporte a formatos de dados que são importantes para a experiência do aplicativo. Por exemplo, se o seu aplicativo for voltado para a exibição de fotos, o suporte a formatos de texto pode não ser útil. Se você declarar suporte a vários formatos de dados, decida qual deles ajudará a representar os dados compartilhados melhor para que você possa separar esse formato no pacote de dados primeiro.

Como o Food with Friends está implementando uma experiência de compartilhamento de destino que permite aos usuários compartilhar restaurantes com o aplicativo, vamos usar o formato de dados Restaurant (Restaurante) que aparece em http://schema.org. O Food with Friends pode se registrar com o contrato de Compartilhamento de destino para receber esse formato de dados. Em seguida, usado os dados no pacote recebido, ele pode criar uma experiência atraente na exibição de seu aplicativo de destino que permita ao usuário adicionar o restaurante na sua lista de desejos.

Embora alguns aplicativos de origem possam compartilhar especificamente o formato de dados Restaurant, outros aplicativos de origem podem representar informações semelhantes usando outros formatos de dados, como Place (Local), LocalBusiness e FoodEstablishment relacionados em schema.org. Dessa forma, o Food with Friends pode dar suporte ao recebimento de vários formatos no contrato de compartilhamento para acomodar uma variedade maior de aplicativos de origem.

O Food with Friends dá suporte aos seguintes formatos nas declarações de compartilhamento de destino do manifesto do aplicativo:

• Restaurant
• Place
• LocalBusiness
• FoodEstablishment

Estamos nos concentrando no tipo de dados Restaurant para simplificar, mas os conceitos também se aplicam a outros tipos de dados.

Quais formatos de dados e cenários você deve examinar?

O Food with Friends somente permitirá a adição do restaurante à lista de desejos do usuário se as informações do restaurante recebidas corresponderem às de um restaurante já conhecido pelo aplicativo. Isso é intencional para evitar várias cópias de restaurantes no aplicativo.

Não damos suporte a tipos de dados padrão porque a maioria dos textos, arquivos, fotos, URI ou HTML compartilhados de aplicativos de origem não são mapeados para um restaurante ou empresa local. Por exemplo, se o Food with Friends desse suporte ao recebimento de texto, ele apareceria na lista de aplicativos de destino de um aplicativo de origem de anotação. Nesse caso, o Food With Friends precisaria fornecer uma mensagem de erro informando ao usuário o motivo desse aplicativo não funcionar com seu aplicativo de origem. Resumindo, os formatos de dados são o que conectam um aplicativo de origem que tem algo a oferecer a um aplicativo de destino. Se os formatos de dados não forem os mesmos, não há nada que valha a pena compartilhar.

Considere todos os formatos de dados que ajudam a identificar o que é importante, examine os formatos de dados que diluem a sua experiência de compartilhamento.

Dando suporte ao contrato de Compartilhamento de Destino

Para dar suporte a formatos de dados, declare-os no designer de manifesto do Visual Studio do seu aplicativo. Isto é o que acontece quando um usuário seleciona o seu aplicativo como o destino de uma ação de compartilhamento:

1. Uma nova instância do aplicativo é iniciada na janela de compartilhamento de destino sobre o aplicativo de origem.
2. Um evento de ativação de compartilhamento de destino é iniciado e o seu aplicativo recebe um objeto ShareOperation como resultado.
3. O seu aplicativo pode recuperar os dados que o usuário compartilhou desse objeto.
4. Você pode usar esses dados para renderizar a exibição do aplicativo de destino e realizar o compartilhamento do usuário.

Para obter mais informações sobre como criar essa experiência, consulte o guia Início rápido: recebendo conteúdo compartilhado.

Além disso, o Visual Studio dá suporte a um modelo para o compartilhamento de destinos. Clique com o botão direito no seu projeto, selecione Adicionar Item, Adicionar Novo Item, clique em contrato de Compartilhamento de Destino na lista. Você terá o código adicionado para dar suporte ao contrato. O Exemplo de código de compartilhamento de destino mostra como receber conteúdo compartilhado.

Projetando uma exibição de aplicativo de destino personalizada

Quando o usuário seleciona um aplicativo de destino na lista de aplicativos do painel Compartilhar, o Windows inicia o aplicativo na exibição de destino de compartilhamento do aplicativo. A exibição do aplicativo de destino é uma exibição especial hospedada no painel Compartilhar e é diferente da exibição principal do aplicativo. Ativando contratos do Windows 8 no seu aplicativo fornece mais informações sobre exibições hospedadas e o gerenciamento da ativação dessas exibições. A exibição do aplicativo de destino foi projetada para concluir a ação de compartilhamento iniciada pelo usuário. Nessa exibição, os usuários podem visualizar seu conteúdo rapidamente, executar ações simples e confirmar sua intenção de compartilhar.

Antes de olharmos para o projeto do aplicativo de destino do Food with Friends, vamos considerar um aplicativo de destino que talvez você já conheça. As imagens abaixo mostram a exibição do aplicativo de destino do aplicativo Email ao lado da exibição completa do aplicativo no Windows 8.

Figura 6: Compartilhando de Fotos para o aplicativo de destino Email à direita

Figura 7: Redigindo um novo email na exibição do aplicativo principal do Email

Observe que a exibição do aplicativo de compartilhamento de destino do Email é mais simples do que a exibição completa do aplicativo. Ela fornece uma visualização limpa e minimalista do conteúdo que o usuário compartilhará em formato de miniatura com HTML e texto associado. Ela oferece uma linha Para para adicionar destinatários, uma área de entrada para a redação de uma mensagem rápida e uma maneira fácil de confirmar o envio do email com o botão Enviar.

Apesar dessa exibição mais simples, a exibição do aplicativo de destino do aplicativo pode ser identificada de forma nítida como um avatar do aplicativo Email, o que reforça a confiança do usuário quanto ao destino do conteúdo compartilhado.

Food with Friends como um aplicativo de compartilhamento de destino

Agora que você tem uma ideia geral sobre o projeto de exibição do aplicativo de destino, vamos ver como o Food with Friends pode criar um aplicativo de destino que ajuda os usuários a adicionar restaurantes à lista de desejos.

Quando o Food with Friends recebe o pacote de dados contendo um Restaurant do aplicativo de origem, ele pode usar os detalhes no formato de dados Restaurant para identificar qual restaurante de seu banco de dados corresponde ao pacote de dados recebido. O aplicativo poderá então mostrar uma visualização desse restaurante na exibição do aplicativo de destino. Isso reforça a confiança na integridade do conteúdo compartilhado.

Essa imagem mostra a exibição do aplicativo de destino do Food with Friends –

Figura 8: Exibição do aplicativo de destino do Food with Friends

Como você pode ver, essa exibição do Food with Friends é simples e personalizada para um aplicativo de compartilhamento de destino. Ela mostra uma visualização do restaurante que o usuário está prestes a compartilhar e um botão simples que pode ser acionado, Adicionar à Lista de Desejos, que esclarece o destino do conteúdo compartilhado no aplicativo principal. Quando o usuário toca ou clica nesse botão, ele confirma a operação de compartilhamento. Exigindo um toque ou clique aqui, ajudamos a impedir um compartilhamento acidental e a construir confiança na experiência geral de Compartilhamento.

Se o aplicativo localizar vários restaurantes que correspondam às informações do conteúdo do pacote de dados, o Food with Friends usará a exibição do compartilhamento de destino para mostrar as opções e permitir que o usuário separe aqueles a serem compartilhados.

Figura 9: Exibição do aplicativo de destino mostra as opções para que os usuários possam escolher os itens a compartilhar

Caso o aplicativo não possa identificar um restaurante de forma precisa ou um conjunto válido de opções com base no pacote de dados recebido, use a exibição do aplicativo de destino para comunicar essa mensagem.

Criando um QuickLink

O QuickLink é uma provisão da API de compartilhamento que permite aos usuários compartilhar conteúdo para destinos familiares dentro do seu aplicativo de destino rapidamente. Um QuickLink funciona como um link personalizado para a sua exibição de destino, fornecendo ações específicas. Quando o Windows filtra a lista de aplicativos de destino disponíveis para o usuário, a lista do QuickLinks é apresentada na parte superior do painel Compartilhar como a lista de destinos disponíveis. Essas ações do usuário e destinos familiares podem incluir locais ou pessoas com os quais são feitos compartilhamentos com frequência por meio do aplicativo de destino. Por exemplo, o aplicativo Email retorna QuickLinks para contatos a que foram enviados emails anteriormente. Da mesma forma, você pode adicionar QuickLinks a pastas, grupos, blocos de anotações e listas de reprodução que você compartilha com frequência ao seu aplicativo de destino.

Figura 10: Painel Compartilhar mostra um QuickLink fornecido pelo aplicativo de destino Email para contatos
que receberam emails anteriormente por meio do aplicativo de destino

O aplicativo de destino pode oferecer um QuickLink com o método de objetos ShareOperation reportCompleted . Um QuickLink deve ter um título, um ícone e uma ID. O título (como "Enviar email para mãe") e o ícone aparecem quando o usuário toca no botão Compartilhar. A ID é o que o seu aplicativo usa para acessar quaisquer informações personalizadas, como um endereço de email, o local de uma pasta etc. Consulte Como criar um objeto QuickLink para saber mais sobre essa ferramenta. 

Observação: os QuickLinks são úteis quando o aplicativo dá suporte a várias ações do aplicativo de destino. Como o Food with Friends somente dá suporte a uma única ação no destino de compartilhamento (Adicionar a lista de desejos), i aplicativo não implementa QuickLinks.

Compartilhamento estendido e relatório de erros

Às vezes, os aplicativos de origem compartilham grandes partes de dados, como fotos, vídeos ou arquivos, resultando em transferências de dados mais demoradas. Esses tipos de operações de compartilhamento são conhecidos como compartilhamentos estendidos nos quais o seu aplicativo de destino pode precisar de mais tempo para receber e processar os dados.

Como o compartilhamento deve ser rápido e fluido, e a exibição do aplicativo de destino é leve, hospedada no aplicativo principal, os usuários podem tocar na exibição do aplicativo de destino para retornar ao aplicativo principal. Portanto, os aplicativos de destino não devem depender de uma interação do usuário (ou esperá-la) com a exibição de aplicativo de destino após o início do compartilhamento. Os aplicativos de destino podem depender do uso do objeto ShareOperation e seu método para informar ao Windows que o aplicativo está processando dados.

• reportStarted – use esse método para informar ao Windows que o seu aplicativo começou a recuperar os dados do objeto DataPackage do aplicativo de origem.
• reportDataRetrieved – use esse método para informar ao Windows que o seu aplicativo concluiu a recuperação dos dados do pacote.
• reportCompleted – use esse método para informar ao Windows que o seu aplicativo concluiu a operação de compartilhamento.

Quando o seu aplicativo estiver processando os dados para um compartilhamento estendido, forneça ao usuário uma interface do usuário de andamento na exibição do aplicativo de destino. Isso informa o usuário de que a solicitação dele está em andamento e reforça a confiança quando ele retornar ao seu aplicativo e verificar o progresso da operação de compartilhamento. Consulte Quickstart: adding progress controls (Quickstart: adicionando controles de progresso) para saber mais sobre os controles de progresso no Windows 8.

Figura 11: A exibição do aplicativo de destino do Email mostra um anel de progresso ao concluir um compartilhamento estendido, como o envio de anexos grandes

Se algo der errado durante a transferência de dados e o seu aplicativo de destino tiver de concluir a operação de compartilhamento, você pode usar o reportError para enviar uma mensagem de erro para o Windows. O usuário verá a mensagem quando conferir o status do compartilhamento no painel Compartilhar. Depois que você reportar o erro, o seu aplicativo será fechado e o compartilhamento, concluído. O usuário precisará iniciar novamente para compartilhar o conteúdo com o seu aplicativo.

No exemplo do compartilhamento de destino do Food with Friends, se o aplicativo não puder identificar um restaurante em seu banco de dados que corresponda ao restaurante que foi compartilhado a partir do aplicativo de origem pelo formato de dados Restaurant, ele deverá reportar um erro.

Vamos recapitular!

O compartilhamento entre aplicativos fornece uma ótima oportunidade de compartilhar aplicativos de destino. Habilitando o seu aplicativo para receber conteúdo compartilhado, os seus usuários aproveitarão o seu aplicativo mesmo quando estiverem envolvidos em outra atividade. Esperamos que agora você compreenda melhor os princípios de design, os tipos de dados, as classes e propriedades que você pode usar para criar um ótimo destino de compartilhamento. Estamos ansiosos para saber como os seus aplicativos transformarão o conteúdo compartilhado e criarão experiências mais amplas e sofisticadas para o usuário final.

Se desejar saber mais sobre o compartilhamento, leia Copiando e trocando dados e Share content target app sample (Exemplo de aplicativo de destino de compartilhamento de conteúdo) para começar!

Ishita Kapur

Gerente de programas

Experiência do usuário do Windows

A comunicação a curta distância (NFC, Near Field Communication) é uma tecnologia sem fio emergente de curto alcance. Com um alcance preciso de 2 cm, os usuários podem enviar/receber conteúdo tocando em dispositivos que estejam próximos um do outro para juntá-los. O toque permite que você selecione algo (ou alguém) rapidamente. Além de ser rápido, também é fácil de aprender. Basta ver para entender. Não é preciso ler um manual.

Por exemplo, imagine que você está vendo fotos com uma amiga e ela quer que você envie essas fotos para ela. Com a NFC, você só precisa tocar no seu dispositivo para enviá-las. Parece simples demais? Talvez, mas a ideia principal é simplificar o compartilhamento de conteúdo entre dispositivos.

Figura 1: Esta imagem mostra o Nokia 360 Speaker compartilhando as informações
de emparelhamento Bluetooth com um Windows Phone

Assim como o Bluetooth e o Wi-Fi, NFC é um protocolo sem fio padrão definido pela NFC Forum. Seu PC precisa de um rádio de NFC. Há muitos PCs com Windows 8 que têm rádios de NFC integrados diretamente a eles. Se a NFC não vier inclusa como parte do seu PC, você pode comprar dongles e conectá-los ao PC.

A NFC oferece funcionalidades bacanas. Os usuários podem tocar e enviar fotos, tocar em um menu para fazer um pedido em um restaurante, ou até mesmo tocar para emparelhar um dispositivo Bluetooth. Esses cenários são bastante diferentes entre si, mas o que eles têm em comum é o ¨toque¨ para iniciar a experiência. A NFC é usada em vários tipos de dispositivos, como PCs, telefones, alto-falantes, headsets, telas sem fio etc. para transformar a conexão entre dispositivos em uma experiência verdadeiramente intuitiva. Além disso, a NFC usa marcas de RFID; antenas leves, passivas e bastante econômicas que podem conter um volume considerável de dados e aderem a praticamente qualquer objeto, geralmente cartazes. Por exemplo, para comprar o ingresso de um filme bastaria tocar no cartaz do filme! Isso se chama marca de NFC. Apresentaremos um exemplo básico do toque em um marca de NFC para demonstrar os principais conceitos da API de NFC.

Mas, primeiro, vamos explicar melhor o que significa tocar para juntar dispositivos que estão próximos.

Definição de ¨toque¨

Assim como você toca para emparelhar um mouse Bluetooth ou para compartilhar fotos, também é importante tocar para juntar dispositivos que estejam próximos. Ainda que o conceito de toque já esteja bastante difundido, o toque para juntar um PC a outro dispositivo é uma novidade para a maioria das pessoas. Apresentamos algumas diretrizes do toque que mostram aos usuários:

1. Onde é possível tocar para juntar os dispositivos: com o uso da marca de toque, também conhecida como a marca visual de ¨Tocar e Fazer¨, que indica onde a antena de NFC está localizada. Dependendo do modelo do PC, há diferentes partes que podem ser tocadas. Por exemplo, você pode tocar na parte traseira de um tablet ou na parte frontal de um tudo-em-um. Esta é a aparência da marca em qualquer PC com Windows 8 habilitado para NFC:
   
   

   Figura 2: Marca visual de Tocar e Fazer

2. Os dispositivos estão se comunicando entre si: durante o toque, os usuários devem ter a certeza de que algo está acontecendo, mesmo que não possam ver os dados que estão sendo transferidos. Por isso, o Windows reproduz um som quando os dispositivos estão próximos e se comunicando entre si.

O Windows executa essas ações automaticamente, para que você não precise se preocupar com isso. Para obter mais informações sobre os elementos da experiência do usuário, consulte Especificações de implementação da proximidade de curta distância. Tendo isso em mente, vamos explorar alguns cenários bacanas que você pode experimentar com a NFC.

Quando usar a NFC

Use a NFC quando um usuário precisar selecionar algo ou alguém no seu aplicativo. A NFC oferece uma forma intuitiva de selecionar, e é geralmente mais rápida (e mais bacana!) que a busca manual. O toque é o gatilho que inicia a experiência e, dependendo do seu aplicativo, a experiência pode ir desde o recebimento de uma foto até a criação de uma lista de reprodução. A decisão do que acontece depois do toque só depende do seu aplicativo. Então, para simplificar, classificamos esta gama de ações como experiências de ¨Tocar e Fazer¨.

Apresentamos, abaixo, alguns exemplos do uso da NFC para selecionar algo em um aplicativo. Você poderia tocar e...

• Obter informações de um cartaz: As marcas de NFC são marcas de RFID leves e econômicas que custam entre US$ 0,15 e US$ 1,00 (o preço depende do custo de impressão). Elas podem ser comparadas a códigos de barras 2D, mas são mais fáceis e rápidas de usar. Tocar em uma marca é mais confortável do que tirar uma foto do código de barra (e esperar que a câmera pegue o ângulo certo). Há cada vez mais fabricantes inserindo marcas em cartazes em áreas movimentadas, como aeroportos, estações de metrô e paradas de ônibus. As marcas de NFC podem conter de 48 B a 4 KB de dados. Você pode programar uma marca para iniciar seu aplicativo em uma página específica.

• Trocar informações de contato: em vez de soletrar seus dados de contato para um amigo e esperar que ele tenha anotado certo, toque nos dispositivos para juntá-los e trocar as informações de contato. Assim como no caso acima, você pode programar suas informações em um cartão de visitas/marca de NFC ou transferir as informações diretamente por meio de um aplicativo.
• Reproduzir sua estação de rádio favorita: use uma marca de NFC para iniciar uma estação de rádio em casa onde você estiver; no trabalho, na academia ou no carro. Você pode até mesmo ter várias estações de rádio programadas em diferentes marcas, como, por exemplo: uma marca para a academia, outra para o trabalho e outra para a hora de dormir.
• Fazer seu pedido em um restaurante cheio: ir a um restaurante badalado na hora do jantar significa ter de esperar um bom tempo para simplesmente fazer um pedido. Em vez disso, toque em uma marca na mesa para fazer o seu pedido.
• Jogar um jogo multiplayer com um amigo: você pode se conectar facilmente a um jogo multiplayer como Battleship, Xadrez ou Scrabble com um amigo, tocando nos dispositivos para juntá-los. Após o toque, a conexão persiste por meio de um transporte fora de banda com alcance e taxa de transferência maiores, como Bluetooth ou Wi-Fi-Direct.

Agora que já temos uma boa noção sobre quando podemos usar a NFC, vamos para a parte divertida: desenvolver um aplicativo com nossas APIs de proximidade do Windows 8.

Como implementar a NFC

Como você pôde observar, a NFC facilita várias tarefas diárias para os usuários finais. Ajustar um alarme, por exemplo. Tenho certeza de que todo mundo já passou pela experiência de colocar a hora errada no alarme para despertar. Quando já está tarde e você só quer dormir, talvez não seja a melhor hora para fazer isso. A NFC facilita essa tarefa. Basta você tocar em uma marca predefinida, confirmar e ir dormir sem preocupações. Então, para ajudar os usuários nessa tarefa diária, suponha que você criou um aplicativo básico de alarme que permite aos usuários ajustar um alarme com o uso de uma marca de NFC. Essa suposição se divide em dois cenários.

1. Ajustar um alarme na marca: As marcas de NFC podem ser reutilizáveis, por isso o aplicativo deve permitir que os usuários programem um alarme. Por exemplo, um usuário pode querer programar diferentes alarmes: um para os dias úteis e outro para o fim de semana. Isso se chama publicar dados em uma marca.
2. Ajustar um alarme a partir da marca: Depois que o usuário tocar em uma marca, o aplicativo deve ser iniciado para confirmar o ajuste do alarme. Isso significa que o aplicativo pode ser iniciado com contexto ou argumentos.

A API de NFC oferece várias maneiras de cumprir o mesmo objetivo, mas abordarei a forma mais simples de implementar esse cenário.

Vamos ver, passo a passo, como ajustar um alarme em uma marca de NFC:

1. Mário inicia o aplicativo de alarme e define uma hora, digamos, 7:00. Isso é só o alarme, ainda sem nenhum envolvimento com a NFC.
2. Mário seleciona uma opção para ¨Ajustar alarme em marca de NFC¨. Nesse momento, o aplicativo chama as APIs de NFC para publicar informações no rádio NFC, especificamente uma cadeia de caracteres identificadora de aplicativo & 07:00. As marcas de NFC usam um formato de mensagem padronizado: o NDEF (formato de troca definido de NFC). Seu aplicativo não precisa se preocupar com a formatação de dados em uma mensagem de NDEF. O Windows faz isso para você! Agora, o usuário pode tocar na marca de NFC.
3. Mário toca na marca com o uso do PC, e o aplicativo confirma a programação da marca. Depois que a marca é tocada, é importante que os usuários saibam que seu aplicativo programou a marca com êxito. Como discutimos anteriormente, o toque no PC é um conceito novo para a maioria das pessoas, por esse motivo, a confirmação deixa o usuário confiante de que o que ele fez deu certo. O aplicativo sabe que uma mensagem foi transmitida com êxito registrando a informação em um manipulador de mensagens transmitidas.

As APIs de NFC podem ser encontradas no namespace Windows.Networking.Proximity. Elas desempenharão uma função na etapa 2, depois que o usuário selecionar a opção ¨Ajustar alarme em marca de NFC¨. Primeiro, o aplicativo inicializa um objeto de proximidade. O objeto de proximidade é usado para informar quando uma marca (ou dispositivo) está dentro/fora do alcance. Depois, adicionaremos um manipulador de eventos DeviceArrival. O manipulador detecta quando a marca é tocada, o que significa que podemos começar a escrever informações na marca. É útil informar aos usuários que eles estão escrevendo em uma marca, para que eles não saiam do alcance. Você pode usar o mesmo evento para detectar quando qualquer dispositivo de proximidade é tocado.

O trecho de código a seguir mostra como inicializar e adicionar um manipulador de eventos DeviceArrival.

JavaScript

var proximityDevice;

function initializeProximityDevice() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.getDefault();

    if (proximityDevice) {
        proximityDevice.addEventListener("devicearrived", proximityDeviceArrived);
       
}
   else {
        // No NFC radio on the PC, display an error message
    }


function proximityDeviceArrived(device) {
        // Let the user know we’re ‘Writing to Tag’

}
}

private void InitializeProximityDevice()
{

Windows.Networking.Proximity.ProximityDevice proximityDevice;
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

    if (proximityDevice != null) {
        proximityDevice.DeviceArrived += ProximityDeviceArrived;
    
    }
    else
    {
        // No NFC radio on the PC, display an error message
    }
}

private void ProximityDeviceArrived(Windows.Networking.Proximity.ProximityDevice device)
{
            // Let the user know we’re ‘Writing to Tag’

}

Em seguida, publicamos informações na marca. O aplicativo publica duas coisas: uma cadeia de caracteres identificadora de aplicativo, que consiste em uma ID e uma plataforma de aplicativos, e argumentos de inicialização. No Windows 8, a ID de aplicativo é <nome da família do pacote>!<ID de aplicativo>, e a plataforma de aplicativos é ¨Windows¨. Você deve copiar o valor da ID de aplicativo do atributo ID do elemento Application no manifesto do pacote do seu aplicativo. O argumento de inicialização é ¨07:00¨; o alarme definido pelo usuário. Chamaremos isso de a mensagem.

Se o aplicativo funcionar em várias plataformas, você poderá publicar IDs e plataformas de aplicativos alternativas, para que você possa tocar na mesma marca em outro dispositivo compatível com NFC, como o Windows Phone 8! Para obter mais informações sobre IDs alternativas, visite o MSDN.

O aplicativo publica os dados na marca usando um método chamado publishBinaryMessage. O método assume três parâmetros: messageType, mensagem e uma função messageTransmittedHandler. Definiremos messageType como ¨LaunchApp:WriteTag¨, que informa ao Windows que seu aplicativo quer escrever informações em uma marca de NFC. A mensagem é apenas a mensagem que definimos anteriormente (argumentos de inicialização e cadeia de caracteres identificadora de aplicativo). Precisaremos armazenar a mensagem como mensagem binária em um buffer. A função messageTransmittedHandler registra retornos de chamadas. Com isso, seu aplicativo sabe que a mensagem foi escrita com êxito na marca. Usaremos essa função para informar duas coisas ao usuário: escrevemos uma mensagem com êxito na marca e a marca não precisa mais estar dentro do alcance.

As mensagens continuam sendo publicadas até a função StopPublishingMessage ser chamada, ou quando o objeto ProximityDevice for liberado. Neste exemplo, usaremos a função de interrupção. PublishBinaryMessage retorna uma ID de publicação. Usaremos essa mesma ID de publicação para interromper a publicação da mensagem no rádio de NFC.

O trecho de código a seguir mostra como escrever dados em uma marca de NFC.

JavaScript

var proximityDevice;

function getAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;

}

function publishLaunchApp() {
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice) {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        var launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        var praid = "AlarmApp"; // The Application Id value from your package.appxmanifest.

        var appName = Windows.ApplicationModel.Package.current.id.familyName + "!" + praid;

        var launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.unicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.utf16LE;
        dataWriter.writeString(launchAppMessage);
        var launchAppPubId =
             proximityDevice.publishBinaryMessage(
                 "LaunchApp:WriteTag", 
                 dataWriter.detachBuffer(), 
                 proximityWriteTagLaunchAppMessageTransmitCallback);
        
    if (launchAppPubId != -1) {
            // Stop publishing the message on NFC radio
        proximityDevice.stopPublishingMessage(launchAppPubId);
    }

     }
}

function proximityWriteTagLaunchAppMessageTransmitCallback() {
    // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

Windows.Networking.Proximity.ProximityDevice proximityDevice;

private string GetAlarmTime(){

    // Grab time set by the user, call this variable ‘Alarm’
    return Alarm;
}

private void PublishLaunchApp()
{
    proximityDevice = Windows.Networking.Proximity.ProximityDevice.GetDefault();

if (proximityDevice != null)
    {
        // The format of the app launch string is: "<args>\tWindows\t<AppName>".
        // The string is tab or null delimited.

        // The <args> string can be an empty string ("").
        string launchArgs = getAlarmTime();

        // The format of the AppName is: PackageFamilyName!PRAID.
        string praid = "MyAppId"; // The Application Id value from your package.appxmanifest.

        string appName = Windows.ApplicationModel.Package.Current.Id.FamilyName + "!" + praid;

        string launchAppMessage = launchArgs + "\tWindows\t" + appName;

        var dataWriter = new Windows.Storage.Streams.DataWriter();
        dataWriter.UnicodeEncoding = Windows.Storage.Streams.UnicodeEncoding.Utf16LE;
        dataWriter.WriteString(launchAppMessage);
        var launchAppPubId =
        proximityDevice.PublishBinaryMessage(
            "LaunchApp:WriteTag", dataWriter.DetachBuffer(), 
            proximityWriteTagLaunchAppMessageTransmitCallback);
    
    if (launchAppPubId!= -1)
    {
        proximityDevice.StopPublishingMessage(launchAppPubId);
    // Stop publishing the message on NFC radio
    }

    }
}

private void proximityWriteTagLaunchAppMessageTransmitCallback(
    Windows.Networking.Proximity.ProximityDevice sender,
    long messageId)
{
        // Inform the user that: the message has been successfully written to a tag & the tag no longer needs to be in range
}

1. Mário está lendo um livro digital/escrevendo um email/jogando/usando o Windows e se lembra que precisa ajustar o alarme para segunda-feira de manhã. Ele pega sua marca de ¨Alarme de fim de semana¨e toca nela pelo PC. Ele recebe uma notificação do sistema convidando-o a iniciar seu aplicativo de alarme. O Windows cuida de tudo até esse ponto. Seu aplicativo não precisa fazer nada.
2. Mário aceita, e seu aplicativo é inicializado, exibindo a tela ¨Confirmar alarme¨ e o horário 7:00. Depois que o Mário aceita a notificação do sistema, o Windows envia os argumentos de inicialização (iguais aos de cima) ao seu aplicativo durante a ativação. Isso se chama inicialização contextual, e é o mesmo que inicializar o aplicativo em uma página específica.
3. Mário define o alarme. Isso é só o alarme, sem a NFC.

É bem fácil obter os argumentos de inicialização da marca de NFC. O aplicativo precisa manipular inicialização contextual de uma marca de NFC. A inicialização contextual é o mesmo que inicializar seu aplicativo em uma página específica. Nossos argumentos de inicialização especificam um alarme (7:00), que seu aplicativo usa para exibir um alarme proposto. Além disso, se o seu aplicativo não estiver instalado no PC, o Windows convidará o Mário a instalar o aplicativo a partir da Windows Store, automaticamente!

O trecho de código a seguir mostra como implementar a inicialização contextual.

JavaScript

app.onactivated = function (args) {
    if (args.detail.kind === activation.ActivationKind.launch) {
        if (args.detail.arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket") {
            //do nothing here.
        }
        else {
    // Use args.detail.arguments to parse out ’07.00’ string, and display to the user
        }

        args.setPromise(WinJS.UI.processAll());
    }
}

async protected override void OnLaunched(LaunchActivatedEventArgs args)
        {
            if (args.Arguments == "Windows.Networking.Proximity.PeerFinder:StreamSocket")
            {
                _isLaunchedByTap = true;
            }
            else
            {
// Use args.Arguments to parse out ’07.00’ string, and display to the user

            }
            Window.Current.Activate();
        }

Isso é tudo que seu aplicativo precisa fazer para dar suporte à leitura e gravação em uma marca de NFC. Bem simples para um cenário de tecnologia tão avançada! Antes de terminar, vamos falar sobre uma questão de higiene: o tratamento de erros.

Tratamento de erros

Há alguns erros comuns que seu aplicativo pode encontrar.

• A marca tocada não tem o formato NDEF. O Windows 8 não oferece suporte automático à reformatação de uma marca em NDEF, por isso você precisa baixar e instalar um formatador de NDEF.
• A marca tocada é somente para leitura. Algumas marcas de NFC podem estar bloqueadas com permissão somente de leitura (como as antigas fitas de VHS).
• A marca tocada é pequena demais e não comporta todos os dados.
• O PC de um usuário não tem NFC. Como mencionei desde o início, a NFC é uma tecnologia emergente cuja adoção ainda está sendo difundida. Para verificar se um PC oferece suporte à proximidade, use o método ProximityDevice.getDefault(); o método retornará NULL se não houver rádios NFC instalados.

É divertida e intuitiva!

A NFC finalmente chegou, pronta para os consumidores padrão, e o Windows tem o ecossistema e uma experiência de usuário completa e bem projetada. A tecnologia tem muito potencial para desenvolver aplicativos e experiências em dispositivos altamente intuitivos. É divertida e intuitiva.

A NFC é um assunto bastante vasto, por isso fique atento nas próximas postagens no blog sobre outras experiências bacanas para desenvolvedores de NFC no Windows 8.

Para saber mais sobre NFC e proximidade, consulte os recursos abaixo.

Recursos

Obrigada,

Priya Dandawate
gerente de programas, dispositivos e rede

Com as contribuições de: Max Morris, Marzena Makuta, Mike Loholt, Jake Sabulsky e Vishal Mhatre

As pessoas estão sempre cercadas por dispositivos conectados a uma rede. Até mesmo as geladeiras e máquinas de lavar mais modernas podem se conectar à Internet e a redes domésticas. Por isso, é claro que os usuários finais esperam que seus aplicativos também estejam conectados. Esses ¨aplicativos conectados¨ consomem o conteúdo mais recente da Web: mídias sociais, mídias digitais, blogs e outros tipos de conteúdo. O desenvolvimento de aplicativos conectados tornou-se a norma, ainda assim pode ser desafiador lidar com problemas comuns, como a perda da conexão à rede, os custos de redes limitadas ou problemas de desempenho. Mais do que nunca, o Windows 8 facilita a escrita de um aplicativo conectado.

Nesta postagem, apresentaremos algumas dicas úteis para você proporcionar uma experiência de conexão rápida, fluida e descomplicada aos usuários dos seus aplicativos da Windows Store.

• Escolha a API certa para os seus cenários
• Escolha as funcionalidades de rede certas
• Adapte o comportamento do aplicativo para redes limitadas
• Reaja à alteração de status da rede
• Conteúdo de cache para fluidez

Agora, vamos falar mais sobre os detalhes de cada dica.

Escolha a API certa

Para construir uma casa, você vai querer usar as ferramentas certas. Um martelo para martelar pregos, uma serra para cortar tábuas e uma chave de fenda para apertar os parafusos. Da mesma forma, você buscará as APIs de rede certas para desenvolver um aplicativo conectado da Windows Store. O Windows 8 oferece uma grande variedade de APIs de rede que seu aplicativo pode usar para se comunicar com outros computadores e dispositivos pela Internet ou em redes privadas. Por isso, o primeiro passo é determinar os recursos de rede de que seu aplicativo precisa.

O cenário de rede mais comum é o acesso a um site para obter ou armazenar informações. Um exemplo simples seria um jogo que usa um site para armazenar informações e pontuações dos usuários. Um exemplo mais complexo seria um aplicativo que se conecta a um serviço Web baseado em REST e usa uma biblioteca fornecida pelo serviço Web para acessar ou armazenar informações. O Windows 8 conta com várias APIs que se conectam a sites e serviços Web. Com essas APIs, seu aplicativo pode acessar serviços Web que dão suporte a REST ou enviar comandos básicos de protocolo HTTP (como GET e POST) a um servidor Web. Para o acesso à Web, a API certa depende da linguagem que você usa para desenvolver o aplicativo:

• XMLHTTPRequest e WinJS.xhr: aplicativos escritos em JavaScript e HTML.
• HttpClient: aplicativos escritos em C# ou Visual Basic .NET e XAML.
• XML HTTP Request 2 (IXHR2): aplicativos escritos em C++ e XAML.

O código a seguir mostra como executar uma solicitação/resposta básica com um serviço Web baseado em REST. Neste caso, o serviço Web poderia executar um script ASP.NET no servidor Web.

JavaScript

function makeXHRCall() {
    WinJS.xhr({ uri: "http://www.microsoft.com/en-us/default.aspx” }).done(
        function onComplete(result) {
            print(result.responseText);
        },
        function onError(err) {
            print("Error: " + err.responseText);
        });
}

C#

private async void MakeHttpCall()
{
    HttpClient httpClient = new HttpClient();
    try {
        string response = await httpClient.GetStringAsync("http://www.microsoft.com/en-us/default.aspx");
    }
    catch (Exception) {
        // Handle exception.
    }
}

Para obter mais informações sobre WinJS.xhr, consulte Conectando serviços Web (aplicativos da Windows Store em JavaScript e HTML). Para obter mais informações sobre HttpClient, consulte Início rápido: Conectando com o uso de HttpClient (aplicativos da Windows Store em C#/VB/C++ e XAML) e a amostra de HttpClient.

Outro cenário de rede comum é baixar e carregar arquivos em transferências que podem levar algum tempo. Um exemplo seria um aplicativo de câmera ou galeria de fotos que precisa carregar ou baixar fotos ou álbuns de fotos de um serviço Web. Essas transferências podem levar muito tempo, por isso não faz sentido obrigar o usuário a esperar até que a transferência termine. A API Windows.Networking.BackgroundTransfer oferece a capacidade de baixar ou carregar arquivos mesmo quando seu aplicativo não está mais em execução. O aplicativo começa a transferência quando está em execução em primeiro plano, com foco, e o Windows 8 continua a transferência em segundo plano, mesmo se o aplicativo não estiver mais em execução.

Outro cenário mais especializado é o acesso a conteúdo sindicalizado. A API Windows.Web.Syndication pode obter feeds nos formatos RSS ou Atom. Além disso, a API Windows.Web.AtomPub permite que um aplicativo publique dados em vários formatos AtomPub.

Em cenários para os quais não há um protocolo de rede de nível superior específico disponível por meio de uma API, o Tempo de Execução do Windows também oferece suporte para soquetes TCP e UDP (juntamente com multicast). A API Windows.Networking.Sockets oferece uma StreamSocket (TCP) e a DatagramSocket (UDP) para que você possa implementar outros protocolos de camada superior.

Observação: O Windows 8 apresenta um novo tipo de soquete chamada WebSocket. Para obter mais informações sobre WebSockets e quando usá-las, consulte Conectando-se com WebSockets.

A tabela a seguir apresenta uma lista mais completa de recursos de rede suportados, com links para informações adicionais.

Escolha as funcionalidades de rede certas

O isolamento da rede é parte do modelo de segurança de aplicativos usado pelo Windows 8. O Windows detecta limites de rede ativamente e aplica restrições de acesso à rede para o isolamento da mesma. Quando implantadas adequadamente, essas funcionalidades ajudam a proteger seus usuários e aplicativos de ataques mal-intencionados.

Os aplicativos devem declarar funcionalidades de isolamento de rede para definir o escopo do acesso à rede. Sem declarar essas funcionalidades, seu aplicativo não terá acesso aos recursos da rede. Consulte Como definir as funcionalidades de rede para saber mais sobre como o Windows aplica o isolamento da rede para aplicativos.

Você não pode usar a rede como um mecanismo de comunicação interprocessual entre um aplicativo da Windows Store e um aplicativo de desktop no mesmo dispositivo. Por esse motivo, não é possível usar endereços de loopback IP em um aplicativo da Windows Store. Há exceções limitadas para fins de desenvolvimento que permitem o uso de endereços de loopback IP em operações no depurador do Visual Studio. Para obter mais informações, consulte Como habilitar loopback e solucionar o isolamento de rede.

As solicitações de acesso à rede se dividem em duas categorias:

1. Solicitações de saída iniciadas pelo cliente: Seu aplicativo age como o cliente e inicia o acesso à rede enviando uma solicitação de rede inicial a um computador remoto, normalmente um servidor. O aplicativo envia uma ou mais solicitações ao servidor, e o servidor envia de volta uma ou várias respostas. Por exemplo, todo tráfego de um aplicativo de cliente Web a um servidor Web se inclui nessa categoria.
2. Solicitações de entrada não solicitadas: Seu aplicativo age como um servidor de rede e escuta solicitações de rede de entrada de um computador remoto. O computador remoto inicia o acesso à rede enviando uma solicitação inicial ao seu aplicativo, que age como um servidor. O computador remoto envia uma ou mais solicitações ao seu aplicativo, que envia de volta uma ou várias respostas ao computador remoto. Por exemplo, um aplicativo que funciona como um servidor de mídia se inclui nessa categoria.

Siga o princípio do mínimo de privilégios e adicione apenas as funcionalidades de que seu aplicativo precisa. Talvez seu aplicativo precise apenas de solicitações de saída iniciadas pelo cliente ou também precise de solicitações de entrada não solicitadas. Alguns aplicativos podem precisar também de acesso a certificados e credenciais de usuário no processo de autenticação em uma rede.

A tabela a seguir mostra detalhes das funcionalidades de isolamento de rede e outros recursos relacionados que costumam ser necessários para aplicativos conectados. As três primeiras são funcionalidades primárias de isolamento de rede que os aplicativos conectados usam. Na verdade, seu aplicativo conectado deve ter pelo menos uma destas três primeiras funcionalidades. Os outros itens na tabela são funcionalidades adicionais que muitas vezes são necessárias por alguns aplicativos conectados.

Use esta lista de verificação para garantir que o isolamento de rede está configurado no seu aplicativo:

• Determine a direção do acesso à rede de que o seu aplicativo precisa, as solicitações de saída iniciadas por clientes, solicitações de entrada não solicitadas, ou ambos.
• Determine o tipo de recursos de rede com os quais o seu aplicativo se comunicará: recursos confiáveis em uma rede doméstica ou corporativa, recursos na Internet ou ambos.
• Configure a capacidade de isolamento mínima necessária da rede no manifesto do aplicativo. Você pode fazer isso usando o Designer de Manifesto de Aplicativo no Microsoft Visual Studio 2012, ou adicione-os manualmente.
• Implante e execute o seu aplicativo para testá-lo usando as ferramentas de isolamento da rede para solucionar problemas. Para obter mais informações, consulte Como habilitar loopback e solucionar o isolamento de rede.

A captura de tela seguinte mostra como habilitar as funcionalidades da rede, usando o Designer de Manifesto de Aplicativo no Microsoft Visual Studio 2012.

Selecione funcionalidades de rede no package.appxmanifest do seu aplicativo no Visual Studio 2012

Adapte o comportamento do aplicativo para redes limitadas

Pense sobre a última vez em que você estava chegando ao seu limite mensal de dados ou, talvez, na última vez em que você viajou para o exterior. Nestas situações, eu normalmente acabava usando o meu dispositivo e os meus aplicativos com cautela para evitar tarifas de rede desnecessárias.

O Windows 8 trata desse problema do usuário permitindo que os aplicativos monitorem os recursos disponíveis da rede e se comportem adequadamente quando estiverem em redes limitadas. Para promover a confiança dos usuários em seu aplicativo, você pode torná-lo capaz de identificar quando uma conexão pode incorrer em custos e adaptar o comportamento do aplicativo para evitar ou reduzir essas tarifas.

A API Windows.Networking.Connectivity fornece informações sobre o tipo e o custo de uma conexão de rede. Isto permite que o seu aplicativo determine quando usar os recursos da rede normalmente, quando usá-los de maneira conservadora ou quando solicitar a permissão do usuário.

Uma ConnectionProfile representa uma conexão de rede. O seu aplicativo pode usar a ConnectionCost de uma ConnectionProfile para determinar se deve ou não adaptar o seu comportamento. A propriedade NetworkCostType indica o tipo de conexão de uma rede. Existem quatro valores possíveis:

• Irrestrita: o uso desta conexão de rede é ilimitado. Ela não tem tarifas de uso ou restrições na capacidade.
• Fixa: o uso desta conexão de rede é irrestrito até um limite específico.
• Variável: o uso desta conexão de rede é limitado por uso de bytes.
• Desconhecida: a informação de custo não está disponível para esta conexão de rede.

Diversas outras propriedades boolianas para a ConnectionCost oferecem ainda mais informações.

• Roaming: a conexão é com uma rede fora do provedor doméstico.
• ApproachingDataLimit: a conexão está chegando ao limite de uso especificado pelo plano de dados.
• OverDataLimit: a conexão excedeu o limite de uso especificado no plano de dados.

Faça o seu aplicativo responder às condições indicadas por essas propriedades. Sempre que uma conexão estiver Roaming, os custos de dados associados ao uso da rede podem ser elevados. Quando a NetworkCostType for Variável, a rede é uma rede limitada, onde o usuário paga pelo volume de dados enviados ou recebidos na rede. Quando a NetworkCostType for Fixa, existe causa para preocupação caso o usuário já esteja acima ou chegando próximo ao limite de dados.

Utilizando estas informações, um aplicativo pode seguir essas diretrizes para decidir como melhor utilizar os recursos da rede.

Este código de exemplo verifica o custo da conexão e faz sugestões para o comportamento adequado do aplicativo.

JavaScript

var CostGuidance = { Normal: 0, Conservative: 1, OptIn: 2 };
// GetCostGuidance returns an object with a Cost (with value of CostGuidance), 
// CostName (a string) and Reason, which says why the cost is what it is.
function GetCostGuidance() 
{
    var connectionCost = Windows.Networking.Connectivity.NetworkInformation.getInternetConnectionProfile().getConnectionCost();
    var networkCostConstants = Windows.Networking.Connectivity.NetworkCostType;
    var Retval = new Object();
    if (connectionCost.roaming || connectionCost.overDataLimit)
    {
        Retval.Cost = CostGuidance.OptIn;
        Retval.CostName = "OptIn";
        Retval.Reason = connectionCost.roaming
            ? "Connection is roaming; using the connection may result in additional charge."
            : "Connection has exceeded the usage cap limit.";
    }
    else if (connectionCost.networkCostType == networkCostConstants.fixed
        || connectionCost.networkCostType == networkCostConstants.variable)
    {
        Retval.Cost = CostGuidance.conservative;
        Retval.CostName = "Conservative";
        Retval.Reason = connectionCost.networkCostType == NetworkCostType.fixed
            ? "Connection has limited allowed usage."
            : "Connection is charged based on usage. ";
    }
    else
    {
        Retval.Cost = CostGuidance.Normal;
        Retval.CostName = "Normal";
        Retval.Reason = connectionCost.networkCostType == networkCostConstants.unknown
            ? "Connection is unknown."
            : "Connection cost is unrestricted.";
    }

    return Retval;
}

C#

public enum NetworkCost { Normal, Conservative, OptIn };
public class CostGuidance
{
    public CostGuidance()
    {
        var connectionCost = NetworkInformation.GetInternetConnectionProfile().GetConnectionCost();
        Init(connectionCost);
    }
    public NetworkCost Cost { get; private set; }
    public String Reason { get; private set; }


    public void Init(ConnectionCost connectionCost)
    {
        if (connectionCost == null) return;
        if (connectionCost.Roaming || connectionCost.OverDataLimit)
        {
            Cost = NetworkCost.OptIn;
            Reason = connectionCost.Roaming
                ? "Connection is roaming; using the connection may result in additional charge."
                : "Connection has exceeded the usage cap limit.";
        }
        else if (connectionCost.NetworkCostType == NetworkCostType.Fixed
            || connectionCost.NetworkCostType == NetworkCostType.Variable)
        {
            Cost = NetworkCost.Conservative;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Fixed
                ? "Connection has limited allowed usage."
                : "Connection is charged based on usage. ";
        }
        else
        {
            Cost = NetworkCost.Normal;
            Reason = connectionCost.NetworkCostType == NetworkCostType.Unknown
                ? "Connection is unknown."
                : "Connection cost is unrestricted.";
        }
    }
}

Use a amostra de informação da rede para saber mais sobre como adaptar o comportamento de aplicativos para redes limitadas.

Os usuários também podem executar o Gerenciador de Tarefas para verificar o volume de dados de rede que cada aplicativo está consumindo. Esta captura de tela mostra um exemplo.

A guia Histórico de Aplicativos no Gerenciador de Tarefas permite que os usuários vejam o consumo de CPU e rede por aplicativo

Reaja à alteração de status da rede

Em qualquer situação com um dispositivo móvel, as redes podem se conectar ou desconectar. Uma rede de banda larga móvel 3G ou 4G pode ficar fora do alcance na casa ou na garagem de um usuário enquanto o Wi-Fi ainda está disponível. Da mesma forma, um Wi-Fi pode ficar fora do alcance quando um usuário deixa a sua casa. Pode haver situações onde nenhuma rede esteja disponível. Dada a proliferação de redes Wi-Fi e de redes de banda larga móveis, tais alterações na rede ocorrem com frequência.

Um evento NetworkStatusChanged indica que o custo disponível ou as opções de conectividade podem ter sido alterados. Para reagir a alterações no status da rede e fornecer ao usuário uma ótima experiência quando as alterações ocorrerem, faça com que os seus aplicativos conectados sigam as seguintes diretrizes.

Perda da conexão devido a erro

Na maioria dos casos, as conexões podem ser restabelecidas simplesmente repetindo a operação de rede. Se isto falhar, espere por um evento NetworkStatusChanged. Recomendamos que os aplicativos usem intervalos crescentes de retirada entre as tentativas, começando com um valor de 50 milissegundos e aumentando este intervalo exponencialmente caso as conexões continuem a falhar.

Perda da rede

Informe o usuário que a conexão foi perdida, faça o registro e espere por um evento NetworkStatusChanged.

Nova disponibilidade de rede

Pode haver situações em que o dispositivo está conectado a múltiplas redes. Por exemplo, um usuário pode estar conectado a uma banda larga móvel, conversando com amigos por meio do aplicativo Windows 8 Messaging antes de chegar em casa e pode estar conectado a uma rede irrestrita ali também. A política padrão no Windows 8 é preferir uma rede irrestrita em vez de uma rede limitada e uma rede mais rápida em vez de uma mais lenta. Entretanto, conexões já estabelecidas por um aplicativo não alternam automaticamente para uma nova rede. Nesse caso, o aplicativo deve agir pois apenas o aplicativo pode tomar a melhor decisão sobre se deve ou não alternar para a nova rede.

Por exemplo, se a transmissão de um vídeo estiver quase concluída, pode não fazer sentido alternar a conexão para uma nova rede. Entretanto, se a rede atual estiver caindo, lenta demais ou se a transmissão for levar mais tempo para concluir, a alternância para uma nova rede pode ser o melhor.

Se você determinar que a alternância de rede é plausível para a situação do seu aplicativo, siga estas diretrizes quando detectar uma nova rede:

1. Verifique os custos da rede já existentes e da nova rede. Se fizer sentido alternar para a nova rede, tente fazer uma nova conexão de rede e tente a operação de rede novamente baseando-se nas diretrizes que acabamos de mencionar. O Windows automaticamente selecionará a rede irrestrita em vez da rede limitada e a rede mais rápida em vez da mais lenta.
2. Se a nova conexão de rede for bem sucedida, use a nova conexão à rede no seu aplicativo e cancele a operação de rede original na rede anterior, caso a conexão já exista.

Alteração no custo da rede

Alterações no custo da rede podem ocorrer quando a NetworkCostType é Fixa e o uso já estiver acima ou chegando próximo ao limite de dados. Alterações no custo da rede também podem ocorrer se a NetworkCostType se tornar Variável, ou se o Roaming mudar para verdadeiro. Nesses casos, adapte o comportamento do aplicativo baseando-se nas diretrizes da dica anterior.

Os códigos de exemplos usam o evento NetworkStatusChanged para fornecer uma ótima experiência de aplicativo para várias alterações de status em redes. Ambos os exemplos usam uma variável booliana global denominada registeredNetworkStatusNotification, inicialmente definida como falso.

JavaScript

// Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
function registerForNetworkStatusChange() {
    try {

        // Register for network status change notifications.
        if (!registeredNetworkStatusNotification) {
            var networkInfo.addEventListener("networkstatuschanged", onNetworkStatusChange);
            registeredNetworkStatusNotification = true;
        }
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

// Event handler for NetworkStatusChanged event
function onNetworkStatusChange(sender) {
    try {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet.
        var internetProfile = networkInfo.getInternetConnectionProfile();
        if (internetProfile === null) {
            print("Not connected to Internet\n\r");
        }
        else {
            internetProfileInfo += getConnectionProfileInfo(internetProfile) + "\n\r";
            print(internetProfileInfo);
        }
        internetProfileInfo = "";
    }
    catch (e) {
        print("An unexpected exception occurred: " + e.name + ": " + e.message);
    }
}

C#

// Register for NetworkStatusChanged notifications, and display new 
// Internet ConnectionProfile info upon network status change.
void NetworkStatusChange()
{
    // Register for network status change notifications.
    try
    {
        var networkStatusCallback = new NetworkStatusChangedEventHandler(OnNetworkStatusChange);
        if (!registeredNetworkStatusNotification)
        {
            NetworkInformation.NetworkStatusChanged += networkStatusCallback;
            registeredNetworkStatusNotification = true;
        }
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

// Event handler for NetworkStatusChanged event
async void OnNetworkStatusChange(object sender)
{
    try
    {
        // Get the ConnectionProfile that is currently used to connect 
        // to the Internet                
        ConnectionProfile InternetConnectionProfile = NetworkInformation.GetInternetConnectionProfile();

        if (InternetConnectionProfile == null)
        {
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser("Not connected to Internet\n", NotifyType.StatusMessage);
            });
        }
        else
        {
            connectionProfileInfo = GetConnectionProfile(InternetConnectionProfile);
            await _cd.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                rootPage.NotifyUser(connectionProfileInfo, NotifyType.StatusMessage);
            });
        }
        internetProfileInfo = "";
    }
    catch (Exception ex)
    {
        rootPage.NotifyUser("Unexpected exception occurred: " + ex.ToString(), NotifyType.ErrorMessage);
    }
}

Para mais informações sobre o evento NetworkStatusChanged , consulte o Guia de início rápido: Gerenciando eventos de conexão e mudanças na disponibilidade e a Network information sample (Amostra de informações da rede).

Conteúdo de cache para fluidez

Passando conteúdo de cache para o disco dá ao seu aplicativo rapidez e fluidez. Por exemplo, um aplicativo leitor de RSS feed pode exibir imediatamente os feeds que foram colocados em cache no disco em uma sessão anterior. Assim que os feeds mais recentes estiverem disponíveis, o aplicativo atualiza o conteúdo. O cache assegura que o usuário tenha conteúdo para ler logo no início, enquanto o aplicativo obtém um novo conteúdo.

O Windows 8 oferece a classe ApplicationData no namespace Windows.Storage. Esta classe oferece acesso ao repositório de dados do aplicativo. Este repositório de dados consiste de arquivos e configurações que são locais ao dispositivo, que são transferidos por múltiplos dispositivos ou que são temporários.

Arquivos são ideais para armazenar grandes conjuntos de dados, bancos de dados ou dados que estejam em um formato de arquivo comum. Arquivos podem existir em pastas roaming, locais ou temporárias. O que isso significa é o seguinte:

• Arquivos Roaming são sincronizados em múltiplas máquinas e dispositivos nos quais os usuários entraram com contas conectadas. O Roaming de arquivos não é instantâneo; o sistema avalia vários fatores para determinar quando enviar informações. Mantenha o uso de dados de roaming abaixo da cota (disponível por meio da propriedade RoamingStorageQuota ). Se a cota for excedida, o roaming de dados será suspenso. Arquivos não podem ser transferidos enquanto um aplicativo os estiver gravando. Portanto, certifique-se de fechar os objetos de arquivos do seu aplicativo quando eles não forem mais necessários.
• Arquivos locais não são sincronizados em múltiplas máquinas. Eles permanecem na máquina onde foram originalmente gravados.
• Arquivos temporários estão sujeitos a serem excluídos quando não estiverem em uso. O sistema considera fatores como capacidade disponível do disco e idade de um arquivo, para determinar quando ou se deve excluir um arquivo temporário.

Estes códigos de exemplo fazem o cache de conteúdo no disco. Fazer o cache da resposta do servidor permite que o seu aplicativo exiba imediatamente o conteúdo ao usuário após um término ou um reinício de sessão. Por uma questão de concisão, estes exemplos não mostram como gravar configurações para o repositório de dados de aplicativo ou como reagir a eventos de roaming. A Application data sample (Amostra de dados do aplicativo) cobre estes detalhes.

JavaScript

var roamingFolder = Windows.Storage.ApplicationData.current.roamingFolder;
var filename = "serverResponse.txt";

function cacheResponse(strResponse) {
    roamingFolder.createFileAsync(filename, Windows.Storage.CreationCollisionOption.replaceExisting)
        .done(function (file) {
            return Windows.Storage.FileIO.writeTextAsync(file, strResponse);
        });
}

function getCachedResponse() {
    roamingFolder.getFileAsync(filename)
        .then(function (file) {
            return Windows.Storage.FileIO.readTextAsync(file);
        }).done(function (response) {
            print(response);
        }, function () {
            // getFileAsync or readTextAsync failed. 
            // No cached response.
        });
}

C#

MainPage rootPage = MainPage.Current;
StorageFolder roamingFolder = null;
const string filename = "serverResponse.txt";

async void cacheResponse(string strResponse)
{
    StorageFile file = await roamingFolder.CreateFileAsync(filename, CreationCollisionOption.ReplaceExisting);
    await FileIO.WriteTextAsync(file, strResponse);
}

async void getCachedResponse()
{
    try
    {
        StorageFile file = await roamingFolder.GetFileAsync(filename);
        string response = await FileIO.ReadTextAsync(file);
    }
    catch (Exception)
    {
        // getFileAsync or readTextAsync failed.
        // No cached response.
    }
}

Para obter mais informações sobre o repositório de dados de aplicativo, consulte a postagem Transferindo os dados de seu aplicativo e experimente a Application data sample (Amostra de dados do aplicativo).

Resumindo

Quando estiver planejando os seus aplicativos da Windows Store, use as diretrizes nesta postagem para fornecer uma experiência de conexão excelente e sem problemas. Estas dicas podem facilitar o seu processo de desenvolvimento e ao mesmo tempo manter a fluidez e aumentar a confiança dos usuários nos seus aplicativos.

- Suhail Khalid, gerente de programa II, Windows

Com a contribuição de: Steven Baker e Peter Smith

Na última semana, Steve Guggenheimer anunciou a //build/ 2013. A conferência acontecerá entre os dias 26 e 28 de junho de 2013, no Moscone Center, em São Francisco. A //build/ é uma ótima oportunidade para você aprender mais sobre como desenvolver aplicativos da Windows Store. Na conferência você assistirá a excelentes apresentações, demonstrações, sessões de informações e muito mais. Muitos membros da nossa equipe de engenharia estão viajando para São Francisco para apresentar essas demonstrações e responder às suas perguntas. Se você quiser ficar por dentro das últimas (e melhores) informações sobre o desenvolvimento de aplicativo da Windows Store, não existe lugar melhor.

As inscrições começaram na terça-feira, 2 de abril. Você pode ver todos os detalhes sobre a conferência e se registrar em www.buildwindows.com.

Encontramos você lá!