4 ms·

Last time I used Parse the Android SDK had a crippling bug that made it unusable. This was version 1.8.0 I believe. Essentially Disk I/O was using the same syn

Last time I used Parse the Android SDK had a crippling bug that made it unusable. This was version 1.8.0 I believe. Essentially Disk I/O was using the same synchronized lock as the main thread. On some devices this caused a reproducible ANR (App Not Responding). I ended up writing a small REST Api client using Retrofit to replace the SDK. It worked well but as mmastrac mentioned there are just too many other critical issues with Parse to make it suitable for anything other than quick prototypes. Besides, it's super expensive if you need have any sort of scale. You could almost hire a part-time engineer to build and maintain a backend for those prices.

evv 11y ago
I wouldn't write off Parse's value because one client was rough around the edges. I suspect the SDKs will become much more stable and usable now that the community can help contribute to them. If you can find a part-time engineer that can build and maintain a backend with all of Parse's features, you should absolutely do that.
- GeneralTspoon 11y ago
  Now that it's open source it's possible to fix, but it wasn't back then. We couldn't ship an app that locked up a user's phone. Combined with all the other issues (mentioned at the top of this thread), we had to write-off Parse. > If you can find a part-time engineer that can build and maintain a backend with all of Parse's features, you should absolutely do that. Most likely, you're not going to be using all of Parse's features; probably just a small subset of them. So I think it's easily doable. In fact, if you were intending to use Cloud Code, you could probably do it yourself with the time you'd save by not having to deploy to production to test your code!
grantland 11y ago
It's unfortunate to hear you had a bad experience with our SDK :( We've actually fixed a few ANR deadlocks in this last release [1], as well as a few others in the releases since 1.8.0 [2]. If you can supply reproduction steps, we'd love to be able to fix this issue as I'm sure you're not the only one experiencing it. In addition, we're more than happy to accept fixes as contributions :D [1]: https://github.com/ParsePlatform/Parse-SDK-Android/releases/tag/1.10.0 https://github.com/ParsePlatform/Parse-SDK-Android/releases/... [2]: https://parse.com/docs/downloads https://parse.com/docs/downloads
- GeneralTspoon 11y ago
  The issue is still open here: https://developers.facebook.com/bugs/838833329491346/?search_id https://developers.facebook.com/bugs/838833329491346/?search... I think the guy on the ticket didn't really understand what I was saying. I'm happy to provide any extra info necessary (what I can remember anyway). From looking through the code, the issue still appears to exist. [1] is called on the Main Thread. It eventually calls to a synchronized block [2]. [3] is called from a background thread and uses the same synchronised lock. --> Main Thread + Background Thread using same lock == Trouble One other annoying issue I reported (#937744189590638 - private) was not being able to update the GCM token. The field is readonly, even though the GCM docs explicitly state that the key changes over time. Meaning you have to delete and recreate the Installation - and what happens if you have other objects linked to that installation? Super annoying. Could be easily solved by making that field writable. [1]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ConnectivityNotifier.java#L87 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast... [2]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseCommandCache.java#L401 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast... [3]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseCommandCache.java#L267 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast...
  - grantland 11y ago
    I've responded to both your tickets. The deviceType issue seems be resolved now, but please ping me on Twitter at @grantland if the deadlock issue fails to re-open. I just need the SDK version you were using since your thread dump was obfuscated. WRT the ParseCommandCache links you sent, you're right that there is some trouble using the same lock on a background thread and UI thread. It would possibly cause some UI stuttering, but it wouldn't necessarily cause a deadlock on it's own. There's probably a bit more to it and I'd love to dig deeper and find out why.
    - GeneralTspoon 11y ago
      For any others reading this - can confirm, deviceToken issue is resolved. It is actually possible to update a pushToken, but you need to have an installationId set (otherwise you'll get an error saying it's not possible). Posted more info for the ParseCommandCache ANR in the ticket. Cheers for taking feedback seriously! :)

evv 11y ago

I wouldn't write off Parse's value because one client was rough around the edges. I suspect the SDKs will become much more stable and usable now that the community can help contribute to them. If you can find a part-time engineer that can build and maintain a backend with all of Parse's features, you should absolutely do that.

GeneralTspoon 11y ago
Now that it's open source it's possible to fix, but it wasn't back then. We couldn't ship an app that locked up a user's phone. Combined with all the other issues (mentioned at the top of this thread), we had to write-off Parse. > If you can find a part-time engineer that can build and maintain a backend with all of Parse's features, you should absolutely do that. Most likely, you're not going to be using all of Parse's features; probably just a small subset of them. So I think it's easily doable. In fact, if you were intending to use Cloud Code, you could probably do it yourself with the time you'd save by not having to deploy to production to test your code!

grantland 11y ago

It's unfortunate to hear you had a bad experience with our SDK :( We've actually fixed a few ANR deadlocks in this last release [1], as well as a few others in the releases since 1.8.0 [2]. If you can supply reproduction steps, we'd love to be able to fix this issue as I'm sure you're not the only one experiencing it. In addition, we're more than happy to accept fixes as contributions :D [1]: https://github.com/ParsePlatform/Parse-SDK-Android/releases/tag/1.10.0 https://github.com/ParsePlatform/Parse-SDK-Android/releases/... [2]: https://parse.com/docs/downloads https://parse.com/docs/downloads

GeneralTspoon 11y ago
The issue is still open here: https://developers.facebook.com/bugs/838833329491346/?search_id https://developers.facebook.com/bugs/838833329491346/?search... I think the guy on the ticket didn't really understand what I was saying. I'm happy to provide any extra info necessary (what I can remember anyway). From looking through the code, the issue still appears to exist. [1] is called on the Main Thread. It eventually calls to a synchronized block [2]. [3] is called from a background thread and uses the same synchronised lock. --> Main Thread + Background Thread using same lock == Trouble One other annoying issue I reported (#937744189590638 - private) was not being able to update the GCM token. The field is readonly, even though the GCM docs explicitly state that the key changes over time. Meaning you have to delete and recreate the Installation - and what happens if you have other objects linked to that installation? Super annoying. Could be easily solved by making that field writable. [1]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ConnectivityNotifier.java#L87 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast... [2]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseCommandCache.java#L401 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast... [3]: https://github.com/ParsePlatform/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseCommandCache.java#L267 https://github.com/ParsePlatform/Parse-SDK-Android/blob/mast...
- grantland 11y ago
  I've responded to both your tickets. The deviceType issue seems be resolved now, but please ping me on Twitter at @grantland if the deadlock issue fails to re-open. I just need the SDK version you were using since your thread dump was obfuscated. WRT the ParseCommandCache links you sent, you're right that there is some trouble using the same lock on a background thread and UI thread. It would possibly cause some UI stuttering, but it wouldn't necessarily cause a deadlock on it's own. There's probably a bit more to it and I'd love to dig deeper and find out why.
  - GeneralTspoon 11y ago
    For any others reading this - can confirm, deviceToken issue is resolved. It is actually possible to update a pushToken, but you need to have an installationId set (otherwise you'll get an error saying it's not possible). Posted more info for the ParseCommandCache ANR in the ticket. Cheers for taking feedback seriously! :)