Windows 8 스타일  개발이 한창 유행이다물론 모바일 생태계 전반전인 유행은 아니더라도 Microsoft 기술을 하는 사람들에게는  관심 대상이다. Windows 8 운영체제가 탑재되는 테블릿도 출시가 되고, New iPad 보다 하드웨어 스팩이  좋은 테블릿 출시도 준비중인 곳이 많다고 들었다새로운 마켓이 열리는 만큼 테블릿 사용자에게는 새로운 재미를 선사해줄 것은 분명한 사실일 것이다.

Windows 8 스타일 개발을 위해  가지 알아야  구조적인 개념이나 유의사항 정도만 언급하기 위해 글을 나간다. C++/CX, C#,VB XAML(eXtensible Application Markup Language)  이용하여 WPF 데스크탑 응용 프로그램처럼 프로그래밍을   있다그리고 HTML/JavaScript 조합으로  개발 환경과 유사하게 개발을   있다.아마 대부분의 Windows 8 스타일  개발자라면 알고 있는 내용일 것이다그리나  포스팅에서는 C++/CX C#개발 언어를 기준으로 아티클 내용을 채울 것이다.

 

Windows 8 스타일  런타임 관점의 구조

[이미지 링크]

   

WinRT(Windows Runtime) 플랫폼의 구조적 아키텍처 이미지이다기존 Windows Desktop 응용 프로그램 환경과다른점은 WinRT APIs  중간에 끼어있다 WinRT  Windows 8 스타일 앱의 핵심이며, Windows  시작하는Namespace 모두 WinRT 이다.

C#,VB 개발 환경은 그나마 편리한 Library Subset  제공한다. .NET Framework 최소화 버전이라고 보면 된다.이를 .NET for Windows Store apps 이라고 부르며위의 이미지에는  내용이 빠져있다.

C++/CX  잘라 .NET for Windows Stores apps 제공되지 않는다. .NET 개발자라면 System(mscorlib.dll) 으로 시작하는 Namespace  얼마만큼 편한지 알텐데 Library Subset 제공되지 않으니 다른 방법을 사용해야한다쉬운 예로 HttpClient 같은 클래스도 C++/CX MsXml COM 컴포넌트를 이용하는 편이 낫다그렇다고 모든C++ 라이브러리를 사용할  있는 것도 아니다. 이 부분에서 특히 라이브러리의 제한이 있으므로 C:\Program Files (x86)\Windows Kits\8.0\Include\shared 폴더에서 사용가능한 Header 파일을 확인해보도록 하자.

만약 Header 파일의 pragma 선언이 Dektop Family 라면 Windows 8 스타일 앱에서는 사용할  없는 라이브러리이며상당한 Header들이 Desktop Family 속하여당장 .NET for Windows Stores apps 만큼 쓸만한 클래스들이 없다는 것이 조금 슬프다다만좋은 소식이라면 C++ boost Library 등이 C++/CX 용으로 컨버전을 시도하는 분들이많으므로조금만 기다려보면 쓸만한 라이브러리들이 대거 출연할 것으로 보인다.

   

더불어 C#, C++ 개발자들도 알고 있어야 하는  중에 하나가 WinRT COM 컴포넌트 기반의 라이브러리라는 것쯤은 들어보았을 것이다그래서 Windows 8 스타일  개발자들은 COM 대한 개념과  나아가 이를 구현할 있다면  좋다특히 C#, VB 에서 WinRT 컴포넌트를 만드는 것은  가지 지켜야할 제약이 있으므로 다음의 링크를  참고하는 것이 좋다.

C#  Visual Basic으로 Windows Runtime 구성 요소 만들기 http://msdn.microsoft.com/ko-kr/library/windows/apps/br230301.aspx

   

