Forem: A.J. Kueterman

Create Your Own LOGAF Scale for Pull Request Reviews

A.J. Kueterman — Fri, 03 Nov 2023 21:37:00 +0000

I like the idea of the LOGAF scale, where we can easily indicate if suggestions to PR review or other feedback is given in 'levels of give-a-f*ck'. A scale like this helps collaborators prioritize and contextualize your feedback quickly in a way that's pretty straightforward.

While I love the raw LOGAF model, I do sometimes hesitate to share this philosophy with everyone at my company based on varying levels of comfort with profanity. Instead, I took the time just to indicate my own low/medium/high 'level of caring' that I can share on PR reviews. I also took the time to briefly spell out what I expect from each level. Now in PRs I can include a 'LOGAF level' link and move on.

Below is my basic scale of 3 levels, the description of each, and the link I'd include in each comment.

Low

A this level I usually just noticed something that had a slight code smell. I may spot things that are tangential to your change or just things I 'noticed' when reviewing.

You can self-resolve these comments in GitHub without a comment.

[🟢 low](https://dev.to/robotsquidward/create-your-own-logaf-scale-for-pull-request-reviews-504o/#low)

Medium

At this level I feel changes should be made but can be convinced with a good reason, a follow up story/documentation/etc. that captures the changes in future work or clarification.

You can self-resolve these comments in GitHub with a comment.

[🟡 medium](https://dev.to/robotsquidward/create-your-own-logaf-scale-for-pull-request-reviews-504o/#medium)

High

At this level I feel like changes need to be made before this PR is merged. In exceptional cases, follow up stories & documentation may resolve these concerns, but they would usually require a conversation with me or some other SME.

Do not self-resolve these comments in GitHub. Make changes / leave comments and allow me to resolve them before merging.

[🔴 high](https://dev.to/robotsquidward/create-your-own-logaf-scale-for-pull-request-reviews-504o/#high)

If you decide to implement your own LOGAF scale for your PR reviews let me know on Mastodon @aj on androiddev.social.

How to Use TalkBack on an Android Emulator

A.J. Kueterman — Fri, 28 Apr 2023 17:48:00 +0000

A huge part of making our apps accessible is enabling access for those who have limited vision. This can range from allowing users to adjust the size of the UI or the text in our apps - to making sure that accessibility tools like screen readers can parse the UI of our apps.

The screen reading tool provided by Google on Android devices is called TalkBack. This app is usually installed by default on Android devices, letting users operate their phones without needing to see the screen. For developers, we can use TalkBack to ensure our app is accessible.

However, you may have noticed that this behavior isn't available by default when you create a new Android Emulator in Android Studio - a problem for developers & testers that don't have access to physical devices.

Let's walk through the process of getting TalkBack set up on your Android Emulators.

Create A New Emulator

In Android Studio (I'm using Android Studio Flamingo 2022.2.1), open the Device Manager and choose Create Device.

Select Hardware

Select a device you'd like to create an Emulator of, making sure to select one that has Play Store access. You can tell by the Play Store icon visible in the 'Play Store' column of the selection list.

After selecting the appropriate hardware, click Next.

System Image

Select or download an Android OS image. I chose to download & select Android Tiramisu (API 33), though any modern OS will do.

Once that is downloaded & selected, click Next.

AVD Setup

We've done all the hard work, no changes needed here unless you need to make specific adjustments to your Emulator setup. Click Finish.

Download the Android Accessibility Suite

Back in Device Manager, click the 'play' button on your newly added device to run it.

If, at this point, we decided to go into Settings and look for TalkBack, we won't get any results. This is the default behavior for all new emulators you create. Let's fix that by downloading the Android Accessibility Suite.

Sign In & Search

Your device should have the Play Store app already installed. Open it, and sign in with your Google account. You may have to go through a few setup steps when logging in to the Play Store, as this emulator is treated as a 'new' device.

In the Play Store search for 'android accessibility suite' and download it.

Using TalkBack

After it downloads and installs, close the Play Store and look at your list of installed apps. You may notice that the Accessibility Suite doesn't show up here. That's expected for this very specific app.

Instead, open Settings, and search for TalkBack. Here you'll see the TalkBack option, which brings you to the Screen Reader section of the device's Accessibility settings.

Ta-da! 🥳 Now we can use TalkBack just like we would on a normal Android device.

TalkBack Resources

For more on testing your apps for accessibility with TalkBack, check out these great resources:

Go forth and build accessible apps!

This post was originally shared at ajkueterman.dev

Android ViewModel: Manual Dependency Injection Made Easy

A.J. Kueterman — Mon, 28 Sep 2020 17:29:12 +0000

If you want to go right to a library that enables easy View Model dependency injection, check out Lazy ViewModels on my GitHub

The Android team has been increasingly vocal about their support for Dependency Injection frameworks like Dagger, going so far as to develop and recommend Hilt - their Android DI framework built on top of Dagger - for modern Android development.

In their guide to manual dependency injection the Android team lays out approaches to manual DI for View Models. They offer both the basic approach to manual DI - just instantiating everything you need in onCreate and using lateinit var View Models - and the container approach using a custom AppContainer to handle dependencies across all your Activities.

The alternative they give to this boiler-plate-heavy approach is to recommend Dagger or Hilt to handle this process for you. However, in many apps, pulling in a DI framework is overhead you really don't need. Instead, what if there was a way to manually inject dependencies into your Android Activity & Fragment View Models without all the boiler plate?

Lazy DI Using Android Lifecycle ViewModel Extensions

One of the ways the Android Fragment & Lifecycle teams have tried to make the View Model easier to use in Activities and Fragments is providing the Android Lifecycle ViewModel Kotlin Extensions library.

dependencies { 
    implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0"
}

This library lets you instantiate a View Model in a Fragment or Activity with a delegate method - making it easy to create a properly scoped View Model.

class MyActivity : AppCompatActivity() {

    private val model: MyViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        model.getUsers().observe(this, Observer<List<User>>{ users ->
            // update UI
        })
    }
}

This is beautiful! However, what if our View Model needs to use a repository to make a call to Retrofit? We would like to inject that repository into our View Model when we construct it.

View Model Provider Factory

One way to enable this behavior is to use ViewModelProvider.Factory, with which you can instantiate a View Model with it's needed dependencies. To do so, you need to create your own Factory that extends the ViewModelProvider.Factory interface, or create a function that can return an object that overrides the Factory.create method.

If we wanted to stop here, we could create a Kotlin function to do this for us:

fun createWithFactory(
  create: () -> ViewModel
  ): ViewModelProvider.Factory {
    return object : ViewModelProvider.Factory {
        override fun <T : ViewModel?> create(modelClass: Class<T>): T {
            @Suppress("UNCHECKED_CAST")// Casting T as ViewModel
            return create.invoke() as T
        }
    }
}

And use it in our Activity or Fragment like this:

private val model: MyViewModel by lazy {
  ViewModelProvider(
    this, 
    createWithFactory {
        MyViewModel(repo = MyRepository())
    }
  ).get(MyViewModel::class.java)
}

We can now create a View Model with the necessary dependencies! However, even with our Factory abstracted into a function, we still need to manage the boiler plate of ViewModelProvider.

View Model Provider & Kotlin Extension Mashup

Remember, we could use by viewModels or by activityViewModels to delegate the creation of our View Models, but we weren't able to inject our required dependencies without a Factory.

Now that we have a handy way to instantiate a View Model with a Factory, we can let these Kotlin Extensions for View Model to hide this ViewModelProvider boiler plate. Here's how it would look in a Fragment.

private val model: MyViewModel by activityViewModels {
    createWithFactory {
        MyViewModel(repo = MyRepository())
    }
}

Almost perfect. All we have to do is provide a Factory and a lambda that returns our View Model. But, with a little help from the lifecycle-viewmodel-ktx library and Kotlin extension functions, we can take it one step further.

Endgame: Easy View Model DI

Let's use the power of extension functions, our Factory knowledge, and the ViewModelLazy class to delegate the creation of our View Model to functions on Activity and Fragment.

We provide the function to create our View Model as a lambda that returns type <VM : ViewModel>, and the viewModelBuilder and activityViewModelBuilder extensions do the rest.

/**
 * Get a [ViewModel] in an [ComponentActivity].
 */
@MainThread
inline fun <reified VM : ViewModel> ComponentActivity.viewModelBuilder(
    noinline viewModelInitializer: () -> VM
): Lazy<VM> {
    return ViewModelLazy(
        viewModelClass = VM::class,
        storeProducer = { viewModelStore },
        factoryProducer = {
            return@ViewModelLazy object : ViewModelProvider.Factory {
                override fun <T : ViewModel?> create(modelClass: Class<T>): T {
                    @Suppress("UNCHECKED_CAST")// Casting T as ViewModel
                    return viewModelInitializer.invoke() as T
                }
            }
        }
    )
}

/**
 * Get a [ViewModel] in a [Fragment].
 */
@MainThread
inline fun <reified VM : ViewModel> Fragment.activityViewModelBuilder(
    noinline viewModelInitializer: () -> VM
): Lazy<VM> {
    return ViewModelLazy(
        viewModelClass = VM::class,
        storeProducer = { requireActivity().viewModelStore },
        factoryProducer = {
            object : ViewModelProvider.Factory {
                override fun <T : ViewModel?> create(modelClass: Class<T>): T {
                    @Suppress("UNCHECKED_CAST")// Casting T as ViewModel
                    return viewModelInitializer.invoke() as T
                }
            }
        }
    )
}

Now, in our Activity:

private val model: MyViewModel by viewModelBuilder {
    MyViewModel(repo = MyRepository())  
}

Or Fragment:

private val model: MyViewModel by activityViewModelBuilder {
    MyViewModel(repo = MyRepository())  
}

We can easily build a ViewModel, along with all it's necessary dependencies, all without the annoying boilerplate!

If you're in a situation where you need complex Android View Models, want to follow SOLID principles of dependency injection, and you're not quite ready to adopt the complexity of a full Dependency Injection Framework - hopefully this helps present some other options that can make the task easier to manage.

If you have thoughts on the Android View Model or want to share your approaches to manual DI, don't hesitate to reach out @ajkueterman on Twitter, or follow me on DEV.to and leave a comment on this story.

This story was originally published on my blog, at ajkueterman.dev

Hacker News Compose

A.J. Kueterman — Sun, 12 Jul 2020 19:41:14 +0000

I recently gave a talk and live code-along session that presented an introduction to Jetpack Compose. The talk was aimed at introducing developers of all levels to Jetpack Compose, so that we could learn how to build a starter Android app using this new UI technology. We started with an empty Android app, and ended with a fully-functioning Hacker News client that fetched top stories and let users save their favorite articles.

If you're interested in Jetpack Compose, and want to get started with a high-level intro and a straightforward example app, then check out my repo on GitHub - hn-compose. It includes the slides from my talk, as well as a multi-part code example that walks through the process of building out our Hacker News client.

Check it out, and feel free to reach out to me on Twitter @ajkueterman or leave a comment on my post in Hacker News.

Originally published at AJ.dev

Safely Launch Exception-Ready Coroutines

A.J. Kueterman — Wed, 11 Mar 2020 20:52:36 +0000

Launching suspend functions in Kotlin can be a complicated affair. Managing your CoroutineScope and making sure exceptions are handled properly can be confusing and easy to forget.

In Android, when using the ViewModel or Lifecycle specific scopes this gets much easier. We let the Android system provide a CoroutineScope and manage killing our coroutines when the lifecycle of those things end.

fun getObjectFromNetwork() {
  viewModelScope.launch {
    val response = networkRepository.getObject()
  }
}

However, there are cases when exceptions can be thrown from the CoroutineScope. A real life example I experienced recently was a SocketTimeoutException that was thrown from a Retrofit call I was making using a suspend function. The result is an Android app crash, which is definitely not desired when network calls can result in many different thrown exceptions.

The Kotlin CoroutineExceptionHandler can help us more easily handle exceptions thrown from our Coroutine scope, but it requires us to register the exception handler when we launch a new coroutine so we properly handle nested exceptions.

val coroutineExceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
  // handle thrown exceptions from coroutine scope
  throwable.printStackTrace()
}

fun getObjectFromNetwork() {
  viewModelScope.launch(coroutineExceptionHandler) {
    val response = networkRepository.getObject()
  }
}

Now, while the ViewModel is probably a logical place for handling exceptions in network calls, there are a lot of exceptions that are thrown irregularly from your app that aren't part of the logical flow of a network call. Using Retrofit as an example, most network calls should return a Response with a body() or errorBody() to handle instead of edge-cases where actual exceptions, like a SocketTimeoutException is thrown. It might be worth it to you to abstract this error handling away from your ViewModel to help minimize boiler plate.

To try this out, let's leverage the power of Kotlin extensions to create a safeLaunch method on CoroutineScope that can apply a default CoroutineExceptionHandler.

fun CoroutineScope.safeLaunch(launchBody: suspend () -> Unit): Job {
  val coroutineExceptionHandler = CoroutineExceptionHandler { 
  coroutineContext, throwable ->
    // handle thrown exceptions from coroutine scope
    throwable.printStackTrace()
  }

  return this.launch(coroutineExceptionHandler) { 
    launchBody.invoke() 
  }
}

Now, we can call safeLaunch on any CoroutineScope, like our viewModelScope, to launch a coroutine with this default error handling behavior.

fun getObjectFromNetwork() {
  viewModelScope.safeLaunch {
    val response = networkRepository.getObject()
  }
}

There you have it! A nicely-encapsulated method to launch suspend functions knowing that we won't see random app crashes because of an unhandled Throwable.

If we wanted safeLaunch to be the core CoroutineScope launch method in our app, we can even improve the extension a bit to allow users the flexibility of passing their own CoroutineExceptionHandler instead of using the default.

val coroutineExceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->   
  throwable.printStackTrace()
}

fun CoroutineScope.safeLaunch(
  exceptionHandler: CoroutineExceptionHandler = coroutineExceptionHandler,
  launchBody: suspend () -> Unit
): Job {  
  return this.launch(exceptionHandler) { 
    launchBody.invoke() 
  }
}

The same day I wrote this article, Manuel Vivo and Florina Muntenescu from the Android developer relations team released a really good series on coroutines, including the subject of coroutine exceptions. Check it out if you want to learn more about coroutines and how to manage them.

X-post from ajkueterman.dev

Dealing with Deprecation & iOS Headers

A.J. Kueterman — Wed, 05 Feb 2020 02:38:21 +0000

Recently, I started getting emails from GitHub letting me know that my GitHub OAuth app was accessing GitHub API's using a deprecated authentication method.

// Detect dark theme var iframe = document.getElementById('tweet-1224527769046077440-650'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1224527769046077440&theme=dark" }

My app, OctoNote, uses the GitHub gists API to store and manage notes as GitHub gists. I had originally set up OAuth for OctoNote using an access_token as a URL query parameter, which is no longer supported.

Instead, we need to add the token as an Authorization header on the request. Doing so in iOS is easy, just specify the value of the token and the name of the Header field (in this case Authorization) on your API call requests.

request.setValue("token \(token_val)", forHTTPHeaderField: "Authorization")

After doing this, your regular calls to the GitHub API's should still work as expected, but you should no longer get deprecation notices from GitHub! 🎉

Android Library Lessons Learned

A.J. Kueterman — Fri, 13 Dec 2019 16:00:04 +0000

Recently, I worked on an Android project where we wished to abstract away some Android resource files from the root application. Instead, we wanted our app - and any subsequent app - to consume Android resources (colors, strings, dimensions) from a library. In addition, because we wanted to define these resources independently of the apps consuming them, we needed to build our library separate from our main application.

After some effort, and some trials working with Gradle and Android dependencies, we were able to build our Android library for distribution to consuming apps. Let's take a minute and talk about what was required to accomplish this, and point out some pitfalls to help you build your first external Android library.

JAR/AAR

A bundle of Java/Kotlin source code without any Android dependencies can be packaged and consumed as a .jar file. This makes things simple and enables cross platform code that isn't dependent on Android.

However, we immediately realized we'd need access to Android stuff in our project. We need access to Android resources, which can only be accessed in an Android Library. Because of this, we know that we'll need to build an Android Archive (.aar) file.

An AAR file can't be tar or jar'd up easily from the command line. Because it's an Android Library ('com.android.library') it needs to be built using Gradle.

Gradle Dependencies

In our case, we were using a Node.js project to output our Android Library resources. This meant that we had a separate, non-Android app, building our eventual AAR output.

The first attempt at this used a packaged version of the Gradle wrapper from a dependency file on the machine, and attempted to package up a library from it's source code defined in the Node app. We quickly ran into issues here, because defining a Library build.gradle file without a parent build.gradle is something of an anti-pattern for an Android project structure.

Normally you have a 'project' build.gradle file at the root, then an application (usually 'app') module with it's own build.gradle file. Then, each module defined in the project would have it's own module build.gradle file. Trying to build a module without defining a parent 'project' build.gradle file isn't the norm - and was causing problems in our implementation.

Instead, what we ended up needing to do was build a shell Android app project with an included sub-module. The shell project defined the Android project structure at a high level, including our library sub-module structure, and was zipped up and packaged with our Node app. Then, as part of our Node app's build process, we would un-zip the Android project and update the sub-module directories to prepare our library. Finally, we would use the included Gradle wrapper in our Library container project to build our submodule.

Besides the clunky-ness of creating an entire Android application project just to build a module - this worked like a charm!

Android Dependencies

After fixing our project structure and defining the proper Gradle files, our app successfully built and packaged an AAR file. However, importing this file into an Android project didn't correctly link Android Resources.

What we soon learned was that including Android Resources is part of the Android AppCompat library. We updated our Android Library build.gradle file to include this dependency, and suddenly we had linked resources:

dependencies {
    ...
    implementation 'androidx.appcompat:appcompat:1.1.0'
}

It turns out that when library modules are packaged up their Android res directory is combined into one values.xml file, including colors, dimensions, etc. In addition, they are linked with the R.txt file generated in the build so they can be referenced by consuming applications. This resource linking using R.txt is done by the Android AppCompat lib.

[Update] Continuous Integration

Part of our project goals included building this library on a build server using Jenkins. One of the hard-learned lessons of this endeavor was that in using our 'container' Android project to build our AAR files on a build server isn't the same as doing Android Studio builds or even local command line builds.

Biggest takeaway was a stupid-simple misstep: make sure your build machine sets the right ANDROID_HOME directory!

Android for a Reason

In my research for solving this particular problem I came across a wide array of responses about sharing resources across multiple projects. Overall, the conclusions on Stack Overflow were pretty grim, with people mostly just explaining why shared Resources are hard in Android.

What I've learned is that packaging a bundle of resources to share across apps is very doable, you just have to respect the structure of a typical Android project and understand a bit about how AAR libraries are built. The more you know 🌟!

Intro to Client Side Git Hooks

A.J. Kueterman — Mon, 12 Aug 2019 15:20:09 +0000

Automation is everything when it comes to the process of deploying code. Even the smallest improvements over time can have a massive impact on the amount of manual processes you have to endure in building and shipping your software.

There are a lot of places to inject automation in the process of writing, building, and deploying code. When writing code on a team and on increasingly large projects those challenges and opportunities only grow. Things like linting, automated tests, and GitHub checks help you reduce toil when pushing, reviewing, merging, and delivering code.

There are many solutions to these problems, and most focus on the most clear gatekeeper when it comes to deploying code - the build step. Your build should be able to detect problems automatically without human intervention. Everything from code style to performance to server health can be tested and certified in a build before you ever push code to production. The build enforces your rules and keeps developers honest in a way manual intervention never will be able to.

However, there are checks that can save even more time when pushed forward into the pre-build process.

A good example is developers committing and pushing bad code. Not merging bad code, but just simply writing bad code and commiting it to source control in their own feature branches. This might not seem like a huge problem - after all protected branches mean you can enforce correctness with build checks before approving merges - but it can introduce manual effort and cause frustration for developers, both of which are things that could easily be avoided with client-side git protection.

Introducing Git Hooks

Git Hooks are a way to run scripts when certain Git commands are run. There are hooks on both client-side Git processes and server-side processes where you can react to changes in the Git workflow. We'll focus on the client-side hooks, where we can protect ourselves before we're even done with a commit.

Client-side Git Hooks

The client-side hooks include hooks for multiple Git processes including committing, email workflows, and other processes like checkout and merge. For now, let's focus on the commit workflow (but check out the rest of the list, there's a lot you can do!).

pre-commit - runs on git commit even before the commit message is generated
prepare-commit-msg - runs before the commit message editor opens but after the default message is generated
commit-msg - runs after message creation, to validate the temporary file containing the commit message

These client-side commit hooks really fall into two categories:

The code in your commit
Formatting/enforcing a proper commit message

We'll start with the first category, using pre-commit to analyze the code we're about to commit before we even consider completing the commit with a message.

Writing a Git `pre-commit` hook

First, you need to designate a location for your hooks in your repository. For our example, we're going to create a directory called .githooks in the root of our repository using these commands:

mkdir .githooks
cd .githooks
touch areYouSure.sh

Open up areYouSure.sh in your favorite editor. Writing a hook is both extremely simple and overwhelmingly open-ended. You just need a script that returns an exit code, 0 for success and non-0 for failure. Anything that isn't 0 aborts the commit altogether.

Let's write a very simple script that just asks our developer if they're sure they want to commit.

#!/usr/bin/env bash

# Check that we want to commit.

read -p "Are you sure you want to commit this (y/n)? " answer
case ${answer:0:1} in
    y|Y )
        exit 0 # If yes, success!
    ;;
    * )
        exit 1 # If no, sorry yo.
    ;;
esac

Finally, make sure you make this new file executable by running

chmod +x .githooks/areYouSure.sh

