Android SDK Attention! #3356
Comments
|
Fully agree, the saddest part is that Parse Server and the iOS SDK are actually powerful, well maintained repos. To be honest, I am pretty confident a major update of the ParsePlatform might be coming up soon, based on numerous answers (scroll down). Too bad there are no official news. Still - even with no update to the client SDKs - if ParseServer keeps moving forward like it did in 2016, it will stay a viable development tool for me. The speed/cost at which you can develop apps at a proof-of-concept level isn't comparable to any other PaaS out there. Even without the client SDKs, the REST API is a reasonable fallback. |
Old devs as well. FWIW I agree with the OP. I’d like to contribute, but we need a present, experienced developer doing at least some coordination (and that is not me for sure). Current maintainers sadly have stepped down from this role as well. We have issues that end with ‘please at least say something’.
I am not. Plus, it might introduce LiveQuery, but there are 100+ open issues, ignored PRs (this one being the saddest), minor and major flaws. Don’t want to get technical, but I can’t believe ParseObject is still not Parcelable. That itself should make every experienced dev to not even consider Parse. I have already seen comments here and there @ stack overflow discouraging newcomers about Parse. And I myself would go for something else if I were to start from scratch. The SDK was an incredible effort, I am grateful to whom worked on it, and it’s sad to see it go. I wouldn’t say the REST API is a reasonable fallback, honestly. There are alternative services out there. We need client libraries. Moreover, the Android SDK crumbling down will have an impact on other SDKs as well. Quoting @benitech from the other post,
I hope the Parse Server team would let this issue open until it is solved somehow. |
|
@natario1 would you elaborate on
While I've worked on Firebase projects last year, it wasn't a match to Parse's simplicity. The same goes for AWS Mobile Hub. I fully agree with you on the necessity to upgrade the client SDKs - but why still maintain / add features to Parse Server without the intention of upgrading the client SDKs? I believe most projects running on Parse are mobile apps... If its really over with the Parse Platform, someone should already rip the bandaid and get it over with... |
It might not, but hey, corporate backing is better than no backing at all. Also, ‘simplicity’ breaks down when you find yourself spending weeks debugging nasty internal bugs. I agree Parse is still the best service for AnyPic / AnyWall apps. But for anything more complex, the SDK needs some love at this point, IMO.
Yes, that makes no sense. If Parse Server wasn’t so incredibly improved in the last year we probably wouldn’t be here struggling about android. |
|
@natario1 Most of the (almost every) new features added to parse-server have been contributed by people outside parse/facebook. I don't believe anyone has risen to take over that SDK and start contributing and fixing those issues you mention. I am not part of Facebook or parse, I contributed on my own time to parse-server. I haven't seen this kind of activity on the Android SDK, and no one can force the community to come together to maintain that project. It seems that you all want to see those SDK well maintained, and evolving, I would love to see it too. This starts with contributing, answering the issues etc... If no one is ready to take over, the community 'ripped the band-aid' themselves. |
|
@flovilmart sure, this is not a corporate rant against Facebook or Parse (not mine at least). I think the goal of the OP is ask Facebook to open up the maintainance part to someone else, and to find that someone else. Right now no one is even merging PRs. And that is discouraging for anyone else. That’s what I would like. |
|
As someone who is not a developer, i was very disheartened by the minimal progress on the Android SDK personally, especially after i had made the choice to start my project with Parse (even after the parse.com shutdown announcement) assuming that the community would really step in big time. Which they did on the Parse-Server for sure. As of now, i have had to spend considerable time and effort in moving away from whatever i was using in Parse Server. I would personally not recommend any new project with Parse. Harsh but real from a PM perspective. |
|
On another note, the amount of time i had to spend to simply get oAuth working was just unreal. @flovilmart was very helpful always, but everyone will note there is still not a simple writeup "how to for dummies" anywhere |
The community is not something magic you can invoke to solve your project, if you're a PM, you know developers, and if you know developers you could have enticed them to become that community.
So you don't use parse-server anymore? Not sure you're adding anything constructive to the discussion besides criticizing the lack of community support for the android SDK.
No there isn't, also nothing prevents you to do it once you managed to get it working. I am really sorry you guys feel that way, and abandoning ship, but I can't do much about that either. Unless someone / many ones are wanting to step up and maintain the android SDK, I'm not sure it's relevant to discuss much more over here. (also this feels more like a bashing than a discussion). I'll close the discussion here, feel free to reopen on the Android SDK. |
|
@flovilmart sorry, but let’s pretend I am an experienced Java developer. I start working on it, make ParseObject parcelable, implement LiveQuery, stop using undocumented, deprecated GCM stuff. Then my PR lies open, just like 95% of what was opened in the last months. What do we do? I think some words are needed from current maintainers, e.g.
|
The best way to get that would be to open those PR, start commenting on issues etc... |
|
@natario1, slow down. Let's stay on target. The point of this thread was not to rant and re-hash what is already known but to get Android developer support in the community. @flovilmart I understand you are encouraging the community to step up but as mentioned before the PR's just sit there unapproved. Can you ask FB or Android maintainers and to spend a few hours of their time approving the PR that are already out there? Once we get the ball rolling on PR's more people will contribute. Finding a maintainer within a 5 day window here was never likely. Let's focus on breathing life into the SDK first. I'd really hate to fork it, that just get's messy and confusing for new devs. |
|
I have been a part of opensource community for many years on various Apache projects and know well how it works. I am happy to have left parse totally and @flovilmart 's comments make me feel even better about doing so. Good luck and good riddance. |
|
@benitech thanks for making me feel wasting my time on helping you instead of someone else. |
|
feel free to make yourself feel as self important as you can. |
|
Seriously - how the hell did this turn into a rant? Maybe we could summon @inlined (one of the orig. contributors to the Android SDK)? He has worked on the massive PR that never got accepted - but seems to be working on Firebase now - however he still contributed to the Android repo... @flovilmart I really thought you were a member of the Parse team... you've done a great job. To be honest, I won't be jumping ship just yet and I'm willing to contribute to the iOS SDK, as far as my experience will allow. What would move things along is a Parse Slack channel - anyone know of one? |
|
@benitech STFU. @flovilmart Ignore the losers please. You do great work. |
|
@nitrag as always There is the gitter open, https://gitter.im/ParsePlatform/Chat I don't hang out much there but that would be a good start for discussing int |
|
you wanna get abusive, then write it in detail. no need for acronyms. |
|
@benitech your account have been reported. |
|
It's fun to be summoned, though I'm sorry it was due to frustration. For everyone's sake, let's all take a deep breath and be sure we're calm before continuing. As a wise Parser once told me, always try to deescalate. In the meantime, I'm glad to offer some background if it will help: FCM: I was actually the Parse Push developer, not really an Android maintainer. I'm a pretty bad Android dev, so this is better for everyone. The PR I sent out tried to move the Parse Android SDK to GCMv4. I couldn't reveal at the time this was in prep for the public release of FCM. I didn't want the Parse SDK left in the cold when FCM was officially released and I got permission from Google leadership to contribute in that narrow regard. The PR was rejected for the right reasons. Parse went through pretty long lengths to reverse engineer GCMv3 so the Parse Push API could be implemented without a dependency on GMSCore, which contributes to the DEX limit. Unfortunately GCMv4/FCM is a much thicker client and it would be foolish to reverse engineer. Also, due to a behavior change in multiple senderID registrations from v3 to v4, this PR had to drop Parse's senderID when the developer provided their own. If the developer's account had any trouble there would be no backup. The advice was to wait until Parse.com is fully sunset before endangering the Parse.com experience. Now that the radically simplified FCM SDK exists & the Parse.com shutdown is sadly here, I think it's definitely time to do some deep cuts in the Android SDK. Almost all of the ParsePush code can be ripped out--from PPNS to the GCMv3 helpers to the weird trampolines we added to reuse BroadcastReceivers/IntentServices to avoid new setup instructions. Instead, just one BroadcastReceiver can be repurposed to listen to the Intent sent by FCM when a new token is found and stuff it into ParseInstallation. Devs who add the FCM dependency will just work (no code necessary) and devs who don't use Parse Push won't lose the DEX space. I've been burning the midnight oil for a long time now and add can't afford to add this to my plate, but I'd be glad to give someone tips if they want to take a whack at it. Parcelable: I appreciate the praise for Parse's simplicity. To abuse a quote: it takes a lot of complexity to make good simplicity. ParseObject's state management is really complex. Look for "opSetQueue" and you'll start to pull on that thread. The real Android stewards were very good at what they did. I'd create a separate request inside the Android SDK repo and tag an owner to get better context here. I highly recommend working out a strategy for Parcelable before doing any coding. The result of the conversation might be that that the intentional decision to not implement Parcelable stands. Community: First and foremost, @flovilmart deserves respect. He is an unpaid contributor working in his area of expertise. He has been so active in the community that even I once thought Parse had hired him after I left. You won't get anywhere treating a gift as an obligation--@flovimart's prior contributions don't require him to give anymore and his skills in ParseServer don't mean he's the right person for any Android love. The dirty secret about Parse's open source future is that it's at risk because of community abuse. Not a single Parser, past or present, is happy with the shutdown. A lot of good people poured their soul into Parse. The people who stuck around to help the community took a lot of abuse from developers who were hurt & angry about the shutdown. Anyone would have trouble staying moralized when stuck between a parent company that pulled your project and a community that abused you for it. Here and everywhere else, please remember that open source is a gift and you get the community you create. If you want to contribute, make sure the maintainers are on board with changes before you do them. If you are asking someone to contribute for you, try to make it easy for them to help you. If a repo needs TLC, talk to the owners about why. Here it seems the Android SDK needs an active contributor. Try to find one who is willing and able to do the job. If you know enough to talk about |
|
Funny to see people bashing at @flovilmart, when all we’d need is just another flovilmart for android :-) respect to you man.
Thumbs up. There’s a kind of vicious circle to be broken, due to owners somehow being away and contributors not being encouraged to contribute. I think breaking it takes something from both sides. |
What a shame really... @inlined, do you happen to know if someone from the old Parse team would even consider coming back to the Android repo? If not @nitrag where do we go from here? As I've already wrote - I'll be taking a look at the iOS issues, but there is nothing I can do for the Android SDK :/. Also - did we just established that there is no "official" support left for the platform? Because from what I've seen, I think the community still thinks that there is someone at Facebook still hacking away at this. Maybe making that clear in the READMEs would help the community mobilize... Edit: I've just checked out the stats for CocoaPods Parse installs - 20k a week, 70k a month - if you ask me, the platform is far from dead. If the numbers for Android are 1/2 that, thats still massive enough for us to bring together a team of contributors... |
|
I'm also curious, what are some possible next steps then? Is it that we need someone to ask @nlutsenko for merge permissions on the repo? (Is there somewhere to see who the maintainers are?) |
|
I'm not sure one want to 'give' merge permissions to anyone at random. There is some trust to be established first with external contributors. So the next natural step is that some/many ones start to actively maintain the project, open PR's, help with issue triage, investigation etc... before we can talk about commit access. This person should at least demonstrate some knowledge of the AndroidSDK and complete understanding of the parse platform in general. I'm happy to discuss this point of view. I'M pretty sure that if one or few people start taking this matter in their hands, @grantland and/or @wangmengyan95 will happily leave the keys to the castle to those people. As for me, unfortunately, I'm not versed enough with Android to provide a critical eye on the Pull requests, nor have sufficient knowledge of the SDK. |
|
"I'm not sure one want to 'give' merge permissions to anyone at random." I didn't suggest that. No need to be argumentative. |
|
Here is something concrete that could be discussed: this PR looks (I think) like it could be merged, what would be a good next step for it? |
|
Here I disagree, the justification of the fix seems weak, no test added etc... |
|
@MartinHerman I raised this to the Parse team and we're discussing the next steps, hang in there. cc @gfosco |
|
Even I am excited to see next update on Android Mobile App SDK because I am usually doing more work on android apps. :) |
|
No news about this, or is there a discussion going on somewhere else? |
|
@inlined @flovilmart @codegefluester - guys, any news on this? |
|
@MartinHerman @natario1 Nope, haven't heard anything new so far |
|
Is any one of you interested in taking over? It first starts with triaging issues. |
|
@flovilmart I can help =) |
|
Given the Parse shutdown, the question also behooves what min Android SDK version is needed. A lot of backwards compatibility choices were made to support older Android versions (parse-community/Parse-SDK-Android#189). I think the community can be more aggressive about supporting newer Android versions and then receiving help to address backwards compat issues (parse-community/Parse-SDK-Android#231 for instance, HttpUrlConnection should be good enough to go) |
|
@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 parse-community/Parse-SDK-Android#548 and parse-community/Parse-SDK-Android#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 (parse-community/Parse-SDK-Android@b3f457f) before this SDK went into hibernation. 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) :) |
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 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. |
|
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. |
|
@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?
The text was updated successfully, but these errors were encountered: