Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Couple of interesting requirements and design question #1

Open
malhal opened this issue Jan 8, 2017 · 1 comment
Open

Couple of interesting requirements and design question #1

malhal opened this issue Jan 8, 2017 · 1 comment

Comments

@malhal
Copy link

malhal commented Jan 8, 2017

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:

  1. 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.

  2. 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).

  3. 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

@wibosco
Copy link
Owner

wibosco commented Jan 9, 2017

@malhal Great to hear that you found the project and post useful.

  1. 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.

  2. This is actually a really good improvement. I believe this could be achieved by checking the isExecuting value before deciding if coalescing is possible.

  3. 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 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants