[心得] 從Xamarin轉Swift

看板MacDev作者 (mize)時間7年前 (2017/05/25 21:27), 編輯推噓8(8017)
留言25則, 9人參與, 最新討論串1/1
前言: 今天突然心血來潮想寫看看自己對於Xamarin的心得,與轉換到純Swift的過程 如果是想進來看教學的可以直接上一頁了 XD 一、投入iOS開發 原本工作是處理政府相關的WebForm專案,因緣際會下在公司接到有iOS的開發專案,在被 老闆指定(強迫)下必須找解決方案開始做,當時的選擇方案有三個 1.Xamarin.iOS => 使用C#開發,又有.Net的強大支援 2.Cordova => 使用網頁語言開發 3.純原生 在思考後選擇了Xamarin.iOS做為開發平台,持續了約兩年,共開發兩個案子 一個為企業內部使用,另一個已上架 二、資源瓶頸 剛開始的時候因為完全沒有接觸過iOS Xamarin在當時中文的只有一個Blog有入門教學,而且真的只有入門Hello World而已 再搜尋國外相關的教學也相當的少,陷入了學習的瓶頸 於是這時候開始學會看OC的教學文章自己轉譯到C#上。 Xamarin的賣點之一可以使用強大的.Net第三方library 但是並不是每個都可以使用,必須要支援PCL .Net自己的則是99%以上都可以正常使用 而iOS原生自己數量龐大的第三方library則是99%都無法使用 iOS原生的library必須有人建立Xamarin的專案使用橋接發布,或是原作者自己另外寫一 套 綜上所述,Xamarin的library數量相當的少,許多功能必須自己手刻 很多時候找到iOS原生有的library但是卻沒辦法用相當痛苦阿! 三、轉Swift 因為原本的專案都進入維護期,又換公司需要開啟新專案,我就毅然決然放棄了Xamarin 投入原生開發 初期相當的不適應,要將原本Xamarin自己寫的library移植到Swift 許多.Net中的糖糖在Swift通通沒了,要不斷的尋找替代方案或是手刻 但是這痛苦的期間也只維持了大約半個月 Xamarin.iOS與原生開發最大的差別在IDE、語言、第三方library,而iOS的開發知識則是 原封不動 例如StoryBoard、Xib、各種View使用方式等等... 藉著原本在Xamarin上學會的相關知識,克服了語言差距順利的開始了純原生的開發 到目前專案已經進行了半年多,深刻覺得原生擁有的資源真的是最多的。 結語: 1.如果你是沒有任何程式經驗想投入iOS開發 建議不要繞遠路直接走原生開發,我推薦 Swift :) 2.如果你是原生的iOS開發者,為了想要使用Xamrin來達成一次開發多平台 你要使用的應該是Xamarin.Forms,這一套特別為了多平台做了相容性開發 但是這種方式或許必須犧牲原生特效、功能, 對於Forms我只有初步使用就覺得難用放棄沒有更深入了解 按照現在趨勢,或許你使用React Native是比較好的方式? 3.如果你是C#的開發者,為了不想換語言所以想選Xamarin 或許在初期一切都是那麼的熟悉,但是一旦碰到App的開發知識就是一片白紙得從頭學 想要針對Xamarin找資源又異常的困難,到最後還是得去翻原生的資源自己轉譯 你原本在C#中不管是WinForm還是WebForm、MVC.Net的知識,在APP開發中九成以上派不上 用場我在開發中最有用的知識只有.Net的多執行續處理 雖然這套在進入Swift後就完全廢掉了 現在Swift對於C#開發者而言已經相當親和,已經不像學習OC那麼的痛苦了 如果這樣還是沒改變你的想法,只能祝福你了:) QA: Q:Xamarin要付費嗎? A:我那個時候Xamarin尚未被M$收購,收費最低就是一年999美金,另外有免費的學生授權 目前微軟有Community版可以直接免費使用,但是要注意條款限制 而如果原本有VS授權的則會直接擁有同級別的Xamarin授權 Q:Xamarin使用的人數多嗎? A:從104上找職缺的話,全台灣或許還沒超過10家公司有在使用 Q:Xamarin.iOS開發的App可以順利上架嗎? A:完全沒有問題! Q:Xamarin需要的IDE與環境 A:Xamarin可以直接掛在Visual Studio上使用,但是開發iOS還是必須要有一台mac當Host 來編譯,推薦直接使用Xamarin Studio在mac上直接編寫 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.26.236.52 ※ 文章網址: https://www.ptt.cc/bbs/MacDev/M.1495718860.A.F5F.html

05/25 22:49, , 1F
感謝分享
05/25 22:49, 1F

05/26 00:38, , 2F
感謝心得分享
05/26 00:38, 2F

05/26 07:03, , 3F
還好一開始就用OC去寫
05/26 07:03, 3F

05/26 13:37, , 4F
在 ios 上,不是寫swift,oc的方式我覺的是推不起來的
05/26 13:37, 4F

05/26 15:27, , 5F
最近還在想說要不要玩看看...還是放棄好了
05/26 15:27, 5F

05/27 22:00, , 6F
很多用這個都是有核心技術 C/C++ library 要共用雙平台
05/27 22:00, 6F

05/27 22:01, , 7F
UI相對來說不是重點就會用這個,因為技術核心不是在視覺
05/27 22:01, 7F

05/28 17:25, , 8F
核心技術是C/C++ Lib的,除非那個核心技術牽涉到UI,不
05/28 17:25, 8F

05/28 17:25, , 9F
然個人覺得還是直接用OC/Swift去串就好。目前知道核心
05/28 17:25, 9F

05/28 17:26, , 10F
Lib跟UI有關的,大概只有遊戲跟導航兩種
05/28 17:26, 10F

05/28 17:37, , 11F
核心在 C/C++ 在 iOS 沒問題, 但 Android 就很麻煩
05/28 17:37, 11F

05/28 17:38, , 12F
所以我是可以理解啦, 如果 Android 要用 NDK 那乾脆就用
05/28 17:38, 12F

05/28 17:38, , 13F
這類工具也不失是合理考量
05/28 17:38, 13F

05/28 17:39, , 14F
Android要用C/C++ Lib很麻煩嗎?這點我倒是不清楚,不
05/28 17:39, 14F

05/28 17:39, , 15F
過聽說Spotify就是這樣搞的,各平台的client基本是都只
05/28 17:39, 15F

05/28 17:40, , 16F
是個小介面,底下全部是共通的lib
05/28 17:40, 16F

03/06 20:25, , 17F
不會啊..有寫過wpf超好轉的,尤其用mvvm的架構
03/06 20:25, 17F

03/06 20:28, , 18F
很適合用在大型專案上..其他的技巧像是linq,orm,di
03/06 20:28, 18F

03/06 20:28, , 19F
完全都是承襲以前經驗
03/06 20:28, 19F

03/06 20:29, , 20F
至於ios機制上的知識,的確這是要從原生語言去補沒錯
03/06 20:29, 20F

03/06 20:30, , 21F
以及原生資源的不足都是跨平台工具的缺點
03/06 20:30, 21F

03/06 20:32, , 22F
viewModel拉出來除了可以在其他專案共用邏輯之外
03/06 20:32, 22F

03/06 20:32, , 23F
也可以用在單元測試上
03/06 20:32, 23F

03/06 20:33, , 24F
個人是覺得很方便,若遇到原生語言的東西就去k官網
03/06 20:33, 24F

03/06 20:35, , 25F
如果沒套件就自己寫啊,整個類別都被搬到c#了
03/06 20:35, 25F
文章代碼(AID): #1P9jlCzV (MacDev)