2014s408 Swift Playgrounds

 >> Hi.

 Welcome to Swift Playgrounds.

  I'm Rick Ballard and with me today is my colleague  Connor Wakamo.

  We're both Engineers in the Xcode Team  and we've been working hard to bring Playgrounds to life.

  We introduced Playgrounds to the world Monday morning  and you saw a little bit more  about them Monday afternoon and yesterday.

  Well, today we're going to go into a lot more depth.

  We're going to start out today with some conceptual background,  what Playgrounds actually are and what you can use them for.

  And then we'll show you examples of how to use Playgrounds  for learning, exploration, and visualization  of the results of your code.

  We'll show you how you can use your own custom resources  with your Playgrounds, and how to use Playgrounds  for algorithm development and development  of other separable pieces of code.

  We'll introduce the XCPlayground framework  which includes some really powerful utilities  that you can use to enhance your Playgrounds.

  And we'll show you how you can develop your own Custom Quick  Looks, so that you can visualize your own classes the same way  you visualize the classes that come with the frameworks.

  Next, we'll show you a great demo  of how awesome Playgrounds are for developing custom views  and in any other kind of custom drawing  and we'll show you how you can use your own asynchronous code  with Playgrounds.

  Finally, we'll finish up today with a little bit  about the limitations that Playgrounds have today.

  So what exactly are Playgrounds?  Playgrounds are a new type of document introduced in Xcode   and they're actually a file wrapper containing a few  useful things.

  First of all is your Swift code.

  The code that would be run and the result are,  and generate results to display automatically every time you  edit your Playground file.

  Swift Playgrounds also can contain a folder  of embedded resources which are made available to your code  or your Playground can reference resources elsewhere  on your system you want to make available.

  Finally, your Playground can contain a timeline full  of timeline items that provide useful visualization  of your results beyond what you see in the sidebar.

  When you first open a Playground,  we show the Playground Editor with your Swift code on the left  and the results sidebar on the right showing the result  of every expression in your code.

  Every time you edit your source, we rerun your Playground source  from the top to the bottom and present the new results  from that run in the sidebar.

  This is the basic editor mode.

  But if you go into the assistant editor mode we'll show the  Timeline Assistant by default which allows you  to visualize your results in more detail.

  For example, you can display the value history  from a line in your code.

  In this case, since it's a numeric value,  we'll draw a graph of that value over time  since it was iterated multiple times in a loop.

  If you're looking for console output like that from Print Man,  you'll also find that in the Timeline Assistant.

  There are a couple other useful things you,  I want to call out here.

  In the lower right hand corner, there's a time-stepper.

  And this controls how long your Playground will continue to run  after the top of a source is finished  if you're using live views or indefinite execution.

  And I'll explain what both of those are a little later on.

  There's also a slider which allows you to go back in time  and view results in the timeline from a specific point  in your Playground execution.

  So here, you can see we're viewing a numeric result  from partway through the Playground execution.

  But you'll find this is very useful with live views  as it allows you to scrub back through the recording  of that view and see exactly what your animation was doing  at a specific point in time.

  So that's what Playgrounds are.

  Let's talk a little bit about what you can use them for.

  We think your first great use  of Playgrounds is going to be learning.

  We've introduced a brand new language for you to learn  and we think the best way to get started is just to open  up a Playground and dive in and play around.

  Our documentation also includes a special interactive Playground  called the Swift Tour.

  This allows you to see documentation  and Playground Editor side by side in the same editor.

  So you can read about how to do something and try it  out right there without leaving the editor.

  Finally, we think Playgrounds are a fantastic way for people  to learn how to program in the first place.

  Beginners don't have to learn how to configure a project  and target and build and run and debug.

  They can just type code into a Playground Editor  and immediately see the results.

  So if you know anyone who wants to learn how to program,  we encourage you to suggest trying it in a Playground.

  We think Playgrounds are also going to be  in indispensable tool in your toolbox  for everyday code development.

  If you're developing an algorithm  or any other separable chunk of code,  you should consider starting it on a Playground,  working on it there until you have it how you want it,  and then dragging that code into your project  for use in your application.

  Any sort of drawing code you want to do is also great  in a Playground because you can immediately see the visual  result of what your code is doing.

  And every time you change your code,  you can immediately see how that affects the visual result.

  Finally, processing code like value transformers or a sequence  of image filters are great in Playgrounds  because you can visualize the result at every step  of the transformation process.

  And when you change something, you can see how  that change ripples through all your results.

  We think you'll find  that Playgrounds are fertile ground for experimentation.

  And in particular, any time you're trying  to learn some new API, you should try it  out on a Playground because you can immediately see how it works  and what results it gives you.

  You don't need a project, you don't need to build and run.

  You just open up even a standalone Playground document,  type in your code, and see what happens.

  I'm sure all of you have many a time gone  to create a new project from the application template,  and gone to find applicationDidFinishLaunching,  just to put a line of code and to try some API.

  Oh, and then you probably have to NSLog it too  so you can see what happened.

  You don't have to do that anymore.

  Now you can just open up a Playground and try  out the API you want to try.

  In fact, we'd recommend you consider keeping a Playground  in your doc at all times for quick access.

  So anytime you want  to try something it's right there at your fingertips.

  So with all that said, let's dive in and take a look  in an actual Playground.

  To do that, I'm going to invite my colleague Connor up on stage.

  >> Thank you, Rick.

  Hello everyone.

  My name is Connor.

  I'm an Engineer on the Xcode Team.

  And today I'll be talking to you about how you can work  with Playgrounds as well as some of the things  which we think Playgrounds will be really great for.

  Now, Rick has already covered many  of the basic concepts behind Playgrounds.

  And so I think really the best way to show you how to work  with Playgrounds is actually just  by jumping straight into a demo.

  So, let's go ahead and do that.

  So here I am at the demo machine and I'm just going  to go ahead and launch Xcode.

  Now you'll notice here that on the Welcome window  for Xcode we've added this brand new "Get started  with a Playground" button.

  It's that way we want to make it really easy for you  to just get started with one.

  So I'll just click on that.

  We'll create a Playground and I'll just give it a name  and a place to save it.

  So "MyPlayground" is fine and putting  on the desktop is fine as well.

  So let's say create, and then we have here our Playground itself.

  So, you notice that we're importing Cocoa,  so we have full access to the Cocoa APIs.

  And then we are also creating a string  and we're assigning the value, "Hello,  Playground" to that string.

  You'll notice that in the result sidebar we're seeing the result  of that.

  So in this case we're seeing the string, "Hello, Playground".

  So OK.

 So that's kind of the basic idea.

  Let's try something with numbers.

  So let's say, for i in 0 to 10, let's just say, i times i.

  You see there that we execute the code  and we're getting an indicator in the result sidebar  that we've executed that code 10 times.

  So, OK, let's try bumping that up to 100.

  We'll let it run and we'll see there  that we immediately get an indication  that this code has executed 100 times.

  Now, knowing that is very useful information  but sometimes you actually want to see the value there.

  And we have support for that as well.

  So OK, I'll just hover over this result, and you'll see  that we're highlighting the line of code  with which it is associated.

  And we're also showing this button here.

  That's called the Value History button.

  And if I go ahead and click on it,  we'll open up the assistant editor into the timeline mode.

  This is the place where you can see results over time as well  as a place for you to store results which you  like to see persistently.

  So in this case, we're showing the graph for i times i.

  And we've seen this, you know, this nice little curve here.

  So OK, so that's kind of the basics of using the timeline  and calculating numbers.

  Let's try something a little bit more interesting.

  Let's go ahead and do something with AppKit.

  So let's first start up by creating a color.

  So you let color equals NSColor.

