6/30/15 – Adam Shaw

It. Is. Fixed. So I started out the day by analyzing my program using built in tools to XCode, namely its allocation manager in the instruments menu. By analyzing both my default implementation, as well as the implementation where I separately instantiate a label and scrollview, I saw that the UILabel accrued memory being taken up in the former, but not in the latter, despite them both possessing the same memory signature in the base memory tool of XCode. I guess this is a valuable lesson; the default memory analyzer in XCode is not good for anything beyond a cursory examination. After this, Prof. Medero and I discovered that upon deallocation, the accelerometer queue of the scrolling label was not being deallocated. I fixed this problem quite easily by adding a control scheme to the unwind segue in the OVC, but the bbb continued. So in that same control scheme, I added a deinitialization of the scroll label, and here is where things got super wonky. In my deinit function in scrollingLabel, I set all the optional items to nil, ended the accelerometer queue and stopped the stopwatch. However, this code was not being run when explicitly being called, UNLESS, the only action being taken in the accelerometer queue was to print to console. It even recognized that the scrollingLabel had been deinitialized, because it printed it as nil, but did not run the deinitialization code. I create a function called wasKilled() and just added the deinitialization code to that, but that too didn’t work, because now it not only called the wasKilled(), but ALSO CALLED THE DEINIT. What. I ended up deleting the deinit code, only using the implemented function, and restoring the functionality of the accelerometer. And it worked. So, what have we learned. I mean, the biggest thing is just to not trust the memory tool built in to Swift, because though it said only 150mb were being used, in reality that was stacking (this is even more confusing given that under certain specific implementations it would show the stacking), and instead always use the allocation instrument. The problem also was not the accelerometer not being cancelled, as I found that only caused a minute increase in CPU resources. I think the problem is deeply rooted in the deinit not working, and the weirdness about it being called when I tried to fix it, but I will leave sorting that out for another day. For now, it works.

One thought on “6/30/15 – Adam Shaw

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s