Windows 8 스타일 앱 개발에 대한 고찰

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

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