blueColor.

  You'll see there that we're now showing  in the result sidebar a color swatch indicating what the color  is as well as indicators of all of the components  which make up that color.

  So I can, you know, take this color  and let's create another attributed string using it.

  So let's say, let attrStr equals NSAttributedString.

  And we'll pass it in the string in an attributes dictionary.

  So we'll use the string we already have  and we'll create a dictionary.

  So we'll say NSForegroundColorAttributeName  and we'll pass it the color we have.

  And then I'll say, NSFontAttributeName,  I'll just pass it a font.

  So I'll say, NSFont, systemFontOfSize  and then let's go to something fairly big, so I'll just put  in 42, see what that looks like.

  So, OK.

 So here, you notice  that we're getting a result for this as well.

  You're seeing that we're showing the plain text representation  of this, as well as an icon indicating  that it is an attributed string.

  Now, that's great.

  You know, we know that this code is executed.

  But I really want to see what the actual value is there.

  See how the attributed string looks itself  and we support that as well.

  So I can just hover over the result and in addition  to the Value History button,  you'll see that we have a Quick Look button.

  And so if I go ahead and click on that we'll show a Quick Look  of that value to show you the full representation of it  as it was created in the Playground source.

  So, OK, that's colors and strings.

  Let's try something with images.

  Let's actually start  up by creating an array of image names.

  So I'll say, let imageNames equals,  we'll put in an array there and, I know it's something to do  with like NSImageNameUser or accounts  or something in that line.

  So I'm just going to create an array with imageNames  that I think it could be, the ImageNameUser,  NameUserAccounts, NSImageNameUserGroup.

  It's OK.

 We run the code and you notice  that we now have an array of strings.

  We actually want to see an array of images  and that's very easy to do.

  I can just say something like,  let images equals imageNames.

map.

  I'll pass it a trailing closure to just say, NSImage named,  pass it the positional argument $0.

  And you'll notice there that we're now seeing that this line  of code executed 4 times.

  And so, basically we can see that,  you know, OK, that makes sense.

  We're executing this line of code 3 times  for the trailing closure itself.

  Then we're executing it once for the assignment to images.

  Actually, I only want to see the images array itself  and we have a nice little trick for doing that in a Playground.

  You just go ahead and put the thing that you want  to see on a line by itself.

  So there you see, you know, we've put images there,  we rerun the code, and we're seeing the images array.

  I can Quick Look that and I can see, "Oh, you know,  here's the image that I'm looking for.

"  And so, I'll just get that image and say,  let image equals images at 0.

  We'll rerun it.

  I'll Quick Look to make sure it's OK and in fact, yeah,  that's the one that I'm looking for.

  Let's go ahead and put this into an image view.

  So I'll say, let imageView equal NSImageView.

  We'll pass our self a frame, so let's say NSRect.

  We'll say 0 for the origin  because we don't really care about that.

  Then we'll also say by 512 for the size.

  Now I'm going to go ahead and put this ImageView  on its own line as well.

  So I can show this result in the timeline.

  And this is a neat little way of building something up.

  You take the, you start creating the object  and then you put another line where we show it as a result.

  Anyway, I can add some code in between there  to see how it builds up over time.

  So you see here that we're starting  out with just this empty imageView, you know,  we're not seeing any interesting there.

  So let's go ahead add our image to the imageView.

  So let's say, imageView.

image equals image.

  And we'll re-execute and we'll see here now that we're  in fact showing the image there  but it's not filling the full imageView.

  It's not doing what we expect.

  That's because we haven't set up the image scaling appropriately.

  So we'll set that as well.

  Say imageScaling equals ImageScaleProportionally  UpOrDown.

 And we'll re-execute and now you'll see  that we're seeing the image at full size in the imageView.

  We're seeing what we expect.

  And it's OK.

  That's how you can work with system resources.

  But I'm sure you have many resources of your own that you'd  like to use in Playgrounds as well.

  And we support that too.

  So I'm just going to go ahead and I'm going  to show the final inspector.

  It will slide in on the right hand of my Playground.

  And you'll notice here that we're,  we have this new section called Playground Settings  which is shown whenever you're viewing a Playground document.

  You can select the platform  against which the Playground should execute.

  And, you know, OS X is what we're doing right now.

  But we also support iOS.

  And you can select a path for resources.

  This defaults to none but you can select one  if you have resources that you're interested in.

  In this case, I'm just going to say I have a folder of resources  on my desktop so I'm just going to say,  let's use the Absolute Path option.

  I can then go ahead and choose that.

  So let's say here's my resources folder, I'll choose that.

  And then once I made that choice I'm actually going to go ahead  and hide the Utilities area.

  And to access the images themselves, I just use,  you know, NSBundle API, you know, the resources show  up as resources for the main bundle.

  So I can say something like "let myImage equals NSImage, named".

  I have an image in here that's just called  "Xcode" so let's grab that.

  We'll re-execute and you'll notice  that now we're getting the image result here.

  And click, click to confirm that it's what I think it is.

  And in fact, it is, we're seeing the Xcode icon there.

  And now I'm just going to have  that imageView show the Xcode icon instead.

  So, I'll say, "imageView.

