JavaScript로 Windows 스토어 앱을 개발할 경우 비동기 API와 관련된 작업을 할 때 'promise'라는 구조를 자주 사용하게 됩니다. 또한 얼마 지나지 않아 순차적인 비동기 작업에도 기본적으로 promise 체인을 사용하게 될 것입니다.

하지만 개발 작업 과정에서 진행 상황을 확실하게 파악할 수 없는 경우 promise를 다른 방법으로 사용하게 됩니다. 이에 대한 좋은 예는 HTML ListView 성능 최적화 샘플에 나오는 ListView 컨트롤의 항목 렌더링 기능 최적화입니다. 전편에 이어 이번 글에서도 이 내용을 살펴보겠습니다. Josh Williams가 //build 2012의 Deep Dive into WinJS 세션에서 언급한 코드를 살펴보는 것도 좋습니다. 내용은 약간 수정되었습니다.

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);
    });
})

이 코드에서는 병렬 비동기 작업에 promise를 사용하여 'list'의 순서에 따라 연속적으로 결과를 제공합니다. 이 코드를 보고 그 동작을 즉시 이해할 수 있는 분들은 이 글을 읽지 않아도 됩니다! 그렇지 않은 분들은 promise의 작동 방식과 WinJS(JavaScript용 Windows 라이브러리)에서 사용되는 식을 자세히 살펴보고 패턴을 이해하시기 바랍니다.

promise란 정확하게 무엇일까요? promise 관계

가장 기본적인 내용부터 살펴보겠습니다. promise는 코드 구조 또는 호출 규칙일 뿐입니다. 그렇기 때문에 promise는 기본적으로 비동기 작업과 관계가 없고 그래서 매우 '유용'합니다! promise는 나중에 사용할 수 있게 되거나 이미 사용 가능한 값을 나타내는 개체일 뿐입니다. 이러한 맥락에서 인간 관계를 나타내는 용어인 promise를 사용하게 되었습니다. 제가 만약 “도너츠 12개를 보내 드리겠다고 약속합니다”라고 말한다면 지금 당장은 도너츠가 없지만 나중에 언젠가는 확실하게 도너츠가 생긴다는 의미입니다. 그리고 도너츠가 생겼을 때 보내면 됩니다.

이러한 맥락에서 promise는 두 에이전트 간의 관계를 의미합니다. 한 에이전트는 어떤 물건을 공급하기로 약속하는 '주관자'이고 다른 에이전트는 약속과 물건을 받는 '소비자'입니다. 주관자가 해당 물건을 취득하는 방법은 전적으로 주관자의 재량에 달렸습니다. 마찬가지로 소비자는 약속 그 자체와 받은 물건을 원하는 대로 사용할 수 있습니다. 심지어 약속을 다른 소비자와 공유할 수도 있습니다.

또한 주관자와 소비자 사이에는 '생성'과 '처리'라는 두 가지 단계가 있습니다. 이 모든 관계가 다음 다이어그램에 정리되어 있습니다.

다이어그램의 흐름을 관찰해 보면 promise가 비동기 작업과 잘 맞는 이유가 두 단계로 구성된 관계 때문이라는 사실을 알 수 있습니다. 요청이 접수(promise)된 것을 확인한 소비자가 계속 기다리지(동기식) 않고 다른 일을 할 수 있다는(비동기식) 것이 가장 중요합니다. 즉, 소비자는 약속이 처리되기를 기다리면서 다른 요청에 응답하는 등의 다른 일을 할 수 있습니다. 이것이 바로 비동기 API의 가장 중요한 목적입니다. 그렇다면 물건이 이미 제공되는 경우에는 어떨까요? 약속이 즉시 처리되어 모든 것이 동기 호출 규칙이 됩니다.

물론 이 관계에도 몇 가지 고려해야 할 사항이 있습니다. 누구나 살면서 약속을 하고 또 약속을 받기도 합니다. 약속이 지켜지는 경우도 많지만 그렇지 못한 경우도 실제로 많습니다. 예를 들어 피자 배달 직원이 배달 도중에 사고를 당할 수 있습니다! 약속 불이행은 어쩔 수 없는 현실입니다. 개인 일상에서나 비동기 프로그래밍에서나 이를 받아들여야 합니다.

promise 관계 내에서 이를 살펴보자면, 주관자는 "죄송하지만 이 약속을 지킬 수 없게 되었습니다"라고 말할 수 있는 방법이 필요하고 소비자는 이를 확인할 수 있는 방법이 필요합니다. 두 번째로, 소비자는 주관자의 약속 이행에 대해 인내심이 그리 많지 않습니다. 만약 주관자가 약속 이행 진행 상황을 추적할 수 있다면 소비자가 그 정보를 받아 볼 수 있는 방법이 필요합니다. 세 번째로, 소비자가 주문을 취소하고 주관자에게 더 이상 그 물건이 필요 없다고 말하는 경우가 있습니다.

이러한 요구 사항을 다이어그램에 추가하면 완전한 관계가 완성됩니다.

이러한 관계가 코드에서 어떻게 나타나는지 살펴보겠습니다.

promise 구조 및 promise 체인

실제로 promise에 대한 다양한 제안 또는 사양이 있습니다. Windows 및 WinJS에 사용된 것은 Common JS/Promises A이며, promise(나중에 제공할 가치를 나타내기 위해 주관자가 반환하는 것)를 then이라는 함수를 갖는 개체로 정의합니다. 소비자는 then을 호출하여 promise의 처리를 신청합니다. Windows의 promise도 promise 체인에 사용되는 done이라는 비슷한 함수를 지원하는데, 이 부분에 대해서는 잠시 후에 다루겠습니다.

이 함수에 대해 소비자는 최대 3개의 선택적 함수를 인수로 전달할 수 있으며 순서는 다음과 같습니다.

1. 'completed handler'. 이 약속된 값이 사용 가능하게 될 때 주관자가 이 함수를 호출하고, 해당 값이 이미 사용 가능한 경우에는 then 내에서 즉시 completed handler가 호출됩니다.
2. 약속된 값을 얻지 못할 경우 호출되는 선택적 함수 'error handler'. 어떠한 promise든 error handler가 호출되면 절대로 completed handler가 호출되지 않습니다.
3. 작업에서 지원할 경우 중간 결과와 함께 주기적으로 호출되는 선택적 함수 'progress handler'. WinRT의 경우 API가 IAsync[Action | Operation]WithProgress의 반환 값을 갖고 IAsync[Action | Operation]는 그렇지 않다는 의미입니다.

error handler만 연결하고 completed handler는 연결하지 않으려는 경우 이러한 인수 중 아무 인수에나 'null'을 전달할 수 있습니다.

관계의 반대편을 살펴보면, 소비자는 then을 여러 번 호출하여 같은 promise에 handler를 원하는 만큼 신청할 수 있습니다. 또한 중심 콘텐츠에 then을 호출할 수 있는 다른 소비자와 promise를 공유할 수도 있습니다. 이러한 기능이 완벽하게 지원됩니다.

즉, promise는 수신하는 모든 handler 목록을 관리하고 적절한 시기에 호출해야 합니다. 또한 전체 관계에서 살펴본 것처럼 promise는 취소를 허용해야 합니다.

'Promises A' 사양의 다른 요구 사항은 then 메서드 자체가 promise를 반환하는 것입니다. 두 번째 promise는 첫 번째 promise.then에 제공된 completed handler가 돌아올 때 처리되며 두 번째 promise의 결과로 반환 값이 제공됩니다. 다음 코드를 살펴보시기 바랍니다.

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

someOperationAsync가 시작되면 'promise1'을 반환하는 것이 이 코드의 실행 체인입니다. 이 작업이 진행 중일 때 'promise2'를 즉시 반환하는 promise1.then을 호출합니다. 비동기 작업이 가능하지 않으면 completedHandler1이 호출되지 않는다는 점을 확실히 이해하시기 바랍니다. 여전히 기다리고 있는 상황을 가정해 보겠습니다. 이 경우 바로 promise2.then 함수를 호출합니다. 이번에도 역시 completedHandler2가 호출되지 '않습니다'.

나중에 someOperationAsync가 값 14618로 완료되었다고 해 봅시다. 이제 'promise1'이 처리되고 해당 값을 가진 completedHandler1을 호출합니다. 'result1'은 14618이 됩니다. 이제 completedHandler1이 실행되고 값 7103을 반환합니다. 이 시점에서 'promise2'가 처리되고 completedHandler2가 호출되며 'result2'는 7103입니다.

completed handler가 다른 promise를 반환하는 경우는 어떨까요? 이 경우는 약간 다르게 처리됩니다. 위 코드의 completedHandler1이 다음과 같이 promise를 반환한다고 합시다.

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

이 경우 completedHandler2의 'result2'는 'promise2a' 자체가 아니라 'promise2a'의 fulfillment 값입니다. completed handler가 promise를 반환하기 때문에 'promise2a'의 결과로 promise1.then에서 반환된 'promise2'가 처리됩니다.

바로 이러한 특징 때문에 순차적인 비동기 작업을 체인으로 엮을 수 있고, 체인의 각 작업의 결과는 다음 작업으로 전달됩니다. 중간 변수 또는 명명된 handler가 없는 경우 promise 체인에서 다음 패턴을 자주 보게 됩니다.

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
});

물론 각 completed handler는 수신하는 결과를 가지고 다양한 일을 하지만, 모든 체인에서 이 핵심 구조를 보게 될 것입니다. 또 하나의 사실은, 이 코드의 모든 then 메서드는 주어진 completed handler를 저장한 후 다른 promise를 반환하기 때문에 하나씩 차례대로 실행된다는 것입니다. 따라서 이 코드의 마지막 부분에 도착하면 'operation1'만 시작하고 completed handler가 호출되지 않습니다. 하지만 then을 호출할 때마다 중간 promise가 생성되고 서로 연결되어서 순차 작업이 진행될 때 체인을 관리합니다.

각 순차 작업을 이전 completed handler에 중첩하여 같은 순서로 배열할 수 있으며 이 경우 'return' 문 중 일부가 제외됩니다. 하지만 이렇게 중첩하려면 들여쓰기 때문에 고생을 많이 하게 되며, 특히 then을 호출할 때마다 진행 상황과 error handler를 추가할 경우 더욱 어렵게 됩니다.

이에 대해 부연 설명을 하자면, WinJS에서 promise의 기능 중 하나는 체인에서 발생하는 모든 오류가 자동으로 체인의 끝부분에 전달된다는 것입니다. 다시 말해, 모든 수준에서 handler를 사용하지 말고 마지막으로 호출되는 then에 error handler를 하나만 연결할 수 있어야 합니다. 하지만 다양한 이유로 인해 체인의 마지막 링크가 then 호출인 경우 이러한 오류가 가려진다는 점에 주의해야 합니다. 이 때문에 WinJS에서는 promise에 done 메서드를 제공합니다. 이 메서드는 then과 같은 인수를 받아들이지만 체인이 완전하다고 표시합니다(또 다른 promise 대신 'undefined'를 반환). 그러면 체인의 오류에 대해 done에 연결된 error handler가 호출됩니다. 뿐만 아니라 error handler가 없을 경우 done 메서드가 앱 수준에서 예외를 발생시키며, 이는 WinJS.Application.onerror 이벤트의 window.onerror로 처리할 수 있습니다. 정리하자면, 예외를 드러내서 적절하게 처리할 수 있도록 모든 체인을 done으로 끝내는 것이 가장 좋습니다.

물론 then 호출의 긴 체인에서 마지막 promise를 반환하는 것이 '목적'인 함수를 작성하는 경우 마지막 부분에 then 을 사용해야 합니다. 오류 처리의 책임은 또 다른 체인에서 해당 promise를 사용하는 호출자에게 있습니다.

promise 생성: WinJS.Promise 클래스

개발자는 'Promises A' 사양에 맞게 promise 클래스를 직접 만들 수는 있지만 너무 번거롭기 때문에 라이브러리에 맡겨 두는 것이 가장 좋습니다. 이러한 이유로 WinJS에서는 WinJS.Promise라는 철저한 검증을 마친 강력하고 유연한 promise 클래스를 제공합니다. 이 클래스를 사용하면 주관자/소비자 관계 또는 then 동작을 일일이 관리할 필요 없이 다양한 값과 작업에 대한 promise를 간편하게 생성할 수 있습니다.

필요하다면 new WinJS.Promise 또는 적절한 도우미 함수를 사용하여 비동기 작업과 기존(동기) 값 모두에 대한 promise를 생성할 수 있습니다. 이에 대해서는 다음 단원에서 설명하겠습니다. promise는 단지 코드 구조일 뿐이라는 점을 기억하시기 바랍니다. promise가 비동기 작업을 래핑해야 할 필요는 '전혀' 없습니다. 마찬가지로, promise의 어떤 코드 조각을 단지 래핑한다고 해서 자동으로 비동기식으로 실행되지는 않습니다. 비동기식으로 실행하는 것은 여전히 개발자의 몫입니다.

WinJS.Promise를 직접 사용하는 간단한 예를 들어 보겠습니다. 1부터 어떤 숫자까지 추가하면서 긴 계산을 수행하려고 하는데 비동기식으로 계산해야 한다고 가정해 보겠습니다. 일상적 작업에 대한 콜백 메커니즘을 직접 개발할 수 있지만 promise 내에서 래핑할 경우 다른 API의 다른 promise와 체인으로 연결하거나 이어 붙일 수 있습니다. 이러한 줄과 함께 WinJS.xhr 함수가 promise 내에서 JavaScript의 비동기 XmlHttpRequest를 래핑하므로 개발자가 후자의 특정 이벤트 구조를 처리하지 않아도 됩니다.

물론 긴 계산에 JavaScript 작업자를 사용할 수도 있지만 설명을 위해 UI 스레드를 유지하고 setImmediate를 사용하여 작업을 여러 단계로 구분하겠습니다. 다음은 WinJS.Promise를 사용하여 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) });
    });
}

new WinJS.Promise를 호출할 때 생성자의 단일 인수는 'initializer' 함수입니다(이 예에서는 익명). initializer가 수행할 작업을 캡슐화하지만 이 함수 자체가 UI 스레드에서 '동기식으로' 실행될 것이 분명합니다. 따라서 여기서 setImmediate를 사용하지 않고 긴 계산을 수행할 경우 그 시점의 모든 UI 스레드를 차단하게 됩니다. 다시 한 번 말씀 드리지만 promise 내에 코드를 배치한다고 해서 자동으로 비동기식으로 실행되지는 않습니다. initializer 함수 자체에서 그렇게 설정해야 합니다.

인수의 경우 initializer 함수는 promise가 지원하는 completed, error 및 progress 사례의 '디스패처' 세 개를 수신합니다. 보시다시피 작업하는 동안 적절한 인수를 사용하여 적절한 시기에 디스패처를 호출하고 있습니다.

저는 이러한 함수를 "디스패처"라고 부릅니다. 소비자가 promise의 then 메서드(또는 done, 설명은 생략)를 요청하는 handler와 다르기 때문입니다. 좀 더 자세히 알아보자면, WinJS는 handler 배치를 관리하며, 몇 명이 되었든 몇 개가 되었든 소비자가 handler를 요청할 수 있습니다. 이러한 디스패처 중 하나를 호출하면 WinJS가 내부 목록을 통해 반복하면서 개발자를 대신하여 모든 handler를 호출합니다. 또한 WinJS.Promise는 then이 체인 연결에 필요한 만큼 또 다른 promise를 반복하도록 합니다.

정리하자면, WinJS.Promise는 promise를 둘러싼 모든 것을 제공합니다. 따라서 개발자는 promise가 나타내는 핵심 작업에만 집중할 수 있으며, 이러한 것들은 initializer 함수에 포함되어 있습니다.

promise 생성을 돕는 도우미

promise를 생성하는 기본 도우미 함수는 정적 메서드인 WinJS.Promise.as입니다. 이 메서드는 promise의 '모든' 값을 래핑합니다. 기존 값의 래퍼는 정상적으로 작동하고 then으로 전달되는 모든 completed handler를 호출합니다. 따라서 알고 있는 임의의 값을 promise로 처리할 수 있기 때문에 연결 또는 체인 연결을 통해 다른 promise와 혼합하여 구성할 수 있습니다. 기존 promise에 as를 사용하면 해당 promise만 반환합니다.

다른 정적 도우미 함수는 WinJS.Promise.timeout입니다. 이 함수는 setTimeout 및 setImmediate와 관련된 편리한 래퍼를 제공합니다. 두 번째 promise가 특정 시간(밀리초) 내에 처리되지 않을 경우 두 번째 promise를 취소하는 promise를 만들 수도 있습니다.

setTimeout 및 setImmediate와 관련된 timeout promise가 'undefined'를 사용하여 스스로 처리되는 것을 주의 깊게 살펴보시기 바랍니다. 이와 관련하여 “이 promise를 사용하여 시간 제한 이후에 다른 결과를 제공하려면 어떻게 해야 합니까?”라는 질문을 자주 받습니다. 답변을 드리자면, then이 completed handler의 반환 값을 통해 처리되는 또 다른 promise를 반환합니다. 이 코드 줄에서 예를 들자면 다음과 같습니다.

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

이 코드는 1초 후 값 12345로 처리되는 promise 'p'를 생성합니다. 다시 말해, WinJS.Promise.timeout(…).then(function () { return <value>} )는 지정된 시간 제한 이후 '<value>'를 제공하는 패턴입니다. '<value>' 자체가 또 다른 promise인 경우 시간 제한 이후 특정 시점에 해당 promise의 처리 값을 제공합니다.

취소 및 promise 오류 생성

다들 보셨겠지만 조금 전에 본 코드는 두 가지 결함이 있습니다. 첫째, 시작 후 작업을 취소하는 방법이 없고 둘째, 작업 처리 오류를 표시하는 방법이 없습니다.