Now let's figure out how we can have Git actually run this script automatically as part of the pre-commit hook.

Add a custom `pre-commit` step

In our .githooks directory we'll create a new script to handle our custom pre-commit actions with these commands:

cd .githooks
touch pre-commit

Open the new pre-commit file in your favorite editor. Let's update it to do the basic things we need.

#!/bin/sh

# Specify the directory for the hooks.
# We'll use the current one (.githooks)
hookDir=$(dirname $0)

# Specify the hooks you want to run during
# the pre-commit process:
"$hookDir/areYouSure.sh"
# && "hookDir/add-your-own-scripts-here"

This script will specify the directory where we'll store our hooks (the current .githooks directory) and then it will specify the scripts that should run as part of pre-commit. In our example we just have the single areYouSure.sh script.

You could code your script code directly into pre-commit. We are instead abstracting this code into its own script to enhance readability, reusability, and to enable us to easily add more scripts to our pre-commit step in the future.

Finally, make sure you make this new file executable by running

chmod +x .githooks/pre-commit

Tell Git to use our custom hooks

After you've completed the steps above, you should have a new .githooks directory containing the pre-commit script and our new custom script areYouSure.sh. We can go ahead and commit these files to source control. If you do this now, you'll notice that you don't get our 'are you sure' popup in the command line.

