07 2月

使用Storyboard构建Navigation Controller和Table View

文 / Simon Ng:iOS程序员,Beginning iOS 9 Programming with Swift一书的作者,AppCoda.com创始人。

原文链接:http://www.appcoda.com/use-storyboards-to-build-navigation-controller-and-table-view/

到现在为止,如果一直跟着我们的教程学习,你应该有了对UITableView基本的了解。并且知道如何利用它构建简单的应用程序了。本周,我们要说说新东西,Storyboards。这是Xcode 4.2和iOS 5 SDK引入的最令人激动的功能特性之一。作为iOS开发人员,它使你的生活更简单,可以轻而易举地设计iOS应用程序的用户接口。

本文将向你展示如何使用Storyboards构建Navigation接口,并将它与UITableView集成起来。我们会尽力保持简单,集中精力解释概念。因此就没有好玩儿的界面和漂亮的图形。以后的文章会解决艺术性的问题。

好,我们开始吧!

什么是Navigation Controller?

我们开始编码前,像以往一样,我们对Navigation Controller和Storyboards做一个简单的介绍。

就像Table View,Navigation Controller是你在iOS应用程序中另一种最常见的UI元素。它提供了逐层向下的层次内容。看一看内置的Photos,YouTube 和Contacts应用,这些应用程序都使用了Navigation Controller来显示分层的内容。通常,大多数应用程序中的Table View和Navigation Controller是一起工作的。但这并不是说一定要两个一起使用。

Photos-App-Navigation-Controller

Storyboards概览

前面说过,Storyboard是Xcode 4.2以来引入的新功能特性。它为iOS开发者提供了创建和设计用户界面提供了全新的方式。对初学者来说,介绍Storyboard之前,创建导航界面和标签界面着实困难。每个界面都存储在单独的nib文件中。在这之上,还要编写代码讲所有的界面连接到一起,描述导航如何工作。

有了Storyboards,所有的界面都存储在一个文件中。这给了你一种应用程序可见的表现方式,向你展示了这些界面是如何连接在一起的。Xcode提供了内置的编辑器来编辑Storyboards的布局。通过简单的点击,你可以定义不同界面之间的转变(也就是所谓的segues)。这并不意味着不需要为用户界面编写代码。但Storyboards显著减少了编码量。下面的示例图片展示了Storyboards在Xcode中的样子。

Storyboards-Explained

Scene和Segues

使用Storyboards时,Scene和Segues是总出现的两条术语。在Storyboard中,scene指一个单独的视图控制器和它的视图。每一个scene都有一个dock,dock主要被用来在视图控制器和它的视图之间做action和outlet关联。

Segue位于两个scene之间,管理两个scene之间的转变(transition)。Push和Modal是转变的两种常见类型。

在Storyboards中创建Navigation Controller

我们现在动手创建Storyboards。在本文中,我们将构建一个使用UITableView和UINavigationController的简单示例应用。使用Table View显示菜谱。当用户选择任何一道菜时,应用程序就跳转到下一个页面显示细节。这不难的。

首先,启动Xcode(确保使用4.2版本以上),使用“Single View application”模版创建一个新的项目。

Choose-Xcode-Template

点击“Next”继续。把下图中Xcode项目中需要填写的内容补齐。确认勾选“Use Storyboards”选项。

RecipeCookbook-Xcode-Project

点击“Next”继续。Xcode会询问把“SimpleTable”存到哪里。选择任一文件夹(例如,桌面)保存你的项目。

你可能注意到了Xcode项目中细微的差别。与之前文章中的内容比较,.xib文件(interface builder)被MainStoryboard.storyboard文件代替了。

Empty-Storyboard-in-Xcode

默认情况下,Xcode创建一个标准的视图控制器。因为我们要使用Navigation Controller控制界面导航,首先要将view controller修改为navigation controller。直接选择“Editor”菜单,选择“Embed in”,然后选择“Navigation Controller”。

Storyboard-Embed-in-Navigation-Controller

Xcode会自动给RecipeBook View Controller嵌入Navigation Controller。界面看起来是这个样子的:

Storyboard-Added-with-Navigation-Controller

继续网下进行前,我们运行一下程序,看看是什么样子的。点击“Run”按钮,你应该能看到一个添加了导航条的空白视图。这表明已经成功地把RecipeBook View Controller嵌入到了Navigation Controller中了。

RecipeBookApp-Empty

为数据添加Table View

接下来,我们会添加Table View,显示菜谱。在对象库中选择“Table View”,拖拽到“Recipe Book View Controller”。

请注意,不能把这些对象拖拽到缩小了的编辑器中,如果无法把table view拖拽到view controller,放大后再试。

Storyboard-Add-Table-View

下一件要做的事情是编写代码表格数据(也就是菜谱)。在项目导航栏,选择“RecipeBookViewController.h”,在“UIViewController”后面添加协议参数。

#import <UIKit/UIKit.h>

@interface RecipeBookViewController : UIViewController <UITableViewDelegate, UITableViewDataSource>

@end

如果你读过Simple Table有关的文章,应该非常熟悉上面的代码。我就不在解释细节 了。如果理解起来有困难,查阅一下更早的文章

接下来,选择“RecipeBookViewController.m”,为保存表格数据定义实例变量(也就是菜单数组)。

@implementation RecipeBookViewController {

NSArray *recipes;

}

在“viewDidLoad”方法中,添加如下代码初始化“recipes”数组:

– (void)viewDidLoad

{

[super viewDidLoad];

//Initialize table data

recipes = [NSArray arrayWithObjects:@”Egg Benedict”, @”Mushroom Risotto”, @”Full         Breakfast”, @”Hamburger”, @”Ham and Egg Sandwich”, @”Creme Brelee”, @”White Chocolate Donut”, @”Starbucks Coffee”, @”Vegetable Curry”, @”Instant Noodle with Egg”, @”Noodle with BBQ Pork”, @”Japanese Noodle with Pork”, @”Green Tea”, @”Thai Shrimp Cake”, @”Angry Birds Cake”, @”Ham and Cheese Panini”, nil];

}

最后,我们必须实现两个数据源方法,来生成表格数据:

“tableView:numberOfRowsInSection”和“tableView:cellForRowAtIndexPath”方法。调用这两个方法是UITableViewDataSource协议的一部分。配置UITableVIew时,这两个方法是必须要实现的。第一个方法用来通知Table View区域内的行数,而第二个方法被用来填充表数据,因此我们添加如下代码。

作为参考,下面是整个“RecipeBookViewController.m”的源码。

//

//  RecipeBookViewController.m

//  RecipeBook

//

//  Created by Simon Ng on 14/6/12.

//  Copyright (c) 2012 Appcoda. All rights reserved.

//

#import “RecipeBookViewController.h”

@interface RecipeBookViewController ()

@end

@implementation RecipeBookViewController {

NSArray *recipes;

}

– (void)viewDidLoad

{

[super viewDidLoad];

// Initialize table data

recipes = [NSArray arrayWithObjects:@”Egg Benedict”, @”Mushroom Risotto”, @”Full Breakfast”, @”Hamburger”, @”Ham and Egg Sandwich”, @”Creme Brelee”, @”White Chocolate Donut”, @”Starbucks Coffee”, @”Vegetable Curry”, @”Instant Noodle with Egg”, @”Noodle with BBQ Pork”, @”Japanese Noodle with Pork”, @”Green Tea”, @”Thai Shrimp Cake”, @”Angry Birds Cake”, @”Ham and Cheese Panini”, nil];

}

– (void)viewDidUnload

{

[super viewDidUnload];

// Release any retained subviews of the main view.

}

