Xamarin

960px

에뮬레이터 5종세트

960px

1석5조

1 Xamarin (자마린)

C\#과 .NET Framework 을 리눅스에서도 쓸 수 있게 해주는 Mono 프로젝트에서 시작되었다

마침 리눅스가 안드로이드라는 이름으로 세계를 지배하고 윈도우폰이 죽을 쓰자 세련된 .NET Framework 와 강력한 C\# 으로 안드로이드와 아이폰을 개발하고자 하는 수요가 자마린을 성장시켰다

안드로이드와 iOS 의 모든 API 가 번역되어있기 때문에 네이티브앱 개발이 가능하다. iOS 에서의 최적화는 놀라울 정도이며 안드로이드의 최적화도 계속 진행되고 있다

One Source Multi OS 개발이 가능하기에 해외에선 "앱개발의 미래" 라고 불리우고 있으며 마침 구글은 JAVA 를 버린다고 선언했고 애플은 Objective-C 를 버리고 Swift 로 가는데 버전 1 2 3 이 크게 달라서 앱개발환경은 큰 변화를 맞이하고 있다

한번 작성한 폼과 로직이 안드로이드와 아이폰에서 똑같이 작동하고 동시에 유지보수가 가능하기에
게임계의 Unity 처럼 앱개발의 Game Changer 가 될 거라 기대하고 있다

Visual Studio 로 윈도우와 Mac 에서 iOS Android 에뮬을 띄울 수 있다

Mono 를 주도해온 낫 프리드만(CEO)과 미구엘 데 이카사(CTO)가 설립하였으며 2016년 2월 24일 마이크로소프트가 인수 2016년 3월 31일 무료화되고 소스를 공개하였다 공식홈페이지 오픈소스

국내 커뮤니티
네이버 카페
페이스북 공개그룹

2 Xamarin.Android

Mono for Android 에서 개명되었다 안드로이드의 모든 API 를 C# 스타일의 API 로 번역 내부구현하였다

3 Xamarin.iOS

MonoTouch 에서 개명되었다 iOS의 모든 API 를 C# 스타일의 API 로 번역 내부구현하였다

4 Xamarin.Mac

해외에선 이를 이용한 유료앱도 출시되어있다

5 Xamarin.Forms

2014 년 뒤늦게 출시된 Xamarin.Forms 는 출시되자마자 개발자들의 엄청난 호응을 얻었으며 진정한 Cross-Platform 개발이 이루어졌다 MS 의 WPF 를 기반으로 제작되어 유사한 면이 많다

new Label() 하면 Android iOS WindowsPhone UWP MacOS Tizen 으로 모두 번역해준다 다양한 nuget 패키지들과 함께 이용하면 90% 이상의 코드를 공유할 수 있으며 10%이하의 OS 별 코드를 작성하여 여러 OS 용 네이티브 앱 개발이 가능하다

WPF 와 마찬가지로 Code 스타일과 Xaml (재믈) 스타일이 있다 장단점이 있으며 개발환경/취향에 따라 선택하면 된다

Xamarin.Forms로 만든 allb 앱 iOS/Android 양 플랫폼 앱 동시출시 경험기

그러나, 위의 이야기는 양쪽 플랫폼을 자유롭게 다룰 인력이 없는 개발사에 해당하고, iOS/Android 개발 인력과 기획자가 갖춰져있는 팀의 경우 아직까지는 기존의 네이티브로 하는 것이 빠를 수 있다. 게임의 경우 기존 네이티브에서 제공되는 UI를 사용하는 경우가 거의 없고, 아예 해당 게임에 맞는 UI 를 바닥부터 개발하는것이 대부분이기에 유니티 같은 Cross-Platform 개발이 유리하지만, 게임 외의 앱들은 네이티브에서 제공하는 UI를 사용해야 하기에 오히려 작업이 늘어나는 경우도 있다.