두 가지 문제를 해결하는 비결을 소개해 드리자면, calculateIntegerSum 함수처럼 promise를 생산하는 함수는 항상 promise를 반환해야 합니다. 어떤 작업이 완료되지 않거나 아예 시작되지 않을 경우 해당 promise는 소위 말하는 '오류 상태'에 있는 것입니다. 즉, 해당 promise는 completed handler에 전달할 수 있는 값을 갖고 있지 않으며 앞으로도 가질 수 없습니다. 단지 error handler만 호출할 수 있습니다. 사실, 소비자가 한 promise에서 then을 호출했는데 그 promise가 이미 오류 상태인 경우 해당 promise는 즉시(동기식으로) then에 전달되는 error handler를 호출합니다.

WinJS.Promise가 오류 상태로 진입하는 두 가지 이유가 있습니다. 첫 번째는 소비자가 cancel 메서드를 호출하는 경우이고 두 번째는 initializer 함수 내의 코드가 error 디스패처를 호출하는 경우입니다. 이러한 상황이 발생하면 해당 promise에 전달된 오류 값이 무엇이든 error handler에 전달됩니다. WinJS.Promise 내에 작업을 생성할 경우 WinJS.ErrorFromName 인스턴스를 사용할 수도 있습니다. 이 인스턴스는 JavaScript 개체이며, 오류를 식별하는 'name' 속성과 자세한 정보가 들어 있는 'message' 속성을 갖고 있습니다. 예를 들어 한 promise가 취소되면 error handler는 'name' 및 'message' 이름이 “Canceled”로 설정된 오류 개체를 받습니다.

작업을 아예 시작할 수 없는 경우는 어떨까요? 예를 들어 0, 0처럼 잘못된 인수로 calculateIntegerSum을 호출할 경우 카운트를 시도조차 하지 않고 그 대신 오류 상태의 promise를 반환합니다. 이것이 바로 정적 메서드 WinJS.Promise.wrapError의 목적입니다. WinJS.ErrorFromName의 인스턴스를 가져와서 오류 상태의 promise를 반환합니다. 우리가 예로 든 코드에서도 새로운 WinJS.Promise 인스턴스를 사용하는 대신 오류 상태의 promise를 반환합니다.

또 다른 문제는 promise의 cancel 메서드를 호출하면 promise 자체가 오류 상태에 빠지는 것입니다. 진행 중인 비동기 작업을 중지하려면 어떻게 해야 할까요? 앞에서 구현한 calculateIntegerSum은 생성된 promise의 상태에 관계없이 작업이 완료될 때까지 계속해서 setImmediate를 호출할 것입니다. 사실, promise가 취소된 후 작업에서 complete 디스패처를 호출할 경우 promise가 해당 완료를 무시합니다.

이 문제를 해결하려면 promise가 해당 작업에 더 이상 계속할 필요가 없다고 알릴 수 있는 방법이 필요합니다. 이러한 이유로 WinJS.Promise 생성자는 promise가 취소될 때 호출되는 두 번째 함수 인수를 사용합니다. 이 글의 예에서는 이 함수를 호출할 때 setImmediate가 이어서 호출되지 않도록 하면 계산이 중지됩니다. 다음은 오류를 적절하게 처리한 코드입니다.

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;
    });
}

대체적으로 WinJS.Promise 인스턴스를 생성하여 다양한 용도에 이용할 수 있습니다. 예를 들어 다른 비동기 메서드를 통해 웹 서비스에 정보를 전달하는 라이브러리를 갖고 있다면 promise 내에서 작업을 래핑할 수 있습니다. 새 promise를 사용하여 다양한 소스의 여러 비동기 작업(또는 다른 promise)을 모든 관계를 제어하고 싶은 하나의 promise로 결합할 수도 있습니다. WinJS.Promise의 initializer 코드 내에서 다른 비동기 작업과 그 promise에 대한 개발자 고유의 처리기를 사용할 수 있습니다. 이러한 처리기를 사용하여 네트워크 시간 제한에 대한 자동 재시도 메커니즘을 캡슐화하고, 일반적인 진행 상황 업데이트 UI를 연결하고, 자세한 로깅 또는 분석을 추가할 수 있습니다. 어떤 방법을 사용하든 나머지 코드에서 사소한 부분은 신경 쓰지 않고 소비자 측에서 promise를 처리할 수 있습니다.

다음 코드 줄을 사용하면 JavaScript 작업자를 매우 간단하게 promise로 래핑할 수 있습니다. WinRT의 다른 비동기 작업과 모양 및 동작이 비슷합니다. 잘 아시겠지만 작업자는 앱의 작업자 개체에 message 이벤트를 발생시키는 postMessage 호출을 통해 결과를 전달합니다. 다음 코드는 message에 전달되는 결과를 통해 처리되는 promise에 해당 이벤트를 연결합니다.

// 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
});

이 코드를 확장하여 작업자의 오류를 처리하려면 error 디스패처를 다른 변수에 저장하고 message 이벤트 처리기가 이벤트 인수의 오류 정보를 확인하도록 하고, complete 디스패처 대신 error 디스패처를 적절하게 호출해야 합니다.

병렬 promise 연결

promise는 비동기 작업을 래핑하는 데 자주 사용되기 때문에 개발자는 여러 작업을 병렬로 진행할 수 있습니다. 그렇다면 그룹의 한 promise가 처리되는 시기 또는 그룹의 모든 promise가 처리되는 시기가 언제인지 궁금할 것입니다. 이러한 용도로 사용되는 것이 정적 함수 WinJS.Promise.any 및 WinJS.Promise.join입니다.

두 함수는 여러 값을 수락하거나 값 속성이 있는 개체를 수락합니다. 두 값은 promise일 수 있으며 promise가 아닌 값은 WinJS.Promise.as를 통해 래핑되고 결국 전체 배열 또는 개체가 promise로 구성됩니다.

다음은 any의 특징입니다.

• any는 다른 promise 중 하나가 처리되거나 오류(논리적 OR)와 함께 실패할 때 처리되는 단일 promise를 생성합니다. 기본적으로 any는 모든 promise에 completed handler를 연결하며, 한 completed handler가 호출되면 any promise가 수신한 모든 completed handler를 호출합니다.
• any promise가 처리된 후, 즉 목록의 첫 번째 promise가 처리된 후 목록의 다른 작업이 계속 실행되어 해당 promise에 개별적으로 할당된 모든 completed, error 또는 progress handler를 호출합니다.
• any에서 promise를 취소할 경우 목록의 모든 promise가 취소됩니다.

join의 경우

• join은 다른 '모든' promise가 처리되거나 오류(논리적 AND)와 함께 실패할 때 처리되는 단일 promise를 생성합니다. 기본적으로 join은 모든 promise에 completed 및 error handler를 연결하며, 모든 handler가 호출될 때까지 기다렸다가 수신하는 모든 completed handler를 호출합니다.
• 또한 join promise는 개발자가 제공하는 모든 progress handler에 진행 상황을 보고합니다. 이 예의 중간 결과는 지금까지 처리된 개별 promise에서 얻은 결과입니다.
• join에서 promise를 취소할 경우 아직 보류 중인 모든 promise가 취소됩니다.

any와 join 외에도 알아두면 편리하게 사용할 수 있는 정적 WinJS.Promise 메서드가 두 개 더 있습니다.

• is는 임의 값이 promise인지 확인하여 부울을 반환합니다. “then” 함수를 사용하는 개체인지 확인하는 것이 기본 역할이며, “done”은 테스트하지 않습니다.
• theneach는 then을 사용하여 promise 그룹에 completed, error 및 progress handler를 적용하고, 그 결과를 promise 내의 또 다른 값 그룹으로 반환합니다. 모든 handler는 'null'일 수 있습니다.

연속 결과를 갖는 병렬 promise

WinJS.Promise.join 및 WinJS.Promise.any를 사용하여 병렬 promise, 즉 병렬 비동기 작업을 처리할 수 있습니다. 다시 한 번 말씀 드리지만 join이 반환하는 promise는 배열의 모든 promise가 처리될 때 처리됩니다. 하지만 promise는 무작위 순서로 완료됩니다. 이 방법으로 실행할 수 있는 일련의 작업이 있지만 그 결과를 잘 정의된 순서로, 다시 말해서 promise가 배열에 나타나는 순서대로 처리하려면 어떻게 해야 할까요?

이렇게 하려면 각 후속 promise를 앞에 있는 모든 promise의 join에 연결해야 합니다. 이 글을 시작할 때 소개한 코드가 정확하게 이 방법을 사용합니다. 그 코드를 다시 한 번 보여 드리겠습니다. 하지만 이번에는 promise가 잘 보이도록 약간 수정했습니다. 'list'는 가상의 promise를 생산하는 비동기 호출 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);
    });
})

이 코드를 이해하려면 배열의 reduce 메서드가 작동하는 방식을 먼저 이해해야 합니다. 배열의 각 항목에서 reduce는 함수 인수를 호출합니다. 여기서는 callback인데 인수 네 개를 수신합니다. 이 코드에서는 네 개 중 세 개만 사용하고 있습니다.

• 'prev' 'previous' 호출에서 callback으로 반환된 값입니다(첫 번째 항목에서는 'null').
• 'item' 배열의 현재 값입니다.
• 'i' 목록의 항목 인덱스입니다.
• 'source' 원래 배열입니다.

목록의 첫 번째 항목에는 opPromise₁이라고 하는 promise를 사용합니다. prev가 'null'이기 때문에 [WinJS.Promise.as(null), opPromise₁]을 연결합니다. 하지만 join 자체를 반환하는 것은 아니라는 점에 주의하시기 바랍니다. 그 대신 completed라고 이름을 붙인 completed handler를 join에 연결하고 then으로부터 promise를 반환할 것입니다.

then에서 반환되는 promise는 completed handler가 반환될 때 처리된다는 것을 기억하시기 바랍니다. 즉, callback에서 반환하는 것은 첫 번째 항목의 completed handler가 opPromise₁의 결과를 처리할 때까지 완료되지 않은 promise입니다. join의 결과를 되돌아보면 원래 목록의 promise에서 얻은 결과가 들어 있는 개체를 통해 처리됩니다. 즉, 처리 값 'v'가 'prev' 속성과 'result' 속성을 모두 포함하며, 후자는 opPromise₁의 결과입니다.

'list'의 다음 항목을 사용하여 callback이 이전 join.then의 promise가 들어 있는 'prev'를 수신합니다. 그런 다음 opPromise₁.then 및 opPromise₂의 새로운 join을 생성하게 됩니다. 결과적으로 이 join은 opPromise₂가 처리되고 opPromise₁의 completed handler가 반환될 때까지 완료되지 않습니다. 놀랍지 않습니까? 이 join에 연결하는 completed₂ handler는 completed₁이 반환될 때까지 호출되지 않습니다.

목록의 각 항목마다 동일한 종속성이 계속 구축됩니다. 항목 'n'에 대한 join.then의 promise는 completed_n이 반환될 때까지 처리되지 않습니다. 따라서 completed handler가 'list'와 같은 순서대로 호출됩니다.

결론

이 글에서 promise 그 자체로는 미래의 어느 시점에 제공할 값을 갖고 있는 주관자와 그 값을 언제 받을 수 있는지 알고 싶어하는 소비자 사이의 관계를 나타내는 코드 구조 또는 호출 규칙에 불과하다는 것을 살펴보았습니다. 그렇기 때문에 promise는 비동기 작업의 결과를 매우 잘 나타내며 JavaScript로 작성된 Windows 스토어 앱 내에서 광범위하게 사용됩니다. 또한 promise의 사양에서는 순차적인 비동기 작업을 체인으로 연결하는 것을 허용하며, 각 중간 결과는 한 링크에서 다음 링크로 전달됩니다.

WinJS(JavaScript용 Windows 라이브러리)는 모든 작업을 개발자 혼자 래핑할 수 있도록 견고하게 구축된 promise를 제공합니다. 또한 promise를 병렬 작업에 연결하는 등의 일반 시나리오를 위한 도우미도 제공합니다. 따라서 WinJS를 사용하면 비동기 작업을 매우 효율적이고 효과적으로 처리할 수 있습니다.

Windows 에코시스템 팀 프로그램 관리자
Kraig Brockschmidt
작성자, 'HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍하기'

컬렉션을 지원하도록 JavaScript로 작성된 Windows 스토어 앱의 성능에 가장 큰 영향을 미치는 것은 WinJS ListView 컨트롤과의 원활한 연동입니다. 사실 별로 놀라운 일은 아닙니다. 수많은 항목을 관리하고 표시할 때 항목 최적화 하나하나가 모두 중요합니다. 그 중에서도 가장 중요한 것은 각 항목을 렌더링하는 방법입니다. 즉, ListView 컨트롤의 각 항목을 언제, 어떻게 DOM에 구축하고 앱에서 표시할 것인지가 가장 중요합니다. 사실, 사용자가 신속하게 목록을 둘러보고 목록의 페이스를 유지하려고 할 때에는 언제와 어디서 중 '언제'가 더 중요합니다.

ListView의 항목 렌더링은 HTML에 정의된 선언적 템플릿 또는 목록의 모든 항목에 대해 호출되는 사용자 지정 JavaScript 렌더링 함수를 통해 이루어집니다. 선언적 템플릿을 사용하는 것이 가장 간단한 방법이지만 전체 프로세스에서 특정 컨트롤을 융통성 있게 사용할 수 없다는 단점이 있습니다. 한편 렌더링 함수는 항목별로 렌더링을 사용자 지정할 수 있어서 HTML ListView 성능 최적화 샘플에서 보여 준 것처럼 다양한 최적화가 가능합니다. 최적화의 종류는 다음과 같습니다.

• 기본 렌더링 함수에서 지원하는 기능을 사용하여 항목 데이터 및 렌더링된 요소를 비동기식으로 제공할 수 있습니다.
• ListView의 전체적인 레이아웃에 필요한 항목 모양 생성을 내부 요소와 분리할 수 있습니다. 이 기능은 자리 표시자 렌더러를 통해 지원됩니다.
• 데이터를 대체하여 이전에 생성한 항목 요소 및 그 하위 요소를 재사용함으로써 요소 생성 단계 대부분을 생략하고 자리 표시자 렌더러를 재활용할 수 있습니다.
• 항목이 표시되고 ListView가 빠른 속도로 이동되지 않을 때까지 이미지 로딩이나 애니메이션처럼 리소스 소모가 많은 시각화 작업을 지연합니다. 이 기능은 다단계 렌더러를 통해 수행됩니다.
• 다단계 일괄 처리 렌더러를 통해 동일한 시각화 작업을 일괄 처리함으로써 DOM 재렌더링을 최소화합니다.

이 글에서는 이러한 단계를 살펴보고 ListView의 항목 렌더링 프로세스와 어떻게 연동하는지 알아보겠습니다. 어느 정도는 예상하시겠지만 항목 렌더링의 '시기'를 최적화하는 문제는 비동기 작업과 관련이 깊기 때문에 다양한 promise가 나오게 됩니다. 그러므로 이 블로그의 이전 글 promise의 모든 것을 바탕으로 promise 자체에 대해서도 자세히 알아볼 것입니다.

모든 렌더러에 적용되는 공통 사항으로, 언제나 핵심 항목 렌더링 시간(지연된 작업은 제외)을 최소로 유지하는 것이 중요합니다. ListView의 최종 성능은 업데이트가 화면 새로 고침 간격과 얼마나 일치하느냐에 따라 크게 좌우됩니다. 항목 렌더러에 소비하는 시간(밀리초)이 조금만 길어져도 ListView의 전체 렌더링 시간이 다음 새로 고침 간격까지 늘어나서 프레임이 손실되고 화면 끊김 현상이 발생합니다. 다시 말해서, 항목 렌더러는 JavaScript 코드 최적화에서 매우 중요한 역할을 합니다.

기본 렌더러

항목 렌더링 함수, 줄여서 '렌더러'가 어떤 모양인지 신속하게 살펴보겠습니다. 렌더러는 ListView의 itemTemplate 속성에 템플릿 이름 대신 할당하는 함수로, 필요에 따라 ListView가 DOM에 포함하려는 항목에 대해 호출됩니다. (렌더러에 대한 기본 설명서는 itemTemplate 페이지에서 찾을 수 있지만 이 페이지에서는 최적화만을 간단하게 보여 줍니다.)

여러분은 항목 렌더링 함수에 ListView 데이터 원본의 항목이 제공되고, 그 후 해당 항목에 필요한 HTML 요소를 생성한 후 ListView가 DOM에 추가할 수 있는 루트 요소를 반환할 것으로 예상하실 것입니다. 기본적으로는 이 예상이 맞지만 두 가지 사항을 더 고려해야 합니다. 첫째, 항목 데이터 자체는 비동기적으로 로드되기 때문에 요소 생성을 해당 데이터의 가용성과 연결할 수 있습니다. 뿐만 아니라 항목 자체를 렌더링하는 프로세스에 원격 URI에서 이미지를 로드한다거나 항목 데이터에서 확인된 다른 파일을 읽는 등의 다른 비동기 작업이 관련될 수 있습니다. 앞으로 보게 될 다양한 최적화 수준에서 항목 요소를 요청하고 해당 요소를 실제로 제공하는 사이에 수많은 비동기 작업이 가능합니다.

그렇기 때문에 이번에도 promise가 관련될 것으로 예상할 수 있습니다! 첫 번째 근거로, ListView는 항목 데이터에 렌더러를 직접 제공하지 않고 해당 데이터에 대한 promise를 제공합니다. 그리고 함수는 항목의 루트 요소를 직접 반환하지 않고 해당 요소에 대한 promise를 반환합니다. 따라서 항목으로 구성된 전체 페이지가 렌더링될 때까지 ListView가 여러 항목 렌더링 promise를 함께 연결하여 기다릴(비동기) 수 있습니다. 이러한 방법을 통해 여러 페이지를 지능적으로 구축합니다. 시각적 항목으로 구성되는 페이지를 먼저 구축한 후 그 페이지 앞뒤로 사용자가 그 다음으로 이동할 확률이 높은 오프스크린 두 페이지를 구축합니다. 뿐만 아니라 이러한 promise를 모두 제 위치에 배치하면 사용자가 페이지를 이동할 때 ListView가 완료되지 않은 항목에 대한 렌더링을 쉽게 취소할 수 있으므로 불필요한 요소를 생성하지 않을 수 있습니다.

다음 샘플을 통해 이러한 promise가 simpleRenderer 함수에서 어떻게 사용되는지 살펴보겠습니다.

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;
    });
}

이 코드는 가장 먼저 completed 처리기를 itemPromise에 연결합니다. 항목 데이터가 제공되면 처리기가 호출되어 호출에 대한 응답으로 요소를 효과적으로 생성합니다. 다시 한 번 강조하지만 요소를 직접 반환하는 것이 아니라 해당 요소로 처리되는 promise를 반환하는 것입니다. 즉, itemPromise.then()의 반환 값은 ListView가 '요소'를 필요로 할 때 해당 요소에 의해 처리되는 promise입니다.

promise를 반환하기 때문에 필요하다면 다른 비동기 작업을 수행할 수 있습니다. 이 사례에서 렌더러는 중간 promise를 연결하여 체인의 마지막 then에서 해당 promise를 반환할 수 있습니다. 예를 들면 다음과 같습니다.

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;
    });
}

이 예에서는 마지막 then 호출에서 promise를 반환하기 때문에 체인의 마지막에 done을 사용하지 '않는다'는 점에 주의하시기 바랍니다. 발생하는 모든 오류는 ListView에서 처리합니다.

자리 표시자 렌더러

ListView 최적화의 다음 단계에서는 요소 구축을 두 단계로 나누는 '자리 표시자 렌더러'를 사용합니다. 이렇게 하면 ListView가 각 항목 내에 모든 요소를 구축하지 않고도 목록의 전체적인 레이아웃을 정의하는 데 필요한 요소 부분만 요청할 수 있습니다. 결과적으로 ListView가 레이아웃 단계를 신속하게 완료하고 추가 입력에 대해 계속해서 민첩하게 반응할 수 있습니다. 그리고 나머지 요소는 나중에 요청할 수 있습니다.

자리 표시자 렌더러는 하나의 promise만을 반환하는 것이 아니라 다음과 같은 두 가지 속성을 가진 개체를 반환합니다.

• element - 크기 및 모양을 정의하기에 충분하고 항목 데이터에 종속되지 않는 항목 구조의 최상위 요소입니다.
• renderComplete - 남은 요소의 콘텐츠가 구성될 때 처리되는 promise입니다. 다시 말해서 앞에서 본 것처럼 itemPromise.then으로 시작하는 체인에서 promise를 반환합니다.

ListView는 렌더러가 promise를 반환하는지(이전과 같은 기본 사례) 아니면 'element' 및 'renderComplete' 속성을 반환하는지(좀 더 발전된 사례) 확인할 수 있을 정도로 똑똑합니다. 따라서 이전 simpleRenderer와 동등한 자리 표시자 렌더러는 다음과 같습니다.

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' />");
        })
    };
}

샘플의 css/scenario1.css 파일의 'itemTempl' 클래스가 항목의 너비와 높이를 직접 지정하기 때문에 'element.innerHTML'의 배치를 renderComplete 내부로 이동할 수 있습니다. 'element' 속성에 포함된 것은 자리 표시자에 기본 “…” 텍스트를 제공하기 때문입니다. 개발자는 모든 항목 간에 공유하는(그래서 렌더링 속도가 빠른) 작은 인패키지(in-package) 리소스를 참조하는 'img' 요소를 간편하게 사용할 수 있습니다.

자리 표시자 렌더러 재활용

다음 최적화인 '자리 표시자 재활용' 렌더러는 promise와 관련이 있는 위치에 새 항목을 전혀 추가하지 않습니다. 그보다는 앞에서 렌더링되었지만 더 이상 표시되지 않는 항목의 루트 요소인 'recycled'라는 렌더러에 두 번째 매개 변수의 존재를 인식시킵니다. 즉, recycled 요소의 하위 요소가 이미 제 위치에 있기 때문에 개발자가 데이터를 대체하거나 일부 요소를 수정할 수 있습니다. 완전히 새로운 항목을 추가할 경우 리소스가 많이 드는 요소 생성 호출 과정이 필요한데, 이 과정을 대부분 생략할 수 있으므로 렌더링 프로세스 시간을 크게 절약할 수 있습니다.

loadingBehavior를 "randomaccess"로 설정할 경우 ListView가 recycled 요소를 제공할 수 있습니다. 'recycled'가 제공되면 요소 및 하위 요소에서 데이터를 삭제하고 자리 표시자로 반환한 다음 데이터를 채우고 필요하다면 'renderComplete' 내에 하위 요소를 추가할 수 있습니다. ListView가 맨 처음으로 생성되거나 loadingBehavior가 "incremental"로 설정되어 있어서 recycled 요소가 제공되지 않을 경우 요소를 새로 생성해야 합니다. 다음은 이러한 변형에 대한 샘플 코드입니다.

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";
        })
    };
}

'renderComplete'에서 새 자리 표시자에 대해 생성하지 않은 요소(예: 'label')가 있는지 확인하고 필요하다면 요소를 생성합니다.

좀 더 일반적인 방법으로 recycled 항목을 제거하려면 ListView의 resetItem 속성에 함수를 제공하는 방법을 고려해 보십시오. 이 함수는 위에서 보여 준 것과 비슷한 코드를 갖고 있습니다. resetGroupHeader 속성도 동일합니다. 그룹 헤더뿐만 아니라 항목에도 템플릿 함수를 사용할 수 있기 때문입니다. 그룹 헤더는 그 수가 훨씬 적고 일반적으로 성능에 미치는 영향이 같지 않기 때문에 자세히 다루지는 않았습니다. 하지만 그 성능은 보시는 바와 같습니다.

다단계 렌더러

이번에 살펴 볼 최적화는 '다단계 렌더러'입니다. 이 최적화에서는 나머지 항목이 DOM에 모두 표시될 때까지 재활용 자리 표시자 렌더러를 로드 지연 이미지 및 기타 미디어로 확장합니다. 또한 항목이 실제로 화면에 나타날 때까지 애니메이션 같은 효과를 지연합니다. 이를 통해 사용자가 ListView를 신속하게 이동하는 것을 인식하므로 ListView가 안정적인 상태가 될 때까지 리소스가 많이 필요한 작업을 비동기적으로 지연할 수 있습니다.

item의 멤버는 itemPromise 즉, ready라는 속성(promise)과 두 개의 메서드 loadImage 및 isOnScreen에서 오기 때문에 ListView가 필요한 후크를 제공하며 둘 모두 (더 많은) promise를 반환합니다. 예를 들어 다음과 같습니다.

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

사용 방법은 다음과 같습니다.

• ready 체인의 첫 번째 completed 처리기에서 이 promise를 반환합니다. 이 promise는 요소의 전체 구조가 렌더링되어 표시될 때 처리됩니다. 즉, 또 다른 then을 이미지 로딩 등의 시각화 후속 작업을 하는 completed 처리기와 체인으로 연결할 수 있습니다.
• loadImage URI에서 이미지를 다운로드하여 제공된 'img' 요소에 표시하고, 같은 요소에 의해 처리되는 promise를 반환합니다. 이 promise에 completed 처리기를 연결하면 스스로 isOnScreen에서 promise를 반환합니다. img 요소를 제공하지 않을 경우 loadImage가 'img' 요소를 생성하여 completed 처리기에 제공합니다.
• isOnScreen 처리 값이 항목의 표시 여부를 나타내는 부울인 promise를 반환합니다. 현재 구축에서는 알려진 값이기 때문에 promise가 동기적으로 처리됩니다. 하지만 promise에 래핑하면 보다 긴 체인에 사용할 수 있습니다.

이 모든 것을 적용한 것이 아래 샘플의 multistageRenderer 함수이며, 이미지 로드가 완료되는 위치에서 페이드 인 애니메이션이 시작됩니다. 'renderComplete' promise에서 무엇이 반환되는지 잘 보시기 바랍니다.

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);
    }
})

다양한 작업이 진행되지만 여전히 기본 promise 체인만을 사용하고 있습니다. 렌더러의 첫 번째 비동기 작업은 항목 요소 구조에서 텍스트처럼 간단한 부분을 업데이트하는 것입니다. 그러면 item.ready에서 promise가 반환됩니다. 해당 promise가 처리될 때, 좀 더 정확하게 말해서 해당 promise가 처리될 경우 항목의 비동기 loadImage 메서드를 사용하여 이미지 다운로드를 시작하면 해당 completed 처리기에서 item.isOnScreen promise가 반환됩니다. 즉, '화면' 가시성 플래그가 체인의 마지막 completed 처리기에 전달됩니다. isOnScreen promise가 처리될 때, 조금 더 정확히 말해서 처리될 경우, 즉 항목이 실제로 표시될 때 애니메이션과 같은 관련 작업을 수행할 수 있습니다.

처리될 경우를 강조해서 말씀 드렸는데, 이 동작이 수행될 때 사용자가 ListView 내부를 돌아다니고 있을 확률이 매우 높기 때문입니다. 모든 promise를 체인으로 연결해 놓으면 항목이 화면에 표시되지 않거나 버퍼링된 페이지가 사라질 때 ListView가 비동기 작업을 취소할 수 있습니다. 이 정도면 ListView 컨트롤이 '수많은' 성능 테스트를 거쳤다는 충분한 증거가 되지 않을까요?

또한 여전히 'renderComplete' 속성 내의 렌더링 함수에서 promise를 반환하고 있기 때문에 모든 체인에서 then을 사용한다는 점을 다시 한 번 강조하겠습니다. 이러한 렌더러에서 체인 마지막까지 갈 일이 없기 때문에 마지막 부분에 done을 사용할 일도 없습니다.

미리 보기 일괄 처리

마지막 최적화는 ListView 컨트롤을 향해 날리는 '마지막 일격'입니다. batchRenderer라는 함수를 보면 다음과 같은 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);
    }
})

item.loadImage 호출과 item.isOnScreen 확인 사이에 thumbnailBatch라는 이 신기한 함수를 호출하는 것만 빼면 multistageRenderer와 거의 차이가 없습니다. 체인에 thumbnailBatch를 배치했기 때문에 그 반환 값은 자체적으로 또 다른 promise를 반환하는 completed 처리기여야 합니다.

어려운가요? 그렇다면 자세히 알아보겠습니다. 하지만 그 전에 우리가 하려는 것에 대한 배경 지식을 좀 더 쌓아야 합니다.

ListView에 항목이 하나밖에 없다면 다양한 로드 최적화가 눈에 띄지 않을 수 있습니다. 하지만 일반적으로 ListView에는 여러 항목이 있고 각 항목마다 렌더링 함수가 호출됩니다. 이전 단원의 multistageRenderer에서 각 항목을 렌더링하면 비동기 item.loadImage 작업이 시작되어 임의의 URI에서 축소판이 다운로드되며, 각 작업마다 임의의 시간이 배정될 수 있습니다. 따라서 목록 전체를 놓고 보면 여러 loadImage 호출이 동시에 진행되고, 각 항목의 렌더링은 특정 미리 보기가 완료될 때까지 기다립니다. 여기까지는 별 문제가 없을 것입니다.

하지만 multistageRenderer에서 전혀 보이지 않는 중요한 특징 한 가지가 있습니다. 그것은 바로 미리 보기의 'img' 요소가 '이미' DOM에 있으며, 다운로드가 완료되는 즉시 loadImage 함수가 해당 이미지의 'src' 특성을 설정한다는 것입니다. 결국 promise 체인의 나머지 부분에서 돌아오는 즉시 렌더링 엔진에서 업데이트가 트리거되고, 해당 시점 이후부터는 근본적으로 동기 상태가 됩니다.

따라서 짧은 시간 내에 다수의 미리 보기가 UI 스레드로 돌아올 수 있고 그렇게 될 경우 렌더링 엔진에 과도한 변동이 일어나 표시 성능이 떨어지게 됩니다. 과도한 변동을 피하려면 이러한 'img' 요소가 DOM에 있기 '이전에' img 요소를 완전히 생성한 후 단일 렌더링 경로에서 모두 처리할 수 있도록 img 요소를 일괄적으로 추가해야 합니다.

샘플에서는 createBatch라는 마법과 같은 promise 코드 함수를 통해 이 작업을 처리했습니다. createBatch는 전체 앱에 대해 단 한 번만 호출되며, 그 결과(또 다른 함수)는 thumbnailBatch라는 변수에 저장됩니다.

var thumbnailBatch;
thumbnailBatch = createBatch();

지금부터 설명할 이 thumbnailBatch 함수를 호출하면 다시 렌더러의 promise 체인으로 삽입됩니다. 이렇게 삽입하는 이유는 잠시 후 보게 될 일괄 처리 코드의 특성을 감안한 것으로, 로드된 'img' 요소를 그룹화해 두었다가 나중에 적절한 간격으로 릴리스하여 처리하기 위함입니다. 다시 한 번 강조하지만, 렌더러의 promise 체인을 살펴보면 thumbnailBatch() 호출의 결과로 promise를 반환하는 completed 처리기가 반환되어야 하며, 해당 promise의 처리 값(체인의 다음 단계를 살펴볼 것)은 이후에 DOM에 추가할 수 있는 'img' 요소여야 합니다. 일괄 처리 '후' DOM에 이미지를 추가하여 전체 그룹을 동일한 렌더링 경로로 결합할 수 있습니다.

이것이 바로 이전 단원에서 본 batchRenderer와 multistageRenderer의 결정적인 차이점입니다. 후자의 경우 미리 보기의 'img' 요소가 이미 DOM에 있으며 loadImage에 두 번째 매개 변수로 전달됩니다. 따라서 loadImage가 이미지의 'src' 특성을 설정할 때 렌더링 업데이트가 트리거됩니다. batchRenderer 내에서는 'img' 요소가 loadImage 내에 별도로 생성되지만('src' 또한 설정됨) 'img'가 아직 DOM에 없습니다. thumbnailBatch 단계가 완료된 후에만 DOM에 추가되어 단일 레이아웃 단계 내에 있는 그룹에 속하게 됩니다.

그러면 지금부터 일괄 처리 작업이 어떻게 수행되는지 살펴보겠습니다. 다음은 완전한 createBatch 함수입니다.

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;
            });
        };
    };
}

다시 한 번 말씀 드리지만 createBatch는 '한 번만' 호출되며 목록의 '각' 렌더링된 항목마다 thumbnailBatch 결과가 호출됩니다. 그 후 loadImage 작업이 완료될 때 thumbnailBatch에서 생성하는 completed 처리기가 호출됩니다.

이러한 completed 처리기를 아주 간단하게 렌더링 함수에 직접 삽입할 수 있지만 여기서 우리가 하려는 것은 항목별 조정 작업이 아닌 '여러 항목에 걸친' 조정 작업입니다. 이 조정 작업은 createBatch 시작 부분에서 생성 및 초기화되는 두 개의 변수를 통해 수행됩니다. 하나는 빈 promise로 초기화되는 'batchedTimeout'이고, 다른 하나는 처음에는 비어 있는 여러 함수를 초기화하는 'batchedItems'입니다. createBatch 역시 completeBatch 함수를 선언하며, 이 함수는 'batchedItems'를 비우고 배열의 각 함수를 호출합니다.

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;
            });
        };
    };
}

렌더링되는 각 항목에 대해 다시 호출되는 thumbnailBatch(createBatch에서 반환되는 함수) 내에서 어떤 일이 벌어지는지 살펴봅시다. 먼저 기존 'batchedTimeout'을 '취소'하고 바로 다시 만듭니다.

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

두 번째 줄을 보면 Promises의 모든 것<TODO: link>에서 살펴본 미래의 제공/처리 패턴이 보입니다. 'waitPeriod' 밀리초(기본값은 64밀리초) 후 completeBatch를 호출하라고 합니다. 다시 말해서 이전 호출의 'waitPeriod' 내에 thumbnailBatch를 다시 호출할 경우 batchTimeout이 또 다른 waitPeriod에 대해 설정된다는 뜻입니다. 그리고 item.loadImage 호출이 완료된 '후' thumbnailBatch만 호출되기 때문에 이전 호출의 'waitPeriod' 내에 완료되는 모든 loadImage 작업이 같은 배치에 포함된다고 자신 있게 말할 수 있습니다. 'waitPeriod'보다 더 긴 간격이 있을 경우 배치가 처리되고(이미지가 DOM에 추가되고) 다음 배치가 시작됩니다.

이 시간 제한 작업을 처리한 후 thumbnailBatch가 complete 디스패처 함수를 'batchedItems' 배열에 단순히 푸시하는 새로운 promise를 생성합니다.

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

Promise의 모든 것 <TODO: link>에서 promise는 단지 코드 구조일 뿐이라고 했던 것을 기억하시기 바랍니다. 오늘 우리가 하는 모든 것이 그 연장선에 있습니다. 새로 생성된 promise는 그 자체로는 비동기 동작이 전혀 없습니다. 우리는 지금 complete 디스패처 함수 'c'를 'batchedItems'에 추가하고 있습니다. 물론 'batchedTimeout'이 비동기적으로 완료되기 전에는 디스패처에 아무 것도 하지 않습니다. 따라서 여기서는 사실상 비동기 관계가 하나 있습니다. 시간 제한이 발생하고 completeBatch 내의 배치를 비울 경우 다른 곳에서 delayedPromise.then에 제공되는 completed 처리기를 호출하게 됩니다.

그러면 thumbnailBatch의 코드 마지막 줄로 이동합니다. 이 함수는 createBatch가 실제로 반환하는 함수입니다. 이 함수는 렌더러의 전체 promise 체인에 삽입되는 바로 그 completed 처리기입니다.

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

이 코드를 promise 체인에 바로 넣어서 그 결과로 나타나는 관계를 보겠습니다.

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