image equals myImage".

  We'll re-execute and now you're seeing this new result,  let's add it to the timeline as well.

  So you can see here that we have what we expected.

  The Xcode icon is showing up in our imageView.

  You'll probably also notice  that we're still seeing the older version here  with the user icon in the imageView.

  And that's because Playgrounds actually capture results  on every single line of execution.

  So you can do these kinds of comparisons.

  So like for instance, you know, let's look at the imageView  when we first create it.

  And it's empty.

  Then I added the user icon to there.

  And so, we see that earlier version that we saw  where it's small in the center.

  Then I set the image scaling appropriately  and it's now filling full image view.

  Finally, I updated it to use myImage and we're seeing  that it's showing the Xcode icon.

  And that's great, so that you don't have, you know, go back  and see what happened at a particular point.

  We're capturing the data for you as your Playground executes.

  So I think that about covers the basics, so let's go back  to slides and talk a little bit more about Playgrounds.

  So one of the key ideas that you saw there is  that Playgrounds will automatically execute.

  You just type in some code and you'll see the results  in a sidebar on the right.

  Additionally, you saw that we can add a value history  to the timeline.

  So here we have a line of code which executed 100 times.

  And if I hover over that result,  you'll see this Value History button.

  If I click it, we'll switch into the assistant editor  and we'll show that as a history of that value.

  Additionally, many values in the Playground have Quick Looks.

  All right.

  So in this case we have an attributed string.

  We don't see the full representation of the sidebar,  just kind of the plain text of it.

  But if I click on the Quick Look button,  we'll see the attributed string as it was created  in the Playground source.

  We support many different types  for Quick Looks in the Playground.

  We support colors, strings -- both plain text and attributed.

  We can show images, views,  in this case we'll capture a snapshot of the view  at that point in time.

  We can show arrays and dictionaries  as we'll show a structured version of the array  or dictionary, ah, like you might see  in the variables view on the debugger.

  We can show points, rects, and sizes.

  We'll kind of create a graphical representation of those.

  We can show Bézier paths, so both NSBezierPath on the Mac  and UIBezierPath on iOS.

  We can show URLs, for this we'll take the plain text of the URL  and show it in the sidebar.

  But if you Quick Look, it will show you a web view  with the contents of that URL.

  And finally, for types  if we don't have a native Quick Look representation,  we can usually get a structured view of it, again,  like you would see in the variables view in the debugger.

  So here I have an object of a class  that I created in the Playground.

  And it is, it has a couple of properties,  a foo property and a bar property.

  And you're seeing the values of those at that line  of code when it executed.

  In this demo, I also showed you how you can use your own  resources with Playgrounds.

  And this is actually fairly easy.

  So you just go ahead and show the file inspector.

  You select a location for Playground resources.

  And for this we have three options.

  We've got an Absolute Path option which basically says,  "OK, I've got this folder of resources somewhere  on my computer and I'd like to show it  and use it with the Playground.

"  We have a Relative to Playground path option.

  And this is really great  if you're checking your Playground into SCM.

  Because you can say, "Oh, you know, here's this Playground  and here's this folder of resources that's next to it,  I can set this up and then when you use other people to check  out your repository, then it will automatically be able  to use the Playground with its resources.

"  Finally, we support an Inside Playground option.

  And this is great if you're sharing  in ways other than via SCM.

  Because you can just say, "I want to store my resources  in my Playground" and you can email that out to other people  and see, when they open it, they'll be able  to see those resources immediately.

  Once you have made the selection,  to access these resources in your Playground source,  you just use things like,  NSBundle.

pathForResource ofType and NSImage named.

  The resources just show up as the resources  for the main bundle during Playground execution.

  So, now that we have the basics out of the way,  I think I'd like to start talking to you about some  of the use cases for which Playgrounds would be  really great.

  And the first of these is Experimentation.

  I'm sure that all of you out there have a folder  on your computer which looks something like this.

  It's just a bunch of Xcode projects created  from the template that are, you know, maybe 1 or 2 changes  to see how something works or to test out an idea.

  It's actually isn't that easy of a process.

  You know, you have to do many different --  you have to first choose the right project template then find  the right file in that project to edit which may be easy  or maybe not depending on which template you chose.

  You'd have to do what you're trying to do in the first place,  and that's write some code.

  Once you've written something, you then have  to build your project.

  You then run whatever you built.

  And for iOS that may involve deploying  to a simulator or to a device.

  And if you didn't get it right the first time, you'd then have  to redo this, stop in the debugger and step  through your code to figure out where things are going wrong.

  We think Playgrounds can handle this a whole lot better.

  That's because there's really only 2 steps.

  You would just, say, get started  with a Playground and write your code.

  Once you start writing your code,  we'll automatically execute it for you and show you the results  in the sidebar so you can see where things are going wrong.

  So now, I think I'd like to show you a demo  of what this looks like.

  So let's go back to the demo machine.

  So here I am.

  I'm going to go ahead and just launch Xcode again.

  And this time I'm going to create an iOS-based Playground.

  So I'll say, File, New File, and I'll say, iOS Playground.

  And I want to actually test  out how the UITableViewCell style API works.

  So, I'm just going to call and create this Playground  and call it TestTableViewCell.

  Save it to the desktop, and OK.

  So, here we have our iOS Playground.

  It's, you know, importing UIKit, but otherwise, it's the same,  we're just creating a string and assigning it to a variable.

  So, if I want to use a UITableViewCell style,  I need a UITableViewCell.

  And the best way to show that is with a UITableView.

  In order to get those cells  into my UITableView, I need a data source.

  So, let's just go ahead and implement a data source.

  So I'll say "class DataSource".

  We'll inherit from NSObject and we'll conform  to the UITableViewDataSource protocol.

  Notice now that we're getting an issue here and that's  because the DataSource we've created does not actually  conform to UITableViewDataSource.

  And, you know, that's expected.

  We haven't actually implemented any methods yet.

  So, I'm actually going to jump to the declaration  of UITableViewDataSource by command-option-clicking on it.

  We see that we then open the assistant editor.

  And instead of showing you UITableView.

h,  we're going to show you a Swift version of that header.

  So, in this case, we're seeing, you know, here's our protocol.

  We're seeing that we need to implement these two methods.

  And so, OK, I'm just going to take this one, this first one  to tell the TableView the number of rows per section.

  I'm going to copy and paste it in here.

  And then I'm just going to start things out, return 1 from this.

  So, OK.

 So that's the number of rows.

  Let's also provide the cell.

  And OK, let's just go ahead and create our UITableViewCell.

  Let's say let cell equals UITableViewCell.

  I need to fix this typo.

  Here, we'll say the style, we'll just say the default style.

  And then for the reuseIdentifier,  we aren't actually going to be reusing these cells  so we can just pass nil for this parameter.

  And OK, so there we have our cell.

  Let's go ahead and configure it.

  So, I can say something like cell.

textLabel.

text equals Text.

  OK.

 So that's the text label.

  We'll see what that looks like.

  UITableViewCell may also have a detail text label.

  But that's not guaranteed to be the case.

  So I'm going to explicitly handle the fact  that it's an optional.

  So, I can say something like  "if let detailTextLabel equals cell.

DetailTextLabel".

  And so, if the code inside of this "if" executes,  then we'll know that we have a detailTextLabel.

  So, I can say something like,  detailTextLabel.

text equals Detail Text,  and we know that this is safe.

  We're not going to accidentally try to assign a property to nil.

  So now that we've configured our UITableViewCell,  I can just go ahead and return that.

  You can see now that we no longer have an issue  in our Playground.

  But we're also not getting any results in the sidebar.

  That's because we haven't actually instantiated our  data source.

  So, I'll just say something like DataSource equals DataSource  and then I can, you know, I'll just create a TableView  and tell it to use our DataSource.

  So, let tableView equals UITableView.

  We'll pass it a frame so, CGRect.

  Again, we don't care about the origin.

  I'll pass 320 for the width,  and for the height we just need enough to be able  to show all the cells we care about.

  So, I'll just say something like 240.

  Finally, we'll pass a style of Plain.

  We'll then tell the tableView to use our DataSource.

  And then, we will tell the tableView to reload data.

  Let that Playground execute.

  And once it's finished executing, we'll be able  to see the tableView we've created.

  So, I'm going to just go ahead and add this to the timeline.

  We can see here that we've created our tableView, you know,  we're seeing the cell that we want,  with the text that we want.

  So, OK.

 So that, you know, gets us up and running.

  But actually I want to see the styles  for all the styles that we have.

  So, I'm going to jump back to the declaration  of UITableViewCell style.

  And you can see here that there are 4 options.

  So I'm going to change this 1 to a 4, so if 4 rows.

  Instead of always passing the default style,  I'm going to conditionalize it based on the row  that we're currently at.

  So, I'll say let row equals IndexPath.

row.

  And I'll say something like let style equals  UITableViewCellStyle.

fromRaw.

  I'll pass the row.

  This fromRaw will convert the UITable, the raw row integer  into a UITableViewCell style optional.

  And we confirm that by using quick help and we can say that,  "Oh, yes in fact, this style is an optional  UITableViewCell style.

"  If we were to pass this directly here,  we would get an error as you can see here.

  We need to explicitly handle the fact that this could be nil.

  You know, the UITableViewCell initializer doesn't expect that.

  So, let's go ahead and check that.

  So we'll say, if we have a style, let's unwrap it,  otherwise you just use the default style.

  It's OK.

 Now that we've handled that,  let the Playground re-execute and let's jump back  to the timeline using the jump bar.

  And once it's re-executed, we'll notice here  that we're now seeing all the different UITableViewCell styles  in our tableView.

  And so now, I have a Playground which I can, you know,  share with my co-workers or just keep it as a reference  for myself to see what each UITableViewCell style  looks like.

  Let's go back to slides now.

  So that showed you how great Playgrounds are  for experimentation.

  You just get started with an idea,  write some code, and see how it works.

  And now I'd like to invite Rick back on stage to talk  about another great idea we have for Playgrounds  and that's Algorithm Development.

  Rick?  >> Thanks, Connor.

  Developing algorithms and any other separable pieces of code  in a Playground is a great way to go.

  And so to show you that, I'm going to dive right into a demo.

  So what we're going to do today is implement insertion sort,  a fairly straightforward sort.

  We're going to create a brand new Playground to do that.

  So I'll just say get started with a Playground,  and we'll call the Playground InsertionSort  and save it on the desktop.

  If you're not familiar with insertion sort,  imagine that you have a hand of cards and you want to put them  in order with the lowest values in the left  and the highest values on the right.

  One way you might do that is, start with the second  to leftmost card and compare its value to the leftmost card.

  If it's less, you'd swap the position  of the two cards in your hand.

  You'd then look at the third to leftmost card and compare it  to the second to leftmost.

  If it's less, you'd swap it, compare it to the leftmost card,  swap it if needed, and go on doing this for every card  in your hand until every card had reached the correct,  sorted position.

  When you're done, your hand will be in order.

  So, let's implement that in a Playground.

  To start with, we need some random data  that we're going to sort.

  So, I'm going to go ahead and I'm going  to declare an array of data.

  I'm going to use var because this needs  to be a mutable array, so I can add to it and sort it.

  And we'll just make an empty array of ints to start with.

  And I could say for i in 0 through 20,  because maybe I want 20 data points.

  I can say data.

append to add a new element.

  And let's use the arc4random function  to generate a random number.

  That doesn't return a Swift Int, so we're going  to cast it explicitly to a Swift Int.

  And we'll modulus it by 100 to get a number between 0 and 99.

  So if I look at data here,  you can see I have a result here on the right.

  Here's an array of what look like pretty random numbers.

  You'll also notice if I edit the Playground source again it  reruns and I get a different array of random numbers.

  Ah, OK, so that's great.

  Well, it's nice to be able to generate random data  but I probably don't want it to change  on me every time I edit the Playground source  because that might make it hard to develop my algorithm.

  So, let's grab this random data and use it every time.

  To do that, I'm going to click over the result sidebar  and use command-A to select this data, command-C to copy it,  and then I'm just going to paste this in here as array literal.

  And now I can work off the same random data every time.

  OK.

 So, let's start implementing our algorithm.

  The first thing we need is a function  to swap two points of data in our array.

  There actually is a built-in function called swap  for this already.

  But for the sake of argument, we'll implement it ourselves.

  So, I'm going to say func.

  I'll call mine exchange.

  You know, we're going to make this a generic because, well,  we have an array of ints.

  Our insertion sort should be able to work on any type.

  So, any type at least as long as it's comparable.

  One element can be compared as greater  than or less than another.

  So, we'll mostly work on comparable types here,  the exchange function can work on any type  because we just are swapping types.

  So this is an exchange using a type D.

  And it's going to take an array of T and two indexes  which we're going to exchange in the array.

  So, the simplest way to exchange these objects is to assign one  to a temporary variable, assign the second to the first,  and assign the temporary variable to the second.

  So, we can say let temp equals data of i.

  Data of i equals data of j.

  And data of j equals temp.

  OK.

 I think we've implemented this correctly  but let's try it and find out.

  I can say exchange, pass my data array  and we'll say exchange the 0th element with the second element.

  And then we'll take a look at our array when we're done.

  So, before, element 0 was 12, and element 2 was 15,  now element 0 is and element 2 is 12.

  So, it looks like exchange works properly.

  OK.

 The next thing we need is a function to, given an index,  look at the data point of that index,  compare it to the data point to its left; if it's less,  exchange them and keep comparing and exchanging  until it reaches the correct position in the array.

  So, let's call this function swapLeft.

  Again, it's a generic but this time we need  to actually do a comparison.

  So, we're going to say our type D is comparable and we're going  to pass an array of T and an index of the data point we want  to start swapping left.

  OK.

 So, let's implement this, we're going to start  with our index and go back to position 1,  not 0 because there's nothing to the left of 0 to swap.

  So, I'm going to say for i in, and, you know,  I could do a range from 1 to index  but what I really want is index to 1.

  So I'm going to reverse the range with reverse 1.

  3 dots makes it a fully closed range  which means it will go all the way to index.

  So, since I'm reversing this, it goes from index and ends at 1.

  And for each of these data points, I'm just going to say  if data of i is less than data of i minus 1,  exchange data i and i minus 1.

  OK.

 If it's not less than data of i minus 1,  it must have reached the correct sort of position  in the array, so we can stop there.

  So, let's say else break.

  OK.

 Let's try this function out.

  I'm going to go ahead and say swapLeft, pass data,  and let's pass element 1, 2, 3, 4, 5, 6.

  Let's pass element 6 left.

  Oops! And look at our data.

  And you can see the has moved all the way  from the 6th position to the beginning of the array  and everything's been moved to the right.

  So it looks like this function is working great too.

  OK.

 The last thing we need is to actually implement the sort,  so this should be pretty simple.

  We'll call our function isort,  works again on type T that is comparable.

  And we can just pass an array of T  and it will sort the whole array.

  To do this, I'm just going to say for i in 1 (we're starting  at 1 because there's nothing to the left of 0 to sort to)  to data.

count, swapLeft, data and i.

  So, let's try it out, isort data.

  And we'll look our data array when we're done.

  And you can see it did a whole bunch of assignments up here.

  And now here's our final array and it looks  like this is in sorted order.

  So, we've correctly implemented insertion sort.

  So, this is great for a simple algorithm like insertion sort.

  That wasn't too hard.

  But you know if I was doing something more complicated,  it might be nice to have more visibility  into exactly what's going on here.

  So, let's look at how we might visualize our results  in more detail.

  Well to start out with, let's draw a graph of the results  of the data at the beginning.

  To do that, I'm just going to say for x in data (to iterate  through every data point) and just print out x.

  And so, you'll see there are 20 data points here.

  So this line executed 20 times.

  And if I click on the Value History button,  I get a nice graph here showing my data at the beginning and,  boy, that does look random.

  OK.

 So, now I want to try to print  out another graph every time swapLeft is called,  so I can see what's happening to the graph  over iterations of swapLeft.

  And I could put this "for" statement in the end  of swapLeft again and show the Value History.

  But again, in Value History Timeline item for given,  a line is going to show all the data from that line.

  So, each time swapLeft is called,  its data would be appended to the same graph.

  That's not what I want.

  I want a new graph, every time it's called.

  So to do that, we're going to need a new tool in our toolbox.

  I'm going to go back to slides and show you that.

  With Playgrounds, we're shipping a new framework called  XCPlayground and it contains some very useful utilities  for enhancing your Playgrounds.

  Right now, we have API for manually capturing values  to display in timeline items, showing your views live  and extending execution for asynchronous code.

  Right now, we're going to use the API  for manually capturing values.

  That API is called XCPCaptureValue.

  It's a function that takes an identifier, which is a string,  and your value, which is of any type.

  When you pass it -- your value -- it will take that value  and put it in a timeline item for you.

  So, the identifier that you pass it identifies what timeline item  you want that value to go to.

  If you call this function on different lines  but pass the same identifier,  the values from those different lines will go  to the same timeline item.

  Conversely, and what we want here, if you have one line  that calls XCPCaptureValue but it's called multiple times  with different identifiers  and it passes those different identifiers,  that one line can generate multiple different timeline  items (or grabs, in our case).

  That identifier is also shown as the name of the timeline item  so you can easily see what data is what.

  The value pass can be anything, because it's a generic  but it helps if it's a type of value that we know how  to Quick Look appropriately.

  So, let's go back and give this a shot.

  So to start out with, I need to import XCPlayground  to make this API available and I'm going to go ahead  and define a new function.

  I'll call it visualize and it's a generic.

  And it will take an array of type T and I'm going to use this  "for" loop in it, so I'll just indent that  and close the function.

  But instead of just printing out x, what we want  to do is capture that value.

  So, I'll call XCPCaptureValue.

  I need an identifier, so let's add one to our function.

  So, identifier is a string and we could pass  that identifier, and our value is x.

  OK.

 So let's try this function out and visualize the data  at the start of our sort and we'll label it Start  as the identifier just so we know what's what.

  And here you can see it ran and here's our data at the start.

  So that's a good start.

  So now, we're going to go ahead and visualize our data  after every iteration of swapLeft.

  So, I can call visualize, I'll pass data as it is  after this iteration of swapLeft.

  And for our identifier, let's label it after the iteration,  the number of times that swapLeft is called,  which is the index parameter.

  And so, I'm going to let this run now.

  And you can see that it's generated multiple graphs  labeled after the iteration that we're on.

  So, now we can just scroll through here  and see what's happening to our data over time as swapLeft runs  and the sort completes.

  You can see it looks like our data is getting sorted piece  by piece.

  And so, at the end, we have a nicely-sorted array.

  So there, we can easily visualize exactly what's going  on with our algorithm.

  We think you'll find this very, very useful.

  OK.

 Let's move on to another example.

  I've got a heap Playground I made here earlier.

  And it's got this HeapGrapher class at the top  which I'll explain in a moment.

  But the meat of this class is my heap class which,  if you're not familiar with a heap, a heap is a type  of balanced binary tree where the value  of every node is greater than or equal  to the value of its children.

  Heaps are often used to implement priority queues,  because it's very efficient  to remove the highest priority item, that's the top  of the tree, and it's also efficient to insert new items  into the correct position of the tree for their priority.

  We're implementing our heap with an underlying array  to represent the tree.

  And in our array, the tree noted index i has children  at indexes i times and i times 2 plus 1.

  So you can see down here  at the bottom we've got some random data  that we seeded ourselves with.

  And we've created a new heap with that data.

  And we "heapified the heap," which is to say, put that data  into correctly heap-sorted order.

  On the right, in the results sidebar,  you can see our default treatment  of this custom class is to show the name of the class  and show its properties.

  In this case, it has one property which is  that heap array and here it is before it's been heapified,  when it's not a correct heap.

  And here it is after it's been heapified,  when it's purportedly a correct heap.

  But you know, it's really hard to tell looking  at this array whether that's a correct heap.

  This array represents a tree and, you know,  not so good at visualizing, "Hh, well, here's I,  and here's i times 2, and yeah, that's less.

