Lately, I’ve been seeing a number of half-baked implementations of a function that splits a floating-point number (Floats, Doubles, and the like) into a whole number and fraction part. For example, given the value 3.141592, it should return:
// modf returns a 2-element tuple,
// with the whole number part in the first element,
// and the fraction part in the second element
let splitPi = modf(3.141592)
splitPi.0 // 3.0
splitPi.1 // 0.141592
Since C doesn’t have a tuple type, you call modf differently. Here’s the function’s signature:
double modf(double x, double *integer)
Its return value is the fractional part, and the whole number value is put into an extra variable whose address you provide. If you’re working in Swift and feeling homesick for the pointer-y stuff you have to do in C, you can call modf this way:
var wholeNumberPart: Double = 0.0
let fractionalPart = modf(3.141592, &wholeNumberPart)
fractionalPart // 0.141592
wholeNumberPart // 3.0
But seriously: do it the first way. It’s more Swift-like (Swift-esque? Swifty?).
“Well, the Empire doesn’t consider a small one-man fighter to be any threat, or they’d have a tighter defense. An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station. But the approach will not be easy. You are required to maneuver straight down this trench and skim the surface to this point. The target area is only two meters wide. It’s a small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system. A precise hit will start a chain reaction which should destroy the station. Only a precise hit will set off a chain reaction. The shaft is ray-shielded, so you’ll have to use proton torpedoes.”
Click the photo to see it at full size.
For those of you who don’t remember the film, here’s the original still:
Click the photo to see it at full size.
For those of you who are insatiably curious (and hey, if you’re reading this blog, the odds are good that you are), here’s Larry Cuba explaining how he made the computer graphics for the Death Star briefing in Star Wars. Remember, this was the 1970s!
Which is the quickest, and most efficient way to concatenate multiple strings in Swift 2?
// Solution 1...
let newString:String = string1 + " " + string2
// ... Or Solution 2?
let newString:String = "\(string1) \(string2)"
Or is the only differentiation the way it looks to the programmer?
It’s not worth worrying about the speed of string concatenations when you’re doing them, once, a dozen, a hundred, or even a thousand times. It may start to matter with larger quantities of larger strings. I decided to run a quick and dirty benchmarking test, which you should take with the appropriate number of grains of salt. Here’s the important part of my code:
let string1 = "This"
let string2 = "that"
var newString: String
let startTime = NSDate()
for _ in 1...100_000_000 {
// Here's the concatenation:
newString = string1 + " " + string2
}
print("Diff: \(startTime.timeIntervalSinceNow * -1)")
You may have noticed that I used _ (underscore) characters to make the size of the for loop, 100000000, easier to read, just as we in North America use commas and people elsewhere use spaces or periods. Swift, along with a number of programming languages, lets you do this — take advantage of this and make your code easier to read when dealing with large numbers!
Using the + operator to concatenate strings as shown in James’ example, here’s the average time as reported by the app running in Debug mode over a dozen runs:
1.4 seconds on the simulator on my MacBook Pro (2014 15″ model, 2.5GHz i7, 16GB RAM), and
1.3 seconds on my iPhone 6S
Then, after changing the line after the Here’s the concatenation comment to:
newString = "\(string1) \(string2)"
I ran it again and got these results over a dozen runs:
50.9 seconds on the simulator
88.9 seconds on the iPhone 6S
Running on the phone, the + method is almost 70 times faster, which is a significant difference when concatenating a large number — 100 million — strings. If you’re concatenating far fewer strings, your better bet is to go with the option that gives you the more readable, editable code. For example, this is easier to follow and edit:
"Hello, \(userName), and welcome to \(appSectionName)!"
than this:
"Hello, " + userName + ", and welcome to " + appSectionName + "!"
In this article, we’ll look at responding to user’s touches on the screen.
Set up a new project
It’s time to do the File → New → Project… dance again! Open up Xcode and create a new Game project:
When it comes time to name the project, give it an appropriate name like RespondingToTouches (that’s the name I gave my project).
Once again, we’ll set the game to that it’s landscape-only. The simplest way to restrict our app’s orientation to landscape is by checking and unchecking the appropriate Device Orientation checkboxes in the app’s properties. Make sure that:
Portrait is unchecked
Landscape Left and Landscape Right are checked
Click the screenshot to see it at full size.
You can confirm that the app is landscape-only by running it. It should look like the video below, with spinning spaceships appearing wherever you tap the screen. It shouldn’t switch to portrait mode when you rotate the phone to a portrait orientation:
Making the spaceship go to where you touch the screen
It’s time to make our own interactivity. Let’s make an app that puts the spaceship sprite in the center of the screen, and then has the spaceship sprite immediately go to wherever the user touches the screen.
Open Gamescene.swift and replace its code with this:
First task: drawing the spaceship sprite in the center of the screen. Before you look at the code, see if you can do it yourself. There’s enough information in the previous article to help you do this, or you can follow these hints:
A sprite is an instance of the SKSpriteNode class, and given the name of an image, you can instantiate one by using SKSpriteNode‘s init(imageNamed:) method.
A game scene’s didMoveToView method is called when the scene is first presented, and it’s the perfect place to do things like setting sprites in their initial locations.
A sprite’s location onscreen can be set using its position property, which is of type CGPoint, a struct that holds 2 Floats: one for the x-coordinate, and another for the y-coordinate.
The frame of a scene is the rectangle — a CGRect — that determines its bounds. You can get its width and height through the properties bearing those names.
You might want to scale down the spaceship sprite to one-third of its size. The setScale method will do that.
To display a sprite in a scene, you need to use the addChild method.
If you were to touch the screen, nothing would happen. That’s because there’s no code to respond to touches on the screen…yet! We’ll start by adding code to the touchesBegan method.
touchesBegan is called when the user puts a finger on the screen. It provides information about that touch action in its touches<c/ode> argument, a Set of touch objects, which are instances of the UITouch class. One of the properties of UITouch is locationInNode, which is a CGPoint. Given that sprites have a position property that is also a CGPoint, you've probably already guessed what we're about to code.
The default setting for multitouch in an app is “off”. We want to keep things simple for now, so we’ll just go with the default, which means that the app will register only one touch at a time, which in turn means that touchesBegan‘s touches argument will only contain a single touch object. We’ll retrieve that object from touches by using Set‘s first property.
Try coding it yourself before looking at the code below:
If you run the app, you’ll see that the spaceship jumps to wherever you put down your finger:
Making the spaceship go to where you released your finger
You’ll notice that if you hold your finger on the screen and move it about, the ship doesn’t follow your finger. It just stays where you first touched the screen and doesn’t move until you remove your finger and touch some other point.
The name touchesBegan implies that it has a counterpart method for when the user releases his/her finger from the screen. That method is called touchesEnded, and it takes the same arguments as touchesBegan.
Start typing touchesEnded into GameScene, and Xcode’s autocompletion should make it simple for you to set up a touchesEnded method. Cut the code from touchesBegan and paste it into touchesEnded, like so:
Note what happens: the spaceship doesn’t move when you touch the screen until you remove your finger. Only when you release your finger does it move, and it jumps to the location where you released your finger from the screen. Try touching the screen, moving your finger to another location on the screen, and then releasing your finger.
What if we put the same code into both the touchesBegan and touchesEnded methods, like this?
If you run the app, the spaceship now jumps to the location where you made initial contact with the screen, and again to the location where you released your finger.
Making the spaceship follow your finger as you move it
You’re probably wondering if there’s a method that responds to changes that occur between the touchesBegan and touchesEnded events, something that lets you track the movements of the user’s finger as it moves on the screen. There is, and it’s called touchesMoved. It takes the same arguments as touchesBegan and touchesEnded, which means that it should respond to the code that we put into those two methods. Copy and paste the code from either touchesBegan and touchesEnded and paste it into touchesMoved. Your code should look like the following:
You’ll find that the spaceship jumps to the location where you touched the screen and as long as you keep your finger on the screen, you can drag it around. When you release your finger from the screen, the ship stays at the location where you released your finger.
Let’s refactor the duplicate code in touchesBegan, touchesMoved, and touchesEnded into its own method, handleTouch. The code will now look like this:
Let’s combine this article’s lessons with the ones from the last one. Can you create some actions that make the spaceship pulsate as long as the user presses on the screen, as shown below?
Before you look at my solution below, see if you can’t code it yourself first:
You may have noticed that in the touchesEnded method, the spaceship sprite is restored to its normal scale with an action rather than by simply setting its scale using the setScale method. I found that simply setting the spaceship back to its normal scale with setScale a little too abrupt; restoreScaleAction makes the transition very smooth.
What we just covered
In this article, we covered:
A recap of:
Starting a new Game project in Xcode
Restricting an app’s orientation to landscape-only
Drawing sprites at a specified location on the screen
Responding to the event where the user touches the screen with the touchesBegan method
Responding to the event where the user stops touching the screen with the touchesEnded method
Responding to the event where the user moves his/her finger while touching the screen with the touchesMoved method
Combining actions with touch events for interesting visual effects.
In the next article in this series, we’ll look at moving player characters around the screen.
Here’s the story:Business Insider has posted a story with the lengthy title Apple’s gigantic iPad Pro outsold Microsoft’s entire Surface lineup last quarter — and it was only on sale for 6 weeks. They report that with a November 11 release date, Apple had only 6 weeks of the fourth quarter of 2015 in which to sell the iPad Pro, and in that time, they sold over 2 million units. In twice the time, Microsoft managed to sell fewer units of their entire Surface line: 1.6 million of them over the entire fourth quarter.
Here’s the story hidden inside that story: Like most online news outlets, Business Insider tries to squeeze a few more clicks and pageviews out of you by providing links to related stories also on their site. For this story, here are the articles they linked to:
…and here are the IDC numbers they cited. Because Business Insider is really in the clicks-for-money business and not the “informing you” business, they made do with a crappy screenshot of IDC’s table of 4Q 2015 tablet sales:
Business Insider‘s reporting on the shrinking tablet market is correct. From 2014 to 2015, tablet sales shrank by 10.1%, with Huawei as the only top 5 vendor seeing growth. As for their prediction of the iPad’s Pro’s impending doom: if this is doom, I’d like some of that action, please!