The reason our hooks aren't run, is we still need to configure Git to let it know we have a new location for pre-commit for this repository. To do that, run this command in the root of your repo:

git config core.hooksPath .githooks

This tells Git to configure the hooks path for this repo to our custom .githooks directory. Now, whenever git runs the pre-commit step it will defer to our custom actions in our own pre-commit script.

Now, when you start a new git commit, you should see our areYouSure.sh prompt. A Yes answer should continue your commit (moving on to commit message steps) while a No answer should abort your commit.

Next Steps

Congrats! 🎉 You have successfully written and configured a custom pre-commit hook in your repository!

Now, you can continue to improve your pre-commit workflow by simply adding new scripts to .githooks and specifying which hooks you want to run in your custom pre-commit script.

A few resources to help continue your Git Hooks journey:

GitHooks.com
pre-commit - a framework for pulling custom pre-commit scripts from remote repos
Learn about server-side git hooks to enforce policy and some starter server-side scripts

Thanks for reading, if you have questions or thoughts on pre-commit hooks or want to share the awesome stuff you've done with git automation - let me know in the comments!

I originally published this post on AJ.dev, read it there.

Your First Android Libraries

A.J. Kueterman — Mon, 22 Jul 2019 17:37:04 +0000

When you start a brand new app in Android Studio, you're dropped into a bare-bones project that likely just has a single, empty Activity.

