Compare methods of notifying about changes from services to controllers AngularJS - angularjs

Question

I have found this solution from Aviv Ben-Yosef in his blog post:
angular.module('app').controller('TheCtrl', function($scope, NotifyingService) {
// ... stuff ...
NotifyingService.subscribe($scope, function somethingChanged() {
// Handle notification
});
});
angular.module('app').factory('NotifyingService', function($rootScope) {
return {
subscribe: function(scope, callback) {
var handler = $rootScope.$on('notifying-service-event', callback);
scope.$on('$destroy', handler);
},
notify: function() {
$rootScope.$emit('notifying-service-event');
}
};
});
I am thinking to do this: jsfiddle
angular.module('app').factory('NotifyingService', function() {
var handlers = {
list: []
};
return {
subscribe: function(callback) {
handlers.list.push(callback)
},
notify: function() {
handlers.list.forEach(function(handler) {
handler();
});
}
};
});
Edited: My goal is send changes to controllers in the same page. For example, there is a controller is doing something with the user and then it will notify the results to other controllers on the same page every time. I don't need to have the following abilities: unsubscribe the handlers, differentiate which handler to fire each time.
My solution seems very simple and I have not found anyone using it on internet, so I am feeling there should be something wrong with it (memory issues?).
Please point out the flaws in my solution (with resources if complicated. Ex. Memory). All I want to know is if this solution is okay to go with.
If my solution is good, please tell me, or compare pros and cons of both solutions.
Updated
Thanks to #Daniel Beck. He pointed out that my solution does need a way/function to remove handler once the controllers are out of scopes, otherwise memory leaks. I believe this is the major flaw in my solution.

Answer 1

Maybe I'm missing something obvious -- I'm sure someone will come along to point that out if so -- but it seems to me that the sole advantage to the first one (from the blog post) is that you don't have to remember to destroy the $on watcher when you're done with it. Its major disadvantage is that the service uses a single event name for all its $emits -- if you used this service in two different controllers, both would be triggered every time; there's no way to differentiate which handler you actually intended to trigger.
Your version shares that flaw, and additionally provides no way to remove unneeded handlers -- it appears to support only running each of a list of callbacks when its notify is called. Which is exactly what $rootScope.$emit does already.
I think you're both kinda reinventing the wheel, here.