[翻譯] iOS開發工具的介紹（第一部分）

標籤：android   des   style   blog   class   code   

IOS DEVELOPMENT TIPS & TRICKS - PART I

http://blog.trifork.com/2013/12/19/ios-development-tips-tricks-part-i/

 

As you might know, I am very fond of developing apps for the iOS platform. I started back in mid-2009 by trying to create an app for the Dutch Lowlands festival but I unfortunately failed to make the app a reality. I didn‘t care because now I learned how to write iPhone apps!

也許你知道了，我非常喜歡在iOS平台上開發軟體。早在2009年中期的時候我就嘗開發一款APP，但很不幸，最終沒能讓那款APP與大家見面。當然咯我不在意的，畢竟那是我的處女試水作，我從裡面學到了如何開發一款APP。

 

 

After that I never stopped trying out new app ideas in my spare time and occasionally blogging about it. In 2010, I created an app to use to communicate with friends using our custom forum-like website which was called ‘Yert‘.

之後我在業餘時間從來沒有放棄去開發新的APP。在2010年，我開發了一款APP，很像論壇一樣能讓朋友間彼此通訊，這款APP名字叫‘Yert‘。

 

And later, March 2011, I created an app in my spare time together with my uncle (Jos Jong) and brother (Jim van Zummeren) which turned out to be quite profitable:Easy Calendar. I learned the most creating this app. I also developed some iOS apps for clients of Trifork, for example I made the love to load app for The New Motion and an app that allows doctors to log their hours for GeriMedica:Ysis Mobiel.

之後，在2011年，利用空閑時間我和我的叔叔、大哥開發了一款日曆的軟體。這回我真正的學到了如何開發一款APP了。之後我開發了一些用戶端APP。

 

Oh, and I almost forgot: Learn to write with Tracy! An iPad app that makes learning how to write for children more fun and thus effective.

差點忘了另外一款應用。一款iPad的APP，一款教小孩畫畫的應用。

 

Next to the apps that made it into the App Store, I worked on a bunch of other ideas in my spare time that unfortunately never saw the light of day. But I learned from them every time. I want to share some tips & tricks with you all, which I learned over time. I want to talk about what tools I use nowadays, what frameworks I recommend and the different ways of distributing an app.

其實除了APP商店上線的那些應用，平時我還開發了一大堆的半成品沒能上線。但是呢，我從裡面學到了好多好多。我想和你分享一些心得和建議。我會向你介紹我平時使用什麼工具，給你推薦好的架構，以及不同的開發APP的工具。

 

 

 

IDE: AppCode

First off, I want to talk about AppCode, which I think is the best IDE for the job. I talked about it in great detail in a blog I wrote earlier: AppCode: IntelliJ for Objective C!. After using it for over two years I still think it is the best IDE for creating iOS apps. Xcode (the IDE that comes bundled with the iOS SDK) has become better and better since I wrote that blog, but still AppCode triumphs. It is hard to say why it is better in one sentence, so I recommend reading the AppCode blog I wrote. But if you know IntelliJ you know what I am talking about. The way IntelliJ is better than Eclipse, the same way AppCode is better than Xcode.

首先我想講講AppCode，我認為是最好的開發APP的IDE工具。在之前的博文中我詳細講到了它。我用它做了兩年的開發。不過呢，Xcode變得越來越好用，但我還是偶爾會用它。很難用一句話說明它好的地方，所以我建議你閱讀下我我之前發的博文。如果你知道什麼是IntelliJ，你就知道它比Eclipse好，AppCode好的地方就像IntelliJ與Eclipse的差別一樣。

AppCode is not a full replacement of Xcode, which actually is an advantage! It opens Xcode project files and saves them back as Xcode project files. This makes it possible to still switch back to Xcode at any time. So there is no risk involved trying to use AppCode. For example AppCode doesn‘t have the Storyboard interface designer. You can simply switch back any time you need to create a storyboard, and continue writing code using AppCode. Also, whenever there is a big change in Xcode, for example new language features, it generally only takes AppCode a couple of weeks to catch up in the form of an update.