If you're trying to build out a project beyond "Hello World!", especially if you plan to follow some architectural best practices like using MVVM, you'll quickly run into some limitations with the basic Android libraries included in every project.

After creating a few basic starter applications, I thought I'd share what I think are the best "first step" dependencies to add to your Android project.

TL;DR - `app/build.gradle`

Before I go into more detail, here's the basic dependencies list I put together for my last starter app.

dependencies {

    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.3.31"
    implementation 'androidx.appcompat:appcompat:1.0.2'
    implementation 'androidx.core:core-ktx:1.0.2'
    implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
    // enable ViewModelProviders
    implementation "androidx.lifecycle:lifecycle-extensions:2.0.0"
    // enable TextInputLayout
    implementation 'com.google.android.material:material:1.0.0'

    testImplementation 'junit:junit:4.12'
    // enable Mocking with Mockito
    testImplementation 'org.mockito:mockito-core:2.19.0'
    // enable InstantTaskExecutorRule
    testImplementation 'androidx.arch.core:core-testing:2.0.1'

    androidTestImplementation 'androidx.test:runner:1.2.0'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
    // non-deprecated AndroidJUnit4
    androidTestImplementation 'androidx.test.ext:junit:1.1.1'

}

The lines I commented are the ones I added to what was included with the basic Android blank-Activity starter app in Android Studio 3.4.

