Next Auth0.Android Major release

[lbalmaceda]

Hello! 👋 We've been working over the past month to bring you a few improvements to the Auth0 Android SDK. Yesterday we published the first beta release for the v2 branch.

A few notable highlights the BETA introduces:

• Support for AndroidX artifacts, removing any Jetifier dependencies
• Support for Kotlin runtime dependencies
• Customizable networking client and request stack
• OpenID Connect compliance improvements

If you're coming from the previous major, you can check out the Migration Guide or dive into the updated quickstart guide here.

The release is also available both in Bintray and Maven Central.

We’d love for you to give the new SDK a try and welcome your feedback on any recommendations or issues you encounter.

Should you have any feedback or questions about the SDK, please raise an issue via GitHub.

---

Update Feb 11th

We've released the stable version 2.0.0.

Version v1 will continue to receive Bug & Security fixes until 5th November 2021. After that date, the only version supported will become v2.

[VincentJoshuaET]

Will Lock.Android still be usable with this? (Anyways, Lock.Android still needs to be jetified)

[VincentJoshuaET]

Update: it does not.

java.lang.NoSuchMethodError: No virtual method setDevice(Ljava/lang/String;)Lcom/auth0/android/authentication/ParameterBuilder; in class Lcom/auth0/android/authentication/ParameterBuilder; or its super classes (declaration of 'com.auth0.android.authentication.ParameterBuilder' appears in /data/app/~~CpIqMi9IgDPNHiEE4VhBWg==/com.example.myapplication.debug-nX3nDhHlO_Qx_4VgZCI8gA==/base.apk)
        at com.auth0.android.lock.Lock$Builder.<init>(Lock.java:193)

[audkar]

Awesome news 🎉

Just noticed two things:

1. Using legacy JSON serialization dependency

Gson has been superseded by Moshi years ago. Product app developers can use whatever works for them. But library devs should consider impact of their chosen dependencies and current ecosystem status. And current situation is that Gson is being less used in todays applications. Most clients probably will be using some other serialization tool. Auth0 would pull additional 300+kb to every client.
Maybe consider using some of current popular JSON parser. Or even parse responses with default Java APIs. There is only few places where it is needed and these are quite simple DTOs.

2. Networking logic separated but default implementation (with dependencies) included

It would be logical that default networking/serialization implementation would be pulled to clients only if they use it. Maybe separating two modules:

• auth-core - Auth0 logic + NetworkingClient interface
• auth - transitive dependency to auth-core + default Networking implementations with OkHttpClient

[lbalmaceda]

@VincentJoshuaET

Will Lock.Android still be usable with this?

Lock Android and Auth0 Android are different libraries meant to be used separately. However, this SDK is an api scoped dependency of Lock Android, and bumping the SDK version would imply that every breaking change committed with this major release would now be translated there as well. We could make all the code updates internally to use the newer release, but still, those devs consuming the Authentication API client outside of Lock, for example, would find breaking changes along the way.

Making Lock Android stop requiring Jetifier (migrating to Android X) is a separate project that is not on the scope today. It would also mean a new major release of Lock Android. I can check with the Product team to help clarify that.

[lbalmaceda]

@audkar we appreciate the feedback!

I agree that Gson is old and could use some update. What we need such a library for is really for the simple use case of parsing the server responses and/or the ID token's header and payload parts, which are not too complex for this SDK at least. I think a solution that doesn't involve any third-party libraries would be ideal. I know android does have some support for that e.g. using JSONObject.

About the second one, I like the separation of modules. I would like to balance overengineering this SDK vs providing good defaults. Considering one for production always uses Proguard to remove unused code/dependencies, the final package size should not be a problem if you decide to provide your own implementation of the NetworkingClient with a different networking library than the one we choose.

It's our understanding that Square's OkHttp is the most used networking client on Android/Java. Square's libraries are even being used officially by Google in their codelabs, and the Android Studio IDE has official support for OkHttp in the Network Profiler tab (pictures below).

I'm curious about what networking library you use typically on your apps? Or if you normally use Proguard for production builds.

Let me raise these in our next Product call to evaluate making those changes.

Resources

Codelabs using Square's libraries

Network Profiler

[audkar]

@lbalmaceda

I'm curious about what networking library you use typically on your apps?

• I dropped Gson many years ago
• OkHttp is default Http client choice for me. But I still see clients which are using something like Volley.

you normally use Proguard for production builds.

Yes, most developers do use Proguard/R8. But added dependency is still pulled. That adds work to Gradle dependencies resolution, code shrinking and unnecessary dependency restriction.

So in case I decide to use my own http implementation, CI server still have to pull default http implementation dependencies and code shrinker work to remove it.
Even in case I use OkHttp client in my application, new major OkHttp client will be release and I might want not to wait for Auth0 client library update. Implementing my own networking with new OkHttp version still would cause dependency resolution problems. (Same thing as happened with Android support/AndroidX dependency).

So 1st point (removing Gson) would be in my wishlist. 2nd point (separate networking default dependencies) is a nit picking to make great library and making sure that it will not cause problems for clients in future.

[lbalmaceda]

Thanks for the explanation. One of the last changes we added this week before releasing 2.0.0 was one that could enable us in the future to safely drop Gson in favor of different implementations. While we still haven't made that decision, it's something we can now change internally without breaking our users. I appreciate you gave us prompt feedback.

[lbalmaceda]

Lock Android got released this week with support for the newer SDK. SLAs got updated as well. I'm closing this now. Feel free to create a new issue if you come across any errors.