Geek Answers Handbook

UIButton like UIButton in fast?

I look at this Swift tutorial, and there is this line:

var button:UIButton = UIButton.buttonWithType(UIButtonType.System) as UIButton

two questions:

  • why does this line end with as UIButton ? Is it not clear that the user wants to create a system type button? It seems redundant.
  • Do I need to declare a UIButton type in the first part of the string? Or, in other words, not enough to declare it as

var button = UIButton.buttonWithType (UIButtonType.System)

I mean, if the part after the equal sign initializes a system-type button, is that not enough for the compiler to conclude that button is UIButton ? I mean, Apple stated that the compiler can type in.

+7
swift
source share
4 answers

You need to remove as UIButton . buttonWithType() return AnyObject! , not UIButton , so conversion must be done. Other than this, you do not need to explicitly enter the variable with : UIButton . Since the return type of buttonWithType() as a downcast for UIButton, the variable type will be inferred as UIButton . This is what you should use:

 var button = UIButton.buttonWithType(UIButtonType.System) as UIButton
+10
source share

Some additional background in addition to the answers already provided: Objective-C Method

 + (id)buttonWithType:(UIButtonType)buttonType

returns id . It was a "traditional" way to declare a "factory" method so that it could also be used from subclasses. IN

 UIButton *button = [UIButton buttonWithType: UIButtonTypeSystem];

because id can be converted to any Objective-C pointer.

Now the equivalent id type in Swift is AnyObject , and the above method maps to

 class func buttonWithType(buttonType: UIButtonType) -> AnyObject!

Swift is much more strict and implicitly converts types, so the return value must be explicitly pointed to UIButton :

 var button = UIButton.buttonWithType(UIButtonType.System) as UIButton

The "modern" approach for declaring factory methods is instancetype (see, for example, http://nshipster.com/instancetype/ or Would it be useful to start using instancetype instead of id? ). Simple example NSString method

 + (instancetype)stringWithCString:(const char *)cString encoding:(NSStringEncoding)enc

which is displayed in Swift on

 class func stringWithCString(cString: CString, encoding enc: UInt) -> Self!

Self is the type of object the method is called on, so the return type

 NSString.stringWithCString("foo", encoding: NSUTF8StringEncoding)

there is NSString! , and return type

 NSMutableString.stringWithCString("bar", encoding: NSUTF8StringEncoding)

there is NSMutableString! . Swift does not require any casting. In the following examples, the Swift compiler “knows” that str is an NSString :

 var str = NSString.stringWithCString("foo", encoding: NSUTF8StringEncoding) var cs = str.UTF8String

Foundation Foundation headers already use instancetype in many places, but not wherever possible (as in buttonWithType: . This may be improved in future releases of the SDK.

+7
source share

If you click the buttonWithType button, you will see that in swift is declared as

 class func buttonWithType(buttonType: UIButtonType) -> AnyObject!

Since the return type is AnyObject! you need to dial it back to UIButton.

+2
source share

Swift 2.1 now

 var button = UIButton(type: .System)

so no need to reset with .buttonWithType

0
source share

More articles:


All Articles