Chapter 1. How does Xamarin.Forms fit in? Part.1

프로그래밍은 굉장히 즐겁습니다. 문제를 분석하고, 해법을 찾고, 여러 다른 시각으로 접근해서 코드를 생산해내는 것은 큰 즐거움입니다. 처음으로 프로그램을 돌려보고 성능 개선을 위해 매진하는 것 또한 즐겁습니다.

버그를 잡는 것 또한 이따금 즐거울 수 있고, 여러분의 코드가 최선의 방식이 아님을 깨닫고 부분적 또는 전체적으로 재작성 하는 것 또한 즐거울 수 있습니다.

그러나, 모든 것이 다 그렇게 즐거운 것은 아닙니다. 가장 하기 싫은 것 중 하나는 이미 잘 작동하는 프로그램을 다른 OS에 맞게, 완전히 새로운 프로그래밍 인터페이스(API)를 가지고서 재작성하는 일일 것입니다.

그런 일은 매우 고된 단순 노동이지만 꼭 필요한 일일 수 있습니다. 가령 아이폰에서 이미 유명한 앱이 안드로이드에서는 훨씬 더 유명해질수도 있는데, 그걸 알아낼 수 있는 건 직접 만들어 올리는 수밖에 없습니다.

그러나 문제가 있습니다.

다른 시스템에 맞게 재작성하는 과정에서, 기존 프로그램의 구조를 그대로 똑같이 유지하겠습니까, 아니면 뭔가 개선시키겠습니까? 물론 구조적 개선을 그 참에 이루어 내는게 매력적일 수 있습니다. 그러나, 그 과정에서 원래 버전과 크게 다른 점이 생겨버린다면 장차의 유지보수 과정은 점점 더 힘들어질 것입니다.

이건 완전히 새로운 두려움은 아닙니다. 지난 반세기 동안 개발자들은 하나의 프로그램을 여러개의 하드웨어에서 돌아가도록 작성하는 능력을 갈망해 왔습니다. 이게 애초에 high-level 언어가 생겨나게된 이유이고, "cross-platform" 개발컨셉을 개발자들이 지지해온 이유입니다.

Cross-platform mobile development

개인용 컴퓨터 산업은 지난 몇년간 큰 패러다임의 변화를 겪었습니다. 데스크탑 컴퓨터는 여전히 키보드와 큰 모니터를 가지고 작업해야 하는 프로그래밍, 스프레드 쉬트 등의 영역에서 우세합니다. 그러나 더 많은 개인용 컴퓨팅은 작은 기기로 이루어집니다. SNS나 정보검색, 미디어 보기 등이 그것입니다. 태블릿과 스마트폰은 터치로 조작하는 것이 우선이라는 점에서 기본적으로 다른 user interface 패러다임을 가집니다.

The mobile landscape

격변해온 모바일 시장에서도 이제는 두 개의 큰 플랫폼이 있습니다.

• Apple family(iPhone, iPad, 기타 iOS기기)
• Android OS(리눅스 커널을 기반으로 구글이 개발)

현재 더 많은 안드로이드 기반 기기들이 시중에 존재하는 한편 아이폰 유저들은 좀더 아이폰에 헌신적이고 더 많은 시간을 아이폰 기기에 사용합니다.

안드로이드나 iOS만큼 유명하지는 않지만 컴퓨팅의 역사에서 더 오랜 기간 명성을 떨쳐온 플랫폼이 하나 더 있습니다.

• Microsoft Windows Phone, Windows 10 Mobile

지난 몇년간 Microsoft는 모바일, 데스크탑, 태블릿의 API를 통합하고자 했습니다. 그 결과 Windows 8.1에서는 .NET 기술을 기반으로 WinRT(Windows Runtime)로 통합을 이뤄냈고, 현재는 UWP(Universal Windows Platform)이라는 기술로 발전했습니다. 그 결과 데스크탑에서 폰에 이르기까지 단일 UWP Application으로 커버할수 있게 되었습니다.

소프트웨어 개발자들은 이 플랫폼들 중 하나 이상을 타겟으로 하여 최적의 전략을 만들어야 했는데 쉽지가 않았습닏. 거기엔 4개의 장애물이 있었습니다.

