search

parse-community / Parse-SDK-Android

The Android SDK for Parse Platform
https://parseplatform.org/
Other
1.89k stars 735 forks source link

The future of Parse Android SDK #1100

Open azlekov opened 3 years ago

azlekov commented 3 years ago

Hello šŸ‘‹, I'm using the Parse SDK for more than a year now for a side project of mine. For this time I did not see any movements here and fortunately I stumble upon just one new issue with the Firebase configuration, because the FCM module requires an older version. In Firebase SDK latest releases they did some breaking changes moving some stuff around. Downgrading the version was a workaround.

Meanwhile a have influenced from the Parse-Swift new SDK and start to build upon it a pure Kotlin one, where can be found here: ParseKt Everything cool, but I hit some quite challenging stuff around typings in Kotlin and type erasure on the JVM, where for Swift there are solutions provided by the language. So I hit a wall.

Next I start thinking how to overcome this situation - using non-active supported SDK and challenges creating a pure one in Kotlin and to have stable up-to-date solution for my projects.

Few options I imagined here:

  1. Re-thinking and implement something similar to this current SDK but in Kotlin (the ParseKt heavily uses generics and ratified types + kotlin.serailization instead of JSON 'bag' with Map and fat deserialisers with type checking)
  2. This SDK is a solid, but huge one. So maybe a good approach will be to be modernized and step-by-step internally replacing and changing critical and painful parts (bolts, local storage issues, etc). This is not a job for one person who don't know the SDK internals and decisions taken there.
  3. I was start thinking and actually rise a question why to not replace this SDK in my project with a Apollo GraphQL. For me seems that the overhead will be manage of authentication and of persistence which I start manage also using this SDK because of problematic local storage. I address also that I will lose some flexibility in manner of typing because of the flexible ParseObject.

After all I decide to give a chance on this SDK and see where I can go for a short time and was hoping for support from the core members to continue this discussion and to help somehow with the native Android SDK. Pure Kotlin SDK also means that, it should run on the JVM and Parse can be consumed from other servers (microservices) or desktop apps. Also means that with proper decisions and discussions, can be a Kotlin Multiplatform Module KMM another option to the community.

My master plan for this SDK is:

@mtrezza I open this issue more like a discussion board, where I hope šŸ¤ž to find followers and push the Android SDK to a bright future and in the right direction šŸ˜„ ...again, inspired by the Parse-Swift.

Looking forwards, Asen

mtrezza commented 3 years ago

Thanks Asen for starting this important discussion!

First off, a big thanks from the core team for picking this up, and with such a hands-on approach. We will make sure this effort gets every support possible to improve the long-term sustainability of the SDK. I've pinned this discussion to the top of the issue list in the hope for other contributors to join in.

Two basic questions that come to mind are:

cc @parse-community/core-maintainers @Jawnnypoo @rogerhu

mobilekosmos commented 3 years ago

I'm wondering if "Port the source base to Kotlin" is really necessary? You can call java code from Kotlin without problem, you never know what the future brings, maybe someday people will prefer to use more of JAVA again for Android Apps, etc.

mobilekosmos commented 3 years ago

@L3K0V are you continuing the job as you said? because I want to use it in a proyect and as you said this lib needs some work.

mtrezza commented 3 years ago

This thread is an important one deserves more attention. Maybe I can help to kickstart the conversation by posting a call on our Twitter and inviting other to join in. @L3K0V Would that help?

azlekov commented 3 years ago

I'm wondering if "Port the source base to Kotlin" is really necessary? You can call java code from Kotlin without problem, you never know what the future brings, maybe someday people will prefer to use more of JAVA again for Android Apps, etc.

Kotlin overall provides more syntax sugar and features which Android can leverage for easily development. Supported Java version in latest Android is Java 11 which is LTS. Latest LTS is actually Java 17 from few days ago. So my point is that for Android development using Kotlin gives you possibility to have nice and cool features as soon as possible where Google team are trying their best to catch up with the Java versions and back port some stuff using desugaring for example.

Does it make sense to do this change in a new Parse Kotlin SDK repo? Maybe after the first two steps of the plan, which would be beneficial also for the current Android SDK I suppose.

I'm thinking lately for the Kotlin approach here and what @mtrezza said. It sounds like a good idea to split the Java and the Kotlin Parse SDK into two repositories until we have a stable Kotlin one. Correct me if I get it wrong @mtrezza but your idea is to split and have two parallels SDKs for some time?

@L3K0V are you continuing the job as you said? because I want to use it in a proyect and as you said this lib needs some work.

How my work is stopping you from using the SDK, @mobilekosmos? Are you referring this SDK or my ParseKt experiment?

mtrezza commented 3 years ago

Correct me if I get it wrong @mtrezza but your idea is to split and have two parallels SDKs for some time?

Yes, analogous to how the Parse Swift SDK is developed separately from the Parse iOS SDK. The iOS SDK can still receive hotfixes if necessary, but eventually it will be archived and replaced by the Swift SDK as soon as there is feature parity, excluding features that have been deliberately discontinued.

mobilekosmos commented 3 years ago

How my work is stopping you from using the SDK, @mobilekosmos? Are you referring this SDK or my ParseKt experiment?

I didn't mean it like that, but the current state of the SDK is not really usable, all dependencies are outdated, etc. I tried to fresh it up by myself and needed 1-2 days for it, then I saw you already made a PR with dependencies updates, but it's still under revision and it takes ages for someone to merge PRs. For example, after updating all dependencies and making needed changes, uploading to jitpack is broken on my end because maven-publish works now in a different way and I don't have idea how to fix that. In the end I only want to work with an up to date library.

azlekov commented 3 years ago

The Java 8 improvements should be done. I need to build a version and do some manual tests. All unit tests passed. So I'm also kind of waiting. I'm not 100% sure if the coverage is reported right. Kotlin changes are independent and they are derived from the Java 8 improvements branch.

mtrezza commented 3 years ago

@L3K0V What do you think would be needed to kickstart the master plan you proposed? Should we create separate issues for each of the steps and maybe apply bounties to it to incentivize others to join in?

azlekov commented 3 years ago

I believe we need somebody from the core team who knows the Android SDK internals, maybe to help us or share some knowledge. The update dependencies PRs are stacking up but there's no much feedback from the core team. Also from what I see, there's no much interest regarding the Android SDK future from the community.

mtrezza commented 3 years ago

I would not infer the level of community interest from this issue activity. I think many are using the SDK, but because it currently just works, there may be little traffic to the GitHub page. In fact, in an ongoing poll within our community, 40% of respondents say they actively use the Parse Android SDK. It's among the top 3 most used SDKs, out of the 11 SDKs.

I assume you mean https://github.com/parse-community/Parse-SDK-Android/pull/1095 - let me look how we can get the ball rolling.

mobilekosmos commented 3 years ago

PLEEEEEEEEEEEEEEEEEEEEEEEEEEEEEASE update the lib to newest standards :)

mtrezza commented 3 years ago

It seems that your capitalization worked, @mobilekosmos šŸ˜

It's still a pre-release with 2.0.0-alpha.1, because there are a few other PRs we want to merge before official release. But because its pre-released, you can already try it out easily in your project - any feedback is welcome!

API docs updating already works locally https://github.com/parse-community/Parse-SDK-Android/pull/1110, will be published with release 2.0.0

Shabinder commented 3 years ago

Yeah, I would like KMP support too, at least JVM, it will let devs use this for Desktop Clients also rather than limiting it to only Android.

bahaa-kallas commented 3 years ago

Thanks for the proven effort so far.

Pure Kotlin SDK also means that, it should run on the JVM and Parse can be consumed from other servers (microservices) or desktop apps. Also means that with proper decisions and discussions, can be a Kotlin Multiplatform Module KMM another option to the community.

I hope that you take in mind making the library multiplatform-ready (as high priority) during porting the sdk to kotlin. Because KMM will enter beta in spring 2022 and in about 6 months this topic will be brought up again to make the sdk multiplatform ready (if not already made) which will means there will be some sort of refactoring (And there might be some breaking changes as a result of that). So I advice focusing on shifting the sdk to pure kotlin and making it multiplatform-ready in one run.

Greetings and looking forward to try it out

parse-github-assistant[bot] commented 3 years ago

Thanks for opening this issue!

mobilekosmos commented 2 years ago

Following question, there is no full time dev working on this project, right? If no, why actually?

mtrezza commented 2 years ago

We are working on that.

andypliu commented 1 year ago

Thanks Asen for starting this important discussion!

First off, a big thanks from the core team for picking this up, and with such a hands-on approach. We will make sure this effort gets every support possible to improve the long-term sustainability of the SDK. I've pinned this discussion to the top of the issue list in the hope for other contributors to join in.

Two basic questions that come to mind are:

  • To your third point: Are there any working concepts out there which use a light native wrapper around a cross-platform GraphQL core? If there is a working example, we may want to study this closer in an effort to re-think the way we currently maintain our SDKs. Each SDKs is written from the ground up without a shared code base, which may not be state-of the art anymore. We may want to research that.
  • To your master plan: Does it make sense to do this change in a new Parse Kotlin SDK repo? Maybe after the first two steps of the plan, which would be beneficial also for the current Android SDK I suppose.

cc @parse-community/core-maintainers @Jawnnypoo @rogerhu

Hi Mtrezza,

Any update on the new "Parse Kotlin SDK"? Will the KotlinSDK be KMM library? Has the project started?

softcleandev commented 9 months ago

What is the current status? Is the project still alive?