이제 인수 'v'가 item.loadImage의 결과이고, 그 결과는 우리가 원하는 'img' 요소라는 것을 알 수 있습니다. 일괄 처리를 원하지 않을 경우 return WinJS.Promise.as(v)만 사용해서 체인 전체가 작동하도록 하면 됩니다. 그렇게 하면 'v'가 동기적으로 전달되어 다음 단계에서 'newimg'로 나타납니다.

그 대신 현재 'batchedTimeout'이 처리될 때까지 'v'로 처리되지 않는 delayedPromise.then에서 promise를 반환하게 됩니다. 이때 loadImage 완료 사이에 'waitPeriod' 간격이 또 있을 경우 'img' 요소가 체인의 다음 단계로 전달되어 DOM에 추가됩니다.

그것으로 끝입니다!

결론

HTML ListView 성능 최적화 샘플에서 보여 준 다섯 가지 렌더링 함수 사이에 한 가지 공통점이 있습니다. promise로 표현되는 ListView와 렌더러 간의 비동기 관계로 인해 렌더러가 매우 유연하게 언제 어떻게 목록에 있는 항목에 사용할 요소를 생성할지 알 수 있다는 점입니다. 여러분이 앱을 작성할 때 ListView 최적화에 사용하는 전략은 데이터 원본의 크기, 항목 자체의 복잡성, 해당 항목에 대해 비동기적으로 얻는 데이터의 양(예: 원격 이미지 다운로드)에 크게 좌우됩니다. 당연한 말이겠지만 여러분은 원하는 성능에 도달할 때까지 항목 렌더러를 최대한 단순하게 유지하고 싶을 것입니다. 이제는 어떤 경우에도 ListView와 여러분의 앱이 최고의 성능을 발휘하도록 도와 주는 도구가 준비되어 있습니다.

Kraig Brockschmidt
Windows 에코시스템 팀 프로그램 관리자
작성자, HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍하기

게임은 Windows 스토어 앱의 핵심 분야입니다. Windows 스토어용 게임 앱 개발을 생각하고 있다면 지금 소개할 온라인 게임 개발 이벤트가 도움이 될 것입니다. 이 이벤트는 무료이며 초보 게임 개발자와 전문가 모두에게 개방되어 있습니다.

YoYo Games의 GameMaker: Studio를 이용하여 더 빠른 시간 내에 고품질의 게임을 개발하고 게시하는 방법을 소개하겠습니다. GameMaker:Studio에는 다양하고 훌륭한 기본 디자인 옵션과 끌어서 놓기 도구가 있어서 아직 구체적인 게임 아이디어가 없거나 개발 경험이 없는 분도 쉽게 앱 개발을 시작할 수 있습니다. 하지만 게임 앱 개발 경험이 있는 개발자라면 고급 도구를 활용하는 것이 세상에 단 하나밖에 없는 게임 환경을 개발하는 데 도움이 될 것입니다.

이번 온라인 이벤트는 6월 15일 오전 10시(태평양 연안 표준시)부터 온라인 강의와 라이브 채팅으로 진행됩니다. 이 기회를 통해 여러분은 독창적인 게임을 개발하는 방법뿐만 아니라 다양한 게임 유형 및 기본 게임에 그래픽과 레벨, 소리를 추가하는 방법에 대해서도 배울 수 있습니다. GameMaker 포럼에서 이번 한 주간 내내 일대일 지원을 제공해 드립니다.

이번 이벤트는 학생이나 초보 개발자 또는 노련한 전문가 모두에게 스토어용 게임을 개발하고 업로드하여 Windows 스토어에 게시하는 데 도움이 될 것입니다. http://msdnevents.com/gameon/에서 자세한 사항을 확인할 수 있으며 이벤트에 등록할 수 있습니다. 무료 도구와 리소스도 확인하십시오.

- Windows 개발자 콘텐츠, 수석 콘텐츠 게시 관리자, Robert Rodriguez-Lawson

아직도 Windows 스토어 앱에서 사용 가능한 자격 증명 보관에 대해서 들어본 적이 없으십니까? 그렇다면 이 글을 꼭 보셔야 합니다. 왜냐하면 자격 증명 보관을 이용하면 사용자 자격 증명의 저장 및 검색 작업이 간편해질 뿐만 아니라 자격 증명을 안전하게 저장할 수 있기 때문입니다. 또한 사용자는 자격 증명을 '무료로' Microsoft 계정과 로밍할 수도 있습니다.

여러분이 미디어 파일이나 소셜 네트워킹과 같은 보호된 리소스에 액세스하는 서비스를 제공하는 앱을 개발했다고 생각해 봅시다. 서비스 이용을 위해서는 각 사용자의 로그인 정보가 필요합니다. 그래서 여러분은 사용자가 서비스에 로그인할 수 있도록 앱에 사용자 이름과 암호를 입력할 수 있는 UI를 개발할 것이고 특별히 문제는 없습니다.

하지만 여러분은 사용자들에게 좀 더 나은 서비스를 제공하고 싶고 사용자들이 앱을 사용할 때마다 로그인 정보를 입력하지 않아도 되도록 로그인 정보를 안전하게 저장할 수 있기를 원합니다. 그렇다면 바로 자격 증명 보관이 필요합니다. 간단한 자격 증명 보관 API 호출로 사용자 이름과 암호를 저장하고 손쉽게 검색할 수 있으며 사용자가 다음에 앱을 사용할 때 자동으로 로그인할 수 있습니다.

안전한 저장소

자격 증명 보관을 앱에 적용했을 때 가장 좋은 점은 사용자 자격 증명이 안전한 위치에 저장되며 디스크에 저장할 때는 자격 증명 정보가 암호화된다는 점입니다. 물론 여러분의 앱에 대한 사용자 자격 증명을 로컬 저장소에 있는 파일에 저장할 수도 있습니다. 하지만 사용자 자격 증명을 일반 텍스트로 저장하면 보안에 상당한 위험이 생길 수 있습니다. 어떤 사용자의 시스템이 침해되면 그 사용자의 사용자 이름과 암호가 쉽게 액세스되고 도용당할 수 있습니다. 하지만 사용자 이름과 암호를 자격 증명 보관을 이용해 저장하면 악성 소스가 침투하기 쉬운 파일은 암호화됩니다.

자격 증명 보관은 각각의 Windows PC 사용자에게만 고유하게 적용되며 자격 증명에 액세스하는 것은 자격 증명을 저장한 앱에서만 가능합니다. 즉 여러분은 여러분의 앱에 저장한 자격 증명만 검색할 수 있으며, 마찬가지로 다른 앱에서는 여러분의 앱 보관소에 저장된 자격 증명에 접근할 수 없습니다.

자격 증명 로밍

사용자를 위한 새로운 혜택으로, 여러분이 자격 증명 보관을 이용하여 사용자 이름과 암호를 저장하면 사용자는 신뢰할 수 있는 컴퓨터 어디에서나 저장된 자격 증명을 Microsoft 계정과 로밍할 수 있습니다. 이 기능을 이용하면 앱의 보안을 유지하면서도 사용자들이 앱을 더 편리하게 이용할 수 있습니다. 앱이 설치되어 있고 Microsoft 계정이 연결되어 있다면 자격 증명을 다시 확인하지 않아도 신뢰할 수 있는 모든 컴퓨터에서 자동으로 앱에 로그인할 수 있기 때문입니다.

하지만 도메인 계정에서는 조금 다르게 작동합니다. Microsoft 계정으로 자격 증명이 저장된 경우, 이 계정이 도메인 계정(예를 들면, 직장에서 사용하는 계정)과 연결되어 있다면 자격 증명은 그 도메인 계정과 로밍될 수 있습니다. 하지만 도메인 계정에 로그인했을 때 새로 추가된 자격 증명이 있으면 로밍되지 않습니다. 도메인의 개인 자격 증명이 도메인 외부에 노출되는 것을 방지하기 위한 것입니다.

사용자 자격 증명 저장

사용자 자격 증명을 자격 증명 보관으로 저장하는 것은 두 단계로 아주 간단합니다. 먼저 Windows.Security.Credentials 네임스페이스에서 PasswordVault 개체를 사용하여 자격 증명 보관에 대한 참조를 가져옵니다. 그리고 앱의 식별자, 사용자 이름 및 암호를 포함하는 PasswordCredential 개체를 만들어, 이 개체를 자격 증명을 보관소에 추가하기 위한 PasswordVault.Add() 메서드로 보냅니다.

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));

사용자 자격 증명 검색

PasswordVault 개체에 대한 참조를 가져온 후에는 다음과 같은 몇 가지 방법으로 자격 증명 보관에서 자격 증명을 검색할 수 있습니다.

• 사용자가 보관소의 앱에 제공한 모든 자격 증명을 PasswordVault.RetrieveAll() 메서드를 이용하여 검색할 수 있습니다.
• 저장된 자격 증명의 사용자 이름을 알고 있다면 PasswordVault.FindAllByUserName() 메서드를 이용하여 그 사용자 이름에 대한 모든 자격 증명을 검색할 수 있습니다.
• 저장된 자격 증명의 리소스 이름을 알고 있다면 PasswordVault.FindAllByUserName() 메서드를 이용하여 그 리소스 이름에 대한 모든 자격 증명을 검색할 수 있습니다.
• 마지막으로 자격 증명의 사용자 이름과 리소스 이름을 모두 알고 있다면 PasswordVault.Retrieve() 메서드를 이용하여 바로 그 자격 증명을 검색할 수 있습니다.

리소스 이름을 전체적으로 저장해 놓은 앱에서 사용자의 자격 증명을 찾았을 때 자동으로 사용자가 로그인할 수 있는 예시를 살펴보겠습니다. 한 사용자당 여러 개의 자격 증명이 있을 경우 우리는 사용자에게 로그인 시 기본으로 사용할 자격 증명을 선택하도록 요청하고 있습니다.

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;
}

사용자 자격 증명 삭제

사용자 자격 증명을 자격 증명 보관에서 삭제하는 것 역시 두 단계로 아주 간단합니다. 마찬가지로 Windows.Security.Credentials 네임스페이스에서 PasswordVault 개체를 사용하여 자격 증명 보관에 대한 참조를 가져옵니다. 그리고 삭제하려는 자격 증명을 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));

간편하고 안전함

앞서 살펴보았듯이 자격 증명 보관은 사용자 인증 작업은 물론, 이후에도 지속적으로 편리하게 로그인할 수 있도록 사용자 자격 증명을 저장하는 작업까지 간단하게 할 수 있는 손쉬운 기능입니다. 그리고 이 모든 과정이 아주 안전한 방식으로 이루어집니다.

Windows 8 앱 인증과 관련한 다른 주제로, OAuth와 같은 웹 사이트에서 인증 토큰을 검색하고 사용자의 Microsoft 계정을 기반으로 앱을 개인 설정할 수 있는 웹 인증 브로커도 있습니다.

기타 자세한 내용은 다음을 참조하십시오.

• 사용자 정보 관리(JavaScript)
• 사용자 정보 관리(C#/VB/C++ 및 XAML을 사용한 Windows 스토어 앱)
• 자격 증명 보관 샘플
• Windows.Security.Credentials

- Windows 개발자 콘텐츠, 수석 콘텐츠 개발자, Doug Rothaus

이 블로그 글을 작성하는 데 도움을 준 Yashar Bahman에게 특별히 감사드립니다.

여러분이 개발한 앱의 비즈니스 논리와 사용자 위치 정보가 연동되면 여러분은 앱 사용자들에게 그들의 현재 위치에 맞는 날씨, 쿠폰, 스포츠 행사 또는 콘서트 목록을 간편하게 제공할 수 있습니다. 여러분은 Windows 8의 지리적 위치 기능과 Bing Maps SDK를 사용하여 위치 인식 Windows 스토어 앱을 만들 수 있습니다.

여러분의 앱에서 IP 주소, WiFi 네트워크 또는 GPS 데이터를 가지고 위치 서비스를 통해 사용자에게 위치에 따른 특정 정보를 제공하는 방법을 알아보겠습니다. 위치 정보가 있다면 Bing Maps SDK를 사용해서 사용자가 자신의 위치를 확인하도록 만들 수 있습니다.

위치 검색

Windows.Devices.Geolocation 네임스페이스로 사용자 위치를 검색할 수 있습니다. 사용자 위치를 검색하기 위해 GPS, WiFi 네트워크, IP 주소 중 어떤 것을 사용할지는 다음과 같은 두 가지 주요 요인에 따라 달라집니다.

1. 요구되는 정확도 수준: 여러분의 앱에서 필요로 하는 기준을 충족하는 이상적인 정확도입니다.
2. 위치 데이터 사용 가능성: 모든 장치에 GPS가 내장되어 있지는 않으며 위치 정보를 요청할 때 네트워크 또는 Wi-Fi 연결을 사용하지 못할 수도 있습니다.

원하는 정확도

위치 정보를 요청하는 경우, 사용자의 앱에서 원하는 정확도를 지정하면 지정된 범위 내에서 위치 정보가 신속하게 반환됩니다. 위치 정보 유형에 따라 정확도도 다릅니다.

• GPS – GPS의 오차 범위는 10m 이내로 정확도는 가장 높지만 GPS 센서를 '켜고' 위성 데이터를 수신 및 삼각 측량하여 자세한 위치 정보를 반환하려면 1~2분 정도의 시간이 걸릴 수 있습니다. 하지만 GPS의 위성 연결이 이루어지고 나면 이후의 위치 정보는 더 빨리 수신할 수 있습니다. 물론 GPS를 많이 사용할수록 전력 소비는 늘어나며 Geolocator.DesiredAccuracy 속성을 High로 설정해야 GPS에서 정보를 수신할 수 있습니다.
• Wi-Fi – Wi-Fi 연결의 오차 범위는 300m~500m입니다. 연결이 유지되는 동안은 GPS가 위성에 연결해서 데이터를 수신하는 것보다 더 빠르게 위치 데이터를 반환할 수 있습니다. Wi-Fi를 통해 위치 정보를 수신하려면 DesiredAccuracy 속성을 Default로 설정해야 합니다.
• IP 주소 – IP의 오차 범위는 1km 이하입니다. 네트워크 연결이 지속되는 동안에는 GPS가 위성에 연결해서 데이터를 수신하는 것보다 더 빠르게 위치 데이터를 반환할 수 있습니다. IP를 통해 위치 정보를 수신하려는 경우에도 DesiredAccuracy 속성을 Default로 설정합니다. 위치 서비스는 반환할 수 있는 최고의 정확도로 반환합니다. 반환된 정확도의 수준은 Geocoordinate.Accuracy 속성에서 확인할 수 있습니다.

앱의 성능과 전력 소비에 영향을 줄 수 있으니 원하는 정확도 값을 신중하게 생각하여 정하십시오. 예를 들어, 여러분의 앱이 날씨 예보 서비스를 제공하는 앱이라면 GPS 수준의 높은 정확도는 필요하지 않습니다. 또한 반환된 데이터의 정확도를 기반으로 오류 반경을 표시함으로써 사용자 데이터의 정확도를 나타내야 합니다. 아래는 여러분이 원하는 정확도를 설정할 수 있는 C# 코드입니다.

C#

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

C#

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

Geolocator 클래스의 인스턴스를 만들고 원하는 정확도를 설정하여 현재 위치를 수신할 수 있는 JavaScript 코드입니다. 아래의 'promise' 변수는 WinJS.Promise 개체라는 것을 유의하십시오. done 메서드를 사용해서 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();

Bing 지도

Bing 지도 앱은 사용 가능한 위치 데이터의 정확도를 조정하는 앱의 좋은 예입니다. 일반적으로 GPS나 Wi-Fi를 사용하지 않는 데스크톱 PC인 경우에는 IP 주소를 기반으로 위치를 찾고 지도에서 현재 위치를 지역 수준으로 확대해서 표시합니다. 일반적으로 무선 LAN 카드가 설치되어 있는 랩톱의 경우에는 Wi-Fi를 사용해서 보다 정확한 위치를 찾고 더 자세한 수준으로 확대해서 표시합니다. 사용자가 그보다 더 자세한 수준으로 확대하려고 하면 현재 위치 아이콘에서 오류 반경이 표시됩니다. GPS가 탑재된 장치의 경우에는 Bing 지도에서 GPS를 통해 정확도가 높은 위치 데이터를 수신하여 더 자세한 위치를 표시합니다.

Bing 날씨

위에서 언급했듯이 Bing 날씨 앱 같은 앱에는 지역 수준의 정보만 제공해도 되기 때문에 신속하게 위치 값을 반환할 수 있도록 필요한 정확도를 낮게 지정할 수 있습니다. 이러한 설정으로 앱은 사용자에게 더욱 빠르게 반응할 수 있습니다. 이와 같이 지역 수준의 위치 정보만 제공해도 되는 앱으로는 라디오 방송국 가이드, 특가 상품 쇼핑, 지역 뉴스 피드 등의 앱이 있습니다.

Bing Maps SDK로 위치 데이터 표시

사용자의 GetGeopositionAsync호출에서 얻은 위치 정보를 지도상에서 확인할 수 있습니다.

• 우선 다음 코드를 사용해서 Geoposition을 Bing 지도에서 사용할 수 있는 Location으로 변환합니다.

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.
  });

• 그리고 Bing 지도를 사용하여 사용자의 위치를 표시합니다. Bing Maps SDK는 여기에서 다운로드할 수 있습니다. Bing 지도 키는 Bing 지도 포털에 등록하고 Bing 지도 키 얻기의 지침에 따라 얻을 수 있습니다. 등록할 때는 키 유형별 사용 제한사항을 확인하고 여러분의 앱에 적합한 키를 고르시기 바랍니다.
  디자이너에 Bing 지도 컨트롤을 추가하고 자격 증명에 해당 키를 삽입하십시오.

<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>

• 이제 여러분의 앱에서 지도가 표시될 페이지에 해당 코드를 적용할 수 있습니다. 해당 코드는 지도의 확대 수준을 설정하고 위치를 표시합니다. 확대 수준에 대한 자세한 내용은 Bing 지도에 위치를 표시하는 방법을 참조하시기 바랍니다.