.

.

"  Wouldn't it be much better if I could just visualize this  as a tree everywhere my heap is referenced  to my Playground source?  So let's see how to do that.

  In order to visualize my own custom class,  we're going to implement Custom Quick Look Support  for this class.

  Our Custom Quick Look Support allows you to add Quick Looks  for subclasses of NSObject only (right now).

  And to do it, you implement the debugQuickLookObject method  which takes no parameters  and returns any object as an optional.

  And you're going to return the value that you want  to represent your object as its Quick Look.

  So, right now, that value (the values  that we support here) are colors, strings (both plain  and attributed), images, and Bézier paths.

  So, for your Custom Quick Looks you can use any of these types.

  So, let's try it out.

  OK.

 So I mentioned before I had a little HeapGrapher class  that I wrote.

  That's a little class that knows how to take an array and draw it  as a tree, so we're going to use that.

  We'll implement our debugQuickLookObject method.

  It takes any, or returns any object as an optional  and we're just going to create one of our HeapGraphers.

  And this HeapGrapher knows how to generate an NSImage  which is one of the Custom Quick Look types, supported types.

  So, we're just going to return the image it generates  with g.

graphHeap and pass self.

heaparray.

  And now, when this runs, instead  of showing the default representation for our class,  it shows our custom Quick Look representation,  which is an image.

  And so when I click the Quick Look button,  you can see here it's drawing my heap as a tree.

  This is before it's been heapified when you can see,  for example, 78 is less than 89.

  So this is not a correct heap.

  But if I Quick Look it after it's been heapified,  I can now go, oh great, is greater than 86 and 89,  86 is greater than 84 and 79, and so on and so forth,  and I can really easily visually verify  that this is a correct heap.

  So that's how you can Quick Look your own classes in Playgrounds  and we think you'll find that very useful.

  All right.

  Next, we'd like to move on to showing you how great it is  to do Custom View Development  and other drawing development in Playground.

  And to do that, I'm going to hand it over to Connor.

  >> Thank you, Rick.

  Another great use case we think Playgrounds will be used  for is Custom View Development.

  And that's because you can just start writing some code  and see the actual view as it's being drawn  and as you're starting to build up your drawing code.

  So for this I have a goal.

  I want to take this Playground icon  and add some animation to it.

  The icon that we have is really great.

  It conveys the playfulness of Playgrounds.

  But unlike Playgrounds themselves, it's static.

  There's nothing dynamic about it.

  And so, I'm going to try to add animation to this.

  And what better way to do it than when  in a Playground itself?  So, let's jump over to the demo.

  So OK, here I'm going to go ahead and open up a Playground  that I've already started.

  So, OK.

 So here we've got a Playground.

  We've got our subclass of NSView called PlaygroundIconView.

  It has a few layers.

  It's got these three instance, er, these three instance methods  which actually do the setup of those layers.

  You see that they're unimplemented right now  and we'll come back to that in a moment.

  I also have an extension of NSColor which defines a couple  of colors for the Playground icon itself.

  I then have a helper function to convert an NSBezierPath  to a CGPath for use with CAShapeLayer.

  Finally, I just go ahead and create an instance  of my PlaygroundIconView.

  And then, I put it on a separate line  so I can add some stuff later.

  Let's go ahead and show that in the timeline.

  So, OK.

 So you'll see now  that we've just got ourselves an empty view here.

  So yes, we have an empty view here.

  We actually just now need to go ahead  and implement these setup functions.

  So let's go ahead and do that.

  So we'll start out by creating the path  for the background layer.

  So you can see here we're creating NSBezierPath  and we can Quick Look it to make sure it looks right.

  And in fact, yeah, that looks more or less  like the Playground icon.

  So let's tell, let's setup our layer.

  So OK, now we're setting up the layer.

  You can see here in the timeline  that we're now drawing the layer where, you know.

