Windows 8 앱 개발자 블로그

Windows 개발자 센터 경험 소개

Windows 8 Team — Thu, 16 May 2013 16:55:00 GMT

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

새로운 소식

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

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

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

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

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

역할에 적합한 콘텐츠

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

개발자

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

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

디자이너

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

비즈니스

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

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

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

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

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

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

대상 앱과 공유

Windows 8 Team — Wed, 15 May 2013 16:13:00 GMT

앱을 통한 공유에서는 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 데이터 형식을 주로 다루고 있지만 다른 데이터 형식도 개념은 비슷합니다.

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

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

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

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

대상 공유 계약 지원

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

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

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

또한 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로 첨단 앱 개발

Windows 8 Team — Wed, 24 Apr 2013 22:40:09 GMT

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를 다른 장치에 가까이 대고 탭한다는 개념은 대부분 생소할 것입니다. 탭과 관련하여 알아야 할 몇 가지 유용한 지침은 다음과 같습니다.

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

그림 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 태그를 사용하여 알람을 설정할 수 있는 기본 알람 앱을 한번 작성해 보겠습니다. 이는 두 가지 시나리오로 나눌 수 있습니다.

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

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

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

민수가 알람 앱을 실행하고 시간을 오전 7시로 설정합니다. 아직 NFC가 연결되지 않은 일반 알람 설정입니다.
민수가 'NFC 태그에 알람 설정' 옵션을 선택합니다. 그러면 앱이 NFC API를 호출하여 NFC 라디오에 앱 식별자 문자열과 07:00이라는 정보를 게시합니다. NFC 태그는 표준화된 메시지 형식인 NDEF(NFC Defined Exchange Format)를 사용합니다. Windows에서 알아서 처리하므로 앱에서 별도로 데이터의 형식을 NDEF 메시지로 지정할 필요가 없습니다. 이제 사용자가 NFC 태그를 탭할 수 있습니다.
민수가 태그를 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
}

아주 간단하지 않습니까? 이제 Windows 스토어 앱에서 NFC 태그에 기록하는 방법을 알았습니다. 너무 간단해서 더 이상 설명이 필요 없으므로 다음 시나리오인 태그를 통해 알람을 설정하는 시나리오로 넘어가 보겠습니다. NFC 태그에서 알람을 읽는 과정을 알아보겠습니다.

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

리소스

링크	형식
근접 연결을 사용한 개발에 대한 지침	문서
근접 API	문서
앱의 근접 연결 테스트 및 문제 해결	문서
게시 및 구독(자세한 내용)	문서
근접 연결 앱 샘플	샘플
근접 연결에 대해 궁금한 점이 있습니까? 여기에서 물어보십시오.	포럼

감사합니다.

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

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

연결된 Windows 스토어 앱 만들기

Windows 8 Team — Wed, 17 Apr 2013 20:57:00 GMT

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

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을 사용하여 연결을 참조하십시오.

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

API

기능

예

Windows.Web.Syndication

Windows.Web.AtomPub

RSS 또는 Atom 형식의 피드를 버전에 관계없이 검색합니다. OData와 같은 최신 형식에 대한 지원 기능을 쉽게 구현할 수 있는 API입니다. 또한 Windows 런타임은 Atom 컬렉션을 게시하는 데 사용되는 Atom Publishing Protocol도 지원합니다.
자세한 내용은 신디케이티드 콘텐츠 액세스 및 관리를 참조하십시오.

신디케이션 샘플

AtomPub 샘플

RSS 판독기

Windows.Networking.BackgroundTransfer

호출 앱이 포그라운드에 있지 않을 때도 사용 요금을 인식하며 콘텐츠 업로드 및 다운로드가 계속 진행되고 다시 시작할 수 있습니다. 이 API는 HTTP, HTTPS 및 FTP 프로토콜을 사용한 콘텐츠 전송을 지원합니다.
자세한 내용은 백그라운드로 데이터 전송을 참조하십시오.

백그라운드 전송 샘플

SkyDrive

Xbox 동영상

XMLHTTPRequest(JavaScript)

WinJS.xhr(JavaScript)

