PROGRAM PARK

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# 개발언어를기준으로아티클내용을채울것이다.

[이미지링크]

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++/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월호특집기사로기고한필자의다음의글부터참고바란다.

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.NETCustomControl을구현해보았다면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 에아래의글들을한번정도꼭필독하기바란다.

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 엄준일 (POWERUMC)

출처http://blog.powerumc.kr/trackback/390