.

.

  We have the background, we've got the little border there,  and so, OK, we've got our background set up.

  Let's also do the seesaw base and we'll do the same thing.

  We'll create a path for that.

  And we'll let it execute and we'll see here,  let's Quick Look, make sure.

.

.

  Yeah, that looks more or less like the little base  that we have for the play- .

.

.

for the seesaw.

  So let's set up the layer itself as well.

  And there, we just make that change  and immediately get the feedback of seeing what that looks  like when drawn in our view.

  Let's also do the seesaw layer.

  I've got some code here to set that up as well.

  You see here that we're just, you know, have a closure  which will create the child layer itself.

  We then create a couple of layers for the children  on each side of the seesaw, and then we set up the bench itself  and then add those layers to our seesaw layer.

  So, OK.

 So now we've got ourselves something  that looks kind of like the Playground icon.

  But like the icon itself, it's not animating.

  So let's go ahead and add support for animation  to our PlaygroundIconView.

  I have a snippet for that as well.

  And so, let's walk through what this is doing.

  I define a constant for the maximum angle of the seesaw.

  I've, you know, worked through this and I think pi  over 12 is about right.

  I also have a property for the current angle of the seesaw  after any pending animation is finished.

  And then have a property which determines whether  or not it should be animating.

  It starts out as false but we have this code here  which executes whenever this is set to say, "Well,  if the animation state has changed and we're told  to animate, then just start animating depending  on the current angle of the seesaw.

"  I then have this helper method  for actually performing the animation itself.

  So we just, you know, go ahead and create a CABasicAnimation,  set a couple of values, set our timing function  to match what a seesaw would actually look like.

  Set the duration to what was passed in which defaults  to 1-1/2 seconds, but can be customized depending  on the angle of the seesaw.

  We then add the animation to our seesaw layer.

  We set the underlying transform property of that seesaw layer,  so that once the animation completes it looks correct.

  And then we update our current seesaw angle  property accordingly.

  Finally, we have, uh, we implement the "animationDidStop,  finished" delegate callback.

  Or basically say that if we finished  and we're still supposed to still be animating,  then just go ahead and animate to the opposite angle  of what we currently are at.

  So, OK.

 Let's go ahead and tell this view to start animating.

  So we'll do that and you'll notice that after it reruns,  we seeing the view update it's look, you know,  so we see that it tilted over to the side.

  We're not seeing the animation itself.

  And for that, we're going to need some help  from the XCPlayground framework.

  So, let's switch back the slides  to see what that could look like.

  So the second piece of functionality  which the XCPlayground framework provides is the ability  to show live views in the timeline.

  And you do that by calling this XCPShowView function.

  It takes an identifier and the view that you want to show.

  After calling it, we'll show the view live while the Playground  executes and then we'll record frames  as the Playground executes  so you can play them back once execution finishes.

  The identifier you pass to this function must be unique inside  of the Playground.

  That's because this is how we refer  to the live view internally in Xcode.

  And it is also what we'd show as the title  for the live view in the timeline.

  The view pass must also not have a superview.

  This is because we will add it to our own view hierarchy  and it would generally not produce the results you're  looking for.

  So with this in our toolbox, let's jump back to the demo  and see how it's used.

  So I'm going to go ahead and just go ahead  and import XCPlayground.

  And then down here, instead of just having this view item,  I'm going to remove that from the timeline.

  I'm going to say something like XCPShowView  and pass an identifier.

  It can be anything as long as it's unique.

  So I'll say Playground Icon View.

  And then I'll pass the view that we've created.

  So, we'll just let that re-execute.

  And you see there that in the timeline,  we're showing the view live as it's animating.

  You-all also probably noticed this little timeout field  down here.

  And that lets us specify the amount of time  which we'll let the Playground continue executing  after we reach the end of execution of the top of a code.

  Now, it defaults to 30 seconds but I'm going to adjust this  down since I know my animation only takes  about a second and a half.

  So I'll do 10 seconds to get a few times around.

  After we edit that, we'll rerun it.

  And so that's great, you know, we see it running there.

  And I'd like to show how you can integrate XCPShowView  with the XCPCaptureValue API we mentioned earlier.

  And so, what I'm going to do, I'm going to capture the angle  of the seesaw, or of the left edge  of the seesaw as we're animating.

  So here, I'm just going to say XCPCaptureValue.

  I'll pass Left Seesaw Position and I'll just pass   because we know at this point that it's,  you know, it's flat on there.

  Then you can take this and I'm going to put it in our  "animationDidStop, finished" callback.

  Now I'm going to just pass the negative currentSeesawAngle.

  That's just because that's what we need to do in order  to get the left position of the seesaw.

  That is how the angle works out for the transform.

  So you see here that as we're executing,  we're getting the graph kind of building up over time.

  And then once execution finishes,  the graph will snap back into place and kind  of show you the best view of the data that it collected.

  It's OK.

 You probably also noticed this slider  became active.

  And so, I can just go ahead and take that  and drag it through here.

  And you'll notice that we're updating the graph at the bottom  but we're also showing you the animation, you know,  as it went through in time.

  So this is, you know, a fairly basic animation  and it's doing what we expected but, you know,  if you had something more complex and you want  to just kind of take a look at just a small portion  of your animation, you could do that as well.

  And I can also do something like, you know,  click on one of these points.

  So I can click there.

  We can see it, you know, that the two things are in sync.

  I click there.

  It updates the point.

  I can use the arrow keys to go through the graph's points  and see that, OK, yeah, you know,  we're doing what we expect it to do.

  And so, that's how you can show live views in the timeline  with the XCPlayground framework.

  Let's go back to the slides now.

  Now, I'd like to talk to you  about how you can use asynchronous code  in your Playgrounds.

  You got a little taste of this in the demo before.

  But I'd like to go into a little bit more detail now.

  The third piece of functionality  which the XCPlayground framework provides is the ability  to extend execution.

  By default, execution terminates once all top-level code  has executed.

  XCPlayground, though, provides API  for extending execution indefinitely.

  That's this XCPSetExecutionShould  ContinueIndefinitely function.

  You should know that this is actually not quite indefinite.

  The execution time is controlled by the timeline's timeout  which defaults to 30 seconds.

  Additionally, execution will be terminated  if you edit the Playground while it's running.

  This is so that we can show you up to date results rather  than let, leaving you a stale results while we wait  for an earlier execution to finish.

  Additionally, as you saw on the last demo, you know,  we didn't actually call this function,  but we saw that execution continued  after we reached the end of top-level code.

  That's because XCPShowView implicitly  calls XCPSetExecutionShould  ContinueIndefinitely.

  You should just think about this as if nothing  in the Playground source has told Xcode  that the Playground used to stay alive,  then the Playground will stop executing once we reach the end  of top-level code.

  So now, I'd like to show you a quick demo of what it's  like to use asynchronous code in Playgrounds.

  So here I am back here and I have a Playground  which uses asynchronous code.

  We create, uh, we have our session delegate  which is an NSURLSessionDelegate.

  It has a few callbacks.

  And then we also just, you know,  create an instance of our delegate.

  We created an NSURLSession.

  And then create a data task to download the contents  of the Apple home page.

  We then tell the data task to resume.

  And you noticed that, you know,  the Playground itself has executed  but we're not receiving any results up here.

  And if I open up the assistant editor, you'll notice  that we haven't received any console output even though they  were clearly logging here that we've received some bytes.

  And this is because nothing  in the Playground has told the Playground  that it should continue executing.

  So we call task.

