<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kotlin on BradCypert.com</title>
    <link>https://www.bradcypert.com/tags/kotlin/</link>
    <description>Recent content in Kotlin on BradCypert.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 22 Mar 2023 19:21:16 -0400</lastBuildDate>
    <atom:link href="https://www.bradcypert.com/tags/kotlin/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Adapting Traits for Kotlin</title>
      <link>https://www.bradcypert.com/adapting-traits-for-kotlin/</link>
      <pubDate>Wed, 10 Apr 2019 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/adapting-traits-for-kotlin/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://docs.scala-lang.org/tour/traits.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Traits&lt;/a&gt;&#xA; are a pattern introduced in Scala (at least, this was my first introduction to them) that help avoid deep class hierarchies in favor of composition. If you don’t have Scala experience, but do have Java experience, you can treat this similarly to &lt;a href=&#34;https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Java 8 Interfaces&lt;/a&gt;&#xA;. However, I still prefer to call them Traits.&lt;/p&gt;&#xA;&lt;p&gt;Although Traits have first-class support in Scala, Kotlin does not directly have Traits. However, &lt;a href=&#34;https://kotlinlang.org/docs/reference/interfaces.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Kotlin does support default interface implementations&lt;/a&gt;&#xA;, just like Java 8. It’s fair to assume then, that Kotlin can have a similar concept of Traits only constructed from Interfaces with default implementations.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Comparing Kotlin to Scala</title>
      <link>https://www.bradcypert.com/comparing-kotlin-to-scala/</link>
      <pubDate>Tue, 05 Mar 2019 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/comparing-kotlin-to-scala/</guid>
      <description>&lt;p&gt;Kotlin to Scala. Scala to Kotlin. Two contenders for my heart. In the left corner, we have the new comer! Weighing in at just over 1.2MB — The Ambassador of Android: Kotlin! And in the right corner, we have the long-time favorite, weighing in at just over 5.3MB — The Archduke of Akka, The Sultan of Spark: Scala!&lt;/p&gt;&#xA;&lt;p&gt;If you’ve made it this far through my silliness, you’re likely comparing Kotlin to Scala for your next project. There’s definitely some key takeaways from the above paragraph that may influence your decision. However there’s more to each language than I could dare try to squeeze into an introductory paragraph. The rest of this post will cover each of these languages in comparison to:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Formatter Objects: Testable Fragments</title>
      <link>https://www.bradcypert.com/formatter-objects-testable-fragments/</link>
      <pubDate>Thu, 24 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/formatter-objects-testable-fragments/</guid>
      <description>&lt;p&gt;Let’s face it — Fragments are a pain to test and it’s predominantly due to how the Android operating system works. Sometimes, you’ll find yourself writing business rules regarding how a view is displayed. Likely, some data will come back from a web server and you’ll have to format some text differently or color something differently. Nothing crazy, but all this code adds up and needs to be tested.&lt;/p&gt;&#xA;&lt;p&gt;Ideally, you’ll have some form of automation coverage to help tackle this problem, but Espresso tests can be slow and environment dependent. But what If I told you that you could write unit tests for this logic and simplify your fragments all in one swoop? Hopefully you’re as excited about that as I am.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Facade Pattern for Simple Dependency Injection</title>
      <link>https://www.bradcypert.com/the-facade-pattern-for-simple-dependency-injection/</link>
      <pubDate>Wed, 16 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/the-facade-pattern-for-simple-dependency-injection/</guid>
      <description>&lt;p&gt;I’ve been working on a &lt;a href=&#34;https://ktor.io/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Ktor&lt;/a&gt;&#xA; api for a while now and found myself needing to make sure my routes had access to my repositories. Naturally, I sought out the advice of anyone who’s implemented &lt;a href=&#34;https://google.github.io/dagger/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Dagger&lt;/a&gt;&#xA; with Ktor. After digging for a bit, I realized that it was completely unnecessary and likely overkill. Dagger works great on Android because you are tied to the constraints of the platform and lifecycles, but with Ktor I have control of the entire scope of my application.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Controllers in Ktor</title>
      <link>https://www.bradcypert.com/controllers-in-ktor/</link>
      <pubDate>Thu, 10 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/controllers-in-ktor/</guid>
      <description>&lt;p&gt;Ktor is a microframework written in Kotlin. It’s focus is on building asynchronous servers and clients in connected systems. I’ve been using it predominantly for the “server” slice of that statement. I call Ktor a “microframework” simply because, while it’s opinionated, you have a lot of freedom in the way that you accomplish tasks within the framework.&lt;/p&gt;&#xA;&lt;p&gt;If you’d like to follow along, you can scaffold out a basic Ktor project via Intellij Idea or the &lt;a href=&#34;https://ktor.io/quickstart/generator.html&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;online tool for generating a seed project&lt;/a&gt;&#xA;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Lambda-Map Performance in Kotlin</title>
      <link>https://www.bradcypert.com/lambda-map-performance-in-kotlin/</link>
      <pubDate>Mon, 19 Nov 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/lambda-map-performance-in-kotlin/</guid>
      <description>&lt;p&gt;Working on an enterprise application written in Kotlin, I’ve recently noticed something that felt “off” to me. Perhaps you’ve seen it, perhaps you’ve written it — maybe even recently! It looks something like this (I call this a Lambda-Map):&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-kotlin&#34; data-lang=&#34;kotlin&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#ff79c6&#34;&gt;object&lt;/span&gt; &lt;span style=&#34;color:#50fa7b&#34;&gt;Demo&lt;/span&gt; {&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#ff79c6&#34;&gt;fun&lt;/span&gt; &lt;span style=&#34;color:#50fa7b&#34;&gt;main&lt;/span&gt;() {&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;       listOf(&lt;span style=&#34;color:#bd93f9&#34;&gt;1&lt;/span&gt;,&lt;span style=&#34;color:#bd93f9&#34;&gt;2&lt;/span&gt;,&lt;span style=&#34;color:#bd93f9&#34;&gt;3&lt;/span&gt;,&lt;span style=&#34;color:#bd93f9&#34;&gt;4&lt;/span&gt;).map {&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            plusOne(&lt;span style=&#34;color:#ff79c6&#34;&gt;it&lt;/span&gt;)&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        }&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    }&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#ff79c6&#34;&gt;private&lt;/span&gt; &lt;span style=&#34;color:#ff79c6&#34;&gt;fun&lt;/span&gt; &lt;span style=&#34;color:#50fa7b&#34;&gt;plusOne&lt;/span&gt;(i: Int): Int = i + &lt;span style=&#34;color:#bd93f9&#34;&gt;1&lt;/span&gt;&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;}&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Sure, this &lt;code&gt;plusOne&lt;/code&gt; function isn’t really necessary. We can just inline it in the Lambda, but imagine for just a moment that this function does much, much more than just add one to a number. It then feels just to have that code pulled out into a private function — but that’s not the offender here.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Introducing KotlinToday.com</title>
      <link>https://www.bradcypert.com/kotlintoday-com/</link>
      <pubDate>Tue, 13 Nov 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/kotlintoday-com/</guid>
      <description>&lt;p&gt;KotlinToday shut down after several years. Thank you for visiting the site for your Kotlin News.&lt;/p&gt;&#xA;&lt;p&gt;When I was learning Clojure for the first time, I had two references that I found myself reading &lt;strong&gt;every single day&lt;/strong&gt;. The first resource is a fantastic guide by &lt;a href=&#34;http://www.flyingmachinestudios.com/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Daniel Higginbotham&lt;/a&gt;&#xA; called &lt;a href=&#34;https://www.braveclojure.com/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Clojure for the Brave and True&lt;/a&gt;&#xA;. The second resource that I found myself using allowed me to immerse myself into the Clojure community and figure out where people were focusing their efforts – &lt;a href=&#34;http://planet.clojure.in/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Planet Clojure&lt;/a&gt;&#xA;. Planet Clojure is a metablog that pulls in blog posts from a vetted list of Clojure developers. In fact, you may have even seen some of my posts on there, too! Unfortunately, when I picked up Kotlin, I couldn’t seem to find a Planet Clojure for Kotlin, so I made &lt;a href=&#34;http://www.kotlintoday.com/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;KotlinToday.com&lt;/a&gt;&#xA;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Sequence: A Kotlin Type</title>
      <link>https://www.bradcypert.com/sequence-a-kotlin-type/</link>
      <pubDate>Sat, 03 Nov 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/sequence-a-kotlin-type/</guid>
      <description>&lt;p&gt;Kotlin, despite being an object oriented language, offers a ton of support for Functional paradigms. One of the most common functional paradigms involves using a combination of &lt;code&gt;map&lt;/code&gt;, &lt;code&gt;filter&lt;/code&gt;, and &lt;code&gt;reduce&lt;/code&gt; on Iterable types. However, Kotlin uses extension functions on Java Collections to create these functions in their standard library. That means that when you call &lt;code&gt;map&lt;/code&gt; on a list, you’ll return a new list. This is usually intended, however, it can become problematic when chaining multiple operations on the same list — You’ll create a ton of intermediate lists!&lt;/p&gt;</description>
    </item>
    <item>
      <title>BDD Assertions with Expekt for Kotlin</title>
      <link>https://www.bradcypert.com/bdd-assertions-expekt-kotlin/</link>
      <pubDate>Fri, 26 Oct 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/bdd-assertions-expekt-kotlin/</guid>
      <description>&lt;p&gt;Behavior-Driven Development (BDD) has became quite a popular strategy for writing tests in the past ten or so years. BDD is a style of test-writing that focuses on test cases that flow like natural English sentences. Expekt is one such library for writing JUnit assertions in Kotlin. Combining JUnit and Expekt you can achieve results like this:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#282a36;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-kotlin&#34; data-lang=&#34;kotlin&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#ff79c6&#34;&gt;class&lt;/span&gt; &lt;span style=&#34;color:#50fa7b&#34;&gt;FormatterTest&lt;/span&gt; {&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  @Test&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#ff79c6&#34;&gt;fun&lt;/span&gt; &lt;span style=&#34;color:#50fa7b&#34;&gt;shouldFormatFloatsWithADollarSignAndTwoDecimalPlaces&lt;/span&gt;() {&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#50fa7b&#34;&gt;Formatter&lt;/span&gt;.format(&lt;span style=&#34;color:#bd93f9&#34;&gt;1.2345&lt;/span&gt;).to.equal(&lt;span style=&#34;color:#f1fa8c&#34;&gt;&amp;#34;$1.23&amp;#34;&lt;/span&gt;)&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  }&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;}&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id=&#34;adding-expekt-to-your-project&#34;&gt;Adding Expekt to Your Project&lt;/h2&gt;&#xA;&lt;p&gt;As of writing, the current version of Expekt is &lt;code&gt;0.5.0&lt;/code&gt; so that’s the one we’ll include in our project. If you’re using Gradle, you can add the following to your dependency list in your build.gradle.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kotlin Sealed Classes</title>
      <link>https://www.bradcypert.com/kotlin-sealed-classes/</link>
      <pubDate>Fri, 19 Oct 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/kotlin-sealed-classes/</guid>
      <description>&lt;p&gt;Kotlin has a concept known as sealed hierarchies (several other languages implement this feature as well). In Kotlin, we can generate a sealed hierarchy through the use of sealed classes.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-are-sealed-classes&#34;&gt;What are Sealed Classes?&lt;/h2&gt;&#xA;&lt;p&gt;Sealed classes are basically an extension to an enum class. They offer similar functionality with a few key differences. Similarly:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;The class can not be instantiated directly&lt;/li&gt;&#xA;&lt;li&gt;The type can be represented as a type from a limited set, but not from any type outside of the set.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Differences however, are the important part:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Static Methods, Companion Objects, and Testing</title>
      <link>https://www.bradcypert.com/static-methods-companion-objects-and-testing/</link>
      <pubDate>Wed, 18 Jul 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/static-methods-companion-objects-and-testing/</guid>
      <description>&lt;p&gt;I’ve been working with Kotlin a ton recently, both at work and for fun. It’s a fantastic language on the JVM that combines almost all of my favorite Scala features and adds in several new features as well. If you haven’t given it a shot yet and you’re a Java reader, give it a try! You’ll love how expressive it can be and how simple and concise some of the code can be. If you’re a Scala reader, you’ll feel familiar with a lot of the syntax and ideas (Objects, replacing statics for example). One thing Kotlin does that still feels a bit weird is it promotes the use of companion objects. A companion object sits inside a class definition and houses all the &lt;code&gt;static&lt;/code&gt; methods which that class will own. Let’s convert a piece of Java code to Kotlin so you can see what I mean.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using ButterKnife with Kotlin</title>
      <link>https://www.bradcypert.com/using-butterknife-kotlin/</link>
      <pubDate>Wed, 16 May 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/using-butterknife-kotlin/</guid>
      <description>&lt;p&gt;Butterknife is a simple but fantastic tool for Android development. When this was introduced, it really simplified my thought process regarding view bindings in my activities, fragments, or view holders. As Kotlin adoption grew,&lt;a href=&#34;https://jakewharton.com/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt; Jake Wharton (creator of ButterKnife)&lt;/a&gt;&#xA; also created &lt;a href=&#34;https://github.com/JakeWharton/kotterknife&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;KotterKnife&lt;/a&gt;&#xA;, for &lt;em&gt;kotlin-esque&lt;/em&gt; view bindings. KotterKnife isn’t bad, but I prefer the annotation syntax of ButterKnife instead! Implementing ButterKnife with Kotlin has a few gotcha’s however, that may be a bit difficult to get setup with. Let’s talk through those.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
