-
Notifications
You must be signed in to change notification settings - Fork 545
added PendingRequestListener::onRequestAttached #383
base: master
Are you sure you want to change the base?
Conversation
Quick review seems OK except there's a null check before an instanceof check which effectively makes the null check not required. However, I'll check out the bits that call it when I get home. On 25 November 2014 17:46:20 GMT+00:00, mignick [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Looking through the rest of the code your changes seem to be aligned Whilst the change means an API change on *PendingRequestListener *which As for the null check on instanceof's I can see other instances of them Eg. if (listener != null && listener instanceof PendingRequestListener) { could be if (listener instanceof PendingRequestListener) { On a wider discussion I question the requirement for a null check on Is there at any point where a null listener would be added? If one is That would be as mentioned part of a wider discussion. Otherwise thanks for the changes I'm sure many users would look forward Andrew On 25/11/2014 18:37, Andrew Clark wrote:
|
Thank you @softwaremaverick for the review. If it would necessary to remove the null check, I could do it for all cases. As I understand now we are waiting for @stephanenicolas's PR review and comments about null check? |
Yes that's correct. Maybe Stephan will know of a scenario why it was added. If it's for safety reasons then I'd prefer the code that adds listeners to prevent nulls from being added to the list. On 26 November 2014 09:16:19 GMT+00:00, mignick [email protected] wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
@stephanenicolas, any chance that you will have time to review this PR in near future? |
@mignick I was just glancing through these changes again as I noticed they've not yet been merged in for some reason. However, looking at PendingRequestListenerWithProgressStub I noticed that the request itself is being stored in the listener which I don't know why it should be. I'm not actually sure what PendingRequestListenerWithProgressStub is used for but I'd have imagine the onRequestAttached would work like onRequestNotFound and just be used as an indicator to show it's actually active. Is there any reason why the request itself should be passed to the listener? This kind of sounds problematic if potentially the request itself started to know about all the listeners and the listener wanted to hold onto the request which I don't think it does right now but would cause a memory leak if it became the case. |
@softwaremaverick PendingRequestListenerWithProgressStub is for testing purpose only, I guess. As a workaround against retain cycles the onRequestAttached could return a weak reference to the request. Thank you. |
Hi!
In our project we need an ability to attach to a pending request after device configuration changed. For example, a user wants to cancel a long running request or it's necessary to show a dialog to a user if there is a pending request still.
I saw the discussion about this in #335 but no activity on the feature. I'm not very experienced in android development, so please be patient about my PR :) If I did it wrong, please advice how to improve it.
Thanks,
Nick