resume, we resume the task and then as soon  as that finishes, we hit the end of top-level code  and the Playground just stops executing.

  Let's go ahead and say import XCPlayground.

  And then we can say XCPSetExecution  ShouldContinue, XCPSetExecutionShould  ContinueIndefinitely.

  This takes a Bool but that defaults to true,  so you typically don't need to pass anything there.

  And I won't do that here.

  You'll now notice that, you know, we were receiving results  from here and we're also seeing the console output  that we expect in the timeline.

  So OK, that's how you use asynchronous code  in Playgrounds.

  Let's go back to slides now.

  There are a few alternatives but we really think  that you should typically use XCPSetExecutionShould  ContinueIndefinitely when you're trying  to use asynchronous code in Playgrounds.

  If that won't work for you though,  you can use other methods for waiting  for asynchronous operations to finish.

  Basically, you just need to make sure you don't reach the end  of top-level code before your operation completes.

  Before we leave today, I'd like to talk to you a little bit  about some of the limitations we have with Playgrounds.

  First off, you should not use performance, uh,  Playgrounds for any performance testing.

  That's because the logging of results  in the Playground will generally dominate the runtime,  not your actual code.

  This means that the performance will be dependent on the number  of lines of code executed, not the actual performance  of whatever it is you are developing.

  And that's not necessarily what you'd expect.

  Instead we'd suggest that you use the XCTest framework  to create performance tests in a test bundle  where you can get more accurate results.

  We have a session later this week called Testing in Xcode   which will go into this in more detail.

  There are few more limitations with Playgrounds.

  Playgrounds cannot be used for things  which require user interaction.

  So we have great support for showing live views  but you can only see them, you can't touch them.

  We also do not support using Playgrounds for anything  which require custom entitlements.

  For iOS Playgrounds, we only support executing  against the simulator.

  So anything which requires a device will not be supported  with Playgrounds.

  And finally, we do not support using your own app  or framework code in a Playground unless it's something  that you can just copy and paste into the Playground source.

  Basically, you can only use things in the standard library,  in the SDK, or that's in the Playground source itself.

  You can get around some of these limitations by using the REPL.

  The REPL is the command line interface to Swift  and it works this way because the REPL can actually execute  in your own process.

  You just stop at a breakpoint, and then at the LLDB prompt,  you execute the REPL command and you'll just be dropped  down right into the Swift REPL.

  Playgrounds though provide a richer experience than the REPL.

  And that's because we will automatically execute your code  from a known state.

  That means, you know, you make a single edit to a line and then,  you know, we just rerun it from 0.

  Whereas with the REPL, if you wanted to make an edit  to something earlier in the source that you had entered,  you have to, you know, get the process back  into the state then, you know, reenter the REPL,  retype everything making that one change  to see how it affects things.

  Playgrounds also supports some of these higher level futures  like Quick Looks and a timeline which we do not support, uh,  which the REPL does not support.

  If you'd like to learn more about the REPL,  you can go to the Introduction to LLDB and the Swift REPL talk.

  And we'll go into much more detail about how the REPL works.

  In summary, we think Playgrounds are a great way to play  with Swift, with Cocoa and with Cocoa Touch.

  We think you can use them for things like learning,  exploration and visualization and frankly probably tons  of things which we haven't even thought of yet.

  The XCPlayground framework provides APIs  for using your Playgrounds for more advanced things.

  So you can do things like manually capture values  with the XCPCaptureValue API.

  You can show live views in the timeline by calling XCPShowView.

  And then you can also extend execution  for asynchronous operations with the XCPSetExecutionShould  ContinueIndefinitely function.

  Finally, we'd really like to just encourage you to go out  and give Playgrounds a try.

  I think, you know, they're really approachable  and if you just sit down with them  for a little bit you'll find a number of great ways  to integrate them into your development process.

  For more information, you can contact our Developer Tools  Evangelist, Dave DeLong.

  We also have some information about Playgrounds  in the Source Editor Help for Xcode 6.

  You can also ask questions about Playgrounds  on the Apple Developer Forums.

  We have several related sessions about Swift this week.

  So there was an Introduction to Swift session yesterday,  which you can catch on the video.

  We also have an Intermediate Swift session later  this afternoon.

  There's also an Advanced Swift session tomorrow  which you'll be able to see.

  We had an Integrating Swift  with Objective-C session earlier this morning  which you can catch on video.

  And we also have a Swift Interoperability  in Depth session later this afternoon.

  Finally, if you'd like to learn more about the Swift REPL,  you can go to the Introduction to LLDB  and the Swift REPL session.

  Thank you all for coming  and I hope you have a great week here at WWDC.