DEV Community: Luca Nicoletti

Be careful with package names

Luca Nicoletti — Wed, 28 Feb 2024 16:21:45 +0000

A few days ago, while working on a side project, I got the point that I needed to create a feature that would allow the user to Add something to my app.

The package showing the already existing objects of the app was declared as follows: appName.objectName.list so I decided to add an appName.objectName.add package to include all the components needed to build that specific part of my app: screens (I'm building this app using Jetpack Compose), composable functions, view models, models, view state definition etc.

Little did I know, I was making my future self-life as hard as I could.

So I went ahead and used the right-click of my mouse to show the pop-up menu to create a new package:

I then proceeded to insert the new keyword for my new package:

Unfortunately, I completely missed the warning you can see above, as I simply typed new and pressed Enter as soon as I was done.

I missed the hint of the Android Studio editor:

That shows something was different with that folder (yep, not a package!).

I went ahead and created my screen, my various composable, and my ViewModel class inside of that package, and ran the app on my device. Initially, the ViewModel had no dependencies so there were no problems.

Kept coding for a while and started adding external dependencies to the ViewModel, to perform the action of adding my objects to the app, with all that it comes with: defined a view state that the screen observes and updates accordingly, created various functions to update that state, from the screen to the view model, etc...

I'd say I spent an hour coding the entire screen, something like that.

And so, as we all do, after finishing coding I re-ran the app to check that everything was working as expected. The app crashed as soon as I tried to reach that screen.

As I was using Room for local storage, and did a few updates on the classes, I thought I'd forgotten about bumping the Database version - so the first thing I did, without looking at the crash log, was to go to the definition of the database and update the version. But that had already been increased by past-me, what a surprise! For once I did the right thing.

So I re-ran the app and looked at the Logcat output to check what was causing my app to crash.

The crash was:

FATAL EXCEPTION: main
   Process: com.lucanicoletti.app, PID: 31649
   java.lang.RuntimeException: Cannot create an instance of class com.lucanicoletti.app.screens.intervals.new.ViewModel
[...]
Caused by: java.lang.NoSuchMethodException: com.lucanicoletti.app.screens.intervals.new.ViewModel.<init> []

That felt weird. I was sure I had set up the ViewModel correctly as the first time I tried reaching that screen, the instance (despite missing external dependencies) was created without problems. I double-checked that the ViewModel had the correct @HiltViewModel annotation, that the (only) activity it was contained within had the correct @AndroidEntryPoint annotation, and that the dependencies it relied upon were set up correctly with either @Bind or @Provide annotation from a @Module. Everything was set up accurately, or so it looked like so.

So, what was I doing wrong?

I started searching for possible solutions on the web, checking StackOverflow for questions with similar errors and crashes, asking ChatGPT for a possible solution, and reaching out to groups of developers I belong to.
All I was able to find were solutions that didn't apply to my case: missing annotations on the ViewModel (or wrong, outdated one), dependencies not set up the correct way, missing annotation in the activity hosting the ViewModel, or other things I already checked in my app or that upon checking, were made precisely.

My app at that point had 3 screens (counting the new one I was creating) and the only difference between those three screens was how they were added and reached from the Navigation component in Jetpack Compose. I had two nested graphs: one containing the two main screens (the two reachable from a bottom bar in my app) and a nested one (the one I just created and was causing trouble). So I thought it was due to the nested-ness of the newest screen, perhaps Hilt (dependency injection) wasn't able to retrieve an instance of the ViewModel due to that. Perhaps there was a specific configuration to set up to have nested graphs and ViewModels injectable. So I went ahead and created this question on StackOverflow.

I got a few comments and an answer, but none was pointing me in the right direction - they couldn't know, since they didn't know the noobie mistake I started with.

After a few days of doing extensive Google searches every search query had only purple results on the first two pages (yes, I spent around 2 days looking at every possible link Google gave me with different queries pointing at my problem).

I was close to giving up: I tried replicating the problem in a smaller (smaller than 3 screens and 3 dependencies, can you imagine?!?) project, but since for time-seek I didn't create the same package structure, the problem was not happening in the replica project. I didn't know what to do, and then a friend asked me for a complete stack trace of the crash (I only posted parts of it, removing namespaces, and so, to hide my app name, screen name etc..).

While copy-pasting the errors in the chat with him, I don't know for what reason, my eyes took a peak at the package structure in AndroidStudio Project Structure and noticed (image above) that the package I was in was missing a small circle on the folder's icon. I wondered why. So I moved the files outside of that package and re-ran the app. It didn't crash.

I deleted the package and re-created it, giving it the same name it had from the beginning: new. The app crashed again. So I renamed the package once more, with add instead of new and the app was running smoothly without crashing.

I was astonished by this situation, it was surely one that no one would have been able to debug for me without having access to the project file(s). But even with that at hand, it might not have been so easy to spot the problem. The warning (second image) is only momentary and doesn't stop you from creating a package with a reserved name my simply hitting Enter on your keyboard.

I would love to get a dialog prompt warning me about the mistake I am making in this scenario, perhaps it would be worth raising a ticket on Android Studio? What do you think? Should I create one? Would it be helpful to everyone in the future to prevent being in my same situation?

Keep your UI test working when migrating from native Auth0 to WebAuth0 login

Luca Nicoletti — Sun, 16 Apr 2023 15:15:53 +0000

Introductions

Auth0 is a popular identity and access management platform that provides developers with an easy-to-use solution for securing their applications and APIs. With Auth0, developers can quickly add authentication and authorization to their applications without having to worry about the underlying infrastructure. Auth0 supports a wide range of authentication protocols and provides a customizable login page, multi-factor authentication, and social identity providers. In this blog post, I will show the two possible solutions offered from the Auth0 SDK to login the user, and how migrating from one another could break your UI E2E automated tests, and how to "crack" a working solution to maintain your test checks all green ✅.

Auth0 SDK

Auth0 makes authentication and authorization easy
Because you have better things to be worrying about.

And I couldn't agree more, us developer have better things to spend our time on, login should always be an effortless implementation in an application, from all points.
In the specifics, the Android Auth0 SDK provides 2 ways of logging the user into your application:

Native login
WebAuth login

Native login

The SDK provides a method to invoke to login the user using username and password. There are variants of this method, one accepting a callback, and one using coroutines, suspending the current thread.
Our app had already in place the native login, using callbacks (a bit of legacy code).
The method, inside the callback, provides you a Credentials object, containing both authToken and refreshToken, which you can then save using the CredentialManager class (from the Auth0 SDK), and re-access whenever you need them to perform any authorised-only API call to your backend.
This method is pure Java/Kotlin and requires you to setup your own UI (however you want) in your app.
Our app looked like this:

We had two fields: username and password, and a checkbox to keep the user logged in. The login button is disabled until both the fields are filled with valid inputs.

Once the user clicks on the login button, we perform the login with Auth0 native authentication, and then navigate the user accordingly to the correct page (either the dashboard or the account setup page).

WebAuth login

The WebAuth login instead, gives you a login-page (that is customisable through the Auth0 dashboard), so you don't have to think about the UI inside your app, not entirely, at least.
You just need to tell the SDK to start the web-flow.
We changed our login page to look like this

It is much simpler, it just has a login button and a checkbox to keep the user signed in. Once the user clicks on the login button, the web-flow is started, and the webpage is shown:

SDK setup

To use the Auth0 SDK, some setup is required, and by some I mean "very little".
The shared setup between the WebAuth and Native is this simple line of code:
val account = Auth0("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")
With this, you will be able to login the user with the WebAuth without anything else.

Native

For the Native login, some more configuration is needed:

val authentication = AuthenticationAPIClient(account)

With this authentication object, you can then login the user using the following code:

authentication.login(username, password)
   .setScope(authScope)
   .setAudience(authAudience)
   .start(callback)

With

authScope being the scope (configured on the Auth0's dashboard)
authAudience being the audience (configured on the Auth0's dashboard)
and callback being a Callback<Credentials, AuthenticationException> used to proceed after the login is successful (gives back a Credentials object), or to show what went wrong from the AuthenticationException received)

WebAuth

For the WebAuth instead, once you have the account object, you can directly call:

WebAuthProvider.login(account)
    .withScope(authScope)
    .withAudience(authAudience)
    .start(activity, callback)

The parameters are the same as the ones above, with the addition of the activity (used to launch the new web activity with ACTION_VIEW from inside the SDK).
Some more configuration need to be done, as you have to specify the callback URLs (for login and logout) on the Auth0 dashboard, and inside your app. This can be done in the manifest as explained here.

Both

The code shown above allows you only to login the user, and gives you back the Credentials. But if you don't store and save them, you won't be able to keep your user logged in, or re-use them at will when needed.
To achieve this, some more code is needed:

val auth0Storage: SharedPreferencesStorage = SharedPreferencesStorage(context)
val credentialsManager: CredentialsManager = CredentialsManager(authentication, auth0Storage) 
// authentication is already defined above

Now with the credentialManager instance, you can save the credentials, using the fun saveCredentials(credentials: Credentials) function, and also retrieve them, using the function suspend fun awaitCredentials(): Credentials. You can also check, beforehand that the manager has valid credentials, using fun hasValidCredentials(): Boolean.
With these three function, you will be able to login the user, save his/her credentials, and retrieve them at will, whenever you need them.

Why migrating to WebAuth?

Since we started targeting a broader audience (we're a B2B), some of our clients asked for - or suggested it would be nice to have - an universal login that allowed them to login using existing accounts from other platforms (e.g.: Google, Microsoft, Apple, etc...). I won't talk about all the UX process that we went through, but in the end it made sense, not requiring a personalised account on our side, and allowing a user to authenticate throughout another existing account would make ours - and their - lifes easier.

Migration

As you might have already seen from the code above, the migration from one to the other is pretty easy and straight forward. There aren't many differences, and both requires a minimum effort to implement, even if starting from scratch.

In fact, it took relatively a short amount of time to do the migration, even using a TDD approach, refactoring all the tests first, and then applying the changes in the code to get back on a full passing test (I'm talking about Unit tests here).
I left UI tests as the last thing to check and update, and boy that was a mistake.
The changes on the clicks to be performed were easy, as it was removing all the "fill this field with X".
The problem was now that, after tapping on the login button, we were outside of our codebase, outside of our application, in a WebView opened from an SDK of which we have no control.
We tried using Espresso Web with androidTestImplementation 'androidx.test.espresso:espresso-web:3.4.0' but unfortunately the framework was not able to find the webview, probably because it was not inside any of our view hierarchies.
I asked the community on StackOverflow if anyone else faced the same problem before, hoping for an easy solution on how to interact with the WebView launched.

No luck.

So we tried checking if it was possible to configure, only for the test-folder, the object WebAuthProvider to automatically perform the login for us, sending to it a username and password. I also opened a feature-request on the Auth0 Android SDK here.

No luck. Again

We had to find another solution to keep our UI E2E tests running.

Interface to the rescue!

After struggling for a bit, we thought about using an interface to solve all our problems: the initial idea was WebAuthProvider required, and perform the login for us. This way, we could have two different implementations: one for our "real" codebase, the one that would run in production and allow the user to login, and one that would be specific for testing, overriding the default implementation, and logging in the user without opening any webview or using the WebAuthProvider.

After considering what to provide this interface and what not, we came up with this solution:

interface WebAuthLogin {
    fun login(
        activity: Activity,
        event: OpenUniversalLogin,
        onSuccess: ((result: Credentials) -> Unit),
        onFailure: ((error: AuthenticationException) -> Unit)
    )
}

where the OpenUniversalLogin event contains the following:

data class OpenUniversalLogin(
    val auth0: Auth0,
    val scheme: String,
    val scope: String,
    val audience: String,
)

Modules and test-substitution

With Hilt we were able to use dependency injection to configure correctly the scenarios listed above: 1 implementation for our production code, and one for testing purposes.
We used a Module to Binds the implementation of our interface. The "official" implementation, as you might have guessed by combining the code I provided, simply would do this:

WebAuthProvider.login(event.auth0)
    .withParameters(mapOf(PROMPT_KEY to LOGIN_KEY))
    .withScheme(event.scheme)
    .withScope(event.scope)
    .withAudience(event.audience)
    .start(
        activity,
        object : Callback<Credentials, AuthenticationException> {
            override fun onFailure(error: AuthenticationException) {
                onFailure(error)
            }

            override fun onSuccess(result: Credentials) {
                onSuccess(result)
            }
        }
    )

Scheme is another parameter that can be configured in the Auth0 dashboard, and since we're using a custom-defined one, we need to provide it to the WebAuthProvider object before performing the login.
The .withParameters(mapOf(PROMPT_KEY to LOGIN_KEY)) line, instead, turned out to be quite useful and required - as well - for us: it was not documented in their repository, but it forced the webview to show the login every time, even if a log out action is not performed. This was a requirement for us, since if the user logs in without the remember me functionality, upon closing the app, we would want him to login again. But without that parameter, since the cookies of the webview were not cleared, when the user clicked the login button, the webview would immediately return to our app, with a logged user, without asking for any credentials.

Whereas for testing, we used TestInstallIn as follow:

@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [RealLoginBinds::class]
)

replacing the "official implementation with a "fake" one that used the "old"-native method to login the user and store its data in the application's cache.
Paired with @UninstallModules() in the tests where we needed the fake implementation.

One additional problem

As you might have noticed, the login function doesn't accept any username or password, so our tests were at the moment blind and wouldn't know which user to login (we need different account as we're testing different scenarios and interactions between accounts - invites, etc...).
To solve this "problem", I had a light-bulb 💡 moment, and came up with

object LoginThingy {
    lateinit var username: String
    lateinit var password: String
}

Kotlin allows you to define an object with lazily initialised variables. With this, our implementation of the login function in the test folder would access the parameters as LoginThingy.username and LoginThingy.password, which we would define, in a case-by-case scenario in our test as

LoginThingy.username = email
LoginThingy.password = password

Conclusions

What we thought was an easy to implement change, turned out to be one of the most challenging task of the last month: not much for the code implementation, but for all the tests we had to do in order to check and re-check that everything was working fine as it was.
Last but not least, after doing the login migration, we had to implement the log-out functionality as well, but that was an easy walk compared to the long, exhausting sprint of the login, given we walked that path already.

The new login is now live in our app, and since it's completely configured from the Auth0 dashboard, we will be able to add Google/Facebook/Apple or other universal login way for our user base to authenticate.

It was a nice challenge overall, that kept me busy with researching online for possible solutions already in place for a while, and I really enjoyed it. Hopefully the next migration will be easier and quicker, without too many headache to follow!