Recently I have migrated an old project of mine from Objective-C to Swift. It was not that difficult and it worked out fine, and I was eager to see how the performance of the migrated system would turn out. How big was my disappointment when I saw that the Swift version of my system was at least a factor of 10 slower than the Objective-C version with unchanged functionality. That can’t be true, I thought and debugged at little bit.
Trusted Domains in NextCloud
Recently I installed NextCloud as a common storage for our choir on some hosted server. Everything worked fine beside the usual little problems during installation procedures. Also my fellow choir members were quite happy with new system but a few of them were complaining that they could not login to the NextCloud. The error message they got was something like „Access through untrusted domain“. Well, I could not imagine what happened here. The SSL certificate was correctly installed and valid. And why did it happen only to a few of them and not all? Weiterlesen
UIDocumentBrowserViewController and External Storage
Some time ago I’ve ported the old and ancient strategy game „Empire“ from macOS to iOS. On macOS I decided to make the game document based. Since the game may last many hours (or even more), it is necessary to store the state of the game in some kind of document to continue it in a later session. On start-up of the game it tries to re-open the last used document. That’s quite easy with the recentDocumentURLs array of the NSDocumentController.
But for iOS such a facility is missing. There is no such thing as a „UIDocumentController“ and the UIDocumentBrowserViewController tells you nothing about recently opened or created documents. I wanted to make the iOS version of Empire document based as well to enable anytime switches between the iOS and macOS version of the game. That’s especially interesting, if the game document is stored on some external server (like iCloud).
LinkedList: NSCoding protocol
In my previous post I’ve explained that the new Codable protocol of Swift 4 has some problems with references to objects (i.e. class instances). Or, better said, the two implementations of coders available
- ProperListEncoder/PropertyListDecoder
- JSONEncoder/JSONDecoder
have this problem: they expand all references to new objects and create doublets if references in the object tree occur more than once for a single object. In the case of loops in the object tree (references of objects to each other) the encoding leads to an endless loop.
The old NSKeyedArchiver/NSKeyedUnarchiver of the Objective C-world do not have this problem: they respect references and restore them correctly at unarchiving. So, I want to implement this old way, i.e. the NSCoding protocol in my LinkedList as well. Remark: LinkedList uses references to its payload as well even in loops but that is taking care of even in the use of the Coding protocol.
LinkedList: Codable protocol and references
Maybe you have read my series of posts about LinkedLists. It was great fun for me to put these things together, but recently, I stumbled over a problem with serialisation, esp. the Codable protocol and references to objects. In Swift 5 there are two Encoder/Decoder pairs available:
- PropertyListEncoder/PropertyListDecoder
- JSONEncoder/JSONDecoder
It turns out that these encoders are not really suitable for archiving object graphs because they expand all references to objects, i.e. put the objects instead of the references in the archive. If you have a simple tree of objects and you do not care about doublets that may be fine but as soon as you have loops in your object graph you are in trouble. Encoding such a graph with these two encoders lead to an endless loop. This may happen quite frequently; just think about delegation where you typically have references of the delegate and its master against each other.