C#

double zoomLevel = 13.0f;

Map.SetView(location, zoomLevel);

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

그리고 액세스할 수 있게 ID 특성 값을 설정하여 지도가 들어가도록 <div> 태그를 만듭니다.

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

마지막으로 HTML 페이지의 지도 컨트롤을 초기화합니다. 다음은 이에 해당되는 JavaScript의 코드입니다.

// 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
  });
}

• 마지막으로, 위치 정보를 사용하는 앱에서는 사용자 권한 설정을 준수하고 언제든지 사용자 권한 설정을 변경할 수 있어야 합니다. 예를 들어, 날씨 앱에서는 현재 위치의 날씨 정보를 얻기 위해 날씨 정보를 활용하지만 언제든지 사용자가 설정에서 위치 권한을 취소할 수도 있습니다. 앱에서 위치 권한을 사용할 수 없는 경우에 대해서도 항상 처리할 수 있어야 합니다. 이와 같은 경우에, 날씨 앱에서는 "사용자의 위치를 찾을 수 없습니다. 날씨 앱에서 사용자의 위치를 찾을 수 있게 권한을 변경해 주십시오."라는 메시지가 나타납니다. 위치 권한 처리 관련 예제는 위치 인식 앱에 대한 지침의 사용자 환경 지침을 참조하십시오.
  

지리적 위치 및 Bing Maps SDK 사용에 대한 자세한 내용은 새롭게 선보이는 동영상과 How to 항목, 그리고 사용자 위치를 비동기 방식으로 얻고 Bing Maps SDK를 통해 시각적으로 표시하는 방법을 단계적으로 안내하는 코드 샘플을 참조하십시오. 동영상, How to 항목, 샘플 가이드에서 위치 기능 활성화, 비동기 방식으로 위치 수신, 특정 지역으로 지도 설정, 위치 정보 정확도 기반 위치 아이콘 설정 등의 방법을 확인할 수 있습니다. Windows 스토어 앱용 Bing 지도에서도 자세한 내용을 확인할 수 있습니다.

결론

위치 기능은 강력하고도 시간 절약에 도움이 되는 기능으로 여러분의 앱에 추가할 만합니다. 여러분은 사용자에게 그들이 있는 위치에 대해 보다 적합한 정보를 제공할 수 있으며, 지역 라디오 방송국 목록, 특가 상품 쇼핑, 교통 정보, 날씨 정보 등 어떤 것이든 상관없이 위치에 따른 맞춤형 정보를 제공할 수 있으므로 여러분의 앱이 더욱 유용해집니다. 앱을 굳이 조작하지 않아도 자동으로 맞춤형 정보를 제공하는 이 기능은 시간을 절약해 주기 때문에 사용자들이 여러분의 앱을 더욱 더 선호하게 될 것입니다.

- Windows 개발자 콘텐츠, 수석 콘텐츠 개발자, Rose Heise

   특별히 이 블로그 글을 작성하는 데 도움을 준 Jon Kay와 Eric Schmidt에게 특별히 감사드립니다.

저희는 2011년 10월 Windows 개발자 센터를 시작한 이후로 전 세계의 개발자, 디자이너들과 함께 긴밀히 작업하면서 앱 작성자들에게 지침을 제공하고, 영감을 불어넣으며, 샘플을 제공할 수 있는 최선의 방법에 대해 논의했습니다. 수백만 명의 방문자들과 여러분의 의견을 토대로 어떤 것이 잘 되고 있고 어떤 경험을 개선할 수 있는지를 평가하고 있습니다.

새로운 소식

Windows 팀은 생생하고 풍부한 앱 에코시스템 개발에 심혈을 기울이고 있습니다. 이러한 노력은 훌륭한 앱, 최고의 경제성, 풍부한 기회 제공이라는 세 가지 모습으로 나타납니다. 새로운 개발자 센터는 Windows를 통해 훌륭한 앱을 개발하고 비즈니스를 구축하는 데 필요한 리소스를 앱 작성자, 디자이너, 비즈니스에 제공합니다.

개발자 센터는 이를 지원하기 위해 다음과 같은 영역에서 발전을 거듭하고 있습니다.

1. 탐색 모델이 앱 개발 수명 주기에서 현재 작업이 진행되고 있는 부분에 필요한 콘텐츠를 찾을 수 있도록 변경되었습니다.
2. 사이트 디자인에서 최상위 작업, 시나리오 및 새 콘텐츠를 강조합니다.

개발자가 원하는 콘텐츠, 샘플, 다운로드뿐만 아니라 디자이너와 비즈니스에 필요한 리소스에 손쉽게 액세스할 수 있게 되었습니다.

어떤 앱을 작성하느냐에 따라 Windows 스토어 앱, Internet Explorer, Windows 데스크톱 및 하드웨어 등 네 가지 영역 중 탐색할 영역이 결정됩니다. 각 영역에서 여러분은 위에서 언급한 사항이 반영된 새로운 경험을 할 수 있습니다. 이 글에서는 Windows 스토어 앱에서 이루어진 특정 변경 사항에 대해 자세히 살펴보겠습니다.

역할에 적합한 콘텐츠

정보가 방대한 웹 사이트라도 사용자가 원하는 정보를 찾지 못하면 유용하다고 할 수 없습니다. 수백, 수천 가지 항목을 제공하는 개발자 센터에서 콘텐츠 구성 및 검색 기능은 매우 중요한 요소입니다. Windows 스토어 앱 개발의 경우 디자이너와 비즈니스를 더욱 효율적으로 지원할 수 있도록 하기 위해 개발을 시작하는 데 필요한 모든 것들을 한곳에 모아 놓는 것부터 역할 및 시나리오별로 세밀하게 집중해야 합니다. 다음은 주요 변경 사항입니다.

개발자

훌륭한 Windows 스토어 앱을 만드는 데 필요한 콘텐츠를 간소화했습니다. Windows 스토어 앱 홈 페이지로 이동하면 다음 항목을 확인할 수 있습니다.

• 필요한 콘텐츠로 바로 이동할 수 있도록 "주요 작업 및 콘텐츠"를 배치했습니다. 사용자의 지역에 해당하는 지역 이벤트와 사이트에 방금 추가된 새로운 리소스가 강조 표시됩니다.
• 코딩을 바로 시작할 수 있는 다운로드 및 시작하는 데 필요한 모든 리소스, 앱을 Windows 스토어에 배치하는 데 도움이 되는 자세한 지침이 제공됩니다.
• 중요한 코드 샘플이 강조 표시되며 개발 주기에 대해 한눈에 쉽게 파악할 수 있는 방법 지침이 제공됩니다.
• 사이트 전체에서 제공되는 "One Dev Minute" 비디오는 앱에 기능을 추가하는 방법에 대해서 간략하게 설명합니다.

디자이너

더욱 다양한 콘텐츠를 제공하며 이 콘텐츠를 쉽게 사용할 수 있도록 사이트의 디자인 섹션을 점검했습니다. 이 사이트에서 유용한 다운로드와 다시 사용할 수 있는 디자인 자산을 더욱 손쉽게 찾아볼 수 있으며, 디자인 영감 및 사례 연구에서는 Windows에 대한 고유한 경험을 만드는 데 필요한 도구를 제공합니다. 터치 및 사용이 간편하게 페이지를 디자인하여 시선을 사로잡는 앱을 만드는 데 필요한 모든 것을 바로 얻을 수 있습니다.

비즈니스

Windows 스토어에서는 경쟁력 있는 플랫폼에서 개선된 경제적 모델과 여러분이 원하는 비즈니스를 구축할 수 있는 유연성을 갖춘 중요한 비즈니스 기회를 제공합니다. 사이트의 새로운 시장 섹션에서는 앱을 마케팅하고, 원격 분석 데이터를 평가하고, 앱 인증에 통과하는 데 도움이 되는 훌륭한 팁을 제공합니다. 더욱 쉽게 인증을 받을 수 있는 다양한 방법을 제공하고 있으며 이를 위한 프로세스를 모두 소화해 낼 수 있도록 콘텐츠를 개선했습니다.

여러 가지 역할을 동시에 수행하는 분들에게도 새로운 사이트 구성이 도움이 될 것으로 기대합니다. 새롭게 구성된 사이트를 통해 취미로 앱을 만드는 분에서 광고 회사, 대기업 소프트웨어 개발자들에 이르는 많은 분들이 Windows를 통해 창의적인 사업 비전을 성취할 수 있기를 희망합니다.

여러분의 참여가 더 나은 결과를 만듭니다.

BUILD 2013이 출시되고 한 달이 조금 넘은 시점에서 논의해야 할 것들이 많습니다. 올해 이벤트에서 많은 항목을 공유할 수 있도록 새로운 콘텐츠를 열심히 만들고 있습니다. 이 블로그 글을 읽는 것 외에도 Twitter에서 @windevs를 팔로우하고 Windows 스토어 뉴스레터를 구독하는 등 여러 가지 방법으로 최근 소식을 접할 수 있습니다.

저희는 Windows 스토어 앱을 디자인하고, 개발하고, 마케팅하는 데 도움이 되는 다양한 콘텐츠를 제공하고 있습니다. 이런 콘텐츠를 통해 여러분이 좀 더 나은 개발자 센터 경험을 할 수 있게 되었으면 합니다. 여러분의 의견을 언제든 공유할 수 있도록 모든 페이지 하단에 새로운 피드백 옵션 두 가지를 제공하고 있습니다. 여러분의 의견을 보내 주세요. 여러분이 고민하는 사항을 해결할 수 있도록 항상 노력하겠습니다.

Windows 개발자 콘텐츠, 콘텐츠 게시 관리자, Keith Boyd

앱을 통한 공유에서는 Food with Friends 앱을 예로 들어 이 앱에서 여러 대상 앱으로 콘텐츠를 공유하여 풍부한 전체 시나리오를 수행할 수 있는 아이디어를 소개했습니다. Windows 8의 앱은 여러분의 고객이 친구나 다른 앱과 공유하고 싶어할 만한 흥미로운 콘텐츠를 제공합니다. 흥미롭고 잘 디자인된 공유 대상을 활용하면 여러분의 앱은 고객들이 많이 연결된 소셜 네트워킹의 중심이 될 수 있습니다.

이 글에서는 Food with Friends와 같은 앱에 대상 공유 계약을 사용하는 방법에 대해 알아봅니다. 이 계약을 통해 앱에서 다른 앱의 '콘텐츠를 받고' 이 콘텐츠를 사용하여 품질을 높일 수 있습니다. 여러분의 앱이 해당 범주에서 최고의 앱이 될 수 있게 도와드리겠습니다.

대상 앱은 대상 공유 계약을 사용하여 만들 수 있고, 쉽고 빠른 공유 환경을 제공합니다. Windows의 모든 앱이 공유 대상이 될 수 있는 것은 아니지만 자신의 앱에서 다른 앱을 통해 받은 콘텐츠를 게시, 변환, 저장하거나 약간의 가치를 더할 수 있다면 앱을 공유 대상으로 만드는 데 다음과 같은 이점이 있습니다.

• 자신의 앱이 항상 대상 앱 목록에 표시됩니다. 따라서 다른 앱과 즉시 관련을 맺고 연결되어 원하는 데이터를 공유할 수 있습니다.
• 공유 계약으로 본인의 앱과 다른 원본 앱이 연결되므로 양쪽 앱을 일 대 일로 통합할 필요가 없습니다.
• OS에 항상 공유 참 메뉴가 표시되어 사용 가능하므로 대상 앱을 OS에서 확인할 수 있어 앱의 기능 범위가 확대됩니다. 이는 더 많은 고객을 자신의 앱으로 끌어올 수 있는 잠재적인 요소가 됩니다.

공유 콘텐츠 수신

공유 대상 앱을 통해 흥미로운 경험을 제공할 수 있는 몇 가지 예를 살펴보겠습니다.

Windows 8의 메일 앱과 피플 앱은 이미 익숙할 것입니다. 메일 앱은 콘텐츠를 받아서 여러 친구들과 공유할 수 있는 쉽고도 개인적인 공유 대상 경험을 제공합니다. 피플 앱을 통해서는 소셜 네트워크상의 많은 사용자들과 콘텐츠를 공유할 수 있으며, 소셜 공유 외에도 앱 간 공유를 통해 보다 앞서 나갈 수 있습니다. SkyDrive와 같은 생산성 앱은 Windows상의 어떤 파일이든 받아 클라우드에 저장할 수 있습니다. 메모 앱은 텍스트, 링크 및 다양한 형식의 데이터를 받아 나중에 참조하도록 보관할 수 있으며 창의력도 마음껏 발휘할 수 있습니다.

사진 앱에서 사진을 시각 퍼즐로 바꾸는 게임 앱인 PuzzleTouch로 사진을 공유할 때 공유 흐름이 어떻게 진행되는지 아래 두 그림을 살펴보십시오.

그림 1: 왼쪽에는 원본 앱이 있고 오른쪽의 공유 창에는 사진을 받을 수 있는 필터링된 대상 앱의 목록이 있습니다.
PuzzleTouch는 사진 앱에서 사진을 받을 수 있는 공유 대상 중 하나입니다.

그림 2: 오른쪽에 있는 앱 다운로드 알림을 통해 어떤 유형의 퍼즐을 만들지 선택할 수
있습니다. 사용자가 앱으로 전환하면 퍼즐이 표시됩니다.

공유 대상 앱이란?

Windows의 전체 공유 환경은 두 가지 요소로 구성됩니다. Windows에서 콘텐츠를 다양한 형식으로 사용할 수 있는 원본 앱이 있고, 또한 특정 형식을 인식하도록 등록되어 있으면서 공유되는 콘텐츠의 대상 역할을 하는 공유 대상 앱이 있습니다. 원본 앱과 공유 대상 앱은 공유 계약을 통해 서로 통신합니다.

앱의 공유 환경을 위해서는 공유 대상 앱이 호스팅된 공유 창에서 렌더링된다는 것을 고려해야 합니다. 사용자가 이러한 보기에서 콘텐츠를 간단히 미리 보고 공유를 확인할 수 있도록 공유 환경을 구축하십시오. 다음 예는 사용자가 브라우저의 링크를 메일 연락처에 있는 사람과 간단히 공유할 수 있는 메일 공유 대상 앱 보기입니다.

그림 3: 메일 대상 앱을 사용하여 사진 앱의 링크 공유

Food with Friends를 위한 시나리오

이제 Food with Friends에서 어떻게 흥미로운 공유 대상 앱 경험을 만들어 내는지 알아보겠습니다. 이 앱에 익숙한 개발자라면 Food with Friends에서 사용자가 주로 수행하는 작업은 '계획 만들기'와 'My Wishlist에 음식점 추가'라는 것을 알 것입니다. 물론 후기 쓰기, 의견 올리기, 친구의 Wishlist 보기 등과 같은 다른 작업도 있지만 이러한 작업은 메인 앱의 컨텍스트 내에서 수행하는 것이 적절합니다. Food with Friends 대상 앱을 통해 핵심 시나리오 두 가지를 효과적으로 완료할 수 있는지 확인하기 위해 간단한 무결성 검사를 해보도록 하겠습니다.

오늘 저녁 계획 만들기

이것은 메인 앱의 핵심 시나리오이지만 공유 대상 경험을 위한 최상의 시나리오는 아닙니다. 왜냐하면 공유 대상 경험은 쉽고 빨라야 하기 때문입니다. 계획을 만들 때는 친구들이 가고 싶어하는 음식점을 알아보고, 친구들의 Wishlist에서 몇몇 음식점을 비교하고, 평가를 검토하는 등 거쳐야 할 작업이 많습니다. 계획을 세우려면 메인 앱 보기에 자세히 나와 있는 세부 정보를 참조해야 하므로 이러한 기능을 공유 대상 앱에 요약하는 것은 그리 좋은 생각이 아닙니다.

Wishlist에 추가

이 시나리오는 공유 대상에서 짧고 통제된 작업으로 원활하게 작동합니다. 이 앱 경험의 주요 내용은 다음과 같습니다.

• 사람들이 후기, 음식 블로그 등이 있는 여행 계획 앱이나 국내 도시 앱 같은 다른 앱을 통해 음식점을 발견합니다. Food with Friends는 ‘My Wishlist’ 섹션에 음식점을 정리하기 때문에 매우 유용한 대상입니다.
• 앱의 대상 앱 보기는 다른 앱의 컨텍스트에 있으면서도 빠르게 작업을 수행할 수 있어야 합니다. 따라서 Wishlist에 음식점을 추가하는 옵션은 공유 대상에 표시하기에 매우 좋습니다.
• 물론 사용자가 앱을 전환하고 다시 검색해서 음식점을 찾은 후 Wishlist에 음식점을 추가할 수는 있지만 공유를 간단히 탭하는 것이 훨씬 더 편리합니다.

Food with Friends Wishlist는 적절한 공유 대상 앱 경험으로 보이므로 여기에서는 이 공유 대상 앱 경험을 디자인하고 빌드하려고 합니다. 우리가 염두에 둔 전체 시나리오는 이렇습니다.

가까운 푸드 트럭을 찾아 주는 앱을 탐색하다가 흥미로운 푸드 트럭 후기를 찾습니다. 나중에 계획을 세울 때 참조할 수 있게 이 앱에서 Food with Friends의 My Wishlist로 푸드 트럭을 추가하려고 합니다.

그림 4: 가까운 푸드 트럭을 찾아 주고 명소를 추천하는 앱 탐색

이 이미지는 우리가 사용하려는 공유 대상 앱 보기입니다.

그림 5: 공유 대상 앱 보기

사용자는 대상 앱 보기에서 공유 작업을 완료하여 현재의 몰입형 앱 경험에서 컨텍스트를 전환하지 않고 Food with Friends에 음식점을 정리할 수 있습니다.

공유 대상 구현

공유 대상을 구현해야 하는 경우에 대한 몇 가지 예를 살펴보았으므로 이제 공유 대상을 구현하는 방법을 알아보겠습니다. 먼저 앱에서 받을 수 있는 데이터 형식이 무엇일지 정합니다.