– (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation

{

return (interfaceOrientation != UIInterfaceOrientationPortraitUpsideDown);

}

– (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

{

return [recipes count];

}

– (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

{

static NSString *simpleTableIdentifier = @”RecipeCell”;

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:simpleTableIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault     reuseIdentifier:simpleTableIdentifier];

}

cell.textLabel.text = [recipes objectAtIndex:indexPath.row];

return cell;

}

@end

最后,我们建立Table View和刚刚创建的这两个方法之间的连接。返回Storyboard。按住Control键,选择“Table View”,拖拽到View Controller的图标。看起来是这个样子的:

Storyboard-TableView-Datasource

松开按钮,弹出了“dataSource”和“delegate”,选择“dataSource”,在Table View和它的数据源之间建立连接。重复上述步骤,在Table View和代理之间建立连接。

Storyboard-TableView-Connect-Datasource

测试应用程序之前,最后一件事是给导航栏添加标题。直接选择“Recipe Book View Controller”的导航栏,填写“Attributes Inspector”下的“Title”。记住,填写完成后点击ENTER,修改生效。

Storyboard-Add-Navigation-Bar-Title

可以运行代码了。点击Run按钮,测试应用程序。如果代码正确,你应该得到一个显示菜谱列表的应用程序。这个应用和之前我们构建的SimpleTable应用非常相似。这里最主要的区别就是嵌入了Navigation Controller。

Storyboard-Navigation-Bar-Title

Prototype Cell简介

还记得如何自定义表格吗?几周前,我们向你展示了如何使用Interface Builder设计自定义的表格。简要地说,你需要为表格单独创建一个nib文件,并用编程的方法将它加载到表呢。介绍了Storyboard中的Prototype Cell以后,创建自定义表格就更简单了。ProtoType Cell可以让你在Storyboard编辑器中轻松设计好表格的布局。

我们不会在本文深入谈论自定义的细节,而仅仅是在表格中添加“Disclosure Indicator”。

选择Table View,添加Prototype Cell。在“Attributes Inspector”下,把“Prototype Cells”的值从“0”改到“1”。修改完成后,Xcode立刻自动显示prototype cell。我们也把“Style”选项从“Plain”改成“Group”,显示另一个表格风格。

Storyboard-Prototype-Cell

接下来,选择“Prototype Cell”,你应该能够为表格定制风格了。为了让每个表格显示一个提示箭头,把“Accessory”改成“Disclosure Indicator”。定义重用标识符(Reuse Identifier)比较重要。你可以认为它是表格的ID。我们可以针对某个具体的prototype cell使用它。然而,这里定义为“RecipeCell”是为了与代码中的一致。

Storyboard-Edit-Prototype-Cell

现在再次运行应用程序。它看起来又发生了些变化。我们把表的风格改为“Grouped”,并添加了提示箭头。

Storyboard-Recipe-App-with-Disclosure

添加详细视图控制器

终于到了文章最后的部分。显示菜谱详细内容的详细视图控制器(Detail View Controller)还差点儿什么呢?当用户点击菜谱中的任何一项时,详细视图控制器都应该显现。

好了,我们添加一个新的View Controller作为详细视图控制器。

Storyboard-Create-Detail-View-Controller

本文的主要目的是向你展示如果实现Navigation Controller。我们会让详细视图尽量简单,就用一个标签来显示菜名。从对象库里拖拽一个标签,放到视图的中央。你可以修改标签的字体和字号,使标签更好看一些。

接下来,我们添加一个segue来连接prototype cell和新的View Controller。添加segue对象非常简单。按住control键不放,点击prototype cell,将其拖拽到View Controller。

Storyboard-Add-Segue

放开按钮,会天出三种类型的Segue(push,modal和custom)。

Storyboard-Segues

就像前面说的,segue定义了scene之间点连接。标准的导航控制器选择“Push”类型的连接。一旦完成,Xcode会自动使用segue链接两个scene。看起来这个样子:

Storyboard-Segue-Connection

现在再运行一下应用程序。选择任何一项后,应用程序会显示详细视图控制器。虽然详细视图控制器只显示一个标签,但是导航控制器已经起作用了。

Receipe-App-With-Detail-Controller

接下来讲些什么内容?

这是一篇较长的文章,终于完成了!我希望你对Storyboard有了更好的理解,知道如何设计自己的导航控制器。然而,还有一件事情没有讲:如何将菜单的名称从“Recipe Book View Controller”传递到“Detail View Controller”呢?我会在本周末发布一篇文章对此进行介绍。

这些Storyboard,UITableView和Navigation Controller是UI元素的基础,构建iOS应用程序的时候常被用到。所以要花费一些时间来通读本文,确保对此了如指掌。

[转载此篇译文,请注明译文出处]

23 9月

使用JSON和WatchKit构建简单的天气应用程序

文 / Gregory Tareyev:iOS开发者,http://iamchill.com联合创始人。

原文链接:http://www.appcoda.com/weather-watchkit-app/

编辑注:这是论坛游客Gregory Tareyev发的帖,他是iOS开发人员和Chill(iamchill.co)的联合创始人。开发的首个可穿戴通信工具让你和朋友们动动指尖就能互动。在本文中,Gregory将分享自己做Apple Watch开发的经验,向你展示如何使用第三方API和WatchKit构建简单的天气应用程序。我们已经写了两篇与WatchKit有关的文章,都是使用Swift语言完成的。一些读者提到是否能有一篇使用Objective-C的文章,这篇便是。

Gregory的文章从这里开始……

大家好,我是Gregory Tareyev(可以来tareyev.ru联系我),是iOS开发人员和Chill(iamchill.co)的联合创始人。第一款可穿戴的通信工具终于搞定了。最近我们在Product Hunt上展示的产品有着不俗的表现,使我们在社区内获得了广泛的影响力并吸引了主要的技术博客报道这次发布。我们也在讨论使用加速器的问题,并考虑使用最好的那种。为构建应用程序而着实努力着,我相信你们每个人都可以为此而努力。

55d1486e117dc_middle

在这里想要与你分享我的Apple Watch开发经验。很有趣,也不难。

为了调动你的兴趣,我要解释在可穿戴设备上进行开发为何如此重要。

  1. 市场仍然不太大,这等同于作为先行者,你可以获得更大的市场份额。
  2. 市场将会获得极大增长,这等同于相关产品规模会随着市场同步增长。

55d14acdba958_middle

来源:图表由Business Insider提供。

在本文中,构建一个简单的Apple Watch天气应用程序,要完成两件事:

  • 如何在使用WatchKit在应用程序中解析JSON数据
  • 如何使用OpenWeatherMap的API(一旦明白其中的道理,你应该能够选择任何基于JSON的API来使用)

我们开始吧!

应用程序示例

示例程序是一款非常简单的天气应用程序,会使用OpenWeatherMap的API得到特定城市(例如:伦敦)的天气信息。这是应用程序最终样例的截图。

55d14b794590b

创建Xcode工程

首先,创建一个Single View Application,并按照如下截图设置项目信息。没错儿,我们使用Objective-C来做,我觉得Objective-C仍然很重要,还是要继续使用的。

55d14bcd1445f_middle

创建一个Watch应用程序,到Xcode顶部菜单栏选取File > New > Target…,选择Apple Watch > WatchKit App。由于使用WatchKit App模版,所以会生成构建Watch应用程序所需要的一切。

55d14ccb2a8f8_middle

取消选择“Include Notification Scene”,其余项保留,点击Finish。

simple-weather-watch-app

你会得到一条警告信息问是否要激活,点击Activate就是了。然后就会看到两个新文件夹:WatchKit Extension和WatchKit App。

simple-weather-watch-scheme

设计应用程序的用户接口

接下来,我们要着手设计应用程序的用户接口。为此,点击“SimpleWeather WatchKit App”下的Interface.Storyboard文件。

首先,从对象库(Object Library)拖拽一个Lable控件,名称设置为“Weather in London”。控件上字体大小可能需要调整一下。然后拖拽一个Image控件。接着再来一个Button控件。你会发现图像和按钮都会自动布局,垂直堆放。把按钮的Title改为“Update”,颜色调为绿色并调整图像的尺寸。

simple-weather-watch-ui

标签用来显示气象类型,而图像显示气象类型的插图。Update按钮是与用户交互的唯一元素,用来更新天气信息。

Interface Builder可以让你看到Apple Watch不同版本的视图。默认情况下,Interface Controller被设置成Any Screen Size。可以点击Interface Builder下方的“Any Screen Size”按钮,在Apple Watch 38/42mm这两种尺寸间切换。如果切换到Apple Watch 42mm,就会发现图像不完全合适,要调整图像大小,把所有控件布局弄好为止。因为更改图像大小时,Xcode会自动添加对布局做特殊处理。这种情况只在选择Apple Watch 42mm的才出现。

simple-weather-watch-ui-42

理解JSON和OpenWeatherMap的API

已经说过了,我们使用OpenWeatherMap的API来得到天气数据。为了理解它是如何工作的,要打开这个链接:http://api.openweathermap.org/data/2.5/weather?q=London,uk。拷贝结果并粘贴到http://json.parser.online.fr。你会看到结构化的JSON数据。在这里,我们感兴趣的是天气类型,也就是dictionary类型数据“weather”下的“main”键。这就是我们要在屏幕上显示的信息。

openweather-api-json

作为参考,可以在http://openweathermap.org/api查看API文档。

现在,一起来看如何解析JSON数据,并把天气信息在应用程序中展现出来。

打开Assistant Editor,按住Control键拖拽Label控件到InterfaceController.h文件的代码中做关联,把outlet命名为“weatherType”。

add-label-outlet

重复上述过程,将Image控件也做好关联,把Outlet命名为“weatherImage”。在给Update按钮做关联时,不要选择Outlet,选择Action类型,并命名为“updateAction”。

add-update-action

在InterfaceController.m文件中为updateAction方法添加逻辑代码:

- (IBAction)updateAction
{
    NSURLRequest* requestForWeatherData = [NSURLRequest requestWithURL:[NSURL URLWithString:@"http://api.openweathermap.org/data/2.5/weather?q=London,uk"]];
    NSURLResponse* response = nil;
    NSError* error = nil; //do it always
 
    NSData* data = [NSURLConnection sendSynchronousRequest:requestForWeatherData returningResponse:&response error:&error]; //for saving all of received data in non-serialized view
    
    NSMutableDictionary *allData = [ NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:&error]; //data in serialized view
    NSString* currentWeather = nil;
    
    NSArray* weather = allData[@"weather"];
    
    for (NSDictionary* weatherDictionary in weather)
    {
        currentWeather = weatherDictionary[@"main"];
    }
}

该方法中,使用了NSURLConnection对OpenWeatherMap同步发出请求。可以使用NSJSONSerialization把JSON数据转换为Foundation基础库类型(例如:NSDictionary)。我们对数据进行解析以后将天气类型存入“currentWeather”变量中。

接下来,要更新标签和图像。

weather-image-if

这样代码看起来不是太美观,对吧?

为了避免对天气类型进行硬编码,可以创建如下方法。这样会使代码更灵活。

  1. -(void)setImageAndTextWithWeather:(NSString* ) weatherName
  2. {
  3.      // Use the weather type as the weather image name. For example, if the weather name is “Rainy”, the image name is set to “rainy.jpg”. 
  4.      // Set the weather type to the given weather name
  5. }

很不错!我们把方法放到真实的代码中:

  1. -(void)setImageAndTextWithWeather:(NSString* ) weatherName
  2. {
  3.         NSString* weatherNameWithoutSpaces = [weatherName stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]]; //delete potential spaces in JSON array
  4.         [_weatherImage setImageNamed:[weatherNameWithoutSpaces stringByAppendingString:@“.jpg”]];
  5.     NSMutableAttributedString *customString = [[NSMutableAttributedString alloc] initWithString:weatherNameWithoutSpaces];
  6.     [customString addAttribute:NSFontAttributeName
  7.                          value:[UIFont systemFontOfSize:18]
  8.                   range:NSMakeRange(0, [weatherNameWithoutSpaces length])]; //Making text more readable by creating a custom string
  9.     [_weatherType setAttributedText:customString];
  10. }