문제1: 상이한 UI 패러다임

세 개의 플랫폼은 얼핏 유사한 UI를 가지고서 멀티터치에 반응하는 듯 하지만 실제로는 미세한 차이점이 있습니다.

앱이나 페이지를 넘나들 때 navigate하는 원리가 다르고, 데이터를 보여주는 방식이 다르고, 메뉴를 일으키고 보여주는 방식도 다르며, 터치를 처리하는 방식또한 다릅니다.

사용자들은 각각의 플랫폼마다 반응하는 방식이나 지식이 다르고, 각각의 문화를 가지고 있습니다. 그리고 그러한 플랫폼의 문화 차이는 개발자에게도 영향을 줍니다.

문제2: 상이한 개발 환경

오늘날 프로그래머들은 각각 친숙한 IDE(통합개발환경)을 가지고 있습니다. 위의 세 플랫폼도 각각 서로 다른 IDE를 가지고 있습니다.

• IOS: Mac에서 실행되는 Xcode
• Android: 다양한 플랫폼에서 실행되는 Android Studio
• Windows: PC에서 실행되는 Visual Studio

문제3: 상이한 프로그래밍 인터페이스

세 개의 플랫폼은 각각의 OS와 그에 따른 API를 갖고 있습니다. 많은 경우에 유사한 종류의 user-interface 객체라 해도 그 이름이 다릅니다. 예를 들어 세 플랫폼 모두 유저가 Boolean값을 끄고 켜는 객체를 가지고 있는데

• 애플:   UISwitch라 불리는 "view"
• 안드로이드:   Switch라 불리는 "widget"
• 윈도우:    ToggleSwitch라 불리는 "control"

문제4: 상이한 프로그래밍 언어

언어에는 약간의 융통성이 있기는 하지만 기본적으로 주력으로 취급되는 것이 존재합니다.

• 애플: Objective-C
• 안드로이드: Java
• 윈도우즈: C#

세 언어가 크게보면 C로부터 유래한 객체향의 사촌격이지만, 아주 먼 사촌입니다.

그런 이유로 앱을 개발하려는 회사는 각각의 언어에 특화된 세개의 팀을 꾸려야 했습니다.

이 언어 문제의 해결은 굉장히 매력적인 주제입니다. 만약 단일한 언어를 사용할 수 있다면 세 개의 플랫폼 간에 코드를 공유할 수가 있고, UI와 관련된 곳은 각각의 API가 있으므로 통일하기 어렵겠지만 UI와 전혀 관계없는 부분은 문제없이 작동할 것입니다.

그러나 어떤 언어가 그 역할을 할 수 있겠습니까?

The C# and .NET Solution

많은 사람들이 다양한 해법을 제시했습니다만, C#이 좋은 답변을 제시했습니다. C#은 2000년에 Microsoft에 의해 발표되었고, Objective-C나 Java에 비해 매우 최신의 언어입니다. C#은 C++나 Java에 영향을 받은 강타입의 엄격한 객체지향 언어로 평가받았습니다만, 추가로 언어 차원에서 프로퍼티, 이벤트를 지원하고 있었는데 그점이 GUI 프로그래밍에 매우 적절한 멤버로 판명되었습니다.

차차 언어가 발전해 나가면서 generic, 람다, LINQ, 비동기 작업이 추가되면서 다목적의 범용 언어로 변모했습니다.

C#은 .NET 프레임웍과 밀접한 관계입니다. 가장 기본적으로 .NET은 C#에 기본 타입(int, double, string 등)을 제공하고, 크게는 방대한 class library들을 제공합니다.

에를 들면  Math, Debugging, Reflection, Collections, Globalization, File I/O, Networking, Security, Threading, Web services, Data Handling, XML과 JSON 읽고쓰기 같은 것 말입니다.

마이크로소프트가 .NET을 발표한 2000년 바로 직후에 Ximian이라는 회사가 Linux에서 C#과 .NET을 돌리기 위해 "Mono"라는 이름의 오픈소스 프로젝트를 시작했습니다.

10년 후 2011년에 Ximian은 Xamarin을 설립하고 이번에는 모바일까지 통합하기 위한 Mono를 개발합니다.