어떤 데이터 형식을 지원해야 할까요?

공유를 사용하면 텍스트, URI, HTML, 비트맵, 파일 같은 표준 데이터 형식이나 http://schema.org에 나와 있는 사용자 지정 데이터 형식을 지원할 수 있습니다. Windows는 지원되는 데이터 형식으로 대상 앱을 필터링하여 공유 창에 필터링된 대상 앱 목록을 표시합니다. 앱은 앱 경험에 중요한 데이터 형식을 지원해야 합니다. 예를 들어, 사진을 보는 데 사용되는 앱은 텍스트 형식을 지원할 필요가 없습니다. 여러 데이터 형식을 지원한다고 선언한 경우 데이터 패키지에서 우선적으로 선택할 수 있도록 공유 데이터를 가장 잘 나타내는 형식을 결정해야 합니다.

Food with Friends는 사용자가 앱에 음식점을 공유하도록 지원하는 공유 대상 경험을 구현하고 있으므로 http://schema.org에 나와 있는 Restaurant 데이터 형식을 사용할 것입니다. Food with Friends는 대상 공유 계약에 등록하여 이러한 데이터 형식을 받을 수 있습니다. 그런 다음 받은 패키지의 데이터를 사용하여 대상 앱 보기에 사용자가 Wishlist에 음식점을 추가할 수 있는 멋진 경험을 구현할 수 있습니다.

원본 앱은 Restaurant 데이터 형식을 정확히 공유하는 경우도 있고, schema.org에 나와 있는 Place, LocalBusiness 및 FoodEstablishment와 같은 다른 데이터 형식을 사용하여 유사한 정보를 표현하는 경우도 있습니다. 따라서 Food with Friends는 공유 계약에 여러 형식을 수신하여 보다 광범위한 원본 앱에 제공할 수 있도록 지원합니다.

Food with Friends는 앱 매니페스트의 공유 대상 선언에 다음과 같은 형식을 지원합니다.

• Restaurant
• Place
• LocalBusiness
• FoodEstablishment

이 글에서는 편의상 Restaurant 데이터 형식을 주로 다루고 있지만 다른 데이터 형식도 개념은 비슷합니다.

어떤 데이터 형식과 시나리오를 자세히 살펴보아야 할까요?

Food with Friends는 앱이 이미 알고 있는 음식점과 일치하는 음식점 정보가 수신될 경우에만 사용자의 Wishlist에 음식점을 추가하도록 지원합니다. 앱에 중복된 음식점 정보가 생기지 않게 하기 위해서입니다.

표준 데이터 형식은 지원되지 않습니다. 원본 앱에서 공유되는 대부분의 텍스트, 파일, 사진, URI 또는 HTML은 음식점이나 지역 사업소에 매핑되지 않기 때문입니다. 예를 들어 Food with Friends가 텍스트 수신을 지원할 경우 메모 원본 앱의 대상 앱 목록에 나타납니다. 이 경우 Food With Friends는 사용자에게 해당 원본 앱과 이 앱이 연동되지 않는 이유를 설명하는 오류 메시지를 제공해야 합니다. 요점은 데이터 형식을 통해 대상 앱에 무언가를 제공하는 원본 앱이 연결된다는 것입니다. 데이터 형식이 다르면 공유할 만한 가치가 없습니다.

관심 있는 사항을 알아볼 때 도움이 되는 데이터 형식과 공유 경험을 방해할 만한 데이터 형식을 모두 자세히 살펴보십시오.

대상 공유 계약 지원

데이터 형식을 지원하려면 Visual Studio 매니페스트 디자이너에서 앱에 해당 데이터 형식을 선언하십시오. 사용자가 여러분의 앱을 공유 작업의 대상으로 선택할 경우 다음과 같은 작업이 수행됩니다.

1. 원본 앱을 통해 대상 공유 창에 앱의 새 인스턴스가 열립니다.
2. share target activation 이벤트가 실행되고 앱이 ShareOperation 개체를 결과로 받습니다.
3. 이 개체를 통해 사용자가 공유한 데이터를 검색할 수 있습니다.
4. 이 데이터를 사용하여 대상 앱 보기를 렌더링하고 사용자의 공유를 완료할 수 있습니다.

이 경험을 만드는 방법에 대한 자세한 내용은 공유 콘텐츠 받기 빠른 시작 가이드를 참조하십시오.

또한 Visual Studio는 공유 대상을 위한 템플릿을 지원합니다. 해당 프로젝트를 마우스 오른쪽 단추로 클릭하고 항목 추가, 새 항목 추가를 선택한 후 목록에서 대상 공유 계약을 클릭한 다음 계약을 지원하기 위해 추가된 코드를 확인합니다. 공유 대상 코드 샘플에 공유 콘텐츠를 받는 방법이 나와 있습니다.

맞춤 대상 앱 보기 디자인

사용자가 공유 창의 앱 목록에서 대상 앱을 선택하면 Windows의 앱의 공유 대상 보기에서 앱이 열립니다. 대상 앱 보기는 공유 창에서 호스팅되는 특별한 보기이며 앱의 기본 보기와는 다릅니다. 앱에서 Windows 8 계약 활성화하기에 호스트 보기와 이러한 보기의 활성화를 처리하는 방법에 대해 자세히 설명되어 있습니다. 대상 앱 보기는 사용자가 시작한 공유 작업이 완료될 수 있도록 지원하기 위해 만들어졌습니다. 이 보기에서 사용자는 콘텐츠를 한눈에 미리 보고, 간단한 작업을 수행하고, 공유 여부를 확인할 수 있어야 합니다.

Food with Friends의 대상 앱 디자인을 살펴보기 전에 여러분이 이미 알고 있을 듯한 대상 앱에 대해 알아보겠습니다. 아래 이미지는 Windows 8의 앱 전체 보기와 메일 앱의 대상 앱 보기입니다.

그림 6: 오른쪽에 있는 메일 대상 앱으로 사진 공유

그림 7: 메일의 메인 앱 보기에서 새 메일 작성

메일의 공유 대상 앱 보기는 전체 앱 보기보다 간단합니다. 사용자가 공유하려고 하는 콘텐츠에 대해 깔끔하게 최소화된 미리 보기를 축소판 형식으로 제공하고 관련 텍스트와 HTML도 제공합니다. 또한 받는 사람을 추가할 수 있는 받는 사람 입력란, 간단한 메시지를 작성할 수 있는 입력 영역, 그리고 보내기 단추를 통해 메일 보내기를 확인하는 간단한 방법을 제공합니다.

이처럼 앱의 대상 앱 보기는 더 간단하면서도 메일 앱의 아바타로 명확히 식별할 수 있으므로 공유 콘텐츠의 대상에 대한 사용자의 신뢰를 높여줍니다.

Food with Friends를 공유 대상 앱으로 사용

대상 앱 보기의 디자인에 대한 일반적인 내용을 살펴보았으니 이제 Food with Friends를 사용하여 사용자가 ‘My Wishlist’에 음식점을 쉽게 추가하도록 도와주는 대상 앱을 만드는 방법에 대해 알아보겠습니다.

Food with Friends가 원본 앱에서 Restaurant이 포함된 데이터 패키지를 받으면 Restaurant 데이터 형식의 세부 정보를 사용하여 기존 데이터베이스에서 수신된 데이터 패키지와 일치하는 음식점을 식별합니다. 그러면 대상 앱 보기에 해당 음식점의 미리 보기를 표시할 수 있습니다. 이는 공유 콘텐츠의 무결성에 대한 신뢰를 높여줍니다.

이 이미지에서는 Food with Friends의 대상 앱 보기를 보여줍니다.

그림 8: Food with Friends의 대상 앱 보기

보시다시피 Food with Friends의 대상 앱 보기는 간단하고 공유 대상 앱에 맞춰져 있습니다. 사용자가 공유하려는 음식점의 미리 보기와 메인 앱의 공유 콘텐츠 대상을 알려 주는 Add to Wishlist라는 간단한 실행 단추를 표시합니다. 사용자가 이 단추를 탭 또는 클릭하면 공유 작업이 확인됩니다. 여기에서 탭 또는 클릭을 요구한다면 의도하지 않은 공유가 방지될 뿐만 아니라 전체 공유 경험에 대한 신뢰를 높이는 데도 도움이 됩니다.

앱이 데이터 패키지 콘텐츠의 정보와 일치하는 음식점을 여러 개 찾으면 Food with Friends에서 공유 대상 앱 보기를 사용하여 옵션을 표시하고 사용자에게 공유할 항목을 선택하도록 합니다.

그림 9: 대상 앱 보기는 사용자가 공유할 항목을 선택할 수 있도록 옵션을 표시합니다.

앱이 수신된 데이터 패키지를 기준으로 음식점 또는 유효한 옵션 집합을 정확히 식별할 수 없을 경우를 대비해서 대상 앱 보기를 사용하여 해당 메시지를 전달하십시오.

QuickLink 만들기

QuickLink는 사용자가 대상 앱 내에서 신속하게 익숙한 대상으로 콘텐츠를 공유할 수 있는 공유 API의 프로비전입니다. QuickLink는 특정 작업을 제공하는 대상 보기에 대한 사용자 지정 링크로 사용됩니다. Windows에서 사용자가 사용할 수 있는 대상 앱 목록을 필터링하면 공유 창 맨 위에 사용 가능한 대상 목록으로 QuickLink 목록이 제공됩니다. 이러한 익숙한 대상 또는 사용자 작업에는 대상 앱을 통해 자주 공유되는 장소나 사람이 포함될 수 있습니다. 예를 들어 메일 앱은 이전에 메일을 보낸 연락처의 QuickLink를 반환합니다. 마찬가지로 대상 앱에 자주 공유하는 폴더, 그룹, 메모 및 재생 목록에 대한 QuickLink도 추가할 수 있습니다.

그림 10: 메일 대상 앱에서 제공하는 이전에 대상 앱을 사용하여 메일을 보낸 연락처에 대한
QuickLink가 공유 창에 표시됨

대상 앱은 ShareOperation개체의reportCompleted메서드를 호출하여 QuickLink를 제공할 수 있습니다. QuickLink에는 제목, 아이콘, ID가 있어야 합니다. 사용자가 공유 참 메뉴를 탭하면 제목(예: "엄마에게 전자 메일 보내기")과 아이콘이 나타납니다. ID는 앱에서 전자 메일 주소, 폴더 위치 등과 같은 사용자 지정 정보에 액세스하는 데 사용됩니다. 이 도구에 대한 자세한 내용은 QuickLink를 만드는 방법을 참조하십시오. 

참고: QuickLink는 앱에서 대상 앱의 여러 작업을 지원하는 경우에 유용합니다. Food with Friends는 공유 대상에서 단일 작업, 즉 Add to Wishlist만 지원하므로 QuickLink를 구현하지 않습니다.

확장 공유 및 오류 보고

원본 앱이 사진, 비디오 또는 파일과 같은 대형 데이터 청크를 공유하면서 데이터 전송 시간이 길어지는 경우가 있습니다. 이러한 공유 작업 유형을 '확장 공유'라고 하며, 대상 앱이 데이터를 받고 처리하는 데 시간이 좀 더 필요할 수 있습니다.

공유는 빠르고 유동적이어야 하고, 대상 앱 보기는 메인 앱을 통해 호스팅되는 가벼운 보기이기 때문에 사용자는 대상 앱 보기에서 탭하여 메인 앱으로 돌아갈 수 있습니다. 따라서 대상 앱은 공유가 시작된 후 대상 앱 보기에 의존하지 않으며 사용자 조작을 예상하지 못합니다. 대상 앱은 ShareOperation 개체와 메서드를 사용하여 Windows에 앱이 데이터를 처리하고 있다고 알려줄 수 있습니다.

• reportStarted – 원본 앱에서 DataPackage 개체의 데이터 검색을 시작했다고 Windows에 알려 주려면 이 메서드를 호출합니다.
• reportDataRetrieved– 패키지에서 데이터 검색을 마쳤다고 Windows에 알려 주려면 이 메서드를 호출합니다.
• reportCompleted – 공유 작업을 완료했다고 Windows에 알려 주려면 이 메서드를 호출합니다.

앱이 확장 공유의 데이터를 처리 중일 때는 대상 앱 보기에 진행률 UI를 표시합니다. 이렇게 하면 사용자에게 요청이 진행 중임을 알려줄 수 있고, 사용자가 앱으로 돌아가서 공유 작업의 진행률을 확인했을 때 신뢰도가 높아집니다. Windows 8의 진행률 컨트롤에 대한 자세한 내용은 빠른 시작: 진행률 컨트롤 추가를 참조하십시오.

그림 11: 대용량 첨부 파일 전송과 같은 확장 공유를 완료하면 메일 대상 앱 보기에 진행률 링이 표시됩니다.

데이터 전송 중에 문제가 발생하거나 대상 앱이 공유 작업을 종료해야 하는 경우에는 reportError를 호출하여 Windows에 오류 메시지를 보낼 수 있습니다. 사용자가 공유 창에서 공유 상태를 확인할 때 메시지를 볼 수 있습니다. 오류가 보고된 후 앱은 종료되고 공유도 종료됩니다. 사용자는 앱에 콘텐츠를 공유하는 작업을 다시 시작해야 합니다.

Food with Friends 공유 대상 예의 경우 앱이 데이터베이스에서 Restaurant 데이터 형식을 통해 원본 앱에서 공유한 음식점과 일치하는 음식점을 식별할 수 없는 경우 오류를 보고해야 합니다.

내용 정리

앱 간 공유는 대상 앱을 공유할 수 있는 엄청난 기회를 제공합니다. 앱에서 공유 콘텐츠를 받을 수 있다면 사용자가 다른 작업을 하고 있을 때도 앱을 활용할 수 있습니다. 이제 훌륭한 공유 대상 위치를 만드는 데 사용할 수 있는 데이터 형식, 클래스, 속성과 디자인 원칙에 대해 잘 이해되셨기 바랍니다. 우리는 여러분이 앱에서 공유 콘텐츠를 변환하고 더 다양하고 풍부한 최종 사용자 경험을 실현할 수 있는 방법을 알려드리게 되어 기쁩니다.

공유에 대해 자세히 알아보려면 데이터 공유 및 교환과 공유 콘텐츠 대상 앱 샘플을 읽고 시작해 보시기 바랍니다.

프로그램 관리자

Ishita Kapur

Windows 사용자 경험

NFC(Near Field Communication, 단거리 무선 통신)는 새로운 단거리 무선 기술입니다. 정확히 2cm 거리에 있는 사람들끼리 물리적으로 장치를 함께 탭하여 콘텐츠를 주고받을 수 있습니다. 탭 방식을 사용하면 대상을 빠르게 선택할 수 있을 뿐만 아니라 이해하기도 쉽습니다. 보면 바로 이해되므로 설명서도 필요 없습니다.

예를 들어 친구와 함께 사진을 보다가 친구가 사진을 달라고 할 때 NFC가 있으면 장치를 친구의 PC에 대고 탭하여 간단히 사진을 보낼 수 있습니다. 너무 간단하게 설명했지만 장치 간에 콘텐츠를 간편하게 공유할 수 있다는 것이 핵심입니다.

그림 1: Nokia 360 스피커가 Windows Phone과
Bluetooth 연결 정보를 공유하는 모습

Bluetooth 또는 Wi-Fi와 비슷한 NFC는 NFC Forum에서 정의한 표준 무선 프로토콜입니다. PC에서 NFC를 사용하려면 NFC 라디오가 필요합니다. Windows 8 PC에는 NFC 라디오가 직접 통합된 경우가 많이 있습니다. NFC가 통합되어 있지 않다면 NFC 동글을 구입하여 PC에 연결하면 됩니다.

NFC는 멋진 기능을 제공합니다. 사진을 탭하여 전송하거나, 레스토랑에서 메뉴를 탭하여 음식을 주문하거나, Bluetooth 장치를 탭하여 연결할 수도 있습니다. 전혀 다른 이야기 같지만 모두 '탭' 방식으로 시작한다는 데 공통점이 있습니다. NFC는 PC, 전화, 스피커, 헤드셋, 무선 디스플레이 등과 같은 다양한 장치에서 사용되며, 매우 직관적인 장치 연결을 지원합니다. 또한 NFC는 RFID 태그를 사용합니다. RFID 태그는 매우 저렴하고 가벼운 패시브 안테나로, 꽤 많은 양의 데이터가 들어가고 거의 모든 곳에 부착할 수 있기 때문에 포스터에 주로 사용됩니다. 예를 들어 영화 포스터를 탭하기만 하면 영화표를 간단하게 구매할 수 있습니다. 이러한 것들을 NFC 태그라고 합니다. 이제 NFC 태그를 탭하는 기본적인 예를 알아보면서 NFC API의 핵심 개념을 몇 가지 설명하도록 하겠습니다.

하지만 그 전에 장치를 함께 탭한다는 것이 무슨 의미인지 자세히 살펴보도록 하겠습니다.

'탭' 정의

Bluetooth 마우스를 탭하여 연결하든, 사진을 탭하여 공유하든, 장치를 같은 방법으로 함께 탭하는 것이 중요합니다. 그리고 탭한다는 것은 잘 알고 있는 개념이지만 PC를 다른 장치에 가까이 대고 탭한다는 개념은 대부분 생소할 것입니다. 탭과 관련하여 알아야 할 몇 가지 유용한 지침은 다음과 같습니다.

1. 장치를 함께 탭하는 지점 - '탭하여 실행' 비주얼 마크라고도 하는 터치마크를 사용여 NFC 안테나가 있는 위치를 표시합니다. PC 모델에 따라 탭하는 부분도 다릅니다. 예를 들어 태블릿의 경우 후면을 탭해야 하지만 올인원의 경우 전면을 탭해야 합니다. NFC 기능이 있는 Windows 8 PC에서 볼 수 있는 마크는 다음과 같은 모양입니다.
   
   

   그림 2: 탭하여 실행 비주얼 마크