대신 C++/CX WinRT 컴포넌트를 만드는 것이 오히려  간단하다앞서 말했다시피 WinRT COM 컴포넌트 기반이지만기존 C++ 에서 COM 컴포넌트를 만드는 만큼 어렵지가 않다. C++ COM 구현의 첫번째는 IUnknown 인터페이스를 구현하는 것이지만, WinRT 에서는 Iunknown을 상속하는 IInspectable 인터페이스가 더 중요하다.IInspectable 인터페이스는 C++/CX 개발된 응용 프로그램이 런타임  해당 클래스의 정보를 제공하기 위한 인터페이스이다물론 기존 C++ 에서도 런타임상 클래스 정보가 필요하여 이를 직접 구현하는 방법도 있다하지만C++/CX IInspectable 인터페이스는 C++/CX 컴파일 과정에서 자동으로 구현을 해준다이는  IUnknown 인터페이스까지 자동으로 구현해준다고 보면 된다그렇기 때문에 Iunknown 인터페이스의 AddRef, Release 메서드에 대한 객체 수명주기를 WeakReference 클래스를 통해 위임할  있다. WeakReference 통해 금방 해제될  있는컴포넌트를 가비지 컬렉터 대상이 되도록 지정한다그러므로 사용 빈도가 매우 많고매번 자원 해제에 대한 비용이반복되는 것은 WeakReference 효과적으로 객체 수명 주기를 다룰  있게 한다이러한 C++/CX 특별히 제공되는 라이브러리는 Microsoft.WRL Namespace 포함되어 있다.

아직 이러한 개념적인 부분이 어렵게 느껴진다면 월간 마이크로소프트 5월호 특집 기사로 기고한 필자의 다음의 글부터 참고 바란다.

[월간 마이크로소프트 5월호 특집기사] C++ 매트로  개발을 위한 C++/CX 언어http://blog.powerumc.kr/378

   

   

Windows 8 스타일  응용 프로그램 관점

짧게 말해 Windows 8 스타일  개발은 쉽다. Visual Studio 2012에서 훌륭하게 대부분이 구현된 템플릿을 제공하기 때문에메서드 중간 중간 원하는 기능을 추가하고클래스나 XAML  만들면 된다다만이는 만든다는 것이 쉽다는 것이지 응용 프로그램 구조적인 측면에서는 전혀 쉽지 않다.

먼저 알아야  것이, Windows 8 스타일  페이지를 상태 관리  것인지 것인지부터 결정해야 한다상태 관리를 유지할 필요가 없다는 것은  개발(ASP.NET/ASP/PHP/JSP)  같은 서버 사이드 개발 환경과 유사하다특히 IIS에서부터 ASP.NET까지 연결되는 Application Pipeline 매번의 Request마다 Pooling Thread 활성화되어서버 랜더링을 통해 사용자에게 HTML Response 전달이 된다.

   

1. 상태 관리를 개별적으로 유지하고 싶다면

다음의  가지 메서드를 재정의하면 된다ASP.NET Custom Control 구현해 보았다면 VIEWSTATE 상태 유지를 위해 이런 유사한 코드를 구현해야 하는 것을  것이다.

   

Frame.Navigate 메서드는 Page Type 인자로 받고매번 새로운 인스턴스를 생성한다. (구현을 다르게 한다면 인스턴스를 이용하도록  수도 있다.) 페이지의 상태 유지야 위의 메서드를 재정의하는 정도로 끝낼  있지만페이지에 포함된 UserControl 있다면 상황은 달라진다독자마다 구현하는 방법은 다르겠지만효과적으로 상태를 관리하기 위해 UserControl 조금 귀찮아지는 존재이다인스턴스의 재사용을 위해 자주 사용하는 UserControl 대한 상태 관리를 고민해야 하다니… (현재 아티클은  내용이 대해 오픈 소스 제공으로 효과적인 방법을 제안하도록필자는 약속 하겠다.)

   

2. 상태 관리를 자동으로 캐싱하고 싶다면

상태 관리를 자동으로 캐싱하는 방법도 매우 쉽다. Page.NavigationCacheMode 프로퍼티를 Enabled 해주면 된다.물론 XAML 코드에 속성을 추가해도 된다하지만 아쉽게도 Frame.Navigate 메서드를 통해 자동으로 상태 관리를 하도록  Page 새로운 인스턴스가 생성이 된다상태 관리 캐싱에 대한 조건은 GoBack(), GoFoward()  같은Frame 이동에 대해서만 유효하다조금  이해할  없는 부분은 Page 포함된 UserControl  상태 관리 캐싱 대상에서 제외된다. (물론가능하도록   있지만 개념적으로  깊게 이해하고 구현해야 한다.)

   

