Connect the UI to Code

Back | Forward



Chapter 2 of 10 at Apple Developer > Jump Right In is Connect the UI to Code.

Don't need much vocabulary

Apple pushes hard for you to struggle to learn what all their words mean.

This is silly. They're flooding you with words you don't need. Xcode itself is tightly limiting your options. You can work all the way thru to the end and push out a well-running app without ever having made time to understand what a "superview" is, or "an implicitly unwrapped optional variable", and so on and on.

You really can focus on what they tell you to do, and learn what it means by watching what happens. Their diagrams do help. Their explanations in words aren't worth much. I'm here to argue most of their explanations in words aren't even worth reading, much less deciphering.

Apple mentions many technical terms you will learn someday, as if you need them now

Model, view, and controller

Xcode divides your app into three parts. Apple runs you on in without quite pausing to tell you this. The picture their authors have in mind as they speak is something like Wikipedia Model view controller.

Apple gives no definition for the few technical terms you do need now


<= Learning Objectives
<= Connect the UI to Source Code

Editor and Assistant Editor

Apple is trying to say that you often want to edit two things at a time, instead of just one.

That's it, that's all they mean, even though they go on and on.

For instance, all at once, you want to look at a Storyboard and also the Swift code running inside it. Well sure, you do. When they say "The Editor", they mean where you mess with the first thing you opened. When they say "The Assistant Editor", they mean where you mess with the second thing you opened.

You find the correct X to close the Assistant Editor.

You find the Pair of Overlapping Hoops to open the Assistant Editor, and notice they turn blue while it's open, and notice that opening the Assistant Editor gives you a second Pair of Overlapping Hoops just above whatever you're editing inside the Assistant Editor.

It's that second Pair in grey that sit next to some Triple Dots "..." in grey. It's those Triple Dots of that second Pair that give you an "Automatic" choice telling you what they guess the second thing should be to edit inside the Assistant Editor, after you select some first thing to edit inside the Editor.

Apple has forgotten the courtesy of drawing a new icon for each new thing

<= Create Outlets for UI Elements

Marks in the code

Apple tells you out loud that they want you to learn to make Marks before they show you what good they are.

Wow. Well, me, I find people giving mystic orders difficult to accept. If you like, go ahead and make three marks in the same file, so you can see how they work.

Before now, you've already found your grey Pair of Overlapping Hoops, and the Triple Dots just to the right of those. Now you can look out to the right end of that chain where you're told what Class you have selected inside the Assistant Editor. Click there to see all the Marks you have made inside that Class, and then click on a Mark to warp to it.

Apple has lost the discipline of introducing the new thing no sooner than it matters

<= Create Outlets for UI Elements

Drag it from where you can find it

Apple talks as if people always only Ctrl+Drag from the Storyboard into Swift.

Yea maybe. The thing is, you can look at two places on screen to see what you select inside the Storyboard. You can look at the Storyboard itself, your mock-up of an iPhone. But you can also look at the Document Outline on the left that shows all its pieces as a list of lists of lists of things, unless you've accidentally hit the Hide/Show Document Outline button to hide it.

And once you've learned to select things inside the Document Outline, you'll often find that easiest to hit with the mouse, select, and Ctrl+Drag from.

Apple introduces two in tandem by talking about one and ignoring the other

<= Create Outlets for UI Elements

One word and two

Apple pushes you to define a "mealNameLabel" and a "nameTextField".

They neglect to disclose the deeper structure of those choices. The structure is obvious only after you learn, and then still rudely hard for a new person to remember because of the choices they made.

The "mealNameLabel" is a first name of two words and a last name of one word: it is a "Label" that presents the "mealName".

The "nameTextField" is a first name of one word and a last name of two words: it is a "TextField" that presents the "name" of the meal. Indeed, one might say it is a "mealNameTextField", if giving your students all the consistency you can were a priority.

Apple has chosen example names so poorly as to trip up new people

<= Create Outlets for UI Elements

Don't trust every kind of undo

This is the place in the tutorial where learning to undo well really begins to matter. For example, near here, you may need Source Control > Discard All Changes, which should just send you back to the start of this chapter, if you ended the last chapter with a Source Control > Commit that worked.

Here now, if you misunderstand just enough to move ever so slightly off the one true path, like you accidentally make an IBOutlet where you wanted an IBAction, well, that's crazy hard to undo. You can undo everything you can see, without it really being undone inside, in the details that only "git diff" shows.

And while it's not really undone, your app will crash, yammering on about some mystic wound such as "NSInvalidArgumentException" "unrecognized selector sent to instance".

You can quickly back out, start over, and get it right.

Apple has forgotten to make your every likely error visible

<= Define an Action to Perform
<= Process User Input

Download and compare and commit

Apple ends this chapter, its chapter 2 of 10, with a download named "02_ConnectTheUIToTheCode". They're just meaninglessly sloppy, inserting an extra "the" into that name that's missing from this chapter's title.

Apple mentions the download & forgets to recommend compare at the end of each chapter.

As soon as you're sure you're finished with this chapter, you can capture your progress. Click back on thru Xcode > Source Control > Commit. Give it a Commit Message such as "Connect the UI to Code". Click to Commit Files. Be happy.

<= Wrapping Up


Back | Forward | Source: Apple Developer > Connect the UI to Code

Build a Basic UI

Back | Forward



Chapter 1 of 10 at Apple Developer > Jump Right In is Build a Basic UI.

Hope for a bot to think with

Apple picks a first goal for your app: it must learn to listen, to speak, and to act.

You tell your app to listen inside its UITextField, you tell it to speak out thru its UILabel, you tell it to act when some human taps its UIButton.

Apple leads with the sneer of "Basic" and the alphabet soup of "UI", but they mean well

<= Learning Objectives

Find the answers in the back of the book

Each chapter of the tutorial ends with a copy of Apple's solution. Glance into it as often as you want, to compare their solution with yours.

You can open the project folder in Xcode, or its '.xcodeproj' file, or compare the text of the files of one project with another

<= Learning Objectives

Don't replace all the example texts

Apple means to say you should create some new folder to work with Xcode, such as "~/Documents/Xcode-Projects". Inside that folder you place your Xcode Projects. Each Project is its own Git Repo.

Apple means to say you can leave the Organization Identifier set to "com.example". They don't mean to say you must spell your own name backwards, as with "org.ieee.doe.jq".

Apple means to say you can give no Organization Name at all, you don't have to name yourself as an organization, you don't have to name some other organization.

Curiously, Apple prints no copyright claims into your code if you name no organization. If you do name an organization, then Apple puts claims into your code to say you assigned your copyrights to them.

Apple doesn't invite you to claim copyright and doesn't applaud you giving anonymously

<= Create a New Project
<= Get Familiar with Xcode

Pick one iPhone to simulate

Beware, Xcode will leave stale versions of your app behind on every iPhone you simulate.

That gets wildly confusing if you try more than one iPhone. Xcode will frequently slap you back into choosing its default choice. Either you take its default as mandate, or you learn to delete old versions of your app.

Xcode shrugs off much of the work of distributing your apps under test

<= Run iOS Simulator

Expect to start twice

Apple develops Xcode with all its security turned off.

If you're typing a password every time you restart Xcode, you're working harder than they do, and you'll notice that your first launch of the iPhone Simulator fails, because you didn't type out your password in zero time. No big deal, once you understand. You just start again.

Xcode doesn't encourage you to aggressively defend your own MacBook

<= Run iOS Simulator

Watch your iPhone simulation catch up

The first iPhone that Xcode shows you won't look the same at first as it does later. Xcode lets you run ahead and get started even as it is slowly slowly filling out the phone for the first time. It is busy installing a dozen apps alongside yours, you just don't get that news unless you ask for it.

Apple forgets to tell you how it is disrupting your world

<= Run iOS Simulator

Race ahead

Apple invites you to review the "AppDelegate.swift" file, as if that file contained words you would find pertinent as you work thru this tutorial. It doesn't. You can skip it.

Apple forgets to respect your time intensely

<= Review the Source Code

<= The App Delegate Source File

Walk backwards

Apple has somehow chosen to come off as arrogantly imagining their words are perfect. They say just tell you, yea, you do what we meant to tell you, without ever walking you thru how to undo any misunderstandings. As if that could ever be real.

So early on, find your way to the major kinds of Undo that work better than:

Edit Undo        ⌘Z

Experiment with:

Product > Clean        ⇧⌘K 

Yea I mean it        ⌥⇧⌘K 

Push so hard as to learn the destructive:

Source Control > Discard All Changes

You'll have to redo what you just did when you try that, but it's worth it, because here you learn how to undo what you did wrongly by accident, when you don't even know what it was that you did wrong.

If you know Git, you can Quit Xcode, drop down into the Terminal, and learn to destroy the rest of your changes like so:

git log 

git reflog

git status --short --ignored 

git clean --ffxdq

That extreme technique for destroying all your work is even more thorough than the choices Xcode gives you. That sharp scalpel will likely go wrong if you forget to quit Xcode or if you haven't already learned Git. For instance, that sharp scalpel will delete all new files.

