Playgrounds Part II

Apple’s pretty highlight page on Swift Playgrounds is here.

Screen Shot 2016-06-14 at 8.09.21 AM

Jonathan Penn figured out how to send documents between my Mac and iPad: just use AirDrop. With that tip, I was easily able to create content on the iPad and move it Macwards and see the material that Apple provided itself.

Here’s how to go from iPad to Mac:

  1. Open AirDrop on your Mac
  2. Tap “My Playgrounds” (4 squares)
  3. Tap Action (top-left, square with arrow pointing up)
  4. Tap the playground you want to send
  5. Tap an AirDrop destination
  6. Wait for the transfer.

iPad Playgrounds use a new format: “Playground Book”:

Screen Shot 2016-06-14 at 8.14.51 AM

It consists of the playground’s contents and user-created edits (stored as a diffpack), which are stored separately. The contents consist of chapters, which in turn have individual playground pages, shared resources and sources. It’s basically the playground we’ve come to know and love on steroids and hallucinogens.

Want to know more about playgrounds? I have a fairly extensive book on playgrounds that’s available right now, which you may be interested in checking out.

The iPad playgrounds app consumes at least two kinds of playground pages: standard pages and cut scenes. These are included as parts of a playground book, which consists of playground chapters, in which the pages and cut scenes are stored. You can read more about the Playground Book Package Format on Apple’s website. (Thanks to Matt Gallagher for the pointer.)

I’m going to warn you in advance that Swift does not play a huge rule in cut scenes. Instead, the cut scenes were constructed using HTML and Javascript. I’ve pasted a fairly short cut scene here, along with a screen shot of some of the resources to create just this one element:

Screen Shot 2016-06-14 at 8.18.42 AM

<!DOCTYPE html>
<html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <meta http-equiv="X-UA-Compatible" content="chrome=1,IE=edge" />
 <title>simpleCommands</title>
 <style>
 html {
 height:100%;
 }
 body {
 background-color:#AFE0D9;
 margin:0;
 height:100%;
 }
 </style>
 <!-- copy these lines to your document head: -->

 <meta name="viewport" content="user-scalable=yes, width=1024" />

 <script type="text/javascript" src="simpleCommands.hyperesources/StopPoints.js"></script>
 <script type="text/javascript" src="simpleCommands.hyperesources/HypePagingSupport.js"></script>

 <!-- end copy -->
 </head>
 <body>
 <!-- copy these lines to your document: -->

 <div id="simplecommands_hype_container" style="margin:auto;position:relative;width:1024px;height:768px;overflow:hidden;" aria-live="polite">
 <script type="text/javascript" charset="utf-8" src="simpleCommands.hyperesources/simplecommands_hype_generated_script.js?65524"></script>
 </div>
 <!-- end copy -->
 <!-- text content for search engines: -->
 <div style="display:none">
 <div>Simple Commands</div>
 <div></div>
 <div>Your goal is to figure out which instructions, in which order, will result in something great.</div>
 <div>Writing code allows you to create your own set of instructions for your iPad to carry out.</div>
 <div>Notice the mashed-together words? Code is punctuated and spaced like human languages, but commands have no spaces between words.</div>
 <div>collectGem()</div>
 <div>You need to follow the instructions in the correct order, or you'll end up with something…unexpected.</div>
 <div>For example, you'll tell Byte to move forward:</div>
 <div>Commands always end with parentheses. You'll see why later!</div>
 <div>moveForward()</div>
 <div>You’ll start by writing commands to move a character named Byte around a puzzle world, performing tasks.</div>
 <div>Now it's your turn to write some code!</div>
 <div>Have you ever followed a recipe to bake something delicious?</div>
 <div>Or followed instructions to assemble something cool?</div>
 <div>Learn to Code
</div>
 <div>Or collect a gem:</div>
 </div>
 <!-- end text content: -->
 </body>
</html>

Yeah, I know.

Playground pages include separate Contents.swift and LiveView.swift files, which really surprised me.  The Live Views use a poster asset (simple JPG), and there’s a metric ton of Super Sekrit meta-comment annotation for setting up each page:

/*:
 **Goal:** Find the bugs and fix them.
 
 When you write code, it’s easy to make mistakes. A mistake that keeps your program from running correctly is called a [**bug**](glossary://bug), and finding and fixing bugs is called [**debugging**](glossary://debug).
 
 The code below contains one or more bugs. To debug it, rearrange the commands into the right order to solve the puzzle.
 
 1. steps: Run the code to see where the mistake occurs.
 2. Identify the command that's in the wrong place, then tap it to select it.
 3. Drag the command to the correct location, then run the code again to test it.
*/
//#-hidden-code
playgroundPrologue()
//#-end-hidden-code
//#-code-completion(everything, hide)
//#-code-completion(identifier, show, moveForward(), turnLeft(), collectGem(), toggleSwitch())
//#-editable-code Tap to enter code
moveForward()
turnLeft()
moveForward()
moveForward()
collectGem()
moveForward()
toggleSwitch()
//#-end-editable-code
//#-hidden-code
playgroundEpilogue()
//#-end-hidden-code
//#-hidden-code
//
// Contents.swift
//
// Copyright (c) 2016 Apple Inc. All Rights Reserved.
//
//#-end-hidden-code

As you see, you can control which elements are presented to the reader/user/coder, to allow a subset of coding to be accomplished with simple taps. It’s a pretty limited approach for end-user consumption.

The entire system is run using a new PlaygroundSupport library, which appears to be iPad only for the moment but will replace XCPlayground, presumably soon in Xcode 8 (despite this screen shot).

Screen Shot 2016-06-14 at 9.20.59 AM

According to docs, the PlaygroundSupport module enables you to access a playground page and manage execution, display and dismiss live views, and share and access persistent data, which you use for creating a consistent experience throughout the interaction with your playground book.

A quick check shows that you can refer to: PlaygroundPage (for page state control), PlaygroundValue, PlaygroundQuickLook (should act like the current version), PlaygroundLiveViewable (protocol for live-view suitable types), PlaygroundKeyValueStore (for persistent data storage), PlaygroundRemoteLiveViewProxy,  PlaygroundLiveViewMessageHandler, PlaygroundLiveViewRepresentation  (type enum for items that can act as live views), PlaygroundRemoteLiveViewProxyDelegate.

Carl Brown tracked down some of this in the “Answers” example playground, which uses custom show() and ask() functions built around these new features.

For example, the AnswersLiveViewClient class works as a proxy delegate for interactions in the live view. It’s a subclass of the Apple-supplied PlaygroundRemoteLiveViewProxyDelegate class that acts as a PlaygroundLiveViewMessageHandler for receiving and processing live view requests.

As far as I can tell, there are not yet any tools on the Mac side that build these pieces. So don’t go looking for iPlaygroundAuthor or even an iPlaygroundBookstore quite yet.

Screen Shot 2016-06-14 at 8.35.34 AM

So what is this entire app good for then? Other than some goodwill Apple outreach? Well, it’s cool having interpretable Swift on your iPad (take that original App Store restrictive rules!) and it’s clearly meant for an audience that accepts limited tap-based interaction, with a lot of beautiful highly designed iBooks-Author-esque HTML support.

Without tools to create content (yet) or a storefront to distribute and potentially monetize, it feels like a proof of concept more than an app. We’ll see how things (if you pardon the pun) develop.

One Comment