2

I have thousands of lines of chained animations code. I have moved it all to a GraphicsHelper class with references back to the data in my ViewController. Once I am through with the code I would like to jettison the class instance on the theory that I can keep memory (and my view controller code) small. The view controller stays in scope during the whole app which runs through several "phases". Is there a way to programmatically disconnect the class instance of the helper class? I have tried to assign nil but I get an error that the class does not conform to NilLiteralConverter protocol. Any way to disconnect the instance or an alternative to my perceived voluminous code problem? Thank you all in advance. Am I the only one in the world that wants to do something like this?

Sid Wyckoff
  • 83
  • 3
  • 5
  • Probably not, but Swift uses ARC and you cant fiddle in the same orchestra. So spoke Apple (at least id did think that). – qwerty_so Jan 06 '15 at 00:12
  • 1
    Have you identified that this class is creating an issue in terms of memory usage? Thousands of lines of code may equate to a few thousand bytes of instructions – Paulw11 Jan 06 '15 at 00:21
  • You can do non-ARC stuff in Swift if you really want to. That’s what `Unmanaged` is for. Course, you need to know what you’re doing and are responsible for the consequences of any screw-ups… The proposed solution below (_with_ the comment’s suggestion to use `?` _not_ `!`) is a better choice except in extreme circumstances. – Airspeed Velocity Jan 06 '15 at 01:57

1 Answers1

5

You need to declare the instance variable of your class as an optional,

class ViewController: UIViewController {
    var helper: GraphicsHelper!

    override func viewDidLoad() {
        super.viewDidLoad()

        helper = GraphicsHelper()
        // some time later
        helper = nil // no errors on this line, GraphicsHelper deinit called
    }
}
rdelmar
  • 103,982
  • 12
  • 207
  • 218
  • 2
    'lazy var GraphicsHelper? = GraphicsHelper()' could be an improvement to this solution. You're using an explicitly unwrapped optional, which is much less safe than a pure optional. The lazy instantiation also helps separate out your code a little. – Jordan Smith Jan 06 '15 at 01:10