Developer Preview에서 Consumer Preview로 앱 마이그레이션

Windows 8 앱 개발자 블로그

Windows 8 엔지니어링 팀에서 제공하는 Windows 8용 Metro 스타일 앱 개발의 이해

Developer Preview에서 Consumer Preview로 앱 마이그레이션

  • Comments 0

저는 Windows 개발 팀에서 파트너 설계자로 일하고 있는 John Sheehan입니다.

프리뷰 버전용 앱을 개발하시는 여러분께 감사의 말씀을 드립니다. 여러분의 의견은 Windows 8 개선 작업에 많은 도움이 되고 있습니다. 프리뷰 버전에서 앱을 개발할 경우 프리뷰 버전이 새로 나올 때마다 앱을 업데이트해야 합니다. 이 글은 여러분의 프로젝트를 Developer Preview에서 Consumer Preview로 마이그레이션하는 방법을 설명하기 위해 작성된 것입니다. 이 글에서는 일부 변경 사항만 설명할 것입니다. 변경 사항에 대한 자세한 내용을 보려면 개발자 센터의 //Build to Windows 8 Consumer Preview에서 앱 마이그레이션에 대한 백서를 다운로드하십시오.

여러분의 앱을 Consumer Preview로 마이그레이션하기 전에 왜 우리가 이러한 변경 작업을 했는지 궁금해 하시는 분들이 있을 것입니다. 제가 확실하게 말씀드릴 수 있는 것은 우리는 변경 작업 하나하나를 매우 신중하게 접근한다는 사실입니다. 일부 개선 작업은 여러분의 의견을 그대로 반영했습니다. 사용자에게 혼란을 주는 기능은 보다 간단하게 변경했고, 성능이 부족하다고 지적 받은 부분은 새로운 기능을 추가했습니다. 기능을 완성하여 직접 사용해 본 결과 원하는 성능이 나오지 않아 그 동안 터득한 내용을 이용하여 개선 작업을 한 경우도 있었습니다. 우리는 수많은 요인을 고려하고 있습니다. 우리는 여러분의 Metro 스타일 앱을 위한 우수한 플랫폼을 개발한다는 목표 아래 모든 결정을 신중하게 내리고 있습니다.

제가 Developer Preview에서 개발한 Connect 4 앱의 마이그레이션 프로세스를 살펴본 결과 마이그레이션을 하려면 약간의 작업이 필요합니다. 하지만 이 글과 문서에 설명된 단계를 따른다면 마이그레이션을 매우 빠르게 수행할 수 있습니다.

그럼 시작해 봅시다!

새로 시작

기존 프로젝트를 그대로 유지하면서 Consumer Preview로 마이그레이션할 수 있다면 좋겠다고 생각하실 수 있지만 Developer Preview 이후 상당 부분이 변경되었기 때문에 새 프로젝트를 시작하는 것이 가장 좋은 방법입니다. 예를 들어 Visual Studio의 경우 프로젝트 정의 파일에 다음과 같은 여러 변화가 있습니다. JavaScript 프로젝트 확장명이 .jsproj로 변경되었고 .csproj/.vbproj 파일의 import 문이 변경되었습니다. 이러한 변경 사항 때문에 기존 프로젝트는 아예 열리지도 않을 것입니다. 새 프로젝트를 시작한 후 기존 프로젝트 조각을 새 프로젝트로 이동할 수 있습니다.

다음 단계는 코드를 마이그레이션하는 방법입니다. //Build to Windows 8 Consumer Preview에서도 마이그레이션 단계 및 마이그레이션에 대한 자세한 내용을 확인할 수 있습니다. 이 글을 읽으시는 동안 이 사이트가 여러 번 언급될 것입니다.

  1. Visual Studio에서 새 프로젝트를 만들고 기존 앱과 UI가 가장 비슷한 템플릿을 선택합니다.
  2. 새 항목 템플릿에서 파일 선택기 계약 또는 검색 계약 등 여러분에게 필요한 계약과 기능을 지원할 경우 기존 코드 대신 해당 항목 템플릿을 사용하십시오.
  3. 새 템플릿을 사용하여 UI 기본 요소를 재구성한 후 기존 프로젝트의 시각 자산 및 오디오 자산을 새 프로젝트로 마이그레이션합니다. 기존 앱에서 핵심 역할을 담당한 사용자 지정 비즈니스 논리를 제외한 나머지 코드는 가져오지 않습니다.
  4. 마지막으로, 새 템플릿을 사용하여 만든 새 UI를 시각 및 오디오 자산과 백엔드 논리에 연결합니다.

