Nowadays, everyone seems to do stuff with OpenAI’s GPT-3/ChatGPT. But how much more useful would it be, if OpenAI’s text completion APIs would return structured data, like JSON, instead of plain text?

Consider the following use case: you want to create a little app that uses the OpenAI GPT-3 API to generate fantasy characters for your role-playing crew — with background stories, attributes and everything.

Yep, that nerd stuff many of us developers love so much. 🧙 But this is for everyone, so stay with me. It will be short and sweet!

Now, let’s start with a simple prompt like this:

Create a character for a fantasy roleplaying adventure, with background story, physical attributes, mental attributes and appearance.

GPT-3’s answer would be something like this (obviously depending on temperature and other parameters):

Name: Evelynne Shadowblade
Background: Evelynne was born into a family of skilled assassins, and was trained in the art of stealth and subterfuge from a young age. However, she grew disillusioned with the family’s morally questionable work, and struck out on her own as a rogue adventurer.
Physical attributes: Evelynne is a lithe and agile half-elf, with short black hair and piercing green eyes. She stands at 5'7” and weighs 120 lbs. Her lithe build allows her to move quickly and quietly, and her elven heritage gives her heightened senses and reflexes.
Mental attributes: Evelynne is intelligent and cunning, with a quick wit and a sharp tongue. She is also fiercely independent and distrustful of authority figures, preferring to work alone or with a small, tight-knit group of allies.
Appearance: Evelynne wears tight-fitting leather armor that allows her to move silently and quickly. She carries a pair of curved daggers at her waist, and a quiver of poisoned arrows on her back. Her face is often obscured by a hood or mask, to further obscure her identity.

That’s cool! 🥷

But let’s be honest, if I were to display so much text in an app, it would look rather unappealing, and overall I couldn’t do a whole lot with plain text in terms of app features.

So how can we make this better? Well, we would first have to bring it into a format that…

1. is consistent across responses.
2. is easy to parse and store (even if the generated data would be in different languages than English).

Now, plain text GPT-3 output isn’t very well suited for this kind of requirements out of the box.

Instead, let’s try to get the API to spit out some JSON with a structure we define in the prompt:

And this is what we get from GPT-3:

{
  "name": "Evelynne Shadowblade",
  "background": "Evelynne was born into a family of skilled assassins, and was trained in the art of stealth and subterfuge from a young age. However, she grew disillusioned with the family's morally questionable work, and struck out on her own as a rogue adventurer.",
  "physical_attributes": "Evelynne is a lithe and agile half-elf, with short black hair and piercing green eyes. She stands at 5'7\" and weighs 120 lbs. Her lithe build allows her to move quickly and quietly, and her elven heritage gives her heightened senses and reflexes.",
  "mental_attributes": "Evelynne is intelligent and cunning, with a quick wit and a sharp tongue. She is also fiercely independent and distrustful of authority figures, preferring to work alone or with a small, tight-knit group of allies.",
  "appearance": "Evelynne wears tight-fitting leather armor that allows her to move silently and quickly. She carries a pair of curved daggers at her waist, and a quiver of poisoned arrows on her back. Her face is often obscured by a hood or mask, to further obscure her identity."
}

Not bad at all—already ticks all the boxes from the list above!

But we can do even better! In RPGs the loadout of a character plays a big role. So let’s put it into a separate JSON array.

And, sure enough, GPT follows the instructions to the point:

{
  "name": "Evelynne Shadowblade",
  "background": "Evelynne was born into a family of skilled assassins, and was trained in the art of stealth and subterfuge from a young age. However, she grew disillusioned with the family's morally questionable work, and struck out on her own as a rogue adventurer.",
  "physical_attributes": "Evelynne is a lithe and agile half-elf, with short black hair and piercing green eyes. She stands at 5'7\" and weighs 120 lbs. Her lithe build allows her to move quickly and quietly, and her elven heritage gives her heightened senses and reflexes.",
  "mental_attributes": "Evelynne is intelligent and cunning, with a quick wit and a sharp tongue. She is also fiercely independent and distrustful of authority figures, preferring to work alone or with a small, tight-knit group of allies.",
  "appearance": "Evelynne wears tight-fitting leather armor that allows her to move silently and quickly. She carries a pair of curved daggers at her waist, and a quiver of poisoned arrows on her back. Her face is often obscured by a hood or mask, to further obscure her identity.",
  "loadout": {
    "weapons": [
      {
        "name": "Curved Daggers",
        "description": "A pair of razor-sharp daggers with a slight curve to the blade. Ideal for close-range combat and stealthy kills.",
        "dps": 25.0
      },
      {
        "name": "Poisoned Arrows",
        "description": "Arrows dipped in a potent toxin that paralyzes or kills the target. Ideal for ranged combat and setting traps.",
        "dps": 15.0
      }
    ],
    "potions": [
      {
        "name": "Invisibility Potion",
        "description": "A potion that renders the drinker invisible for a short period of time. Ideal for sneaking past guards and avoiding detection.",
        "effect": "Grants temporary invisibility."
      },
      {
        "name": "Healing Potion",
        "description": "A potion that restores a portion of the drinker's health. Ideal for quick healing in combat or after a tough battle.",
        "effect": "Restores 50 health."
      }
    ]
  }
}

Obviously we could go much further here, but I think you get the point: You can easily get OpenAI’s GPT-3 API to respond with a JSON using literally any schema you want!

Every developer out there will know what this means: it opens up a whole new set of applications with a super low entry barrier. 🚀 So go, code the next generation of GPT-based applications before someone else does. Exciting times! 🤯

Let me finish with some gotcha’s:

1. Define value types as strictly as possible, such as units (“use SI units”, “use metric units”, “use g instead of kg”), types (“make “dps” a Double”) and the likes.
2. Be prepared for incomplete JSONs if the token limit is reached. Split up single big requests into multiple smaller ones or tell the API to keep it short (literally!) to avoid this situation. Repeat requests if necessary.
3. Following up on the previous point: When attempting to parse the JSON modify your parser to be as lenient as possible. For example: the generated JSON will at times have added commas at the end of lists and for the last key/value pair in objects. So you either need to remove those superfluous commas or use a JSON5 parser which by design allows trailing commas and more.
   Here is a possible implementation of such a trailing comma remover in Kotlin for your convenience:

private val trailingCommaInObjectRegex = Regex(""",\s*\}""")
private val trailingCommaInArrayRegex = Regex(""",\s*]""")

private fun String.removeSuperfluousTrailingComma(): String {
    return replace(trailingCommaInObjectRegex, "}")
      .replace(trailingCommaInArrayRegex, "]")
}

If this helped you, and you are now successfully tapping JSONs from OpenAI’s APIs, consider fueling my brain with some black liquid, too. ☕ Much appreciated!

I’ve been working remotely for 6 years straight now. And no matter what my co-founder thinks, I could surely never (?*) go back to regular office life.

Now, I’m sure you’re thinking: not another treaty on the benefits of working remotely from a privileged knowledge worker.

Well, in part you are right: as a developer I am privileged and always have been. But things might be different than you might picture them…

I’m not just a developer, I’m also founder and CTO of a company called whisp — we are the crew behind CLEAR, one of the most popular intermittent fasting apps on the app stores. And my co-founder and CEO is fiercly pro-office.

So I’m also writing this in part as the second half of a picture both of us are trying to paint at whisp. But I’m also doing this as an attempt to understand the office lovers in our team.

whisp was founded as a remote-first company three years ago. My co-founder and I had been working together for about 6 years. First at a dating app company with a strong office culture, including the obligatory table football, billiard, an amazing office space, free lunches, lots of parties and meetups— just what you would expect from a hip start-up in the late 2010s. Later both of us went to work at a remote-first app-agency with employees all over Europe — here we could work whenever wherever we wanted as long as we got shit done.

At one point we huddled and came to the conclusion, that it was time to roll our own thing. Both of us being well into our thirties it seemed like catching the last train for founding a startup before potential employees would deem us too old to be cool, while at the same time having acquired enough experience to avoid the biggest traps in the app business.