2. 장치가 서로 통신 중 - 탭할 때 전송되는 데이터가 직접 보이지는 않아도 무언가 진행 중이라는 것을 사용자가 확신할 수 있어야 하므로 범위 내의 장치끼리 통신 중일 때는 Windows에서 소리가 재생됩니다.

이 부분은 Windows에서 자동으로 처리하므로 신경 쓰지 않아도 됩니다. 사용자 환경 요소에 대한 자세한 내용은 Windows 8 근거리 근접 연결 구현 사양을 참조하십시오. 이를 바탕으로 NFC로 경험할 수 있는 멋진 시나리오 몇 가지를 살펴보겠습니다.

NFC를 사용하는 경우

사용자가 앱에서 어떤 대상을 선택해야 할 때는 NFC를 사용하십시오. NFC를 사용하면 직관적인 방식으로 선택할 수 있으며 수동으로 검색하는 것보다 빠르고 더 근사하게 보입니다. 탭은 앱에 따라 다르지만 사진 수신부터 재생 목록 시작까지 다양한 경험을 촉발하는 일종의 트리거가 될 수 있습니다. 탭 이후에 발생하는 일은 전적으로 앱이 결정합니다. 따라서 Microsoft는 이러한 경험의 범위를 간단히 '탭하여 실행' 경험으로 분류하고 있습니다.

다음은 NFC를 사용하여 앱에서 무언가를 선택하는 예입니다. 탭하여 다음을 실행할 수 있습니다.

• 포스터의 정보 확인: NFC 태그는 가볍고 저렴한 RFID 태그입니다. 가격은 0.15달러에서 1달러 정도이며 인쇄 비용에 따라 가격이 달라집니다. NFC 태그는 QR 코드와 비슷하지만 더 쉽고, 더 빠르게 사용할 수 있습니다. 카메라 각도를 맞추면서 바코드 사진을 찍는 것보다는 태그를 탭하는 것이 훨씬 더 간편합니다. 공항, 지하철 역, 버스 정류장과 같이 사람들이 붐비는 곳에 태그가 포함된 포스터를 광고하는 제조업체들이 점점 늘어나고 있습니다. NFC 태그에는 48B~4KB 데이터가 저장될 수 있으며 앱의 특정 페이지를 실행하는 태그도 프로그래밍할 수 있습니다.

• 연락처 정보 교환: 내 연락처 정보를 알려줄 때 친구가 잘못 받아적을까 봐 걱정할 필요 없이 장치를 탭하여 연락처 정보를 교환해 보십시오. 마찬가지로 NFC 명함/태그에 정보를 프로그래밍하거나 앱을 통해 정보를 직접 교환할 수 있습니다.
• 좋아하는 음악 방송 재생: 운동하러 갈 때, 차에 시동을 걸 때, 또는 집에서 쉴 때, NFC 태그를 사용하여 라디오 방송을 들어보십시오. 헬스장용 태그, 휴식용 태그, 취침용 태그 등 다양한 태그에 음악 방송을 프로그래밍할 수도 있습니다.
• 붐비는 레스토랑에서 저녁 식사 주문: 저녁 시간에 손님이 많은 레스토랑에서는 주문하는 데만도 엄청 오래 기다려야 합니다. 기다리지 말고 테이블에서 태그를 탭하여 음식을 주문하십시오.
• 친구와 함께 게임: 장치를 함께 탭하여 배틀쉽, 체스 또는 스크래블과 같이 여럿이 같이 하는 게임을 친구와 함께 즐길 수 있습니다. 탭 후에는 Bluetooth 또는 Wi-Fi Direct와 같이 대역이 넓고 처리량이 많은 대역 외 전송을 통해 연결이 유지됩니다.

지금까지 NFC를 사용해야 하는 경우에 대한 유용한 아이디어를 알아보았습니다. 이제 Windows 8 근접 연결(NFC) API를 사용하는 앱을 개발하는 방법을 알아보는 재미있는 시간을 갖겠습니다.

NFC를 구현하는 방법

지금까지 알아본 것처럼 NFC는 일상에서 느끼는 여러 가지 불편을 덜어 줍니다. 알람을 설정하는 예를 보겠습니다. 우리 모두 아침 알람 시간을 잘못 맞춰본 적이 있을 겁니다. 늦은 시각 잠들기 직전에는 누구나 분별력이 약간 떨어지기 마련인데, 이때 NFC를 사용하면 아주 쉽게 미리 설정된 태그를 탭하고 확인한 후 아무런 걱정 없이 잠들 수 있습니다. 그러면 사용자들의 일상적인 불편을 덜어 주기 위해 사용자가 NFC 태그를 사용하여 알람을 설정할 수 있는 기본 알람 앱을 한번 작성해 보겠습니다. 이는 두 가지 시나리오로 나눌 수 있습니다.

1. 태그에 직접 알람 설정: NFC 태그는 재사용이 가능하므로 앱에 사용자가 알람을 프로그래밍할 수 있는 기능이 있어야 합니다. 예를 들어 평일과 주말을 구분해서 알람을 프로그래밍하는 경우가 있습니다. 이것을 태그에 데이터를 게시한다고 합니다.
2. 태그를 통해 알람 설정: 사용자가 태그를 탭하면 앱이 실행되어 알람 설정을 확인해야 합니다. 즉, 상황에 따라 또는 인수를 사용하여 앱을 실행할 수 있습니다.

NFC API로 이러한 시나리오를 구현하는 방법은 여러 가지가 있는데 그 중 가장 간단한 방법을 살펴보겠습니다.

NFC 태그에 직접 알람을 설정하는 과정을 알아보겠습니다.

1. 민수가 알람 앱을 실행하고 시간을 오전 7시로 설정합니다. 아직 NFC가 연결되지 않은 일반 알람 설정입니다.
2. 민수가 'NFC 태그에 알람 설정' 옵션을 선택합니다. 그러면 앱이 NFC API를 호출하여 NFC 라디오에 앱 식별자 문자열과 07:00이라는 정보를 게시합니다. NFC 태그는 표준화된 메시지 형식인 NDEF(NFC Defined Exchange Format)를 사용합니다. Windows에서 알아서 처리하므로 앱에서 별도로 데이터의 형식을 NDEF 메시지로 지정할 필요가 없습니다. 이제 사용자가 NFC 태그를 탭할 수 있습니다.
3. 민수가 태그를 PC에 가까이 대고 탭하면 앱이 태그 프로그래밍을 확인합니다. 태그를 탭한 후 사용자에게 앱이 태그 프로그래밍을 완료했음을 알려주는 것이 중요합니다. 앞서 말했다시피 PC를 탭하는 것은 대부분의 사람들에게 생소한 개념이므로 확인을 통해 사용자에게 탭이 완료되었다고 안심시켜 주어야 합니다. 메시지 전송 처리기를 등록하면 앱이 메시지가 전송되었다는 것을 알게 됩니다.

NFC API는 Windows.Networking.Proximity 네임스페이스에 있으며 사용자가 'NFC 태그에 알람 설정' 옵션을 선택한 후에 진행되는 2단계에서 실행됩니다. 먼저 앱은 근접 연결 개체를 초기화합니다. 근접 연결 개체는 태그(또는 장치)가 범위 내에 있거나 범위를 벗어났을 때 알려주는 데 사용됩니다. 다음으로, DeviceArrival 이벤트 처리기를 추가하겠습니다. 이 처리기는 태그를 탭한 시점, 즉 태그에 정보를 기록할 수 있는 시점을 인식합니다. 태그에 정보를 기록 중일 때 사용자에게 이를 알려주면 범위를 벗어나지 않게 할 수 있으므로 유용합니다. 또한 근접 연결 장치를 탭한 시점도 인식할 수 있습니다.

다음은 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’

}

이제 태그에 정보를 게시합니다. 앱은 앱 ID와 앱 플랫폼으로 이루어진 앱 식별자 문자열과 실행 인수를 게시합니다. Windows 8의 경우 앱 ID는 <패키지 제품군 이름>!<앱 ID>이며 앱 플랫폼은 ‘Windows’입니다. 앱의 패키지 매니페스트에 있는 Application 요소의 ID 특성에서 앱 ID 값을 복사해야 합니다. 실행 인수는 사용자가 설정한 알람인 ’07:00’입니다. 이것을 메시지라고 하겠습니다.

앱이 다양한 플랫폼에서 작동하는 경우 대체 앱 ID 및 앱 플랫폼을 게시할 수 있습니다. 즉, Windows Phone 8과 같이 NFC를 지원하는 다른 장치에서 동일한 태그를 탭할 수 있습니다. 대체 ID에 대한 자세한 내용은 MSDN을 참조하십시오.

앱은 publishBinaryMessage라는 메서드를 사용하여 태그에 데이터를 게시합니다. 이 메서드는 messageType, message 및 messageTransmittedHandler라는 3개의 매개 변수를 받습니다. messageType을 ‘LaunchApp:WriteTag’로 설정해 보겠습니다. 이는 앱이 NFC 태그에 정보를 기록하겠다는 것을 Windows에 알립니다. message는 앞서 정의한 그 메시지입니다(앱 식별 문자열 및 실행 인수). message는 버퍼에 이진 메시지로 저장해야 합니다. messageTransmittedHandler 함수는 콜백에 등록됩니다. 그러면 message가 태그에 기록되었다는 것을 앱에서 알 수 있습니다. 이것은 사용자에게 태그에 메시지가 기록되었고 태그가 더 이상 범위 내에 있지 않아도 된다는 것을 알려줍니다.

메시지는 StopPublishingMessage 함수를 호출하거나 ProximityDevice 개체가 해제될 때까지 계속 게시됩니다. 이 예에서는 중지 함수를 사용하겠습니다. PublishBinaryMessage는 게시 ID를 반환합니다. 이 게시 ID를 사용하여 메시지가 NFC 라디오에 게시되지 못하게 중지하겠습니다.

다음은 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. 민수는 TV 감상 중/전자 메일 작성 중/게임 플레이 중/Windows 사용 중에 월요일 아침 알람을 설정해야겠다고 생각합니다. '수요일 알람' 태그를 PC 가까이 대고 탭합니다. 알람 앱을 실행하라는 알림이 표시됩니다. 이때까지는 Windows가 모든 것을 알아서 처리하므로 앱에서 별도로 할 일이 없습니다.
2. 민수가 수락하면 앱이 실행되고 오전 7시로 설정된 '알람을 확인하시겠습니까?' 화면이 열립니다. 민수가 알림을 수락하면 활성화 과정에서 Windows가 앞서 말한 것과 동일한 실행 인수를 앱에 전달합니다. 이를 상황별 실행이라고 하며, 앱이 특정 페이지에서 실행되게 하는 것과 동일합니다.
3. 민수가 알람을 설정합니다. NFC가 없는 일반 알람 설정입니다.

NFC 태그에서 실행 인수를 받기는 매우 쉽습니다. 앱은 NFC 태그에서 상황별 실행을 처리해야 합니다. 상황별 실행은 앱을 특정 페이지에서 실행하는 것과 동일합니다. 실행 인수가 오전 7시 알람을 지정하고, 앱이 이를 통해 제안된 알람을 표시합니다. 또한 PC에 앱이 설치되지 않은 경우 Windows 스토어에서 앱을 설치하라는 알림을 자동으로 표시합니다.

다음은 상황별 실행을 구현하는 방법을 보여주는 코드 예제입니다.

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();
        }

앱이 NFC 태그를 읽고 NFC 태그에 기록하는 것을 지원하기 위해 해야 할 일은 이것이 전부입니다. 최첨단 시나리오치고는 매우 단순합니다. 마지막으로 매우 유용한 오류 처리 방법에 대해 알아보겠습니다.

오류 처리

앱에는 자주 발생하는 오류가 몇 가지 있습니다.

• 탭한 태그가 NDEF 형식이 아닙니다. Windows 8은 태그를 다시 자동으로 NDEF 형식으로 지정하도록 지원하지 않으므로 NDEF 포매터를 다운로드하고 설치해야 합니다.
• 탭한 태그가 읽기 전용입니다. 일부 NFC 태그는 읽기 전용으로 잠겨 있을 수 있습니다(기존의 VHS 테이프와 유사).
• 탭한 태그가 너무 작고 데이터가 다 들어가지 않습니다.
• 사용자 PC에 NFC가 없습니다. 처음에 말한 것처럼 NFC는 새로운 기술이며 보급률이 점차 높아지고 있습니다. PC가 근접 연결을 지원하는지 확인하려면 ProximityDevice.getDefault() 메서드를 사용하십시오. NFC 라디오가 설치되지 않은 경우 이 메서드에서 NULL을 반환합니다.

재미있고 직관적입니다!

Windows는 마침내 주요 소비자를 위한 NFC를 도입하여 에코시스템과 잘 만들어진 포괄적인 UX를 갖추게 되었습니다. 이 기술은 앱과 장치 환경을 놀랍도록 직관적으로 만들어줄 많은 잠재력을 가지고 있습니다. 재미있고 직관적입니다.

NFC는 광범위한 분야이므로 다른 멋진 Windows 8 NFC 개발자 환경에 대해서도 다양한 블로그 게시물이 기대됩니다.

NFC 및 근접 연결에 대한 자세한 내용은 아래 리소스를 참조하십시오.

리소스

감사합니다.

Priya Dandawate
장치 및 네트워킹 프로그램 관리자

도움을 주신 분: Max Morris, Marzena Makuta, Mike Loholt, Jake Sabulsky, Vishal Mhatre

우리 곁에는 항상 네트워크에 연결할 수 있는 장치가 있습니다. 최신형 냉장고와 세탁기에도 인터넷과 홈 네트워크에 연결하는 기능이 있습니다. 따라서 최종 사용자들은 앱을 연결하는 기능도 당연히 기대하게 될 것입니다. 이렇게 "연결된 앱"에서는 소셜 미디어, 디지털 미디어, 블로그 등 웹의 최신 콘텐츠를 사용합니다. 연결된 앱 개발은 표준이 되었지만 네트워크 연결 끊김, 네트워크 요금제 비용 또는 성능 문제와 같은 일반적인 문제를 처리해야 하는 숙제가 여전히 남아 있습니다. Windows 8에서는 연결된 앱을 예전보다 훨씬 더 쉽게 작성할 수 있습니다.

이 글에서는 Windows 스토어 앱 사용자에게 빠르고 유연하며 번거롭지 않은 연결된 환경을 제공하는 데 도움이 되는 유용한 팁 몇 가지를 살펴봅니다.

• 시나리오에 적합한 API 선택
• 적합한 네트워크 기능 선택
• 네트워크 요금제에 맞게 앱 동작 조정
• 네트워크 상태 변경에 대응
• 유연성을 위한 콘텐츠 캐시

각 팁을 자세히 알아보겠습니다.

적합한 API 선택

집을 지으려면 적절한 공구가 필요합니다. 못을 박으려면 망치가 필요하고, 나무판을 자르려면 톱이 필요하고, 나사를 고정하려면 드라이버가 필요합니다. 마찬가지로 연결된 Windows 스토어 앱을 개발할 때도 적절한 네트워킹 API를 사용해야 합니다. Windows 8에서는 앱이 인터넷이나 사설 네트워크를 통해 다른 컴퓨터나 장치와 통신하는 데 사용할 수 있는 다양한 네트워킹 API를 제공합니다. 따라서 앱에 필요한 네트워킹 기능을 파악하는 것이 첫 단계입니다.

가장 일반적인 네트워킹 시나리오는 웹 사이트에 액세스하여 정보를 검색하거나 저장하는 것입니다. 간단한 예로 웹 사이트를 사용하여 사용자 정보와 게임 점수를 저장하는 게임이 있습니다. 이보다 복잡한 예로는 REST 기반 웹 서비스에 연결하여 웹 서비스에서 제공하는 라이브러리를 통해 정보에 액세스하거나 정보를 저장하는 앱이 있습니다. Windows 8에는 웹 서비스 및 웹 사이트에 연결하는 API가 몇 가지 있습니다. 앱은 이러한 API를 통해 REST를 지원하거나 기본 HTTP 프로토콜 명령(예: GET 및 POST)을 웹 서버로 보내는 웹 서비스에 액세스할 수 있습니다. 웹 액세스의 경우 앱을 개발할 때 사용한 언어에 따라 다른 API를 사용해야 합니다.

• XMLHTTPRequest 및 WinJS.xhr - JavaScript 및 HTML로 작성된 앱
• HttpClient - C# 또는 Visual Basic .NET 및 XAML로 작성된 앱
• XML HTTP Request 2(IXHR2) - C++ 및 XAML로 작성된 앱

다음 코드는 REST 기반 웹 서비스를 사용하여 기본 요청 및 응답을 수행하는 방법을 보여줍니다. 이 경우 웹 서비스가 웹 서버에서 ASP.NET 스크립트를 실행할 수 있습니다.

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.
    }
}

