Luis Ramos

How to share resources in KMM

Wed, 06 Jul 2022 00:00:00 GMT

Building a mobile application will sooner or later put you in a position of bundling resource files. In the Kotlin Multiplatform Mobile world, this is still somewhat of a problem. I have a JSON file with some data I want to bundle in iOS and Android and in this post I will show you of a way to do it with a bit of configuration and some helper code.

Resources folder

The multiplatform shared library already has a structure folder for resources, so I’ve placed the json file in the src/commonMain/resources folder.

The shared resources folder will not be added automatically to the Android library so add this to the shared android library build.gradle:

android {
    // ...
    sourceSets["main"].resources.setSrcDirs(
        listOf(
            "src/androidMain/resources",
            "src/commonMain/resources" // <-- add the commonMain Resources
        )
    )
}

Now the files in that folder will be bundled in the library and available in the Android app!

But what about iOS? Well, the solution I have is a bit awkward but it works! Add the src/commonMain/resources folder to the Xcode project. You can either drag it in, or right click where you want it and select "Add Files to...". Make sure to deselect "Copy items if needed", select "Create groups", and add them to the targets you need.

A drawback of this is that we will need to add new resource files manually in Xcode. We can’t use a reference folder since we need those files to be individually added in the “Copy Bundle Resources” step. But I think this is totally worth it, since in my experience we spend more time editing the existing resources than creating new ones.

If you have a lot of resources you need to add, maybe you could look into a Run Script step that does that work!

Now how do we access the resources at runtime?

Access the resources

To read the resources, create a ResourceReader class with actual implementations for iOS and Android:

 expect class ResourceReader {
    fun readResource(name: String): String
}

// Android resources are available via the class loader
actual class ResourceReader {
    actual fun readResource(name: String): String =
        javaClass.classLoader!!.getResourceAsStream(name).use { stream ->
            InputStreamReader(stream).use { reader ->
                reader.readText()
            }
        }
}

// Kotlin/Native resources will be in the Bundle!
actual class ResourceReader {
    private val bundle: NSBundle = NSBundle.bundleForClass(BundleMarker)

    actual fun readResource(name: String): String {
        val (filename, type) = when (val lastPeriodIndex = name.lastIndexOf('.')) {
            0 -> {
                null to name.drop(1)
            }
            in 1..Int.MAX_VALUE -> {
                name.take(lastPeriodIndex) to name.drop(lastPeriodIndex + 1)
            }
            else -> {
                name to null
            }
        }
        val path = bundle.pathForResource(filename, type) ?: error(
            "Couldn't get path of $name (parsed as: ${listOfNotNull(filename,type).joinToString(".")})"
        )

        return memScoped {
            val errorPtr = alloc<ObjCObjectVar<NSError?>>()

            NSString.stringWithContentsOfFile(
                path,
                encoding = NSUTF8StringEncoding,
                error = errorPtr.ptr
            ) ?: run {
                error("Couldn't load resource: $name. Error: ${errorPtr.value?.localizedDescription} - ${errorPtr.value}")
            }
        }
    }

    private class BundleMarker : NSObject() {
        companion object : NSObjectMeta()
    }
}

These implementations are from the DroidconKotlin repo, which I recommend you take a look at because it has a lot of cool solutions for common KMM problems.

Wrap up

To read the files, call ResourceReader().readResource("timezones.json") and you will get a string with the contents of the file.

With the resources always in the same folder (with the small caveat of having to manually add new files in Xcode) you will have an easier time managing them and making them work for you across both platforms.

While researching for this post, I found the moko-resources library but it is way to opinionated for my use case and it does much more than I needed. Also, if you are looking to share resources across multiplaform tests for your shared library this blog post by Victoria has a really nice solution that I used for my testing setup.

Hierarchy structure in KMM: Sharing platform code between iOS and MacOS

Mon, 13 Sep 2021 00:00:00 GMT

Recently I came across the hierarchy structure feature, a Kotlin Mobile Multiplatform setting that enables you to share platform specific code between similar platforms. In this post I will explain what this useful feature does and help you set it up.

As an example, lets take one of my recent KMM side projects. It has 3 target platforms: Android, iOS and MacOS. In it, I have the need to generate a UUID as an identifier in the shared code. This is something not available in Kotlin standard library, but available in each target platform.

There are libraries that provide this functional already, but it is something very simple to implement by ourselves using the expect/actual construct:

// commonMain/generateUUID.kt
expect fun generateUUID(): String

// androidMain
actual fun generateUUID(): String = UUID.randomUUID().toString()

// iosMain
actual fun generateUUID(): String = NSUUID().UUIDString

// macOSMain
actual fun generateUUID(): String = NSUUID().UUIDString

The Android implementation uses Java UUID class. The code for iOS and MacOS uses Foundation NSUUID class. The way the project is setup right now, we end up with a duplicate actual declaration for the NSUUID call.

This is exactly the type of problem the hierarchy structure feature solves. You can declare an intermediate source set that holds the shared platform code which the target platforms will depend on.

The documentation page explains how to enable support for this. You have to add the following option to gradle.properties:

kotlin.mpp.enableGranularSourceSetsMetadata=true

You can then use the target shortcuts the KMM plugin gives you or, in our case, you have to setup the targets manually. The shortcuts available don't actually cover our case of shared code between MacOS and iOS.

Here is the sources in build.gradle.kts for the shared module, named nativeMain. Note the creating {} call, instead of just getting():

kotlin {
    android()

    ios()
    macosX64("macos")

    cocoapods {
        summary = "Shared Framework"
        homepage = "Shared"
    }

    sourceSets {
        val commonMain by getting
        val androidMain by getting
        val iosMain by getting
        val macosMain by getting
        val nativeMain by creating {
            dependsOn(commonMain)
            iosMain.dependsOn(this)
            macosMain.dependsOn(this)
        }
    }
}

With this setup, our project is now using an hierarchy structure for our MacOS and iOS targets, and we no longer need to duplicate our actual declarations:

// generateUUID.kt
expect fun generateUUID(): String

// androidMain
actual fun generateUUID(): String = UUID.randomUUID().toString()

// nativeMain
actual fun generateUUID(): String = NSUUID().UUIDString

Hope this information helps with your KMM setup, it really helped me clean up some code duplication in my project.

Marrying KMM and Swift with Sourcery

Fri, 02 Jul 2021 00:00:00 GMT

My bet is that Kotlin Multiplatform Mobile is here to stay. It offers a great way to build mobile apps natively that share code, without compromising the best each platform has to offer. Of course, it comes with its own trade-offs.

Let me tell you how you can smooth out some of the quirks using the Swift meta-programming library Sourcery!

The problem: Kotlin extensions in Swift

The interoperability between Swift and Kotlin uses Objective-C as a medium, and it doesn't support Kotlin extensions has one would expect. An extension function like:

// file name is RocketExtensions.kt
fun Rocket.launch(): Boolean

Will translate into Swift like this:

class RocketKt {
	class func launch(_ receiver: Rocket): Bool
}

// How we expect to use it
rocket.launch()

// How we actually have to use it
let rocket = Rocket()
RocketExtensionsKt.launch(rocket)

The way Kotlin/Native generates the Objective-C header files for our extensions means they are accessible in Swift via a RocketExtensionsKt class. Note that the class matches the file name, not the class it is actually extending, which is a bummer. Nothing we can do for now in the Kotlin side, until pure Swift modules are supported.

The solution: Sourcery!

One library that you need to be aware if you are building iOS apps is Sourcery from @merowing_. The description says "Meta-programming for Swift, stop writing boilerplate code." and I am totally there for it.

I have only started to use it recently, but the flexibility you gain is truly incredible. How does this help with our extensions situation? Well, we can write a template that Sourcery can use to generate actual extensions in Swift, shadowing the extension classes from our shared framework.

If you are new to Sourcery, you can follow the installation guide to set it up, and I found this article by Paul Hudson to be a great introduction.