위의 단계에 따라 변경 사항을 여러분의 앱 코드에 자연스럽게 포함할 수 있습니다. 지금부터는 코드를 새 템플릿으로 옮길 때 코드에 영향을 미칠 수 있는 특정 변경 사항에 대해 설명하겠습니다.

모든 언어에 영향을 미치는 일반적인 변경 사항

먼저, 모든 프로그래밍 언어에 영향을 미치는 기본 프로그래밍 모델의 변경 사항 몇 가지를 설명하겠습니다.

매니페스트 변경 사항

매니페스트는 앱의 DNA입니다. 우리가 플랫폼에서 변경 작업을 할 때 매니페스트 구조에 영향을 미치는 경우가 자주 있습니다. 매니페스트의 변경 사항 수를 고려할 때, 새 프로젝트를 만들 때 생성되는 새 매니페스트로 시작하여 매니페스트 편집기로 새 매니페스트를 수정하는 것이 기존 매니페스트를 이식하는 것보다 훨씬 쉬운 방법입니다.

비동기 모델 핫 부팅

Developer Preview에서 모든 비동기 메서드는 콜드 부팅이었습니다. 개발자가 비동기 메서드를 호출하면 비동기 작업 개체를 다시 가져왔습니다. 개발자는 이 작업 개체의 완료 및 진행률 콜백을 등록한 다음(가능한 경우) IAsyncInfo.Start를 호출했습니다. 이 모델의 문제점은 Start 호출이 중복이라는 것입니다. 개발자로서는 메서드를 처음 호출할 때 비동기 작업이 시작된다고 생각하는 것이 당연합니다.

비동기 모델을 보다 직관적으로 만들기 위해 우리는 비동기 모델을 핫 부팅 모델로 변경했습니다. Consumer Preview에서 비동기 메서드를 호출하면 비동기 작업 개체를 다시 가져오지만 Start를 호출할 필요는 없습니다. 대신 비동기 메서드가 호출되면 작업이 암시적으로 시작됩니다. 따라서 더 이상 Start가 필요 없기 때문에 우리는 IAsyncInfo에서 Start를 제거했습니다.