Let's take a closer look at what these libraries are and why we need them.

Prod Code

The implementation keyword specifies dependencies in your actual, running, production code.

Lifecycle Extensions

Enable some handy extensions for Android Lifecycle components. Namely, the ability to use ViewModelProviders.

implementation "androidx.lifecycle:lifecycle-extensions:2.0.0"

Any Android project needs an architectural pattern to follow. Google recommends using MVVM with the Android ViewModel. ViewModelProviders enables you to quickly setup ViewModels in your Activities and Fragments in a Google-approved way.

Material

You can get by without many of the Material Design components, but it's easier to use them. They support some very useful UI elements that Android users are used to seeing.

implementation 'com.google.android.material:material:1.0.0'

For me, this library allowed me to use TextInputLayout for my text fields. This enables built in error fields, animated hints, and a Material-first design that I wanted in my app.

Unit Tests

Using testImplementation specifies dependencies for your Unit Tests. JUnit is included by default.

Mockito

The included ExampleUnitTest in any Android beginner project doesn't use Mockito to test. However, as projects grow, you'll quickly realize the benefits of a full-fledged mocking library.

testImplementation 'org.mockito:mockito-core:2.19.0'

Mockito enables you to use the MockitoJUnitRunner and to mock data and function calls in your test. It really helps to reduce boiler plate and focus on the right functionality in your unit tests.

