首页 > 代码库 > [翻译] iOS开发工具的介绍(第一部分)

[翻译] iOS开发工具的介绍(第一部分)

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!

这篇博文中,我向你介绍了当前最好用的工具,下篇博文当中,我会介绍让框架高亮的工具。虽然陈词滥调,但也敬请期待。