Apple has forgotten the courtesy of always inviting you to undo what they misunderstood

<= The View Controller Source File

<= Open Your Storyboard

Notice Editor is not Edit

Yes, it's true, Xcode has one menu named "Editor" and another named "Edit", just to feed the pain of all humans who find those two words extremely similar.

Likewise, this very tutorial has this entire chapter named "Build the Basic UI" and also a subchapter also named "Build the Basic UI", as if naming a child after a parent.

Apple has forgotten the courtesy of giving totally different names to totally different things

<= Build the Basic UI

Distrust enough defaults

Editor > Canvas > Show Bounds Rectangles will shut off and stay off till you discover it.

Did you catch that? Xcode will choose to turn things off that you need before you discover they exist.

Xcode neglects its duty to give first preference to the newest guest

<= Build the Basic UI

Frequently correct the Zoom

Xcode frequently requires you to rework its zoom. They hide that choice inside of Editor > Zoom > Zoom To Fit. You can also find it if you right-click. You may notice there is a Zoom control you can click into, but it just gives you hard numbers like "75%", it rudely neglects to offer "fit".

Apple does think hard enough and talk long enough to mention you might need to zoom in, but they neglect to mention you often want to zoom to fit and you sometimes want to zoom out.

Xcode doesn't volunteer to show you what you need to see

<= Build the Basic UI

Expect Xcode will be slow to hear you

As often as they tell you press the Return key after you change something, they really mean it. Xcode can sit for hours without taking notice of your input, unless you make a point of pressing Return or clicking to highlight a different input.

Xcode doesn't limit how long it ignores you

<= Build the Basic UI

Let Apple waste some time

Apple pushes you into the Assistant Editor Preview as if it were useful.

It's not useful yet, but it will be useful. Take this one on faith. You'll soon learn to choose from a series of previews. The quickest previews are the least accurate, the slowest previews are the most accurate. This preview is not as quick as a glance over the storyboard, and not yet any more accurate, because your app is still too simple for that. 

Apple's gives you a good or fast experience in Xcode, never both at once

<= Preview Your Interface

Let Apple misuse technical words

For a piece of Swift code to "adopt a protocol" is a specific technical thing you'll soon learn. Apple's first mention of the word "adopt" has nothing to do with that specific thing. It's a strangely unnatural word choice, no kind of plain language.

Apple has forgotten the value of careful word choices

<= Adopt Auto Layout

Let Xcode lose your new constraints

Xcode really will casually discard all your input inside its Add New Constraints popup.

You have to read and understand the tutorial of how to work that popup, and only then go work that popup from start to finish. As often as you stop in the middle to switch focus back to the tutorial, you have to start over.

Apple has forgotten the value of stepwise improvement.

<= Adopt Auto Layout

Learn debugging later

Apple neglects to mention that the new constraints appear in the Outline View. Make time to find them there. Otherwise, you won't have any way to review your work. You won't know how often you wrongly accidentally create too many constraints, too few constraints, or some constraints with the wrong values.

Apple talks as if you're likely to have departed from their instructions far enough to make use of Update Frames, Resolve Auto Layout Issues, Reset to Suggested Constraints, and Choose Clear Constraints. Tell us if you do, I never have.

Apple has forgotten the value of immediate visual feedback

<= Debugging Auto layout

Download and compare

Apple does end this chapter, its chapter 1 of 10, with a download named "01_BuildABasicUI".

You can download that work and compare that work with yours. It will have the same "FoodTracker" name as your work, which can be confusing, so you might should make a point of forgetting about it, by choosing Xcode > File > Open Recent > Clear Menu.

If you know Terminal Diff, then you can get a lot of learning out of telling your MacBook to highlight every small difference between their work and yours.

cd ~/Downloads/01_BuildABasicUIcd ~/Documents/xCode-Projects/FoodTrackerdiff -burp ~/Downloads/01_BuildABasicUI .

The space-dot " ." on the end of those instructions is crucial, and easy to overlook.

Apple forgets to strongly recommend you compare your progress with theirs

<= Wrapping Up

Back up your progress

If you know Git, you should make the Source Control > Commit choice now. Your Commit Message could be "Build a Basic UI". This choice captures your progress now, so you don't lose it, so you can always come back to it. This choice moves the baseline, so you that Source Control > Discard Changes brings you back here, after now.

If you don't know Git, you've still got to find some way to capture progress. Odds on you can quit Xcode and copy the project folder to back it up. I haven't tried that, but it looks like it works.