Speed bump

Sourcery only works with Swift files and a KMM project will generate extensions in a framework with Obj-C headers. So we need to make Sourcery aware of our shared framework code!

If you open up an Obj-C file in Xcode while you are in a Swift project, Xcode will show you a generated interface for the Obj-C file to help you out. We can actually use the Swift CLI to the same effect, and generate a Swift interface for our shared framework that can be feed into Sourcery.

Add a "Run Script Phase" to your Xcode target with this bit of code:

echo "import shared\n:type lookup shared" | \
	xcrun --sdk macosx swift -F../shared/build/cocoapods/framework/ | \
	tail -n+2 >| ./Sources/Shared/Shared.swift

Here is what the script does:

We echo to the Swift CLI that we want to do a type lookup of the shared framework. Replace shared with your shared code framework.
Use xcrun to call swift and generate the interface file. We also take care include a path to our framework in the framework search paths using the -F flag.
Save the output to a Swift file, somewhere where Sourcery can read it.

Make note of adding this step before the Sourcery step, otherwise Sourcery might only pick up new types on the second build. Also note the --sdk macosx flag. Running this inside Xcode will make `swift` default to whatever arch you are building, and if it is iOS it won't work.

Write the Stencil template

Now, we just need to write a template that makes use of our shared framework types to create the extensions we want. Here is what I came up with:

import shared

{% macro paramsWithoutSelf method %}{% for param in method.parameters %}{% if forloop.first %}{% else %}
		{{ param.argumentLabel }}: {{param.typeName}}{% if not forloop.last %},{% endif%}
	{% endif %}{% endfor %}{% endmacro %}
{% macro argsWithoutSelf method %}
	{% for param in method.parameters %}
		{% if forloop.first %}
			{% if param.argumentLabel %}{{ param.argumentLabel }}: {% endif %}self{% if forloop.length > 1%},{% endif %}
		{% else %}
			{{ param.argumentLabel }}: {{ param.name }}{% if not forloop.last %},{% endif%}
		{% endif %}
	{% endfor %}
{% endmacro %}
{% for type in types.all where type.name|contains:"Kt" %}
{% for method in type.methods %}
{% if method.parameters.count > 0 %}
{% set isObsolete %}{% for attr in method.attributes where attr|contains:"available"%}{{attr}}{% endfor %}{% endset %}
{% if not isObsolete %}
{% set extensionName %}{% if method.parameters.first.typeName|contains:"?" %}Optional where Wrapped == {{ method.parameters.first.typeName|replace:"?","" }}{% else %}{{ method.parameters.first.typeName }}{% endif %}{% endset %}
extension {{ extensionName }} {
	func {{ method.shortName }}({% call paramsWithoutSelf method %}) -> {{ method.returnTypeName }} {
		{{ type.name }}.{{ method.shortName }}(
		{% call argsWithoutSelf method %}
		)
	}
}

{% endif %}
{% endif %}
{% endfor %}
{% endfor %}

Sentcil is pretty hard to read for the uninitiated. But don't be intimidated, you can checkout the language overview to get a good grasp of what it can do, and refer to the Sourcery documentation to get an idea of what is available to you.

This template makes some safe assumptions regarding our shared types:

A Kotlin extension class name will always end with "Kt" in Swift
The first parameter of the Kotlin extension method is the class we want to extend
For the previous to work, we ignore methods without parameters, like init()
We can skip methods tagged with obsoleted

The other thing of note is that Optional types are extended correctly with a where clause, otherwise we would generate extension Rocket? {} which doesn't compile.

Using our previous Rocket extension as an example, here is what we end up with:

// Swift generate code
import shared

extension Rocket {
	func launch() -> Bool {
		RocketKt.launch(
			self
		)
	}
}

I am sure the template can be improved, but for now it covers all my extensions without issues and saves me from writing all this boilerplate.

The magic doesn't stop here...

Sourcery fits really well bridging the Kotlin to Swift gap. Its usage doesn't stop with the extensions! Another example of how I use it is with a shared theme configuration.

object Theme {
	val backgroundColor = 0xFFFF00FF
	val salmonColor = 0xFFFF0000
	val shadowColor = 0xFF00000
}

For iOS I wrote a template that creates an extension to SwiftUI.Color with the theme colors. Now every time you add a new color in the Theme object, you automatically get the extensions in Swift. We end up with a file like:

import SwiftUI
import shared

extension Color {
	var backgroundColor: Color {
		Theme().backgroundColor.toColor()
	}
	...
}

// Here is how you use it!
struct DotView: View {
	var body: some View {
		Circle()
			.fill(Color.backgroundColor)
	}
}

Here is the Stencil template:

import shared
import SwiftUI

{% for type in types.all where type.name == "Theme" %}
extension Color {
	{% for variable in type.variables %}
	static var {{ variable.name }}: Color {
		{{ type.name }}().{{ variable.name }}.toColor()
	}

	{% endfor %}
}
{% endfor %}

Conclusion

We made use of a Sourcery template to generate code that makes our Kotlin extensions actually extend the correct Swift classes. We also used the Swift CLI to generate an interface of our shared framework that Sourcery could read. And we set it up so it runs every time Xcode builds, so changes in the shared framework are automatically propagated to Swift.

Integrating Sourcery early into a KMM project pays off in the short and in the long run. With this setup, you avoid writing a lot of boilerplate code and bridge the gap between Kotlin and Swift a bit better. Best part is that you can keep adding templates to fit your usage and make it easy to keep switching contexts.

Hope you enjoyed this post and that it makes your life a little bit easier in the KMM world.

Xcode Format and Save using SwiftFormat and Automator

Tue, 29 Jun 2021 00:00:00 GMT

Lost are the days where we could modify and extend Xcode to do our bidding (RIP Alcatraz). We have some room to work with source editor extensions, but adding a macro that formats our Swift code and then saves the file is out of reach. Or is it?

Via a weird combination of the SwiftFormat source editor extension, Automator, and Keyboard shortcuts I can now format and save my file by pressing the blessed Cmd+S shortcut.

Here is how it works:

Step 1: setup SwiftFormat

If you use brew like me, run these commands to install SwiftFormat. Otherwise, check their Github page for installation instructions.

brew install swiftformat
brew install --cask swiftformat-for-xcode
open "/Applications/SwiftFormat For Xcode.app"

Last command will open the "SwiftFormat For Xcode" app, so it can install the source editor extension. Don't forget to also restart Xcode.

This extension will place a menu item that formats our file, under "Editor" > "SwiftFormat" > "Format File". This is important for our next step!

Step 2: automate with Automator

Open up the lovely Automator, and create a Quick Action.

Next add a "Run AppleScript" action, and paste in the following code:

on run {input, parameters}
	tell application "System Events"
		tell process "Xcode"
			set frontmost to true
			if menu item "Format File" of menu of menu item "SwiftFormat" of menu "Editor" of menu bar 1 exists then
				click menu item "Format File" of menu of menu item "SwiftFormat" of menu "Editor" of menu bar 1
			end if
			click menu item "Save" of menu "File" of menu bar 1
		end tell
	end tell
	return input
end run

The script will do the following:

Check to see if "SwiftFormat" > "Format File" menu item exists in Xcode
If it does exist then click "Format File", otherwise do nothing
Click "Save"

Here is how the Quick Action looks. I've changed the "Workflow receives" to "no input" and "in" to "Xcode".

Save the Quick Action. Automator will place it directly into a macOS "Services" folder, and that will make it available in the "Xcode" > "Services" menu.

This action requires access to "Accessibility" permissions. If you try to run it via Automator you will probably get a permission related error. We will address this further down the post!

And there you go! A Format and Save macro. Now the last step:

Step 3: Add a Keyboard shortcut

Go to "System Preferences" > "Keyboard" and pick the "Shortcuts" tab. On the sidebar, select "App Shortcuts". Add a new shortcut, the "Application" is XCode, the "Menu Title" is the name of our Quick Action (in my case XcodeFormatAndSave), and the "Keyboard Shortcut" is Cmd+S!

