사실, Xamarin이 크로스 플랫폼 앱을 개발하는데 가장 뛰어난 툴이라고는 할 수 없다. 단지 크로스플랫폼 앱을 빠르게 만들고 싶다면, Codova를 이용한 하이브리드앱이나 AIR, Corona SDK 같이 완전히 동일한 코드를 실행하는 다른 크로스 플랫폼 도구를 사용하는 것이 나을 수도 있다. 다만, Xamarin의 장점은 다른 언어가 아닌 C#으로 개발할 수 있다는 점, Visual Studio를 이용할 수 있다는 점, 기능 제약이 없는 네이티브 앱을 개발할 수 있다는 점 등이 특징이다.
완전히 동일한 코드를 사용하는 것은 아니지만 최대한 코드 재사용성을 높이는 방법을 살펴보고 얼마나 코드 재사용이 가능할지, 어느 정도 할만한지를 확인하는 것이 이 글의 목적이다.
자료를 조사하면서 Xamarin 크로스 플랫폼 앱을 개발하는 데 있어서, Portable Class Library를 이용해 공용 라이브러리를 만들거나, Shared 프로젝트를 이용해 코드를 공유하는 방법 등을 이용할 수 있다는 것을 알게 되었다.
Portable Class Library(이하 PCL)는 Windows Phone 7 시절에 서로 다른 .NET 프로젝트에서 이식 가능한 라이브러리를 만들 수 있도록 한 것이고, Shared 프로젝트는 Universal Windows App에서 Windows/Windows Phone 프로젝트간 코드 공유를 위해 나온 것이다. Universal Windows App을 위해서 나온 것이지만, 다른 C#, C++, WWA/JS 프로젝트에서도 사용할 수 있도록 하는 Shared Project Reference Manager라는 VS 확장기능도 있다. PCL과 Shared 프로젝트는 개념이 서로 다르다. 두 가지의 차이에 대해서 설명한 글도 있는데 내용을 요약하면 다음과 같다.
- PCL은 공통 API만 사용 가능하고 플랫폼 고유의 코드를 추상화 레이어 없이는 사용할 수 없는 반면, Shared 프로젝트는 플랫폼 고유의 코드를 사용할 수 있고 XAML UI도 공유할 수 있다.
- PCL과 Shared 프로젝트는 컴파일과 배포 시점에 완전히 다르게 동작한다. PCL은 계약과 구현에 의해 컴파일할 수 있으나, 빌드와 배포 시점에 플랫폼 고유 버전이 사용된다. Shared 프로젝트는 그 것이 속해 있는 부모 프로젝트와 부모의 레퍼런스에 따라 컴파일하고 배포된다.
- 글쓴이(Xamarin Developer Evangelist)는 PCL은 라이브러리 개발자, Shared 프로젝트는 앱 개발자를 위한 것이라고 생각하지만, 앱 개발자의 취향에 따라서 PCL 선택할 수 있지만, PCL의 제약으로 인해서 Shared 프로젝트를 더 많이 쓸 생각이라고…
PCL과 Shared 프로젝트를 함께 쓰는 것도 괜찮은 것 같다. System.Net.Http와 같이 PCL 버전으로 만들어진 라이브러리를 사용하면서 Shared 프로젝트에 공유 코드를 담는 방식으로 구현하는 것이 좋겠다는 생각이 든다.
먼저 Xamarin 크로스 플랫폼 앱 개발 문서에도 나와 있는 PCL을 이용하는 방법에 대해서 살펴보고자 한다. 이전 글에서 3가지 코드 공유 옵션을 간단히 살펴 보았지만, 그 중에서는 PCL을 만들어서 공유 컴포넌트를 만들어 사용하는 것이 가장 재사용성이 높다고 생각된다. (File Linking 방식은 Shared 프로젝트로 대체 가능하다.)
참고로, Visual Studio 없이 Xamarin Studio에서 PCL을 사용하려면 Portable Library Tools가 필요하다.
Visual Studio에서 기존 VS 솔루션에 Portble Class Library 프로젝트를 새로 추가하면 아래와 같은 화면이 나온다. Xamarin이 설치되어 있으면 Targets 리스트에 Xamarin.Android와 Xamarin.iOS가 나오게 된다.
PCL에서 코드를 작성하면 같은 API라도 IntelliSense로 접근 가능한 옵션이 다르게 나온다. 아래는 Xamarin용으로 사용하는 프로파일과 기본 프로파일의 비교이다. 우측 스크롤바를 통해 비교할 수도 있지만, 각각 14개(PCL) vs 40개(일반적인 프로젝트)의 클래스가 사용 가능하다.
이러한 이유로 사용 가능한 API에 상당한 제약이 있다. 아래는 PCL을 만들 때 참고할 수 있는 지원 기능 리스트이다. (출처)
PCL을 사용할 때는 여타 라이브러리와 마찬가지로 아래와 같이 프로젝트 레퍼런스에 추가하여 사용한다.
아래 솔루션 구성을 보면 맨 아랫 부분에 PCL 프로젝트가 있고, Reference 폴더에 PCL이 추가된 것을 볼 수 있다.
PCL 사용 방법은 살펴보았지만 실제로 포팅이 잘 될지는 모르겠다. Universal Windows App은 아니지만, Silverlight로 만들어진 앱을 포팅하는 가이드도 있긴 하다.
- Porting existing .NET apps to iOS
- Porting existing .NET apps to Android
- Porting existing .NET apps to Four Mobile Platforms using PCL
이 중 Android로 포팅하는 것을 참고로 하여 기존에 Windows Phone 8.1 앱 개발 튜토리얼에 나오는 FlickrSearch라는 Universal Store App을 한번 포팅해보고자 한다.
FlickrSearch는 Flickr Open API를 이용해서 특정 키워드(flower)로 검색한 이미지 결과를 GridView에 뿌려주는 Universal Windows App 앱이다. 두 앱은 완전히 동일한 MainPage(xaml/cs) 코드로 동작한다.
먼저, Xamarin’s .NET Mobility Scanner라는 웹사이트 툴을 이용해서 dll이나 exe 파일을 검사하여, 코드를 얼마나 재사용 가능한지를 살펴보는 것을 권장하고 있다. 아래는 FlickrSearch 앱의 Phone 패키지 폴더에서 exe 파일을 넣고 돌려본 결과이다.
예전에 다른 Windows Phone Silverlight 앱을 넣었을 때는 61%가 나왔는데, 보통 60~70% 정도의 결과가 나오는 것 같다. 그런데 실상 결과 리스트를 보면 항목이 너무 많이 나와서 이걸로 포팅하는데 얼마나 도움이 될까 싶기도 하다.
FlickrSearch 솔루션에 Android 포팅을 위해서 FlickrSearch.Android라는 이름으로 Android Application 프로젝트를 추가하고, 여기를 참고하여 FlickrSearch.Shared 프로젝트를 레퍼런스로 추가하였다. 이 때 App.xaml.cs 파일과 TemplateUtility.cs는 Xamarin에서 실행되지 않으므로, 코드 전체를 #if NETFX_CORE ~ #endif로 처리해 주었다.(이럴꺼면 왜 Shared 프로젝트? 라고 생각할 수도 있지만, 일단 Windows/Windows Phone 프로젝트에서 사용하기도 하고, FlickrSearcher.cs 파일은 Android에서도 재사용할 수 있다.)
FlickrSearcher.cs 파일이 실제로 Flickr API를 호출하는 클래스인데, 이 프로젝트에서 유일하게 재사용 가능한 코드이다. 그런데 원래 예제에서는 Windows.Http를 사용하고 있다. 따라서 Xamarin.Android에서는 사용할 수 없고, 다행히(?) PCL로 제공되는 System.Net.Http 를 사용할 수 있기 때문에 이 것으로 바꾸어 주어야 한다. 여기서 PCL 버전의 System.Net.Http을 찾을 수 있었다.
앞서 PCL과 Shared 프로젝트를 함께 쓰는 것이 괜찮다고 언급하였는데, 이처럼 Shared 프로젝트에 Application/UI 로직을 제외한 코드를 넣고, 타 프로젝트와 함께 사용하거나 이미 만들어져 있는 PCL만 참조로 추가하여 개발하는 방식이 포팅하기에는 편리해 보인다.
Shared 프로젝트의 흥미로운 점은 현재 실행되는 부모 프로젝트의 레퍼런스를 따라가기 때문에 FlickrSearch.Android 프로젝트의 레퍼런스에만 PCL을 추가해 주면 된다는 점이다. Universal Windows App에서는 PCL 추가 없이 System.Net.Http를 사용할 수 있다.
FlickrSearch.Android 프로젝트에서 PCL을 이용한 FlickrSearch 클래스로 Flickr 데이터를 잘 가져오는지 테스트해봤다. 
일단 앱이 단순해서 필요한 코드는 쉽게 이식할 수 있었는데, 사실 좀 더 복잡한 프로젝트라고 하면 상당히 많은 코드에서 대체 라이브러리를 찾거나 직접 구현하는데 시간을 들여야 할 듯 싶다. Application/UI Layer는 완전히 새로 만들어야 하기 때문에 앱에 따라서는 이 부분도 상당한 시간이 걸릴 수 있다.
다음 글에서 Android의 GridView를 이용해서 이 데이터를 사용하여 UI를 구성하는 부분을 좀 더 살펴보도록 하겠다.
개밥 먹는 블로그 