AppCode並不能替代Xcode，它開啟Xocde的工程，儲存為Xocde的工程，與Xocde相容，使用AppCode並不會出現問題哦。但差別在什麼地方呢？比如，AppCode沒有IB設計介面。你可以在Xocde中建立後再在AppCode中使用。每次Xcode出現了新的特性，幾周之後AppCode就會出更新補上缺失的功能。

 

 

 

Dependency management: CocoaPods

Next up is dependency management. Admittedly, with iOS you don‘t need as much dependencies as you do when developing Java applications. Most of the stuff you‘re going to need is already included in the iOS SDK. But for the dependencies you DO need,CocoaPods is your friend! It‘s a popular dependency management tool for iOS (and Mac).

下一個是依賴管理器了。做iOS開發，其實你並不需要設定各種依賴（不像java那麼噁心）。大部分的依賴都被整合在iOS的SDK當中。但你還是需要它，CocoaPods。它在iOS（以及Mac）上最流行哦。

 

The way it works is really easy. Simply install it on your Mac with the following Terminal command:

它非常的簡單易用，一句話安裝哦：

1	sudo gem install cocoapods

 

After it‘s installed you can go to your Xcode project directory and create a file namedPodFile:

安裝完之後，你可以到你的Xcode項目目錄中建立一個檔案，名字叫 PodFile：

1	platform :ios, "6.0"

2	pod ‘AFNetworking‘, ‘2.0.2‘

 

This file tells CocoaPods that you want the dependency called "AFNetworking" and that your project requires iOS 6.0. This way if a dependency requires a later version of iOS than your project‘s minimum iOS version, CocoaPods will tell you.

這個檔案是為了告訴COcoaPods你需要一個依賴叫‘AFNetworking’，你的工程編譯的最低目標為iOS6.0。如果一個依賴需要一個更新版本的iOS，它會告訴你的呢。

 

Now run this simple command that will fetch the dependency and attach it to your Xcode project.

現在，你可以運行下面這條命令來自動擷取依賴與你的Xcode綁定。

1	pod install

 

Next to your current MyCoolProject.xcodeproj file, CocoaPods created a workspace file, called MyCoolProject.xcworkspace. From now on you need to open the workspace instead of the project file, which includes your project as well as the CocoaPods dependencies.

在你當前的檔案旁邊出現了一個CocoaPods建立的工作空間檔案。從現在其，你只需要開啟那個工作空間檔案，它既包含了你的工程檔案，也包含了CocoaPods的依賴檔案。

 

Can this get any easier?

The answer is yes! AppCode recently added support for CocoaPods! AppCode helps you create the PodFile using autocompletion and you don‘t have to go to the Terminal anymore to install the dependencies! (a.k.a "pods")

能更簡單些嗎？那是必然的，AppCode最近添加了對CocoaPods的支援！AppCode協助你建立PodFile，你無需用命令列搗鼓了。

Where do the pods come from?

All pods are stored inside a single Github repository: https://github.com/CocoaPods/Specs. Fork this repository and submit a pull request if you want to add your own pod! I did it a few times myself and the pull requests are usually accepted within a day, most of the time even within a couple of hours.

想使用CocoaPods，到Github上找吧，很easy的。

 

 

 

Continuous integration

If you‘re a Java developer you‘re probably already usingJenkins for continuous integration. Did you know you can also use Jenkins for Xcode projects?

如果你是Java開發人員，你也許用過Jenkins。但你知道麼，這貨也能支援Xcode的工程。

 

Simply install the iOS Builder plugin into Jenkins. (download the ".hpi" plugin file here) Jenkins of course has to run on a Mac server.

你只需要簡單安裝IB到Jenkins當中，當然，這個Jenkins是跑在蘋果的裝置上的。

 

Features:

• CocoaPods support (woohoo!)
• Code signing
• Packaging
• Easy configuration

 

Alternatives continuous integration systems you could take a look at:

• Xcode continuous integration. I tried this one as well. It is very easy to setup but I found it to be a bit limiting. But it is the Apple supported way to do continuous integration, so it is worth a try!
• Travis CI, which is an online continuous integration solution which integrates well with your Github repository, and it supports Cocoapods! I haven‘t tried this one yet.

 

 

 

Distribution

While developing an iOS app, you might want to involve testers or just random people you want to show off the app to. As you might know, Apple provides an alternative to distributing your app to the App Store which is made specifically for this purpose. It is called "AD-HOC" distribution. This is basically a way to sign your app against up to 100 devices and make it available to those devices via a URL. You could simply set up an Apache server somewhere and upload the required HTML and IPA (app binary) to it and send people the link to the HTML page. But you will soon find out this is a drag to do each time you want to deploy a new version.

開發APP的時候，你需要測試人員測試。蘋果開發需要從APP商店擷取開發認證，叫做AD-HOC。這是用來讓你給100台裝置授權的。也許，你搭建出簡單的阿帕奇伺服器，上傳你的IPA包以及裝置的授權資訊，發給需要測試的人。但很快，你會發現你要開發一個新版本的應用時就很操蛋了。

 

Also, your testers might encounter crashes and you would really like to see the crash reports (stack traces) to debug the issue. If you want to do this without any help, you will need to ask the tester to connect his iPhone/iPad to iTunes, retrieve the crash reports and send them to you. This is far from ideal. And what if you receive the crash reports from the testers? With iOS you won‘t be able to decipher them unless you saved the "dSYM" file that was produced when you built the AD-HOC binary. Oops, you threw it away!

可能，你的測試人員測試時崩潰了，你想查看崩潰的原因，如果你不藉助外部工具，你就需要讓這個測試人員將它的iPhone或者iPad串連到iTunes，找回他們的崩潰報告並發送給你。很噁心吧。你想重現？你還需要dSYM檔案呢。

 

So to sum up you need some kind of mechanism to make it easy to:

• Distribute your app to testers and other interested people
• Gather crash reports
• Automatically save dSYM files

 

TestFlight 測試載入器我們基本上用不上，就不翻譯了

Well, luckily there are services available online to help you with these things, and more! The first one I ever used wasTestFlight

• Supports iOS & Android
• Divide testers into groups using "teams". For example a different team for each app
• Provides a desktop client that makes it easy to upload your IPA and dSYM files
• Has an SDK to automatically upload crash reports and to do analytics
• Has a mechanism to let testers provide feedback from within the app
• It is free!

After using it for a while I found it has a few shortcomings: the crash reporting functionality is unreliable, I hardly find any crash reports in the backend while I know there are many more. Also the TestFlight website can be kind of confusing, and it is a hassle to sign up new testers.

 

HockeyApp 測試載入器我們基本上用不上，就不翻譯了

Nowadays I use a different service called HockeyApp. A strange name, but especially for distribution and crash reporting it works way better and easier. This is why I like HockeyApp in favour of TestFlight:

• Has (as far as I know) all the features TestFlight has
• It actually saves every crash that occurs
• It asks the user wether to send the crash report or not
• It groups the crash reports to easily see the different kinds of crashes, and how often they occur
• Unfortunately it is not free, but also it is not very expensive ($5 a month for 5 apps)

I definitely recommend HockeyApp.

 

 

 

To be continued

In this blog I showed you what I think are currently the best tools to use for developing iOS apps. In the next blog I will go more into the actual code by highlighting the frameworks I recommend. I know it‘s a cliche to say, but: stay tuned!

這篇博文中，我向你介紹了當前最好用的工具，下篇博文當中，我會介紹讓架構高亮的工具。雖然陳詞濫調，但也敬請期待。