You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just wanted to let you know I had a couple of additional interesting requirements I would like to build on top of this:
My network operation can either be user-initiated, e.g. from a pull-to-refresh, or background-initated, e.g. from a push notification. I would like to coalesce these but they have different NSOperationqualityOfService levels. I was thinking about trying to promote the QOS of an existing background operation if a subsequent user-initated operation is enqueued.
If a network operation is part-way through then I don't want to coalesce another one, because new data might be available on the server to be downloaded. However if there is a part-way one, and another one, then the 3rd can be coalesced (since the 2nd hasn't even been started so no chance of missing anything).
The operations I'll be coalescing have multiple progress blocks, not just completion.
Also I have a question about your design, why did you choose to the coalescing at the enqueuing of the new operation, rather than at the end of the old operation, e.g. at the last step to look into the queue and cancelling any queued operations that are the same as the one just ending. I thought it might be more thread-safe to do it inside an operation, but I suppose that's only if its a serial queue.
Any feedback on how to handle (or if to not bother about) these 3 requirements would be greatly appreciated! Thanks
The text was updated successfully, but these errors were encountered:
@malhal Great to hear that you found the project and post useful.
It should be possible to change the qualityOfService property of the existing operation and you could use the new operation's qualityOfService to determine if it's level is higher - so no need to pass any additional parameters. I'm not sure if changing the qualityOfService of an already enqueued operation will actually have an effect in it's position in the queue.
This is actually a really good improvement. I believe this could be achieved by checking the isExecuting value before deciding if coalescing is possible.
Yes, definitely possible in fact the first example of the coalescing operations that I wrote had success, failure and progress blocks but I stripped it down to try and make the post more understandable.
Interesting thoughts about thread-safety. With this approach I was keen to avoid making unnecessary network calls which as you correctly would only be an issue when multiple operations are executing in parallel - thats why I choose to coalesce as soon as possible. One issue that I can think of with the present solution is if an operation is coalesced as the existing operation is finishing and the callback is skipped (for the new operation).
Not sure if you can but it would be great to see any changes you make 😃
Thanks for the cool project, and the blog post.
Just wanted to let you know I had a couple of additional interesting requirements I would like to build on top of this:
My network operation can either be user-initiated, e.g. from a pull-to-refresh, or background-initated, e.g. from a push notification. I would like to coalesce these but they have different
NSOperation
qualityOfService
levels. I was thinking about trying to promote the QOS of an existing background operation if a subsequent user-initated operation is enqueued.If a network operation is part-way through then I don't want to coalesce another one, because new data might be available on the server to be downloaded. However if there is a part-way one, and another one, then the 3rd can be coalesced (since the 2nd hasn't even been started so no chance of missing anything).
The operations I'll be coalescing have multiple progress blocks, not just completion.
Also I have a question about your design, why did you choose to the coalescing at the enqueuing of the new operation, rather than at the end of the old operation, e.g. at the last step to look into the queue and cancelling any queued operations that are the same as the one just ending. I thought it might be more thread-safe to do it inside an operation, but I suppose that's only if its a serial queue.
Any feedback on how to handle (or if to not bother about) these 3 requirements would be greatly appreciated! Thanks
The text was updated successfully, but these errors were encountered: