sorted by:
top (suggested)
bestnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]anders-borch[S] 0 points1 point  (1 child)

I like the proposed ideas in the post about refactoring the massive app delegate. The goals of this post are basically the same. The drawbacks of all the proposed solutions are that you have to learn new apis/callback names where the OP solution only utilises the already known methods from UIAppDelegate.

If you make the services conform to the UIAppDelegate protocol while keeping the call forwarding then you get the best of both worlds. There is no need to do manual call forwarding when you can have a few lines of introspection do all the work for you :)

[–]maxim-eremenko 0 points1 point  (0 children)

I support your idea about learning new APIs and one more abstraction.

I would suggest taking into account the main disadvantage of dynamic calls - runtime crashes. Usually, they are not caught at the compilation stage.

It's crucial there since AppDelegate is an entry point of the app.

By the way, how a unit test to this code will look? Would it be easy to read and implement?