I few days ago I found a podcast about protocols in swift. Finally I had time to listen to it. It is a great one, produced by Ray Wenderlich. I recommend to listen it to everyone who wants to know more about the topic. You can find it here: http://www.raywenderlich.com/120655/protocols-in-swift-unity Enjoy.
Recently I ran into a weird issue: I had to create an ad-hoc build, but the archive landed in the “Other Items” section in the Xcode’s organizer instead of iOS Apps. Therefore I couldn’t distribute the build.
The issue was that in the Info.plist of the archive the ‘ApplicationProperties’ key is missing. This contains some info about the app. And if it is not present, then the Xcode can’t interpret it as an iOS app.
I had searched for the issue and found several solutions. I tried everything I could: setting skip install to NO for the main project target and skip install to YES for the sub-project targets; making sure sub-projects have Copy Headers in Project, not Public etc. Nothing worked.
Finally I found out that the issue is only reproducible in Xcode 7 and using Cocoapods version 0.38.2. This was a good starting point. Everybody suggests that downgrading Cocoapods resolve the issue. However, these suggestions were made before launching version 0.39.0 as a stable version. So I recommend upgrading it to the newest version. I re-installed the pods, just to be sure I have nothing from the old version left.
Recently I read about socket.io. Basically it enables event-based communication between a server and a client. The server side is written in node.js, and they have a lot of client libraries in different languages. The server is open source, under MIT license. You can download it from Github: https://github.com/socketio/socket.io. The concept is really interesting, so I started looking for a solution in iOS.
You can find a few socket.io client libraries out there written in objective-c. But as it turned out, socket.io had released their own client library for iOS. So you should definitely use that. I was more than happy to see, that the library is written is Swift. They also provide objective-c interface. So I fired up Xcode and started a test project. In this article I will show you how to use the library.
A few days ago I came across an interesting article, about the libraries used in the top 100 iOS apps. Personally I was a bit surprised: I was expecting some libraries to “perform” better. Anyway it is an interesting article, I think it worth reading it:
“Why would I want generics?”
you may ask. And for good reason: often we use classes that works against arbitrary types. Apple makes it all the time. Just look at the NSArray or NSDictionary classes for example.
But lets see the benefits of using generics:
- When you use arbitrary type, there is nothing to prevent you to accidentally use a wrong object type. For example adding an NSString to a collection, but expecting an object when you retrieve the data. This may lead to nasty bugs, even crashes, that may be revealed at runtime only.
- Using generics enables code completion
- Using generics makes the object’s interface visible without cast. For example if I have a class named Foo that has a property named ‘status’, you could access that property for an simply by calling: [array objectAtIndex:index].status;