And there you go! If you go to Xcode and try to save a Swift file, it will run SwiftFormat before it saves.

Actually, it will probably throw an error. This action needs "Accessibility" permissions, so you will need to navigate to "System Preferences" > "Security & Privacy" and give permission to Xcode.

Now you can let Xcode take care of the formatting. You are welcome!

A year of Ler

Mon, 26 Apr 2021 00:00:00 GMT

A year ago, I published Ler - a feed aggregator app for Android. After releasing it, my plan was to clean the code to open source it, and write posts about its architecture and how I code. Almost none of that happened but version 1.1 is out!

Recap

Not much writing happened in regards to the app, but I kept working on it. Not often, but enough to rewrite a lot of the old implementation.

I replaced the usage of Fragment with a custom Screens navigation implementation. Because, why not? Also, I ditched the XML layouts in favor of using regular Android views. Big props to Contour, a layout view for Android by CashApp, it really helped with that.

I use this app as a test bed for new frameworks and libraries. These changes didn't add anything to the feature set, but they felt really good! And I learned how to build an app without relying on fragments.

One thing I am still learning is how to cut scope so I can finish something. I had to give up on the idea of "cleaning up" the code base. By that I mean adding missing tests and restructure the files to make more sense to some other dev. I realized that I would not be able to muster the energy to do it, so the project is now open source for everyone to check out.

Version 1.1 is out!

After a year, the new release of Ler comes with a new feature and a couple of fixes. You can download it here, or check for an update if you are already a user.

Changes since 1.0.2:

New posts notification! You will now be notified when there are new posts for you to read
New settings screen, where you can configure the new posts notification time (or disable it)
You can now disable the subscriptions background refresh
Fixed update URL for a subscription not getting parsed correctly
Fixed post published date parsing, now uses the device locale (and it actually works)

Ding, there are new posts!

I have the notification set so it triggers about the time I wake up, that way I don't miss any new posts. It really helps me stay on top of things, and I can read posts while eating breakfast ;) You can set this to trigger at any time of day.

The rate subscriptions refresh data changed as well, it was overly eager before and now I have set it to refresh every 12 hours. You can disable the refresh in the settings.

Happy reading!

I hope you like the new notification, it was surprisingly complicated to build. I almost gave up on it. A year ago I would have parked the idea before completion. But something I learned this year is how to keep at it, instead of waiting for the right motivation to come around.

Mint: A language for Single Page Applications

Fri, 09 Apr 2021 00:00:00 GMT

Android and iOS are my tech stacks of choice, both for work and pleasure, but I often keep tabs on what's going on on the web.

This post is about Mint, a domain specific type-safe language created to build single page web applications. It has all the necessary utilities that a SPA will use bundled in the framework: components, stores, router, and more! And it makes them part of the language, with specific keywords.

Here is how you declare a component:

component Main {
  style button {
    background: red;
    color: white;
    border: 0;
  }

  fun render : Html {
    <button::button>
      "Click ME!"
    </button>
  }
}

There is a styles keyword that allows you to use CSS to style your components, and it will all be sandboxed properly per component.

The syntax is similar to React, and the way it actually works underneath the hood is by offering React as a platform! It has a compiler and the build system will let you know of any errors you might have in your code. You are completely removed from the implementations specifics, and can focus on building your website.

Here is how you could declare a store and use it in a component, from Mint documentation:

// This is our store. You can have multiple stores per app
store Counter {
  state count : Number = 0

  fun setCount (count : Number) : Promise(Never, Void) {
    next { count = count }
  }
}

component Main {
  // Connecting the store to the component
  connect Counter exposing { count, setCount }

  fun handleClick (event : Html.Event) : Promise(Never, Void) {
    setCount(count + 1)
  }

  fun handleContextMenu (event : Html.Event) : Promise(Never, Void) {
    setCount(0)
  }

  fun render : Html {
    <div
      onContextMenu={handleContextMenu}
      onClick={handleClick}>

      <{ "Count: " + Number.toString(count) }>

    </div>
  }
}

Really like how easy to ready everything is. There is a lot more to it, and I strongly suggest you read through its learning guide/documentation.

Double edged sword

I really enjoy the power of this abstraction. But like all software it comes as a trade-off. By abstracting away the platform, it cuts us off from the ever expanding JavaScript ecosystem.

It's package system only allows for packages with Mint code in them. There is no way to use an existing JavaScript library in Mint, without wrapping it.

Mint has JavaScript interoperability, allowing you to declare standard JavaScript in your Mint code by surrounding it with backticks:

fun handleClick (event : Html.Event) : Void {
  `alert("Hello")`
}

But this interoperability only exists at the code level. There is no build step hooks, so an existing JavaScript library would need to be backticked and probably exposed as a module to be available in Mint world.

Let's say if you want to integrate TailwindCSS into your Mint SPA. Tailwind hooks into your build preprocessor step, in fact it assumes you will have one. Without access to a preprocessor hook, the only option is to generate all Tailwind CSS and include it in the head, like Mint's docs suggest.

We could have our own script that parses the Mint files, looking for CSS classes, and then feed that to TailwindCSS. And then hook this with a file watcher. But at this point, you would have to run npm install && mint install to start up the project, which means you are back into regular JavaScript land. Is this effort worth it? What if we want to use a date parsing library, or a JavaScript form library...

Still try it out!

Mint wants to do everything for you in the name of developer experience, but it cuts us away from web-dev JavaScript tools and environment. Enabling a strong developer ecosystem is what makes JavaScript one of the most popular environments to work in, and I think Mint should enable that if it wants to keep growing.

Nevertheless, if you keep to its boundaries, building a SPA with Mint is a breeze!

Testing your Android ViewModel - with examples

Fri, 19 Mar 2021 00:00:00 GMT

An android application can get really complicated, so in this post I will give some examples on how I write and test ViewModels.

These days my usual tech stack makes use of androidx.lifecycle classes with Kotlin extensions and coroutines. Setting up unit tests for all this just takes a couple of JUnit rules!

Let's start by imagining a fantasy app where you can buy cyber implants.

Start small

This is a view model for a listings screen that shows all available implants:

interface Api {
	fun getCyberImplants(block:()->List<CyberImplant>)
}

class CyberImplantListViewModel(val api: Api): ViewModel() {

	val data = MutableLiveData<List<CyberImplant>>()

	fun loadData() {
		api.getCyberImplants { list ->
			data.value = list
		}
	}
}

Every time loadData() is called we load some data from a backend and we update the live data object in the callback. Here is the unit test for it:

class CyberImplantListViewModelTests {

	@get:Rule
	val instantTaskRule = InstantTaskExecutorRule()

	val api = FakeApi() // FakeApi with canned responses
	val viewModel = CyberImplantListViewModel(api)

	@Test
	fun `when loadData() is called, should load data`() {
		viewModel.loadData()
		assertThat(viewModel.data.value, `is`(api.mockImplantsList))
	}
}

We use InstantTaskExecutorRule so we can make sure our LiveData objects don't call the android main thread. Our view model logic is simple, the test mirrors that: we just need to verify if the live data value property matches what we expect.

Start small + Coroutines

Let me refactor CyberImplantListViewModel, to make use of the lovely Kotlin coroutines (with androidx.lifecycle:lifecycle-viewmodel-ktx extensions):

// Coroutines ❤️
interface Api {
	suspend fun getCyberImplants(): List<CyberImplant>
}

class CyberImplantListViewModel(val api: Api): ViewModel() {

	val data = MutableLiveData<List<CyberImplant>>()

	fun loadData() {
		viewModelScope.launch {
			data.value = api.getCyberImplants()
		}
	}
}

The tests will remain the same, except you now need to add a rule to change the coroutines dispatcher to TestDispatcher. You can use this rule! We don't control the ViewModel.viewModelScope extension, so the rule is the only way to make sure we can set up the correct dispatcher to run the coroutines.

In this case, the Api call is responsible for changing the context to the correct one for a background task.

Always make it so that every suspend method is safe to call on the main thread, since it simplifies the code a lot.

class CyberImplantListViewModelTests {

	@get:Rule
	val instantTaskRule = InstantTaskExecutorRule()

	// Make sure viewModelScope uses a test dispatcher
	@get:Rule
	val coroutinesDispatcherRule = CoroutineDispatcherRule()

	val api = FakeApi()
	val viewModel = CyberImplantListViewModel(api)

	@Test
	fun `when loadData() is called, should load data`() = runBlockingTest {
		viewModel.loadData()
		assertThat(data.value, `is`(api.mockImplantsList))
	}
}

We have a ViewModel, using LiveData and Kotlin coroutines, with unit tests to cover all of it. Nice job.

Add error handling!

Turns out this implementation only covers the happy path, so let's keep going and add some error handling. I really like Kotlin sealed classes to help us out with this.

// Wrap our API results so we can avoid using try/catch in the ViewModel
sealed class Result<out T> {
	data class Error<T>(val message: String): Result<T>()
	data class Success<T>(val data: T): Result<T>()
}

interface Api {
	suspend fun getCyberImplants(): Result<List<CyberImplant>>
}

class CyberImplantListViewModel(val api: Api): ViewModel() {

	val uiState = MutableLiveData<UiState>(Loading)

	fun loadData() {
		viewModelScope.launch {
			uiState.value = Loading
			val result = api.getCyberImplants()
			uiState.value = when(result) {
				is Result.Error -> Error(result.message)
				is Result.Success -> Success(result.data)
			}
		}
	}

	// Magical 🧙‍♀️
	sealed class UiState {
		object Loading: UiState
		data class Error(val message: String): UiState
		data class Success(val implants:List<CyberImplant>): UiState
	}
}

Now our logic not only handles any errors the API throws, but can also show a progress bar to the user while the loading operation happens.

Lets write some tests:

class CyberImplantListViewModelTests {

	@get:Rule
	val instantTaskRule = InstantTaskExecutorRule()

	@get:Rule
	val coroutinesDispatcherRule = CoroutineDispatcherRule()

	val api = FakeApi()
	val viewModel = CyberImplantListViewModel(api)

	@Test
	fun `given api success, when loadData() is called, should show implants`() = runBlockingTest {
		api.prepareSuccess()

		val expected = listOf(
			UiState.Loading,
			UiState.Success(api.mockImplantsList)
		)
		assertThat(uiStates, `is`(expected))
	}

	@Test
	fun `given api error, when loadData() is called, should show error`() = runBlockingTest {
		api.prepareError()

		val expected = listOf(
			UiState.Loading,
			UiState.Error("test error")
		)
		assertThat(uiStates, `is`(expected))
	}
}

I really like how, with data classes, you can declared an expected array of states and the assertThat() will give you a really good error message if the test fails. Really cleans up the test code.

Keep it flexible

To keep our UI flexible, we shouldn't be relying on the models coming from the Api. By adding models just for UI and mapping functions, if the underlying data changes, for example, a name property becomes two firstName and lastName properties, we just need to update our mapping of the data.

class CyberImplantListViewModel(val api: Api): ViewModel() {

	val uiState = MutableLiveData<UiState>(Loading)

	fun loadData() {
		viewModelScope.launch {
			uiState.value = Loading
			val result = api.getCyberImplants()
			uiState.value = when(result) {
				is Result.Error -> Error(result.message)
				is Result.Success -> Success(result.data.toUiModel())
			}
		}
	}

	sealed class UiState {
		object Loading: UiState
		data class Error(val message: String): UiState
		data class Success(val implants:List<ImplantUiModel>): UiState
	}
}

data class ImplantUiModel(
	val id: Int,
	val title: String,
	val value: String
)

fun CyberImplant.toUiModel() = ImplantUiModel(
	id = id,
	title = title,
	value = formattedValue
)

fun List<CyberImplant>.toUiModel() = map { it.toUiModel() }

Looks exactly the same as before, but we future proof our ViewModel some.

Now, we just need to update the tests for the mapping logic:

class CyberImplantListViewModelTests {

	@get:Rule
	val instantTaskRule = InstantTaskExecutorRule()

	@get:Rule
	val coroutinesDispatcherRule = CoroutineDispatcherRule()

	val api = FakeApi()
	val viewModel = CyberImplantListViewModel(api)

	@Test
	fun `given api success, when loadData() is called, should show implants`() = runBlockingTest {
		api.prepareSuccess()

		val expected = listOf(
			UiState.Loading,
			UiState.Success(api.mockImplantsList.toUiModel()) // <== UPDATE
		)
		assertThat(uiStates, `is`(expected))
	}

	@Test
	fun `given api error, when loadData() is called, should show error`() = runBlockingTest {
		api.prepareError()

		val expected = listOf(
			UiState.Loading,
			UiState.Error("test error")
		)
		assertThat(uiStates, `is`(expected))
	}
}

Here is are the tests for the mapping function:

class ImplantUiModelTests {

	@Test
	fun `api model to ui model should map correctly`() {
		val apiModel = StubCyberImplant()
		val expected = ImplantUiModel(
			id = "test_id",
			title = "test_title",
			value = "formatted_value"
		)
		assertThat(apiModel.toUiModel(), `is`(expected))
	}
}

Make it wait

What if we only want to show the loading state if the API request takes longer than a certain amount of time? Let's say 200ms. With Kotlin coroutines, this isn't hard to implement and not hard at all to test!

fun loadData() {
	viewModelScope.launch {
		val loadingJob = launch {
			delay(LOADING_SHOW_DELAY) // delay for 200ms
			uiState.value = Loading
		}

		val result = api.getCyberImplants()
		uiState.value = when(result) {
			is Result.Error -> Error(result.message)
			is Result.Success -> Success(result.data.toUiModel())
		}
		loadingJob.cancel()
	}
}

When loadData() is called, instead of setting the state to Loading immediately, we launch a coroutine that will wait for the required amount of time and only after the Loading state will be updated. We save the Job the loading coroutine returns, and cancel it after the api request is done.

If the API takes less than 200ms to return, loadingJob.cancel() will be called and cancel that coroutine execution. If it takes longer, then the delay() suspension expires, and the state is set to loading. Pretty cool!

Now what about the tests?

class FakeApi(val requestDelay: Int): Api {
	var mockImplantsList: List<CyberImplant> = ...
	override suspend fun getCyberImplants(): Result<List<CyberImplant>> {
		delay(requestDelay)
		return mockImplantsList
	}

)

class CyberImplantListViewModelTests {

	// Let's say that the default delay is half a second
	// so the existing tests still pass
	val api = FakeApi(requestDelay = 500)
	val viewModel = CyberImplantListViewModel(api)

	// ...

	@Test
	fun `given a very fast api, when loadData() is called, should not post loading state`()  = runBlockingTest {
		api.requestDelay = 0

		viewModel.loadData()

		val expected = listOf(
			UiState.Success(api.mockImplantsList.toUiModel()) // only sucess state
		)
		assertThat(uiStates, `is`(expected))
	}
}

The runBlockingTest is really doing all the heavy work. We are unit testing time passing but the tests run instantly! From the documentation for runBlockingTest():

This is similar to runBlocking but it will immediately progress past delays and into launch and async blocks. You can use this to write tests that execute in the presence of calls to delay without causing your test to take extra time.

You could also use delay() to debounce user clicks, or make sure you refresh data after a certain amount of time. And all of that can be tested instantly.

TAP TAP TAP

To wrap up this list, let's implement a way for our users to select a implant and navigate to a detail screen. I tend to keep most of the logic in the ViewModel (easy to test), so lets have a Navigation interface with all the navigation calls.