3. 남발되는 async/await 의한 동기화 문제

Windows 8 스타일 앱을 사용하다가 자주 멈짓 멈짓 한다면 분명 사용자는 짜증날 것이다때문에 async / await 키워드를 더욱 자주 사용하는 편이다그렇기 때문에 UI 상태에 대한 비동기와 컴포넌트나 인스턴스 메서드 호출에 대한 비동기  모두 정확하게 Threading  대한 지식이 필요하고자유 자재로 Threading  다룰  있다면 더욱좋다. Windows 8 스타일 앱에서 가장 많이 발생하는 Threading 문제는 Thread 실행  인스턴스 해제에 대한 동기화와 Thread Cancel  대한 동기화다.

 문제를  피하기 위해서는 클래스나 라이브러리를 만들때 부터 async / await  대한 고려가 필요하다쉽게 이야기하자면 자주 쓰지 않는 편이 좋고써야  곳에 써야 한다.

   

이를  판단하려면 Thread 동기화에 대해 적어도  가지는 반드시 익히는 것이 좋다. MSDN  아래의 글들을 번정도  필독하기 바란다.

관리되는 스레딩 기본 사항 http://msdn.microsoft.com/ko-kr/library/hyz69czz 
스레딩(C#  Visual Basic) http://msdn.microsoft.com/ko-kr/library/ms173178(v=vs.110)

   

      

Windows 8 스타일  배포와 라이브러리 배포 문제

 부분은 매우 민감한 부분이고 조심스럽다실제 Windows App Store에서 테스트할  없을 뿐더러 개발 환경에서발생하는 문제이므로실제 Windows App Store  통해 발생할 수도 있을 가능성이 있을  같다. COM 기반 라이브러리나 DLL 구성 요소 등은 공유 메모리에 로드가 된다는 것을  것이다특히  부분은 COM 컴포넌트에서 민감하게 다루는 IUnknown 인터페이스의 의미와 일맥 상통한다, COM 객체의 참조 카운트(Reference Cout) 0 되지 않으면자원은 해제되지 않는다여기에서 COM 가장 고질적인 문제가 발생한다바로 DLL 지옥이다. Windows 8 스타일 앱의 메모리 위치는  메모리 영역이 아닌 공유되는 메모리 영역에 위치하고 있고, DLL Verserning 자유롭지 못하다. .NET 처럼 GAC(Global Assembly Cache)에서 DLL 버전별로 관리되지 않는다.

따라서, WinRT 런타임 라이브러리를 개발하여 배포된 Windows 8 앱이 활성화 상태일  새로운 앱에서 버전업 WinRT 런타임 라이브러리 배포시에 다른 프로세스가 점유하고 있다는 오류가 발생한다이는 앱이 초절전 유휴 상태에 진입되어도 마찬가지이다.

이찌되었든 개발 환경에서는 충분히 발생된 문제이니차후 Windows App Store에서도 발생할지는 지켜보아야 것이다.

   

Windows 8 Windows Runtime  재배포 정책  업데이트

 런타임 라이브러리인 만큼 라이브러리 코드가 완벽하지는 않을 것이다. .NET Framework 1.0부터 4.5까지 버전업이 되어왔는데 과연 Windows 8 Windows Runtime 어떻게 버전업이 될까사용자의 동의 없이 업데이트나패치는 불가능하다.

   

Windows 8 Features Pack 1,2,3… 시리즈로 업데이트가 될까?
Windows 8 Service Pack 1,2,3… 시리즈로 업데이트가 될까?

   

만약 이렇게 되면, Windows 8 스타일  간에 호환성 문제가 발생할 것이 분명하다. Apple iPhone 모바일 폰의운영체제 업데이트가 실시간으로온라인으로 이루어진다. Windows 8  iPhone 업데이트와 차원이 달라진다. WinRT 지원하는 ARM 버전과 기존의 Windows 8 Desktop 지원하는 x86 버전   가지의 에디션이 있다.

혹시  부분에 대해서 알고 있는 정보가 있으면 공유 부탁 드립니다.