예를들어, 버튼 하나에 이미지를 입히는 작업만 보더라도, 이벤트 처리 코드는 공유하지만 이벤트 처리는 대부분 서버연동이나 페이지 전환이기 때문에 애초에 몇 줄 절약되지도 않으며, 반면에 안드로이드의 해당 버튼을 포함하고 있는 페이지의 layout 파일 작업, 해당 버튼의 상태별 이미지를 보여줄 selector 파일 작업, iOS 의 해당 버튼의 상태별 이미지 제어 코드작업을 해야하는데, 이렇게 작업하고도 기존의 네이티브 UI의 세부적인 설정을 100% 구현하지 못하는 부분들이 있으며, 버튼 하나 하나 마다 이렇게 C# style, Android style, iOS style 을 왔다갔다 하면서 작업해야한다.

그리고 네이티브 SDK의 기본이라 할 수 있는 WYSIWYG 방식의 개발도 사실상 불가능하다. Xaml Viewr 가 있지만 필자가 고장난거라고 확신하고 있었을 정도로 느리다. 거의 iOS 시뮬레이터를 부팅시키는 수준... 그래도 명목상 되기는 되는거라고 광고하겠지

뿐만아니라, 앱의 크기에 있어서도 기존의 네이티브로 만들면 몇 KB로 끝나는 HelloWorld 정도만 구현해도 소중한 iPhone 용량을 60MB 나 차지해버리며, 프로젝트를 완성하면 수백MB 를 차지하는데... 기존 방식으로는 몇십MB 로 끝날 내용이다. 결국 게임도 아닌 앱이 게임처럼 메모리 문제로 다운되는 답없는 상황으로 이어지기 쉽다.그런건 포켓몬고로 충분해

결정적으로 레퍼런스가 너무나도 부족하다. 당장 '버튼 이미지 세팅하고 크기 바꾸는 법'을 찾아보면 깨닫게 된다. 국내 도서는 전무하며, 공식 홈페이지 자료는 애플이나 구글의 공식 자료에 비해 너무나도 부실하기에 구글같은 수준의 레퍼런스를 기대하고 개발하다간... stackoverflow.com 에 조차도 제대로 된 설명이 없어서, 오류가 하나 생길 때 마다 Xamarin 개발진과 영어로 소통을 해가며 개발하는 개척자의 기분을 느낄 수 있으므로 회사의 프로젝트에 도입을 하기 전에 충분한 연구가 필요하다.책이 한두개 나오고 최적화가 어느정도 될 때까지 기다리자

위 반론은 리모릭스 개발 이야기 와 상통하는 이야기로 Xamarin.Android 와 Xamarin.iOS 를 사용하여 5만건이상의 (2017.2 기준) 다운로드를 기록한 성공적인 앱을 만든 노하우와 시행착오가 들어있는 글이다. 하지만 Xamarin.Forms 를 적극 도입하지 않았기에 자마린의 장점을 극대화했다고 할수없다.(개발시작시점에 XF가 없었던것으로 보임) 또한 기존 axml 과 storyboard 같은 UI 구성지식이 없어야 오히려 XF 를 적극 도입하게 되며 약간의 custom renderer 코드만 추가하면 못만들 UI 가 없다. new StackLayout().to 라고 치면 각종 애니메이션 관련 메소드들이 나오며 그밖에도 활용할 패키지와 API 가 무궁무진하다.

apk 와 ipa 의 기본용량은 10~20메가이며 곧 나올 XF 2.4 와 2.5 에서 안드로이드 관련 최적화가 더욱 이루어질 예정이다. google 에서 영문검색으로 자료를 찾으면 대부분의 문제들이 이미 논의되어있다.

참고 지난 4개월간 만든 메신저앱입니다 (xamarin.forms 이용)

6 Xamarin Test Cloud

앱 동작순서를 입력해놓으면 2000 여개의 실기기에서 자동으로 테스트해주고 로깅해준다 (유료)

7 Xamarin Insights

앱 내부에서 일어나는 크래시나 기타정보를 서버로 전달하여 로깅해준다 HockeyApp 과 통합됨