Why I Love Swift: Functional Programming

Apple’s Swift language, which is not even a year old, has grown on me in ways I would never have expected. Partly, that’s because it has opened my eyes to ways of programming I was unaware of.

One of the programming paradigms that Swift forced me to at least look at was functional programming. What’s functional programming? Well, here’s a post by Guanshan Liu, Functional Programming in Swift, that does a much better job than I could ever do. And there’s a great book, Functional Programming in Swift. Simply put, functional programming allows functions to be used as parameters within a function call. Is that very useful or just another egg-head, ivory-tower CompSci methodology that no app developer really needs? Hardly.

Let’s say within a HomeKit app I’m creating that I have an array of accessories (home-automation devices) and their services. Now, that and a nickel won’t get me a cup of coffee nor do much for any user of my HomeKit app. So I want to use the list of the services’ serviceType, mind you in the same order as Apple’s service types supported by HomeKit’s Accessory profile, and the devices that have those service types. Hmmm… Continue reading

Advertisements

HomeKit Singleton Thoughts & Code

Apple’s HomeKit API is pretty cool. For one, HomeKit comes with its own data model and store, one that likely will be shared across a person’s devices via iCloud. That’s very cool.

But if you’ve started playing with HomeKit’s HMHomeManager, you might have noticed that there are cases where a singleton containing, or of, the HMHomeManager would be a good idea. That’s because changes that might occur to the Home Manager in one part of a HomeKit app may not be reflected in another part, or on another device. Such as…”Where’s the room and 10 devices I just added to my home?!?!” Oops! Customers hate that.

So you need a singleton. The next issue is a singleton of what? One route is to create a delegate to act as a singleton. This delegate could contain an array of HMHomeManager type instances, some to serve as “scratch pads” and others as set as the Home Manager. Another route is to create an instance of HMHomeManager in the AppDelegate since (hopefully) you only have one of those running around in an app. And then there’s just creating a custom class to represent HMHomeManager. It is this last option on which this post focuses.

Apple includes a nice little HomeKit sample app, HMCatalog. One of the nice things included in that sample code is a HMHomeManager singleton. Since it’s in Obj-C, I took the liberty of writing it in Swift. Here’s the code:


let HomeStoreDidChangeSharedHomeNotification: String    = "HomeStoreDidChangeSharedHomeNotification"
let HomeStoreDidUpdateHomeNotification: String          = "HomeStoreDidUpdateHomeNotification"




class HomeStore: NSObject, HMHomeManagerDelegate
{
    static let sharedInstance = HomeStore()
    
    var homeManager: HMHomeManager
    var homeQueue: dispatch_queue_t
 
    var home: HMHome{
        get
        {
            var oldHome: HMHome     = self.home
            var newHome: HMHome?
            
            if let aHome = self.homeMatchingName(oldHome.name)
            {
                newHome     = aHome
                self.home   = newHome!
            }
            
            if (oldHome === self.home) && (newHome != nil)
            {
                self.alertForHomeDidChange()
            }
            return self.home
        }
        set(newHome)
        {
            if newHome == self.home
            {
                return
            }
            
            dispatch_async(self.homeQueue, {
                self.home   = newHome
                self.alertForHomeDidChange()
            })
        }
    }
    
    
    
    class func sharedStore()-> HomeStore
    {
        return sharedInstance
    }
    
    
    override init()
    {
        self.homeManager            = HMHomeManager()
        self.homeQueue              = dispatch_queue_create("com.portablefrontier.PFHouseWorks.HomeQueue", DISPATCH_QUEUE_SERIAL)
    
        super.init()
    
        self.homeManager.delegate   = self
    }
    
    
    /*
    func home() -> HMHome
    {
        var oldHome: HMHome     = self.home
        var newHome: HMHome?
        
        if let aHome = self.homeMatchingName(name: oldHome.name)
        {
            newHome     = aHome
            self.home   = newHome!
        }
        
        if (oldHome === self.home) && (newHome != nil)
        {
            self.alertForHomeDidChange()
        }
        return self.home
    }
    */
    
    
    /*
    func setHome(newHome: HMHome)
    {
        if newHome == self.home
        {
            return
        }
        
        dispatch_async(self.homeQueue, {
            self.home   = newHome
            self.alertForHomeDidChange()
        })
    }
    */


    func homeMatchingName(name: String) -> HMHome?
    {
        for aHome in homeManager.homes
        {
            if name == home.name
            {
                return home
            }
        }
        return nil
    }


    
    //: NotificationCenter Functions
    func alertForHomeDidChange()
    {
        dispatch_async(dispatch_get_main_queue(), {
            NSNotificationCenter.defaultCenter().postNotificationName(HomeStoreDidChangeSharedHomeNotification, object: self)
        })
    }
    
    
    
    func homeManagerDidUpdateHomes(manager: HMHomeManager)
    {
        NSNotificationCenter.defaultCenter().postNotificationName(HomeStoreDidUpdateHomeNotification, object: self)
        
        if let aHome = self.homeMatchingName(home.name)
        {
            self.home    = aHome
        }
    }
}

Xcode Issues: How To Work-Around An Ineligible iOS Device

There may come a day, a sad day, when you install the latest version of Xcode, plug-in you iOS device, wait for it to appear in the list of scheme supported devices, and…nothing. Then you click on the scheme pull-down menu and see the following,

Xcode Ineligible Device Post 03 15 2015 Img 1

How did your iOS device become ineligible for development? Well, I don’t know and nobody else seems to have an answer. But there is a work-around Continue reading

Xcode 5 Notes

Some migrating their iOS projects over to Xcode 5 but not converting their project’s xib(s) or storyboard(s) might notice that the performance of Xcode drops when trying to edit those files. Looking in Activity Viewer, it isn’t Xcode that is taking-up all the cycles, but a tool, Interface Builder Cocoa Touch, that has now gone from using its normal smidgen percentage of CPU to over 60%! This will make editing a storyboard or xib very painful.

A search of “Interface Builder Cocoa Touch” will not result in links that address this is issue. After all, Xcode 5 has only been publicly available since today. So what to do?

The problem is the Interface Builder Document settings for the iPhone Storyboard or xib in which the performance is laggy.

Start by looking in the File Inspector of each storyboard in which the performance problem exists. It is likely that the storyboard Interface Builder Document setting was set for “Xcode 4.6”. That is, as it turns-out, bad. Changing the IB Default Document setting of the xib or storyboard to “Default Xcode 5” will fix the problem. Once you make that change, the Interface Builder Cocoa Touch tool will return to its sipping of only a few threads and using 0.0% of the CPU.

BrokenFang Progress 7 January 2007

The task I have been dealing with for the last day or so is how to allow the user to set–or not–a background image, then add images, if they like reset the background image and NOT have that NEW background image cover the previous images. Almost have it licked. So far, my thinking has been to accompany any images loaded, after the initial background image is loaded, with an off-screen loading of those images. So, when setting a new background image, I wipe the window, load a new background image, then redraw the window–atop the new background image–from the off-screen window using Quartz Layers.

I’ve also been looking into CoreData lately since it might be a nice way to manage the various images being loaded/unloaded. I’ve never worked with CoreData, but those who have say it is liberating…once you get past the learning hump, which is a bit high since the only textbook on it is Apple’s documentation. Like the docs for Cocoa Bindings, which CoreData meshes with very closely, the docs for CoreData trend towards the theory and not the practice of using this stuff.

I may switch everything over to Leopard since there’s a rumor that the NSImage and like Cocoa classes have been bolstered under 10.5. Will have to wait and see.