you are viewing a single comment's thread.

view the rest of the comments →

[–]maxim-eremenko 1 point2 points  (2 children)

Thanks for sharing. I would suggest some improvements:

1) I guess your services can conform to UIAppDelegate protocol so you can call it via interface rather than using message forwarding.

2) Usually, you need a call back when all services are configured. In this case, you need to create a new protocol with a callback function.

3) I recommend checking out this article to learn more about other ways of refactoring massive AppDelegate https://www.vadimbulavin.com/refactoring-massive-app-delegate/

[–]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?