iOS 8 HealthKit Santiapps Marcio Valenzuela

HealthKit for iOS8: Part 4

iOS 8 HealthKit Santiapps Marcio Valenzuela
iOS 8 HealthKit

Ok so the Journal view controller was quite simple.  Let’s take another quick break by looking at an even simpler view controller, the FoodPicker:

import Foundation

import UIKit

import HealthKit

class FoodPickerViewController: UITableViewController {

var selectedFoodItem: FoodItem?

let FoodPickerViewControllerTableViewCellIdentifier:NSString = "cell"

let FoodPickerViewControllerUnwindSegueIdentifier:NSString = "FoodPickerViewControllerUnwindSegueIdentifier"

var foodItems: NSArray = NSArray()

var energyFormatter: NSEnergyFormatter {

var energyFormatter: NSEnergyFormatter?

var onceToken: dispatch_once_t = 0

dispatch_once(&onceToken, {

energyFormatter = NSEnergyFormatter()

energyFormatter?.unitStyle = NSFormattingUnitStyle.Long

energyFormatter?.forFoodEnergyUse = true

energyFormatter?.numberFormatter.maximumFractionDigits = 2

})

return energyFormatter!

}

var  healthStore:HKHealthStore?

}

Here we are looking at imports, subclassing UITableViewController and property declarations.

Our first property is selectedFoodItem, which will be set to whatever value the user selects from this tableview as an item that he or she consumed.  Then we have 2 identifiers, one for our tableviewcell and another for our unwind segue.  Remember to set both in the storyboard.  To set the cell identifier you must select the cell in the tableview and for the unwind segue you must select the segue from the “Add” button in Journal to the FoodPicker.  Then we create an array to store the hard coded values of our FoodItems.  Ideally you might want to pull this data from a web service.

Notice we use the NSEnergyFormatter here again.  You could also just create a class for this and access it globally.  Finally we add our health store variable.

Now let’s look at our viewDidLoad method:

override func viewDidLoad() {

super.viewDidLoad()

self.foodItems = [FoodItem(name: "Wheat Bagel", joules:240000.0),

FoodItem(name: "Bran with Raisins", joules:190000.0),

FoodItem(name: "Regular Instant Coffee", joules:1000.0),

FoodItem(name: "Banana", joules:439320.0),

FoodItem(name: "Cranberry Bagel", joules:416000.0),

FoodItem(name: "Oatmeal", joules:150000.0),

FoodItem(name: "Fruits Salad", joules:60000.0),

FoodItem(name: "Fried Sea Bass", joules:200000.0),

FoodItem(name: "Chips", joules:190000.0),

FoodItem(name: "Chicken Taco", joules:170000.0) ]

}

Nothing special here, just hardcoding some FoodItems into our array.  So now our tableview methods:

override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

return self.foodItems.count

}

override func tableView(tableView: UITableView?, cellForRowAtIndexPath indexPath: NSIndexPath?) -> UITableViewCell {

let cell: UITableViewCell = self.tableView.dequeueReusableCellWithIdentifier(FoodPickerViewControllerTableViewCellIdentifier, forIndexPath:indexPath!) as UITableViewCell

var foodItem: FoodItem = self.foodItems[indexPath!.row] as FoodItem

cell.textLabel.text = foodItem.name

cell.detailTextLabel?.text = energyFormatter.stringFromJoules(foodItem.joules)

return cell;

}

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

NSLog("performing unwind segue from FOODPICKER!")

if (segue.identifier == FoodPickerViewControllerUnwindSegueIdentifier) {

var indexPathForSelectedRow: NSIndexPath = self.tableView.indexPathForSelectedRow()!

self.selectedFoodItem = self.foodItems[indexPathForSelectedRow.row] as? FoodItem

}

}

There, now that’s a nice breather.   We set our rows according to the number of items in the array, set our cell values in the same way we did before.  And in our prepareForSegue method, we check our identifier and then set our own selectedFoodItem property from whatever the user selected.

Ok so you’ve had 2 easy classes to rest.  Now let’s get into the longest one.

Advertisements

Swift Closures Quick Reference: Part 2

Let’s analyze some useful applications of closures in everyday code!