WinJS.xhr에 대한 자세한 내용은 웹 서비스에 연결(JavaScript 및 HTML을 사용하는 Windows 스토어 앱)을 참조하십시오. HttpClient에 대한 자세한 내용은 빠른 시작: HttpClient를 사용하여 연결(C#/VB/C++ 및 XAML을 사용하는 Windows 스토어 앱) 및 HttpClient 샘플을 참조하십시오.

또 다른 일반적인 네트워킹 시나리오는 파일 전송 시간이 오래 걸릴 수 있는 파일을 다운로드하거나 업로드하는 경우입니다. 예를 들어 웹 서비스의 사진이나 사진 앨범을 업로드하거나 다운로드해야 하는 카메라 또는 사진 갤러리 앱이 있습니다. 이 경우 전송 시간이 오래 걸릴 수 있으므로 전송이 완료될 때까지 사용자를 기다리게 하는 것은 부적절합니다. Windows.Networking.BackgroundTransfer API는 앱을 실행하고 있지 않을 때에도 파일을 다운로드 또는 업로드할 수 있는 기능을 제공합니다. 앱이 포그라운드에서 실행 중이고 포커스가 있을 때 전송을 시작하면 앱을 종료하더라도 백그라운드에서 전송이 계속 진행됩니다.

좀 더 구체적인 다른 시나리오는 신디케이티드 콘텐츠에 액세스하는 경우입니다. Windows.Web.Syndication API는 RSS 또는 Atom 형식의 피드를 검색할 수 있습니다. 또한 Windows.Web.AtomPub API는 앱이 다양한 AtomPub 형식의 데이터를 게시하도록 지원합니다.

또한 API에서 상위 수준의 특정 네트워킹 프로토콜을 지원하지 않을 경우를 대비해 Windows 런타임에서 멀티캐스팅과 함께 TCP 및 UDP 소켓도 지원합니다. Windows.Networking.Sockets API는 다른 상위 계층의 프로토콜을 구현할 수 있는 StreamSocket(TCP) 및 DatagramSocket(UDP)을 제공합니다.

참고: Windows 8에는 WebSocket이라는 새로운 유형의 소켓이 도입되었습니다. WebSocket이란 무엇이고 어떤 앱에 적합한지 자세히 알아보려면 WebSocket을 사용하여 연결을 참조하십시오.

다음 표에는 지원되는 네트워킹 기능의 전체 목록과 추가 정보 링크가 나와 있습니다.

적합한 네트워크 기능 선택

네트워크 격리는 Windows 8에서 사용하는 앱 보안 모델의 일부입니다. Windows는 네트워크 경계를 적극적으로 검색하여 네트워크 격리에 대한 네트워크 액세스 제한을 적용합니다. 이러한 기능을 올바르게 배포하면 사용자와 앱을 악의적인 공격으로부터 보호하는 데 도움이 됩니다.

네트워크 액세스 범위를 정의하려면 앱이 네트워크 격리 기능을 선언해야 합니다. 이러한 기능을 선언하지 않으면 앱이 네트워크 리소스에 액세스할 수 없습니다. Windows에서 앱에 네트워크 격리를 적용하는 방법에 대해 자세히 알아보려면 네트워크 기능을 설정하는 방법을 참조하십시오.

동일한 장치에서 Windows 스토어 앱과 데스크톱 앱 간에 프로세스 간 통신 메커니즘으로 네트워킹을 사용할 수는 없습니다. 따라서 Windows 스토어 앱에는 IP 루프백 주소를 사용할 수 없습니다. Visual Studio 디버거를 사용할 경우 일부 개발 목적에 한해 IP 루프백 주소를 사용할 수 있는 예외가 적용됩니다. 자세한 내용은 루프백을 사용하도록 설정하고 네트워크 격리 문제를 해결하는 방법을 참조하십시오.

네트워크 액세스 요청은 두 가지 범주로 분류됩니다.

1. 클라이언트에서 시작되는 아웃바운드 요청: 앱이 클라이언트 역할을 하며, 원격 컴퓨터(일반적으로 서버)에 초기 네트워크 요청을 보내 네트워크 액세스를 시작합니다. 앱이 하나 이상의 요청을 서버에 보내고, 서버가 단일 응답 또는 여러 응답을 다시 보냅니다. 예를 들어 웹 클라이언트 앱에서 웹 서버로의 모든 트래픽이 이 범주에 속합니다.
2. 자발적 인바운드 요청: 앱이 네트워크 서버 역할을 하고, 원격 컴퓨터에서 들어오는 인바운드 네트워크 요청을 수신합니다. 원격 컴퓨터가 서버 역할을 하는 앱으로 초기 요청을 보내 네트워크 액세스를 시작합니다. 원격 컴퓨터가 하나 이상의 요청을 앱으로 보내고, 앱이 하나 이상의 응답을 원격 컴퓨터로 다시 보냅니다. 예를 들어 미디어 서버 역할을 하는 앱이 이 범주에 속합니다.

최소 권한의 원칙을 따라 앱에 필요한 기능만 추가하십시오. 앱은 클라이언트에서 시작하는 아웃바운드 요청만 필요할 수도 있지만 원치 않는 인바운드 요청을 수신해야 할 수도 있습니다. 네트워크를 통해 인증할 때 사용자 자격 증명 및 인증서에 액세스해야 하는 앱도 있습니다.

다음 표에는 연결된 앱에 주로 필요한 네트워크 격리 기능 및 기타 관련 기능이 자세히 설명되어 있습니다. 처음 3개는 연결된 앱에서 사용하는 주요 네트워크 격리 기능입니다. 실제로 연결된 앱은 이러한 기능 중 하나 이상을 사용해야 합니다. 나머지 기능은 일부 연결된 앱에 필요한 추가 기능입니다.

이 검사 목록을 사용하여 앱에 네트워크 격리를 구성하십시오.

• 앱에 필요한 네트워크 액세스 방향을 결정합니다(클라이언트에서 시작하는 아웃바운드 요청, 자발적 인바운드 요청 또는 둘 다).
• 앱이 통신할 네트워크 리소스 유형을 결정합니다(집 또는 직장 네트워크의 리소스, 인터넷의 액세스 또는 둘 다).
• 앱 매니페스트에 필요한 최소 네트워크 격리 기능을 구성합니다. 이 기능은 Microsoft Visual Studio 2012의 앱 매니페스트 디자이너를 사용하여 구성하거나 수동으로 추가할 수 있습니다.
• 문제 해결용으로 제공된 네트워크 격리 도구로 앱을 배포 및 실행하여 테스트해 보십시오. 자세한 내용은 루프백을 사용하도록 설정하고 네트워크 격리 문제를 해결하는 방법을 참조하십시오.

다음은 Microsoft Visual Studio 2012의 앱 매니페스트 디자이너를 사용하여 네트워크 기능을 사용하도록 설정하는 방법을 보여주는 스크린샷입니다.

Visual Studio 2012에서 앱의 package.appxmanifest의 네트워크 기능 선택

네트워크 요금제에 맞게 앱 동작 조정

가장 최근에 월 데이터 한도에 도달하거나 해외 여행을 한 적이 언제인지 생각해 보십시오. 이러한 경우에는 일반적으로 불필요한 네트워크 요금이 부과되지 않도록 장치와 앱을 주의해서 사용하게 됩니다.

Windows 8에서는 앱이 사용 가능한 네트워크 리소스를 모니터링하고 네트워크 요금제에 맞게 작동하도록 지원함으로써 이러한 사용자 문제를 해결합니다. 앱에 대한 사용자의 신뢰도를 높이려면 연결 요금이 부과될 수 있는 경우에 앱에서 이를 알려줄 수 있게 만들고 요금 발생을 피하거나 줄이도록 동작을 조정해야 합니다.

Windows.Networking.Connectivity API는 네트워크 연결 유형과 금액에 대한 정보를 제공합니다. 이를 통해 앱에서 네트워크 리소스를 평소대로 사용하는 시기, 아껴서 사용해야 하는 시기, 사용자에게 물어봐야 하는 시기를 결정할 수 있습니다.

ConnectionProfile은 네트워크 연결을 나타냅니다. ConnectionProfile의 ConnectionCost를 사용하여 동작을 조정할지 여부를 결정할 수 있습니다. NetworkCostType 속성은 네트워크 연결 유형을 알려줍니다. 이 속성에는 다음 4개 값 중 하나가 올 수 있습니다.

• Unrestricted - 무제한 이용 가능한 네트워크 연결입니다. 사용 요금이 부과되지 않고 사용량에 제한이 없습니다.
• Fixed - 특정 한도까지 무제한 이용 가능한 네트워크 연결입니다.
• Variable - 사용량이 바이트 단위로 측정되는 네트워크 연결입니다.
• Unknown - 요금 관련 정보가 없는 네트워크 연결입니다.

ConnectionCost의 다른 여러 부울 속성도 자세한 정보를 제공합니다.

• Roaming - 홈 제공자 외부 네트워크에 연결되어 있습니다.
• ApproachingDataLimit - 데이터 요금제에 명시된 사용 한도에 도달했습니다.
• OverDataLimit- 데이터 요금제에 명시된 사용 한도를 초과했습니다.

이러한 속성이 나타내는 상황을 앱에서 대응하게 하십시오. 연결이 Roaming일 때는 네트워크 사용 관련 데이터 요금이 비쌉니다. NetworkCostType이 Variable일 때는 사용자가 네트워크에서 주고받은 데이터 양에 대해 요금을 지불하는 네트워크 요금제를 이용하고 있는 것입니다. NetworkCostType이 Fixed일 때는 사용자가 이미 데이터 한도를 초과했거나 데이터 한도에 도달한 경우 우려할 만한 원인이 있는 것입니다.

앱은 이러한 정보를 참조하여 다음과 같은 지침을 따라 네트워크 리소스를 가장 잘 사용하는 방법을 결정할 수 있습니다.

다음은 연결 요금을 확인하고 적절한 앱 동작에 대한 제안 사항을 반환하는 코드입니다.

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.";
        }
    }
}

네트워크 요금제에 맞게 앱 동작을 조정하는 방법에 대해 자세히 알아보려면 네트워크 정보 샘플을 사용하십시오.

사용자는 또한 작업 관리자를 실행하여 각 앱이 사용하고 있는 네트워크 데이터의 양을 볼 수 있습니다. 다음은 예를 보여주는 스크린샷입니다.

앱별 CPU 및 네트워크 사용량을 볼 수 있는 작업 관리자의 앱 기록 탭

네트워크 상태 변경에 대응

모바일 장치의 경우 네트워크 연결이 불안정할 수 있습니다. 모바일 3G 또는 4G 광대역 네트워크는 사용자의 집이나 창고 안에서 연결이 끊길 수 있지만 Wi-Fi는 계속 사용할 수 있습니다. 마찬가지로 사용자가 집 밖으로 나가면 Wi-Fi 연결이 끊길 수 있습니다. 네트워크를 아예 사용할 수 없을 때도 있습니다. Wi-Fi와 모바일 광대역 네트워크의 보급으로 이러한 네트워크 변경은 자주 일어날 수 있습니다.

NetworkStatusChanged 이벤트는 적용 요금 또는 연결 옵션이 변경되었다는 의미입니다. 네트워크 상태 변경에 대응하고 변경이 생겼을 때 원활한 고객 경험을 제공하려면 연결된 앱에서 이러한 시나리오 지침을 따라야 합니다.

오류로 인한 연결 끊김

대부분의 경우 네트워크 작업을 다시 시도하면 연결을 다시 설정할 수 있습니다. 실패할 경우 NetworkStatusChanged 이벤트를 기다리십시오. 연결이 계속 실패할 경우 50밀리초 값부터 기하급수적으로 늘어나는 백오프 재시도 간격을 앱에 사용하는 것이 좋습니다.

네트워크 연결 끊김

사용자에게 연결이 끊겼음을 알려주고 등록 후 NetworkStatusChanged 이벤트를 기다리십시오.

새 네트워크 사용 가능성

장치가 여러 네트워크에 연결되는 경우가 있습니다. 예를 들어 사용자가 집 밖에서 모바일 광대역에 연결하고 Windows 8 메시지 앱을 사용하여 친구들과 채팅한 후 집에 돌아와서 무제한 네트워크에 연결하는 경우가 있습니다. Windows 8의 기본 정책은 네트워크 요금제보다는 무제한 네트워크로, 느린 네트워크보다는 빠른 네트워크로 설정하는 것입니다. 그러나 앱에 의해 설정된 기존 연결은 새 네트워크로 자동 전환되지 않습니다. 새 네트워크로 전환할지 여부는 앱만 결정할 수 있으므로 앱이 관여해야 합니다.

예를 들어 동영상 스트림이 거의 완료된 경우 새 네트워크로 전환하는 것은 부적절합니다. 그러나 현재 네트워크가 패킷을 삭제하고 있거나, 너무 느리거나, 스트림이 완료될 때까지 추가 시간이 필요할 경우 새 네트워크로 전환하는 것이 가장 좋습니다.

네트워크 전환이 앱 시나리오에 적절한 것으로 판단되면 새 네트워크가 탐지되었을 때 다음 지침을 따르십시오.

1. 기존 네트워크와 새 네트워크의 네트워크 요금을 확인합니다. 새 네트워크로 전환하는 것이 적절할 경우 방금 말한 지침에 따라 새 네트워크 연결을 설정하고 네트워크 작업을 다시 시도하십시오. Windows는 자동으로 네트워크 요금제보다 무제한 네트워크를, 느린 네트워크보다 빠른 네트워크를 우선적으로 선택합니다.
2. 새 네트워크 연결이 완료되면 앱의 새 네트워크 연결을 사용하고 기존의 연결이 있을 경우 이전 네트워크에 대한 원래 네트워크 작업을 취소하십시오.

네트워크 비용 변경

NetworkCostType이 Fixed이고 사용량이 데이터 한도에 도달했거나 초과한 경우 네트워크 요금이 변경될 수 있습니다. NetworkCostType이 Variable이 되거나 Roaming이 true로 변경될 경우에도 네트워크 요금이 변경될 수 있습니다. 이러한 경우 이전 팁의 지침을 따라 앱 동작을 조정하십시오.

다음은 NetworkStatusChanged 이벤트를 사용하여 다양한 네트워크 상태 변경에도 원활한 앱 경험을 제공하는 코드 예입니다. 두 예는 모두 registeredNetworkStatusNotification이라는 전역 부울 변수를 사용하며, 이 변수는 처음에 false로 설정되어 있습니다.

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);
    }
}

NetworkStatusChanged 이벤트에 대해 자세히 알아보려면 빠른 시작: 연결 이벤트 및 가용성 변경 관리와 네트워크 정보 샘플을 참조하십시오.

유연성을 위한 콘텐츠 캐시

콘텐츠를 디스크에 캐시하면 앱이 빠르고 유연하게 동작합니다. 예를 들어 RSS 피드 판독기 앱은 이전 세션에서 디스크에 캐시된 피드를 즉시 표시할 수 있습니다. 최신 피드가 공개되자 마자 앱의 콘텐츠가 업데이트됩니다. 캐싱은 앱을 시작하는 즉시 사용자가 콘텐츠를 읽고 앱에서 새 콘텐츠를 가져오도록 해줍니다.

Windows 8에서는 Windows.Storage 네임스페이스에 ApplicationData 클래스를 제공합니다. 이 클래스는 앱 데이터 저장소에 대한 액세스를 제공합니다. 이 데이터 저장소는 장치의 로컬에 있거나, 여러 장치 간에 로밍되거나, 임시로 저장된 파일 및 설정으로 구성되어 있습니다.

파일은 일반 파일 형식의 대용량 데이터 집합, 데이터베이스 또는 데이터를 저장하는 데 적합합니다. 파일은 Roaming, Local 또는 Temporary 폴더에 있을 수 있습니다. 자세한 의미는 다음과 같습니다.

• 로밍 파일은 사용자가 연결된 계정을 사용하여 로그인한 여러 시스템 및 장치 간에 동기화됩니다. 파일 로밍은 즉시 이루어지지 않습니다. 시스템에서 여러 요인을 평가하여 데이터를 보낼 시기를 결정합니다. 로밍 데이터 사용량은 할당량(RoamingStorageQuota 속성을 통해 사용 가능) 미만으로 유지하십시오. 할당량을 초과할 경우 데이터 로밍이 일시 중단됩니다. 앱이 파일에 데이터를 쓰고 있을 때는 파일을 로밍할 수 없으므로 더 이상 필요 없는 앱의 파일 개체를 닫으십시오.
• 로컬 파일은 시스템 간에 동기화되지 않습니다. 파일이 처음으로 작성된 시스템에 남아 있습니다.
• 임시 파일은 사용되지 않을 때 삭제될 수 있습니다. 시스템에서는 임시 파일을 삭제할 시기 또는 삭제할지 여부를 결정할 때 사용 가능한 디스크 용량이나 파일 저장 기간 같은 요소를 고려합니다.

다음은 디스크에 콘텐츠를 캐시하는 코드 예입니다. 서버 응답을 캐시하면 앱을 종료했다가 다시 시작하는 즉시 사용자에게 콘텐츠가 표시됩니다. 이러한 예에는 편의상 앱 데이터 저장소에 설정을 기록하는 방법이나 로밍 이벤트에 대응하는 방법 등은 나와 있지 않습니다. 자세한 내용은 응용 프로그램 데이터 샘플을 참조하십시오.

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.
    }
}

앱 데이터 저장소에 대한 자세한 내용을 알아보려면 앱 데이터 로밍 게시물을 참조하고 응용 프로그램 데이터 샘플을 사용해 보십시오.

결론

Windows 스토어 앱을 계획할 때는 이 글의 지침에 따라 유용하고 번거롭지 않으며 연결된 환경을 제공하십시오. 이러한 팁은 개발 프로세스를 단축할 뿐만 아니라 앱의 유연성을 유지하고 사용자 신뢰도를 높여줄 수 있습니다.

- Windows 프로그램 관리자 II, Suhail Khalid

도움을 주신 분: Steven Baker와 Peter Smith

지난 주, Steve Guggenheimer가 //build/ 2013 개최에 대해 알려 드렸습니다. 이 컨퍼런스는 오는 6월 26일~28일, 샌프란시스코 Moscone Center에서 개최됩니다. //build/는 Windows 스토어 앱 개발에 대한 자세한 정보를 얻을 수 있는 좋은 기회입니다. 이 컨퍼런스에서는 유용한 프레젠테이션, 데모, 정보 세션 등이 제공됩니다. 대부분의 Microsoft 엔지니어링 팀원이 컨퍼런스에 직접 참여하여 이러한 데모를 제공하고 질문에 답할 예정입니다. Windows 스토어 앱 개발에 대한 가장 유용한 최신 정보를 얻을 수 있는 이 절호의 기회를 놓치지 마십시오.

4월 2일 화요일부터 등록이 시작되었습니다. www.buildwindows.com에서 컨퍼런스에 대한 모든 세부 정보를 확인하고 바로 등록할 수 있습니다.

우리 모두 컨퍼런스에서 만나길 바랍니다!