class CyberImplantListViewModel(
	val api: Api,
	val navigation: Navigation
): ViewModel() {

	val uiState = MutableLiveData<UiState>(Loading)

	// ...

	fun onItemTapped(position: Int) {
		val state = uiState.value as? UiState.Success	?: return
		// find the correct item
		val item = state.data.getOrNull(position)
		item?.let { navigation.goToImplantDetail(it.id) }
	}
}

Our current adapter implementation calls viewModel.onItemTapped() when an item is clicked, passing the clicked position as an argument. Our tests look like this:

class FakeNavigation() {
	var didCallGoToImplantDetail = false
	var goToImplantDetailId = -1
	fun goToImplantDetail(id: Int) {
			didCallGoToImplantDetail = true
			goToImplantDetailId = id
	}
}

class CyberImplantListViewModelTests {

	val api = FakeApi(requestDelay = 500)
	val navigation = FakeNavigation()
	val viewModel = CyberImplantListViewModel(api, navigation)

	// ...

	@Test
	fun `when user taps an item, it should navigate to detail`() = runBlockingTest {
		// tapping before the data is loaded shouldn't do anything
		viewModel.onItemTapped(0)
		assertThat(navigation.didCallGoToImplantDetail, `is`(false))

		// load some data
		viewModel.loadData()

		viewModel.onItemTapped(0)
		assertThat(navigation.didCallGoToImplantDetail, `is`(true))
		val expectedId = api.mockImplantsList.first().id
		assertThat(navigation.goToImplantDetailId, `is`(expectedId))
	}
}

Wrapping up

We started with a pretty basic view model for showing a list of cybernetic implants to the user, and the respective test coverage. We then added coroutines, some logic to handle a loading state, and possible API errors. Then we wrapped it up with a "navigate to detail" example.

Hope these examples where useful to you in some way. I really enjoy writing this, so if you want to see more examples or just want to chat about android, reach out!

Love thy ViewModel

Fri, 29 Jan 2021 00:00:00 GMT

Long gone are the days when android developers had to spend lots of time dealing with activity lifecycles when building their apps. Well, maybe not so long ago! Now there are a lot more tools to make our jobs easier, like the google provided androidx.lifecycle package.

Let's talk about ViewModels, why they are a good tool, and how to use it properly.

What makes them great is that you can take view state that used to be held by an activity (or fragment) and give it to this ViewModel. This state will now survive configuration changes without being leaked.

Add LiveData to the mix and you strike gold:

class ProfileViewModel: ViewModel() {

	val username = MutableLiveData("John Silverhand")

	val cyberhacks = MutableLiveData<List<CyberHack>>()
}

class ProfileActivity: Activity() {

	override fun onCreate(savedInstanceState: Bundle?) {
		super.onCreate(savedInstanceState)
		setContentView(R.layout.profile_activity_layout);

 		val viewModel = ViewModelProvider(this).get(UserModel::class.java)
 		viewModel.username.observe(this) {
 			textView.text = it
 		}
 		// ...
	}
}

The ViewModel is provided to us bound to the activity lifecycle. The LiveData objects will hold the latest data set. The activity will observe both of these LiveData objects when created, always getting the latest data available. Life is good!

With this, we can establish a one way flow of data, from the ViewModel to the activity and its views. This makes unit testing the ViewModel very easy.

Mistakes were made

Now, here is an example of something you should not do with ViewModels:

class ProfileViewModel: ViewModel() {

	lateinit var recyclerView: RecyclerView

	fun setView(view: View) {
		view.textView = "John Silverhand"
		recyclerView = view.recyclerView
	}

	fun loadData() {
		Repository.loadCyberHacks { hacks ->
			recyclerView.adapter.items = hacks
		}
	}
}

In this case, the view and its implementation details are inside the ViewModel. Surviving configuration changes now works against us, since holding a reference to a view will leak it after the activity gets rid of it.

This will also complicate testing. The dependency on the android framework means we will need to write instrumentation tests, which are slow, harder to write, and not run as often as unit tests.

ViewModelProvider is King

The ViewModel class is very simple in its implementation. Take a peek here! It almost has more comments than actual code.

Just because of it's simplicity, we should not be tricked into using it everywhere. The usage of ViewModels in an application implies the use of ViewModelProvider to create them.

class ProfileViewModel: ViewModel() {
	fun reloadData() {
		Repository.loadCyberHacks { hacks ->
			hacks.map { CyberHackViewModel(hack) }
		}
	}
}

class CyberHackViewModel(hack: CyberHack): ViewModel() {
	val title = "${hack.name} - ${$hack.expirationDate}"
}

In the previous snippet, there is no benefit in using a ViewModel for this mapping. A data class fits this situation much better.

Whenever you see yourself creating a ViewModel using its constructor instead of a ViewModelProvider, stop! The only exception to this is, of course, writing unit tests.

Read the manual before driving

Always a good idea to read the documentation for a class before you start using it in your code. Pulled from the ViewModel javadoc:

Thee purpose of the ViewModel is to acquire and keep the information that is necessary for an Activity or a Fragment. The Activity or the Fragment should be able to observe changes in the ViewModel. ViewModels usually expose this information via LiveData or Android Data Binding. You can also use any Observer pattern from you favorite framework.

ViewModel's only responsibility is to manage the data for the UI. It should never access your view hierarchy or hold a reference back to the Activity or the Fragment.

Hope this post helped! I leave you with two classes to help writing unit tests for ViewModels if you use LiveData objects. The InstantTaskExecutorRule will override the ArchTaskExecutor used by the LiveData to dispatch notifications:

class InstantTaskExecutorRule : TestWatcher() {
    override fun starting(description: Description?) {
        super.starting(description)
        ArchTaskExecutor.getInstance().setDelegate(object : TaskExecutor() {
            override fun executeOnDiskIO(runnable: Runnable) {
                runnable.run()
            }

            override fun postToMainThread(runnable: Runnable) {
                runnable.run()
            }

            override fun isMainThread(): Boolean = true
        })
    }

    override fun finished(description: Description?) {
        super.finished(description)
        ArchTaskExecutor.getInstance().setDelegate(null)
    }
}

If you use coroutines with viewModelScope, this CoroutineDispatcherRule will also be useful. It sets up the main coroutine dispatcher to be a TestCoroutineDispatcher:

class CoroutineDispatcherRule(
    private val testDispatcher: TestCoroutineDispatcher = TestCoroutineDispatcher()
) : TestWatcher() {
    override fun starting(description: Description?) {
        super.starting(description)
        Dispatchers.setMain(testDispatcher)
    }

    override fun finished(description: Description?) {
        super.finished(description)
        Dispatchers.resetMain()
        testDispatcher.cleanupTestCoroutines()
    }
}

Publishing your first android library!

Tue, 15 Sep 2020 00:00:00 GMT

Publishing a library you develop is a journey on its own. It can be overwhelming, especially if you are targeting Android. There is a lot of documentation out here, but I could not find one that would go end to end with it. So I wrote this post!

This came about because I released my first open source library: Kroclin! It is a snapshot testing library written in Kotlin, to help out writing less code in your tests. Check it out and give it a star if would like. Now, let me tell you about the journey to release it!

Sonatype provides a guide for OSS repository hosting and another one for releasing your deployment that I read, but they could be more helpful. Everything you need to know is there, it just takes several readings and lots of googling to grok it. Here are the steps you need to go through:

First, create a Sonatype JIRA account if you don't have one already.

Then create a new project issue. Make sure to click this link, since they require that you use the template. In the issue body, write that you want to claim the domain that matches the library groupId. In the case of my library, the groupId is dev.luisramos.kroclin and I claimed dev.luisramos.*. Here is my JIRA ticket as an example.

I picked up from reading other issues that you only need to go through this process once, if you request a wildcard `groupId`. Other libraries released under the same `groupId` don't require a new project ticket to be created.

Note that you could also claim the groupId that matches your project hosting, for example, io.github.orgmir if that's where your project lives.