이미 .then()(JavaScript) 또는 await(C#)를 사용 중인 개발자는 이 변경 사항에 영향을 받지 않습니다.

또한 C++에서 비동기 프로그래밍을 보다 쉽게 할 수 있도록 PPL 작업을 추가했습니다. //Build to Windows 8 Consumer Preview의 자습서를 살펴보신 후 비동기 코드를 PPL 모델로 마이그레이션하실 것을 권장합니다.

Windows Runtime 개체(IClosable)의 결정적 수명 관리

Windows Runtime API는 앱이 파일 핸들 및 네트워크 소켓과 같은 시스템 리소스에 액세스할 수 있도록 합니다. 이러한 리소스는 제한되어 있으며 앱이 리소스에 액세스 중이면 사용자 또는 다른 앱은 이 리소스에 액세스할 수 없습니다. 앱이 리소스 사용을 마치면 앱의 리소스 액세스를 해제해야 합니다. 그러나 Developer Preview에서는 이러한 리소스 액세스를 명시적으로 해제하는 것이 어려웠기 때문에 수많은 앱이 리소스 액세스를 필요 이상으로 오래 유지했습니다.

Consumer Preview에서는 이러한 시스템 리소스에 액세스하는 Windows Runtime API가 리소스 수명을 제어할 수 있습니다. 예를 들어 이러한 WinRT 개체는 JavaScript에서는 Close 메서드를 노출하고 C#에서는 IDisposable 인터페이스를 구현합니다. 이러한 WinRT API에 수명 관리가 바로 노출되기 때문에 앱이 시스템 리소스 사용을 마친 후 액세스를 해제하는 것이 훨씬 쉽습니다. 이러한 새 수명 관리 기능을 사용하여 앱의 리소스 소비를 줄이고, 앱이 시스템 리소스를 사용하지 않을 경우 고객이 항상 파일 등의 시스템 리소스에 액세스할 수 있도록 하십시오.

간소화된 WinRT 스레딩 모델

다른 프로그래밍 환경에 없는 고려 사항이 COM 스레딩 모델 기본 WinRT에 도입되어 혼란스럽다는 여러분의 의견을 받았으며 다음과 같은 문제점이 있었습니다.

  • 개체 수명이 처음 생성된 아파트에 연결되어 있습니다.
  • 자동 마샬링 동작이 최소 놀람의 원칙(principle of least surprise)을 위반합니다.
  • 이벤트 콜백이 예상치 못한 스레드에서 실행되는 경우가 종종 있습니다.
  • C++/C#에서 대리자가 일치하지 않습니다.

이러한 문제점을 해결하기 위해 우리는 WinRT 개체의 스레딩 모델을 변경했습니다. 상위 수준의 변경 사항은 다음과 같습니다.

  • 이제는 개체 수명이 개방형 참조에 연결됩니다. 마지막 참조가 사라질 때까지 개체가 유효하게 유지됩니다.
  • 대부분의 개체가 Agile입니다. 이러한 개체의 메서드 호출이 현재 스레드에서 바로 발생합니다.
  • 대부분의 공통 이벤트는 이벤트가 등록된 스레드로 다시 라우팅됩니다. 작업자 스레드에서 이벤트 콜백이 발생할 가능성은 여전히 남아 있습니다. 하지만 그리 흔하게 발생하지는 않습니다.
  • Developer Preview에서 C# 대리자가 그랬던 것처럼 이제 C++ 대리자는 기본적으로 Agile입니다. 대리자를 만들 때 CallbackContext::Same을 지정할 경우 대리자가 생성된 스레드로 다시 마샬링할 수 있습니다.

Windows.ApplicationModel(계약) 변경 사항

우리는 Consumer Preview의 계약을 상당히 개선했습니다. 이러한 개선 작업은 API, 기능, 매니페스트 등록 및 UI를 변경하는 방식으로 진행되었습니다. 검색, 공유, 설정 및 파일 선택기 등의 모든 계약이 개선되었습니다. 예를 들어 앱이 Save As target처럼 동작할 수 있는 새로운 파일 선택기 계약 FileSavePickerActivatedEventArgs를 추가했습니다. 이것은 매우 강력한 기능으로써 이 기능을 사용하면 사용자가 마치 로컬 디스크를 사용하는 것처럼 간단하게 파일을 열어서 여러분의 클라우드에 저장할 수 있는 선택기를 만들 수 있습니다. 이 변경 사항을 적용하기 위해 우리는 Consumer Preview의 파일 선택기 계약 이름을 FileOpenPickerActivatedEventArgs로 변경했습니다.

Visual Studio에서 지원되는 계약의 경우 이러한 변경 사항을 포함하는 가장 손쉬운 방법은 새 항목 템플릿을 사용하여 계약을 처음부터 새로 만드는 것입니다. 그런 다음 계약을 지원하는 기존 코드를 새 템플릿에 추가하면 됩니다.

URI 프로토콜 방식

수많은 API�� URI 프로토콜 방식을 사용하여 앱 패키지 또는 앱 ApplicationData 상태 위치의 콘텐츠에 액세스합니다. 이러한 API는 Metro 스타일 앱에 HTML/CSS/JS, 라이브 타일, ResourceLoader API, XAML WebView 컨트롤 및 저장소 API로 작성된 리소스 태그를 포함합니다.

우리는 모든 Metro 스타일 앱 및 Windows 8 통합 지점에서 프로토콜 이름이 일치하도록 하기 위해 프로토콜 이름을 변경했습니다. 또한 이러한 프로토콜 방식의 이름을 다음과 같이 변경했습니다.

Developer Preview 방식

Consumer Preview 방식

ms-wwa://

ms-appx://

ms-wwa-web://

ms-appx-web://

localfolder://

ms-appdata://

또한 이제 XAML 앱은 ms-appx:// 등의 지원되는 프로토콜 방식을 사용하여 리소스에 액세스하도록 제한됩니다.

HTML/CSS/JS Metro 스타일 앱의 중요 변경 사항

Consumer Preview의 여러 변경 사항 중 HTML/CSS/JS로 작성된 Metro 스타일 앱과 관련된 것이 많습니다. 다음은 주목할 만한 변경 사항입니다.

컨트롤 변경 사항

여러분의 의견을 수렴하여 Developer Preview에서 사용 가능한 JavaScript 및 HTML 컨트롤을 대폭 변경했습니다. 이제 더 간단하게 앱에 컨트롤을 추가할 수 있으며, 컨트롤을 콘텐츠에 연결하는 데 사용되는 메서드가 보다 직관적으로 변했습니다. ListView, AppBar 및 FlipView 컨트롤에 주목할 만한 변화가 있었으며 여러분은 이 컨트롤을 업데이트해야 합니다. 예를 들어 여러분은 더 이상 ArrayDataSource를 사용하여 ListView를 채울 수 없습니다. 대신 이제는 WinJS.Binding.List를 사용하여 ListViews를 채울 수 있습니다. Binding.List를 사용하면 메모리 데이터에서 ListView로 작업하기가 한층 수월합니다.

다시 한 번 말씀드리지만 컨트롤 변경 사항에 대한 모든 내용은 //Build to Windows 8 Consumer Preview에서 확인할 수 있습니다.

최상위 문서 내에서 탐색

이전에는 로컬에서 패키지된 StartPage에서 웹 기반 URL까지 앱의 최상위 문서 내에서 탐색할 수 있었습니다. 이로 인해 앱이 일시 중지 및 재개 등의 중요한 알림과 상호 작용을 전혀 할 수 없었습니다. 이러한 이벤트는 Windows Runtime 이벤트이므로 보안상의 이유로 웹 컨텍스트에서 WinRT 개체에 액세스할 수 없기 때문입니다. Consumer Preview에서는 더 이상 로컬 컨텍스트에 없는 콘텐츠로 이동할 수 없습니다. 다시 말해, 앱 패키지에서 온 것이어야 하며 ms-appx:// 프로토콜 방식을 통해 참조되어야 합니다.

결과적으로 iframe을 사용하도록 앱 논리를 재구성하여 항상 메모리의 로컬 컨텍스트에서 웹 콘텐츠를 로드하고, 지속적인 단일 최상위 문서를 유지하도록 해야 합니다

WinJS 조각 로드 및 페이지 모델

Developer Preview에서 HTML/CSS/JS Metro 스타일 앱의 탐색 모델은 조각 로드 API를 사용하여 앱 내의 다른 페이지로 이동합니다. 이 모델은 불완전하며 개발자가 컨트롤 초기화 및 페이지 상태 같은 작업을 처리하기 위해 상당히 많은 코드를 작성해야 합니다.

Consumer Preview에서는 페이지 내의 콘텐츠를 로드할 때 사용되는 JavaScript용 Windows 라이브러리(WinJS)의 상위 수준 페이지 컨트롤을 도입했습니다. 또한 이러한 페이지 컨트롤을 사용하도록 Visual Studio 템플릿을 업데이트했습니다. 대부분의 경우, 페이지 컨트롤은 조각 로드 API를 바로 처리하지 않아도 됩니다. 따라서 HTML 조각 탐색이 훨씬 간단합니다.

페이지 컨트롤은 조각 로더를 기반으로 합니다. 페이지 컨트롤은 렌더링된 조각을 백업하는 실제 개체를 제공하고, 개발자가 상태를 저장할 수 있는 장소를 제공하고, 조각 상위-하위 관계를 지정합니다. 부모가 있는 DOM 요소에 연결된 조각을 백업하는 WinJS 컨트롤은 조각에 잘 정의된 수명을 제공합니다. 또한 이 컨트롤 개체에 임의의 메서드 또는 상태를 추가할 수 있습니다.

처리되지 않은 예외 발생 시 앱 종료

JavaScript는 예외를 포함하는 기능의 코드 실행을 중지합니다. 그러나 감지할 수 없는 방법으로 코드를 계속 실행하는 경우가 있습니다. 이 현상이 발생할 경우 앱의 상태를 예측할 수 없습니다. 즉, 앱이 사용 중인 데이터가 유효하지 않은 것이거나 UI가 손상될 수 있습니다. 웹 브라우저에서는 사용자가 페이지를 새로 고칠 수 있으므로 이것이 허용되지만 Metro 스타일 앱에서는 사용자가 앱을 닫은 후 다시 열지 않고도 수주 동안 앱을 실행할 수 있어야 합니다.

따라서 처리되지 않은 JavaScript 오류가 발생하면 이벤트 로그에 오류 메시지가 기록되고 앱이 종료됩니다.

XAML Metro 스타일 앱의 중요 변경 사항

XAML Metro 스타일 앱을 개발하신 분들은 자신의 프로그래밍 언어와 관련된 Consumer Preview의 변경 사항을 알아볼 수 있을 것입니다.

C++ 데이터 바인딩 지원

Consumer Preview에서, 우리는 C++ 개발자가 XAML UI를 사용자 지정 C++ 클래스에 훨씬 간단하게 데이터 바인딩할 수 있도록 상당한 변경 작업을 했습니다. Windows.UI.Xaml.Data.Bindable 속성을 통해 클래스에 주석을 사용하면 바인딩 엔진이 클래스를 인식할 수 있으므로 개발자는 더 이상 이 클래스에 인터페이스를 구현할 필요가 없습니다. 따라서 코드 오버헤드가 대폭 감소합니다.

탐색 API

XAML Metro 스타일 앱이 Windows.UI.Xaml.Controls.Frame.Navigate 또는 Windows.UI.Xaml.Navigation.NavigationEventArgs.Type 같은 탐색 API를 사용할 경우 약간의 신속한 변경 작업이 필요합니다. 이러한 API는 이제 Type 개체를 클래스의 문자열 이름 표현이 아닌 대상으로 허용합니다. 영향을 받는 API 전체 목록은 //Build to Windows 8 Consumer Preview에서 확인할 수 있습니다.

AppBar

우리는 사용자의 Metro 스타일 앱 경험과 일치하도록 Windows.UI.Xaml.Controls.ApplicationBar 기능을 대폭 변경했습니다. 따라서 개발자가 Metro 스타일 앱 경험을 일치시키기 위해 고민해야 하는 부분이 현저히 줄어들었습니다.

주요 변경 사항 중 하나는 개발자가 새로운 Windows.UI.Xaml.Controls.Page.TopAppBar 및 BottomAppBar 속성을 사용하여 앱 내에 AppBar를 배치할 수 있게 된 것입니다. AppBars를 앱 레이아웃에 바로 배치하지 마시고 이러한 새 속성을 사용하시기를 권장합니다. 그 외에도 여러 AppBar 속성을 추가하고, 제거하고, 이름을 변경했습니다.

의미 중심 확대/축소

의미 중심 확대/축소는 Windows 8 플랫폼에서 사용자가 콘텐츠를 확대 또는 축소하여 컨텍스트를 변경할 수 있는 상황을 의미하는 용어입니다. 예를 들어 사진 컬렉션을 확대하면 사진이 작은 축소판에서 큰 미리 보기로 변경되면서 이름, 날짜 등이 완전하게 표시됩니다. Developer Preview에서는 JumpViewer 컨트롤로 의미 중심 확대/축소를 설정했는데 이 컨트롤의 이름이 SemanticZoom 컨트롤로 변경되었습니다. 이름을 변경한 이유는 개발자가 앱에 이러한 컨트롤 중 하나를 구현할 때 개발자가 제공하는 사용자 경험을 보다 정확하게 반영하기 때문입니다.

추가 정보

이 글에서 소개한 변경 사항 외에도 Windows Runtime 및 JavaScript용 Windows 라이브러리의 여러 API가 변경되었습니다. 예를 들어 Windows Runtime에서 네트워킹, 미디어, 시스템, UI, 저장소, 장치, ApplicationModel, 전역화, 그래픽 및 데이터 네임스페이스가 변경되었습니다. 대부분은 사소한 부분만 변경되었지만 코드를 마이그레이션할 경우 앱에 필요한 모든 변경 작업을 수행할 수 있도록 주의해야 합니다. 이 글은 여러분이 새로 시작하는 것을 돕기 위해 작성되었으며 개발 플랫폼의 일부 변경 내용만 다루고 있습니다. 이 글에서 여러 차례 언급했듯이 Consumer Preview로 앱을 마이그레이션하는 방법에 대한 자세한 내용은 개발자 센터에서 //Build to Windows 8 Consumer Preview를 참조하십시오.

많은 의견 보내주시기 바랍니다. 작업 방법에 대한 의문 사항이 있을 경우 개발자 포럼에 자세한 글을 올리시면 글을 읽고 도움을 드리겠습니다.

- Windows 개발 팀 파트너 설계자, John Sheehan

  • Loading...
Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post