最后,在updateAction方法的结尾加上这行代码:

[self setImageAndTextWithWeather:currentWeather];

在Asset Catalog中添加图像

运行应用程序之前,下载这些图像。解压缩后把这些图像全部添加到SimpleWeather WatchKit App文件夹下的Images.xcassets里。

simple-weather-images

可以随便添加更多带有天气类型名称的图像。应用程序不用更改任何代码就可以运行。

测试应用程序

差不多了!现在可以在Apple Watch模拟器中构建并运行应用程序了。选择“WatchKitDemo WatchKit App”项目,并选择合适的设备,然后点击Run按钮,测试Apple Watch应用程序。另外,还可以修改模拟器显示的尺寸,选择Hardware > External Displays > Apple Watch – 38mm。

55d151607af6f_middle

很棒!你开发完成了一款Apple Watch天气应用程序。

作为参考,可以在这里下载最终的项目

http://www.csdn.net/article/2015-08-17/2825474/2

30 8月

苹果官方博客:从SDK详说Swift代码的改变

文 / Apple Inc.     原文链接:Apple Developer’s Blog

Xcode 6.3中,我们为Objective-C添加了新语言特性nullability注解。这个特性给Objective-C提供了表达API使用null和non-null统一的方式。相当于Swift语言中的Optional类型。Xcode 7继续为Objective-C与Swift之间更加自然地通信引入轻量级的泛型模型。泛型使得这两种语言能够可靠地融合并分享带有特定类型元素的集合。

这些特性对任何使用Swift和Objective-C这两种语言编程的人来说都比较有用。但应用程序开发人员每天使用的Objective-C代码占更大部分:这就是组成Apple SDK的那些框架。为了提升Swift和Objective-C的使用体验,全公司的范围内,我们在SDK的头文件中都提供了这样的信息。Xcode 7中,你会发现几乎所有常见框架都指定了其API的nullability注解,包括其集合类型的元素。这使得Swift代码的样子发生了变化。

变化前:

  1. class UIView : UIResponder {
  2.     init!(frame: CGRect)
  3.     var superview: UIView! { get }
  4.     var subviews: [AnyObject]! { get }
  5.     var window: UIWindow! { get }
  6.     // …
  7.     func isDescendantOfView(view: UIView!) -> Bool
  8.     func viewWithTag(tag: Int) -> UIView!
  9.     // …
  10.     var constraints: [AnyObject]! { get }
  11.     // …
  12. }

变化后:

  1. class UIView : UIResponder {
  2.     init(frame: CGRect)
  3.     var superview: UIView? { get }
  4.     var subviews: [UIView] { get }
  5.     var window: UIWindow? { get }
  6.     // …
  7.     func isDescendantOfView(view: UIView) -> Bool
  8.     func viewWithTag(tag: Int) -> UIView?
  9.     // …
  10.     var constraints: [NSLayoutConstraint] { get }
  11.     // …
  12. }

最后一个疑问是Xcode 7中将代码转换成Swift 2的工具,在Xcode的Edit菜单下,Convert > To Latest Swift Syntax。通过必要的编辑,该工具会将一个使用Swift 1.2编写的项目转换成合法的Swift 2.0代码。这些改变源于改进后的头文件信息。例如,正在重写的一个方法,其参数和结果类型更加精确,方法转换的过程中将会被更新与之匹配。

在今年的WWDC的Swift and Objective-C Interoperability视频14:30处,对Objective-C所作的改进做了详尽的描述。注意,该视频使用的是Xcode 6.3中的__nullable语法,并非更新的Xcode 7中用的_Nullable。了解更多nullability注解的信息,可以看看Nullability and Objective-C。了解Swift 2.0和Objective-C中轻量级泛型更多信息,可以看看Xcode 7 Release Notes

http://www.csdn.net/article/2015-08-17/2825473-swift-er-sdk

19 7月

Swift 2.0中的错误处理