Ok so let’s take a look at a real life function that uses a closure.  A typical closure is a completion handler.  A completion handler is a parameter, just like any other, that is passed into a function as a closure.  When that code gets executed, the completion handler gets filled.  Then your function will use the value of that completion handler to do something useful.

Here are some typical uses of closures in API’s.  The typical one is UIView.animateWithDuration.  Open Xcode and start writing UIView.anim… and it will autocomplete for you with this:

UIView.animateWithDuration(<duration: NSTimeInterval>, animations: <() -> Void() -> Void>)

This is telling you that the animateWithDuration takes 2 parameters:

duration which is an NSInterval type called duration &

animations which is a closure type which takes void parameters and returns void.  Remember, animations is just another variable we are passing in, so its separated with a comma from duration.

If you hit enter over the duration parameter, you can write in whatever you want.  If you then tab, it moves over to the ()->Void parameter.  Hit enter again.  The closure turns into this format:

{ () -> Void in
<#code#>
}

Where the { } define your closure and you can see the closure takes () and returns -> () as well.  Except that in this case the final () after -> are replaced by the keyword Void.  Then we get our keyword to transition from the ending ->() in a function to our actual function or closure code which will be enclosed in { }.

In the end you might end up with something like this:

UIView.animateWithDuration(1, 
animations: {() in redBox.alpha = 0 }, 
completion:{(Bool) in println("red box has faded out") })

which is interpreted as:

The function animateWithDuration says: “The value for the duration parameter is 1 second.  The value for animation is a closure of block of code enclosed by { }.  Finally the value for completion is also a closure enclosed by a second { }.”

The animation closure says: “I take no parameters and return void and my code is = in = change the redBox’s alpha to 0.

The completion closure says: “I takes a Bool parameter and returns void and my code is = in = print the message.”

So we are passing those 2 blocks of code to be executed into the function as parameters.

It basically translates to this:

UIView.animateWithDuration(duration: NSTimeInterval, 
 animations: (() -> Void)?, 
 completion: ((Bool) -> Void)?)

Where are you can see, 3 parameters out of which 2 are closures.  Both closures return void but the second one takes a Bool.

So what does it mean?  Well, it says:

1. Here is how much the duration is going to last

2. Here is the animation you will perform inside of the { }.  That requires no parameters and returns nothing.

3. Oh and btw, here is another block of code { } but take a Bool and only execute { } if the Bool is true.  The Bool is set to true when the animation passed in has already finished.

Let’s take a quick look at some closures you’ll find in Apple API’s:

1.  This passes in the dispatch queue as parameter 1 and a closure to downloadData as parameter 2.

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), {
self.downloadDataForRegisteredObjects(true, toDelete:false)
})

2.  This function called performBlockAndWait passes in a closure without parameters and with Void and the code to be executed PLUS another function called executeFetchRequest.

CoreDataController.sharedDataController.backgroundManagedObjectContext?.performBlockAndWait({ () -> Void in
var error:NSError?
var results:NSArray
CoreDataController.sharedDataController.backgroundManagedObjectContext?.executeFetchRequest(request, error:&error)
if ((results.lastObject) != nil)   {
date = (results.lastObject as NSArray).valueForKey("updatedAt") as? NSDate
}
}) 

3.  This assigns a function return to a variable.  That function is GET() and it receives a className parameter, a parameters parameter and a success completion block parameter.  That success completion block parameter is a closure that takes an operation and a response and returns void.  It is called when the operation was successful and writes the operation’s response to disk. If the operation fails, it logs the error.

var operation: AFHTTPRequestOperation = self.GET("classes/\(className)", parameters: parameters, success: { (operation, response) -> Void in
// success code...
if response.isKindOfClass(NSDictionary) {
self.writeJSONResponse(response, className:className as NSString)
}
}, failure: { (operation, error) -> Void in
// failure code...
NSLog("Request for class %@ failed with error: \(className), \(error)")
}) 

4.  This assigns the function result to a variable as well.  It calls the batchOfRequestOperations method and passes it an operationsArray and a progressBlock and a completion block but in this case you can’t see the “completion” name of that last parameter.  Sometimes when you start writing out a function name and it takes a closure as a parameter and its the last one, you don’t have to name it? Why?

var batchOperations: NSArray = AFURLConnectionOperation.batchOfRequestOperations(operationsArray,
          progressBlock: { (finishedOps:UInt, totalOps:UInt) -> Void in
                    NSLog("%lu of %lu complete", finishedOps, totalOps)
})  { (op) -> Void in
                    if (!toDelete) {
                              self.processJSONDataRecordsIntoCoreData()
                    } else {
                             self.processJSONDataRecordsForDeletion()
                   }
}

I guess its because it’s the last parameter in the method call.

Next we take a look at writing our own closures.

Swift Closures Quick Reference: Part 1

Blocks/Closures are confusing!  They’re confusing because its a bit abstract.  Most tutorials cover how a block is declared and used.

Sometimes blocks or closures can me even more confusing…

A block is a bunch of code wrapped up in a {}.

You can 2 either of 2 things with them:

A.  You can assign that block of code to a variable. (this is where completionHandlers, also a confusing concept, fit in)

B.  You can use that block of code directly

Let’s take a look at assigning it to something.  No doubt you have seen a construct like:

var someName = “Mars”

or

var hisAge = 39

This would be considered hardcoding that value to the variable.

Now surely you have seen a function that does something more practical such as calculate or do something in order to return a value.  In the case of someName, well, we could fetch it from a list of users in a web service database.  In the case of hisAge we could calculate it.  Either process would occur in a function.  So we could instead of hardcoding a value, say:

var someName = getHisName()

or

var hisAge = getHisAge()

Well what we are doing here is actually ‘passing a block of code’ to a variable already.  Sorta.  We could somehow imagine that:

var hisAge = getHisAge() { //all the code inside getHisAge function }

which translates to:

var hisAge = { //all the code inside getHisAge function }

Ok, so that’s more or less what a block or closure is.

Where it gets weird, or complicated but just because of the way it looks is when they are passed to functions. You could go ahead and say something like:

func thisIsSomeFunction () -> () { //code }

which is a function that doesn’t take parameters and returns nothing.  Let’s give it a parameter:

func thisIsSomeFunction (aParameter:pType) -> () { //code }

This takes aParameter of pType.  Now replace that parameter with hisAge:

func thisIsSomeFunction (hisAge) -> () { //code}

Now let’s replace hisAge for what it stands for (which is { //all the code inside getHisAge function } )

func thisIsSomeFunction (  () -> () ) -> () { //code}

where () -> () stands for whatever hisAge is equal to, which is the getHisAge function…

Of course the getHisAge function must at least return something, an age, which would typically be an Int:

func thisIsSomeFunction (  () -> (Int) ) -> () { //code }

It would be wise to calculate someone’s age using at least his date of birth, so:

func thisIsSomeFunction (  (NSDate) -> (Int) ) -> () { //code }

Ok so our getHisAge function is in blue and it is passed into this new function.  Now it would be nice to pass in the original getHisAge code which would fit somewhere in here:

func thisIsSomeFunction (  (NSDate) -> (Int) {//getHisAge code} ) -> () { //code }

So for this purpose we have the keyword “in”:

func thisIsSomeFunction (  (NSDate) -> (Int) in {//getHisAge code} ) -> () { //code }

Hope you enjoyed it.  See you in the next part!

Swift is Confusing: Classes, Structures, Designated Initializers, Instance Methods, Type Methods, Functions, Methods, Convenience Initializers & External Parameter Names

Swift is Confusing: Classes, Structures, Designated Initializers, Instance Methods, Type Methods, Functions, Methods, Convenience Initializers & External Parameter Names
Swift is Confusing

Class vs Structs

Both: Store values, initialize, subscripts, extensible & protocol

Class can inherit, de-initialize, reference counting & typecast

Functions vs Methods

Methods are FUNCTIONS INSIDE A CLASS

Functions can be inside or OUTSIDE A CLASS!

Cannot use functionName(param1,param2) to call a function declared inside a class {}

Methods:

  1. It is implicitly passed the object for which it was called
  2. It is able to operate on data that is contained within the class

Instance Methods vs Type Methods (Instance Method vs Class Methods I think)

Methods are functions that are associated with a particular type. Classes, structures, and enumerations can all define instance methods, which encapsulate specific tasks and functionality for working with an instance of a given type. Classes, structures, and enumerations can also define type methods, which are associated with the type itself. Type methods are similar to class methods in Objective-C.

  • class Counter {
  • var count = 0
  • func increment() {
  • count++
  • }
  • }
  • let counter = Counter()
  • counter.increment()

vs

  • class SomeClass {
  • class func someTypeMethod() {
  • // type method implementation goes here
  • }
  • }
  • SomeClass.someTypeMethod()

Class Factory vs Initializer

This is not particular to Swift but may come up in searches.  A Class Factory method is what was know in ObjC as factory methods and I even saw them references as convenience methods or constructors.  These are instead of:

NSArray *someArray = [[NSArray alloc] init]];

they would be:

NSArray *someArray = [NSArray arrayWithObjects:@”One”, @”Two”];

Another example:

  • UITableView *myTableView = [[UITableView alloc] initWithFrame:CGRectZero style:UITableViewStyleGrouped];
  • let myTableView: UITableView = UITableView(frame: CGRectZero, style: .Grouped)

ObjC class or factory methods get mapped as convenience initializers in Swift.  So:

  • UIColor *color = [UIColor colorWithRed:0.5 green:0.0 blue:0.5 alpha:1.0];

gets translated into this:

  • let color = UIColor(red: 0.5, green: 0.0, blue: 0.5, alpha: 1.0)

Designated Initializer vs Convenience Initializer

A designated initializer calls its superclass’ init and defines all values added by the self class.  Unless explicitly provided, a class inherits a super initializer from its superclass.

Any other convenience initializer calls self.init and have the convenience keyword before the init keyword.

Initialization must be done in order; own properties, super, super properties.

Initializers & Optionals in one 🙂

  • class SurveyQuestion {
  • let text: String
  • var response: String?
  • init(text: String) {
  • self.text = text
  • }
  • func ask() {
  • println(text)
  • }
  • }
  • let beetsQuestion = SurveyQuestion(text: "How about beets?")
  • beetsQuestion.ask()
  • // prints "How about beets?"
  • beetsQuestion.response = "I also like beets. (But not with cheese.)"

Default Initializers

  • class ShoppingListItem {
  • var name: String?
  • var quantity = 1
  • var purchased = false
  • }
  • var item = ShoppingListItem()

All non-optional values are supplied with a default value and it is a Base Class (because it doesn’t have a super class)

Diagram:

class A {
    var x: Int
    convenience init() {
        self.init(x: 0)
    }
    init(x: Int) {
        self.x = x
    }
}

where init(x:Int) is the designated initializer and any other must have the convenience keyword.

class B: A {
    var y: Int
    convenience init() {
        self.init(y: 0)
    }
    convenience init(y: Int) {
        self.init(x: 0, y: y)
    }
    init(x: Int, y: Int) {
        self.y = y
        super.init(x: x)
    }
}

Parameter Names / Externals / The first

//Default: First Parameter is the local parameter (don't need to specify it), the rest are external parameters
    func greet (name: String, day: String) -> String {
        return "Hello \(name), today is \(day)."
    }
greet("John", day:"Monday")
    //Use Hash symbol to make the First parameter as external parameter
    func greet2 (#name: String, day: String) -> String {
        return "Hello \(name), today is \(day)."
    }
greet(name:"John", day:"Monday")
Swift Optionals Quick Reference for Newbies by Santiapps.com

Swift Optionals Quick Reference

Swift Optionals Quick Reference for Newbies by Santiapps.com
Swift Optionals Quick Reference for Newbies by Santiapps.com

Optionals confuse me so I wrote this post and hope it can be of some help.

OPTIONALS

Takeaway #1: Optionals are used to declare a variable but are not assigned a value at start

Takeaway #2: Optionals contain a Some or None value, they DONT contain a String or Array or whatever else.

Takeaway #3: Therefore we MUST unwrap the value of an Optional to see what the prize is 🙂 In other words, to access its value!

Takeaway #4: DECLARATION OPTIONS

A) Using the following syntax: var someVar? – You will mostly use this…

B) Using “var someVar!” <Implicitly unwrapped> – Unfortunately UIKit & other Apple frameworks will use a lot of these…

… NEED TO EXPLORE THE DIFFERENCE BETWEEN ? and ! declarations…

Turns out you can declare a variable as an implicitly unwrapped optional if you know it will, at some point, be non-nil.  So for example, in this SO post (http://stackoverflow.com/questions/24006975/why-create-implicitly-unwrapped-optionals) they talk about have viewDidLoad in a view controller call a setter upon load:

var screenSize: CGSize?

override func viewDidLoad() {

super.viewDidLoad()

screenSize = view.frame.size

}

We know that screenSize will be filled because viewDidLoad WILL be called.  Then later we do:

@IBAction printSize(sender: UIButton) {

println(“Screen size is: \(screenSize!)”)

}

We know screenSize will have a value if its ever called.  So we can instead declare it as an implicitly unwrapped optional with a ! instead of a ? in the initial var declaration.  But don’t sweat this so much right now.

Takeaway #5: ACCESS (UNWRAPPING) OPTIONS 

Takeaway #6: Method 1: Traditional (Risky): if var != nil and then access it inside the if block.

if yourOptionalTypeOrOptionalReturningFunction != nil {

doSomethingWith(tempOptional!) || setSomeValue = tempOptional!

}

But to access it you have to unwrap the present 🙂  To do this you use the bang operator !  Whenever you use the ! you are ‘force unwrapping’ a variable, which means it will open it no matter what.  If nil is in there…KABOOM!  Bye bye Moose & Squirrel!  So you better have checked before hand.

Takeaway #7: Method 2: Optional Binding (aka:”if-let nil check”) (Safer): This means you use:

if let tempOptional = yourOptionalTypeOrOptionalReturningFunction {

doSomethingWith(tempOptional) || setSomeValue = tempOptional

}

This is more safe because it checks first or peeks in the box so to speak.  Thus you can use the variable without unwrapping.

< If you remove default value from a ? and have a ! to access it in code, your code will fail if-check will go to else.>

Takeaway #7: Method 3: Implicitly Unwrap: Uses ! operator (assumes var contains some value). But remember from Method 1, if nil, KABOOM!!!!!!

<If you remove default value from a ? and have a ! to access it in code, you get runtime crash = error = “can’t unwrap optional.None”>

Takeaway #8: Optionals unwrapped using? – This one is still kinda confusing to me. Has to do with optional chaining and inline downcast syntax I believe.  It means that when you have many optionals.  Let’s assume you have a class with 2 optional variables, name? and price?  Let’s pretend you write a function that creates a new Stock() class object and must therefore set name & price variables for it.  We would first have to check if one is set and then the other:

if let someName = stock.name {

if let somePrice = stock.price {

//now we can do something with price…

}

}

This would get messy.  So we chain them into a single statement like so:

someVariableWeWantToSet = stockName?.stockPrice

Takeaway #10: Many ObjC framework objects are optionals? and many are implicitly unwrapped! when passed into functions because they will start out as nil (UILabels, MKAnnotationViews or MKPolylines) but we know they will eventually get filled in because that’s why we put them there in the first place:

MKAnnotationView!

MKAnnotation!

UIControl!

MKPinAnnotationView!

MKMapView!

Takeaway #11: When we have something like an MKAnnotation! is received in a function as annotation. If we wish to use its super class properties, we must be inline downcast to while if-let checking. Once inside we can implicitly (force) unwrap MKPinAnnotationView! because we know since the annotation exists, it will have a view. For example, in this method:

func mapView(mapView: MKMapView!, rendererForOverlay overlay: MKOverlay!) -> MKOverlayRenderer! {

if let polylineOverlay = overlay as? MKPolyline {

let renderer = MKPolylineRenderer(polyline: polylineOverlay) renderer.strokeColor = UIColor.blueColor()

return renderer

}

return nil

}

We can interpret that funky as? as follows: “If when I get the variable overlay and unwrap it, it downcasts successfully to a MKPolyline && I get a value (not-nil) then put it into polylineOverlay & continue…” Hope this helps…

Why, oh Why, did Apple take away ARC just to give us Optionals!?

I’m having trouble understanding optionals so here is a shot at explaining them. 🙂

var thisIsAnInt: Int

Simple, this is an Int variable declaration.

var couldBeAnInt: Int?

This on the other hand is an optional variable declaration.

This optional declaration doesn’t mean: “this is an int, which is optional”.

It reads more like: This is an OPTIONAL variable.  It’s a type of variable in and of itself.  Its NOT NECESSARILY an Int.  It just may or may NOT contain an Int”.

Woah!

Ok so what is it for and when do you use it.  Well that part seems simple enough:

If that variable can or could or may be nil at some point, it’s an optional.

If the variable will always have a value, it will never be nil, its NOT an optional.

Don’t be misled by this simplicity.  Some variables can start out as nil and receive a value at some point.  What then?

Well it turns out there is a sort of table, if you will:

  1. Can NEVER be nil (or if it IS, its a bug) = non-optional variable….you know, the regular kind
  2. Starts out nil but NEVER ends up nil after init (or if it is, its a bug) = implicitly unwrapped optional
  3. Nil value has meaning and is expected (if it is, its NOT a bug) = optional

Yeah, thanks for confusing me :S

Here is another way around it:

var perhapsInt: Int? //this is perhaps an Int
perhapsInt = 1 //here we assign it an int
if perhapsInt != nil { //now we check to see if its nil before using it
     let intString = String(perhapsInt!) //IF it isn't, then we can access it by using !
     println(intString)
}

you can also check for that in a different way:

var perhapsInt:Int?
perhapsInt = 1 
if let actualInt = perhapsInt {
     println(actualInt)
}

Here is the kicker:

var perhapsInt: Int?
let definiteInt = perhapsInt ?? 2
println(definiteInt) // prints 2
perhapsInt = 3
let anotherInt = perhapsInt ?? 4
println (anotherInt) // prints 3

And it gets trickier what with ?? and variable != nil.  So let’s throw everything out the window and start anew.  Let’s define a function we might actually be interested in:

Assume we have an array of locations:

let errorCodes = ["100","200","300","400", "500"]
func findErrorCode (code : String, errorCodes: [String])-> String {
for tempCode in errorCodes {
     if ( tempCode == code) {
     return code
     }
}
return ""
}

This is a function we wrote to find a particular code inside an array of possible error codes.  We call it by passing it in a code and the array of possible codes.  If we pass it a code that is NOT in the array, let’s say “700”, then the “internal if” will not evaluate to true and we must return nil.  We must return nil because otherwise, because the function is meant to return a String (the name of the matched code) && that “if block” didn’t hold true, you get a compiler error because we are not being exhaustive.  This means, if we pass the function a value that IS in the array, great, we will get a ‘return code’.  However, if we pass it a value that is NOT in the array, the function would not be returning anything.  So we NEED to return something for it to work.

We could return an emply value but consider the following.  Let’s say we wish to display that code returned in the console, via println (or plot it on a map of servers for example).  The point being that we need to do something with the returned code:

if findCode("700", errorCodes) {
	plotOnMap()
}

So how do we account for such a possibility?  We need to define the return value of the function findCode as an optional.  To do this we add this to the variable “?”.  Here is what the function would look like:

func findCode (code : String, errorCodes: [String])-> String? {
for tempCode in errorCodes {
     if ( tempCode == code) {
          return code
     }
}
return nil
}

Now we can actually return a String value, maybe, or we could be returning an Optional value.

Great, now let’s asume the plot function looks like this:

func plotOnMap (code: Int) -> () {
     println("This line of code magically plots the code on a server map :)")
}

Ok so now we can say

let receiver = findCode("200",errorCodes)
if receiver {
	plotOnMap(receiver);
}

The issue is that the value returned by findCode, is Optional.  So the value of receiver will be optional.

This is what is called “implicitly defined optional“.  We have implicitly defined receiver to be an optional because the return of the function is an optional itself.

We also have another issue, plotOnMap() takes an Int, not a String.  So we have actually defined receiver as:

let receiver: String? = findCode("400",errorCodes) // inferred type String?

Notice we have defined it as String?, not String.  This means receiver can hold a String or a nil, because its being defined as an Optional type, not a String type.

So what can we do?  We can ask it for a value only if it HAS one:

let receiver = findCode("400",errorCodes) 
if receiver {
	plotOnMap(receiver!) // We use of the ! operator to unwrap the value to String
}

This would indeed fix the problem.  You have solved the possibility of an optional in a function you wrote yourself.  But there is always the other case, values returned by functions you DIDNT write!  Ugh!  Remember I mentioned that our plotOnMap() takes an Int, and not a String?  And we are in fact unwrapping an implicitly defined variable (called receiver) into a String (cause that’s what the function returns?  Well we need to convert it into an int, which is simple in Swift, just say string.toInt().  This means we have to do this:

if let receiver = findCode("400",errorCodes) {
	plotOnMap(receiver.toInt())
}

But if you jump to definition on toInt(), you will notice that it also returns an optional.  So we would need to do something more convoluted:

if let receiver = findCode("400",errorCodes) {
	if let receiverErrorCode = receiver.toInt() {
		plotOnMap(receiverErrorCode)
	}
}

which is quite confusing.  So there is a Swift syntax which let’s you condense this into:

if let receiverErrorCode = findCode("400",errorCodes)?.toInt() {
	plotOnMap(receiverErrorCode)
}

It would be prudent just to add an else to the if to be safe 🙂

iOS : Swift : Blocks = Closures

Closure on closures
Closure on closures

I’ve never really liked blocks in ObjC.

When Swift came out it made things more complicated for me because I’ve never really liked C either.

Finally when I had to deal with closures in Swift, well that’s just gonna piss a lot of people off!

After a few days reviewing tons of material online, and I mean TONS!  I came to understand this:

The only C-like exposure I had prior to ObjC was a little PHP.  So that allows me to understand a function, which is the equivalent of a method in ObjC:

DECLARING

func sayHello( ) {

     println(“Hello World”)

}

CALLING

sayHello( )

RESULT

Hello World

Even if you didn’t have any exposure to C or PHP or some other “not-so-friendly” language as ObjC, you can surely understand that

  1. The function is called sayHello
  2. That it takes no input-parameters because the ( ) is empty
  3. That it has no return type because it returns nothing since its missing the keyword “return” inside of it 🙂
  4. And that all it does, instead of returning a value, is print out Hello World

Just to clarify, let’s look at a function with a return value:

DECLARING

func sayHello () -> String {

    var result = “Hello World”

    return result

}

CALLING

var whoAreYou = sayHello()

RESULT (value of whoAreYou)

Hello World

As you can see here, we actually return a value from this function, which we can assign to a variable.  I had to assign it to a variable so that it made sense to actually return a value from a function.  

So we added an output-value to an otherwise plain vanilla function.  Now lets go for the next kind of function, plain + output + input:

DECLARING

func sayHello (friendOne:String) -> String {

    println(“Hi \(friendOne)”)

    var result = “Hello, ” + friendOne

    return result

}

CALLING

var whoAreYou = sayHello(“Marcio”)

RESULT (value of whoAreYou)

Hello, Marcio

Great!  So you’ve got functions covered:

  • Plain void functions
  • Returning output-value functions
  • Input-Paramter, returning output-value functions

CLOSURES (or blocks from ObjC)

There really is no simple way to explain it in a few words.  But the first thing that stands out from a closure or block, is that IT IS a function, yes!  But it can be passed around like a variable.  So let’s take a look:

var someVariable: String

There, we just declared a variable of type string.  Let’s declare another variable:

var someOtherVariable: ( ) -> ( ) = { }

There, we have just declared another variable, of type…? :s

Simply combine the concepts:

variable = function

And we know that a function is:

function = functionName (input-parameter) -> (Output-value) {some code}

So now say:

variable = function = functionName (input-parameter) -> (Output-value) {some code}

Now drop the middle “function” 🙂

variable = functionName (input-parameter) -> (Output-value) {some code}

If you don’t want the function to have a name, because you are assigning it to a variable anyway, so you can just call it by calling the variable:

variable = (input-parameter) -> (Output-value) {some code}

Hey, that looks a lot like what we had above:

var someOtherVariable: ( ) -> ( ) = { }

Cool!  So what does it all mean Basil?

The important thing is that you will use closures in Swift.  I was working with Parse SDK the other day and I ran into this in Xcode:

Get closure on Closures
Get closure on Closures

This is the first stage of Autocomplete which you may already be familiar with.  It’s telling you this:

Void saveInBackgroundWithBlock(block: PFBooleanResultBlock!(Bool, NSError!) -> Void)

You already know what this means, its just a function/method that takes a block as a parameter.  

This function returns Void, according to the left Void in that line.  

Let’s say that the method is called saveInBackgroundWithBlock ( X ) and it takes 1 parameter, X, where X is a block.

The block is defined as a variable “block:” and its called PFBooleanResultBlock!

It has 2 output-values Bool & NSError.

Now you know how to fill it in.  But wait, there’s more…if you call in the next 15 minutes 🙂

But seriously, Xcode now has something new.  Check it out!  To select that method in the image above, you hit Enter.  This spits out the method signature in the Editor window and expects you to fill in the rest…THE NERVE!  Luckily, you can hit Enter again while that blue selection is highlighting the block and that will give you this:

tah dah!

Get closure on Closures
Get closure on Closures

Now that’s better!  This is Xcode’s new second stage Autocomplete.  Its telling us that the block is defined by { } and it takes 2 input-parameters and returns a Void.  That new “in” keyword serves to separate the return (which is in this case, Void) from the actual code block which follows.

So you can call closures like so:

object.saveInBackgroundWithBlock {succeeded, error in

//some code

}

OR

object.saveInBackgroundWithBlock { (succeeded, error) -> Void in

//some code

}

 OR

object.saveInBackgroundWithBlock( { (succeeded:Bool, error:NSError!) in

//some code

})

OR

object.saveInBackground( { (succeeded:Bool, error:NSError! ) -> Void in } )

OR you can assign it:

var someVar: () -> () = {              

println(“Hello World”)

}

Enjoy!

 

EDIT: In brief:

How to write or declare closures:

{ (succeeded: Bool, error: NSError?) -> Void in /* code */ }
{ (succeeded: Bool, error: NSError?) in /* code */ }
{ (succeeded, error) in /* code */ }
{ succeeded, error in /* code */ }
{ /* code using $0 for succeeded and $1 for error */ }

How to pass a closure:

object.saveInBackgroundWithBlock({ /* closure */ })
object.saveInBackgroundWithBlock() { /* closure */ }   // Only if closure is last arg
object.saveInBackgroundWithBlock { /* closure */ }     // Only if closure is only arg

Swift Tutorial II

Ok so in the first tutorial we covered let, which is the keyword for defining constants.

let thisBeAConstant = 3.141

Now we are going to cover variables, which use the var keyword like so:

var thisVariable = time

Notice 2 things about Swift:

1) We don’t use ; at the end of a line.  That’s just weird 🙂

2) We don’t have to specify the type.  The type is inferred by whatever value you pass in, so:

var someString = “this is a string”

var someInteger = 5

So Swift is kinda smart.  Now let’s meet some old friends “Hao jiu bu juan”

ARRAYS

var energies = [“solar”“wind”“fossil”, “this is a mixed array”, 39]

var energies:String[] = [“solar”“wind”“this is a string array”]

And of course we can perform some basic operations such as:

READ

var item1 = energies[0]   // “solar”

INSERT

energies.insert(“hydro”, atIndex: 2)

MODIFY

energies[3] = “geothermal”

APPEND

energies.append(“nuclear”)

or

energies += “nuclear”

COMBINE

energies += [“biomass”“hamster”]

COUNT

var lengthofArray = energies.count

LOGIC

var arrayIsEmpty = energies.isEmpty

REMOVE

energies.removeAtIndex(3)
energies.removeLast()
energies.removeAll(keepCapacity: true)
MUTATE
If we used let energies, then our array is immutable, vs if we used var energies which means its mutable.
Easy as pie.
DICTIONARIES

var energies = [

    “Solar”“Thermal”,
    “Photovoltaic” : “Grid”,
    “Nuclear” : “Dangerous”
]
Here our keys are Solar, Photovoltaic & Nuclear.  These keys can be strings or numeric values such as integers.
Once again we can:
READ
let cheapestSolarEnergy = energies[“Solar”]
COUNT
var energiesCount = energies.count
MODIFY
energies[“Solar”] = “PV”
REMOVE
energies[“Nuclear”] = nil;
INSERT
energies[“Geo”] = “Thermal”
and of course the value of a key can be an array or another dictionary:

var typesOfEnergy =

[
    platforms[“Solar”]: [“Thermal”“PV”“GridTied”],
    platforms[“Wind”]: [“Autonomous”“GridTied”],
    platforms[“Nuclear”] : [“Fusion”“Fission”,“Meltdown”]
]
and we would read it:
var type1 = typesOfEnergy[“Solar”][0]
See you next time! 🙂