2014년에는 오픈 소스 버전의 C# 컴파일러인 .NET Compiler Platform(이전에는 Roslyn이라 불렸음)이 발표되었고, .NET Foundation은 Xamarin이 주도적 역할을 하던 오픈소스 .NET 기술에 함께 참여하기로 합니다.

2016년 3월에 마이크로 소프트는 자마린을 인수하였고, 뜻을 같이 하여 이제 Visual Studio의 사용자는 Xamarin.Forms를 무료로 이요할 수 있게 됩니다.

모든 플랫폼에 하나의 언어

자마린은 첫 3년 동안에 C# 컴파일러 기술과 세개의 .NET 라이브러리에 주력합니다.

Xamarin.Mac :   MonoMac 프로젝트에서 개발
Xamarin.Touch : MonoTouch 프로젝트에서 개발
Xamarin.Android : MonoDroid 프로젝트에서 개발

이 세개의 프로젝트를 합쳐 Xamarin플랫폼이라 칭합니다. 이 라이브러리는 각각의 native API로 작성되었고, 프로그래머는 C#으로 이 플랫폼을 사용할 수 있는데다가 보너스로 기존의 .NET 클래스 라이브러리가 사용가능합니다.

개발자들은 Visual Studio로 모든 플랫폼을 카겟으로 삼을 수 있습니다.
다만, 아이폰과 아이패드 개발자들은 네트워크로 연결된 Mac 컴퓨터가 추가로 필요합니다. 이 맥에는  자마린 스튜디오와 Xcode가 설치되어 있어야 하며, 맥에서 자마린 스튜디오로 작업할 때는 윈도우 플랫폼은 타겟으로 할수가 없습니다.

Sharing Code

단일 언어로 여러개의 플랫폼을 다루는 가장 큰 장점은 app 간에 코드를 공유할 수 잇다는 점입니다.

코드가 공유될 수 있게 하기 위해서는 먼저 그런 목적으로 app이 설계되어야 합니다. GUI가 널리 사용되면서 프로그래머들은 functional 레이어로 코드를 나누는 것이 좋다는 점을 알게 되었는데 그것이 그 유명한 MVC(Model-View-Contoller) 모델입니다. 이 모델은 코드를 세개의 부분으로 나누는데, 그것은 데이터를 다루는 Model, 데이터를 보여주는 View, 유저의 입력을 다루는 Controller입니다.

MVC는 1980년대에 태어났고, 최근에는 현대 GUI에 맞게 MVVM(Model-View-ViewModel)로 발전했습니다.  Model은 역시 배후의 데이터를 다루는 부분이고, View는 시각적 부분과 입력을 포함한 user-interface를 다루며, ViewModel은 Model과 View간에 데이터를 주고받는 것을 다룹니다.

프로그래머가 다수의 플랫폼에서 작동하는 앱을 동시에 개발하고자 하면, MVVM 구조가 도움이 됩니다. Model과 ViewModel은 플랫폼과 무관하게 독립적인 부분이며, View는 플랫폼에 종속된 API에 의존하는 부분입니다.

독립적인 부분에서 파일에 접근하거나 컬렉션 사용, 쓰레딩 등이 필요할 때 닷넷 프레임워크를 사용할 수가 있습니다.

이 플랫폼 독립적인 부분을 따로 떼어서 분리된 프로젝트로 관리할 수가 있는데 그것은 SAP일수도 있고 PCL일 수도 있습니다.

SAP(Shared Asset Project)는 다른 프로젝트에서 접근 가능한 코드와 asset 파일로 구성되고,PCL(Portable Class Library)는 다른 프로젝트에서 참조 가능한 dll(dynamic-link library)로 구성됩니다.

어떤 방법을 사용하건 그것은 .NET 프레임워크 클래스 라이브러리에 접근할 수 있고, 따라서 file I/O, globalization 등을 사용할 수 있게 해 줍니다.

그것은 각각의 플랫폼에 대응할 수 있는 4개의 C# 프로젝트로 구성된 단일한 Visual Studio 솔루션을 작성할 수 있게 된다는 것을 뜻합니다.

아래의 그림은 Visual Studio 프로젝트와 Xamarin 라이브러리, 플랫폼 API 간의 관계를 도식화한 것입니다.