Mostly, if you're coding in 2017 without knowing Git, now is a good time to catch up. Xcode Source Control might be intuitive enough to pick up quickly. Tell us how it goes? Tell us if Xcode loses some of your work as you learn?

Apple leaves your Discard Changes defined to slap you all the way back to your beginning

<= Wrapping Up

Back | Forward | Source: Apple Developer >  Build a Basic UI

Jump Right Into iOS Apps

Welcome

Writing your first iOS App? Working thru Apple Developer > Jump Right In?

Take our map of their pitfalls with you.

Jumping right in to their tutorial is a good idea, because Apple has solved the technical part of how to invite you in to win. They've picked out a quick simple path thru a huge swirling blizzard of details that could distract you. Work thru just 4 chapters and you have an app up and running. Work thru just 9 chapters and you have an app that remembers stuff even when you turn off the iPhone.

What they've left broken is a small flood of misleading details, placed to trip you up: things that scream and scream a lie: the lie that this is not for you. In reality, you'll soon be skilled enough. You won't need any more help from us after you begin to know more and more of what Apple imagines they told you to know, and actually forgot to mention. You might be good on your own as soon as the 3rd chapter. Tell us how it goes?

Apple has lost the knack of keeping discovery simple

Jump right in

iOS Apps for your phone should be easy to write, because free speech. Apple knows this truth so well as to invite you and me to jump right into their free tutorial.

Apple Developer > Jump Right In 

Here we tell you how they've set you up to fail. Read this blog, and you won't waste so much of your life on reverse-engineering every trap that they've laid for you.

We are strong, because public - they are weak, because corporate

Don't go learn Swift

Fair enough, you must go learn Swift first if you and all your friends don't already know Python or Java or C++ or some other object-oriented programming language of this 21st century. Fair enough, you should learn Python or Java or C before you learn something messier.

But if you do know about programming objects, then you don't have to go learn Swift before you ship your first app. You will find Swift quirky, but no more quirky than all the rest of Xcode: InterfaceBuilder, Cocoa, ObjC, and so on and on.

Some feel no shame in speaking of an "implicitly unwrapped optional variable of type"

Do download Xcode

Download the Xcode App from the App Store, into your Mac OS X.

If you have no Xcode, this is an easy and obvious choice, you are blessed. Otherwise, this choice is your first pitfall. For instance, the Terminal App you open in 2017 can fool you into downloading a 2015 Xcode 7.3.1 (7D1014) onto a 2016 macOS Sierra.

Ask me how I know.

The surprise is that you have to work to get the latest. The joy is that it's easy. Just go visit the App Store and pull it down. Don't settle for less than Xcode 9.0.1 (9A1004) in 2017, demand a new free Xcode 10 in 2018, and so on.

Many people know today as 2017, a proud few know today as the year of Xcode 9

Don't expect documentation will exist

All the pain of you running one Xcode while Apple talks of another, all that pain will be ours to share here.

Apple should show their respect for free speech by keeping up with the times. They should ship an insanely great tutorial as part of each Xcode. They did ship the Xcode tutorial for Sep/2015 in Sep/2015. They did ship the Xcode tutorial for Sep/2016 in Dec/2016. They still haven't yet shipped the tutorial for Jun/2017, and it's Nov/2017 now.

You can run the latest Xcode on the Mac you have, & talk out your pain with all of us here. Me, I first tried this on a macOS Sierra 10.12.16 with Xcode 9.0.1 (9A1004). But get this: I'm still happy to talk with you, no matter your choice of what version to run.

Apple hasn't found the discipline to write their doc before they ship the code

Don't match your version to theirs

Apple has somehow chosen to come off as dishonest. They lead with an unbelievable story. They pretend you can easily match your version to the version they bothered to document. They pretend you can then easily adjust to run something more current.

You can diss their nonsense, as quickly as you learn to pick it out

Get ready to spend money

Apple lets you write apps, run them, and screen-shot them on a good slow simulator of an iPhone. All for free, bundled into your Mac OS X.

But the Apple security on your iPhone will lock you out from running your own apps, except while you subscribe as an Apple Developer. That's like US$100 per year, plus sales tax, plus surrendering your anonymity.

Somehow they don't mention the full price up front



Back | Forward | Source: Apple Developer > Jump Right In

Blogspot met Pat

"You should blog", she told me.

"I like signal, I don't like noise."

"You can only write enough nonfiction if you write much too much at first, and then cut it back, like a sculptor shaping stone."

"Ok, I can do that. Hobbits like to fill the web with things that they already know, set out fair and square with no contradictions."

For instance:

Google Search: Pat+AND+silence

Sources: NIST, JDidion, JRRTolkien