Closed mbfakourii closed 1 year ago
I will reformat the title to use the proper commit message syntax.
Attention: 9 lines
in your changes are missing coverage. Please review.
Comparison is base (
21ce56f
) 39.61% compared to head (638440b
) 40.60%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Please check these two functions thoroughly and give suggestions, this PR needs discussion.
Changed to draft
@mtrezza @Nidal-Bakir Do you think the implemented method is appropriate?
I suggest looking at what other SDKs do and doing the same. There is the concept of a Queue so the objects get saved in order.
Do other SDKs save the unsaved Objects even when the app is closed(destroyed) using native services (android and iOS) when the connection is restored for example?
I suggest looking at what other SDKs do and doing the same. There is the concept of a Queue so the objects get saved in order.
Do other SDKs save the unsaved Objects even when the app is closed(destroyed) using native services (android and iOS) when the connection is restored for example?
I think the queue issue happens in dio or Http and we don't need to create this queue.
According to the ios documentation
Saves this object to the server at some unspecified time in the future, even if Parse is currently inaccessible.
Use this when you may not have a solid network connection, and don’t need to know when the save completes. If there is some problem with the object such that it can’t be saved, it will be silently discarded.
Objects saved with this method will be stored locally in an on-disk cache until they can be delivered to Parse. They will be sent immediately if possible. Otherwise, they will be sent the next time a network connection is available. Objects saved this way will persist even after the app is closed, in which case they will be sent the next time the app is opened. If more than 10MB of data is waiting to be sent, subsequent calls to -saveEventually will cause old saves to be silently discarded until the connection can be re-established, and the queued objects can be saved.
Based on what I understand, the internal structure of Android is implemented with this concept. If possible, take a look at the Android structure.
The concept that I didn't understand was where to double check and send the saved it objects?
I wrote the codes of this section in the await ParseObject.submitEventually()
function! And I allow the user to use it wherever they need. But not sure about that !
Overall everything is good.
I have some thoughts:
What will happen if the current user logs out?
- should we clear the cache? or could you give the end user the option to decide what should happen?
- should we give the end user control over the cached objects that need to be saved/deleted?
At the moment, the caches are not deleted, but I think a function should be written to delete the cache
Regarding the second question, I did not see anything in other SDKs. Do you have any suggestions for this? What control do you mean?
At the moment, the caches are not deleted, but I think a function should be written to delete the cache
Got it.
Regarding the second question, I did not see anything in other SDKs. Do you have any suggestions for this? What control do you mean?
I mean what if the user wants to clear the currently cached objects for saving/deleting and start over? Should we expose such a feature?
Or in general, should we expose the current cache state so the end user can alter it?
If yes we should consider a saving mechanism like functions to be invoked. for example:
something like that
I mean what if the user wants to clear the currently cached objects for saving/deleting and start over? Should we expose such a feature?
Or in general, should we expose the current cache state so the end user can alter it?
If yes we should consider a saving mechanism like functions to be invoked. for example:
- onBeforStartSaving()
- shouldSave()
- shouldDelete()
- onBeforSave()
- onBeforDelete()
- onAfterSave()
- onAfterDelete()
- onAllSaved()
- onAllDeleted()
something like that
I don't think this is necessary. I haven't seen anything about this in other SDKs. Do you have a reason why it needs to be added?
Do you have a reason why it needs to be added?
No, I'm just wounding if we need to give the end user finer control over the eventual save in general. If the other SDKs do not do that we are good.
So currently, we need to discuss how the submitEventually
function should be called and what will happen when the user logs out when there are some unsaved objects.
Do you have a reason why it needs to be added?
No, I'm just wounding if we need to give the end user finer control over the eventual save in general. If the other SDKs do not do that we are good.
So currently, we need to discuss how the
submitEventually
function should be called and what will happen when the user logs out when there are some unsaved objects.
Do you think we should leave this function to the user or place it somewhere like the save()
function?
I don't think this function has been given to the user in other SDKs!
What's missing in this PR to get it merged?
What's missing in this PR to get it merged?
The code is finished, the tests must be written
The error related to Test Flutter beta
has been resolved in this PR
@mtrezza
Done 😃
Note for review: The Flutter test is failing, hence we need to merge https://github.com/parse-community/Parse-SDK-Flutter/pull/969 first before merging this PR.
Could you check whether I've resolved the conflicts correctly? Then I believe this can be merged.
I checked, and there was no problem.
Pull Request
Issue
Closes: #149 and #194
Approach
In this feature, Functions
saveEventually
anddeleteEventually
inParseObject
were added---> in
saveEventually
At first, normalsave
command is entered in parseObject, if aNetworkError
is encountered, this object is saved in a list with a key with the help of ParseCoreData. In our collection, we have a list of objects inParseCoreData
that are inNetworkError
.---> in
deleteEventually
At first, normaldelete
command is entered in parseObject, if aNetworkError
is encountered, this object is saved in a list with a key with the help of ParseCoreData. In our collection, we have a list of objects inParseCoreData
that are inNetworkError
.---> in
await ParseObject.submitEventually()
With the help of the functionawait ParseObject.submitEventually()
(which is debatable how to use it) we checks the error objcetsIn this function, we first get the error parseObjects from
ParseCoreData
, then we send this list to_saveChildren
. In this function, these objects are sent to the server in the form of chunks, and finally, we empty theParseCoreData
list.In the following, we also take the list of
parseObjects
that must be deleted fromParseCoreData
and try to delete them, and then we delete the successfully deleted parseObjects from theParseCoreData
list.@parse-community/flutter-sdk-review Please check these two functions thoroughly and give suggestions, this PR needs discussion. and please check the algorithm, is this method good?
Tasks