Closed nitrag closed 7 years ago
@rogerhu Seems like you could do a great job with contributions. I think part of the problem comes from lack of people with rights to merge PRs, which is part of the reason why the project is slipping. Personally, if I make a PR and it goes unmerged/uncommented on by the maintainers for a number of weeks/months, I am pretty discouraged from making any more contributions.
Quite a few of the open PRs right now all address the same issues; the Parse Android SDK not being buildable on Android 23+. Accepting one of those would be a great start and would eliminate the fact that everyone who forks the repo and goes to make changes has to go through this same process of first updating the SDK to the latest dependencies. @flovilmart Do you have the ability to add individuals as collaborators/members of the Android SDK repo?
I can't add contributors to the repo like that, also, this contributor status is not something that is given but earned. If anyone is wanting to take the lead, establish a vision, etc... I'd be more than happy to help get those access.
Note that so, far, most of the comments on that matter are complaints that no-one is taking over but none have clearly stated their intention to take over. I have neither the time nor the capacity to maintain the android project. My hands are full with my full time job, (yes I don't work for Parse nor Facebook), the maintenance of parse-server, the iOS SDK's, and parse-server-modules organization, and my 3 kids.
That being said, if anyone wants to move forward taking over, start helping to solve the issues, we'll find someone to review the code, and get it merged from now on. As for past PR's they may not have received any attention for multiple reasons, but that role of maintainer would be to start understanding why.
I'm curious, who is the person(s) who can grant contributor status?
As far as supporting old Android SDKs, I'd still love to see support back to Android 16 (4.1)
I was the last person to add the major upgrade from OkHttp2 to OkHttp3 in this library so feel somewhat of a personal responsibility to get some of the bugs that I introduced. :) Things like https://github.com/ParsePlatform/Parse-SDK-Android/pull/548 and https://github.com/ParsePlatform/Parse-SDK-Android/pull/506 seem somewhat straightforward to get merged in. The removal of the legacy Apache HTTP library is also something that seems to make a lot of sense.
The latest OkHttp library also supports web sockets (https://medium.com/square-corner-blog/web-sockets-now-shipping-in-okhttp-3-5-463a9eec82d1#.xlkgirivu) which would also help the project start to achieve parity with LiveQuery support. I think that would be the next priority to get going. I'm sure there are people in this thread who would be excited to work on it with help/guidance from Parse contributors.
Edit: just noticed https://github.com/ParsePlatform/ParseLiveQuery-Android so obviously someone is already working on it. :)
@rogerhu yeah we started with @mmimeault the liveQuery android SDK, I believe it makes sense to keep both projects separated (for maintainability) :)
We need to get the ball rolling and I think that involves breathing some life into the SDK by merging existing PR's or rejecting them with comments.
@flovilmart can you speak to the powers at be to spend a few hours over the next two weeks on the existing PR's. Without this I don't think we'll ever move forward.
The we can reach out to some of the "forkers" and get them to include their updates.
Long term, I'm also recruiting some of the parse-server hosting providers to contribute resources to the SDK's. They say that after things stabilize on their end they will move into the maintainer role but that probably won't be for another month or two from now.
@rogerhu If you upgrade to OkHttp3, will Android 16 be supported? I'm with @alexblack and still think our apps should be backwards compatible to at least this level.
OkHttp3 is already in the Parse Android SDK 1.13.0+. It was probably the last major commit (https://github.com/ParsePlatform/Parse-SDK-Android/commit/b3f457f556899358da781e902094c863051d6834) before this SDK went into hibernation.
Yes, absolutely, Android 16 should be fine. Do you see any compat issues in the current SDK version?
HttpUrlConnection is the primary interface now for the Android network library, and it so happens that OkHttp was backported as the engine that powers HttpUrlConnection in Android 4.4 (API 19) (https://twitter.com/jakewharton/status/482563299511250944?lang=en).
The Apache HTTP Client that's part of Android and removed after API 23 is largely abandoned by Google (https://android-developers.googleblog.com/2011/09/androids-http-clients.html). But we're talking abandoned since Gingerbread (Android 2.3) :)
I'm also recruiting some of the parse-server hosting providers to contribute resources to the SDK's.
That would be nice, but I pretty much gave up on them. They had a full year to move forward, and instead didn't really do anything (with a few exceptions)
@flovilmart I'm not relying on them or saying we should wait for them to move forward. I'm just saying it's likely more support will be coming. That's all.
Here's the latest from Sashido.io, received yesterday.
We really want to start devoting time on Github, but we are still working on implementing features for the mass of users such as backups, SSLs,etc. The bad thing is that these take a lot of time. So up until now we haven't got the time to complete these and focus on anything else. We will do it at some point, we just can't promise a date. The engineers do their best to work as fast as possible on the features we are implementing,but some of them need more time. We'll keep you posted.
We still need you to motivate the current maintainers so we can get the ball rolling. I've started the Android Nanodegree this week, I'll help where I can but I'm far from qualified at this point.
AFAIK, the parse.com team was about 20 people full time, 1/3 was devoted to deployments, the rest mostly on SDK's and server code. That gives a rough estimate of 14 full time engineers to maintain the platform and evolve that the same pace it one moved.
On parse-server, I can quite confidently say that the team is more than capable of handling it, we have about 10 external people with commit access. The parse-server-module org is also quite OK, with many people with commit access.
If we could have at least 2-3 people per client SDK to take over then we could really start moving the ball faster and forward.
There has been some discussion to ease client side development like leveraging new techs like graphQL. On my side this is something i'm exploring for parse-server (being graphQL compatible). That would alleviate the need of custom SDK's as we'd be able to rely on 3rd party implementations while providing a lightweight modern SDK for push, localDatastore etc...
In a sense, this idea is motivated by the need to reduce the burden on SDK maintenance, but it starts on the server. (building a full graphQL<-> parse bridge).
I understand this is a 180 degrees turn that won't happen overnight, but I can definitely see it as a future-proof solution, giving you a base implementation of graphQL on the top of the Parse REST.
I've looked through the majority of the tickets and responded to at least 27 of them (https://github.com/ParsePlatform/Parse-SDK-Android/pulse). Here is where I think the work needs to go:
[x] Fix OkHttp3 upgrade bugs and release a new build ASAP
If clientKey = null, don't set as a header (https://github.com/ParsePlatform/Parse-SDK-Android/pull/506/files)
Release fix that deals with ParseFile.save() issues (https://github.com/ParsePlatform/Parse-SDK-Android/pull/542/files
Confusion about issues with ParseFile limits > 10 MB because of a BinTray caching issue (https://github.com/ParsePlatform/Parse-SDK-Android/issues/491#issuecomment-234337140)
[ ] Upgrade Parse OkHttp libs
[ ] Add a Parse test fix for https://github.com/ParsePlatform/Parse-SDK-Android/pull/542/files
[ ] Add support for socket timeouts/self-signed SSL certs? (https://github.com/ParsePlatform/Parse-SDK-Android/issues/448, https://github.com/ParsePlatform/Parse-SDK-Android/issues/440, https://github.com/ParsePlatform/Parse-SDK-Android/issues/498)
[ ] Resolve some saveInBackground() (https://github.com/ParsePlatform/Parse-SDK-Android/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20saveinbackground) and Parse.getCurrentUser() bugs (https://github.com/ParsePlatform/Parse-SDK-Android/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20currentuser)
[ ] Figure out a plan for FCM and Parse Push (https://github.com/ParsePlatform/Parse-SDK-Android/issues/572). Resolve and close GCM co-existing issues (https://github.com/ParsePlatform/Parse-SDK-Android/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20gcm%20
[ ] Figure out how to support LiveQuery (work in progress, but could benefit from OkHttp 3.6.0 upgrade?)
Anything else?
That sounds like a plan! @hramos, can you add @rogerhu to the maintainers of that repo, so he can start moving forward? And probably me, just in case?
Thanks @rogerhu!
Invited both of you folks.
Thanks! We now need help figuring out how to get the Sonatype images staged for release published. :) Is there anyone on the Parse side who can help?
We have use Andorid SDK for half a year,and found pretty much bugs in Android SDK. For example, Local cache is not good to use, some times it took much time to find dirty objects.
@ly85206559 We have @rogerhu to represent the community for improvements to the SDK. Please open a Issue with a reproducible error over at the Android SDK.
FYI I have access now to publish to jcenter but not sonatype. I am planning to pull the trigger and publish to the former until I can get help pushing to the latter..
Access to Sonatype should be granted to you soon @rogerhu
Thanks! They granted me it. :)
Sorry to post this in the wrong place, on purpose. The Android SDK is in dire need of some TLC. I however am not an Android Dev. I am here to encourage experience Java devs to step-up, as flovilmart has done for parse-server, and ask Facebook (@nlutsenko) for administrative rights to Parse-SDK-Android so we can push development forward. The iOS SDK is getting some love but no attention at-all for Android.
There are many many nuance bugs, many are already in PR Stage waiting to be approved thanks to some of the devs listed below.
I would hate to see all this work going into parse-server be for naught because the SDK's have major flaws that results in hours of troubleshooting and causes new devs to become frustrated and walk away.
@sashakhail, @natario1, @jianwatertown, @mlauwers-edentify, @Joelo14, @rebahbouchaib, @dkuspawono, @nonda, @Ilhasoft, @evocodes just to name a few, please also comment your concerns to bring attention to this issue.
Even though this is in the wrong place, can we please keep it open for 7 days to get the attention it needs?