After you have opened a new project ticket, you need to prove that you own the domain you claimed. You can either:

Add a TXT record to your DNS referencing the url to the JIRA ticket you created (fastest)
Setup a redirect to your GitHub page

I went with the first option, and since every DNS provider differs I won't go into specifics. Some googling on how to add a TXT record for your DNS provider should get you there.

NOTE: You will need to submit the full URL for the issue, so in my case the content for the TXT record was https://issues.sonatype.org/browse/OSSRH-60527.

I went ahead and added a comment on the ticket with the output of dig -t TXT luisramos.dev, just to show that it was working. Don't know if it made a difference 😅

After doing the proof of domain ownership, you will need to wait for Sonatype to reply to your ticket. They will let you know once the repository on their end is ready to receive artifacts. Don't actually upload anything until they give you the OK, your artifacts will just end up in a generic catch-all repository.

After they reply, go ahead and upload your first artifact. You can copy my gradle-mvn-push.gradle script and run ./gradlew clean build uploadArchives (don't worry, I also copied it from someone else). You could also use a plugin like vanniktech/gradle-maven-publish-plugin.

Once the upload is done, go ahead and log in to https://oss.sonatype.org using your Sonatype JIRA account.

Select Staging Repositories on the side bar, and you should see a list with the repository for your library. Select the repository, and press Close on the top bar. This will perform some validation on Sonatype's side, and once the status updates and the repository is tagged as closed, select the repository again and press Release.

If you use a plugin, the upload step will probably try to close and release the staging repository. Logging in to Nexus Repository Manager should only be needed when you are releasing for the first time, or if you use a script like me.

You can now update on your JIRA ticket that the repository has been released. This will let Sonatype know, and they will trigger a sync with maven central, so your library can show when searching in search.maven.org. This step should is also only needed the first time you are releasing.

And that's it! It might take a couple of hours for the sync to happen, but congratulations! You have released a library onto the world! What a trip it was 🚀

Ler - An RSS Aggregator for Android!

Fri, 20 Mar 2020 00:00:00 GMT

I have been working on a RSS aggregator app called Ler. Its available for Android, and you should give it a try! It is the first app I design, develop and publish all by myself, so I am pretty proud of that!

I know what you are thinking, another RSS feed app? Aren't there billions of them? Well, yes. But this one is mine. And I have plans. Big plans! Let me tell you how it came to be, and what I want to do with it.

Twitter is a time sink

I spend too much time on twitter. I checked my phone usage settings for apps, and twitter is always number one on the list, toppling YouTube (!!) and WhatsApp. I though I watched a lot of YouTube, but apparently, on a very boring day, I accumulated 4 hours of twitter usage...

So I looked into Googles digital well-being app, and turned on a 30 minute timeout for Twitter. And it works! Some days, I don't even reach the timeout. Unfortunately, this also meant that a lot of the blogs I read wouldn't reach me as well.

And there you have it. I took the time I was wasting and built this app!

Ler

The app name is the portuguese word for reading. I did a search and it seems nobody claimed it, so why not? The main features that I have built so far:

You can subscribe to RSS feeds (crazy I know). You can manually type in a website address, or you can share from the browser to the app!
You can filter out articles that you already read, or just show articles from one feed.
You can swipe an article to toggle it read, or mark all articles in a feed at once!
Feeds will be checked for updates every hour auto-magically.

Articles currently open in the browser. I toyed with the idea of having a built in reader, but that seemed overkill for what I wanted to do. I already used the browser to do most of my reading anyway.

I am pretty proud of how it turned out, despite not being great at UI design, I kept it simple and it does the job! I have been using it for the past couple of weeks, and I think I impressed myself by actually using it instead of defaulting to Twitter as a time killer.

Open so everyone can read it

Not only am I using this app to avoid using twitter all the time, I will also use it as a showcase project. Hence, my plan in the next weeks is to write a bunch of tests, clean up the folder structure, and open source it.

So far, I have not worked in an app that had their source open, so most often when talking about my work I can't provide examples. I applied all my knowledge and tried to build the simplest app I could, while still being a good example of how I would build an app.

My plan is to also write about android development, while using the app as an example. I made some architecture choices that I can talk about, since I haven't found a lot of written examples online.

Please give it a spin, and let me know what you think! You can tweet at me or send me an [email](mailto:luis.ramos@hey.com?subject=Ler Feedback). I have a little roadmap with more features, but let me know if you want a particular feature added, and I will add it to the list!

My new blog! - Creating a Gatsby website

Tue, 17 Mar 2020 00:00:00 GMT

Welcome to my new blog! Hope you enjoy it, I have spent the last couple of weeks building it. Now that it is done, I can finally start writing about stuff!

I kinda rebuilt it because I wanted to write about building it...

So let me tell you how it works, what I learned, and how easy it is to do it!

Tech stack

To be upfront about it, this blog is built using Gatsby, and deployed using GitHub Actions to a Digital Ocean droplet. And I am very happy with it. This entire website is open source, so if you wanna check the code go ahead!

One day I was reading some blog posts from Tania Rascia and this post made me look into Gatsby. In it she migrated her WordPress blog to a Gatsby website that she built from a pretty bare bones template. I have been thinking of revamping my blog again, since the last one was more than a year ago. Pairing that with my interest with this new JAMStack thing, I just got excited and started looking through the docs!

After building this website, I really enjoyed working with the plugin system and I loved that it used React and Graphql.

Getting started

Following Tania's footsteps, I installed the gatsby-cli and created a website using the gatsby-advanced-starter. Turns out, that was totally overkill for me, and most of the things there overwhelmed me. So I tried again running gatsby new luisramos.dev and slowly added the plugins I needed as I went along.

Starting with the empty project, the first thing I did was setup Tailwind CSS. I am not very good in terms of design skills, and playing around with CSS is fun but can also become a huge waste of time. Tailwind fits nicely into the "just make a component" React world, and paired with a fantastic documentation page, it is very easy to work with. You can quickly create your styles using the existing classes, and when it you start duplicating a lot, you move everything to a component! 👍

Setting up Tailwind with Gatsby was as easy as adding the plugin gatsby-plugin-postcss to gatsby configuration, adding a postcss.config.js requiring the Tailwind library, and adding the Tailwind css imports to the global.css file.

I am very impressed with the plugin system. Anything you need, and you bet there is a plugin that does it! I wanted a RSS feed with all my posts, there's a plugin for that: gatsby-plugin-feed. I want my posts to be in markdown, there's a plugin for that: gatsby-transformer-remark. I wanted syntax highlighting for my code snippets, there's even a plugin for the plugin: gatsby-remark-prismjs! Overall, very wonderful to work with.

This plugin system even got me wanting to build more websites!

React+Graphql

Another feature I enjoyed was the React and Graphql support. In the beginning it felt very overkill to have a graphql query everywhere, but the more I read the documentation, the more it made sense to me.

I have enough experience with React that I could jump straight into this new website building my layout. After I had build the header/footer/nav combo, I started thinking about the main page, and I decided that I wanted the latest three posts there. So when you land, you can immediately read some stuff.

To do this, you write a graphql query in your React page, name it pageQuery and export it. Then, Gatsby will take the data generated from that query and feed it to the component.

The whole experience around this was incredible: I played around with the graphql browser until I had the data I wanted, I pasted the query into the page component, and like magic the data was there! Graphql is pretty sweet.

After that, I added some code to gatsby-node.js so it would create a page for all of my posts. It uses a template, so I don't need to create a component for each post manually. After that, I added a contact and about pages, an RSS feed, some more styling and a bit of content. Sooner than I was expecting, I had a website ready to be deployed!

Deployment via GitHub Actions

My previous blog was hosted on the same Digital Ocean droplet that this one is. I have this one box that I use to play around with several things, so since I am already paying for it, and I don't drive a lot of traffic, I planned the same for this blog.

The deployment steps to get this into the server are:

Run gatsby build to get the static version of the website
Upload the generated folder to the server, preferably using rsync

So I shopped around a bit, and I am impressed by the amount of GitHub actions already available. I created a workflow that checkouts my code, runs the build and uploads the website to my server in less than half an hour. And it caches the ~/.npm folder, so it all runs in 2 mins on CI.

Yay Gatsby

I am very happy with the current setup. This website already has pulled this post out of me, so lets see if it makes me write more! Hope you enjoyed this write up as much as I have enjoyed building the site.

If you liked this post, or if you just wanna send me some feedback, send me a tweet.

As a final note, I wrote this post in a very cool markdown editor, Typora. It is free during beta, so give it a try!

Oh My Zsh prompt theme for Windows Powershell!

Sat, 04 May 2019 00:00:00 GMT

I do most of my programming in my mac these days, but once in a while my gaming desktop becomes the testground for some code bashing. Since I use git on the terminal, on windows I use powershell instead of a sweet zsh shell.

Working with powershell is not that bad, but I terribly miss not having the git branches on my prompt. Since I really enjoy the Oh My Zsh theme on my Mac, here’s a snippet that changes your power shell prompt!

function prompt {
\$ESC = [char]27

$p = Split-Path -leaf -path (Get-Location)
  $branch = $(git symbolic-ref -q HEAD) -replace "refs/heads/"
  if ($branch) {
$branch = "$ESC[34mgit:($ESC[0m$ESC[31m$branch$ESC[0m$ESC[34m)$ESC[0m "
}

"$ESC[1m$ESC[32m$([char]0x279C)$ESC[0m $ESC[36m$p$ESC[0m $branch\$ESC[0m"
}

This code lands in the $profile file, which probably needs to be created:

new-item -itemtype file -path $profile -force
notepad $PROFILE

Notepad should open up and you can copy paste the snipped there!

Auto Layout UIView Extension: A quick way to programatically create layouts

Tue, 30 Apr 2019 00:00:00 GMT

Recently I have taken a renewed interest into this blog. I have revamped the theme (mostly stealing it from my friend's blog, check it out) and now I'm focusing on writing more regularly. I noticed that a lot of my code snippets are just sitting quietly on GitHub or Gitlab and could use a post or two to describe why I made them!

The first one I want to talk about is a UIView extension that I always use in my iOS projects. I always prefer to build my interface programmatically, so that lead me to search for a few auto layout libraries.

The issue I have with using an auto layout library is that if a new developer joins the team, that person will need to deal with my choice of library that usually comes with its own set of idioms and abstractions. My experience is that people enjoy building layouts differently and the preference will always be for some other library! Also, the added abstractions leave me a bit too far away from the auto layout specifics.

Instead of choosing a library, a few years ago I created an extension with just a couple of methods to see if I could get away without adding a dependency.

func align(with view:UIView, constant:CGFloat = 0.0) {
  translatesAutoresizingMaskIntoConstraints = false
  leftAnchor.constraint(equalTo: view.leftAnchor, constant: constant).isActive = true
  rightAnchor.constraint(equalTo: view.rightAnchor, constant: -constant).isActive = true
  topAnchor.constraint(equalTo: view.topAnchor, constant: constant).isActive = true
  bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -constant).isActive = true
}

I kept adding to it as I needed and it kept growing. Currently it looks more like this:

@discardableResult
func align(with view: UIView, constant: CGFloat = 0.0) -> [NSLayoutConstraint] {
  translatesAutoresizingMaskIntoConstraints = false
  let constraints = [
    leftAnchor.constraint(equalTo: view.leftAnchor, constant: constant),
    rightAnchor.constraint(equalTo: view.rightAnchor, constant: -constant),
    topAnchor.constraint(equalTo: view.topAnchor, constant: constant),
    bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -constant),
  ]
  NSLayoutConstraint.activate(constraints)
  return constraints
}