Lifecycle Testing

If you're doing the right thing and following MVVM with the Android Architecture Components, then you'll probably want to test your ViewModels and LiveData.

testImplementation 'androidx.arch.core:core-testing:2.0.1'

The core-testing library enables you to test LiveData in your JUnit tests using the InstrumentationTestRegistry rule.

/**
 * Enables Architecture Components testing in JUnit tests.
 * (Include this at the top of your Unit Test class body.)
 */
@get:Rule
var task = InstantTaskExecutorRule()

UI Testing

The androidTestImplementation keyword refers to UI/Instrumentation test dependencies.

Android JUnit

While you don't need this to use AndroidJUnit4, this dependency includes the latest, non-deprecated version.

androidTestImplementation 'androidx.test.ext:junit:1.1.1'

What's next?

Hopefully this guide has helped you identify some foundational dependencies you'll need for almost any Android project.

It's impossible to be prescriptive about what dependencies you'll need to explore the infinite possibilities available to you in your next Android project. What's next is up to you.

This article is republished from my blog, AJ.dev - read it there.

Quick Guide to ASWebAuthenticationSession API Changes in iOS 13

A.J. Kueterman — Wed, 17 Jul 2019 21:34:13 +0000

One of the biggest announcements at WWDC 2019 was the new 'Sign In With Apple' feature, where Apple will now provide an authentication email & password to apps on behalf of you and manage them securely using the iCloud Keychain.

Apple continues to push these privacy-focused features especially around authentication to try to disrupt ubiquitous services like Facebook & Google OAuth that make login flows much easier for users - but at the cost of their data going into the hands of ad companies.

As such, a lot of focus has been given to the Authentication services in iOS. We saw it begin last year with the move from auth services inside SafariServices to the dedicated AuthenticationServices APIs. This year, iOS 13 leverages AuthenticationServices to enable the Sign In With Apple APIs, and continue to refine the sign in experience.

A Guide to Changes in `ASWebAuthenticationSession`

Last year, I talked a bit about OAuth in iOS in my post about Apple's move from SFAuthenticationSession to ASWebAuthenticationSession and how I went about converting my iOS app to use the new API. This year, the ASWebAuthenticationSession has some smaller tweaks to enhance the OAuth sign-in experience across iOS (including iPadOS) devices.

