I'm in xCode 9, looking at the Interface Builder.
If I double click it, it'll zoom to really really big or really really small.
How can I control the zoom level that I'm looking at?
This isn't really relevant to Swift. You're asking about Xcode.
That said, you can use the pinch-to-zoom gesture if you have a trackpad, or click the plus and minus buttons at the bottom of the storyboard editor. There's also a number there, showing the current zoom lever, e.g. 100%. You can click it and choose among several options.
But please refer to the Apple Developer Forums over at https://forums.developer.apple.com/ for questions like this, that have nothing to do with Swift.
Thanks for the response & for the link.
I'll sign up to that one and start asking Swift questions here, xCode questions there.
From my perspective, they go together and I was surprised that I couldn't find a forum HERE on xCode.
I did find the +/- buttons. Thanks
Yes, iOS app development, Swift, Foundation, UIKit, Xcode, etc are often confounded with each other, because they overlap a lot. It is common to refer to an iOS app developer as a Swift developer. It's not exactly wrong, but it isn't very precise either.
Swift is a programming language with a corresponding compiler and a fairly small standard library. Swift is a general purpose programming language, that can be used for both systems programming and application programming. And even scripting and used with an interactive interpreter on the command line.
Swift interoperates seamlessly with Objective-C and C and allows you to import any Objective-C framework. Since both the iOS, tvOS and macOS SDKs are just a bunch of Objective-C frameworks, it is easy to use Swift with these SDK. In fact, Apple encourages you to do so. Therefore, Swift has rapidly become the de-facto programming language for iOS app development.
Nonetheless, Swift is really independent from all of that. In fact, most of the functions and types you'll use with Swift, aren't really even Swift features. They're only available if you either import UIKit or import Foundation, which are Apple frameworks.
This forum, for the most part, is about Swift-the-language, and not Swift-the-app-developement-tool.
And Xcode is an entirely different beast, independent from all of this.
Again, you probably want to check out the Apple Developer Forums, or maybe even Stack Overflow, for questions regarding app development.
Ack! I didn't realize I actually posted this.
I was (obviously) just ranting.
I'm going through a tutorial. A line of code was:
var myURL = "http://the-actual-url" as String
I'm finding all kinds of crazy things.
I just learned about #selector
Sheesh myObj.myFunc() or static myClass.myFunc()
why all the to do? (rhetorical)
this too:
return (theDataOb.theData?.count)!
imho - rediculous
If something might be null, with or without all the ? & ! stuff I have to deal with it.
Maybe the compiler isn't too smart but all the ? & ! doesn't help ME at all.
if(myThing != null) {use it}
OK I quit. Thanks for listening
Thanks for the reply, that helps:)
It should never be required to write "this is a string literal" as String. There are occasionally times when you'll need to cast an Objective-C string to a Swift string, but string literals are always going to be inferred as a String.
That's the point. Not everything inside double quotes is a String. For the stdlib it also can be a Character or a SubString. For Foundation it can be an NSString or NSMutableString.
Aaaaand, the fun part is: you can make your own custom types, that can be instantiated with a sequence of character inside double quotes.
Once you understand the reasoning behind it and how that fits together it's quite good. But it takes some time learning swift to get there… ;)
Trash this tutorial!
(at least If this as String is not part of some deeper introduction into the type system)
Totally off topic, but I'd love a simple example of how a custom type can be "instantiated with a sequence of character inside double quotes." It just sounds interesting!
A code example with a primitive point like type Foo:
struct Foo {
var x: Int
var y: Int
}
extension Foo: LosslessStringConvertible {
var description: String {
return "\(x):\(y)"
}
init?(_ description: String) {
guard
case let parts = description.split(separator: ":"),
parts.count == 2,
let x = Int(parts[0]),
let y = Int(parts[1])
else { return nil }
self.x = x
self.y = y
}
}
extension Foo: ExpressibleByStringLiteral {
typealias StringLiteralType = String
init(stringLiteral: StringLiteralType) {
guard let me = Foo(stringLiteral)
else {
preconditionFailure("Could not instantgiate from StringLiteral")
}
self = me
}
}
extension Foo: Equatable { }
var foo1 = Foo(x: 2, y: 3)
var foo2 = Foo("2:3")
var foo3 = "2:3" as Foo
var foo4: Foo = "2:3"
foo1 == foo3 // true
foo2 == foo4 // true
In the foo3 and foo4 case you need to explicitly tell what type this "sequence of characters inside double quotes" shall have. But it is not a String but your own custom type! ;-)
1 Like
Well unless someone has overridden the typealias the compiler uses to determine the default literal type. In which case string literals won’t be a String type.
Well, you guys have me curious now.
What is this: typealias good for?
Also, isn't an alias just another name for the same type (that is, isn't it still just a String?)
Very cool. I hope to make some use of this. Thanks!
1 Like
No, a type alias is a new name for an existing type. It's basically a C typedef.
For instance, once you do: typealias Byte = UInt8 Then Byte will refer to UInt8 elsewhere in the program.
The Swift standard library includes a typealias StringLiteralType = String, which (among other things) determines what string literals get inferred as. If you define your own type alias for StringLiteralType then it'll will infer that instead (which is a bit of compiler magic, since type aliases don't usually work like that).
Type aliases can also be generic: typealias List<T> = Array<T> will make any List<T> be an array of T.
It can be very helpful for types that are long and awkward to type, or that might reasonably be their own type semantically but aren't worth writing a wrapper type for. It's also useful for specifying associated types for protocol conformance.
1 Like