In the past few posts I’ve discussed the development tools I dislike and like. In that order, because you should always open with bad news. Now, if like to discuss a couple development tools I wish existed.
For those of us in the objective c development circles, reference counting isn’t something we have to consciously think about anymore. At least, not very often unless using a non-ARC enabled library. Which, really, that needs to be updated.
Anyhow, because of that, many developers completely ignore the still existent need to understand the retain/reference count for any of your objects. The need to know this is because different libraries will copy a reference on instantiation of a new object; others just point to the original parameter. That behavior is relatively consistent across Apple provided APIs, but third party libraries are not as consistent. Then there is the magic of blocks and block based APIs.
So what is the issue? The issue is that it can be relatively easy to create code that accidentally leaks memory because objects do not become released as expected. Often this is due to an unintended retain cycle (A retains a reference to B which retains a reference to A so neither can ever be released). As mentioned, blocks are some of the biggest culprits due to their nature (A retains a reference to a block which references either A directly or a property of A).
What do I want to do to solve this? I would love for there to be a tool that can map what objects are currently retaining which other objects. Ideally this in the form of a “mind map” kind of visual presentation. I’d be happy with a
recursiveDescription style console output. For this to be useful, the output would need to be symbolicated to the point where the objects have the names used in code (where possible). Blocks would pose an issue, though it could be solved by using only named blocks instead of anonymous code. The challenge of developing this code is that currently there is no way to know what object is calling
retain on another object, or from the other direction it isn’t possible to know from the receiver who made the
retain call. One way that I can think to make this work for a bit would be to swizzle the
retain call you are interested in. Then inside the swizzle you could try to recourse the call stack to try and determine where the call originated. There are many potential issues to work through: deep call history, private objects making the call, not actually being directed to the real called, only method names. However, it should be possible to work around most of these, but I don’t have the time myself to do it. 🙁
code based interface builder
This issue is related to my distaste for Xcode. Anymore, iOS and OSX developers use Xib/storyboard files to define the interfaces of their apps. The reason is that Xcode provides a built in visual drag and drop interface. However it is very limited.
The limitations are many.
– it is sluggish. Opening an Xib file brings Xcode to a complete halt for multiple seconds. And that is only worse for storyboards. Stopping the IDE ruins the flow of development.
– it is not human understandable. The Xib and storyboard files are XML format and this human readable, but they are far from intelligible. The format makes use of many properties to allow the dark magic used to build the actual ui as the app runs, but they are not spelled out anywhere. The files are not cvs friendly because of useless changes made just by opening the file.
– the layout is relatively basic. The interface exposes many functions of laying out a view, but nothing too dynamic. Spacings and alignments can be set to constant values even though percentages are perfectly valid.
My solution is an IB replacement that produces code that will be placed in the
viewDidLoad methods (and maybe
layoutSubviews). The interface of the tool would be pretty similar to the current IB with a drag and drop method of development. The largest gain would be that all important properties of a given element could be exposed for modification which would then be put down in code that is easily checked and understood. Additionally, the concept of IBOutlets would be removed. All objects are available in the class as instance variables (though maybe that would be tweaked). The advantage of this is that the developer can then add and remove publicly declared
@property variables and methods.
In the end this style of interface development would provide the developer with more control over the UI. It would be easier to use source control, it would encourage better programming practices, should retain accessibility for designers, and be more maintainable across os versions.