Closed krausegil closed 8 years ago
Hi @krausegil,
ConcurrentModificationException
, could you paste some code snippet which cause this bug?Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.
Please try the latest SDK. Our release notes have details about what issues were fixed in each release.
In addition, you might find the following resources helpful:
This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.
We are closing this issue due to another 7 days of inactivity. If you have additional information to help pinpoint this issue as an SDK bug, please reopen it with the additional information.Thank you for your feedback.
Hey, sorry for the delay. We found a workaround and once it worked we had many other bugs to solve to stabalize the product.
Anyway, the workaround was removing the inheretance so all of our Parse class inherite ParseObject directly. That means ugly not OOP code - duplication of the code of "ParsePet" both in ParseDog and in ParseCat, for example. But it seems to have solved the problem. Unlike previous attempts to solve this time when we went back to old versions the problem returned.
Anyway, we looked for it in your documentation and found no where that it says something about this bug / limitation. We only got the idea to try it from here: http://stackoverflow.com/questions/31682495/subclassing-a-parseobject-subclass-android/31682925#31682925
Please do mention it in big latters in your documentation. That issue cost us lots of development time especially as it sometimes work and sometimes doesn't...
As for #2 (Debug mode) - I'm talking about when we run the app with the Android Studio debugger (on a real device / Genymotion). When we do this, any parse call takes segnificantly more time.
@krausegil Could you clarify whether or not using nested ParseObject
subclasses worked (albeit slowly)? I'm a little confused as your original comment made it seem like it worked (slowly), but the stackoverflow thread you linked to in your second comment stated that it didn't work.
RE debug mode: debug mode will always be slower as the Android debugger is attached to your application, monitoring everything such as the call stack of all the threads in your application. If all you're testing is speed, you'll need to make sure that you consistently use the debugger or not across all your benchmarks. I recommend not using it since all you're worrying about is speed.
RE children: could you instrument your network calls with ParseInterceptors
to verify how many children are getting saved/network requests being made?
I also believe that we'll need a minimal sample project that reproduces your issue to deduce what's happening and to provide a fix.
This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.
@grantland @wangmengyan95
Please your reply.
In the last few days some of our write calls are super slow again. some take about 1 minute for saving an object edit. Objects of thios class only have 2 children. Non of them is "derty" when this save operation is done.
If this problem was in an operation done by all users and not only in an "adminstrator" platform - this would have killed the app.
1/ Subclassing shouldn't cause significant slowdowns, especially for asynchronous code.
3/ We still need this information.
4/ As per our Contributing Guidelines, we need a concise repro to make this actionable such as a small project that shows the problem you have described.
This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.
We are closing this issue due to another 7 days of inactivity. If you have additional information to help pinpoint this issue as an SDK bug, please reopen it with the additional information.Thank you for your feedback.
The problem: Sometimes saving parse objects using the save() function takes several minutes. In those 2-15 minutes the save function will not return.
Background: In our app, for each Class that we want to save to the servers, we create a class extending ParseObject, using an inheritance tree. For example: Both class ParseDog and class ParseCat extends ParsePet, which in turn extends ParseObjectWrapper. Some classes like ParseNotification extends ParseObjectWrapper directly. For users we use the built in ParseUser class.
We do all our work with parse in a closed parse module.
We have Objects which reference other objects (always from another class), we use reference arrays, and so on. We do all relations as recommended in the parse documentation.
Other issues that might be worth mentioning:
More about the problem:
Links to other bugs that we thought might be relevant: