The future of Parse Android SDK

[azlekov]

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:

• Migrate everything and refactor the code to Java 8
  • feat: update all dependencies and modernize the source base #1095
• Update all dependencies to be up-to-date
  • feat: update all dependencies and modernize the source base #1095
  • feat: update project dependencies and code refactoring #1141
• Waiting all feature PRs to be merged
  • feat: add support for custom objectId #1088
• Port the source base to Kotlin
  • Migrate the source base to Kotlin #1099
• Remove bolts and replace them with coroutines
• Remove local storage and provide extensible storage interfaces, so everybody can implement their own storage - Room, ObjectBox, Kodein-DB, etc.
• Create runtime or api module which can be KMM or just for the JVM without bound to Android APIs.
• Normalized cache

@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]

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

[mobilekosmos]

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]

@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]

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]

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]

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]

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]

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]

@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]

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]

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 #1095 - let me look how we can get the ball rolling.

[mobilekosmos]

PLEEEEEEEEEEEEEEEEEEEEEEEEEEEEEASE update the lib to newest standards :)

[mtrezza]

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 #1110, will be published with release 2.0.0

[Shabinder]

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]

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]

Thanks for opening this issue!

• ❌ Please edit your post and use the provided template when creating a new issue. This helps everyone to understand your post better and asks for essential information to quicker review the issue.

[mobilekosmos]

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

[mtrezza]

We are working on that.

[andypliu]

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]

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