HttpClient(C#)

XML HTTP 요청 2(IXHR2)(C++)

REST 기반 웹 서비스 및 다른 HTTP 기반 프로토콜과 상호 작용합니다.
자세한 내용은 웹 서비스에 연결을 참조하십시오.

XHR, 탐색 오류 처리 및 URL 스키마 샘플

HttpClient 샘플

Bing 지도

Windows.Networking.Proximity

앱이 아주 가까이 있는 두 장치를 탐지한 후 소켓 API를 사용하여 두 장치 간에 네트워크 통신을 실행할 수 있습니다.
자세한 내용은 근접 연결 및 탭 지원을 참조하십시오.

근접 연결 샘플

게임

공동 작업 앱

Windows.Storage.Pickers

원격 파일 공유와 통신합니다.
자세한 내용은 데이터 및 파일에 액세스를 참조하십시오.

파일 선택기 샘플

Xbox 음악

사진

Windows.Networking.Sockets

앞서 언급한 SMTP, MAPI 또는 텔넷과 같은 API에서 지원하지 않는 프로토콜을 사용하는 서비스에 연결하거나 동일한 로컬 네트워크의 다른 장치에 연결합니다. HTTP 프록시를 포함한 웹을 통해 새 서비스에 연결하기 위해 소켓과 유사한 의미 체계(비동기, 양방향)가 필요한 앱에도 사용됩니다.
자세한 내용은 소켓을 사용하여 연결을 참조하십시오.

StreamSocket 샘플

DatagramSocket 샘플

WebSocket과 연결 샘플

ControlChannelTrigger 샘플

Lync, 공동 작업 화이트보드 또는 주식 투자

Windows.Storage.ApplicationData

Windows 8은 사용자 장치 간 특정 응용 프로그램 데이터를 자동으로 전환합니다. 사무실에서 PC를 사용하고 집에서 태블릿을 사용하는 등 둘 이상의 장치를 활용하고 있는 사용자가 여러 장치에 앱을 설치한 경우 응용 프로그램 데이터 로밍이 매우 유용합니다.
자세한 내용은 응용 프로그램 데이터 로밍에 대한 지침을 참조하십시오.

응용 프로그램 데이터 샘플

적합한 네트워크 기능 선택

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

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

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

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

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

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

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

네트워크 기능

설명

앱의 예

인터넷(클라이언트)

공항이나 카페 등 공공 장소에서의 인터넷과 네트워크에 아웃바운드 액세스합니다. 인터넷 액세스가 필요한 대부분의 앱은 이 기능을 선언해야 합니다.

RSS 판독기

소셜 네트워크

게임

인터넷(클라이언트 및 서버)

공항이나 카페 등 공공 장소에서의 인터넷과 네트워크에 인바운드 및 아웃바운드 액세스합니다. 중요한 포트로의 인바운드 액세스는 항상 차단되어 있습니다. 이 기능은 인터넷(클라이언트) 기능의 상위 집합입니다. 둘 다 선언할 필요는 없습니다.

P2P 앱

멀티캐스트를 사용하여 플레이어를 검색하는 멀티 플레이 게임

사설 네트워크(클라이언트 및 서버)

사용자가 신뢰하는 전용 공간에서의 네트워크에 인바운드 및 아웃바운드 액세스합니다. 일반적으로 집이나 직장의 네트워크입니다. 중요한 포트로의 인바운드 액세스는 항상 차단되어 있습니다.

NAS(Network Attached Storage) 콘텐츠에 액세스하는 앱

LOB(기간 업무) 앱

사설(집 또는 직장) 네트워크에서 멀티캐스트를 사용하여 플레이어를 검색하는 멀티 플레이 게임

근접 연결

장치와의 필드 근접 통신에 필요합니다. 사용자가 초대장을 보내거나 수락하면 앱이 네트워크에 액세스하여 아주 가까이 있는 장치에 연결할 수 있습니다.

아주 가까이 있는 사람과 멀티 플레이 게임

엔터프라이즈 인증

도메인 자격 증명이 필요한 기업 인트라넷 리소스에 연결하도록 접근 권한을 줍니다.

LOB(기간 업무) 앱

공유 사용자 인증서

사용자 ID를 인증하기 위해 스마트카드 인증과 같은 소프트웨어 및 하드웨어 인증에 액세스하도록 접근 권한을 줍니다. 런타임에 관련 API가 호출될 때 사용자가 조치를 취해야 합니다(예: 카드 삽입 또는 인증서 선택 등).

가상 사설 네트워크 앱

LOB(기간 업무) 앱

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

앱에 필요한 네트워크 액세스 방향을 결정합니다(클라이언트에서 시작하는 아웃바운드 요청, 자발적 인바운드 요청 또는 둘 다).
앱이 통신할 네트워크 리소스 유형을 결정합니다(집 또는 직장 네트워크의 리소스, 인터넷의 액세스 또는 둘 다).
앱 매니페스트에 필요한 최소 네트워크 격리 기능을 구성합니다. 이 기능은 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일 때는 사용자가 이미 데이터 한도를 초과했거나 데이터 한도에 도달한 경우 우려할 만한 원인이 있는 것입니다.

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

동작

연결 요금

앱 지침

예

일반

NetworkCostType이 Unrestricted 또는 Unknown이고 ConnectionCost가 Roaming이 아닙니다.

앱이 제한 사항을 구현하지 않습니다. 앱이 연결 요금을 Unlimited로 처리하고 사용 요금 및 사용량 제한의 적용을 받지 않습니다.

미디어 플레이어 앱이 전체 HD 영화를 재생할 수 있습니다.

앱이 제한 사항이나 프롬프트 없이 대용량 파일을 다운로드할 수 있습니다.

절약

NetworkCostType이 Fixed 또는 Variable이고 ConnectionCost가 Roaming 또는 OverDataLimit이 아닙니다.

앱이 네트워크 사용량을 최적화하기 위한 제한 사항을 구현하여 네트워크 요금제에 대한 작업을 처리합니다.

미디어 플레이어 앱이 저해상도로 영화를 재생할 수 있습니다.

앱이 중요하지 않은 다운로드를 연기할 수 있습니다.

옵트인

ConnectionCost가 Roaming 또는 OverDataLimit입니다.

네트워크 액세스 요금이 요금제 금액을 훨씬 초과한 예외적인 경우를 앱에서 처리합니다.

앱이 사용자에게 네트워크에 액세스할지 묻습니다.

앱이 모든 백그라운드 데이터 네트워크 작업을 일시 중지합니다.

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

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

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의 기본 정책은 네트워크 요금제보다는 무제한 네트워크로, 느린 네트워크보다는 빠른 네트워크로 설정하는 것입니다. 그러나 앱에 의해 설정된 기존 연결은 새 네트워크로 자동 전환되지 않습니다. 새 네트워크로 전환할지 여부는 앱만 결정할 수 있으므로 앱이 관여해야 합니다.

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

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

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

네트워크 비용 변경

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

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

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

//build/ 2013에 지금 등록하십시오!

Windows 8 Team — Fri, 05 Apr 2013 17:33:25 GMT

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

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

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

jQuery 버전 2.0의 Windows 스토어 앱 지원

Windows 8 Team — Thu, 04 Apr 2013 18:39:25 GMT

웹 개발 경험이 있는 분들은 아마도 오픈 소스 JavaScript 프레임워크 jQuery를 사용해 보셨을 겁니다. 또한 jQuery를 사용하여 Windows 스토어 앱을 개발하다 보면 JavaScript 런타임 또는 동적 콘텐츠 관련 오류가 발생할 수 있습니다. 조만간 출시될 v2.0 버전에서는 jQuery 팀이 이러한 문제를 해결했습니다. jQuery v2 베타는 HTML5/JS로 Windows 스토어 앱을 개발할 수 있습니다. 여러분은 웹 개발자로서 그 동안 쌓아온 기술과 자산을 활용하여 멋진 Windows 8 앱을 개발할 수 있습니다. 이제 최신 jQuery 2.0 베타 버전으로 Windows 8 앱 개발에 도전하세요.

"jQuery 팀은 jQuery 2.0이 사용될 새로운 환경에 많은 기대를 걸고 있습니다. HTML 및 JavaScript 개발자들은 jQuery에 대한 지식을 활용하여 개발 프로세스를 단축하려고 합니다. jQuery 2.0은 Windows 8 스토어 응용 프로그램 같은 환경에서 개발 프로세스를 단축할 수 있는 기능을 제공합니다." - jQuery Foundation 사장, Dave Methvin

Windows 스토어 앱: 새로운 맥락의 JavaScript 코드

이전에는 왜 jQuery가 "작동"하지 않았는지 궁금하실 것입니다. HTML/JS, C#, C++ 등 어떤 언어를 사용하든 모든 Windows 스토어 앱은 기본적으로 Windows 런타임에 액세스할 수 있습니다. 따라서 앱이 새 플랫폼에서 안전하게 실행될 수 있도록 새로운 보안 모델이 개발되었습니다. 뿐만 아니라 웹에 일반적으로 사용되는 API 중 일부는 새로운 네이티브 환경에 잘 맞도록 많은 부분이 수정되었습니다. 이러한 차이점 때문에 브라우저에서 실행될 코드에 문제가 발생할 수 있습니다. 대부분의 문제는 동적 콘텐츠와 관련하여 "HTML1701: 동적 콘텐츠를 추가할 수 없습니다." 또는 "0x800c001c - JavaScript 런타임 오류: 동적 콘텐츠를 추가할 수 없습니다." 같은 예외 오류일 것입니다.

이 모델에 대한 자세한 내용은 안정적이고 신뢰할 수 있는 앱 개발을 참조하십시오. Windows 개발자 센터에서 Windows 스토어 응용 프로그램과 웹 브라우저의 차이점에 대해 자세히 알아볼 수 있습니다.

jQuery 업데이트로 새로운 모델 지원

다들 알고 계시듯이 jQuery는 다양한 브라우저에서 작동하는 간편한 API를 통해 HTML 문서 통과 및 조작, 이벤트 처리, 애니메이션, Ajax 같은 작업을 훨씬 간단하게 처리할 수 있기 때문에 웹에서 매우 인기가 많은 JavaScript 프레임워크입니다.

jQuery의 이 모든 기능을 Windows 스토어 앱에서 지원하기 위해 appendTo의 jQuery 전문가들이 jQuery 커뮤니티와 협력하여 새로운 Windows 8 앱 모델을 지원하도록 jQuery를 업데이트했습니다. 새로운 jQuery가 플랫폼을 최대한 활용할 수 있도록 하기 위해 Microsoft Open Technologies의 엔지니어들이 기술적인 부분을 지원했습니다.

jQuery에 Windows 스토어 앱 지원을 추가하기 위해 초기 테스트, 단위 테스트 포팅 �� jQuery의 핵심 기술인 Sizzle selector 엔진 같은 jQuery 종속성 평가를 실시했습니다. appendTo에서는 jQuery 지원 논리의 여러 영역을 확인하고, Windows 스토어 앱 보안 모델의 지침에 따라 작동하도록 재작성이 필요한 문서의 대상 요소에 사용된 구문 분석 항목을 Sizzle 전체에 걸쳐 확인했습니다.

appendTo는 jQuery Core 프로젝트에 직접 코드를 제출했고 이 프로젝트는 이번 지원과 통합되었습니다. 따라서 앱에 jQuery를 추가하는 즉시 이 모든 기능을 무료로 사용할 수 있습니다. Windows 스토어 앱에서 jQuery를 사용할 때 다른 패턴을 사용해 보고 싶은 분도 있을 것입니다. net.tuts+ 사이트를 방문하면 이러한 패턴에 대해 자세히 알아볼 수 있습니다. 이번 업데이트의 변경 사항에 대한 자세한 내용은 appendTo 블로그 글을 참조하십시오.

코드 작성!

HTML5 및 JavaScript 개발자는 현재 갖고 있는 지식과 기존의 JavaScript 코드 및 라이브러리를 사용하여 Windows 8 앱을 개발할 수 있습니다. jQuery 코드를 사용하려면 jQuery 2.0 베타로 업그레이드한 후 appendTo에서 제공하는 새로운 패턴을 따라 하시면 됩니다. jQuery를 사용하지 않더라도 갖고 계신 코드와 라이브러리에 이와 똑같은 패턴 및 기술을 적용하여 Windows 8과 완벽하게 호환되는 앱을 개발할 수 있습니다.

웹 개발 기술을 Windows 플랫폼에 사용하여 새로운 기회에 도전해 보고 싶은 분은 MS Open Tech 블로그를 확인하십시오.

- MS Open Tech 수석 기술 에반젤리스트, Olivier Bloch

Windows 스토어 게임 개발

Windows 8 Team — Fri, 29 Mar 2013 22:49:00 GMT

Windows 8은 혁신적인 폼 팩터, 새로운 칩 아키텍처, 흥미로운 상거래 모델, 엄청난 가능성으로 PC 환경을 바꾸어 놓았습니다. PC 게임은 오래 전부터 사람들이 컴퓨터를 사용하는 주된 이유 중 하나였습니다. 이제 게임은 그 어느 때보다도 새로운 장치 환경의 가치를 여실히 보여주고 있습니다. Windows 스토어를 통해 간편하게 게임을 받고, 즐기고, 친구와 공유하고, 안전하게 업데이트할 수 있습니다. 게임이 앱 다운로드에서 매우 높은 비율을 차지하고, 상당한 수익을 창출하고 있으며, 새 플랫폼에서 가장 높은 사용자의 호응을 불러오고 있다는 사실은 전혀 놀랍지 않은 일입니다. GDC가 얼마 앞으로 다가오면서 더욱 많은 개발자들이 Windows 8의 무한한 가능성에 대해 관심을 보이고 있습니다.

우수한 Windows 스토어 게임을 만들려면 어떻게 해야 할까요? 창의적이고, 혁신적이고, 수익성이 높은 게임을 간편하게 개발할 수 있도록 Windows가 제공하는 것은 무엇일까요? 여러분은 어떤 도구, 기술 및 서비스를 사용할 수 있습니까? 에코시스템에서는 무엇을 사용할 수 있을까요? 개발자들은 Windows 8 앱을 개발하면서 어떤 정보를 공유했을까요? 이 글에서는 이러한 질문에 대한 답을 제시하고 우수한 Windows 스토어 게임을 개발하는 방법을 알려 드립니다.

Windows 8 게임 디자인 및 개발 고려 사항

Windows 8은 즐거운 엔터테인먼트 경험을 제공할 수 있도록 특별히 설계되고 엔지니어링되었습니다. Windows 8 사용자 경험(UX) 지침에는 전체 화면 이미지를 사용하고 경계나 추가적인 창 장식이 없는 빠르고 원활한 상호 작용을 제공하도록 권장합니다. 디자인 지침에는 사용자의 호응을 유도하는 경험에 집중하고, 몰입할 수 있는 환경에서 상호 작용할 수 있는 앱을 제공하도록 권장하고 있습니다. 기본 게임 컨트롤은 쉽게 찾을 수 있는 곳에 배치하고 보조 컨트롤은 사용자가 필요로 하기 전에는 눈에 잘 띄지 않도록 앱 바나 설정 패널에 배치해야 합니다. 일반 앱을 개발할 때 아주 유용한 원칙입니다. 그런데 이러한 원칙이 게임에는 어떤 영향을 미칠까요? 지금까지 게임 개발자들은 빠르고 부드러우며 전체 화면으로 제공되는 몰입도가 뛰어난 경험을 제공해 왔습니다. 그렇지만 다음과 같은 기본적인 의문이 항상 따라다녔습니다.

강력한 데스크톱 PC에서 노트북 및 태블릿으로 게임 메커니즘을 확장하려면 어떻게 해야 할까요?
어떤 폼 팩터를 주요 대상으로 삼아야 할까요?
게임 내에서 터치, 게임 컨트롤러, 키보드/마우스를 모두 지원할 수 있을까요?
가장 중요한 화면 크기, 종횡비 및 해상도는 얼마일까요?

게임 개발자들은 오래 전부터 다양한 기술을 사용하여 PC 사용자에게 재미있는 게임을 제공해 왔습니다. Windows에서 사용되는 API는 시간이 흐르면서 장족의 발전을 거듭해 왔습니다. Windows 8에는 새로운 개발 플랫폼이 추가되었습니다. Windows 런타임 API는 이전 API에서 최고의 기술만을 추출하여 성능, 보안, 개발 일관성 및 서비스를 획기적으로 개선했습니다. Windows 스토어에는 게임을 검색, 배포 및 서비스하는 새로운 방법이 추가되었습니다. 이러한 최신 API는 새로운 개발 모델을 원하는 게임 개발자에게 엄청난 가치를 제공합니다. Windows 스토어 게임 개발을 시작할 때 다음과 같은 의문이 생길 수 있습니다.

게임 개발에 가장 적합한 Windows 런타임 API는 무엇입니까?
게임 장르가 달라도 같은 개발 모델을 사용할 수 있습니까?
다른 플랫폼의 코드를 전환하려면 어떻게 해야 합니까?
기존 버전의 Windows로 작성된 코드를 업데이트하려면 어떻게 해야 합니까?
업데이트가 필요한 게임 자산은 무엇입니까?
개발 비용을 절감하는 데 도움이 되는 리소스가 있습니까?
DirectX SDK는 어디에 있습니까?

상상 그 이상의 게임

모든 게임은 아이디어에서 시작됩니다. 아이디어를 얻는 경로는 매우 다양합니다. 길을 걷다가 또는 샤워를 하다가 갑자기 아이디어가 떠오르기도 하고 동료들과 협력하여 반복 작업을 하던 중 새로운 아이디어가 떠오르기도 합니다. 일단 아이디어를 얻었으면 어떤 종류의 게임인지 결정해야 합니다. 전혀 새로운 게임을 개발할 수도 있고 기존 게임을 포팅할 수도 있습니다. 슈팅, 퍼즐, 레이싱과 같은 게임을 만들 수도 있습니다. Windows 스토어에는 모든 장르의 게임이 모여 있습니다. //build/ 2012에서 발표된 게임 사례 연구를 보면 영감을 얻는 데 많은 도움이 될 것입니다. Windows 스토어 개발자 계정을 갖고 있다면 게임의 하위 범주를 검색하여 아이디어를 얻고 지역에 따라 어떤 게임 범주가 인기를 끌고 있는지 확인할 수 있습니다.

게임 디자인 지침

어떤 게임을 만들 것인지 결정했으면 그 다음으로 프런트 엔드 디자인을 결정합니다. 그러면 나중에 개발 시간을 상당히 단축할 수 있습니다. Windows 8 게임 카테고리 디자인 지침에는 사용자의 흥미를 유발하여 타일 및 알림을 계속 확인하도록 할 수 있는 방법이 나와 있습니다. 또한 어떤 전체 레이아웃을 사용하고 기본 및 보조 컨트롤을 어디에 배치해야 하는지에 대한 조언도 제공합니다.

상호 작용에 대한 권장 사항이 제공되며 게임에 터치, 센서 및 계약을 포함시키는 방법도 설명되어 있습니다. 게임 메커니즘 및 컨트롤을 최대한 빨리 결정해서 개발 범주를 확정해야 합니다. 하지만 Windows 런타임 플랫폼을 사용하면 같은 코드를 사용하여 더욱 간편하게 터치, 펜(잉크) 및 마우스를 지원할 수 있으므로 폼 팩터마다 특별한 메커니즘을 디자인할 필요는 없습니다. 모든 Windows PC에는 게임 컨트롤러를 연결하는 위치가 있습니다. 게임을 개발할 때 이 컨트롤 메커니즘을 꼭 사용해 보시기 바랍니다.

어떻게, 어떤 속도로 플레이어에게 게임 상호 작용과 메커니즘을 소개할 것인지에 대한 계획을 세워야 합니다. 너무 느리면 흥미를 잃게 되고 너무 빠르면 포기하게 됩니다. 아마도 가장 중요한 것은 사용할 수익 모델과 상거래 플랫폼을 결정하는 일일 것입니다. Windows 스토어에서는 개발자가 비즈니스 모델을 선택할 수 있습니다. Windows 스토어는 무료 게임, 광고 기반, 앱 내 구매 및 다운로드 가능 콘텐츠를 지원합니다. 기본적으로 제공되는 시간제 또는 기능제 평가판을 Windows 스토어 게임에 사용할 수 있습니다. 또는 타사 상거래 제공업체를 이용하거나 개발자가 직접 만든 것을 사용할 수도 있습니다. 어떤 방법을 선택하든 게임의 성공, 즉 수익이나 인기에 영향을 미치는 중요한 요소이므로 신중하게 고민해야 합니다.

다른 Windows 스토어 앱과 마찬가지로 게임 역시 다양한 활성화, 보기 및 일시 중지 상태를 지원해야 합니다. 디자인 지침을 보면 게임을 일시 중지하는 방법과 시기, 게임 상태를 일시 중지하는 방법과 시기, 전체 화면/동시 보기/전체 보기 상태를 처리하는 방법을 결정할 때 고려할 사항이 설명되어 있습니다. 게임에서 가로 및 세로 방향을 지원하는 방법을 결정해야 합니다. 여러 화면 크기에 맞게 게임 자산의 해상도를 조정할 때 대상 및 기타 화면 컨트롤의 크기를 고려해야 합니다. 화면 종횡비, 해상도 및 DPI 설정도 고려해야 합니다. 이러한 점에 주의한다면 어떤 화면 크기, 어떤 배율에서도 게임 콘텐츠가 정확하게 렌더링될 것입니다.

마지막으로, 게임의 접근성과 소셜 네트워킹 기능을 강화하는 데 도움이 되는 몇 가지 팁이 더 있습니다. 고대비 모드와 추가 오디오 대기열은 가시성을 높이고 게임하기 좋은 환경을 만드는 데 도움이 되므로 조명 조건이 좋지 않거나 시각 장애가 있는 플레이어를 위해 도입하는 것이 좋습니다. 또한 플랫폼에서 기본적으로 제공되는 온라인 ID(인증), 데이터 로밍 및 다른 앱과의 공유 기능을 사용하면 게임 결과를 비교하거나 여러 PC에서 게임을 하는 등의 소셜 활동을 통해 사용자의 참여도를 높일 수 있습니다.

게임 개발 지침

DirectX는 Windows 게임 개발 플랫폼의 핵심으로 간주되고 있습니다. 하지만 그 외에도 여러 구성 요소가 개발되어 Windows 8 SDK로 전환되었고 그 결과 다양한 Windows 게임 에코시스템을 지원하는 데 필요한 모든 기능이 플랫폼에 탑재되었습니다. Windows 게임 개발 플랫폼은 일관적이고 포괄적인 개발 방법을 제공합니다. 다른 게임 개발 플랫폼의 모범 사례도 적용했습니다. 하지만 핵심 아키텍처 목표 두 가지에 역점을 두어 관찰했다는 점이 가장 주목할 만합니다. 아키텍처를 결정할 때 가장 중요한 것이 성능 및 전력 소모라는 점은 Windows 8 그래픽의 뛰어난 하드웨어 가속 성능 블로그 글에서 설명했습니다. Windows 8은 전체 플랫폼이 빠르고 원활한 엔터테인먼트 경험을 제공하도록 설계되었기 때문에 간편하게 게임을 개발할 수 있습니다.

게임 개발에서 선호하는 언어는 C++와 DirectX

Windows 런타임은 편리하고 일관적인 방법으로 모든 최신 장치 및 센서를 노출하고 Windows 이벤트를 간단하게 처리할 수 있는 풍부한 API를 제공합니다. Windows SDK는 하나밖에 없기 때문에 Windows 스토어 게임 개발에 필요한 모든 API를 Microsoft Visual Studio 2012에서 얻을 수 있습니다. 현실적이고 몰입도가 뛰어난 경험을 제공하려면 Windows 8 DirectX API를 사용하여 3D 게임을 구축하는 것이 좋습니다. 가장 간편하게 게임을 개발할 수 있는 DirectX 버전으로, DirectX 9.1부터 DirectX 11.1의 최신 하드웨어 기능까지 광범위한 그래픽 수준을 지원하므로 전력 효율성이 좋은 ARM 기반 휴대용 Windows 8 태블릿 PC에서 오버클록된 다중 GPU 게이머 장치에 이르는 모든 PC에 최적화된 게임을 개��할 수 있습니다.

특정 개발 언어를 자유롭게 다룰 수 있는 분이라면 Windows 8에서도 기존의 기술과 경험을 대부분 사용할 수 있습니다. 개발하는 게임 종류 및 개발자의 기호에 따라 다양한 기술을 결합하여 Windows 스토어 게임을 개발할 수 있습니다. 구문 또는 모델에 대한 어떠한 제약도 없습니다. 관리 코드 개발자는 Windows 스토어 플랫폼의 강점과 기능을 활용하는 XAML로 재미있고 부드럽게 작동하는 2D 게임을 개발할 수 있습니다. 웹 개발자의 경우 웹 및 웹 게임을 개발하던 기존의 기술을 잘 활용하면 Windows 스토어를 통해 수익성이 높은 게임을 개발할 수 있습니다. 3D 대화형 게임의 경우 C++와 DirectX를 함께 사용할 것을(선택적으로 XAML까지 사용 가능) 권장하며 이에 대해서는 이 문서의 나머지 부분에서 집중적으로 설명하겠습니다.

게임 개발 구성 요소

Windows 8은 모든 OS 버전에서 사용하고 모든 PC에 탑재된 게임 기술을 기본적으로 제공하므로 기술을 따로 배포하거나 여러 버전을 관리할 필요가 없습니다. 추가 구성 요소를 검색, 다운로드 및 설치할 필요도 없습니다.

그림 1: Windows 8 게임 개발 구성 요소 및 라이브러리

그래픽, 오디오, 입력에서 파일 I/O, 스케줄링, 수식, 네트워킹에 이르는 모든 구성 요소를 원하는 개발 언어로 사용할 수 있습니다. 하위 수준 구성 요소는 뛰어난 유연성, 리소스 관리 및 성능을 제공하지만 처리 작업과 그에 필요한 데이터 흐름을 포괄적으로 제어하려면 코드가 추가로 필요할 수 있습니다. C++를 사용하면 Windows 8 플랫폼의 GPU, CPU 및 하위 수준 서비스와 직접 연결되므로 고성능 코드를 작성할 수 있습니다. 최신 C++/CX 언어 확장을 사용하면 C#처럼 간단한 구문을 작성할 수 있습니다. 참조를 계산하여 개체를 투명하게 관리할 수 있습니다. 하지만 게임의 원활한 수행을 저해할 수 있는 런타임 계층, 가비지 수집 또는 JIT(Just-In-Time) 컴파일 동작은 없습니다.

3D 및 2D 그래픽에서 미디어, 이미지 및 기타 게임 구성 요소의 경우 Windows 8 DirectX 기술에서 구축에 필요한 포괄적인 API 모음, 구성 요소 및 라이브러리를 제공합니다. 이에 대한 개요는 DirectX 게임 개발 시작에서 확인할 수 있습니다. 새로운 Windows 8 그래픽 스택은 통합이 강화됨에 따라 Direct2D, Direct3D, DirectVideo 및 DirectCompute 구성 요소를 손쉽게 함께 사용할 수 있게 되었으며 이전보다 리소스 중복이 줄었습니다. 또한 XInput 라이브러리를 통해 Xbox 컨트롤러를 기본적으로 지원하도록 했습니다. 자세한 내용은 DirectX 게임의 입력 및 컨트롤 작업을 참조하십시오. XAudio2로 오디오 및 사운드 믹싱을 개선한 API에 대해서는 DirectX 게임의 오디오 작업 단원에서 다루고 있으며 간소화된 수식 함수와 그 유형에 대해서는 DirectXMath 프로그래밍 지침에 설명되어 있습니다.

DirectX/C++ 개발 방식의 최대 장점 중 하나는 코드의 상당 부분을 재사용하여 Windows 스토어 게임(및 Windows 데스크톱 게임), Windows Phone 게임, Xbox 360 게임을 만들 수 있다는 것입니다. DirectX API는 모든 Microsoft 게임 플랫폼과 관련되어 있습니다. 우수한 Windows 게임을 개발하는 데 필요한 모든 것은 런타임, Windows SDK 및 Visual Studio 2012에 포함되어 있습니다. 기존 DirectX SDK에 대한 내용은 DirectX SDK는 어디에 있습니까?를 참조하십시오. Windows 8에서 제공하는 개발 모델이 몇 가지 더 있습니다. DirectX 및 XAML 상호 운용성을 지원하는 하이브리드 모델은 제어 기능과 성능이 우수하며 사용법이 간편한 WinRT UI 도구 키트를 제공합니다.

개발 도구

우리는 Windows 스토어 게임 개발자의 요구를 만족할 수 있는 우수한 도구 모음을 제공하고 있습니다. Visual Studio 2012는 Direct3D 게임 개발을 훨씬 간편하게 시작할 수 있는 DirectX Windows 스토어 앱용 템플릿을 제공합니다. 템플릿 코드는 기본적인 보기 공급자 인프라, 창 지원 및 필요한 모든 헤더와 구성 요소에 대한 참조를 지원합니다. 그 외에 개발자가 선택하는 게임 개발 모델에 관계없이 모범 사례에 따라 게임을 개발할 수 있도록 도와주는 템플릿도 있습니다.

뿐만 아니라 Visual Studio 2012에는 게임 개발, 디버깅 및 프로파일링을 개선하는 새로운 기능이 추가되었습니다. Visual Studio 2012 그래픽 도구에 상당한 투자를 하여 그래픽 응용 프로그램 개발을 원활하게 통합할 수 있도록 했습니다. 개발자는 익숙한 IDE 인터페이스를 떠나지 않고도 3D 모델을 작업하고, 텍스처와 이미지를 보고, HLSL 셰이더를 만들고 편집하고 컴파일할 수 있습니다. 이제 Visual Studio 2012는 그래픽 API 캡처와 재생 기능이 통합되어(이전에는 Windows PIX라고 함) 이전보다 더욱 직관적으로 그래픽 작업이 많은 DirectX 응용 프로그램을 디버깅할 수 있습니다.

샘플 및 자습서

다음 샘플은 게임 개발을 신속하게 시작할 수 있는 다양한 소스 코드 예를 제공합니다. 각 샘플은 특정 기술 또는 방법에 초점을 맞추고 있습니다. 자습서와 샘플은 개발자의 수준을 염두에 두고 개발되었습니다. 이제 개발을 시작하는 분들을 위해 최소의 코드와 가장 간단한 방법부터 익혀 나가는 논리적 순서로 구성되어 있습니다. 전체 게임이 완성될 때까지 이전 샘플에 한두 가지 개념을 추가한 새로운 샘플을 제공하는 방식이 반복됩니다. Windows 스토어 앱 코드 작성(DirectX 및 C++)에는 Windows 스토어 앱의 DirectX 및 C++ 코드를 작성하기 위해 알아야 하는 내용이 설명되어 있습니다.

Direct3D 자습서: 5단계로 구성된 이 자습서는 Direct3D를 초기화하고, 표면에 그리고, 스왑 체인을 사용하여 표면에 업데이트를 표시하는 방법을 설명합니다. 이 샘플에 나오는 "회전하는 정육면체"는 다른 Direct3D 샘플을 확장한 것입니다. 따라서 Direct3D API를 처음 시작하는 분들도 쉽게 따라 할 수 있습니다.
DirectX 터치 샘플: D3D 자습서의 회전하는 정육면체에 최소의 터치 지원을 추가하는 방법을 보여 줍니다. 특히 Direct3D 애니메이션 업데이트를 Windows 런타임에서 제공하는 터치 이벤트에 연결하는 방법을 집중적으로 설명합니다. 손가락을 모으고 벌려 확대/축소하는 동작은 범프 매핑을 참조하십시오.
Direct3D 스프라이트 샘플: 스프라이트 일괄 처리 동작을 Direct3D로 구현하는 방법을 보여 주며 이는 XNA SpriteBatch API와 비슷합니다. 스프라이트는 3D 장면에서 독립적으로 전환 및 관리할 수 있는 2D 비트맵으로, 주로 2D 게임에 사용되거나 3D 게임에서 계산이 복잡하거나 멀리 있는 개체를 나타낼 때 사용됩니다.
리소스 로딩 샘플: 셰이더, 텍스처, 메시 같은 리소스 및 자산을 로드하는 방법을 보여 줍니다. 참고로, 각 콘텐츠 유형마다 프로젝트 내에서 연결된 빌드 규칙이 있습니다. 개발자는 고유의 콘텐츠 프로세서 앱을 추가하고 고유의 규칙을 만들어서 호출할 수 있습니다.
Direct3D 범프 매핑 샘플: 일반 맵과 픽셀당 조명을 사용한 범프 매핑을 보여 줍니다. 이 샘플은 일반 맵 및 컬러 텍스처를 사용하여 개체 표면을 음영 처리하는 코드를 보여 줍니다. 또한 제스처 인식기 없이 손가락을 모으고 벌려 확대/축소하는 기본적인 컨트롤 구현 방법을 설명합니다.
Direct3D 사후 처리 샘플: Windows 스토어 C++ 앱의 축소된 중간 버퍼를 Direct3D와 함께 사용하여 회전하는 간단한 정육면체를 사후 처리하는 방법을 보여 줍니다. 하드웨어의 기능 수준에 따라 두 가지 셰이더를 사용하는 방법을 보여 줍니다. 중간 렌더링 대상을 수정하여 더 작은 표면을 렌더링하도록 성능을 개선한 후 장치의 최종 기본 해상도를 높여서 품질을 높일 수 있습니다.
AUDIO2 오디오 파일 재생 샘플: 이 샘플 앱은 대기 시간이 짧은 대화형 사운드 효과에 사용되는 XAudio2 API를 DirectX 게임에 통합하여 사운드 경험을 개선하는 방법을 보여 줍니다.
XINPUT 게임 컨트롤러 샘플: DirectX 게임에 Xbox 컨트롤러 지원을 추가하는 방법을 보여 줍니다. 이 샘플은 Xbox 게임 컨트롤러의 입력을 읽어서 아날로그 스틱을 움직이고 단추를 누르는 동작에 대한 데이터를 표시합니다. Direct2D 및 DirectWrite를 사용하여 연결된 컨트롤러의 입력 상태를 읽어서 디스플레이에 표시하는 방법을 보여 줍니다.
Direct3D 입체 3D 샘플: Windows 8은 핵심 OS 기능으로써 스테레오 3D를 지원합니다. 이 앱은 DirectX 게임에 입체 3D를 넣는 방법을 보여 줍니다. Direct3D의 시스템 스테레오 변화에 응답하는 방법도 보여 줍니다.
평가판 및 앱 내 구매는 게임의 성공에 매우 중요한 요소입니다. 이 샘플에서는 Windows 스토어에서 제공하는 라이선싱 API를 사용하여 게임 또는 앱 내 구매에서 지원되는 기능의 라이선스 상태를 확인하는 방법을 보여 줍니다.

다음은 개별 기술을 결합하여 전체 게임을 완성하는 종합 샘플입니다.

DirectX 간단한 3D 슈팅 게임: 이 최종 샘플 앱과 포괄적인 코드 연습은 간단한 1인칭 슈팅 갤러리 게임에 다양한 컨트롤 유형과 DirectX 기술을 넣는 방법을 보여 줍니다. 각 기술 샘플의 기본 지식을 이미 알고 있는 분들은 현재 제공되고 있는 Windows 스토어 Direct3D 게임의 모든 구성 요소를 살펴볼 수 있는 좋은 기회입니다.
XAML DirectX 간단한 3D 슈팅 게임: C++ 앱에 DirectX(Direct3D 11.1, Direct2D, XInput, XAudio2)와 XAML을 사용하여 간단한 1인칭 3D 게임을 구현하는 방법을 종합적으로 보여 줍니다. Direct3D는 3D 콘텐츠를 렌더링하는 데 사용되고 XAML은 HUD(heads-up display)와 게임 상태 메시지에 사용됩니다.
DirectX Marble Maze 게임 샘플: 플레이어가 기울이기 컨트롤을 사용하여 온갖 위험으로 가득한 미로 사이로 대리석을 굴려 통과하는 간단한 미로 게임 앱입니다. 모든 게임 구성 요소를 단일 응용 프로그램에 맞추는 방법을 보여 줍니다. 또한 완전한 코드 연습의 형태로 이 앱에 대한 다양한 지침을 제공하고 있습니다.

게임 개발을 위한 기술

게임 개발과 깊게 관련된 개발 패턴, 모범 사례 및 기술을 살펴볼 필요가 있습니다.

다양한 Direct3D 기능 수준용 개발에서는 그래픽 성능이 서로 다른 여러 장치에서 게임을 최적화하는 방법을 설명합니다. DirectX와 C++를 함께 사용하여 Windows용으로 개발한 Windows 스토어 게임의 고객층을 확장하는 데 도움이 됩니다.
비동기 프로그래밍에서는 게임에서 다중 코어 및 하이퍼 스레드 CPU를 최대한 활용하는 방법을 설명합니다. 게임의 그래픽, 오디오, 논리, 파일 I/O 및 네트워킹을 모두 병렬 처리하면 최고의 성능과 긴 배터리 수명을 제공할 수 있습니다.
Windows 스토어 게임에는 스레드 풀 병렬 처리를 사용합니다. CreateThread 같은 기존의 스레딩 API는 사용하지 않습니다. 이 글에도 설명되어 있지만 UI를 렌더링하고 응답 속도를 높이는 데 있어서 작업 모델은 매우 중요합니다.
화면 방향 지원에서는 화면 회전, 콘텐츠 DPI 조정, DirectX 응용 프로그램 입력을 다룹니다. 다양한 화면 해상도에서 잘 작동하는 게임을 만드는 데 도움이 됩니다.
게임에 마우스 이동/보기 컨트롤 추가에서는 Windows 스토어 개발 모델에 터치를 추가하는 데 사용된 기존의 마우스와 비슷한 탐색 기술을 설명합니다.
마우스 컨트롤 개발에서는 시스템 커서를 숨기고 절대값 대신 화면의 상대 좌표를 반환하는 상대적 마우스 컨트롤 구현에 대해 설명합니다.
게임 게시 요구 사항에서는 Windows 8 게임 개발자에게 등급 인증이나 패키징 같은 일반적인 게임 게시 시나리오에 제공되는 도구 및 지원에 대해 설명합니다.
Windows RT 및 ARM 프로세서 지원에서는 Direct3D 기능 수준 9_1을 목표로 ARM 패키지를 컴파일하여 Windows RT 장치에서 DirectX Windows 스토어 게임을 실행하는 방법을 설명합니다.

개발 시간 또는 비용을 절감하는 미들웨어 사용

고품질의 우수한 게임을 개발하려면 비용이 많이 듭니다. 여러 플랫폼에서 실행되는 게임을 개발하는 과정은 복잡하고, 오류가 자주 발생하고, 비용도 많이 듭니다. 여러 유명 게임 스튜디오에서 게임 개발 프로세스 또는 "파이프라인"을 구성하는 도구와 생산 기술을 개발하고 있습니다. 이를 통해 게임 자산을 다양한 게임과 플랫폼에 활용할 수 있습니다. 렌더링 엔진, 사용자 인터페이스 도구 키트, 가시성 폐색, 물리학 시뮬레이터, 오디오 비디오 제작, 애니메이션 보간, 인공 지능 등은 게임 개발에 일반적으로 사용되는 기술 카테고리 중 극히 일부에 불과합니다. 어떤 게임 기술은 개발하고 보완하는 데 몇 년이 걸릴 수도 있습니다.

게임 파이프라인은 매우 가치가 높기 때문에 여러 스튜디오에서는 게임 만큼이나 파이프라인에도 전략적 투자를 고려하고 있습니다. 하지만 모든 사람이 파이프라인 개발에 시간과 비용을 투자할 여력이 있는 것은 아닙니다. 다행히도 타사 공급업체에서 이러한 기능을 제공하는 종단간 게임 개발 파이프라인이나 개별 기술 라이브러리를 제공하고 있습니다. Windows 8이 출시된 후로 여러 게임 미들웨어 공급업체에서 기존 제품을 새로운 Windows 스토어 앱 모델로 전환했습니다. 이러한 제품을 사용하면 위험을 크게 줄이면서도 훨씬 빨리 Windows 스토어에 게임을 게시할 수 있습니다. 시간이 지나면 Windows 스토어 게임 개발용 제품을 출시하는 공급업체가 점차 늘어날 것입니다. 다음은 이 글을 작성한 시점을 기준으로 Windows 8 게임 개발을 지원하는 제품 버전을 발표 또는 출시한 타사 게임 미들웨어 공급업체를 알파벳 순서로 정리한 목록입니다.

Appcelerator	appMobi {!}	Audiokinetic Wwise
Autodesk Scaleform	Cocos2d	Epic Unreal Engine 3
Exit Games Photon Server	Fortumo Mobile Payments	Firelight Technologies FMOD
GameSalad Creator	Havok Physics	Havok Vision Engine
MonoGame	Ogre Rendering Engine	NVIDIA PhysX
Scirra Construct 2	SharpDX	ShiVa3D
SlimDX	Unigine Engine	Unity 3d
Yoyo Games GameMaker

Microsoft’s XNA Game Studio는 Xbox 360, Windows Phone 및 Windows를 대상으로 하는 게임 개발 파이프라인입니다. 하지만 Windows 스토어 게임 개발과 호환되지 않습니다(XNA 게임은 Windows 8의 데스크톱 앱으로 지원됨). Visual C++/CX를 사용한 DirectX 개발은 XNA의 패턴과 사례를 많이 차용했기 때문에 개념적으로 상당히 비슷합니다. 따라서 XNA 게임 개발자들은 비교적 어려움 없이 DirectX 및 C++ 개발로 전환할 수 있을 것입니다. XNA Game Studio 기능을 상당히 많이 모사한 오픈 소스 MonoGame 라이브러리를 적절하게 사용하여 큰 성공을 거둔 개발자들도 있습니다. XNA로 개발된 게임 자산을 Windows 스토어에 활용했다는 기사도 여러 차례 보도되었습니다. 이 주제에 대한 자세한 내용은 링크를 참조하십시오.

게임 개발을 위한 추가 리소스

MSDN의 게임 개발 전용 문서
//build/ 2012의 게임 중심 세션, 슬라이드 및 대화 내용
GDC 2012의 게임 중심 세션, 슬라이드 및 대화 내용
//build/ 2011의 게임 중심 세션, 슬라이드 및 대화 내용
개발자들이 필요할 때마다 질문과 답변을 주고받는 개발자 센터의 게임 개발 전용 포럼
Direct3D 11 C++ 코드 작성을 위한 도우미 클래스를 모아 놓은 DirectX 도구 키트
그 밖의 유용한 리소스를 찾을 수 있는 Chuck Walbourn의 블로그 및 Shawn Hargreaves의 블로그

요약

Windows 8은 게임에 가장 적합한 새로운 폼 팩터, 혁신적인 기술, 수익성이 높은 상거래 모델로 PC 환경을 바꾸어 놓았습니다. 새로운 이 플랫폼을 잘 활용하는 개발자에게 무한한 가능성이 열려 있습니다. 이 글을 작성하는 시점에도 Windows 스토어에 수천 개의 게임이 제공되고 있으며 날마다 그 수가 늘어나고 있습니다. 개발자들이 우수한 Windows 스토어 게임을 개발하여 성공을 거두려면 무엇을 해야 하는지 알리기 위해 이 글을 작성했습니다. 손쉬운 방법으로 창의적이고, 수익성이 높은 게임을 개발할 수 있도록 Windows 8에서 제공하는 기능을 설명하는 데 초점을 맞추었습니다. 플랫폼에서 제공하는 도구, 기술 및 서비스와 타사 기술을 살펴보았습니다. 샌프란시스코에서 매년 열리는 GDC(Game Developer Conference)가 얼마 남지 않은 이 시점에서 이 글이 Windows 스토어 게임 개발을 위한 길잡이가 되기를 바랍니다.

게임 개발은 계속되어야 합니다!

수석 프로그램 관리자, Shai Hinitz

생생한 활동 업데이트 3부: 푸시 알림 및 Windows Azure Mobile Services

Windows 8 Team — Fri, 29 Mar 2013 17:37:59 GMT

이 시리즈의 1부에서는 "생생함"이라는 것이 사용자에게 주는 의미, 그리고 생생한 경험을 구축하는 데 있어서 앱이 어떤 역할을 하는지에 대해 살펴보았습니다. 2부에서는 웹 서비스를 작성하고 디버깅하여 라이브 타일의 주기적 업데이트를 지원하는 방법을 살펴보았습니다. 이 시리즈의 완결편인 이번 3부에서는 WNS(Windows 푸시 알림 서비스)를 통해 요청이 있을 때 특정 클라이언트 장치에 타일 업데이트, 알림 및 원시 알림을 제공하는 방법과 Windows Azure Mobile Services에서 전체 프로세스를 간소화하는 방식에 대해 알아보겠습니다.

푸시 알림

2부에서 살펴본 것처럼 주기적 업데이트는 클라이언트 쪽에서 실행되며 타일이나 배지를 업데이트하는 폴링 또는 "pull" 메서드를 지원합니다. 서비스에서 업데이트를 장치로 직접 보내면 "푸시" 알림이 발생하며, 이 경우 해당 업데이트가 특정 사용자, 앱 및 보조 타일에만 적용될 수 있습니다.

푸시 알림은 폴링과는 달리 언제든지 발생할 수 있으며 발생 빈도 또한 매우 높습니다. 하지만 장치가 배터리를 사용 중이고 연결된 대기 상태이거나 알림 트래픽이 과도하게 발생할 경우 Windows가 장치의 푸시 알림 트래픽의 양을 제한합니다. 즉, 모든 알림이 반드시 전달되는 ��은 아니며 특히 장치가 꺼져 있으면 알림이 전달되지 않을 확률이 더 높아집니다.

따라서 푸시 알림을 사용하여 빈도 또는 시간 확인 기능이 비슷한 시계 타일 또는 기타 타일 가젯을 구현하려 하면 안 됩니다. 그보다는 푸시 알림을 사용하여 사용자에게 중요한 의미가 있거나 사용자가 관심을 보일 만한 백엔드 서비스에 타일 및 알림을 연결하는 방법을 생각해 보시기 바랍니다. 이렇게 하면 사용자가 여러분의 앱을 자주 방문하도록 유도할 수 있습니다.

자세한 내용으로 넘어가기 전에, 푸시 알림을 크게 두 종류로 나누어 살펴보겠습니다.

타일이나 배지 업데이트가 포함된 XML 업데이트 또는 알림 메시지 페이로드: Windows는 이러한 푸시 알림을 처리하고, 앱을 대신하여 업데이트 또는 알림을 실행할 수 있습니다. 원한다면 앱에서 이러한 알림을 직접 처리할 수도 있습니다.
서비스에서 보낼 데이터가 들어 있는 이진 또는 '원시' 알림: 앱별 코드로 처리하지 않으면 Windows가 데이터로 어떤 작업을 해야 할지 알 수 없기 때문에 이러한 알림은 '반드시' 앱별 코드로 처리해야 합니다. 페이로드 5KB 크기 제한, Base64 인코딩 등에 대한 자세한 내용은 원시 알림에 대한 지침 및 검사 목록을 참조하십시오.

두 가지 중 어떤 경우에 해당하든, 실행 중인(포그라운드) 앱이 PushNotificationChannel 클래스 및 이 클래스의 PushNotificationReceived 이벤트를 통해 푸시 알림을 직접 처리할 수 있습니다. XML 페이로드의 경우 앱에서 콘텐츠를 수정하고, 태그를 변경하는 등의 작업을 수행한 후 로컬에서 실행하거나 무시할 수 있습니다. 원시 알림의 경우 앱에서 콘텐츠를 처리한 후 알림이 있으면 어떤 알림을 실행할지 결정합니다.

앱이 일시 중지 상태이거나 실행되지 않을 때도 같은 목적으로 백그라운드 작업을 제공할 수 있습니다. 반드시 앱의 요청이 있고 앱이 잠금 화면에 액세스할 수 있어야 합니다. 그래야만 알림을 받을 때 앱별 코드가 실행됩니다.

알림이 도착하면 일반적으로 백그라운드 작업에서 다음과 같은 한두 가지 동작이 수행됩니다. 첫째, 알림의 관련 정보를 로컬 앱 데이터로 저장합니다. 다음에 앱이 활성화되거나 재개될 때 앱에서 이 정보를 검색할 수 있습니다. 둘째, 백그라운드 작업에서 로컬 타일과 배지 업데이트 및/또는 알림 메시지를 실행할 수 있습니다.

일반적인 이메일 앱을 떠올려 보면 원시 알림을 보다 쉽게 이해할 수 있습니다. 백엔드 서비스는 사용자에게 전송되는 새 메시지를 탐지하면 여러 이메일 메시지 헤더가 들어 있는 원시 푸시 알림 또는 WNS를 보냅니다. 이때 서비스에서는 해당 사용자의 특정 장치에 설치된 특정 앱과 연결되어 있는 '채널 URI'를 사용하여 이 작업을 수행합니다.

그런 다음 WNS가 해당 알림을 클라이언트로 푸시합니다. 작업이 성공하면 Windows가 해당 알림을 받아서 이 채널 URI와 연결된 앱을 검색합니다. 해당하는 앱을 찾을 수 없으면 알림이 무시됩니다. 어떤 앱이 있고 그 앱이 실행 중이라면 Windows는 'PushNotificationReceived' 이벤트를 실행하고 그렇지 않으면 해당 앱에 대해 실행할 수 있는 백그라운드 작업을 찾아서 호출합니다.

둘 중 어디에 해당하든 원시 알림은 결국 앱 코드에 의해 실행되어 그 후 데이터를 처리하고, 앱 타일에 배지 업데이트를 실행하여 새 메시지 개수를 표시하고, 메시지 헤더가 있는 순환 타일 업데이트를 최대 5개까지 실행합니다. 또한 앱에서는 새 메시지가 도착할 때마다 알림 메시지를 표시할 수도 있고 새 메일이 있다는 사실을 알리는 알림 메시지를 하나 이상 표시할 수도 있습니다.

결과적으로 알림은 사용자에게 새 메일이 도착했다는 사실을 알려 주고, 시작 화면의 앱 타일은 새로운 이메일 소식을 신속하게 확인할 수 있는 정보를 제공합니다.

이러한 클라이언트 쪽 이벤트 처리기 및 백그라운드 작업에 대한 자세한 내용은 원시 알림 샘플, 이 블로그의 오프스크린 상태에서 앱의 효율성 높이기 - 백그라운드 작업, 그리고 백그라운드 네트워킹 백서를 참조하십시오. 지금부터는 이 글의 본래 목적인 서비스 쪽 이야기로 넘어가겠습니다.

WNS(Windows 푸시 알림 서비스) 작업

Windows, 앱, 서비스 및 WNS가 협력적으로 작동하기 때문에 특정 사용자의 특정 장치에 있는 특정 앱 타일 또는 알림이나 원시 알림 처리기에 사용자별 데이터를 제공할 수 있습니다. 아래는 이러한 관계를 그림으로 나타낸 것입니다.

이 모든 작업이 원활하게 수행되려면 다음과 같은 배선 작업이 필요합니다.

개발자가 Windows 스토어에 앱을 등록하여 푸시 알림을 사용합니다. 그러면 서비스가 WNS로 인증할 때 사용하는 SID 및 클라이언트 암호가 제공됩니다. 보안을 위해 이러한 정보를 클라이언트 장치에 저장하면 절대 안 됩니다.
런타임에서 앱은 각 라이브 타일(기본 및 보조)에 사용하거나 원시 알림에 사용할 Windows의 WNS 채널 URI를 요청합니다. 앱에서는 다른 백그라운드 작업에 사용할 수 있도록 30일마다 이러한 채널 URI를 새로 고쳐야 합니다.
앱 서비스에서는 날씨 업데이트 위치나 특정 사용자 계정 및 활동 같은 사용법을 설명하는 데이터와 함께 앱이 채널 URI를 업로드할 수 있는 URI를 제공합니다. 서비스는 나중에 사용할 수 있도록 이러한 채널 URI 및 연결된 데이터를 URI를 받는 즉시 저장합니다.
서비스는 백엔드를 모니터링하여 각 특정 사용자/장치/앱/타일 조합에 적용되는 변경 사항을 확인합니다. 특정 채널의 알림을 트리거하는 조건이 감지되면 서비스는 해당 XML 또는 원시 알림 콘텐츠를 작성하고, SID 및 클라이언트 암호를 사용하여 WNS에 인증한 후 WNS에 채널 URI와 함께 알림을 보냅니다.

각 단계를 자세히 살펴보겠습니다. 한 가지를 미리 알려 드리자면, HTTP 요청 처리에 어려움을 느끼는 분들을 위해 Windows Azure Mobile Services가 대부분의 작업을 대신 처리합니다. 이에 대해서는 천천히 살펴보겠습니다.

Windows 스토어에 앱 등록

서비스에 사용할 SID 및 클라이언트 암호를 얻는 방법은 Windows 개발자 센터의 WNS(Windows 푸시 알림 서비스)로 인증하는 방법을 참조하십시오. SID는 WNS로 앱을 식별하는 역할을 하고, 서비스는 클라이언트 암호를 사용하여 앱에 알림을 보낼 수 있다는 내용을 WNS로 전달합니다. 다시 한 번 강조하지만 이러한 정보는 반드시 서비스에 저장해야 합니다.

WNS(Windows 푸시 알림 서비스)로 인증하는 방법의 4단계 "클라우드 서버의 자격 증명을 WNS로 보내기"는 서비스에서 푸시 알림을 보낼 때만 하면 되는 작업입니다. 이에 대해서는 잠시 후에 다루겠습니다. 현재 단계에서는 서비스가 알림을 보낼 때 필요한 주요 부품 중 하나인 채널 URI가 없는 상태이기 때문입니다.

채널 URI 획득 및 새로 고침

클라이언트 앱은 런타임에 Windows.Networking.PushNotifications.PushNotificationChannelManager 개체를 통해 채널 URI를 획득합니다. 이 개체에는 다음 두 가지 메서드만 있습니다.

createPushNotificationChannelForApplicationAsync: 앱의 기본 타일에 사용할 채널 URI와 알림 및 원시 알림을 만듭니다.
createPushNotificationChannelForSecondaryTileAsync: 'tileId' 인수에 의해 식별되는 특정 보조 타일에 사용할 채널 URI를 만듭니다.

두 비동기 작업의 결과는 PushNotificationChannel 개체입니다. 이 개체의 'Uri' 속성에는 채널 URI와 해당 채널을 새로 고쳐야 하는 기간을 나타내는 'ExpirationTime'이 들어 있습니다. 'Close' 메서드는 필요에 따라 채널을 구체적으로 종료하는데 사용되며, 앱이 포그라운드에 있고 이 채널을 통해 푸시 알림을 받을 때 실행되는 'PushNotificationReceived' 이벤트가 가장 중요합니다.

URI의 수명은 30일입니다. 30일이 지나면 WNS가 해당 채널에 대한 모든 요청을 거부합니다. 따라서 위에서 설명한 'create' 메서드를 앱 코드에 사용하여 적어도 30일마다 URI를 새로 고쳐서 서비스로 보내야 합니다. 다음은 이에 적합한 계획입니다.

처음 실행할 때, 채널 URI를 요청하고 로컬 앱 데이터의 'Uri' 속성에 문자열을 저장합니다. 채널 URI는 장치에만 적용되므로 로밍 앱 데이터에 저장하면 안 됩니다.
두 번째 실행부터는 채널 URI를 다시 요청하여 이전에 저장한 채널 URI와 비교합니다. 두 채널 URI가 서로 다를 경우 서비스로 보내거나 필요하다면 서비스에서 기존 채널 URI를 대체하도록 합니다.
또한 앱이 30일 넘게 일시 중단 상태일 수도 있으므로 앱의 'Resuming' 처리기에서 이전 단계를 수행합니다(본 문서의 시작, 다시 시작 및 멀티태스킹 참조).
앱이 30일 이내에 실행되지 않을 경우를 대비하여 유지 관리 트리거로 며칠 또는 일주일 간격으로 실행되는 백그라운드 작업을 구현합니다. 자세한 방법은 오프스크린 상태에서 앱의 효율성 높이기 - 백그라운드 작업을 참조하십시오. 이 경우의 백그라운드 작업은 앱이 채널을 요청할 때와 동일한 코드를 실행하여 서비스로 채널을 보냅니다.

서비스로 채널 URI 보내기

일반적으로 푸시 알림 채널은 이메일 상태, 메신저 대화, 기타 개인 설정된 정보 등 사용자별 업데이트와 함께 작동합니다. 서비스가 모든 사용자 및/또는 모든 타일에 같은 알림을 보내야 하는 경우는 거의 없습니다. 따라서 서비스는 각 채널 URI를 보다 구체적인 정보와 연결해야 합니다. 메일 앱의 경우 사용자 ID로 검사할 계정을 지정하기 때문에 사용자 ID가 가장 중요합니다. 반면 날씨 앱은 각 채널 URI를 특정 위도 및 경도와 연결합니다. 그러면 각 타일(기본 및 보조)이 고유한 위치를 나타냅니다.

앱에서 서비스에 채널 URI를 보낼 때는 이러한 구체적인 정보를 함께 담아서 보내야 하며 서비스에서는 이러한 정보를 나중에 사용할 수 있도록 저장해야 합니다.

사용자 ID의 보안이 우려된다면 서비스별 자격 증명을 사용하거나 Facebook, Twitter, Google 또는 사용자의 Microsoft 계정 같은 OAuth 공급자를 통해 앱에서 별도의 서비스로 사용자를 인증하도록 하는 것이 가장 좋습니다. OAuth를 사용하면 Windows Azure Mobile Services에 여러 가지로 도움이 되며 이에 대해서는 나중에 살펴보겠습니다. 어떤 사정으로 인해 이 방법을 사용할 수 없다면 서비스로 보내는 모든 사용자 ID를 암호화하거나 HTTPS를 통해 사용자 ID를 보내야 합니다.

헤더에 연결하든지, 메시지 본문의 데이터를 통해 보내든지, 서비스 URI의 매개 변수로 보내든지 이 정보를 보내는 방식은 개발자의 선택입니다. 이 부분의 통신은 철저하게 앱과 서비스 사이에서 발생합니다.

예를 하나 들어보겠습니다. 'receiveuri.aspx'라는 페이지(다음 단원에서 나올 페이지)를 사용하는 어떤 서비스가 있고 이 페이지의 전체 주소는 'url'이라는 변수에 있다고 가정해 봅시다. 다음 코드는 앱에 사용할 기본 채널 URI를 Windows에 요청하여 HTTP를 통해 해당 페이지에 게시합니다. 이 코드는 푸시 및 주기적 알림 클라이언트 쪽 샘플을 가져와서 간단하게 고친 것으로, 'itemId' 변수를 다�� 곳에 정의하여 보조 타일을 식별하는 데 사용했습니다. 또한 여기에는 보이지 않지만 이 샘플에는 C++ 변형도 들어 있습니다.

JavaScript:

Windows.Networking.PushNotifications.PushNotificationChannelManager
    .createPushNotificationChannelForApplicationAsync()
    .done(function (channel) {
        //Typically save the channel URI to appdata here.
        WinJS.xhr({ type: "POST", url:url,
            headers: { "Content-Type": "application/x-www-form-urlencoded" },
            data: "channelUri=" + encodeURIComponent(channel.uri) 
                + "&itemId=" + encodeURIComponent(itemId)
        }).done(function (request) {
            //Typically update the channel URI in app data here.
        }, function (e) {
            //Error handler
        });
    });

C#:

using Windows.Networking.PushNotifications;

PushNotificationChannel channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(url);
webRequest.Method = "POST";
webRequest.ContentType = "application/x-www-form-urlencoded";
byte[] channelUriInBytes = Encoding.UTF8.GetBytes("ChannelUri=" + WebUtility.UrlEncode(newChannel.Uri) + "&ItemId=" + WebUtility.UrlEncode(itemId));

Task<Stream> requestTask = webRequest.GetRequestStreamAsync();
using (Stream requestStream = requestTask.Result)
{
    requestStream.Write(channelUriInBytes, 0, channelUriInBytes.Length);
}

다음 ASP.NET 코드는 이 HTTP POST를 처리하는 기본적인 'receiveuri.aspx' 페이지를 구현하는 것으로, 해당 항목의 유효한 채널 URI, 사용자 및 식별자를 수신하도록 합니다.

"기본" 코드라는 것을 강조한 이유는 보시다시피 'SaveChannel' 함수가 요청 콘텐츠를 고정된 텍스트 타일에 쓰기만 할 뿐 여러 사용자로 확대되지는 않기 때문입니다. 물론 실제 서비스에서는 이 용도로 사용하는 데이터베이스가 따로 있지만 구조는 이와 비슷합니다.

<%@ Page Language="C#" AutoEventWireup="true" %>

<script runat="server">

protected void Page_Load(object sender, EventArgs e)
{
    //Output page header
    Response.Write("<!DOCTYPE html>\n<head>\n<title>Register Channel URI</title>\n</head>\n<html>\n<body>");
    
    //If called with HTTP GET (as from a browser), just show a message.
    if (Request.HttpMethod == "GET")
    {
        Response.StatusCode = 400;
        Response.Write("<p>This page is set up to receive channel URIs from a push notification client app.</p>");
        Response.Write("</body></html>");
        return;
    }

    if (Request.HttpMethod != "POST") {
        Response.StatusCode = 400;
        Response.Status = "400 This page only accepts POSTs.";
        Response.Write("<p>This page only accepts POSTs.</p>");
        Response.Write("</body></html>");        
        return;
    }
    
    //Otherwise assume a POST and check for parameters    
    try
    {
        //channelUri and itemId are the values posted from the Push and Periodic Notifications Sample in the Windows 8 SDK
        if (Request.Params["channelUri"] != null && Request.Params["itemId"] != null)
        {
            // Obtain the values, along with the user string
            string uri = Request.Params["channelUri"];
            string itemId = Request.Params["itemId"];
            string user = Request.Params["LOGON_USER"];
                 
            //TODO: validate the parameters and return 400 if not.
            
            //Output in response
            Response.Write("<p>Saved channel data:</p><p>channelUri = " + uri + "<br/>" + "itemId = " + itemId + "user = " + user + "</p>");

            //The service should save the URI and itemId here, along with any other unique data from the app such as the user;
            SaveChannel(uri, itemId, user);

            Response.Write("</body></html>");
        }
    }
    catch (Exception ex)
    {
        Trace.Write(ex.Message);
        Response.StatusCode = 500;
        Response.StatusDescription = ex.Message; 
        Response.End();
    }
}
</script>

protected void SaveChannel(String uri, String itemId, String user)
{
    //Typically this would be saved to a database of some kind; to keep this demonstration very simple, we'll just use
    //the complete hack of writing the data to a file, paying no heed to overwriting previous data.
    
    //If running in the debugger on localhost, this will save to the project folder
    string saveLocation = Server.MapPath(".") + "\\" + "channeldata_aspx.txt";
    string data = uri + "~" + itemId + "~" + user;

    System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();
    byte[] dataBytes = encoding.GetBytes(data);

    using (System.IO.FileStream fs = new System.IO.FileStream(saveLocation, System.IO.FileMode.Create))
    {
        fs.Write(dataBytes, 0, data.Length);
    }

    return;
}

이 서비스의 코드는 제가 무료로 제공하고 있는 전자책의 13장 'HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍', 그 중에서도 특히 HelloTiles 샘플을 보면 잘 나와 있습니다. 이 샘플은 이전에 언급했듯이 클라이언트 쪽 SDK 샘플과 작동하도록 설계되었습니다. 로컬 호스트가 지원되는 상태에서 Visual Studio 2012 Ultimate 또는 Visual Studio Express 2012 for Web 같은 디버거로 HelloTiles을 실행하면 'http://localhost:52568/HelloTiles/receiveuri.aspx'와 같은 URL이 생성됩니다. 이 URL을 클라이언트 쪽 SDK 샘플에 붙여 넣으면 됩니다. 샘플이 해당 URL에 요청을 보내면 여러분은 서비스 내의 아무 중단점에서 중지하여 코드를 살펴볼 수 있습니다.

알림 보내기

실제 서비스에는 데이터 원본을 모니터링하면서 적절한 시기가 되면 특정 사용자에게 푸시 알림을 보내는 지속적인 프로세스가 있을 것입니다. 이 동작은 다음과 같은 여러 가지 방식으로 발생합니다.

알림이 실행되는 빈도에 따라 예약된 작업을 통해 특정 위치의 날씨 알림을 확인하고(예: 15-30분마다 한 번) 그에 대한 응답으로 푸시 알림을 실행할 수 있습니다.
백엔드 메시징과 같은 다른 서비스는 새 메시지가 준비되면 서버의 한 페이지에 요청을 보낼 수 있습니다. 그러면 해당 페이지에서 적절한 알림을 실행합니다.
사용자가 서버에서 해당 페이지와 상호 작용할 때 사용자의 작업이 특정 채널에 푸시 알림을 트리거합니다.

요약하면 푸시 알림을 트리거하는 방식은 여러 가지가 있으며 그 중에서 백엔드 서비스 또는 웹 사이트의 특성에 따라 전적으로 결정됩니다. 이 글의 목적에 맞도록 13장 'HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍'에 있는 동일한 HelloTiles 샘플 서비스에 'sendBadgeToWNS.aspx'라는 페이지를 넣었습니다. 이 페이지는 사용자가 브라우저에서 해당 페이지를 방문할 때마다 이전에 텍스트 파일에 저장된 채널 URI를 사용하여 푸시 알림을 보냅니다. 실제 서비스에서는 파일 콘텐츠를 읽는 대신 데이터베이스를 조회하여 채널 URI를 가져오지만 전체적인 구조는 매우 비슷하다는 점을 다시 한 번 강조합니다.

ASP.NET 페이지:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="sendBadgeToWNS.aspx.cs" Inherits="sendBadgeToWNS" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">    
    <title>Send WNS Update</title>
</head>
<body>
    <p>Sending badge update to WNS</p>    
</body>
</html>

숨겨진 C# 코드:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Net;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Json;
using System.Text;

public partial class sendBadgeToWNS : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        //Load our data that was previously saved. A real service would do a database lookup here
        //with user- or tile-specific criteria.
        string loadLocation = Server.MapPath(".") + "\\" + "channeldata_aspx.txt
        byte[] dataBytes;
        
        using (System.IO.FileStream fs = new System.IO.FileStream(loadLocation, System.IO.FileMode.Open))
        {
            dataBytes = new byte[fs.Length];
            fs.Read(dataBytes, 0, dataBytes.Length);
        }

        if (dataBytes.Length == 0)
        {
            return;
        }
        
        System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();

        string data = encoding.GetString(dataBytes);
        string[] values = data.Split(new Char[] { '~' });
        string uri = values[0]; //Channel URI
        string secret = "9ttsZT0JgHAFveYahK1B6jQbvMOIWYbm";
        string sid = "ms-app://s-1-15-2-2676450768-845737348-110814325-22306146-1119600341-293560589-2707026538";
        
        //Create some simple XML for a badge update
        string xml = "<?xml version=\"1.0\" encoding=\"utf-8\" ?>";
        xml += "<badge value='alert'/>";
                    
        PostToWns(secret, sid, uri, xml, "wns/badge");
    }
}

우리가 여기서 할 일은 채널 URI를 검색하여 XML 페이로드를 작성한 후 WNS로 인증하고 해당 채널 URI에 HTTP POST를 수행하는 것이 전부입니다. 마지막 두 단계는 Windows 개발자 센터의 빠른 시작: 푸시 알림 보내기 항목에서 가져오는 'PostToWns' 함수를 통해 실행됩니다. Windows 스토어에서 얻은 클라이언트 암호 및 SID를 사용하여 https://login.live.com/accesstoken.srf에서 OAuth를 통해 WNS로 인증하는 과정이 대부분이므로 코드 전체를 보여 드리지는 않겠습니다. 이 인증의 결과로 액세스 토큰을 얻게 되고 이 액세스 토큰은 채널 URI로 보내는 HTTP POST에 포함됩니다.

C#:

public string PostToWns(string secret, string sid, string uri, string xml, string type = "wns/badge")
{
    try
    {
        // You should cache this access token
        var accessToken = GetAccessToken(secret, sid);

        byte[] contentInBytes = Encoding.UTF8.GetBytes(xml);

        // uri is the channel URI
        HttpWebRequest request = HttpWebRequest.Create(uri) as HttpWebRequest;
        request.Method = "POST";
        request.Headers.Add("X-WNS-Type", type);
        request.Headers.Add("Authorization", String.Format("Bearer {0}", accessToken.AccessToken));

        using (Stream requestStream = request.GetRequestStream())
            requestStream.Write(contentInBytes, 0, contentInBytes.Length);

        using (HttpWebResponse webResponse = (HttpWebResponse)request.GetResponse())
            return webResponse.StatusCode.ToString();
    }
    catch (WebException webException)
    {
        // Implements a maximum retry policy (omitted)
    }
}

이 예에서는 HTTP 요청의 'X-WNS-Type' 헤더가 'wns/badge'로 설정되었고 'Content-Type' 헤더가 기본값인 'text/xml'로 설정된 것을 눈여겨보시기 바랍니다. 타일의 경우 유형은 'wns/tile'이어야 하고 알림은 'wns/toast'를 사용합니다. 원시 알림의 경우 유형은 'wns/raw'를 사용하고 'Content-Type'을 'application/octet-stream'으로 설정합니다. 헤더에 대한 자세한 내용은 설명서의 푸시 알림 서비스 요청 및 응답 헤더를 참조하십시오.

푸시 알림 실패

이와 같은 HTTP 요청 전송이 항상 성공하는 것은 아니며, WNS가 200 코드(성공) 이외의 다른 코드로 응답하는 몇 가지 이유가 있습니다. 자세한 내용은 푸시 알림 서비스 요청 및 응답 헤더의 "응답 코드" 단원을 참조하십시오. 다음은 일반적인 오류와 그 원인입니다.

채널 URI가 올바르지 않거나(404 찾을 수 없음) 만료되었습니다(410 없음). 이 경우 서비스가 데이터베이스에서 채널 URI를 제거하고, 제거된 채널 URI에 대한 요청을 더 이상 만들면 안 됩니다.
클라이언트 암호 및 SID가 올바르지 않거나(401 권한 없음) 앱 매니페스트의 앱 패키지 ID와 Windows 스토어의 패키지 ID가 일치하지 않습니다(403 사용 권한 없음). 이와 같은 불일치 문제를 해결하는 가장 좋은 방법은 Visual Studio의 '스토어 > 스토어에 앱 연결' 메뉴 명령을 사용하는 것입니다. 이 명령은 Visual Studio 2012 Ultimate의 '프로젝트' 메뉴에서 찾을 수 있습니다.
원시 알림 페이로드가 5KB를 초과합니다(413 요청 엔터티가 너무 큼).
클라이언트가 오프라인 상태일 수 있습니다. 이 경우 WNS에서 자동으로 다시 시도하지만 결국에는 실패를 보고합니다. XML 알림의 경우 클라이언트가 다시 온라인에 연결되면 푸시 알림을 캐시하여 전달하는 것이 기본 동작입니다. 원시 알림의 경우 기본적으로 캐시가 비활성화되어 있으므로 채널 URI로 보내는 요청에서 'X-WNS-Cache-Policy' 헤더를 'cache'로 설정하여 이를 변경할 수 있습니다.

기타 이유(400 잘못된 요청)인 경우 XML 페이로드에 UTF-8로 인코딩된 텍스트가 있는지, 원시 알림이 base64로 되어 있고 'Content-Type' 헤더가 'application/octet-stream'으로 설정되어 있는지 확인하십시오. 또한 특정 기간 내에 푸시 알림을 너무 많이 보내려고 하면 WNS가 전송을 제한할 수 있습니다.

앱이 잠금 화면에 없고 장치가 연결된 대기 상태인 경우에도 원시 푸시 알림이 거부될 수 있습니다. Windows는 연결된 대기 상태와 앱이 포그라운드에 있지 않을 때는 비잠금 화면 앱으로 전송되는 원시 알림을 차단하기 때문에 WNS는 전송되지 않을 알림을 삭제하는 기능에 최적화되어 있습니다.

Windows Azure Mobile Services

복잡한 푸시 알림 작업에 대해 알아보았고 저장소 문제는 아예 건너뛰었으니 "이 작업을 좀 더 간편하게 하는 방법은 없나요?"라는 궁금증이 생길 법도 합니다. 여러분이 고객 기반을 차�� 확대하다 보면 채널 URI가 수천에서 수백만 개에 달할 수도 있는데(물론 그렇게 되기를 바라지만!) 그렇게 많은 채널 URI를 관리하려면 어떻게 해야 할까요?

다행히도 여러분 외에도 이런 질문을 한 사람들이 있습니다. Urban Airship에서 제공하는 타사 솔루션 외에도 Windows Azure Mobile Services를 사용하면 채널 URI를 훨씬 간편하게 관리할 수 있습니다.

Windows Azure Mobile Services, 줄여서 AMS는 우리가 살펴본 대부분의 서비스에 사용할 수 있는 이미 제작된 솔루션(기본적으로 수많은 REST 끝점)을 제공합니다. "Mobile Service"는 기본적으로 개발자를 대신하여 데이터베이스를 관리하고 WNS에 페이로드를 간편하게 보낼 수 있는 라이브러리 함수를 제공하는 서비스입니다. AMS에 대한 소개는 Windows Azure Mobile Services로 구현하는 "클라우드 지원 앱"에서 확인할 수 있습니다.

특히 푸시 알림의 경우 우선 Windows Azure Mobile Services SDK for Windows 8에서 클라이언트 쪽 라이브러리를 얻어야 합니다. 그런 다음 Mobile Services에서 푸시 알림 시작(JavaScript 버전도 있음)을 참조하십시오. AMS가 앞에서 살펴본 배선 작업을 어떤 방식으로 지원하는지에 대해 자세하게 설명되어 있습니다.

Windows 스토어에 앱 등록: Windows 스토어에서 앱에 사용할 클라이언트 암호 및 SID를 얻었으면 Mobile Service 구성에 해당 값을 저장합니다. 방금 언급한 시작 항목의 "Windows 스토어에 앱 등록" 단원을 참조하십시오.
채널 URI 획득 및 새로 고침: 앱에서 채널 URI를 요청하고 관리하는 일은 전적으로 클라이언트 쪽 작업이며 절차는 이전과 동일합니다.
서비스로 채널 URI 보내기: AMS를 사용하면 이 단계를 훨씬 간단히 수행할 수 있습니다. 먼저 Windows Azure 포털을 통해 Mobile Service에 데이터베이스 테이블을 만듭니다. 그러면 앱에서는 채널 URI 및 연결할 기타 주요 정보를 통해 해당 테이블에 레코드를 삽입할 수 있습니다. AMS 클라이언트 라이브러리는 백그라운드에서 HTTP 요청을 처리할 뿐 아니라 서버에 변경 사항이 있으면 클라이언트 쪽 레코드를 업데이트하는 작업까지 처리합니다. 뿐만 아니라 AMS는 사용자의 Microsoft 계정을 통해 또는 다른 OAuth 공급자인 Facebook, Twitter, Google 중 하나로 앱을 등록한 경우 이 중 하나를 통해 자동으로 인증을 처리할 수 있습니다. 자세한 내용은 Mobile Services에서 인증 시작을 참조하십시오.
알림 보내기: Mobile Service 내에서는 JavaScript를 변형한 Node.js로 작성된 스크립트와 JavaScript로 작성된 예약된 작업을 데이터베이스 작업에 연결할 수 있습니다. 이러한 스크립트에서는 채널 URI와 페이로드를 사용하여 'push.wns' 개체를 호출하면 채널에 필요한 HTTP 요청이 생성됩니다. 또한 'console.log'를 사용하여 간단하게 푸시 실패를 캡처하고 응답을 기록할 수 있습니다. 이러한 로그는 Windows Azure 포털에서 쉽게 검토할 수 있습니다.

자세한 내용은 다음 두 자습서 Windows Azure Mobile Services를 사용한 타일, 알림 및 배지 푸시 알림 및 Windows Azure Mobile Services를 사용한 원시 알림을 참조하십시오. 이 글에서는 지침을 모두 복습하지는 않고 몇 가지 핵심만 살펴보겠습니다.

Mobile Service를 설정할 때 특정 서비스 URL을 사용하게 됩니다. AMS SDK에서 'MobileServiceClient' 개체의 인스턴스를 만들 때 사용하는 것이 바로 이 URL입니다.

JavaScript:

var mobileService = new Microsoft.WindowsAzure.MobileServices.MobileServiceClient(
    "https://{mobile-service-url}.azure-mobile.net/",
    "{mobile-service-key}");

C#:

using Microsoft.WindowsAzure.MobileServices;

MobileServiceClient MobileService = new MobileServiceClient(
    "https://{mobile-service-url}.azure-mobile.net/",
    "{mobile-service-key}");

C++(추가 샘플에서 발췌):

using namespace Microsoft::WindowsAzure::MobileServices;

auto MobileService = ref new MobileServiceClient(
    ref new Uri(L" https://{mobile-service-url}.azure-mobile.net/"), 
    ref new String(L"{mobile-service-key}"));

이 클래스는 서비스와 이루어지는 모든 HTTP 통신을 캡슐화하므로 개발자가 하위 수준의 배관 작업을 신경 쓸 필요가 없습니다.

특정 OAuth 공급자로 인증하려면 'login' 또는 'LoginAsync' 메서드를 사용합니다. 그 결과로 나오는 것이 해당 정보를 앱에 제공하는 'User' 개체입니다. 인증된 후에는 클라이언트 개체의 'CurrentUser' 속성에도 사용자 ID가 포함됩니다. 이와 같이 Mobile Service를 직접 인증할 경우 서비스가 사용자 ID에 액세스할 수 있으므로 클라이언트가 사용자 ID를 명시적으로 보낼 필요가 없습니다.

JavaScript:

mobileService.login("facebook").done(function (user) { /* ... */ });
mobileService.login("twitter").done(function (user) { /* ... */ });
mobileService.login("google").done(function (user) { /* ... */ });
mobileService.login("microsoftaccount").done(function (user) { /* ... */ });

C#:

MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Twitter);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.Google);
MobileServiceUser user = await MobileService.LoginAsync(MobileServiceAuthenticationProvider.MicrosoftAccount);

C++:

task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Facebook))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Twitter))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::Google))
    .then([this](MobileServiceUser^ user) { /* */ } );
task<MobileServiceUser^> (MobileService->LoginAsync(MobileServiceAuthenticationProvider::MicrosoftAccount))
    .then([this](MobileServiceUser^ user) { /* */ } );

서비스에 채널 URI를 보내는 작업도 간단합니다. 서비스의 데이터베이스에 레코드를 저장하면 클라이언트 개체가 HTTP 요청을 만듭니다. 이렇게 하려면 앞에서 링크를 제공한 푸시 알림 자습서 샘플에 나와 있는 아래의 예처럼 데이터베이스 개체를 요청하고 레코드를 삽입하기만 하면 됩니다. 각 코드 조각에서 'ch'는 WinRT API의 'PushNotificationChannel' 개체를 포함하는 것으로 가정합니다. 작성된 'channel' 개체에 보조 타일 ID 또는 채널의 목적을 식별하는 기타 데이터 같은 다른 속성을 넣을 수도 있습니다.

JavaScript:

var channelTable = MobileServicesSample.mobileService.getTable('Channels');

var channel = {
    uri: ch.uri, 
    expirationTime: ch.expirationTime.
};

channelTable.insert(channel).done(function (item) {

    },
    function () {
        // Error on the insertion.
    });
}

C#:

var channel = new Channel { Uri = ch.Uri, ExpirationTime = ch.ExpirationTime };
var channelTable = privateClient.GetTable<Channel>();

if (ApplicationData.Current.LocalSettings.Values["ChannelId"] == null)
{
    // Use try/catch block here to handle exceptions
    await channelTable.InsertAsync(channel);
}

C++:

auto channel = ref new JsonObject();
channel->Insert(L"Uri", JsonValue::CreateStringValue(ch->Uri));
channel->Insert(L"ExpirationTime", JsonValue::CreateBooleanValue(ch->ExpirationTime));

auto table = MobileService->GetTable("Channel");
task<IJsonValue^> (table->InsertAsync(channel))
    .then([this, item](IJsonValue^ V) { /* ... */ });

일단 채널 레코드가 삽입되면 서버가 해당 레코드에 수행한 변경 또는 추가 작업이 클라이언트에 반영된다는 점에 주의해야 합니다.

뿐만 아니라 'GetTable/getTable' 호출에서 데이터베이스 이름의 철자를 잘못 입력할 경우 레코드를 삽입하려고 시도하기 전에는 어떤 예외도 발견할 수 없습니다. 이러한 버그는 추적하기가 매우 어렵습니다. 모든 것이 제대로 작동한다고 확신했는데 실제로는 그렇지 않은 경우가 발생할 수 있으므로 반드시 데이터베이스 이름을 확인해야 합니다.

다시 한 번 강조하지만 클라이언트 쪽에서 삽입한 항목은 HTTP 요청으로 전환되어 서비스에 전달됩니다. 하지만 서비스 쪽에서도 이러한 요청은 숨김 처리됩니다. 따라서 요청을 받아서 처리하는 대신 각 데이터베이스 작업(삽입, 읽기, 업데이트 및 삭제)에 사용자 지정 스크립트를 연결합니다.

이러한 스크립트는 Node.js에서 사용 가능한 고유의 개체 및 메서드를 사용하여 JavaScript 함수로 작성되며 앱의 클라이언트 쪽 JavaScript에서 해야 할 일은 없습니다. 각 함수에는 적절한 매개 변수가 제공됩니다. 'insert' 및 'update'는 새로운 레코드를 수신하고, 'delete'는 항목의 ID를 수신하고, 'read'는 쿼리를 수신합니다. 또한 모든 함수는 'user' 개체를 수신하며 앱에서 Mobile Service를 사용하여 사용자를 인증할 경우에는 작업을 실행하여 HTTP 응답이 될 항목을 생성할 수 있는 'request' 개체도 수신합니다.

요청을 실행하고 레코드, 즉 'item'을 삽입하는 가장 간단한(기본값) 'insert' 스크립트는 다음과 같습니다.

function insert(item, user, request) {
    request.execute();
}

레코드에 타임스탬프와 사용자 ID를 연결하는 방법도 매우 간단합니다. 아래와 같이 요청을 실행하기 전에 'item' 매개 변수에 해당 속성을 추가하기만 하면 됩니다.

function insert(item, user, request) {
    item.user = user.userId;
    item.createdAt = new Date();
    request.execute();
}

이 스크립트에서 데이터베이스에 레코드를 삽입하기 전에 'item'의 내용을 변경하면 변경된 항목이 자동으로 클라이언트에 전달됩니다. 위의 코드에서 삽입이 성공하면 클라이언트의 'channel' 개체에 'user' 및 'createdAt' 속성이 포함됩니다. 정말 편리합니다.

또한 서비스 스크립트에서 'request.execute' 이후, 특히 성공 또는 실패에 응답하여 추가 작업을 수행할 수도 있습니다. 자세한 내용은 서버 스크립트 예제 사용 방법 설명서를 참조하십시오.

다시 푸시 알림으로 돌아가서, 테이블에 채널 URI를 저장하는 작업은 한 쪽에서만 발생하며 서비스가 이 특별한 이벤트에 응답하여 알림을 보낼 수도 있고 보내지 않을 수도 있습니다. 오히려 그보다는 서비스에서 추가 정보를 사용하여 다른 테이블을 만들고, 이 테이블에서 수행되는 작업이 채널 URI의 일부 하위 집합에 알림을 트리거할 확률이 더 높습니다. 다음 단원에서 몇 가지 예를 살펴보겠습니다. 하지만 어떤 경우에도 'push.wns' 개체를 사용하여 스크립트에서 푸시 알림을 보낸다는 사실은 변하지 않습니다. 원시를 포함하여 특정 유형의 업데이트를 보낼 수 있는 다양한 메서드가 있으며 사용 가능한 템플릿과 일치하는 이름 메서드를 통해 타일, 알림 및 배지가 직접 작동합니다. 예를 들면 아래와 같습니다.

push.wns.sendTileSquarePeekImageAndText02(channel.uri, {
    image1src: baseImageUrl + "image1.png",
    text1: "Notification Received",
    text2: item.text
}, {
    success: function (pushResponse) {
        console.log("Sent Tile Square:", pushResponse);
    },
    error: function (err) {
        console.log("Error sending tile:", err);
    }

});

push.wns.sendToastImageAndText02(channel.uri, {
    image1src: baseImageUrl + "image2.png",
    text1: "Notification Received",
    text2: item.text
}, {
    success: function (pushResponse) {
        console.log("Sent Toast:", pushResponse);
    }
});

push.wns.sendBadge(channel.uri, {
    value: value,
    text1: "Notification Received"
}, {
    success: function (pushResponse) {
        console.log("Sent Badge:", pushResponse);
    }
});

이번에도 'console.log' 함수가 로그에 항목을 만듭니다. 이 로그는 Azure Mobile Services에서 확인할 수 있습니다. 그리고 위에서 타일 알림을 통해 표시된 로그 호출을 오류 처리기에 넣는 개발자들이 많습니다.

'send*' 메서드를 보면 각각 특정 템플릿에 연결되어 있는 것을 알 수 있습니다. 즉, 타일의 경우 와이드 및 정사각형 페이로드를 두 개의 알림으로 나누어 따로 보내야 한다는 의미입니다. 사용자가 시작 화면에서 어떤 타일 모양을 선택할지 알 수 없기 때문에 대부분의 경우 두 가지 크기로 다 보내야 한다는 점을 기억하십시오. 템플릿별 'push.wns'의 'send' 함수를 사용한다는 것은 호출 두 개를 순차적으로 만들어서 각 호출이 별도의 푸시 알림을 생성한다는 의미입니다.

다양한 태그를 이용하여 한 번에 여러 타일 업데이트를 보내거나 여러 알림을 보내는 다중 업데이트를 결합하려면 'push.wns.sendTile' 및 'push.wns.sendToast' 메서드를 사용합니다. 예를 들면 아래와 같습니다.

var channel = '{channel_url}';

push.wns.sendTile(channel,
    { type: 'TileSquareText04', text1: 'Hello' },
    { type: 'TileWideText09', text1: 'Hello', text2: 'How are you?' },
    { client_id: '{your Package Security Identifier}', client_secret: '{your Client Secret}' },

    function (error, result) {
        // ...
    });

이보다 훨씬 하위 수준에서도 'push.wns.send'를 사용하여 알림 콘텐츠를 매우 정확하게 관리할 수 있으며 원시 알림에 사용할 수 있는 'push.wns.sendRaw'도 있습니다. 자세한 내용은 push.wns 개체 설명서를 참조하십시오.

Windows Azure Mobile Services를 사용한 실제 시나리오

Windows Azure Mobile Services를 사용한 타일, 알림 및 배지 푸시 알림의 샘플 앱은 데이터베이스 테이블에 삽입되는 새 메시지에 응답하여 푸시 알림을 보내는 방법을 잘 보여 줍니다. 하지만 이는 결국 앱이 자기 자신에게 푸시 알림을 보낸다는 의미가 되기 때문에 사용자의 다른 장치에 설치된 같은 앱에 알림을 보내는 경우 외에는 일반적으로 이렇게 할 필요가 없습니다.

그보다는 알림을 최종적으로 수신하는 앱/타일 외부에서 발생하는 이벤트에 응답하여 서비스가 푸시 알림을 보낼 확률이 훨씬 높습니다. 다음과 같은 몇 가지 시나리오를 고려해 볼 수 있습니다.

소셜 네트워크 사용:

앱에서 사용자의 소셜 네트워크를 사용하여 친구에게 도전장을 보내는 등의 기능을 구현할 수 있습니다. 예를 들어 한 사용자가 게임에서 신기록을 세우면 타일 업데이트 또는 알림을 통해 같은 게임을 설치한 친구들에게 도전장을 보낼 수 있습니다. 피트니스 앱에서도 같은 방법을 사용할 수 있습니다. 특정 종목에서 신기록이 나오면 기록을 게시하는 것입니다.

이렇게 하려면 앱에서 적절한 Mobile Service 테이블(Scores, BestTimes 등)에 새 레코드를 삽입할 수 있어야 합니다. 삽입 스크립트 내에서 서비스가 데이터베이스에 현재 사용자의 친구 중 조건에 맞는 친구를 쿼리하여 해당 채널 URI에 알림을 보냅니다. 추가 쿼리 조건은 보조 타일에 사용할 게임의 정확한 특징, 특별한 운동 종류 등을 설명합니다.

날씨 업데이트 및 알림:

날씨 앱은 일반적으로 앱의 기본 타일에 위치를 할당하고 보조 타일을 만들어서 위치를 추가로 할당할 수 있습니다. 각 타일에서 중요한 정보는 앱이 각 채널 URI와 함께 테이블에 삽입하여 서비스로 보내는 위도 및 경도입니다. 해당 채널로 업데이트를 트리거하려면 중앙의 날씨 서비스에 업데이트 및 알림을 주기적으로 쿼리한 후 응답을 처리하고 Mobile Service의 알림 테이블에 적절한 메시지를 삽입하는 또 다른 프로세스(아래에 설명된 예약된 작업 같은)가 서비스에 필요합니다. 그러면 삽입 스크립트가 적절한 채널 URI를 검색하여 업데이트를 보냅니다. 또는 날씨 서비스 자체에 알림이나 주기적 업데이트를 등록할 수 있다면 서비스의 또 다른 페이지에서 요청(HTTP PUT일 가능성이 가장 높음)을 받아서 처리하고 Mobile Service를 호출하여 레코드를 삽입할 수 있으며 그 결과로 업데이트가 트리거됩니다.

메시지:

인스턴트 메시지를 처리하는 방식은 날씨 업데이트를 받는 방식과 매우 흡사합니다. 위에서 설명한 대로, 다른 프로세스에서 새 메시지 수신을 모니터링하거나(들어오는 메시지를 주기적으로 검사하는 프로세스인 경우) 새 메시지가 도착하면 메시지 원본으로 알림을 등록합니다. 두 경우 모두 새 메시지가 도착하면 해당 채널에 푸시 알림이 트리거됩니다. 이 경우에 채널 URI는 특정 종류의 메시지에 사용되는 사용자 타일에 연결됩니다. 이 글의 앞부분에서 설명한 이메일 시나리오와 비슷한 상황이기 때문에 원시 알림을 사용하는 분들이 많을 것으로 생각됩니다.

어떤 시나리오에 해당하든 데이터베이스 테이블에 실제로 어떤 것도 삽입할 필요가 없습니다. 삽입 스크립트에서 'request.execute'를 호출하지 않으면 데이터베이스에는 아무런 변화도 없지만 스크립트 내에서 알림을 보내는 등의 기타 작업을 여전히 수행할 수 있습니다. 다시 말해서 나중에 사용할 일이 없는 레코드로 데이터베이스를 채울 필요가 없습니다. 괜히 데이터 저장 비용만 늘어날 뿐입니다.

Azure Mobile Services에는 작업을 예약하는 기능도 있습니다. 자세한 내용은 Mobile Services에서 반복 작업 예약하기를 참조하십시오. 이러한 작업은 다른 서비스의 데이터를 일상적으로 검색하여 처리하고 서비스의 데이터베이스에 레코드를 삽입하여 다시 푸시 알림을 트리거할 수 있습니다. 이 시리즈의 2부에서 살펴본 것처럼 다른 웹 페이지와 모바일 앱 역시 해당 데이터베이스를 변경하여 푸시 알림을 트리거할 수 있습니다. Mobile Service의 데이터베이스 스크립트는 이 모든 상황에서 실행됩니다.

결론

이제 정리해 보겠습니다. 지금까지 우리는 "생생한 활동 업데이트"가 사용자, 개발자, 앱 및 서비스에 어떤 의미를 주는지에 대해 처음부터 끝까지 살펴보았습니다. 타일, 배지 및 알림 업데이트의 기능, 주기적 알림을 설정하는 방법, 이 프로세스의 일환으로 백그라운드 작업을 사용하는 방법, 주기적 알림과 푸시 알림을 처리하는 서비스 구조에 대해 알아보았습니다. Windows Azure Mobile Services를 사용하면 푸시 알림 작업의 전체 프로세스를 완벽하게 파악할 수 있습니다. 서비스를 처음부터 작성할 필요가 없기 때문에 개발자의 생산성이 향상되는 것은 물론이고 여러 골치 아픈 상황에서 벗어날 수 있습니다.

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

생생한 활동 업데이트 2부: 라이브 타일에 사용할 서비스 작성 및 디버깅

Windows 8 Team — Mon, 11 Mar 2013 19:07:21 GMT

이 시리즈의 1부에서는 "생생한" Windows 8 사용자 경험을 가능하게 하는 타일 업데이트, 배지 업데이트 및 알림 메시지의 본질에 대해 알아보았습니다. 특히 알림이 XML 페이로드로 구성된 후 실행 중인 앱 또는 백그라운드 작업에서 로컬로 실행되거나 온라인 서비스로 요청할 때 제공되는 방법을 살펴보았습니다.

Visual Studio Ultimate 2012 또는 Visual Studio Express 2012 for Windows 8을 사용하는 앱을 이용하면 간단하게 XML 페이로드를 생성한 후 현재 실행 중인 앱에서 XML 페이로드를 실행해 보고 디버깅할 수 있습니다. 앱 타일 및 배지 샘플, 보조 타일 샘플 및 예약된 알림 샘플만 있으면 됩니다.

그 외에는 웹 서비스를 개발하고 디버깅하여 주기적으로 업데이트 및 푸시 알림을 지원하는 약간의 수고만 하면 됩니다. 이 시리즈의 클라이언트 측에 대한 설명은 푸시 및 주기적 알림 클라이언트 쪽 샘플에 잘 나와 있습니다. 하지만 이 샘플을 최대한 활용하려면 약간의 노력이 필요합니다. 이 글에서는 타일 및 배지 업데이트에 대한 주기적 알림을 지원하는 서비스를 개발하는 방법을 구체적으로 살펴볼 것입니다. 그 중에서도 특히, 생산 환경에 서비스를 배포하기 전에 Visual Studio 도구와 로컬 호스트를 사용하여 서비스를 디버깅하는 방법을 집중적으로 알아보겠습니다. 또한 Windows Azure Mobile Services를 같은 용도로 사용하는 방법도 살펴볼 것입니다. 이 방법은 3부에서 살펴볼 것인데 푸시 알림을 지원할 때 매우 유용합니다.

서비스의 기본 특징

타일 및 배지 정기 업데이트를 지원하는 서비스가 실질적으로 하는 일은 무엇일까요? 먼저 “서비스”의 정확한 의미부터 살펴보겠습니다. 클라이언트 앱에 주력한 개발자는 서비스라는 단어를 보면 겁부터 내는 경우가 많기 때문입니다.

아주 간단히 설명하자면, 서비스란 웹 서버에 있는 코드 조각으로, 서버에 HTTP 요청이 전송되면 '해당 서버'에서 실행됩니다. HTML 페이지(.htm 또는 .html)는 이와 달리, 서버 쪽 코드가 없고 서버가 해당 페이지의 텍스트를 단순히 반환하기만 하며, 모든 처리 작업이 클라이언트(해당 페이지에 들어 있는 실행 중인 모든 클라이언트 측 스크립트 포함)에서 처리됩니다. 하지만 php, asp, aspx, cgi, cshtml 또는 기타 서버 쪽 확장자로 끝나는 페이지 URI를 갖고 있다면 다음과 같은 일반적인 방법에 따라 효과적으로 "서버"에 이야기를 전달할 수 있습니다.

서비스는 클라이언트 HTTP 요청을 받아서 URI에 들어 있는 모든 인수를 처리한 후 적절한 텍스트 응답을 반환합니다. PHP나 ASP.NET 같은 기술로 작성된 '웹 페이지'의 경우 응답이 HTML 형식이어야 합니다. Facebook, Twitter 및 그 외의 수많은 서비스처럼 웹 API를 구축하는 서비스는 일반적으로 URI 쿼리 문자열(또는 요청 헤더)에 허용되는 매개 변수 개수에 제한이 없으며 요청에 대한 응답으로 XML 또는 JSON 데이터를 반환합니다. 그리고 참고로 알려 드리자면, 이 글에서 우리가 논의할 서비스는 SOAP 같은 다른 프로토콜 기반의 서비스가 아니라 REST(representational state transfer) 기반의 서비스입니다. 왜냐하면 현재 서비스에 가장 많이 사용되는 것이 REST이기 때문입니다.

따라서 주기적으로 타일 및 배지 업데이트를 제공하는 서비스는 앱에서 이러한 목적으로 Windows에 제공하는 모든 URI에 존재하는 서비스일 뿐이며, 적절한 XML 페이로드를 통해 HTTP 요청에 응답합니다. 페이로드에는 지원되는 모든 템플릿에 상응하는 요소가 들어 있습니다. 이미지는 다른 URI로 참조되며 인라인 인코딩은 지원되지 않습니다. 또한 모든 소스의 정보가 페이로드에 포함될 수 있으며, 이에 대해서도 간단하게 살펴볼 것입니다.

하지만 세부적인 내용이 어떻든 간에 모든 서비스는 요청을 받아서 처리하고 XML 응답을 작성하는 비슷한 구조를 갖고 있습니다. 지금부터 기본 구조를 만드는 방법을 살펴보겠습니다.

서비스 작성

개발자가 선택한 서버 쪽 언어를 지원하는 도구를 사용하여 서비스를 작성하고 디버깅할 수 있습니다. 우리는 Visual Studio, 특히 Visual Studio Ultimate 2012 및 Visual Studio Express 2012 for Web을 집중적으로 살펴볼 것이며, 이 Visual Studio Express 2012 for Web은 여러분이 이미 알고 계신 Windows 파트너와 함께 무료로 이용하실 수 있습니다. 웹 플랫폼 설치 관리자를 실행하여 설치할 수 있으며, 웹 플랫폼 설치 관리자를 통해 PHP, WebMatrix 등 다양한 관련 기술을 설치할 수 있습니다. 이렇게 하면 다양한 언어로 서비스를 만들 수 있습니다.

아주 간단한 예를 하나 들자면, 다음은 배지 값이 서버를 따라 현재 날짜로 설정된(중요!) 배지 업데이트 XML 페이로드를 통해 응답하는 완전한 PHP 서비스를 구성하는 코드입니다. 이 코드는 제 무료 전자책 13장 HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍:에 수록된 HelloTiles 샘플에서 가져온 것입니다.

<?php
    echo '<?xml version="1.0" encoding="utf-8" ?>';
    echo "<badge value='".date("j")."'/>";
?>

이 서비스는 직접 해볼 수 있습니다. 제가 시험용으로 설정해 놓은 Windows Azure 사이트 링크 http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/dayofmonthservice.php를 클릭하면 다음과 같은 XML이 표시될 것입니다.

<?xml version="1.0" encoding="UTF-8"?>
<badge value="24"/>

푸시 및 주기적 알림 클라이언트 쪽 샘플 시나리오 5 “배지 업데이트에 대한 폴링”에서 이 URI를 그대로 시험해 보십시오. Visual Studio Express for Windows 내에서 앱을 처음으로 실행하면 다음과 같이 시작 화면에 타일이 나타납니다.

이제 위의 URI를 시나리오 5의 텍스트 상자에 입력하고 주기적 업데이트 시작 단추를 누릅니다. 네트워크에 연결되어 있다면 샘플의 타일에 숫자 배지가 나타날 것입니다.

앱이 주기적 업데이트를 시작하는 즉시 Windows는 업데이트에 대한 폴링을 시도한 후 지정된 간격마다 계속해서 폴링을 반복합니다.

보다 구체적인 PHP 예는 뛰어난 라이브 타일 환경 만들기(2부)를 참조하십시오. 다양한 방법으로 사용자 지정된 타일 업데이트를 확인할 수 있습니다. 해당 예의 가상 함수 'get_trucks_from_database'는 URI의 쿼리 문자열 매개 변수에 들어 있는 우편 번호를 사용하여 데이터베이스에 쿼리한 다음, 쿼리 결과로 XML 응답을 작성합니다.

그 외에도 이 서비스로 다양한 일을 할 수 있는데, 예를 들면 아래와 같습니다.

위에서 본 day-of-month PHP 서비스의 경우 서버가 다른 시간대에 있는 경우가 자주 있기 때문에 앱에서 쿼리 문자열에 현지 시간대를 지정하여 보다 정확한 날짜를 가져올 수 있습니다.
날씨 서비스에서 URI에 위도와 경도 값을 사용하여 해당 위치의 현재 날씨를 검색할 수 있습니다.
서비스에서 즉각적으로 이미지를 생성하여 웹 서버에 저장한 다음 XML 페이로드에 적절한 URI를 삽입할 수 있습니다.
서비스에서 다른 서비스에 고유한 요청을 보내 쿼리 문자열 매개 변수로 사용자 지정된 추가 데이터를 얻을 수 있습니다. 이에 대해서는 나중에 자세히 설명하겠습니다.
앱에서 타일 업데이트에 대한 대기열을 설정할 경우(EnableNotificationQueue 메서드 참조) 시나리오 4 푸시 및 주기적 알림 클라이언트 쪽 샘플에서 보여 드린 것처럼 별도의 URI를 최대 5개까지 지정하여 주기적 업데이트를 폴링할 수 있습니다. 타일 업데이트 대기열은 각 URI의 업데이트로 채워집니다. 물론 각 URI에 나중에 사용자 지정에 사용할 고유의 쿼리 문자열을 넣어서 같은 서비스에서 모든 요청을 자체적으로 수용할 수 있습니다.
앱의 쿼리 문자열에 사용자 ID를 넣으면 서비스가 데이터 저장소에 쿼리하여 사용자의 운동 기록, 게임 최고 점수, 등록된 피드의 최신 뉴스 등을 검색할 수 있습니다. 이 경우 사용자 ID가 PII(개인 식별이 가능한 정보)로 사용될 수 있기 때문에 앱이 개인 정보 보호 정책을 준수해야 합니다. 즉, 쿼리 문자열에서 사용자 이름을 암호화하거나 https:// URI를 사용해야 합니다.

참고: Windows는 주기적 업데이트 메커니즘 내에 서비스로 사용자를 인증할 수 있는 수단을 제공하지 않습니다. 이러한 수준의 지원은 푸시 알림을 통해서만 또는 기업 시나리오의 경우 매니페스트에 엔터프라이즈 인증 기능을 선언해야만 가능합니다.

