Okay so it's pretty obvious that push notifications aren't always reliable, as stated in the docs.
Correct me if I'm wrong, it's simply because someone might not have internet for an extended period of time and the notification could for example, expire, or get replaced, or even get lost for some cosmic reason.
I'm okay with that.
But as a junior programmer I used a lot of local notifications, not for display, but simply to call different methods when some processes where done.
Here is a simple example, when the app starts, I have a data-update process of, say, messages and stuff. When that update is done (about 3 seconds later), I send a notification that all my controllers listen to so they update their UI accordingly. If I'm on the home screen I'll show those little red badges, if I'm in a conversation I'll add the messages in the tableview, and so on.
And, as a junior developer, I had the chance to work with a senior developer who frowned upon this style. He says that it's just not reliable and I should use delegate callbacks and completion handlers. Which I find very hard to do considering the way the app is built. My system is literally a one-liner and never failed, whereas his system requires a lot of implementation of different methods in each separate class. It seems both redundant and messy.
I'm finally getting where I wanted : are notifications reliable locally, I'm talking about this :
[[NSNotificationCenter defaultCenter] postNotificationName:NOTIF_SOMETHING_SOMETHING object:self];
with its addObserver: counterpart obviously.
Am I really wrong about chosing this work style ? What should I have done? Or is that okay? Or is that even awesome?
Sadly enough this is a quite opinion-based question because it's about standards and good practices, but I feel like it's not broad enough to be against the rules because I really really feel like someone is gonna bring a technical reason why this or that should/shouldn't be done, or clarify what should be used where and when.
Anyway, please ask me to clarify anything if need be, I'm genuinly interested in all the responses to come, and I'm looking forward to it.
There are different kinds of notifications in the iOS world, each really have different purposes and shouldn't be confused with each other.
push notifications: these are the only ones not being reliable in the sense that they depend on a network connection and apple's push system...
UILocalNotification:
these are ways to notify your users upon certain events (you could compare it to a push notification only that it's not sent from a server but triggered locally by your own app)
NSNotification:
these are purely technical and basically they provide a broadcast mechanism that can be used to enable communication between certain parts of your app. i understand that on first sight it might seem handy to use NSNotification often in your code, because it's a simple and straightforward way to let 2 (or more) classes communicate with each other. however, you senior dev was right in that he advised you not to overuse this mechanism. mainly because it leads to a messy coding structure and doesn't scale well when your project becomes bigger. another huge issue is that it makes debugging very difficult. when using delegates or completion blocks on the other hand, you have a chance to structure your code in a reasonable way that ensures that you encapsulate functionality as you should, makes the code more readable and is way more appropriate to be used at scale.