Using the Objective-C category to avoid compilation errors

Question

Today I'm a little nasty.

All of our view controllers inherit from two different parent view controllers, say, XXXViewController and YYYViewController. XXXViewController, in turn, inherits from TrackedUIViewController , which is the class specified in the Google Analytics SDK, so all your view controllers can inherit it and easily track it.

YYYViewController, however, inherits from another type of view controller. Ah, and this is open source, which I really don't want to change.

What is the problem? We cannot track any of the YYYViewController because we cannot access the methods specified in the TrackedViewController because they are private.

I don’t want to change the source specified in the Google Analytics SDK. So what have I done? Create a category that provides these methods to avoid a compilation error.

The obvious downside to this is that the GA source code may change, but it will be pretty easy to spot.

I was wondering what other problems I might run into doing this, and if you guys can come up with a better approach.

thanks

Answer 1

You can go into the YYYViewController inheritance chain, in turn, see which class it inherits from. If it is a UIViewController, just change this particular superclass to TrackedUIViewController in the source, and you don't care.

Example for a better understanding: Suppose that YYYViewController inherits from ZZZViewController , which in turn inherits from UIViewController . Now you can change the superclass from ZZZViewController from UIViewController to TrackedUIViewController - since TrackedUIViewController inherits from UIViewController , no functionality will be lost, but your whole YYYViewController class will YYYViewController be tracked.

Hope this helps :-)

Answer 2

You have already pointed out the greatest risk of using undocumented APIs: changes to the API are beyond your control and may violate your logic, for example, if methods are deleted / renamed or their behavior ceases to meet your expectations.

From a purely technical point of view, I do not see any additional problems, since in Objective-C all methods are publicly available. As long as they continue to exist, you can continue to call them.

Answer 3

I would say that the root problem is excessive subclasses. Keep the level manager hierarchies shallow. Use composition instead of subclass. If you need a subclass to ensure that the functions that the class provides can be turned on and off by subclasses.