물론 다른 기술을 사용하여 서비스를 작성할 수도 있습니다. ASP.NET은 동일한 Notifications Extensions 라이브러리(C#로 작성된)를 앱에 사용하여 간단하게 체계적인 XML 페이로드를 생성할 수 있는 좋은 기술입니다.

HelloTiles 샘플 서비스를 설명하기 위해 제 전자책 13장(도우미 콘텐츠 보기)에 만들어 놓은 매우 기본적인 WebMatrix 서비스를 통해 간단한 예를 살펴보겠습니다. 이 서비스는 고정된 XML 페이로드(정사각형 타일과 와이드 타일 모두에 바인딩된)를 반환하며 뛰어난 라이브 타일 환경 만들기(2부)의 첫 번째 ASP.NET 예와 비슷한 구조를 갖고 있습니다.

@{
  //
  // This is where any other code would be placed to acquire the dynamic content
  // needed for the tile update. In this case we'll just return static XML to show
  // the structure of the service itself.
  // 
  var weekDay = DateTime.Now.DayOfWeek;
}
<?xml version="1.0" encoding="utf-8" ?>
<tile>
    <visual lang="en-US">
        <binding template="TileSquarePeekImageAndText02" branding="none">
            <image id="1" src="http://www.kraigbrockschmidt.com/images/Liam07.png"/>
            <text id="1">Liam--</text>
            <text id="2">Giddy on the day he learned to sit up!</text>
        </binding>
        <binding template="TileWideSmallImageAndText04" branding="none">
            <image id="1" src="http://www.kraigbrockschmidt.com/images/Liam08.png"/>
            <text id="1">This is Liam</text>
            <text id="2">Exploring the great outdoors!</text>
        </binding>
    </visual>
</tile>

이 서비스는 http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/Default.cshtml에 배포됩니다. 푸시 및 주기적 알림 클라이언트 쪽 샘플의 시나리오 4를 시험해 보십시오. 몇 초 후 다음과 같은 타일 업데이트가 나타날 것입니다. 왼쪽은 와이드 타일이고, 오른쪽은 정사각형 2개로 된 미리 보기 타일입니다.

지금부터 Notification Extensions 라이브러리를 사용하여 같은 코드를 작성해 보겠습니다. 가장 먼저 할 일은 다음 순서에 따라 웹 사이트에 사용할 라이브러리 버전을 구축하는 것입니다.

앱 타일 및 배지 샘플로 이동하여 해당 프로젝트의 Notifications Extensions 폴더를 내 프로젝트의 폴더에 복사합니다. 프로젝트를 마우스 오른쪽 단추로 클릭하고 NuGet 패키지 관리…를 선택한 다음 'NotificationsExtensions.WinRT'를 검색하여 Visual Studio에서 바로 라이브러리를 설치할 수도 있습니다. 하지만 이것은 라이브러리를 기존 앱 프로젝트로 가져오는 방법이고, 우리는 독립 실행형 DLL을 구축해야 합니다.
Visual Studio Express for Windows에서 NotificationsExtensions.csproj 파일을 엽니다.
솔루션 탐색기에서 NotificationExtensions 프로젝트를 마우스 오른쪽 단추로 클릭하고 속성을 선택하여 아래와 같이 변경합니다.

응용 프로그램 설정에서 출력 유형을 '클래스 라이브러리(.dll)'로 변경합니다. ASP.NET 사이트에 라이브러리를 사용하기 위한 조치입니다.
빌드 설정에서 구성을 '모든 구성'으로 변경하고 조건부 컴파일 기호를 'NETFX_CORE; WINRT_NOT_PRESENT'로 변경한 다음 페이지 하단의 XML 문서 파일을 선택합니다. 'WINRT_NOT_PRESENT' 플래그는 WinRT 없이 라이브러리를 컴파일할 수 있다는 의미입니다.

디버그 또는 릴리스 대상을 선택한 다음 Notifications Extensions 프로젝트를 마우스 오른쪽 단추로 클릭하고 빌드를 선택합니다.

그러면 해당 프로젝트 폴더에 DLL 및 관련 파일이 생성됩니다. 이제 DLL을 웹 사이트 프로젝트에 넣어야 합니다.

사이트에 아직 Bin 폴더가 없을 경우 Visual Studio Express for Web에서 웹 사이트 프로젝트를 마우스 오른쪽 단추로 클릭하고 추가 > ASP.NET 폴더 추가 > Bin을 선택합니다.
Bin 폴더를 마우스 오른쪽 단추로 클릭하고 참조 추가…를 선택합니다. 참조 추가에서 Notifications Extensions 프로젝트의 bin\Debug 또는 bin\Release 폴더로 이동하여 DLL을 선택합니다.

Visual Studio Ultimate을 사용 중인 경우 필요하다면 웹 사이트 솔루션에 Notification Extensions 프로젝트를 추가해도 됩니다. 이 도구로 두 프로젝트 유형을 모두 처리할 수 있습니다. 단, 해당 프로젝트의 소스 코드를 웹 서버에 배포하면 안 됩니다!

브라우저에서 로컬로 실행되는 사이트를 구축하는 경우 'System.Runtime'에 참조를 추가할 때 오류가 발생할 수 있습니다. 이 오류를 수정하려면 web.config 파일을 열고 'compilation' 요소를 다음과 같이 변경하십시오.

<compilation debug="true" targetFramework="4.0">
  <assemblies>
    <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 
  </assemblies>
</compilation>

이 모든 작업을 완료하면 앞에서 본 하드 코딩된 예와 똑같은 결과를 출력하는 페이지(DefaultNE.aspx)가 완성됩니다.

<?xml version="1.0" encoding="utf-8" ?>
<%@ Page Language="C#" %>
<script runat="server">   1:  
   2:     public string GenerateTileXML()
   3:     {
   4:         // Construct the square template
   5:         NotificationsExtensions.TileContent.ITileSquarePeekImageAndText02 squareTile = 
   6:             NotificationsExtensions.TileContent.TileContentFactory.CreateTileSquarePeekImageAndText02();
   7:         squareTile.Branding = NotificationsExtensions.TileContent.TileBranding.None;        
   8:         squareTile.Image.Src = "http://www.kraigbrockschmidt.com/images/Liam07.png";
   9:         squareTile.TextHeading.Text = "Liam--";
  10:         squareTile.TextBodyWrap.Text = "Giddy on the day he learned to sit up!";
  11:         
  12:         // Construct the wide template
  13:         NotificationsExtensions.TileContent.ITileWideSmallImageAndText04 wideTile =
  14:             NotificationsExtensions.TileContent.TileContentFactory.CreateTileWideSmallImageAndText04();
  15:         wideTile.Branding = NotificationsExtensions.TileContent.TileBranding.None;
  16:         wideTile.Image.Src = "http://www.kraigbrockschmidt.com/images/Liam08.png";
  17:         wideTile.TextHeading.Text = "This is Liam";
  18:         wideTile.TextBodyWrap.Text = "Exploring the great outdoors!";
  19:                 
  20:         // Attach the square template to the notification
  21:         wideTile.SquareContent = squareTile;
  22:         wideTile.Lang = "en-US";
  23:         
  24:         // The wideTile object is an XMLDOM object, suitable for issuing tile updates
  25:         // directly. In this case we just want the XML text.
  26:         return wideTile.ToString();        
  27:     }
</script>
<%   1:  = GenerateTileXML() 
%>

http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/DefaultNE.aspx에서 이 서비스를 방문할 수 있으며, 아주 사소한 차이점을 제외하고 근본적으로 이전과 동일한 XML이 생성됩니다. 시나리오 4 푸시 및 주기적 알림 클라이언트 쪽 샘플에 이 URI을 붙여 넣어도 이전과 같은 타일 업데이트가 생성됩니다.

서비스 디버깅

올바른 타일 또는 배지 업데이트를 생성하려면 서비스 응답의 XML을 적절하게 구성해야 합니다. Windows는 적절하게 구성되지 않은 XML을 거부합니다. Notifications Extensions 라이브러리는 개발자들이 프로세스에서 자주 범하는 오류를 상당히 줄여 주기 때문에 사용하는 것이 좋습니다.

그런데 만약 서비스가 전혀 작동하지 않는다면 어떻게 해야 할까요? 서비스가 요청을 처리하고 응답을 생성하는 방식을 진단하여 디버깅하려면 어떻게 해야 할까요?

사실, 제가 위의 ASP.NET 서비스 코드를 처음 테스트할 때 XML 응답 맨 위에 선행 줄 바꿈 문자가 있어서 업데이트가 나타나지 않았습니다. '<?xml ?>' 헤더가 '<%@ Page %>' 지시문 뒤가 아닌 파일의 첫 번째 줄에 나타나고 추가적인 LF(Line Feed)가 전혀 없는 것은 바로 이 때문입니다.

여러 가지 이유로 서비스 코드를 자세히 검사하여 한 줄씩 디버깅해야 하며, 특히 데이터베이스에 쿼리하여 쿼리 결과를 처리하려면 더욱 철저한 검사가 필요합니다.

한 가지 팁을 알려 드리자면, 개발용 컴퓨터에서 로컬 호스트를 사용하면 SDK 샘플 같은 클라이언트 테스트 코드를 실행하는 동시에 로컬에서 서비스를 실행하여 디버깅할 수 있습니다.

로컬 호스트가 있다는 것은 인터넷 정보 서비스나 Apache 같은 로컬 웹 서버를 실행하고 있다는 뜻입니다. Windows에서 IIS를 켜려면(기본 기능) 제어판 > Windows 기능 켜기/끄기로 이동합니다. 아래 그림처럼 상단에서 인터넷 정보 서비스를 선택하여 핵심 기능을 설치합니다.

IIS가 설치되면 'c:\inetpub\wwwroot'에서 'http://localhost/'로 시작하는 로컬 사이트를 찾을 수 있습니다. 앞 단원에서 설명한 PHP 페이지 같은 것들을 바로 이 위치에 가져다 놓으면 클라이언트 샘플의 'http://localhost/dayofmonthservice.php'와 비슷한 URI을 사용할 수 있습니다.

IIS와 함께 PHP를 사용하려면 Microsoft의 웹 플랫폼 설치 관리자를 통해 PHP를 설치해야 합니다. 그렇지 않으면 서버 쪽 코드가 정상적으로 실행되지 않습니다. PHP를 설치했으면 로컬 PHP 페이지의 URI를 브라우저에 입력합니다. “처리기 PHP53_via_FastCGI에 잘못된 모듈이 있습니다."라는 오류 메시지(매우 유용한 메시지죠!)가 표시되면 앞에서 본 Windows 기능 켜기/끄기 대화 상자로 돌아가서 인터넷 정보 서비스 > World Wide Web 서비스 > 응용 프로그램 개발 기능으로 이동한 후 CGI 확인란을 선택하고 확인을 누릅니다. CGI 엔진이 설치되면 PHP 페이지가 제대로 작동할 것입니다.

로컬 호스트가 정상적으로 작동하면 개발용 컴퓨터에서 Visual Studio Express for Web 또는 Visual Studio Ultimate을 사용하여 서비스를 디버깅할 수 있습니다. Visual Studio Express for Web과 Visual Studio Express for Windows를 동시에 사용하여 클라이언트 및 서버 코드를 함께 디버깅할 수도 있습니다.

웹용 Visual Studio 디버거에서 서비스 또는 웹 사이트를 실행하면 브라우저를 통해 'http://localhost:<포트>/' 형식의 URL에서 실행됩니다. 여기서 <포트>는 해당 프로젝트에 임의로 할당됩니다. 예를 들어 Visual Studio Express for Web에서 이전 단원의 DefaultNE.aspx 페이지를 실행하면 Internet Explorer를 통해 http://localhost:52568/HelloTiles/DefaultNE.aspx에서 해당 페이지가 열립니다. 페이지 코드에 중단점을 설정할 경우 디버거가 중단점에서 즉시 중지합니다.

같은 로컬 호스트 URI를 클라이언트 코드에 사용하여 요청을 시작할 경우에도 중단점에서 중지합니다. 예를 들어 제가 Visual Studio Express for Windows에서 푸시 및 주기적 알림 클라이언트 쪽 샘플을 실행하여 해당 URI을 시나리오 4에 붙여 넣으면 Windows가 요청을 만드는 즉시 Visual Studio Express for Web이 디버거에서 제 서비스를 중지합니다. 그러면 저는 해당 코드를 철저히 검사하여(다행히도 Windows가 충분한 시간을 제공하기 때문에) 올바른 응답이 생성되는지 확인할 수 있습니다. 올바른 응답이 생성되지 않을 경우 코드를 수정하고 로컬 호스트에서 서비스를 다시 시작하면 됩니다.

서비스가 의도대로 작동한다는 확신이 들면 라이브 웹 호스트(또는 스테이징 환경)에 서비스를 업로드하고 최종 생산 테스트를 수행합니다.

반드시 클라이언트 코드를 디버거에서 실행하여 로컬 호스트를 이 방법으로 사용해야 하는 것은 아닙니다. 하지만 이 방법을 사용하려는 경우에는 로컬 호스트가 제대로 작동하도록 Visual Studio에서 옵션 하나를 켜야 합니다. 이 옵션은 기본적으로 선택되어 있지만 변경이 필요한 경우 디버깅 > 로컬 네트워크 루프백 허용 아래에서 프로젝트 속성을 보면 이 옵션을 찾을 수 있습니다.

외부 소스의 데이터

주기적 알림 서비스는 자체 데이터베이스에 쿼리하는 것은 물론이고 다른 서비스에 요청을 보내 응답에 사용할 데이터를 얻을 수 있습니다. 하지만 이러한 요청은 근본적으로 비동기적이고 다양한 실패 조건이 존재한다는 한계가 있습니다. 따라서 이러한 요청을 사용하면 서비스 구현 방법이 매우 복잡해질 수 있습니다.

Windows는 클라이언트 API에 따라 30분 또는 그 이상에 한 번씩만 서비스에 요청을 보낸다는 사실을 이용하면 간단하게 문제를 해결할 수 있습니다. 다시 말해서, 다른 서버 쪽 프로세스가 날씨 알림, 순위표, RSS 피드, 그리고 그 밖에 웹 API가 있는 모든 것을 모니터링하는 외부 요청을 만들 때까지 상당히 긴 시간이 있습니다. 이러한 프로세스의 결과는 데이터베이스에 저장되고, 주기적 알림 서비스는 다음 요청을 받을 때 이러한 결과를 동기식으로 쿼리할 수 있습니다.

사실, 무수히 많은 에이전트가 같은 데이터베이스를 업데이트할 수 있습니다. 사용자가 개발자의 웹 사이트를 통해 데이터를 입력하는 경우를 예로 들 수 있습니다. 사용자는 휴대전화 앱을 사용하여 활동을 추적할 수 있으며, 결과는 자동으로 데이터베이스에 업로드됩니다. 사용자의 친구들도 개인용 장치에서 같은 앱을 사용하여 데이터베이스를 업데이트할 수 있습니다.

아래는 이러한 처리 방식을 그림으로 나타낸 것으로, 데이터베이스가 백 엔드 상태의 중앙 저장소 역할을 하고 주기적 알림 서비스는 해당 상태를 사용하기만 합니다.

주기적 업데이트 서비스와 함께 Windows Azure Mobile Services 사용하기

백엔드 서비스를 구축하여 라이브 타일 및 기타 알림을 지원하는 방법을 배웠으니 Windows Azure Mobile Services, 줄여서 AMS는 여러분이 직접 살펴보시기 바랍니다. 이 시리즈의 3부에서 살펴보겠지만 AMS를 사용하여 매우 간단하게 푸시 알림을 만들 수 있을 뿐 아니라 다음과 같은 다양한 방법으로 주기적 업데이트 서비스를 지원할 수 있습니다.

Mobile Services의 경우 다른 서비스에 요청을 보낼 수 있는 예약된 백그라운드 작업을 만들어서 그 결과를 데이터베이스에 저장할 수 있습니다. Mobile Services에서 반복 작업 예약하기 항목을 보면 Twitter에서 트윗을 가져오는 예를 확인할 수 있습니다.
AMS(또는 Windows Azure의 다른 위치)에 SQL Server 데이터베이스를 만들면 다른 웹 호스팅 SQL Server 데이터베이스처럼 해당 데이터베이스에 액세스할 수 있습니다. 따라서 PHP로 작성된 것을 포함한 웹 사이트 및 기타 서비스에서 SQL Server 데이터베이스를 사용할 수 있습니다.
AMS는 Mobile Services SDK를 사용하여 정말 간단하게 클라이언트 앱에서 데이터베이스에 레코드를 삽입할 수 있습니다.
Mobile Services와는 달리 Windows Azure는 Node.js, Python, Java, PHP, .NET을 포함한 다양한 언어로 작성된 서버 쪽 프로세스를 호스팅할 수 있습니다.

향후에는 주기적 알림 서비스를 포함한 임의의 http 끝점을 만들 수 있는 “서비스 작업”이라는 새로운 기능이 Azure Mobile Services에 추가될 것입니다.

Windows Azure에 대한 자세한 내용은 http://www.windowsazure.com을 참조하십시오. 채널 9의 Windows Azure Mobile Services 자습서로 들어가면 소개 비디오도 볼 수 있습니다.

오늘은 주기적 알림 서비스를 만드는 방법을 살펴보았으니 다음에는 푸시 알림에 대해 알아보겠습니다. 주기적 알림으로 하는 것보다 더 자주 업데이트를 해야 할 때, 다시 말해 필요할 때마다 업데이트하기 위해 사용하는 것이 푸시 알림입니다. 그래서 떠민다는 의미로 “푸시”라는 이름이 붙었습니다. 이 주제는 3부에서 다룰 것이며, 3부에서는 Azure Mobile Services에 대해 자세히 살펴보겠습니다.

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

생생한 활동 업데이트 1부: 타일, 배지 및 알림 작업

Windows 8 Team — Wed, 06 Mar 2013 00:10:07 GMT

라이브 타일 및 타일과 관련된 배지 기능, 알림 메시지, 푸시 알림은 Windows 8 및 Windows 스토어 앱의 가장 대표적인 특징 중 하나입니다. 이러한 것들이 결합되어 "생생한 활동 업데이트" 시스템을 구성합니다. 앱이 실행되지 않을 때에도 시작 화면과 잠금 화면 양쪽에 표시되는 서비스에서 끊임없이 앱으로 정보가 전달됩니다.

이 블로그의 이전 글에서는 라이브 타일 및 알림과 관련된 기본 기능 몇 가지를 살펴보았습니다.

이전 글은 아래와 같습니다.

뛰어난 라이브 타일 환경 만들기(1부): 타일 디자인을 소개하고 앱 기능에 따라 템플릿을 선택하는 방법을 설명합니다.
뛰어난 라이브 타일 환경 만들기(2부): 앱에서 로컬 업데이트를 보내고, 주기적인 알림을 설정하고, 보조 타일을 관리하는 방법을 설명합니다. PHP 및 ASP.NET의 서비스 구조에 대해서도 소개합니다.

세 번째에 해당하는 이 글에서는 앞의 두 글에서 소개한 내용을 바탕으로 여러 영역을 보다 자세히 다루겠습니다.

이 글의 1부에서는 다음 내용을 다룹니다.

사용자 경험을 눈으로 간략하게 살펴보기: "생생하다"는 것이 사용자에게 주는 의미
템플릿 카탈로그로는 파악하기 어려울 수도 있는 다양한 기능을 확실하게 보여 주는 타일, 배지 및 알림 메시지의 XML 스키마
타일, 알림 및 백그라운드 작업의 관계

2부에서는 여러 언어로 서비스를 작성하고 디버깅하는 방법을 설명합니다. 특히 Visual Studio 2012 Express for Web/Visual Studio 2012와 함께 로컬 호스트를 사용하는 방법을 소개합니다. 또한 Windows Azure Mobile Services를 이러한 용도로 사용하는 방법에 대해서도 간략하게 설명하겠습니다.

그런 다음 3부에서는 푸시 알림을 살펴보겠습니다. WNS(Windows 푸시 알림 서비스)를 사용하는 방법과 Windows Azure Mobile Services를 사용하여 앱에서 푸시 알림을 지원하는 방법을 설명할 것입니다.

이러한 3부작으로 구성된 이 글에서는 //Build 2012, 3-101 생생한 활동 업데이트에서 발표된 세션 I의 내용을 좀 더 보충하여 구체적으로 살펴볼 것이며, 채널 9에서 동영상과 슬라이드를 이용할 수 있습니다. 또한 제 무료 전자책의 13장에 수록된 Microsoft Press HTML, CSS 및 JavaScript로 Windows 8 앱 프로그래밍의 내용을 복습하고 보충할 것입니다. 이 보도 자료는 제목과는 달리 다른 언어로 작업하는 개발자에게 상당히 도움이 됩니다.

"생생하다"는 것이 사용자에게 주는 의미

이 시리즈에서 우리가 말하는 “생생하다”는 표현이 무슨 뜻인지 사용자가 확인할 수 있는 위치는 시작 화면과 잠금 화면, 그리고 알림 메시지가 나타나는 모든 곳입니다.

이제 여러분은 시작 화면에 표시되는 타일 개념을 완전히 파악하셨을 것입니다. 아래 예처럼 타일은 정사각형과 와이드의 두 종류가 있으며 다양한 레이아웃 템플릿을 사용하여 텍스트, 이미지 또는 둘 다 표시할 수 있습니다. 색상은 앱 매니페스트에 의해 정의됩니다. 앱에서 정사각형 타일과 와이드 타일을 모두 지원한다면 사용자가 둘 중에서 선택할 수 있습니다. 타일의 왼쪽 아래에 앱 이름과 로고를 표시하거나, 아무 것도 표시하지 않을 수도 있습니다. 오른쪽 아래에는 작은 ‘배지’를 표시할 수 있습니다. 배지는 1부터 99 사이의 숫자(메일, 메시지 등의 경우) 또는 미리 정의된 문자 모양입니다(배지 이미지 카탈로그 참조).

또한 타일 템플릿에는 이미지 같은 콘텐츠의 첫 번째 부분과 텍스트 같은 두 번째 부분 간에 전환되는 다양한 "미리 보기" 디자인이 포함되어 있습니다. 타일 템플릿 카탈로그에서는 높이가 두 배인 타일처럼 보이지만 사실은 절반씩 두 개가 모두 표시된 것입니다. 시스템에서는 다른 타일 애니메이션에 맞추어 이러한 두 부분 간에 전환 애니메이션을 실행합니다. 뿐만 아니라 타일의 대기열에 자동으로 순환하는 업데이트를 최대 5개까지 포함할 수 있습니다. 시스템에서는 이러한 업데이트를 다른 타일과 맞추어 다시 애니매이션 처리합니다. 대기열의 각 업데이트에 태그를 지정하여 각 업데이트를 개별적으로 대체할 수 있습니다. 그냥 둘 경우 먼저 들어온 순서대로 처리됩니다.

애니매이션 간에 이루어지는 이러한 조정 작업을 살펴보면 Windows가 타일 업데이트를 미리 정의된 템플릿으로 제한하는 이유를 이해할 수 있습니다. 타일에서 앱이 제각각 실행되게 둘 경우 시작 화면이 어떻게 될지 상상해 보십시오. 뿐만 아니라 타일에서 동영상이 제멋대로 재생되도록 둔다면 배터리는 순식간에 소모될 것입니다. 이처럼 과도한 자유를 허용한다면 화면은 엉망이 될 것입니다. 완전히 고정된 시작 화면과 정반대의 모습이 되겠지만 보기 좋지 않은 화면이 될 것은 분명합니다. Windows 디자이너들은 오래 봐도 질리지 않는 시작 화면을 만들고 싶어했습니다. 그 결과, 생생하게 살아 움직이면서도 모든 타일이 조화를 이루며 통합된 느낌을 주는 사용자 경험을 개발했습니다. 템플릿과 시스템에서 제어하는 애니메이션을 사용하면 적당히 통일된 느낌을 주면서도 앱의 개성을 충분히 표현할 수 있습니다. 한 가지 기억할 것은, 언제든지 이미지 전용 템플릿을 사용하여 그 안에 원하는 디자인을 배치할 수 있습니다. 하지만 타일의 다른 부분에 대한 다른 동작을 제안하는 단추 같은 이미지는 만들면 안 됩니다. 이러한 기능은 지원되지 않습니다.

알림 메시지는 시작 화면, 잠금 화면, 바탕 화면 또는 실행되는 앱 위에 표시됩니다. 알림을 탭하면 알림을 발급할 때 지정된 인수를 통해 관련 앱이 작동됩니다. 알림은 관련 앱의 매니페스트에 정의된 색상으로 표시되며 오른쪽 아래에 앱 로고가 표시됩니다. 사용자는 색상과 로고를 통해 알림을 탭할 경우 어떤 앱이 작동하게 되는지 쉽게 알아볼 수 있습니다.

타일과 마찬가지로, 각 알림의 레이아웃은 알림 템플릿 카탈로그의 템플릿에 의해 정의되며 텍스트 전용 템플릿과 텍스트와 이미지를 모두 사용할 수 있는 템플릿 중에 선택할 수 있습니다. 알림은 한동안 표시되었다가 사라집니다. 알림과 함께 소리가 나도록 설정할 수 있으며 회의 알림과 마찬가지로 반복해서 나타나게 할 수도 있습니다.

잠금 화면에서는 날짜, 시간 및 시스템 배지와 함께 앱 활동이 표시됩니다. 아래 예에서 보시는 것처럼 앱 콘텐츠는 최대 7개의 로고와 화면 아래에 표시되는 배지, 그리고 시간 옆에 표시되는 텍스트 업데이트로 구성됩니다.

사용자는 PC 설정 > 개인 설정 > 잠금 화면으로 이동하여 잠금 화면에 표시할 항목을 선택할 수 있습니다. 아래는 그 예입니다. 첫 번째 줄에서 사각형 중 하나를 탭하면 잠금 화면을 지원하는 앱 목록이 나타납니다. 이러한 앱은 로고 및 배지로 표시됩니다. 두 번째 줄에서는 자세한 텍스트를 표시할 앱을 선택할 수 있습니다. 이 텍스트는 해당 앱의 가장 최신 타일 업데이트에서 옵니다.

업데이트 XML

사용자 경험이 살아 있다는 말의 의미를 살펴보았으니 지금부터는 이러한 업데이트가 무엇으로 구성되는지, 즉 타일 업데이트, 배지 또는 알림 메시지를 어떻게 설명해야 하는지 알아보겠습니다.

'원시' 알림을 제외한 모든 업데이트는 Windows에서 처리하여 타일을 업데이트하거나 알림을 표시할 수 있는 간단한 XML 조각으로 구성됩니다. (원시 알림은 앱별 텍스트 또는 이진 데이터로 구성됩니다. 이러한 알림을 수신하는 앱 또는 백그라운드 작업은 일반적으로 해당 데이터를 처리한 후 그에 대한 응답으로 타일 업데이트, 배지 업데이트 또는 알림을 실행합니다.)

우리가 사용하는 템플릿은 이러한 업데이트를 위한 XML 구조일 뿐입니다. 예를 들어 숫자 7에 대한 배지 업데이트는 다음과 같이 보입니다.

<badge value="7"/>

이러한 XML 비트가 자주 호출되며, 앞에서 본 가운데 아래 타일의 빨간색 점 배지를 표시하는 '페이로드'는 다음과 같습니다.

<badge value="busy"/>

이처럼 이미지 참조, 텍스트 및 로고/이름 옵션이 포함된 와이드 타일의 XML 페이로드는 'TileWideSmallImageAndText01' 템플릿을 사용할 경우 아래와 같으며 더 많을 수도 있고 더 적을 수도 있습니다(이미지 URI는 가상).

<tile>
  <visual>
    <binding template="TileWideSmallImageAndText01" branding="logo">
      <image id="1" src="http://friends.contoso.com/sally.png" alt="Sally's picture"/>
      <text id="1">Hey, you there? Txt me when you’re back</text>
    </binding>
  </visual>
</tile>

이 페이로드를 잘 보면 템플릿을 'binding' 요소 내에 표시한다는 것을 알 수 있습니다. 나머지 XML은 Windows가 해당 템플릿과 비교하여 검사합니다. 'binding' 요소의 branding 특성은 'logo', 앱의 'name' 또는 'none'을 표시할지를 나타냅니다. 그런 다음 'binding'의 하위 요소는 템플릿에서 필요한 나머지 부분을 설명합니다.

지금은 업데이트에 사용되는 특정 템플릿을 자세히 살펴보기 보다는 일반적인 XML 스키마를 살펴보겠습니다. 이러한 스키마는 각 업데이트에 사용할 수 있는 추가 기능을 표시합니다. 다시 말해서 타일 템플릿 카탈로그, 배지 이미지 카탈로그, 알림 템플릿 카탈로그는 필수 요소인 스키마만 표시하지만 추가 옵션이 모두 표시됩니다.

스키마에 대한 설명은 설명서의 타일, 알림 및 배지 스키마 단원에서 확인할 수 있습니다. 하지만 구체적인 내용은 여러 주제에 걸쳐 나뉘어 있기 때문에 지금은 아래의 의사 스키마를 통해 전체적인 구조를 살펴보는 것으로 요약 정리하겠습니다.

배지 업데이트는 가장 간단합니다. 그럼 시작하겠습니다.

<?xml version="1.0" encoding="utf-8" ?>
<badge value = "1-99" | "none" | "activity" | "alert" | “attention” | "available" |
    "away" | "busy" | "newMessage" | "paused" | "playing" | "unavailable" | "error" 
    version? = "integer" />

기술적으로는 모든 XML 페이로드에 '<?xml>' 헤더 태그가 있어야 합니다. Windows는 헤더 태그가 없어도 아무 문제 없이 작동하지만 저는 완벽을 기하기 위해 헤더 태그를 사용합니다.

그 다음으로 'badge' 요소에 'value' 특성이 들어갑니다. 값으로는 숫자를 입력하거나(99보다 큰 숫자는 “99+”로 표시됨) 또는 특정 문자 모양을 식별하는 미리 정의된 단어 중에 선택할 수 있습니다. 자세한 내용은 설명서의 배지 이미지 카탈로그에서 확인할 수 있습니다.

'version'은 이 중에서 유일한 기타 특성으로, 선택 사항입니다. 이름 뒤의 '?'는 선택 사항이라는 의미로, 나중에 스키마로 변경할 수 있습니다. 선택 사항이기 때문에 페이로드에서 생략해도 됩니다.

타일 업데이트의 의사 스키마는 아래와 같습니다.

<?xml version="1.0" encoding="utf-8" ?>
<tile>
  <visual version? = "integer" lang? = "string" baseUri? = "anyURI" fallback? = "string"
    branding? = "none" | "logo" | "name" addImageQuery? = "boolean" >

    <!-- One or more binding elements -->
    <binding template = "TileSquareImage" | "TileSquareBlock" | "TileSquareText01" | ... 
      fallback? = "string" lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >
      
      <!-- Some combination of image and text elements -->
      <image id = "integer" src = "string" alt? = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>
</tile>

'visual' 요소에는 업데이트에 전체적으로 적용되는 특성이 들어 있습니다. 선택 사항인 'version' 특성은 생략해도 됩니다. 기타 특성에 대한 설명은 아래와 같습니다.

특성	설명
lang	“en-US”나 “de-DE” 같은 업데이트 날짜의 언어를 식별하는 BCP-47 문자열이며 선택 사항입니다.
baseUri	페이로드의 모든 URI 앞에 추가되는 선택적 URI로, 페이로드를 구성할 때 반복되는 정보를 생략하고자 할 때 사용합니다. 기본값은 “ms-appx:///”입니다.
branding	타일에 앱 로고(기본값은 “logo”)와 이름(“name”)을 표시하거나 아무 것도 표시하지 않도록(“none”) 선택할 수 있습니다.
addImageQuery	“true”로 설정할 경우 (기본값은 “false”) 페이로드의 URI로 전송되는 모든 요청에 쿼리 매개 변수를 추가하라고 Windows에 지시합니다. 즉, 각 이미지 URI에 대해 현재 언어, 배율 및 대비 설정을 확인합니다. 매개 변수의 형식은 다음과 같습니다. ?ms-scale=<scale>&ms-contrast=<contrast>&ms-lang=<language> 자세한 내용은 타일과 알림 메시지의 세계화 및 접근성을 참조하십시오.

'visual' 내의 페이로드에는 각 타일 크기를 나타내는 'binding' 요소가 하나 이상 있습니다. 즉, 단일 페이로드에 정사각형 타일과 와이드 타일의 업데이트를 모두 넣을 수 있습니다(가장 이상적임). 사용자가 언제든지 타일 크기를 변경할 수 있기 때문에 이렇게 하는 것이 중요합니다. 어느 한 크기를 생략하면 사용자가 해당 타일을 선택해도 업데이트가 표시되지 않습니다. 하지만 각 타일마다 별도로 업데이트를 보낼 수 있으며 Windows는 두 타일을 모두 유지합니다.

'binding' 내부를 살펴보면 검사할 XML 템플릿을 지정하는 'template' 특성이 있습니다. 'visual'에도 같은 특성이 있는데 다만 이 'binding' 요소에만 적용되며 'visual' 요소를 재정의한다는 차이점이 있습니다. 유일한 기타 특성인 'fallback'은 기본 템플릿을 찾을 수 없을 경우에 사용할 템플릿을 지정합니다. 이전 버전과의 호환성을 위한 특성이므로 Windows 8에서는 사용할 필요가 없습니다.

각 'binding' 내에는 템플릿에 따라 'image'와 'text' 요소가 조합되어 있습니다. 이러한 각 요소의 특성에 대해서는 이미 설명을 드렸거나 따로 설명하지 않아도 잘 아실 것이라 생각합니다. 이미 짐작하시겠지만 'binding'이나 'visual'에도 표시되는 'image' 또는 'text'의 모든 특성은 상위 요소의 특성 값을 재정의합니다.

알림 메시지는 타일과 구조가 비슷하지만 몇 가지 추가 기능이 있습니다.

<toast launch? = "string" duration? = "long" | "short" >
  <visual version? = "integer" lang? = "string"
    baseUri? = "anyURI" branding? = "none" | "name" | "logo" addImageQuery? = "boolean" >

    <!-- One or more bindings -->
    <binding template  = "ToastImageAndText01" | "ToastImageAndText02" | ...=""
      fallback? = "string"  lang? = "string" baseUri? = "anyURI"
      branding? = "none" addImageQuery? = "boolean" >

      <!-- Some number of child elements -->
      <image id  = "integer" src = "string" alt = "string" addImageQuery? = "boolean" />
      <text id = "integer" lang? = "string" />
    </binding>
  </visual>

  <!-- Optional audio -->
  <audio src? = "ms-winsoundevent:Notification.Default" | ...=""
    loop? = "boolean" silent? = "boolean" />
</toast>

visual 내의 모든 'lang', 'baseUri', 'branding', 'addImageQuery' 특성은 타일의 특성과 그 의미 및 기본값이 동일하며 'binding', 'image', 'text' 내의 모든 특성 역시 마찬가지입니다. 이 페이로드에서 타일 업데이트와 알림 메시지의 유일한 차이는 지원되는 템플릿입니다.

알림 페이로드를 구분하는 특징은 가장 바깥쪽에 위치한 'toast' 요소의 특성, 그리고 그 하위 요소이자 선택 사항인 'audio'입니다.

'toast'를 사용하면 앱의 활성화 처리기에 인수로 전달되는 문자열을 'launch' 특성에 할당할 수 있습니다. 이것이 바로 보조 타일에서 실행되는 작업입니다. 'duration' 특성의 값은 “short”(5초 또는 PC 설정 > 접근성의 값) 또는 “long”(25초 또는 PC 설정 > 접근성의 값이며 short보다 큼)으로 설정할 수 있습니다.

'audio'의 'src' 특성은 알림 오디오 옵션 카탈로그에서 찾은 미리 정의된 사운드 중 하나를 나타내는 문자열입니다. 현재는 이 사운드 중에서만 선택할 수 있으며, 이러한 사운드는 일반적으로 제어판에서 구성한 시스템 사운드로 매핑됩니다. 참고로 말씀 드리자면, 모든 사운드를 끄면 아무 소리도 들리지 않습니다. 앱을 테스트할 때 이 점에 주의하시기 바랍니다. 이러한 제한을 두는 여러 이유가 있습니다. 그 중 한 가지 이유로, 원격 소스의 사용자 지정 사운드를 넣을 경우 엄청난 네트워크 트래픽이 발생합니다. 장치가 잠금 화면 상태에서 전력을 절약하기 위해 연결된 대기 상태로 전환할 경우 이로 인해 문제가 발생할 수 있습니다. 알림에 오디오 광고를 삽입하는 등의 오용을 막기 위한 조치이기도 합니다.

이와는 별개로, 'silent' 특성을 “true”로 설정하면 항상 오디오가 음소거됩니다. 'loop'의 경우 알림의 'duration' 특성을 설정하고 오디오의 'src'를 카탈로그의 네 가지 “반복” 사운드(‘alarm’과 ‘call’에 각각 두 가지 사운드) 중 하나로 설정하면 'loop'를 “true”로 설정하여 사운드를 반복하거나 “false”로 설정하여 사운드를 한 번만 재생(기본값)할 수 있습니다.

오디오 반복 외에도 반복 알림의 일정을 예약할 수 있습니다. XML 페이로드에 포함되지는 않지만 ScheduledToastNotification 개체를 만들 때 지정할 수 있습니다. 이 경우 각 간격마다 같은 페이로드(오디오 및 모두)가 나타납니다.

앱을 실행하지 않아도 생생한 활동 업데이트

어떤 XML 페이로드가 어떤 업데이트를 생성하는지 알아보았으니 그 다음으로 이러한 페이로드를 적절한 시간에 시스템에 보내는 방법과 페이로드를 만드는 방법을 살펴보겠습니다. 이 두 가지 주제는 이전 글 뛰어난 라이브 타일 환경 만들기(1부) 및 뛰어난 라이브 타일 환경 만들기(2부)에서 다루었으며 코드로 페이로드를 작성하는 방법이 잘 설명되어 있습니다. Notifications Extensions 라이브러리 사용법도 설명되어 있는데 이 라이브러리는 여러 샘플에서 얻을 수 있으며 Visual Studio의 NuGet 패키지로도 제공됩니다.

지금부터 페이로드를 전달하는 메서드를 요약 정리하겠습니다. 메서드를 실행하는 세 가지 방법이 있습니다.

실행 중인 앱 또는 앱의 백그라운드 작업에서 직접 또는 로컬 업데이트를 실행할 수 있습니다. 바로 실행할 수도 있고 나중에 실행되도록 예약할 수도 있습니다. 타일, 배지 및 알림에도 만료 시간이 있습니다. 이 시간까지 타일, 배지, 알림이 전달되지 않으면 자동으로 제거되거나 일정에서 제거됩니다.
실행 중인 앱은 Windows에 주기적 업데이트를 위한 URI를 최대 5개까지 제공할 수 있으며 간격은 30분부터 하루까지 지정할 수 있습니다. URI를 여러 개 사용할 경우 각 URI는 업데이트 대기열의 슬롯 5개 중 하나에 해당합니다. 주기적 업데이트가 구성되면 Windows는 각 간격마다 해당 URI에 요청(HTTP GET)을 보냅니다. 요청의 결과로 Windows에 유효한 페이로드가 반환되면 마치 실행 중인 앱이 업데이트를 직접 실행하는 것처럼 Windows가 앱을 대신하여 상응하는 타일로 해당 업데이트를 보냅니다. 이 시리즈의 2부에서는 업데이트 서비스를 만드는 방법을 살펴보겠습니다.
주기적 업데이트의 주요 장점은 앱이 실행되지 않는 동안에도 계속해서 요청을 보내기 때문에 사용자가 앱을 전혀 실행하지 않아도 한동안은 진행 중인 업데이트와 배지가 타일에 전달된다는 것입니다. 물론 사용자가 업데이트에 관심을 갖고 여러분의 앱을 다시 방문하는 것이 가장 좋겠죠!
앱에서는 WNS(Windows 푸시 알림 서비스) 채널 URI를 요청하여 해당 URI를 앱 자체의 백엔드 서비스로 보낼 수 있습니다. 그러면 이러한 서비스에서는 WNS를 사용하여 해당 채널 URI를 통해 업데이트를 발급하게 되고, 장치가 온라인에 연결되면 WNS는 해당 업데이트를 장치로 보냅니다. Windows는 이러한 업데이트를 받아서 해당 타일에 적용하거나 알림을 표시합니다. 또는 앱이 백그라운드 작업을 구성하여 이러한 푸시 알림을 받을 수도 있습니다(원시 알림에 필요한 방법). 푸시 알림은 이 시리즈의 3부에서 다루겠습니다.

다음 표는 이러한 옵션을 정리한 것으로, 타일의 순환 대기열 기능과 알림의 반복/오디오 기능이 포함되어 있습니다.

알림 유형	대기열	일정 예약	만료	반복	오디오	주기적	푸시
타일	✔	✔	✔			✔	✔
배지			✔			✔	✔
알림		✔	✔	✔	✔		✔
원시							✔

타일과 배지에 대한 모든 옵션은 앱의 기본 타일 및 보조 타일에 똑같이 적용된다는 점을 기억해야 합니다. 보조 타일에 대한 자세한 내용은 위에서 언급한 이전 글에 잘 설명되어 있습니다. 보조 타일 샘플을 참조하시는 것도 많은 도움이 될 것입니다.

샘플 이야기가 나온 김에 추가로 알려 드리자면 앱 타일 및 배지 샘플, 예약된 알림 샘플, 푸시 및 주기적 알림 클라이언트 쪽 샘플을 살펴보시면 다양한 시나리오에 대한 완벽한 예를 확인할 수 있습니다. 이 샘플의 코드를 완벽하게 숙지한다면 앱의 타일 및 알림 관련 작업을 할 때 엄청난 도움이 될 것입니다.

모든 샘플에서, 백그라운드 작업에서도 타일, 배지 및 알림 업데이트를 실행할 수 있다는 점을 기억하시기 바랍니다. 백그라운드 작업은 앱 전체가 일시 중단되거나 메모리에 없어도 실행되는 앱 코드의 일종이라고 볼 수 있습니다. 백그라운드 작업에서 업데이트를 실행해도 메인 앱과 같은 코드가 사용되기 때문에 실질적인 차이는 없습니다.

백그라운드 작업은 다양한 조건의 상태를 확인할 때 매우 유용하며, 신속하게 수행할 수 있기 때문에 각 작업에 할당된 CPU 할당량을 준수합니다. 조건에서 요구할 경우 백그라운드 작업에서 적절한 알림을 생성할 수 있습니다. 사실 백그라운드 작업의 기본 동작은 (a)업데이트를 실행하고 (b)앱의 AppData 폴더 또는 설정 컨테이너에 값을 저장하는 것입니다. AppData 폴더 또는 설정 컨테이너에 저장된 값은 다음에 앱이 실행될 때 처리됩니다.

또한 앱이 실행되지 않을 때 원시 푸시 알림을 처리하려면 백그라운드 작업이 반드시 필요합니다. 이 내용 역시 3부에서 다루겠습니다.

백그라운드 작업에 대한 자세한 내용은 이 블로그의 이전 글 백그라운드에서 생산성 높이기와 보다 일반적인 개요가 설명되어 있는 오프스크린 상태에서 앱의 효율성 높이기를 참조하십시오.

이제 클라이언트 앱에 대해 어느 정도 익숙해지셨을 테니 2부와 3부에서는 타일, 배지 및 알림의 온라인 서비스가 하는 역할에 대해 살펴보겠습니다.

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