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?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS How do I programmatically have a method's behavior checked before the app compiles?
- Thread starter moonman239
- Start date
- Sort by reaction score
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.
Code:
- (UIResponder *)nextResponderWhich 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.
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.
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?
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?