@discardableResult
func alignTop(to anchor: NSLayoutYAxisAnchor, constant: CGFloat = 0.0, priority: UILayoutPriority = .required, isActive: Bool = true) -> NSLayoutConstraint {
  translatesAutoresizingMaskIntoConstraints = false
  let constraint = topAnchor.constraint(equalTo: anchor, constant: constant)
  constraint.priority = priority
  constraint.isActive = isActive
  return constraint
}

As you can see, some wrapper functions with sensible defaults make auto layout better to work with. The code becomes cleaner and easier to read, and you don't loose any of the features that auto layout gives us.

func viewDidLoad() {
  super.viewDidLoad()
  // ... setup view code

  containerView.align(with: view)
  textView.alignTop(with: view, constant: 40)
  textView.alignLeadingTrailing(with: view, constant: 20)
}

This extension has grown after several years of copying this over to each new project and adding something that was missing. It fits my needs well, so I have stopped looking for an auto layout library! The full extension is available in this public gist. Thanks for reading!

Blog revamp: Migrating to Hugo

Thu, 27 Sep 2018 00:00:00 GMT

Update: Since this post was made, I have moved my blog to a new website and tech stack. Check out the post about the new revamp!

The blog has a new look! I like to think it looks a bit better now. Of course the fun side of it is the tech stack. It is now generated using hugo, deployed using Gitlab incredible CI pipelines, and also I'm hosting it on a Digital Ocean droplet.

I want to talk about my experience migrating from Jekyll to hugo, and how I went about setting everything up.

Migrating to Hugo

This blog was previously hosted in Github pages, and it used Jekyll to render the static pages. All the content was in markdown already, so it was relatively easy to migrate it to hugo. The content structure is relatively similar in both frameworks. I only had trouble with the syntax highlight for my code snippets, and with processing the template sass files to CSS.

Hugo uses a code syntax generator called Chroma. The only change is that instead of using the normal markdown code marks, it uses specific tags:

< highlight swift >

You also need to declare the language you are highlighting (swift in that example).

Generating new content is super easy and fast, you just run the following command:

hugo new posts/title-of-blog-post.md

This command will create a new file in the specified content folder, with some front-matter meta data already setup for you to fill.

The template system is also straightforward to use, and you can easily define new content types and front-matter, to be used by the hugo new command.

Hugo Extended

I found a gap in documentation about this, but it seems that hugo has an "extended" version. It adds extras, like sass processing, to the usual binary.

When I tried to edit the template sass files, the changes weren't visible on refresh. They were being ignored, and since I was running locally there was no change it could be some cache issue. I eventually figured out that the template was using generated resources in a resources/_gen/ folder, and deleting that basically broke the generation. Since no CSS was found, hugo threw an error and didn't generate the website.

After googling around, I found out about the extended version of hugo that you can download from their releases page. Running the extended version compiled the sass files into CSS, and made everything work again. But now this means I need the extended version to generate my website, since I want to process the sass files on every generation.

Deployment with Gitlab CI

If you haven't tried Gitlab you should really give it a spin. I'll to not fanboy about it too much, but they have some amazing features.

One of them is the ability to setup a CI pipeline, writing some configuration on a .gitlab-ci.yml at the root of your repo. This way, every time I push a commit to master, a deployment is triggered by Gitlab. You get 1000 free minutes of running time each month, more than enough for all your blogging needs.

Since I have to use hugo extended to generate my website, I couldn't use the suggested image to run my build. I created a new Dockerfile that installs the right hugo binary, and also all the commands needed for deployment. This highlights another cool feature of Gitlab: you have a container register for each project, meaning you can have your container images right next to the project they are relevant to.

After I built and pushed the image, I just needed to reference it in my CI file to get it running the deployment without a hitch! It's pretty satisfying to finally get a CI job green. Check out the .gitlab-ci.yml and the Dockerfile used for this.

Hosting on Digital Ocean

The final command of the deployment is a rsync into a Digital Ocean droplet. Pretty satisfied with the setup process for creating a droplet, it's a one button click for most of what you need. Haven't had an issue with it yet!

