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 버전 가지의 에디션이 있다.

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

신고
Posted by 땡초 POWERUMC

댓글을 달아 주세요