Thursday, February 28, 2013

View Unloading into the Future!

When Apple released iOS 6, they stated that developers were having "trouble" with properly using viewDidUnload and viewWillUnload and decided that ultimately the memory hit from releasing objects in these methods wasn't enough of a concern to keep those methods and they were deprecated.  It was basically a nice way of saying that a lot of developers are so terrible at view lifecycle management that they were just going to remove the unload methods so that developers didn't continue to mess up their app by not knowing what they were doing.  Now I personally applaud Apple for taking into account this problem and dealing with it in a way that doesn't hurt legacy apps.  However, I do believe that all APIs are tools that when wielded appropriately can be useful for building something that works well.  So when viewDidUnload and viewWillUnload were deprecated, one of the first things I set out to do was port them so that I could continue to use these "tools" into the future.  Now, if you don't want to use viewDidUnload or viewWillUnload and want to conform to Apple's recommended application life cycle design guidelines then this article won't likely help you, and I must credit your wisdom.  For the rest of you, let's jump into memory warnings!

viewWillUnload and viewDidUnload ported to iOS 6





So to implement the new viewDidUnload and viewWillUnload methods we need to know when they are supposed to be executed.   Pretty simply, when a UIViewController gets a memoryWarning and it's view is not actively visible, it will call viewWillUnload, release its view and then will call viewDidUnload.  So let's start by implementing our revised didReceiveMemoryWarning method.


- (void) didReceiveMemoryWarningWithViewUnloading
{
    if (_cmd == @selector(didReceiveMemoryWarning))
    {
        // we were swizzled, call the original
        [self didReceiveMemoryWarningWithViewUnloading];
    }
    else
    {
        // not swizzled and called directly
        [self didReceiveMemoryWarning];
    }

    static BOOL s_portUnloading = NO;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
                      NSArray* comps = [[[UIDevice currentDevice] systemVersion] componentsSeparatedByString:@"."];
                      s_portUnloading = [[comps objectAtIndex:0] integerValue] >= 6;
                  });
    if (s_portUnloading)
    {
        if (self.isViewLoaded && !self.view.window)
        {
            if ([self respondsToSelector:@selector(viewWillUnload)])
            {
                [self viewWillUnload];
            }
            self.view = nil; // unload
            NSAssert(!self.isViewLoaded);
            if ([self respondsToSelector:@selector(viewDidUnload)])
            {
                [self viewDidUnload];
            }
        }
    }
}


First thing we do in our method to support unloading a view controller's view on a memory warning is ensure that the original memory warning method is called. This is as easy as doing a simple selector comparison to see if we are swizzled or not.

Next we need to check that our OS version is iOS 6 or later to ensure we are extending the functionality only where it needs to be extended.  We don't however want to take the overhead of making the OS version check over and over again, so we will use a static BOOL to store whether we are iOS 6+ or not.  Now as far as checking the OS, I'm just parsing the systemVersion but honestly every app should have a strong mechanism for OS Version checking.  I personally have a custom Version object that is an object representation of a version with an class method for easily accessing the OS Version (as well as another for the Application Version).  I should do a post on Version objects in the future as it's really something every application should have.

Once we've checked that we do want to support the unloading of the view we just replicate the view unload logic that older iOS versions already support.

  1. Only unload if the view is loaded AND is not currently visible (I use self.view.superview as the check, however, it could be feasible to check if the view hierarchy exists in a window but we'd also need to remove the view before unloading it so that it's not a dangling view reference inside some other view)
  2. Call viewWillUnload if available
  3. Unload the view
  4. Call viewDidUnload if available
Ok, we've got our replacement method so lets implement the category class method we'll use to turn on view unloading by memory warnings.


@implementation UIViewController (ViewUnloadSupport)

+ (void) portViewUnloadSupport
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
                      NSArray* comps = [[[UIDevice currentDevice] systemVersion] componentsSeparatedByString:@"."];
                      if ([[comps objectAtIndex:0] integerValue] >= 6)
                      {
                          SwizzleInstanceMethods([UIViewController class], @selector(didReceiveMemoryWarning), @selector(didReceiveMemoryWarningWithViewUnloading));
                      }
                  });
}

@end


Alright, no problem! If the OS is greater than or equal to iOS 6, let's swizzle the didReceiveMemoryWarning instance method. All we have to do is call [UIViewController portViewUnloadSupport]; from the application did load method and we have view unloading support once again in iOS 6.  NOTE: I did not provide the @interface declaration of the category but it just seemed like trivial detail.

24 comments:

  1. I’m excited to uncover this page. I need to to thank you for ones time for this particularly fantastic read !! I definitely really liked every part of it and i also have you saved to fav to look at new information in your site.
    Data Science Training in Bangalore

    ReplyDelete
  2. I read that Post and got it fine and informative. Please share more like that...
    data science course noida

    ReplyDelete
  3. Hey what a brilliant post I have come across and believe me I have been searching out for this similar kind of post for past a week and hardly came across this. Thank you very much and will look for more postings from you Best web application development company service provider.

    ReplyDelete
  4. This is really an informative articles. Do you have any idea about that Kenya evisa cost. Now we can easily know about that within few seconds

    ReplyDelete

  5. Thanks for the informative and helpful post, obviously in your blog everything is good..
    data scientist course in malaysia

    ReplyDelete
  6. This is a very useful article. Indian emergency visa application form, you can get a visa within 1 to 3 working days by filling the India emergency visa application form.

    ReplyDelete

  7. Hey friend, You are interested in travel to India from USA, Indian e-Visa is issued for USA citizens under the following 5 categories. More info about Indian visas you can read through our website.

    ReplyDelete
  8. Hii sir, Thanks for sharing a great blog!! Your writing material is very impressive. Many people ask, can we get Turkey transit visa? Yes, indeed. You can get a Turkey transit visa online.In fact, it is a very quick, cheap and easy way to get a Turkey visa.

    ReplyDelete
  9. you can surely peruse and modify anything you compose with Grammarly's free composing application. Grammarly for windows customers may be completely tested by using Grammarly for gifted clients by using coordinating it. Grammarly Full Version Crack

    ReplyDelete
  10. The wi-fi safety consultant component, protect the consumer from intimidation that happen from wireless relations specially, the application check such wireless network linked to your computer and give alerts of their safety rank. Bitdefender Total Security 2019 Activation Code Latest

    ReplyDelete