I am using nginx to serve the website on the droplet, which was fairly easy to setup with all the info that is available online. I setup certbot to create and automatically renew SSL certificates for the website. It also takes care of updating the website config for you.

Also, since Cloudflare has a one website free tier, I got all of my traffic running through it. So hopefully, my droplet will barely be touched!

DevOps for the common man

I am really happy with this setup. Hugo is a powerful framework, quick to setup but robust enough to handle more heavy duty websites. Gitlab enables DevOps for the common man, giving me control over it but in a way that I'm not overwhelmed. And hosting solutions like Digital Ocean used in conjunction with CDNs like Cloudflare mean that you can serve a lot of people for cheap. A lot can be done by leveraging this infrastructure, which gets me excited!

Next up, I'll add a static CMS like Netlify to this blog so I can write from anywhere!

iOS local notifications ninja bug!

Tue, 26 Sep 2017 00:00:00 GMT

Recently I was working in a project that require me to show a local notification. And for the love of XCode, the app would not show an alert! I was at a loss!

Beginning with iOS 10, the iOS notification framework was revamped to unify both remote and local notifications. This threw me into a loop while trying to figure out the problem. The only thing I had to go by was an error message that popped up when adding the notification to UNUserNotificationCenter:

Adding notification request failed with error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.usernotifications.usernotificationservice" UserInfo={NSDebugDescription=connection to service named com.apple.usernotifications.usernotificationservice}

What a cryptic message, thanks Apple Dev team! I had a custom action setup, so the user could open a url with more info. I was adding this URL to the userInfo of the notification and here was where the bug lived! The issue was that I was adding the URL object, instead of an absolute string of the url. As soon as I changed this, everything worked.

Of course, a stackoverflow answer helped me figure this out!

Fastlane Supply uploads everything!

Tue, 05 Sep 2017 00:00:00 GMT

Ever since I found out about fastlane, I've been using it to deploy Android and iOS apps. It's amazing how streamlined things can get: it saves you a bunch of time when deploying a release; it supports integrations with your favorite distribution platforms (yay Crashlytics); and you can easily copy the setup from one app to the other! Couldn't be happier with it.

Here's a tip for the Android devs out there using fastlane, add this to your before_all step:

before *all do
  sh "rm -f ../app/build/outputs/apk/*/\_/\*.apk"
end

I've found that when deploying Android builds using supply, the tool tries to upload whatever it can find in your build/outputs folder. And often the error you get are unrelated like:

Google Api Error: apkUpgradeVersionConflict:
APK specifies a version code that has already been used.

This is obviously not true if you check your google play console and your build.gradle file. Looking at the output the (at the GRADLE_ALL_APK_OUTPUT_PATHS variable), it seems supply is trying to upload every apk he finds, including debugging version and other flavors. Adding that line will save you some time and stop you from screaming "Why don't the versions match??"

Xcode crash on auto-complete: Snippets!

Sun, 07 Feb 2016 00:00:00 GMT

My XCode crashed after updating it to version 7.2. It happened every time I tried to use auto-complete in an Obj-c file. Since my project was in Swift, it didn't bother me much. Things got worse when I actually needed to edit some library code!

It crash with this exception:

(NSInvalidArgumentException): -[__NSCFData isEqualToString:]: unrecognized selector sent to instance 0x7fd01c5d4530

Since I got bored fast using a text editor to work around it, I tried to fix it. I use some plugins, one of them being fuzzy-autocomplete (if you don't use it, check it out, it's awesome!) I assumed the problem was with one of them. I removed them one by one and everytime I tried, BAM! Still crashing!

This was bad, because plugins where my only option. After googling for a while, I didn't find anyone with a similar problem, so I guessed it had something to do with my custom installation. And this is dumb, but I should have looked to the XCode crash log sooner...

6 0x00000001038f4708 +[IDECodeSnippetLibraryCompletionStrategy_scope:matchesScope:atBOL:] (in IDEKit)

After checking the crash log, it was apparent who the culprit was: Snippets!

It was the only custom thing left on my installation. I renamed the snippets folder, effectively stopping XCode from finding them. And guess what? Yes! Auto-complete worked again! I re-added all my loved plugins (fuzzy-autocomplete included), and back to coding I was. I didn't add my snippets, because I wasn't using them at all. But recreating them with the new XCode should solve the problem.

Just another day working with XCode...

PS: On a side note, if you don't use plugins with XCode, check Alcatraz, a plugin manager! You are bound to find something that will improve your XCode usage :)

iOS Project Structure

Mon, 11 Jan 2016 00:00:00 GMT

To better organized my code, I have been changing my project structure along the years. I think I've finally set with one, so time to record it for the future!

There are two basic guidelines when creating a project structure. First, keep it simple. Second, use something that makes sense to you.

If you google a bit for this topic you may find this quora answer or these guidelines. They both suggest something like this:

View Controllers
Views
View Models
UI (aka storyboards)

If you have small projects, this structure will work fine. But when you start adding more files to it it becomes confusing. I rather organize files in a functional way, separating them by areas and layers of the app. So it ends up something more like this:

Interface
- Base
- Onboarding
- Feed
- User
- Settings
Networking
Local Storage
Classes
- Categories/Extensions
- Classes that don't fit anywhere else
Resources

Inside those folders I usually follow the first setup, separating files by Views, ViewControllers, etc. This way you have almost every file related to an area of the app in one folder. All my images are stored in XCAssets. Fonts and other raw files are in Resources (usually with a dedicated folder for each).

If you have an even awesome setup or if you just want to share yours, feel free to send me a tweet.

Swift Variables in Extensions

Mon, 19 Oct 2015 00:00:00 GMT

I have recently started working on a project that uses Swift2.0! I have been using Obj-C for the past 3 years, and when Swift came I wasn't one of the early adopters. Problems with the language and with SourceKit always crashing in XCode 6 didn't make for a good dev environment. Now with the 2.0 released to the wild, the promise of open source and XCode 7, Swift is good to go!

One of the first problems I had is one that happens to many iOS developers that use extensions/categories in their projects: How do I add a variable (static or not) to an extension?

Since I seem to always be googling for this one, I'll log it here for future convenience.

Static Variables

For a static variable, there is actually a really neat way:

extension UIView {
  struct Static {
    static var defaultPadding : CGFloat = 16
  }
  func widthWithPadding() -> CGFloat {
    return self.bounds.width + Static.defaultPadding
  }
}

Since you can declare structs in an extension, you can use these value objects to hold your static variables and they function the same way as declaring a static variable on the class. If you don't like the extra Static. declaration, you can create wrappers using computed variables:

extension UIView {
  var defaultPadding : CGFloat { return Static.defaultPadding }
}

Instance Variables

For instance variables the solution is to use the obj-c runtime. You need to create computed variables that get and set an associated object using objc_getAssociatedObject() and objc_setAssociatedObject(). This is the same approach taken if using it with Obj-C.

import ObjectiveC

extension UIViewController {
  struct Static {
    static var MainTitle = "\_MainTitle"
  }
  var mainTitle: String? {
    get{
      return objc_getAssociatedObject(self,&Static.MainTitle) as? String
    }
    set(value){
      if newValue = newValue {
        objc_setAssociatedObject(self,&Static.GenericTitle,newValue as NSString?,.OBJC_ASSOCIATION_RETAIN_NONATOMIC)
      }
    }
  }
}

That way you can extend to your heart desire! If you want to understand the difference between structs and classes check out the Apple docs. And to find out more about what kind of magic you can do with obj-c runtime check out NSHipster post on it.

Test Post. Please Ignore.

Sun, 18 Oct 2015 00:00:00 GMT

Hey, I'm creating this to see if I can finally settle the toughs that come to me while I code away. I find that I should write down something so future me can make use of the troubles I go through, but the past me never got around to actually do something. Let's see if this time is the charm.

I plan to write about software, mobile programming, the weather and whatever I feel like (that means gaming probably).

Let's do this!