Migrate AppAuth to Kotlin and split it into two modules

[amrfarid140]

Kotlin became a first class language for Android in 2017 and since then more and more projects adopted it. AppAuth interoperability with Kotlin has been great but it still can benefit from being written in Kotlin.

In addition, this library has two things:

1. Implementation for OAuth2.0 protocols.
2. Integration with the Android platform for redirect handling and other parts

We can split this library into two parts.

The first would be a pure kotlin one where OAuth2.0 protocols are implemented and the second would be the platform dependent one where the OS is needed for redirection handling for example.

This can also be an opportunity to Kotlin coroutines instead of AsyncTask and decide if we want to support Kotlin multi-platfrom.

What are your thoughts on this?

[agologan]

First of all, a rewrite should be done as a separate project and if successful we would recommend people to migrate to that. Secondly, in order to migrate to it, ~~compatibility with Java must be maintained~~ API design when calling from Java needs to be considered (see below). Thirdly, having two modules - one for the api calls and another for the Android integration is a good idea assuming the first module does not depend on Android specifics at all, otherwise the value is diminished.

[amrfarid140]

rewrite should be done as a separate project

I get the point but no necessarily agree. We can use a different branch as a new develop or master for this rewrite and merge it to actual master when it is recommended.

compatibility with Java must be maintained.

100% agree

assuming the first module does not depend on Android specifics

Yup.. that's the idea. Decouple logic from the Android platform as much as we can

[agologan]

A rewrite is not a conversion, or a migration - it's a new product which would have a new structure both physical and logical and a new API surface. It can share the AppAuth name but it should not clobber this current iteration of the product. Yes it can live in a branch, but at that point it's a completely new codebase, which probably deserves it's own repository and identity.

[raderto]

Why not just convert to Kotlin and make it a major version release? Also don't we get 100% interoperability by default? Conversion to Kotlin is more of a refactor than a rewrite. The bulk of documentation, examples, logic would be the same.

The conversion away from AsyncTask is expected tbh, AsyncTask is deprecated.

[agologan]

Sorry, in regards to Java compatibility I guess I needed to be more explicit: yes all Kotlin could be callable from Java with some caveats: one being the required Jvm annotations and the other, knowing generated code patterns. Calling Kotlin from Java is not as straightforward as the reverse so if you wrote a new library it would be nice to give some thought to the API if that's an important topic to you.

To your second point, I read the proposal as being an incentive for a rewrite, not refactor hence my further arguments to create a new product. If the proposal was instead about a conversion then I'd have to ask why?

[raderto]

Gotcha. If you're avoiding singletons or using Dagger for those you really shouldn't run into a ton of issues with java calls into Kotlin. @JvmStatic is likely all you would need and I would expect there to be significantly fewer @JvmStatics that @NonNulls or @Nullable annotations which you'd get from Kotlin's ?. Also, the work done to put those annotations there will result in really good conversion as they're carried over to teh resulting Kotlin.

On the why, you would be able to use coroutines and create suspend functions to make the network calls while sharing the same pool of resources as dispatchers (as migration away from AsyncTask occurs you don't have alloc a new thread internal to the SDK). It would make it easier to contribute back as Android dives deeper into Kotlin. The code size would also shrink drastically given the amount of null checks in the library.

I don't think you would need to go full blown separate everything out the gate to get the benefits of Kotlin. You could separate those asks and treat them as different.

[Pertence]

Adding to the discussion, is it interesting to have a demo app written in Kotlin? I can help create one if anyone is interested.

[agologan]

I don't mind it but I haven't seen anybody asking for this. It's probably because Kotlin vs Java semantics are so similar that you can just convert code in your IDE if you want to. Might be a good idea to just start with the Readme examples and see if there are any takers.