So off we went. Apparently we had similar experiences from the past, at least when it came to the last 3 years where we had worked together — undeniably the most influential ones in our career up to that point. It seemed to be a given that we would have similar ideas for how we would want to work together at whisp.

At first it just looked like that. We gathered for quite a few internal hackathons to conceive the next big thing and in the end came up with a prototype for an intermittent fasting app — as intermittent fasting also had helped us a lot to cope with the stress (and unhealthy habits) of our previous gigs we thought it would be something other people might be interested as well.

Then we parted into our own spaces and started hacking on the real thing. Both of us are living in different places, roughly 60 kilometers apart. We knew how to efficiently work remotely, we didn’t have money for an office — working from home seemed like a given.

And so our company became remote-first — at first…

But soon my co-founder muttered. He is an extrovert par excellence, thriving on in-person contact, while I am what many would describe as the typical introverted developer — not being completely averse to social interaction, but only in small doses and with big breaks in between.

So working remotely obviously was more beneficial to me than to him. I enjoyed planning features with him via video call, spec’ing them out from a design perspective in Figma (that was mostly his part) and then technically in Slite and Linear (my part). Afterwards I went head-on into undisturbed development — keeping him posted about my progress in Linear and Slack, but apart from that focusing on doing what I can do best: 1000111110110110111001… (you get the idea)

At the same time my co-founder would go and search for investors and plan new features.

In the meantime we hired a handful of new employees, most on the product and content side of things, but also a few developers.

But while things really looked well on the business side, something felt off, especially for my co-founder. He felt a sense of disconnection. We hired many of our employees and freelancers on the notion of being a remote-first company. At the same time most of them came from our region as we had extensively sourced from our existing contacts from our former jobs.

So we decided to provide them with a place where they could work from if they didn’t want to work from home or didn’t have a suitable place there.

We went looking for a small office space in a shiny new coworking space. Working from there was purely optional.

After some time we observed something interesting: one half of the employees worked from the office nearly full-time. The other half worked from home as much as they could.

The company had become what my co-founder aptly once called remocal. Half working colocated and in-person, half working remotely. But could that work? What kind of team member went for which option? And why?

Remoters

As mentioned before, half of our company consists of people who strongly prefer working remotely over work from a shared office space — I call us (slightly unimaginatively) Remoters.

Why?

People who opted to work remotely most or all of the time (which includes me) usually cited the following reasons for doing this:

• A new-found freedom: many of them never had worked remote-first before. They especially enjoy to be able to choose time and location of their work.
• Additional time for private matters, hobbies and family, as they don’t have to commute to and from work.
• They enjoy the high levels of trust we put into them (when we founded the company we opted for not tracking time at all)
• The abundance of focus time they are getting when working uninterrupted. We are keeping digital meetings to a minimum and try to work async as much as possible.
• Out of reach from certain viruses — yes, COVID, I’m looking at you.

Who?

This is by no means to be generalized, but in our company people preferring to work remotely tend to tick the following boxes:

• Rather introvert than extrovert. They enjoy social interaction, but only a limited amount with longer breaks to decompress.
• Good at setting work/life boundaries and shutting off after work.
• Good at planning, scheduling and productivity in general.
• Very reliable, a core trait to make remote work possible. Most expect the same thing from their coworkers.
• Need silence and their mode to get into the zone. You will see them with headphones on all time when they need to work in a space where other people are communicating. Sensory overload is a thing for this group. Most of them also will not be able to focus when someone is constantly looking over their shoulder.
• Learn and improve on their own schedule. They usually prefer a self-paced online course over a three day workshop to get the hang of a new topic.
• Have special requirements for their work setup, e.g. a warm cozy area, a cup of Joe made from their favorite carefully selected beans, a clicky keyboard unsuitable for shared office spaces (that would be me).
• Some have very busy schedules and/or love/have to scatter their work stints over the course the day — parents will relate.
• Some people in this group love to work from different places all over the world which is only feasible when working remotely.

Officionados

Our office crew which you would find at least 80% of the time in our office values different things as they are a different sort of people. My co-founder is one of those Officionados.

Why?

For Officionados choosing the office as their preferred working location feels just logical due to the following reasons:

They needed the in-person meetings and water cooler talks as they considered it a vital part of their creating synergies — and bonding. Also, working on a problem in an office face-to-face can help pushing through difficulties as encouragement comes easier when being in the same room.

• A feeling of connectedness. This group loves to bond via social interactions. Please don’t mistake this with loud people, they may be silent at times, but they are not breaking a sweat when facing a new person and have to do small talk.
• Synergies which often unfold over water-cooler talks. Unbelievable things can grow out of those unplanned meetings and Officionados value this a lot.
• Clear separation of work and (private) life — when at the office it’s work time, when not, private life unfolds.
• High quality and work suited space. Not everyone has access to a perfectly equipped home office, let alone a separate room for work only. And not everyone can switch off at home when there are children, partners or roommates around. A dedicated office solves these problems.
• The maker spirit of co-working spaces. As opposed to exclusive offices, offices and work stations in co-working spaces tend to have many different kinds of interesting people with tons of inspiring ideas and characters floating around. Certainly not the worst place for a startup-team to be.

Who?

• Learn and grow with people, not documents. They learn most efficiently in a group, when pushing each other through motivation valleys and to the limits when approaching the apex.
• Love to hang around with their colleagues after work. This obviously is possible with much less ceremony when simply leaving work together to hang out for another hour or two in their favorite bar or restaurant. For them having lots of social contact actively reduces stress (contrary to many remote believers for whom too much of it induces stress).
• Constant feedback-loops are highly valued. The back and forth when discussing ideas with others brings out the best in many Officionados.

Obviously those lists are neither exhaustive nor exclusive and not everyone in every group matches all of them. But the patterns are quite obvious — at least in our team.

Now, for me the most interesting insight unfolds when you look at what Officionados love about working from home from time to time and what Remoters enjoy during their visits at the office.

Here is a secret: Most Remoters actually like meeting their team mates — yes, they do! For them (well, I should say “us”) it is comparable to a birthday. You are looking forward to it, but it would wear off quickly if you had birthday everyday. Heck, birthdays even wear off for most people anyway over the years even if they are just once a year. Similarly Remoters don’t need in-person meetings and water cooler talks to work productively. And they don’t need it daily because it also induces a certain level of stress — commuting to the office, meeting new people in shared offices, different coffee or tea (!) and not being able to go offline if it becomes too much and focus becomes impossible.

So for Remoters visiting the office space and seeing their team in person is something special and unique — a highlight, not the default.

And Officionados? Being social beings means many of them love meeting new people. And where can you meet people better than while traveling? Working remotely from co-working spaces, airports and Airbnbs in other countries makes visiting new places so much easier without spending half of your vacation days on traveling to your desired destination.

And of course many Officionados also have families and non-work obligations and therefore, from time to time (or daily, e.g. during the first half of the day), love the unprecedented freedom of working remotely to get everything done.

It turns out, most of our team members are actually both: Officionados and Remoters. It’s just the ratios which differ — though quite substantially for some. And as life changes, so do preferences and needs.

So maybe, it’s not about Remoters vs Officionados. It’s about finding the right way to work for you at this very moment in your life. And supporting others in doing the same.

And that’s what we are trying to do over here at whisp. Yes, I’m fully aware that this remocal setup is certainly bound to spark a lot more interesting (and at times heated) discussions in the future. 😅

But in the end for a company the most important thing is that everyone working there can do so at their very best. And this is only possible if we can create a work environment that works for everyone. For some this is a beautiful and lively office space. For others it’s a cozy home office. And for many it’s both and is as fluid as life itself.

*I admit this post turned out different than I initially intended it to be when I started to write and I’ve actively decided against going over it once more and redacting it (except for adding that little question mark in the intro). As reflection can result in the most curious insights. Most curious indeed… 🤔 And sometimes it can help to have the meandering river of thought written down rather than redacting it away. As it is very likely that at some point in your life you will be back at the source of river, caught in the same state of mind. And reading written down your thoughts from years ago when you were in the same situation can provide a nice shortcut to the delta and the open sea of possibilities and freedom of mind.

I will surely read these lines again in the future. Here’s a heads-up to my future self:

Panta rhei — everything flows. (Simplikios)

So never say never, you stubborn donkey.

It happened again.

I grossly underestimated integrating a third party SDK into our iOS app based on Kotlin/native. And by grossly I mean not just 2x or 5x, but an order of magnitude. I’m not proud of it, but it’s just what it is and it’s certainly worth a blog post as I learned one or two (actually 4, feel free to skip to the last section if you are in a hurry) things from it — and I guess I just need to write this down to finally start looking at it not just as a gigantic waste of time, but also as a lesson in patience and humility.

First of all, technically I lied in the intro: I underestimated the effort by *at least* an order of magnitude, as I am still not done yet. After two weeks. Not working straight on it, but on and off, which is kind of worse as it really created a lot of context switching overhead. That being said, let’s start from the beginning.

It was just another task on just another day…

OneSignal is a push and in-app messaging SDK for mobile apps. It helps facilitating communication with your user base and as such is quite important for many mobile apps.

OneSignal integration into our (not Kotlin/native based, but just plain Kotlin) Android app was easy peasy. Just as expected I was done in a day including extensive testing.

So I expected around two days for iOS integration, as firstly, I have nowhere as much iOS experience as Android experience and secondly, our iOS app is based on Kotlin/native which potentially could complicate things. However, I didn’t expect much trouble from the latter as the OneSignal SDK was supposed to just touch the Swift side of things, so what could go wrong?

Well, turns out, hell of a lot!

The OneSignal SDK does something clever when you integrate it into your app (no matter whether you are using Swift Package Manager or Cocoapods). Without writing a single line of code its existence as a dependency alone will trigger a process called swizzling on app start. I am not super proficient in iOS development — I am more on a _can-make-things-work_ level, but here is what I understood swizzling does at a very high level: at app start (so at runtime, not at compile time) swizzling will exchange/add implementations of functions. This is usually done so that developers don’t need to implement certain calls to the SDK on their own and in the process make mistakes by calling the wrong functions at the wrong time.

In OneSignal’s case they are swizzling push notification handling capabilities which should make my life as an engineer easier. Should. The problem is, the way they are doing swizzling changed initialization/loading order of certain classes — something the Kotlin/native code at the other end of the food chain didn’t expect!

What the swizzle?

My first thought was: why does the Kotlin/native code even bother? It’s all Swift stuff being touched by OneSignal, or is it? Turns out, it’s not. Swizzling causes virtually all classes in your binary to be touched — that’s just how it works from what I understood from the more advanced documentation and posts you can find online. It seems to follow the visitor pattern: visit all classes and functions and then ask whether the implementation should be changed. If all classes are touched, so are the Kotlin/native classes.

And that’s the culprit. Right at app start, the app crashed with a SIGABRT (feel free to ignore the trace, it’s just here for the show effect):

Yes, that’s what I, with my limited iOS knowledge, got to see after launching my app. Quite of a mouthful, huh? There are better ways to start your day, believe me.

It took me some time to figure out what was happening — although that’s actually an exaggeration. I didn’t really know what was going on, just that swizzling somehow seemed to interfere with some Kotlin/native magic.

Road to redemption?

So I did what every responsible engineer does: fire up Google and search for what I thought was causing the problem. In lieu of meaningful search results (Kotlin/native still isn’t as widely employed as it could potentially be) I then reached out to the OneSignal and Kotlin/native developers.

If anyone is interested, here are the bug reports:

Crash at app start with Kotlin/native; objc_getClassList causing initialize to fire before load on non-OneSignal · Issue #1042 · OneSignal/OneSignal-iOS-SDK

and

https://youtrack.jetbrains.com/issue/KT-50982#focus=Comments-27-5741956.0-0

Luckily, developers of both OneSignal and Kotlin turned out to be very responsive, kudos! And the Kotlin engineer I talked to even came up with a quick to implement workaround, after I had managed to create a sample project for him to replicate the issue: I had used CocoaPods to integrate the OneSignal SDK, he asked me to use SwiftPM instead and at the same time make the Kotlin/native shared code module a dynamic framework.

And it worked! As you might expect I was overjoyed! And it got even better, the Kotlin native engineer already had implemented a fix for the issue which is scheduled to be released in about 3 months as part of the next Kotlin beta.

Actually, I would have preferred to stay with CocoaPods and the static framework and instead disable swizzling for the OneSignal SDK, but it’s not clear yet, whether the latter is possible — the cost of taking away much of the integration work from user-engineers is usually paid by the same engineers when their setup is not as expected. ¯\_(ツ)_/¯

At that point, I had spent about 2 weeks on the problem. Phew.

Time to merge. I created the PR and our CI started to do it’s thing. Part of the _thing_ is to create and export an archive for internal testing purposes. And guess what? Yup, exporting failed.

shared not found in dylib search path

Bummer.

By changing the shared Kotlin/native module to be a dynamic instead of a static framework I screwed up linking big time! At the time of writing this issue has not yet been solved despite two days of try and error (once more violating learning #3, see below). I’ll update the post when we have a solution for that problem.

Update

There finally is a solution, and it consists of fixes introduced to the latest versions of Kotlin and OneSignal. Big thanks to the amazing teams over there for going the extra mile here and fixing this awkward issue! 👏

Lessons learned

1. Never underestimate the integration costs of a third party SDK, especially if it promises to be integrated “in less than 10 lines of code” (quoting the OneSignal landing page).
2. Never underestimate the added costs when employing a growing, but not yet established technology (such as Kotlin/native in my case). However, to be fair, this was the first time I stumbled on such an issue with Kotlin/native, never had any similar problems over 2 years of development, so it also seems to be a special case.
3. Never overestimate your own skills and instead ask for help, when you need it. It took me three days until I reached out to the OneSignal and Kotlin engineers. Before I spent way to much time trying to debug things I clearly had no real idea of. That doesn’t mean one should bombard dev-support or StackOverflow without spending some time to think about a solution on your own. But you should foster the mental clarity to see when you need help. And when you reach out to your fellow developers: ensure that your bug report adheres to their project’s guidelines and provide all the information needed in a concise and complete manner. It’s just a matter of etiquette and respect of their time.
4. Never underestimate the time it takes to create a sample project. Here, it took me over two days to finally boil it all down to the essentials and making sure that the issue is still reproducible.

Now, any of those learnings should be new to someone who spent more than two decades on coding (oy, I’m getting old…). But it helps to reiterate them from time to time to overcome the hubris that sometimes comes with growing experience.

I will probably end up to be the person reading this post the most — it shall serve as a reminder for my future self, but might also help you, dearest reader, to avoid the estimation traps I fell into.

It’s that time of the year where many of us revise their workflows and try to optimise. And boy, there is always quite a lot to improve!

This time my GitHub workflow was ripe for a productivity check. Something, that I always found cumbersome since the inception of the amazing GitHub auto-merge feature was, that you couldn’t see whether a pull request was due for auto-merge or not in the pull request overview page:

For everyone who doesn’t know auto-merge: it essentially allows you to tell GitHub to merge a pull request as soon as all checks are green. Usually this means after the CI has successfully build the branch and all checks have passed. No more waiting for that little checkmark to turn green to be able to press the merge button! ✅

Even when working alone on a repository there can be quite a lot of (automated) pull requests with tools like Dependabot and the likes.

When it’s review and merging time, for me that usually means lots of unnecessary clicking on yellow state (that is in progress of being checked) pull requests which actually were already queued up for auto-merging — thanks for nothing, bad short-term memory! 🤯

A simple way to improve this is labeling pull requests for which auto-merge had been enabled previously which makes those PRs easy to spot and simple to filter in the pull request overview.

Turns out, that’s super easy to do with GitHub actions! And to make it even simpler for you, I’ve packaged this into an action ready to be used via the Github marketplace:

Label auto-merge PRs - GitHub Marketplace

You can integrate this into your repository with a straightforward 2-step process:

1. Create a new workflow file in your repository, usually under .github/workflows. You can give it any name, e.g. automerge-labeler.yml.
2. The content of the file should be something like the following:

What this configuration file instructs the workflow to do is:

1. Monitor all pull requests for enable or disable auto-merge events.
2. Instruct the automerge-labeler action to (un-)label those pull requests with auto-merge.

Commit and push and boom! 💥 All auto-merge pull-requests will now automatically be labeled!

Consider this: You need a button to change its elevation depending on the scroll state of a RecyclerView (in fact any ScrollingView): the button (which for various reasons I decided to implement as an ImageView should have zero elevation when the RecyclerView is at scroll position 0 and 6 dp elevation otherwise.

The way to make this work is by leveraging CoordinatorLayout and a custom Behavior.

Behaviors are a quite flexible CoordinatorLayout feature. You can attach behaviors to any direct child of a CoordinatorLayout (or children of ViewGroups which define their own default behavior, but I won't dive into this here).

You can set behaviors either in code or in XML. I did the latter:

<androidx.coordinatorlayout.widget.CoordinatorLayout
   ...>
    
   <ImageView
      ...
      app:layout_anchor="@id/rcv"
      app:layout_anchorGravity="top|start"
      app:layout_behavior="com.example.ElevateOnScrollBehavior"
      android:elevation="@{0}" />
   
   <RecyclerView
      ...
      android:id="@+id/rcv" />
 </androidx.coordinatorlayout.widget.CoordinatorLayout>

First we are setting the initial elevation to 0 using android:elevation, you'll note that this is a data binding expression here - more on that at the end of this post.

app:layout_behavior="com.example.ElevateOnScrollBehavior" defines our elevation modifying behavior.

app:layout_anchor="@id/rcv" tells the behavior which target view is relevant for it and should report its scroll state.

app:layout_anchorGravity="top|start" defines the position of the ImageView relative to the RecyclerView which for that sake is handled like a FrameLayout, that's why we can just define a gravity and need to fake everything else using paddings and margins.

Let’s have a look at the behavior. For our use case we are interested into to functions in the CoordinatorLayout.Behavior interface: onStartNestedScroll() and onNestedScroll()

The first is called before the actual scroll happens and allows us to decide whether we are interested in it based on properties like the axis or the scroll target.

The latter is then called every time a subsequent scroll happens and this is where we employ our magic.

class ElevateOnScrollBehavior<V : View> @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null
) : CoordinatorLayout.Behavior<V>(context, attrs) {

    override fun onStartNestedScroll(
        coordinatorLayout: CoordinatorLayout,
        child: V,
        directTargetChild: View,
        target: View,
        axes: Int,
        type: Int
    ): Boolean =
        axes == ViewCompat.SCROLL_AXIS_VERTICAL &&
                target is ScrollingView

    override fun onNestedScroll(
        coordinatorLayout: CoordinatorLayout,
        child: V,
        target: View,
        dxConsumed: Int,
        dyConsumed: Int,
        dxUnconsumed: Int,
        dyUnconsumed: Int,
        type: Int,
        consumed: IntArray
    ) {
        if ((target as ScrollingView).computeVerticalScrollOffset() > 0) {
            6.dpToPx(coordinatorLayout.context.resources.displayMetrics).scoped { newElevation ->
                if (newElevation != child.elevation) {
                    child.elevation = newElevation
                }
            }
        } else if (child.elevation != 0f) {
            child.setZeroElevation()
        }
    }
}

As you can see we are only interested in scrolls along the vertical axis and only in those coming from ScrollingViews as this interface has a method we are going to use in onNestedScroll() to determine the vertical scroll offset of the target view. Conveniently RecyclerView implements ScrollingView, so we are good to go here.

In onNestedScroll() we simply check for the vertical scroll offset and if it is bigger than zero we give the View some (fixed for now) elevation, otherwise we set it to zero.

Unfortunately using View.setElevation(0f) would result in a non-clickable view for some reason. Therefore I am using my custom View.setZeroElevation() extension function and a custom data binding adapter for android:elevation. More on that in Zero elevation - zero click handling?.

Something I’ve only discovered after 10 years of Android development: Setting zero elevation on clickable elements causes them to not being clickable anymore!

I haven’t yet investigated whether this is a bug or a feature, but here is a simple workaround (by means of BindingAdapters, but of course you can also use the supplied View-Extension function on its own):

@BindingAdapter("elevation")
fun setAppElevation(view: View, elevation: Float) {
    setElevation(view, elevation)
}

@BindingAdapter("android:elevation")
fun setAndroidElevation(view: View, elevation: Float) {
    setElevation(view, elevation)
}

private fun setElevation(view: View, elevation: Float) {
    if (elevation == 0f) {
        view.setZeroElevation()
    } else {
        view.elevation = elevation
    }
}

fun View.setZeroElevation() {
    elevation = 0f
    bringToFront() // this fixes 0 elevation views not being clickable
}

The trick is to call bringToFront() after setting the elevation to 0dp - this makes the View recognize click events again. By using BindingAdapters and forwarding to View.elevation we ensure that we don't break existing elevation functionality for Views.

You can simply use this in your layout XML like this:

<View
      ...
      app:elevation="@{0}" />

or

<View
      ...
      android:elevation="@{@dimen/zero}" />

where @dimen/zero is just a fictional 0dp dimension resource which is automatically converted to float pixels by data binding, but obviously it could be any expression resulting in a float.

I thought it might be nice to have such a thing every time I open my shell (I am using iterm2 with zsh for what it’s worth, but the following will work with nearly every shell out there).

To make it happen first locate your shell’s configuration file. Usually you can find those in your home folder, oftentimes they start with a dot (.) and end with rc. In the case of zsh the file is called .zshrc. In case of bash (the default shell on many systems) it is .bashrc. If the file doesn’t exist yet simply create it in your home folder.

TL;DR: To get exactly the output like in the screenshot above you would append the following two lines to your rc file:

And here is what we did:

To output something at every start of the shell just add a line at the bottom of the configuration file. E.g. to print a simple static text we would append:

echo "Welcome, commander!"

To print a quote from the zen API we need to use curl instead which is a pretty common way of performing network requests via the shell:

curl -s -m 1 https://api.github.com/zen

-s is short for --silent and does just that: it won’t show any errors or timeouts or request-meta information like status codes, just the plain response.

-m 1 controls the timeout: In our case we want it to be rather small as usually you fire up the terminal quite often and want it to be available as fast as possible. So this sets the timeout to 1 second.

Finally -w '\n' takes care of adding a newline character at the end of the curl response. Otherwise some shells (like zsh) would print out a percent sign at the end of the line.

And that’s it. Enjoy the zen. ☯️

Oftentimes, when locally building release builds, e.g. to debug issues, you don’t have access to the signing config as you maybe just have it available on your CI — after all you should really try to avoid storing your release keystores on your local development machine.

However, Android Studio will complain (inside the run configuration screen) about a missing signing configuration if you try to build release variants without:

In that case you can simply use the debug keystore by adding the following line to your release build type definition in your app’s build.gradle:

android {
  buildTypes {
    release {
      signingConfig debug.signingConfig
    }
  }
}

That should allow you to compile and run the release version of your app locally.

Please note that in app purchases won’t work with the debug certificate. You also won’t be able to upload an APK signed with the debug certificate to the Play Store.

Today I stumbled about one of these tiny things which — once you uncover them — immensely ease your life.

Consider a String with placeholders stored in your strings.xml:

Now let's say we want to use that String directly in data binding. Before figuring out the following trick I would fetch the data from the attached ViewModel which would use String.format() to replace the placeholder with e.g. the user name.

Turns out there is a by far easier way to do this directly within the layout:

Isn't that neat?

Let’s imagine you need to provide a gradient background consisting of arbitrarily many colors to a View.

This can’t be done via regular drawable XML as a gradient within a shape can only define three colors: startColor, centerColor, endColor.

To reach our goal we will be using data binding.

We define an integer array in e.g. arrays.xml and fill it with the desired color resources:

Then we define a binding adapter to apply the colors in a gradient to the background of the View:

Now we can define the background colors in our layout XML (apply it to any View class you like):

Note, that we have to reference integer-array resources with @intArray in data binding expressions!