Access Control in Swift

Now since Xcode 6 Beta 4 Swift got some nice access control features we know a bit from Java. Now you can declare Classes, methods, properties, structs or enums with public, private or internal.

  • private entities are available only from within the source file where they are defined.
  • internal entities are available to the entire module that includes the definition (e.g. an app or framework target). Default behavior when no keyword is used.
  • public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.

You can even declare the write access to private but expose the read access.
This gives us more control we knew from Objective-C with read only public properties or exposed methods in the header file.

See more and examples here at Apple’s Swift Blog

Let’s build an iOS app in Swift and own frameworks: WikiLocation

[Update July 23.] Apple added access control in Beta 4 which means that I have to adapt the new behavior (explicit exposing methods for public access) for my example frameworks. Right now I’m traveling around. This will be done later in August. [/update]
Enough theory, enough reading in Swift. Now it is time to build a real app. With this blog post I will demonstrate Swift. This is not a tutorial how to build iOS apps from scratch. I assume that you are familiar with building iOS apps in Objective C. The purpose of this article is to explain some Swift features, pitfalls and patterns with code snippets.
What is this app about? The app’s name is WikiLocation. As the name implies, it uses your current location and provides you nearby Wikipedia articles. (Buildings, lakes and so on). Straight forward. Not too much magic.
This mini app covers ViewControllers, Views & Models in Swift and custom iOS Frameworks (modules) :

Continue reading

final and lazy keywords in Swift

final
Mark methods,classes and variables as final to improve the performance if you know that the method won’t be overridden.

final func printMessage(message:String) {
  println("Log: "+message)
}

 

lazy
Mark your variables / properties with lazy to initialize them when you access the variable / property the first time.

class ViewController: UITableViewController {

    lazy var geoManager = GeoManager.sharedInstance
    var dataSource = WikiArticle[]()

    override func viewDidLoad() {
        super.viewDidLoad()

        self.geoManager.start()
    }
    .....
}

The geoManager will be initialized lazy. That means that the instance for the property will be created when we access the property the first time (in viewDidLoad).
“You must always declare a lazy property as a variable (with the var keyword), because its initial value may not be retrieved until after instance initialization completes. Constant properties must always have a value before initialization completes, and therefore cannot be declared as lazy.”Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/de/jEUH0.l

But: Swift lazily initializes global constants (and variables) per default.

let theSharedInstance = Singleton()
class Singleton  {

    class var sharedInstance : Singleton {
        return theSharedInstance
    }
}

Xcode 6 – View Debugging

Xcode 6 has a really cool feature: View debugging – which means that you can visualize your app’s view hierarchy

  1. Print the whole view hierarchy in a list
  2. See the view stack in 3D
  3. Retrieve super detailed information and properties about your view
  4. ….But…you can’t modify the view’s properties like with Reveal. I assume that Apple will add this feature in the Golden Master of Xcode 6

Continue reading

Xcode 6 and Interface Builder – Cool Stuff

Now I see a lot of benefits in working with IB instead of custom UIView classes. (This should be the end of the good old debate IB vs Code.

  • @IBInspectable which gives you access to your custom class properties & @IBDesignable which updates your interface in IB in realtime without compiling the app and launching simulator. There is an tutorial here which goes into more detail. Add the @IBInspectable in front of your properties and change the value via the didSet observer.
    @IBInspectable var borderWidth:CGFloat = 0.0 {
        didSet {
            layer.borderWidth = borderWidth
        }
        } 

    Interface Builder properties
    from now on you can change the custom property in the Interface Builder.

    Add @IBDesignable in front of the class

    @IBDesignable class YourCustomCell : UITableViewCell {
    ..
    

    See your custom UI in real time without running the app. Note: You need to put the class with @IBDesignable in a framework.

  • iOS Frameworks – Now we don’t need to stick with static libs. Using capsulated frameworks including assets is a big win in iOS 8. It looks like that Apple is encouraging the developers to use frameworks as often as possible (also for UIView components)
  • View debugging:  Reveal like feature to display the view hierarchy  – Now in Xcode you can snapshot the current view hierarchy and inspect the stack in 3D like in Reveal. Continue reading