How do I programmatically have a method's behavior checked before the app compiles?

Discussion in 'iOS Programming' started by moonman239, Jun 11, 2014.

  1. moonman239 macrumors 68000

    Mar 27, 2009
    Example: Suppose that I have an object that, under iOS 7.1. uses a view's nextResponder method to get the containing view controller. Also, suppose that, in a future version of iOS, the next responder in the responder chain is not the view controller. How do I ensure that I can't build my app using that SDK until I work around the fact that the next responder is not the view controller?
  2. JohnsonK macrumors regular

    Mar 6, 2014
    If I understood correctly, check
  3. moonman239 thread starter macrumors 68000

    Mar 27, 2009
    That will only work at runtime. I want to make it so that if a future version of iOS alters the return value of a method, then the compiler will automatically complain. In the hypothetical situation I described above, I would want either Xcode or the compiler to tell me that the iOS version under whose SDK I'm building the app will return a different object when it calls the view's nextResponder method.

    Let me write a list to help you understand the example:

    What would happen if I built the app using iOS SDK 7.1 and did not modify any UI responder chain:
    1) Object calls a view controller's view's nextResponder method.
    2) That object returns the view controller.

    What I would want to happen if nextResponder's return value will no longer be the view controller:
    1) Either Xcode or the compiler notices that the aforementioned object expects the nextResponder method to return the view controller.
    2) Whichever program notices that won't let the app be built until I change the code so that the aforementioned object gets the view controller using some other method.
  4. MattInOz macrumors 68030


    Jan 19, 2006
    - (UIResponder *)nextResponder
    I assume this is the method you mean?
    Which UIViewController inherited from UIResponder so your only really assured that the object provided is a UIResponder. If you stick to UIResponder methods then any change will throw a error.
  5. moonman239 thread starter macrumors 68000

    Mar 27, 2009
    If I stick to UIResponder methods, then I would hope those methods wouldn't cause an error.

    Anyways, yes, the view's next responder is never guaranteed to be a view controller. Therefore, any attempt to invoke any method that is available to any UIViewController and not the next responder will be met with an error at runtime. I want an error to occur before runtime, so that I am aware that the next responder is not a UIViewController.
  6. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    I don't think you can get what you want.

    Apple is very unlikely to change the return type of existing APIs. It would usually deprecate an API and replace it with another one if they don't like something about how a given API works.

    Adding assertions to your code is a way to guarantee expected behavior, but the assertion will fail only at run time. Unit tests are another way to guarantee expected behavior.

    Why do you want this info at compile time?

Share This Page