I have a scenario where I'll be doing many updates that end up effecting a Result that my VC is listening to. Ideally I'd just send 1 notification at the end of my batch
A few questions:
Is it possible to batch notifications, rather than having every update send a notification?
Is this even the right way to think about it? Should I just stop listening to the notifications when the batch starts and start listening again when it's done?
Notifications only occur at the end of a write transaction, so the easiest thing to do for this case would be to perform all of your work in one transaction (I'd definitely recommend doing it on a background thread), and then close it when you want the notification to be fired.
This would be the general recommended approach since it would guarantee all fine-grained change indexes are coalesced into that singular notification at the end.
If you don't care about the fine-grained change indexes (i.e., you're just doing a complete refresh on each notification), then you definitely could consider simply setting a flag that disregards notifications until you've completed your work.
You could also remove the notification block, but this would mean there'd be a significant amount of tear-down, and re-setup work you'd have to do each time.
Related
In my application I use a winevent hook to get focus changes system-wide. Because there are no timing problems, I use an out-of-context hook, even if I know that it is slow. If there are multiple events fired quickly on after another, the system queues them and gives them to the hook callback function in the right order.
Now I would like to process only the newest focus change. So if there are already other messages in the queue, I want the callback function to stop and restart with the parameters of the newest message. Is there a way to do that?
When you receive a focus change, create an asynchronous notification to yourself, and cancel any previous notification(s) that may still be pending.
You can use PostMessage() and PeekMessage(PM_REMOVE) for that. Post a custom message to yourself, removing any previous custom message(s) that are still in the queue.
Or, you can use TTimer/SetTimer() to (re)start a timer on each focus change, and then process the last change when the timer elapses.
Either way, only the last notification will be processed once the messages slow down.
This might be very basic questions but I have spent enough time to explore the possible solutions. In my project, I am successfully getting status info via service request. I want to add a continuous observer for any state change on the server. I am not sure if the server is setup to push silent notifications. It appears KVC/KVO or Notifications only observers changes in objects. How can I elegantly approach this problem to refresh my view only when the status changes on the server?
You can poll the server continuously, or in my opinion, a much better solution is to use WebSockets. There's a variety of libraries out there for both iOS and server-side.
I approach such a development task like this:
Use the performSelectorInBackground:withObject: method to create a concurrent thread.
Use an NSURLConnection to perform an HTTP GET operation (synchronously) against your server, allowing the thread to block until a reply arrives.
Use an NSEvent object to notify the main thread when a response is available for inspection.
Repeat the above, as needed.
For state changes that occur less frequently, I would use the Apple Push Notification Service to send state change information to my app, without the need for continuous polling.
I noticed in a comment on this post Overhead of NSNotifications, user JustSid says
the overhead won't be noticeable if the App doesn't send out 30+ per run loop cycle
I'd like to write a little helper class that keeps track of how many NSNotifications have been sent on the current run loop cycle and alert me if it's above a certain pre-configurable number. I know I can register for all notifications (pass nil to name and object), but how do I track what run loop cycle they've been sent from?
It would be easy enough to have a category on NSNotificationCenter that increments some internal integer when a notification observer is added (and consequently decrements it when it is removed), but you have to ask yourself: How much is too much?
If you consider it to be some arbitrary integer (say, 30 for example's sake), then what happens when you test it on a device that has more memory and processor constraints than the one you have now? What happens if you test it on a device that can easily handle 30 observers and notifications floating around (it would be a complete waste)? While it would be possible to code general rules, it would be impossible to gauge the impact notifications have on application response time in every case.
The other possibility would be having a background process query the notification stack (or somehow just gauge it internally like above) when the amount of observers brings certain system functions to a crawl. Of course, ignoring the fact that this is way too much work, you'd be designing a sub-system which probably utilizes as much memory and steals as much away from performance as you tried to remedy with it in the first place!
TL;DR There are so many other patterns and structures you could be using instead of notifications, so why are you the one catering to NSNotification's needs?
In PureMVC / ActionScript, after sending out notifications using send Notification or notify-observers, how do I make sure all the observers has received the notification and finished the work?
On the other words, is sendNotification in synchronized way.
Thanks
As far as I know, the proper way to do this is to put all of your tasks in SimpleCommands, and then add all of these to a single MacroCommand. As long as the SimpleCommands are synchronous (eg, you don't start any load processes), when the MacroCommand finished, you are guaranteed that all of the SimpleCommands in it have finished.
You may also want to investigate the AsyncCommand utility. I am not a huge fan of this, but some of my colleagues like it.
I'm building an online calendar in Ruby on Rails that needs to send out email notifications whenever a user-created event is about to start/finish (i.e you get a reminder when a meeting is 5 minutes away). What's the best way of figuring out when an event is about to start? Would there be a cron task that checks through all events to find out which ones are starting within a certain threshold (i.e 5 minutes) ? A cron task seems inefficient to me, so I'm wondering what might be a better solution. My events are stored in a mySQL database. There must be a design pattern for this... I'm just at a loss for what to search for.
Any help would be greatly appreciated. Thanks.
In all likelihood you will probably implement some background queuing mechanism to actually deliver the notifications - at least you certain should be considering this approach.
Assuming this, why not create your delayed notification jobs at event creation time to be delivered when the associated event is starting or finishing. The background queue, which is already waking up periodically to look for work, will pick these up and run them.
However adopting this approach requires you to consider the following (at least):
Removing queued notification job if the associated event is removed
Amending the notification job if the associated event is amended (say a new time)
Ensuring that the polling resolution of the queuing system does not allow notifications to be delivered so late as to be useless.
If you haven't picked a queuing solution for your application you should consider these options