文 / Juan Pablo Claude:来自智利首都圣地亚哥,毕业于美国北卡罗莱纳大学教堂山分校(University of North Carolina at Chapel Hill),获化学博士学位,后入阿拉巴马大学伯明翰分校(University of Alabama at Birmingham)任教。2005年底作为Cocoa和Django框架程序开发人员加入Big Nerd Ranch。此前,有过DOS环境下C编程,Windows环境下使用C++编写数据分析应用程序的经历。

原文链接:https://www.bignerdranch.com/blog/error-handling-in-swift-2/

苹果公司在今年的全球开发者大会(Worldwide Developers Conference, WWDC)上宣布推出Swift2.0,该语言的首席架构师Chris Lattner表示,Swift2.0主要在语言基本语法、安全性和格式美观度这三方面进行了改进。除了这些新的功能特性,还有对语法的优化、修饰及美化,最后是Swift 1.x中最具影响力的错误处理机制。

这是因为你根本无法回避它。如果打算使用Swift 2.0的话,必须接受错误处理这样的机制,并且错误处理机制将改变Cocoa和Cocoa Touch框架中使用NSError与方法交互的方式。

历史一瞬:不起眼的开端

我们都知道,Swift语言作为Objective-C当前替代语言被推出,是OS X和iOS应用程序开发的“通用语”。在最初的版本中,Objective-C没有原生的异常处理机制。后来通过添加NSException类,还有 NS_DURING, NS_HANDLER和 NS_ENDHANDLER宏才有了异常处理。这种方案现在被称为“经典的异常处理”,还有这些宏都是基于setjmp()和longjmp()这两个C语言函数的。

异常捕获(exception-catching)看起来如下图所示,在NS_DURING和NS_HANDLER宏之间抛出的任何异常都将会导致在NS_HANDLER和NS_ENDHANDLER宏之间执行相应的代码。

  1. NS_DURING
  2.     // Call a dangerous method or function that raises an exception:
  3.     [obj someRiskyMethod];
  4. NS_HANDLER
  5.     NSLog(@“Oh no!”);
  6.     [anotherObj makeItRight];
  7. NS_ENDHANDLER

下面是立刻能触发抛出异常的方法(现在仍然可用):

  1. – (void)someRiskyMethod
  2. {
  3.     [NSException raise:@“Kablam”
  4.                 format:@“This method is not implemented yet. Do not call!”];
  5. }

可以想象,这种手工处理异常的方式戏弄的是早期Cocoa框架程序开发人员。但是这些程序员还不至于到这份儿上,因为他们很少使用这种方式。无论在Cocoa还是Cocoa Touch框架下,异常通常都被归为灾难性的,不可恢复的错误,比如程序员造成的错误。上面的-someRiskyMethod就是很好的例子,由于实现部分没有准备好而引发了异常。在Cocoa和Cocoa Touch框架中,可恢复的错误由稍后讨论的NSError类来处理。

原生的异常处理

我想由于Objective-C中的经典异常处理机制对应的手工处理方式让人感觉闹心,于是苹果公司在Mac OS X 10.3(2003年10月)中发布了原生的异常处理机制,彼时还没有iOS系统。这本质上是将C++的异常处理嫁接到了Objective-C。异常处理的结构目前看起来是这样的:

  1. @try {
  2.     [obj someRiskyMethod];
  3. }
  4. @catch (SomeClass *exception) {
  5.     // Handle the error.
  6.     // Can use the exception object to gather information.
  7. }
  8. @catch (SomeOtherClass *exception) {
  9.     // …
  10. }
  11. @catch (id allTheRest) {
  12.     // …
  13. }
  14. @finally {
  15.     // Code that is executed whether an exception is thrown or not.
  16.     // Use for cleanup.
  17. }

原生的异常处理使你有机会为每个异常类型指定不同@catch部分。无论@try结果如何,@finally都要执行其对应的代码。

尽管原生的异常处理如所预期的那样抛出一个NSException异常,但是最明确的方法还是“@throw <expression>;”语句。通常你抛出的是NSException实例,但说不定什么对象会被抛出。

NSError

尽管Objective-C原生与经典的异常处理有许多优点,但Cocoa和Cocoa Touch框架应用程序开发人员仍然很少使用异常,而是限制程序出现程序员所导致的不可恢复的错误。使用NSError类处理可恢复的错误,这种方法早于使用异常处理。Swift 1.x也继承了NSError的样式。

在Swift 1.x中,Cocoa和Cocoa Touch的方法和函数可能不会返回一个布尔类型的false或者nil来表示一个失败(failure)的对象。另外,NSErrorPointer对象会被当作一个参数返回特定的失败信息。下面是个典型的例子:

  1. // A local variable to store an error object if one comes back:
  2. var error: NSError?
  3. // success is a Bool:
  4. let success = someString.writeToURL(someURL,
  5.                                     atomically: true,
  6.                                     encoding: NSUTF8StringEncoding,
  7.                                     error: &error)
  8. if !success {
  9.     // Log information about the error:
  10.     println(“Error writing to URL: \(error!)”)
  11. }

程序员所导致的错误可以用Swift标准库(Swift Standard Library)函数fatalError(“Error message”)来标记,将其在控制台记录为错误消息并无条件中止执行。还可以使用assert(), assertionFailure(), precondition()和preconditionFailure()这些函数。

Swift第一次发布时,一些非苹果平台开发人员已经准备好了火把和干草叉。他们声称Swift不能算是“真正的语言”,因为它缺乏异常处理。但是,Cocoa和Cocoa Touch社区对此不予理睬,我们知道NSError和NSException那个时候就存在了。就我个人而言,我相信苹果公司仍然在思考实现错误和异常处理的正确方式。我还认为直到问题解决了,苹果公司才会公开Swift源码。这一切问题在Swift 2.0中全被扫清了。

Swift 2.0中的错误处理

在Swift 2.0中,如果想要抛出错误,那么抛出的对象必须符合ErrorType协议。可能正如你所愿,NSError就符合该协议。枚举在这里用来给错误进行分类。

  1. enum AwfulError: ErrorType {
  2.     case Bad
  3.     case Worse
  4.     case Terrible
  5. }

然后如果一个可能抛出一个或多个错误的函数或方法会被抛出关键字标记:

  1. func doDangerousStuff() throws -> SomeObject {
  2.     // If something bad happens throw the error:
  3.     throw AwfulError.Bad
  4.     // If something worse happens, throw another error: 
  5.     throw AwfulError.Worse
  6.     // If something terrible happens, you know what to do: 
  7.     throw AwfulError.Terrible
  8.     // If you made it here, you can return:
  9.     return SomeObject()
  10. }

为了捕获错误,新型的do-catch语句出现了:

  1. do {
  2.     let theResult = try obj.doDangerousStuff()
  3. }
  4. catch AwfulError.Bad {
  5.     // Deal with badness.
  6. }
  7. catch AwfulError.Worse {
  8.     // Deal with worseness.
  9. }
  10. catch AwfulError.Terrible {
  11.     // Deal with terribleness.
  12. }
  13. catch ErrorType {
  14.     // Unexpected error!
  15. }

这个do-catch语句和switch语句有一些相似之处,被捕获的错误详尽无遗,因此你可以使用这种样式来捕获抛出的错误。还要注意关键字try的使用。它是为了明确地标示抛出的代码行,因此当阅读代码的时候,你能够立刻找到错误在哪里。

关键字try的的变体是“try!”。这个关键字大概也适用于那些程序员导致的错误。如果使用“try!”标记一个被调用的抛出对象中的方法,你等于告诉编译器这个错误永远不会发生,并且你也不需要捕获它。如果该语句本身产生了错误(error),应用程序会停止执行,那么你就要开始调试了。

  1. let theResult = try! obj.doDangerousStuff()

与Cocoa和Cocoa Touch框架间的交互

现在的问题是,你如何在Swift 2.0中处理爷爷级的NSError API呢?苹果公司已经Swift 2.0中为统一代码行为作了大量工作,并且已经为未来写入Swift的框架准备方法。Cocoa和Cocoa Touch中可以产生NSError实例的方法和函数有苹果公司的签名( signature),可以自动转换为Swift新的错误处理方式。

例如,这个NSString的构造器( initializer)在Swift 1.x中就有以下签名:

  1. convenience init?(contentsOfFile path: String,
  2.                   encoding enc: UInt,
  3.                   error error: NSErrorPointer)

Swift 2.0中,签名被转换成:

  1. convenience init(contentsOfFile path: String,
  2.                  encoding enc: UInt) throws

注意:在Swift 2.0中,构造器不再被标记为failable,它并不需要NSErrorPointer来做参数,而是使用抛出异常的方式显式地指示潜在的失败。

下面的例子使用了这种新的签名:

  1. do {
  2.     let str = try NSString(contentsOfFile: “Foo.bar”,
  3.                            encoding: NSUTF8StringEncoding)
  4. }
  5. catch let error as NSError {
  6.     print(error.localizedDescription)
  7. }

注意错误是如何被捕获的,并且如何被转换成了一个NSError实例,这样你就可以获取与其相似API的信息了。事实上,任何ErrorType类型的实例都可以转换成NSError类型。

最后说说@finally

