Swift Arrays - The Bugs, the Bad and the Ugly (and a best practice suggestion)

UPDATE 2: I've added a new post about the changes in Beta 3 (I like them)

UPDATE: Apple have indicated that the array behaviour in Swift is going to change - see this post

My previous post suggests an explanation for why the behaviour of Swift Arrays is as it currently (in the very first Swift release) is as it is. In this post I intend to explain the behaviours, show the problems and give examples. Many examples are based on those found in this thread on the Apple Developer forums. Feel free to add comments if I've missed any categories and I'll incorporate them if they form a different case.

The relevant part of the documentation covers most of the behaviour and apart from the issues specifically mentioned in the Bugs section at the bottom these are descriptions of the specification not just the implementation.

Is it Value? Is it Reference? No its Confused!

Swift Arrays - Too Swift and flexible for Our Good

UPDATE 2: I've added a new post about the changes in Beta 3 (I like them)

UPDATE - Apple have indicated that the array behaviour in Swift is going to change - see this post

Update 3: Please note that this article remains for the historical record and to ensure that links in other articles aren't broken but that the behaviour of Swift arrays was radically changed in Beta 3 and it resolves most if not all of the issues that I had with Swift arrays making the following essentially redundant. Update 2 above links to my follow up article reviewing the changes. You can also read several of my more recent articles about Swift. [This presentation about optimising Swift is particularly recommended and this article about mutating Swift arrays from multiple threads is on topic with this post. - Update 4]

I really like Apple's new Swift language. It brings in some of the best features of many functional languages including ML, to Haskell such as type inference, strong types, generic types and combines them with with an object system that can interoperate with the existing frameworks while still being fast and efficient. It encourages immutable values over variables and will eliminate whole classes of errors related to null pointers and improper handling of them.

The main thing that I don't like about it is the handling of "immutable" arrays. For performance reasons when an array is declared with "let" it means only that the array length is immutable and other arrays cannot be assigned to the same variable. You can however change any of the values in the array. I think that almost whatever the performance gains this is not worth the confusing behaviour that results. [Edit: Follow up post explaining the current behaviour is now available.]

In the post I will mix speculation and a little investigation of the behaviour to understand what the current behaviour is and the rationale for it. I also intend to propose a way out of the situation by which the behaviour could be changed with minimum disruption. Apple has indicated that source compatibility is not guaranteed to be maintained and I think automatic conversion would be possible to migrate code.

Hacking Constraints in Storyboard Files

When Interface Builder doesn't do what you want Hack the Storyboard XML

I like Autolayout and the concepts behind it. I also like using Interface Builder to see the relationships I'm creating but there isn't quite the right degree of flexibility and control (at least as of Xcode 5.1.1).  This post shows how you can convince Interface builder to do your will when it doesn't want to let you create quite the layout that you want you can directly edit the Storyboard XML to enable the effect that you want (and subsequently view it and tweak it in Interface Builder).

Fast Lists is much more stable on iOS 7.1

iOS 7.1 Strongly Recommended

Based on the (lack of) crash reports that I have received so far for Fast Lists iOS 7.1 is much more stable and most of the issues I had open were probably actually iOS bugs rather than Fast Lists bugs. So far I have received only two crashreports pertaining to iOS 7.1 and both are apparently the same (new) issue although I have not investigated deeply yet.

All Users should update to Fast Lists 2.04 ASAP (or 1.78 if you can't install iOS 7)

There a improvements and fixes in each release of Fast Lists, most of them minor but the newest version should be pretty stable. Fast Lists 2.0x versions are all pretty stable but if you are running a version earlier than 1.78 there are issues that will cause crashes and there is nothing to lose by updating.

To Apple employee that crashed Fast Lists 1.72 on 2nd April on an iPad

That is probably my bug please update to the latest Fast Lists, 1.72 had serious crashing issues although I obviously haven't tried it on the iOS version you are using which may resolve some of them.

Unexplained Crashs (in Fast Lists) Part 1 (and only for now) - UPDATE

UPDATE This crash seems to have stopped occurring since iOS 7.1 was release. At this time (4th April) I haven't seen any occurrences on iOS 7.1 when I was seeing it more about weekly on iOS 7.0x. Several other crash types have also not been observed on iOS 7.1 although two instances of a different crash have been seen.

Most software crashes sometimes and unfortunately this includes Fast Lists. At the moment I have records of 12 crashes in the latest version (2.04) that was released about a month ago (18th Feb). On many occasions crashes are clearly caused within the software I have developed whether due to my mistake or the libraries (both Apple and 3rd party) that I use having bugs and not and not behaving as documented.  This post is about several crash reports that appear to be occurring deep within Apple's code (although quite possibly due to my own incorrect software), it includes the crash reports very slightly redacted and what I have currently deduced about the cause.

I think the general interest in this post for non-developers will be pretty close to zero.

A Week with Docker

This is a bit of a brain dump rather than a fully polished and edited post, in the unlikely event it gets any significant viewership I’ll try to clean it up.

It is some initial thoughts and experiences with using Docker for about a week. Specifically I was getting JIRA up and running in Docker on Rackspace for my own use (and it directly receives crash reports from some of my iOS apps). I also used it on my home server to set up a build environment for a JIRA plugin.

Update - Rackspace Cloud Servers Advice

Rackspace Cloud Servers are currently configured with no swapfile. I strongly recommend following the instructions to create a swapfile otherwise once you hit the limit of your server memory it will kill a process (probably your biggest which could well be Java).

General Docker Thoughts

Docker is nice, new containers spin up quickly, the documentation is OK. It is still pre-1.0 so moving fast and much of the online articles about it are out of date already. This isn’t really the first place you should look for information so I’m generally not going to explain syntax or concepts except to give my understanding of the difference between images and containers.

Just written my first custom UIGestureRecognizer

HFRotationalPanRecognizer is for handling rotational drags and you can find it here. I needed it for a fixed wheel where the two fingered rotation would be inappropriate and confusing. It is suitable for wheels, dials and other fixed rotating issues.

It wasn't too bad once I had my head around it. This article and Erica's book (well I have the iOS 5 version) helped. The key things to remember are to set the gesture state for each move in the gesture as that triggers the update. I also used the same style as the UIPanGestureRecognizer for reporting the move by accumulating it through the gesture but allowing it to be reset by the handler for incremental updates.

I did have quite a bit of trouble sorting out the origin and finished with it settable but always in the superview's co-ordinate space.

UIDynamics - The gotcha!

Make sure you remove all behaviours before directly manipulating a View.

I've been using the iOS 7 framework in a little app I've been writing this week and I was having problems which turned out to be because I wasn't removing all the behaviours from the View before directly transforming it (while it was being dragged).

This includes behaviours that you wouldn't expect to be affected such as UIAttachment anchors pinning the centre of the View to the point which the direct transformation was rotating it. As soon as the dynamic behaviour wants to update the view it will put it where it thinks it should be ignoring all your transformations. Basically (probably for valid performance reasons) the UIDynamics ONLY reads the view's properties when behaviors are added to the view.

It would be nice if there was a call that you could make (either to behaviours or to the UIDynamicAnimator) to inform it of updates to a view so that it could refresh rather than tearing everything down and setting it up again, maybe iOS 8.

Github Expanding Diffs - Great new feature

Github has added a great feature (which Bitbucket already had but I'm excited about anyway).  When you are looking at a commit/pull request or diff it only shows the code immediately around the changes but now you can tap the icon in the gutter to see more code which can be really useful to help understand the commit.

See these screenshots of an example commit to SVGtoIcons. See previous posts for information about that project.