If you're a developer already sweating about the huge array of changes and opportunities coming for developers in 2019, don't fret about this one, it's a small tweak purely for enhancing OAuth experiences across devices.

To set the stage, let's look at a code snippet for ASWebAuthenticationSession in iOS 12.

//...
var webAuthSession: ASWebAuthenticationSession?
//...
@available(iOS 12.0, *)
func getAuthTokenWithWebLogin() {

    let authURL = URL(string: "https://github.com/login/oauth/authorize?client_id=<client_id>")
    let callbackUrlScheme = "octonotes://auth"

    self.webAuthSession = ASWebAuthenticationSession.init(url: authURL!, callbackURLScheme: callbackUrlScheme, completionHandler: { (callBack:URL?, error:Error?) in

        // handle auth response
        guard error == nil, let successURL = callBack else {
            return
        }

        let oauthToken = NSURLComponents(string: (successURL.absoluteString))?.queryItems?.filter({$0.name == "code"}).first

        // Do what you now that you've got the token, or use the callBack URL
        print(oauthToken ?? "No OAuth Token")
    })

    // Kick it off
    self.webAuthSession?.start()
}

In this example, the only thing we need to provide the ASWebAuthenticationSession is the authentication URL, a callback URL scheme, and a completion block that handles the result of the OAuth. The OS handles the rest - displaying an alert, launching a Web login flow, and dismissing.

In iOS 13, as Apple continues to refine the multi-app experience for iOS and iPadOS, we now need to help the OS out when it's making the decision on where and how to display the OAuth Alert and Web login flow.

To do that, we have to let the ASWebAuthenticationSession know which window is presenting the OAuth request. This is done by implementing the ASWebAuthenticationPresentationContextProviding interface in your presenting View Controller.

The presenting View Controller needs to implement the ASWebAuthenticationPresentationContextProviding interface and return the relevant window in the presentationAnchor method.

class LoginViewController: UIViewController, ASWebAuthenticationPresentationContextProviding {
    //...
    func presentationAnchor(for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
        return self.view.window ?? ASPresentationAnchor()
    }
    //...
}

Then, when setting up our auth session, we need to specify our presentationContextProvider delegate.

self.webAuthSession?.presentationContextProvider = context

The full updated method, now passing in a ASWebAuthenticationPresentationContextProviding context (our presenting VC that implements the ASWebAuthenticationPresentationContextProviding interface).

//...
var webAuthSession: ASWebAuthenticationSession?
//...
@available(iOS 13.0, *)
func getAuthTokenWithWebLogin(context: ASWebAuthenticationPresentationContextProviding) {

    let authURL = URL(string: "https://github.com/login/oauth/authorize?client_id=<client_id>")
    let callbackUrlScheme = "octonotes://auth"

    self.webAuthSession = ASWebAuthenticationSession.init(url: authURL!, callbackURLScheme: callbackUrlScheme, completionHandler: { (callBack:URL?, error:Error?) in

        // handle auth response
        guard error == nil, let successURL = callBack else {
            return
        }

        let oauthToken = NSURLComponents(string: (successURL.absoluteString))?.queryItems?.filter({$0.name == "code"}).first

        // Do what you now that you've got the token, or use the callBack URL
        print(oauthToken ?? "No OAuth Token")
    })

    // New in iOS 13
    self.webAuthSession?.presentationContextProvider = context

    // Kick it off
    self.webAuthSession?.start()
}

At this point, your ASWebAuthenticationSession now knows where and how to display your Web-based login flow, and will provide a consistent experience across devices!

Thoughts on OAuth

It has been an interesting experience tinkering with OAuth over the last two years. Right as I was learning the APIs Apple made a big move to new APIs, and this year it's clear how that change is enabling a better sign in experience for users.

Now, in iOS 13, by observing the specific change in this small API, we can see the evolution of iOS to a multi-window experience.

As I see this slow progression play out, I'm beginning to wonder about the future of OAuth in iOS at all. Will web authentication be blacklisted altogether in favor of Sign In With Apple? Will Apple centralize auth in a way that allows me to authenticate with GitHub without going to GitHub services for tokens? Only time will tell, but the changes today can project the changes in the future - stay alert!

If you have any thoughts/questions/predictions about OAuth and Web Authentication with iOS, don't hesitate to reach out to me on Twitter @ajkueterman.