细心的读者可能已经注意到,Swift 2.0引入了一个新的do-catch语句,而不是do-catch-finally。不管是否捕捉到错误的情况下,你如何指定必须运行的代码呢?为此,现在可以使用defer语句,用来推迟代码块的执行直到当前的作用域结束。

  1. // Some scope:
  2. {
  3.     // Get some resource.
  4.     defer {
  5.         // Release resource.
  6.     }
  7.     // Do things with the resource.
  8.     // Possibly return early if an error occurs.
  9. // Deferred code is executed at the end of the scope.

Swift 2.0将Cocoa和Cocoa Touch的错误处理机制凝聚为具有现代风格的用法,这是一项伟大的工作,也会使许多程序员倍感亲切。统一行为是不错的定位,会使Swift语言和其所继承的框架逐步发展。

http://www.csdn.net/article/2015-07-01/2825095/2

17 6月

Swift语言那些鲜为人知的特性

文 / Russ Bishop:全能型程序员,使用C#,Objective-C和Swift语言编程,开发了奇特的应用Storm Sim Free。

原文链接:http://www.russbishop.net/more-swift-attributes

Swift语言有各种各样缺乏(或没有)文档记录的特性(attribute)放在那里等着被使用。让我们一起看看其中的一些特性:

@inline

这个特性为编译器提供了内联提示。有效的取值是__always和never。除非我认为必须要用这两个值,否则就不会使用它(特别是__always)。到目前为止与其相关的规则还不是很明确,在有限的测试下,它可以正常地工作,但还要视具体情况而定。

进一步的解释:尽管底层虚拟机(Low Level Virtual Machine, LLVM)有强制内联的概念,但我们目前还不知道这个@inline特性是否与其直接映射,也不知道是否存在大小方面的限制,但这将会导致编译器忽略这一点而跳过内联。理论上说应该是这样的,但我不保证一定是。

注意(当优化设置关闭时)在调试模式下的构建将忽略@inline。

@transparent

我最初并未将这个特性列出来。该特性会导致编译器在管道(pipeline)中更早地将函数内联。它用于“像+(Int, Int)这样非常原始的函数”,而“不应该用于独立函数”

甚至在没有优化设置的调试模式下@transparent特性函数就会被内联,所以在调用“1+1”这样的函数的时候并不会特别慢。另外这个特性与@inline(__always)非常类似。

@availability

这个特性可以用来标识某些函数只在某些平台或版本上可用。第一个参数是平台,可以用星号(*)代表一切可用,还可以是iOS或OSX。因为如果需要针对不同的平台,就要指定多个@availability属性。

如果需要表示该函数在某个给定的平台完全不可用时,可以将第二个参数置为unavailable。此外,还可以用introduced,deprecated和obsoleted来指定一个或是多个版本的组合:obsoleted意味着该项已经删除,deprecated仅仅表示如果使用就会给予警告。最后你可以设置message的值,如果该项被使用了就由编译器输出。下面是一些例子:

  1. @availability(*, unavailable)
  2. func foo() {}
  3. @availability(iOS, unavailable, message=“you can’t call this”)
  4. func foo2() {}
  5. @availability(OSX, introduced=10.4, deprecated=10.6, obsoleted=10.10)
  6. @availability(iOS, introduced=5.0, deprecated=7.0)
  7. func foo3() {}

@noreturn

正如该特性所描述的那样:编译器可以假定这个函数是一个永远循环运行的起点,例如while true { },或者假定是函数abort或者exit进程的情况。

评论者Marco Masser指出,如果调用另一个被标志为@noreturn的函数,那么编译器会忽略掉当前函数中缺失的返回值(missing return values),因为编译器理解程序的控制流。

@asmname

该属性给出了函数、方法或属性实现的符号名称。如果你已经知道对应的函数参数及其类型,那么就可以直接调用Swift的内部标准库函数,甚至不用头文件,也可以方便地调用C语言编写的函数:

  1. @asmname(“function”) func f()

@unsafe_no_objc_tagged_pointer

上面这个仍然是个谜,但我猜测它是在告诉Swift与Objective-C联系的时候不要使用tagged pointer

@semantics

这又是另一个谜。参数看起来像是array.mutate_unknown或array.init这样的字符串数组。想必这是要告诉编译器(或静态分析器)函数是如何工作的。

结论

谁还需要乏味老套的 @objc和@autoclosure呢?还是算了吧!

我今年会去参加苹果全球开发者大会(WWDC),你也一定要去呀!

http://www.csdn.net/article/2015-06-08/2824887-more-swift-attributes

09 6月

ARC中retain cycle揭秘

文 / Ignacio Nieto Carvajal:自由开发者,精通iOS和Mac OSX应用程序开发,还包括Web服务和UX/UI设计。

原文链接:http://digitalleaves.com/blog/2015/05/demystifying-retain-cycles-in-arc/

ARC中的retain cycle就像日本B级恐怖电影一样。开始使用Cocoa或Cocoa Touch做开发时,你甚至不会在意它的存在。直到有一天应用程序由于内存泄漏而出现了崩溃现象,你才意识到它们的存在,看到像幽灵一样的retain cycle无处不在。随着岁月流逝,你学会适应它们,发现它们,避免它们……但最终恐慌还在,无孔不入。

包括我在内,对于许多开发人员来说,ARC的最令人失望之处莫过于苹果公司让ARC来管理内存。不幸的是ARC没有循环引用检测器,因此很容易出现retain cycle现象,从而迫使开发人员在编码时要采取特殊的预防措施。

对于iOS开发人员来说,retain cycle是个难点。在网上有很多误导信息[1][2],人们所给出的这些错误信息和修复方法甚至会导致应用出现新的问题,甚至崩溃掉,基于这样的情况,本文中我会阐明主题,给读者一些启发。

相关理论一瞥

Cocoa框架内存管理可以追溯到MRR(Manual Retain Release),在MRR中,开发人员在创建对象的时候,要为每个内存中的对象声明所有权。并且,当不再需要该对象时,要放弃所有权。MRR通过引用计数系统来实现这种所有权机制。每个对象都被分配一个计数器指示被“拥有”了多少次,每次加一,释放对象的时候每次减一。当引用计数变成零的时候,该对象将不复存在。对于开发人员来说,不得不手动维护引用计数真的是很烦人的事情,于是苹果公司引入了自动引用计数(Automated Reference Counting, ARC)机制,免得开发人员手动添加保留(retain)和释放(release)指令,让他们专注于解决应用程序的问题。在ARC环境下,开发人员要将一个变量定义为“strong”或“weak”。使用weak的话应用程序中被声明的对象不会被retain,而使用strong声明的对象将会被retain,并且其引用计数加一。

为什么要在乎?

ARC的问题在于容易导致retain cycle,它发生在两个不同的对象间彼此包含强引用的时候。试想一个Book对象包含一系列的Page对象,每个Page对象有个属性指向该页所在的这本书。当你释放掉指向Book和Page的变量时,Book和Page之间还存在着强引用。因此,即使没有变量指向Book和Page了,Book和Page及其所占用的内存也不会被释放掉。

不幸之处在于并非所有retain cycle都很容易被发现。对象之间的传递关系(A引用B,B转而引用C,C引用A)会导致retain cycle。更糟糕的是Objective-C里的块(block)和Swift里的闭包(closure)都被认为是独立的内存对象。因此,任何在块或闭包内对像的引用都将会对其变量做retain操作。因此,如果对象仍然retain这个块的话,就会导致潜在的retain cycle发生。

retain cycle可以成为应用程序潜在的危害,导致内存消耗过高,性能低下和崩溃。但还没有来自于苹果公司的文档,针对retain cycle可能发生的不同场景,以及如何避免进行描述。这导致了一些误解并形成了不良的编程习惯。

用例场景

那么闲话少说,我们一起来分析一些场景,确定它们是否会导致retain cycle以及如何避免:

父子对象关系

这是retain cycle的典型例子。不幸的是这也是苹果公司唯一给出相关解决方案文档的例子。就是我上面描述的Book和Page对象的例子。这种情况的典型解决方案是把Child类里面的代表父类的变量定义成weak,这样就可以避免retain cycle。

  1. class Parent {
  2.    var name: String
  3.    var child: Child?
  4.    init(name: String) {
  5.       self.name = name
  6.    }
  7. }
  8. class Child {
  9.    var name: String
  10.    weak var parent: Parent!
  11.    init(name: String, parent: Parent) {
  12.       self.name = name
  13.       self.parent = parent
  14.    }
  15. }

在Swift语言中,代表父类的变量是个弱变量的事实迫使我们将其定义为可选类型。不使用可选类型的另一种做法是将父类型对象声明为“unowned”(意味着我们不会对变量声明进行内存管理或声明所有权)。然而在这种情况下,我们必须非常仔细地确保只有一个Child实例指向Parent,Parent就不能是nil,否则程序就会崩溃:

  1. class Parent {
  2.    var name: String
  3.    var child: Child?
  4.    init(name: String) {
  5.       self.name = name
  6.    }
  7. }
  8. class Child {
  9.    var name: String
  10.    unowned var parent: Parent
  11.    init(name: String, parent: Parent) {
  12.       self.name = name
  13.       self.parent = parent
  14.    }
  15. }
  16. var parent: Parent! = Parent(name: “John”)
  17. var child: Child! = Child(name: “Alan”, parent: parent)
  18. parent = nil
  19. child.parent <== possible crash here!

一般来说公认的做法是父对象必须拥有(强引用)其子对象,这些子对象对其父对象应该只保持一个弱引用。这同样适用于集合,集合必须拥有其所包含的对象。

包含在实例变量中的块和闭包

另一个经典的例子虽然不是那么直观,但正如我们之前所说的那样,闭包和块是独立的内存对象,并retain了它们所引用的对象。因此如果我们有一个包含闭包变量的类,这个变量又恰好引用了其所拥有对象的属性或方法,由于闭包通过创建一个强引用而“捕获”了自己,就会有retain cycle发生。

  1. class MyClass {
  2.    lazy var myClosureVar = {
  3.       self.doSomething()
  4.    }
  5. }

这种情况下的解决方法是将自身定义成“weak”版本,并且将此弱引用赋给闭包或块。在Objective-C语言中,要定义个新的变量:

 

  1. – (id) init() {
  2.    __weak MyClass * weakSelf = self;
  3.    self.myClosureVar = ^{
  4.       [weakSelf doSomething];
  5.    }
  6. }

而在Swift语言中,我们只需要指定“[weak self] in”作为闭包的启动参数:

  1. var myClosureVar = {
  2.    [weak self] in
  3.    self?.doSomething()
  4. }

这样一来,当闭包快执行完毕时,self变量不会被强制retain,因此会得到释放,打破循环。注意,当声明为weak时,self在闭包内是如何变成可选类型的。

GCD中的dispatch_async

与一贯的认识相反,dispatch_async本身并不会导致retain cycle。

  1. dispatch_async(queue, { () -> Void in
  2.    self.doSomething();
  3. });

在这里,闭包对self强引用,但是类(self)的实例对闭包没有任何强引用,因此一旦闭包结束,它将被释放,也不会有环出现,然而,有的时候会被(错误地)认为这种情况会导致retain cycle。一些开发人员甚至一针见血地指出将块或闭包内所有对“self”的引用都声明为weak:

  1. dispatch_async(queue, {
  2.    [weak self] in
  3.    self?.doSomething()
  4. })

在我看来,对每种情况都这样做并不是好的做法。我们假设某个对象启动了一个长时间的后台任务(比如从网络上下载一些东西),然后调用了一个“self”方法。如果对self传递一个弱引用的话,那么类会在闭包结束之前完成它的生命周期。因此,当调用 doSomething()的时候,类的实例已经不存在了,所以这个方法永远不会被执行。这种情况下,(苹果公司)建议的解决方案是对闭包内的弱引用(???)声明一个强引用:

  1. dispatch_async(queue, {
  2.    [weak self] in
  3.    if let strongSelf = self {
  4.       strongSelf.doSomething()
  5.    }
  6. })

我不仅发现语法冗长单调,缺乏直观性,甚至令人感到厌恶,而且使闭包作为独立的处理实体的打算也落空了。我认为要理解对象的生命周期,确切地明白什么时候应该为实例声明一个内部的weak版,还要知道对象存续期间会有哪些影响。但话又说回来,这正是我解决应用程序的问题时分散我注意力的地方,如果Cocoa框架中没有使用ARC的话,这些都是没有必要写的代码。

局部的闭包和块

没有引用或包含任何实例或类变量的函数局部闭包和块本身不会导致retain cycle。常见的例子就是UIView的animateWithDuration方法:

  1. func myMethod() {
  2.    …
  3.    UIView.animateWithDuration(0.5, animations: { () -> Void in
  4.       self.someOutlet.alpha = 1.0
  5.       self.someMethod()
  6.    })
  7. }

对于dispatch_async和其他GCD相关的方法,我们不用担心没有被类实例强引用的局部闭包和块,它们不会发生retain cycle。

代理方案

代理(delegation)是使用弱引用避免retain cycle的一个典型场景。将委托声明为weak一直是一种不错的做法(并且还算安全)。在Objective-C中:

  1. @property (nonatomic, weak) id <MyCustomDelegate> delegate;

Swift中:

  1. weak var delegate: MyCustomDelegate?

在大多数情况下,对象的代理实例化了该对象,或者被认为比对象存在的时间更长久(并且对代理方法做出反应)。因此,在一个设计得很好的类中,我们不会找到与对象声明周期相关的任何问题。

使用Instruments来调试retain cycle

不管我如何努力避免retain cycle,忘记去引入一个弱引用并意外地创建一个(多谢ARC!)这样的事情迟早还有发生。幸运的是XCode套件中的Instruments应用程序是很不错的工具,用于检测和定位retain cycle。一旦开发阶段结束,在提交苹果商店之前就分析(profile)你的应用是个不错的习惯。Instruments有很多模版用来分析应用的不同方面,但我们感兴趣的是“Leaks”选项。

一旦打开Instruments,你就应该启动应用程序并作一些交互操作,特别是在要测试的区域或试图控制器上。任何检测到的泄漏都将会在“Leaks”部分出现一条红线。辅助视图包含一个区域,Instruments用来显示发生泄漏处的堆栈追踪,用来找到问题所在,甚至使你可以直接定位到造成问题的代码。

http://www.csdn.net/article/2015-05-27/2824782-demystifying-retain-cycles-in-arc