DEV Community: Tavon

Let's Code Flutter: 3 Useful Widgets

Tavon — Tue, 30 Mar 2021 13:21:48 +0000

There are so many Widgets, and each of them does so many things. In a lot of cases, you can think of Widgets as various upgrades to other Widgets. And the way Flutter seems to be optimized, there's no limit to how many Widgets you can apply to other Widgets. Here are three Widgets that I've been using lately to help me get my work done.

GestureDetector

Personally, this one is named slightly deceptively, but that's only because I'm coming from a pure Android development background. But this handy little widget behaves like most others: it adds behavior to its children.

In Android, to have something react to presses, you would give it an onClickListener. Simple enough, and all Views support it. Similarly in Flutter, you would instead wrap the child you want to handle these presses in a GestureDetector widget.

@override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => handleTap(),
      child: Container(),
    );
  }

You can also handle a million (Citation needed) other types of gestures.

Here's a small snippet of everything GestureDetector has to offer. As well as handling taps, I've used it to handle panning, similar to how a Slider functions.

LayoutBuilder

Sometimes you need a child widget to depend on the parent's size. During the build, this is generally not available. However, you can get what you need by wrapping the child in a LayoutBuilder widget.

@override
  Widget build(BuildContext context) {
    return Scaffold(
        body: SafeArea(
            child: Container(
                margin: EdgeInsets.all(5.0),
                child: LayoutBuilder(
                  builder: (context, BoxConstraints layout) {
                    return Container(
                      width: layout.maxWidth / 3,
                      height: layout.maxHeight / 3,
                      child: Container(),
                    );
                  },
                )
            )
        )
    );
  }

Inside a Scaffold, inside a SafeArea, inside a Container with margins, we want to act on the constraints of the space we have left. The constraints contain the minimum and maximum width and height available to us.

ValueListenableBuilder

This is a new Widget for me, and I'm still trying to figure out the best/optimal use case for it. In my original post about switching to Flutter, I list a few widgets that I assume will be your "bread and butter," making up the majority of the widgets you use. In that list I mention StreamBuilder, a Widget that takes a Stream and calls its builder every time the stream emits items.

A ValueListenableBuilder performs almost exactly the same way, except it listens to a ValueNotifier, then emits that value to its builder whenever it changes.

ValueNotifier<bool> _showEmptyView = ValueNotifier(false);

  @override
  Widget build(BuildContext context) {
    return Container(
      child: Column(
        children: [
          ValueListenableBuilder<bool>(
            valueListenable: _showEmptyView,
            builder: (context, _showEmptyView, child) {
              if (_showEmptyView) {
                return Container(
                    color: Colors.red,
                    child: ...
                );
              } else {
                return Container(
                    color: Colors.blue,
                    child: ...
                );
              }
            },
          ),
          ElevatedButton(
            onPressed: () {
              _showEmptyView.value = !_showEmptyView.value;
            },
            child: Text("Press me"),
          )
        ],
      ),
    );
  }

Depending on your layout and optimization needs, you could ignore this Widget and just call setState, updating a show/hide boolean. Or you could create a custom StatefulWidget that handles the state, which is actually what ValueListenableBuilder is.

If you have any insight into this Widget, please share!

Head on over to the Flutter official documentation for more information on these amazing widgets.

What are some Widgets you've been using lately? Let me know in the comments and help me find something new to play around with!

Let's Code Flutter: Widget Notifications!

Tavon — Tue, 16 Mar 2021 15:35:42 +0000

Working with Flutter (and therefore, Dart) has been an interesting learning experience. I'm still #TeamKotlin, but my job has a Flutter app so I needed to get acquainted with how things work. My first real learning curve came in trying to understand the BLoC pattern, coming from an MVP Android app.

I don't think I have a full grasp on that yet, so this is not that blog post.

The way I understand BLoC pattern currently, they are not actually supposed to really hold references to models. The BLoC is purely for logic. (Whoops. Vast departure from MVP.) Additionally, the original developers passed the BLoC down through multiple Widget levels — either that, or multiple Streams or Sinks. Something about this just didn't feel right. (Please correct me if I'm wrong! The BLoC pattern conflicts with everything I know. 😭)

In the process of understanding the BLoC pattern — and the sea of Streams/Sinks that I have — I learned how to send notifications up the Widget tree, and that's with... Notifications! I don't know the current Best Practice ™ for using them, sadly. But at the moment, they fit my needs.

Listening for Notifications

Quick recap: Flutter UI is just a huge tree of Widgets. You've clicked 3 pages down on a button in the center? It's a child of almost 100 Widgets at this point. Notifications serve the purpose of "bubbling up" messages from children to their ancestors.

A good example would be a built-in Notification: ScrollNotification. If you use a Scrollable Widget, and need to keep track of scrolling events, you would listen for a ScrollNotification. And as with more things in Flutter, you listen to a Notification using another Widget: NotificationListener.

var widget = Scaffold(
      body: NotificationListener<ScrollNotification>(
        onNotification: (notification) {
          //do things with the notification here
          return true;
        },
        child: Container(
          child: ...,
        ),
      ),
    );

Somewhere in that Container will be a Scrollable widget, and we want to listen for a ScrollNotification. When the notification is dispatched, this Widget will catch it and act upon it. If we want to make it available to other ancestors, simply return false;, otherwise return true to make it stop bubbling up the tree.

That's it!

Make your own Notification

Making your own custom Notification is easy.

class SomeExampleNotification extends Notification {

  final String name;

  SomeExampleNotification(this.name);
}

To make a notification you would simply extend Notification , then make the class as you see fit. You would then listen for this Notification like you would a ScrollNotification.

My Current Dilemma

At the moment, I'm facing one tiiiiny little issue, which may not be an actual issue. I've already encountered at least one instance where I want to listen to multiple Notifications, and would prefer to do them at about the same hierarchy as each other in the tree. However, NotificationListener only allows listening to one type of Notification, meaning I end up with nested NotificationListeners.

NotificationListener<OneNotification>(
          onNotification: (notification) {
            // do things
            return true;
          },
          child: NotificationListener<TwoNotification>(
            onNotification: (notification) {
              // do more things
              return true;
            },
            child: Container(child: ...)

This seems weird to me, but outside of wrapping the two notifications in another (or just making one with different types), I can't see a better way of doing this.

If you have any ideas of how to better address this, let me know in the comments! Help me out! lol

Let's Code Flutter: Animations!

Tavon — Tue, 09 Mar 2021 23:06:08 +0000

In Android, we can typically do very simple animations by setting animateLayoutChanges to true in the ViewGroup of our layout's XML. It's been my tried and true method for a long time now. Anything more advanced than maybe changes to how a Dialog or Activity is shown has caused headaches that ended up not being worth the trouble.

Therefore I haven't done a lot with animations, and am envious of those who have accomplished more.

While sprucing up my job's Flutter app, I wanted to make an expandable/collapsable area to show and hide some content. The user would click a button, and it would drop down revealing more of the information that was peeking through.

That's when I discovered the simplicity of Flutter animations.

Maybe it's like this in Android, too, and I've just been woefully ignorant of them. I know there's something about a ValueAnimator, but... eh, it's not as simple as this!

Widget _buildCollapsableWidget() {
        var expandedWidget = _makeExpandedWidget();
        var collapsedWidget = _makeCollapsedWidget();
    return Container(
      child: AnimatedCrossFade(
        alignment: Alignment.center,
        crossFadeState: _isExpanded ? CrossFadeState.showFirst : CrossFadeState.showSecond,
        duration: Duration(milliseconds: animationDuration),
        firstChild: expandedWidget,
        secondChild: collapsedWidget,
        sizeCurve: Curves.linearToEaseOut,
      ),
    );
  }

Using AnimatedCrossFade, I have accomplished what I was looking for: a smooth open and close animation. And it's easily customizable!

When the user presses a button, I updated _isExpanded. I use a ValueNotifier for this (something else I learned about) but setState should work just as well.

There's a gajillion different Curves to use; the one I have selected starts off in a very straight, then curves out to slow down towards the end of the animation. You can look at a video of the Curve here. (Sidenote: I love the Flutter docs.)

That's... honestly it. It's super simple. I added a similar animation to the button the user presses, switching between an Up caret and a Down one, however for that I use an AnimatedSwitcher.

// Other code here
return AnimatedSwitcher(
    duration: Duration(milliseconds: 600),
    transitionBuilder: (Widget child, Animation<double> animation) {
      return ScaleTransition(child: child, scale: animation);
    },
  child: _caretWidget,
  switchInCurve: Curves.bounceOut,
);

I'm trying to find more and more excuses to throw in an animation: they're so simple, and provide just a bit of extra polish. It makes the app feel a bit more alive and modern.

Flutter offers a ton of easy-to-use animated Widgets, as well as a bunch of ready-to-use Transitions. Above, I used the ScaleTransition, but there are ones for Size, Rotation, and even Position. The AnimatedWidget docs page provides details on these.

Have you had a chance to use Flutter animations yet? If so, what've you built with it? Show me what you've made and help inspire everyone!

Let's Code Flutter: Making the switch

Tavon — Tue, 23 Feb 2021 17:36:57 +0000

After learning Android development, I knew that native code — Java, now Kotlin — would be the way I would proceed going forward. I'd heard of all the cross-platform options but they never sounded good to me. I always felt as if they were subpar options; the apps I'd seen with them always "looked" like they came from cross-platform code (whatever that means).

Basically, I was super judgey.

There's always been a need for them, though. One problem I continuously faced because I only did native Android code was that if I ever thought of a business opportunity or side project, I would only be able to do the Android code. If I wanted to potentially offer an iOS app, I'd have to either learn to do it by hand or hire someone else.

But I stuck to my guns and never went through with any ideas that came to mind.

At my job, I ended up being the only mobile developer in house. We have an iOS contractor who takes care of our two primary iOS apps, and I take care of the Android apps. We eventually acquired another company, one that had an Android and iOS app.

But it was written with Flutter.

"Well, f***."

I'm an eager learner, honestly. I started dabbling in Python some years back because it worked for AWS and it's been my rando language of choice since then. I don't really "know it" but I know enough to get by.

So I dived in to learn Dart and what I could do with Flutter.

Why was I so stubborn!?

I think Dart and Flutter are easy to learn, but there's definitely a learning curve. One of the first things I had to learn was how to build out a screen.

Building a layout

My thoughts on Flutter's layouts have changed since I was first introduced. In the beginning, I was a bit confused but learned how to just deal. I considered it just one of those things in a programming language that doesn't need a true explanation. Just learn it that way and move on.

However now that I've spent more time with it (and Android has announced Compose), I see Flutter's layout a bit differently. I used to think they were drastically different from the XML layouts used in android.

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:background="@android:color/white">

    <TextView
        android:id="@+id/hello_world"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
                android:layout_gravity="center"
        android:text="Hello World!"/>

</LinearLayout>

In a basic layout, we'd have our main ViewGroup, something like a LinearLayout or — my favorite default — a ConstraintLayout. To show "Hello World!" we throw in a TextView and tell it to be centered within the view. Done.

When I learned how to do this in Flutter, I was puzzled. This was some weird nested hierarchy that was done in Dart. They aren't separate files!?

In flutter, I have to return a Widget in a build function. In that function, I deeply nest my Widgets in some strange hierarchy where each Widget is a child of another, and I apply certain configurations to each to change how to look and are positioned.

Oh, wait. It's exactly like XML.

@override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.white,
      alignment: Alignment.center,
      child: Text("Hello !"),
    );
  }

That's it, technically. I can make it more complex by adding a Scaffold and a SafeArea, but this is honestly pretty simple. In fact, it's arguably simpler than the XML.

When you first create your Flutter project in Android Studio, they give you an amazing starting layout, which includes a Scaffold. Without looking up the definition, I'm going to do my best to explain what that is.

A Scaffold in Flutter is that basic UI layout that has the possibility to have a toolbar at the top, with bottom navigation and a floating action button. You could probably do without and make it all yourself. That's actually what I tend to do in Android layouts, adding what I need and aligning it properly in a ConstraintLayout. In Flutter, the Scaffold probably the best way to go about it. And it's super easy!

@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headline4,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }

One thing that still takes some getting used to is that you don't really use Strings all "willy nilly" like I'm used to everywhere else. In Flutter, you almost always wrap them in a Text widget. In fact, most widgets that have a place for text only require a Widget.

This means that you can do some crazy things, all out of the box. For example, in the AppBar, the title parameter in Android would probably be a generic String. In Flutter, however, it takes just a Widget. Text is a Widget, but so is Container... or another SCAFFOLD!

Please don't put another Scaffold there.

But this means that if I wanted to add a subtitle, I can customize the way the title is shown, adding a Column (another Widget) with room for them both. Or perhaps I want just an image there. The possibilities are pretty much endless.

Again, please don't put another Scaffold there.

Your main arsenal

There's a million Widgets out there, but here are the ones I use constantly for my layouts.

Text

For all your String needs. You can style them by adding a TextStyle to it.

Row & Column

They are the literal building blocks of tables. If you're at all familiar with HTML, these two are used the same. (I think? The last time I really built a website was when Pokemon was new and Pokemon websites dominated the internet.) Rows are horizontal, Columns and vertical. Both take a list of Widgets, including other Rows and Columns if you need them.

Visibility

This was a weird one to learn about. In Android, Views have a visibility value that can be set. In Flutter, that wasn't there. But you can wrap them in a Visibility widget and set the flag accordingly.

Center

Similar to Visibility, this was a bit of a learning curve.

MenuItem

This might be due to the way my company's app is set up, but I use this little thing everywhere. Icon to the left, title, with a potential subtitle should I need it? EASY.

StreamBuilder

Sigh. I won't go in depth on this Widget in this blog post, but I both LOVE this Widget and hate it. I'm new to the BLoC pattern, where Sinks and Streams are used heavily, and this thing relies on Streams. I'm going to eventually write up my thoughts on the BLoC pattern and how to best utilize it, but until then the Flutter website has an amazing page on this Widget.

That's all I'm going to get into today. Nothing too specific. I really just wanted to get the people who've been on the fence about trying it. Try it. It's super easy and opens the doors for so many possibilities.

I'm still a diehard Android native guy, though. lol

Let's Code Kotlin: Goodbye Builders, Hello Data Classes

Tavon — Mon, 08 Feb 2021 16:05:12 +0000

If it wasn't for auto-generation, I can't say I'd be a good programmer. Back when Java was my sole language used for Android apps, manually writing each and every getter and setter would have been the bane of my existence, and eventually my downfall. Potentially constructors, too. Android Studio luckily can generate them all for me, which is why I'm still alive today.

When I switched to Kotlin, I was amazed. So many things I had been creating for years with ~~too~~ so* many lines of code were now being reduced to a small handful for the necessities.

I've mentioned before about my love for this Kotlin feature, but it deserves its own post: Let's talk about Data Classes.

The Java Way

In Java, you need to be verbose.

class Pizza {

    private Dough dough;
    private Sauce sauce;
    private Cheese cheese;
    private List<Topping> toppings = new ArrayList<>();

    private Pizza(Dough dough, Sauce sauce, Cheese cheese, List<Topping> toppings) {
        this.dough = dough;
        this.sauce = sauce;
        this.cheese = cheese;
        this.toppings = toppings;
    }

    static class Builder {
        private Dough dough;
        private Sauce sauce;
        private Cheese cheese;
        private List<Topping> toppings = new ArrayList<>();

        public Builder() {

        }

        public Builder(Pizza pizza) {
            this.dough = pizza.dough;
            this.sauce = pizza.sauce;
            this.cheese = pizza.cheese;
            this.toppings = pizza.toppings;
        }

        public Builder setDough(Dough dough) {
            this.dough = dough;
            return this;
        }

        public Builder setSauce(Sauce sauce) {
            this.sauce = sauce;
            return this;
        }

        public Builder setCheese(Cheese cheese) {
            this.cheese = cheese;
            return this;
        }

        public Builder setToppings(List<Topping> toppings) {
            this.toppings = toppings;
            return this;
        }

        public Pizza build() {
            return new Pizza(dough, sauce, cheese, toppings);
        }
    }

}

I never want to see that type of code again in my life. To build a pizza, we would do this:

Pizza newOrder = new Pizza.Builder()
                .setDough(Dough.HAND_TOSSED)
                .setSauce(Sauce.EXTRA_NORMAL)
                .setCheese(Cheese.MOZZARELLA)
                .setToppings(Arrays.asList(Topping.BACON, Topping.JALEPENOS))
                .build();

All of that work to get something, admittedly, pretty. I can't really argue with the results: the builder pattern produces some nice looking code. It's been worth it in the past, but the amount of boilerplate code has always frustrated me.

If I wanted to add one more configuration to it — let's say we split up toppings to be Meats and Vegetables — then I have to:

Change private List<Topping> toppings = new ArrayList<>(); in the class to reflect the split
Change the private constructor to handle the split
Duplicate the toppings split in the Builder
Remove setToppings() in the builder
Add two more sets to the builder to handle meats and vegetables.

Heaven forbid I want to add uncookedToppings to the configuration.

It's entirely too much and my brain hurts just thinking about it.

The Kotlin Way

In Kotlin, there's a much simpler way to handle builders: not having one at all.

data class Pizza(val dough: Dough,
                  val sauce: Sauce,
                  val cheese: Cheese,
                  val toppings: List<Topping>) {
}

That entire Java class gets reduced to 5 lines; it could be 1 but this how I like to format my classes.

The code to make a pizza now turns into this:

val newOrder = Pizza(
                Dough.HAND_TOSSED, 
                Sauce.EXTRA_NORMAL, 
                Cheese.MOZZARELLA, 
                listOf(Topping.BACON, Topping.JALEPENOS)
)

Again, this could all end up on one line, but this is how I format my object initializations if three or more parameters being provided.

To be fair, you can do this in Java as well by removing the builder and allowing you to use the public constructor. And for simple cases, sure, that could be fine. But then if you have defaults for each value, you'd probably end up in a case where you have a million constructors letting you configure the pizza however you want: just set the dough and cheese, or just the sauce and dough. At this point, the Builder provides you with more flexibility by allowing you to set the defaults there, and if they aren't provided with one of the setters, it'll fallback to the default.

But then we're back to using the Builder, and that's where my frustration comes in.

In Kotlin, you can provide the default value, too:

data class Pizza(val dough: Dough = Dough.NORMAL,
                  val sauce: Sauce = Sauce.NORMAL,
                  val cheese: Cheese = Cheese.MOZZARELLA,
                  val toppings: List<Topping> = listOf()) {
}

This is your standard pizza: regular dough, regular sauce, mozzarella cheese, and no toppings.

val defaultPizza = Pizza()

Our plain cheese pizza is a simple Pizza().

Extra cheese? We can set just that.

val extraCheese = Pizza(cheese = Cheese.EXTRA_MOZZARELLA)

Hand-tossed with mushrooms? Easy, and you can call the toppings first then the dough, using Kotlin's Named Arguments.

val handTossedMushroom = Pizza(toppings = listOf(Topping.MUSHROOMS), dough = Dough.HAND_TOSSED)

.copy

As an added bonus of data classes, they have a built-in .copy() method. In our Java example, we had to manually make a separate constructor that took in an old Pizza and set the values it held into our new builder, allowing us to change them.

Pizza updatedOrder = new Pizza.Builder(newOrder)
                .setCheese(Cheese.EXTRA_MOZZARELLA)
                .build();

In Kotlin, however, it's all baked in. (You get it? Baked? lol) And with the help of Named Arguments, you can only change the values you want to change.

val updatedOrder = newOrder.copy(cheese = Cheese.EXTRA_MOZZARELLA)

Data classes are absolutely amazing. For more information on them, visit the official documentation.

Anyone else love data classes as much as me? Leave a comment below and let me know how your life is better because of them. 😉

Learn In Public

Tavon — Mon, 01 Feb 2021 16:14:30 +0000

I have this nagging voice in my head that says, "No. You shouldn't do that. It's either already been done or no one will care."

It has stopped me from doing personal projects and blog posts, and gives me this feeling of it doesn't matter. This bleeds over into my personal life as well; I have an issue sharing things with my partner if I don't think he cares about them, and I treat my friends and family the same way.

But I've seen this phrase too many times recently for this not to be a sign of some sort.

Storytime: Exactly One Result

It's past 10am on a Monday and I normally have my blog posts fully fleshed out, edited, and ready to post days before. I have my posts scheduled to release at 9am, and I post them on my social medias after I check in with work.

But I have nothing for this week — literally this week that this post is released. That voice keeps whispering, "Nah." There's plenty of topics to write about in my notes, even a few attempts at starting them. But I just keep hearing, "Nah." Either it's been done or I don't feel confident enough in the topic yet to try to be a "voice." This is what usually precludes the end of my blog — it happened last year, and countless other times before.

I decide to throw myself into work. Maybe I'll run across something I can quickly write about and go on with my day. Some obscure Kotlin or Android thing that I can spell out in about 600 words.

I work as an Android developer at a startup in D.C. I'm currently restoring an old feature that was in the app some years ago, but removed because it was just not done well and usage was low. I've been working on it for almost a week now and today I'm getting my bearings on where I left off on Friday. I was building the flow to create a new inventory. Perfect. I run the app and encounter an error: my dependency injection library — Dagger — has apparently failed to autogenerate the code for my new screens, so I can't check what they look like on a device yet. I perform a clean, rebuild, and invalidate the cache and restart the IDE — things that typically fix 90% of the issues with libraries that auto-generate code.

Nothing works.

So, I run to Google. "DaggerAppComponent is not abstract and does not" is what I search, hoping for something. But, of course, I can't find anything that is even close to what is happening to me. I decide to make sure I have properly exhausted this query's results, and I do it again with quotations: "DaggerAppComponent is not abstract and does not". Avid searchers will know that I'm now looking for this exact phrase. It doesn't always help: almost no one has the exact same error message, but I was hopeful because I did not name "DaggerAppComponent."

I get exactly 1 result.

Solving obscure problems typically takes at least a few search results, combining Method #1 from the second result, Method #7 from that first one, and then shaking — not stirring — as suggested by someone on Twitter. "Perfect," I say sarcastically. "This isn't going to be helpful."

I click the result and jump directly to the answer, ready to make another failed attempt at searching.

The answer is very simple. I put my NewMeetingComponent into a package named "new". I forgot that in terms of java it's not a valid package name. Either Android Studio hadn't shown a warning or I had discarded it for some reason.

Well... ****.

Remember, I was in the process of building a flow to create a new inventory. So, I also named my package new. The thought had crossed my mind briefly, but I ignored it; I expected a warning or something if that was the case.

I change the package name and hit run. Everything works now.

Then I leave a comment, cementing that, while not spelled out verbatim, I'm taking this as a sign:

Just a reminder to everyone: even if you think it's obscure, every bit of "learning in public" helps.

Let this be your sign, too.

Learn in public.

It's worth it.

Someone will care. Someone does care.

Fun fact! I wanted to get a picture of the error to use as a preview image for this post. I switched the package back to new – or, at least I tried to. NOW all of a sudden there's errors and warnings: "'new' is not a valid package"

Everything happens for a reason, yeah? Someone must have needed this post as much as me.

Let's Code Kotlin: Scoped Functions (let, apply, also, run)

Tavon — Mon, 25 Jan 2021 17:34:07 +0000

Kotlin offers a lot of tools to help make coding easier and simpler. At first glance, though, they can be a bit overwhelming and the exact usages of each can be confusing. I'm going to do my best to break down let, apply, also, and run.

The primary differences between these four extension functions boil down to two things: the way the context object is referenced inside of the scope (this vs it), and the return value of the lambda. That's it.

`.let { }`

This is one of two scope extension functions that I use regularly. I mentioned in a previous post that I typically use let for null checks, performing some extra work on the context if the object is not null. Inside the scope, the context object is referred to as it.

val dateCompleted = book.dateCompletedTimestamp?.let {
            convertToDateString(it)
        }

It can also serve as a way of mapping one value to another, as .let returns the lambda result (whatever is the last line of the lambda). For instance, in our example, convertToDateString will turn that timestamp into a String. Since it's on the last line of the lambda, it will become the value of dateCompleted. If .dateCompletedTimestamp was null, then dateCompleted would be null as well.

`.apply { }`

apply is another useful extension function that performs the exact opposite of let: the context object is referred to as this and the same object is returned. I typically use apply when initially creating an object. You could similarly just build your object as a data class or with a Builder, but for those that you can't or don't have control over this works beautifully.

fun createBookUpdatePayload(dateCompleted: Long, bookId: String, rating: Int): JsonObject {
    return JsonObject().apply {
        addProperty("date_completed", message)
        addProperty("book_id", bookId)
        addProperty("rating", rating)
    }
}

`.also { }`

This one, according to the docs, seems to have a very limited "official" usage: it seems to be used primarily for logging within a chain. I believe I've used it similarly a few times. If you've used it another way, leave a comment so we all can get a better understanding of what .also can do. .also refers to its context object as it and it returns the object it references.

fun getLastCompletedBook(): Book {
        return allBooks
                .filter { it.dateCompletedTimestamp != null }
                .also { println("Number of books read: ${it.size}") }
                .sortedByDescending { it.dateCompletedTimestamp }
                .first()
                .also { println("Last completed book: ${it.name}") }
}

`.run { }`

I'm going to be honest: I don't think I've used this one. Its context object is referred to as this and it returns the last line of the lambda. I also can't think of a reason to use this over something else. But there are still recommendations for it in the official documentation. It's supposed to be a cross between .let and .apply.

If I had to shove this into my fictional book app, here's how I'd do it:

fun postReadingUpdateToTwitter(bookId: Long, currentPage: Int): Complete {
    return bookService.run {
        val result = postUpdate(bookId, currentPage)
        if (result == Result.OK) {
                Completable.complete()
        } else {
                Completeable.error("Update error")
        }
    }
}

Interestingly enough, you can also use run as just a scope lambda. Meaning, without using it as an extension function.

val book = run {
    val bookName = "How to use Run"
    val bookId = 4815162342

    Book(name = bookName, dateCompletedTimestamp = null, bookId = bookId)
}

addBookToShelf(book)

My advice: skip this one. But if you've got a good example, let me know in the comments.

Bonus: `with`

There's also apparently another non-extension scope function named with. You instead pass the object into it, and use it like you would .apply.

with(allBooks) {
    forEach { book ->
        println("Title: ${book.title}")
    }
}

val lastCompletedBook = with(books) {
  val filtered = filter { it.dateCompletedTimestamp != null }
  val sorted = filtered.sortedByDescending { it.dateCompletedTimestamp }
  sorted.first()
}

As with the non-extension run, I might skip this. But I'm sure I can find a use for it somewhere. Though, at that point, I'd probably just make a separate function and call that.

Recap!

.let → Context object is it; returns the lambda result
.apply → Context object is this; returns the object
.run → Context object is this; returns the lambda result
.also → Context object is it; returns the object

And two non-extension functions:
run → no context object; returns the lambda result
with → pass in the context object, use with this; returns the lambda result

Whew. That's a lot but it's worth learning about them. Don't overuse them; it can be easy to throw everything into a scoped lambda, but if it hurts readability I would revert to a more verbose solution. There's plenty of official documentation on them if you need more insight. Have some fun with them though and let me know what you create with them!

Let's Code Kotlin: For & While

Tavon — Tue, 19 Jan 2021 16:04:17 +0000

Last week I went over If, Else, And When. This week I explore two more pieces of Kotlin syntax. Lucky for us, they are almost equivalent to their Java counterparts: For and While. The latter may seem new, but you'll come to find that it's an old concept with a new name.

For

You can loop through a collection in Kotlin similar to how you can in Java.

for (spell in spellbook) {
    print("${spell.name}")
}

If you don't need anything more advanced, this will work for you just fine in many cases without any added complexity. Actually, you can perform this version of looping in another way by making use of a convenient extension function on Collection: forEach.

spellbook.forEach {
    print("${it.name}")
}

spellbook.forEach { spell ->
    print("${spell.name}")
}

In the first example, it is the default name for each item in the collection. The second example shows you how to rename it to something a bit more specific.

Looping through a range of numbers is a bit different. You may be used to writing for (int i = 0; i < 10, i++). That's not a complex thing to write, but it's much simpler in Kotlin.

for (i in 0..10) {
    // this will loop, from 0 to 12, inclusive.
}

Despite being simpler, however, I find that I almost never loop through things like this. In Java, it was customary to start at 0, go until the size of the list, incrementing by one each time. In the code block of that for loop, I'd make a variable for the item at the given index. I've abandoned this method in Kotlin. I think I've used it maybe once; I find myself using the .forEach extension method more.

It's worth noting that ranges can get complex. They're not too difficult and open up some possibilities that could be useful, like looping from ten to zero but only going through the even indices. Again, I don't loop through ranges anymore, but it's interesting to see how this differs from its Java implementation.

for (i in 10 downTo 0 step 2) {
    // this will loop from 10 to 0, but only the event numbers, inclusive
}

You can find more documentation on For loops on the official Kotlin page (and also the page about Ranges).

While

For the sake of completion, while and do while are pretty much exactly like they are in Java.

while (x > 10) {
    x += 2
}

do {
    update()
) while (x != 3)

Short and simple! Check out my other posts and stay tuned for more Kotlin tips!

Let's Code Kotlin: If, Else, When

Tavon — Mon, 11 Jan 2021 18:31:35 +0000

Kotlin was an easy language to switch to, with a very small learning curve. Most of it looks similar to it's Java counterpart, yet somehow easier. To go along with the other posts I have about switching from Java to Kotlin, today I'll go over a few basics just to make sure it's clear how easy the switch is: ifs, elses, and whens.

If & Else

Overall, Ifs and Elses don't change much. Outside of leaving off semicolons, you can use your knowledge of Java to watch if-else statements.

‌

if (makeIntimidationCheck() >= DC)
    // intimidation success code

‌
‌

var proficiencyBonus: Int

if (level >= 17) {
    proficiencyBonus = 6
} else if (level >= 13) {
    proficiencyBonus = 5
} else if (level >= 9) {
    proficiencyBonus = 4
} else if (level >= 5) {
    proficiencyBonus = 3
} else {
    proficiencyBonus = 2
}

‌
It's worth noting that there is no ternary operator in Kotlin, meaning you can't do var value = isSomething ? valueOne : valueTwo. That kinda makes me sad (I like the aesthetic, sue me), but an if-else can handle it just fine the same way.

‌

var charismaSkillBonus = 3

var intimidationBonus = if (isProficientInIntimidation) proficiencyBonus + charismaSkillBonus else charismaSkillBonus

‌
‌

var intimidationBonus = if (isProficientInIntimidation) {
    // other stuff
    proficiencyBonus + charismaSkillBonus
} else {
    // other stuff
    charismaSkillBonus
}

‌

When

In Java (and many other languages), you can use a Switch statement. In Kotlin, it's called when. Let's turn that previous example about proficiencyBonus into a much better when:

‌

var proficiencyBonus = when (level) {
    1, 2, 3, 4 -> 2
    5, 6, 7, 8 -> 3
    9, 10, 11, 12 -> 4
    13, 14, 15, 16 -> 5
    17, 18, 19, 20 -> 6
}

‌
Eh, okay, that's probably not the best. Luckily, in my example, level can only be a number from 1 to 20. But, knowing this, when can modify that a bit, showing some of the complexities that a when can handle.

‌

var proficiencyBonus = when (level) {
    in 1..4 -> 2
    in 5..8 -> 3
    in 9..12 -> 4
    in 13..16 -> 5
    in 17..20 -> 6
}

‌
Awesome! Much better, I think.

A when can also serve as a more direct replacement for an if-else chain. If you remove the argument, you can do whatever you want.

‌

var proficiencyBonus = when {
    level >= 17 -> 6
    level >= 13 -> 5
    level >= 9 -> 4
    level >= 5 -> 3
    else -> 2
}

‌
‌---
‌
There is some official Kotlin documentation that goes into a bit more depth on these things and more. Check it out and let me know in the comments or on Twitter (@GatlingXYZ) if you have any questions or want me to flesh anything out a bit more. The next post in my "Let's Code" series for Kotlin will be about Fors and Whiles, so stay tuned!

#MakeTheChangePt2: Kotlin Properties

Tavon — Mon, 24 Feb 2020 13:05:05 +0000

There aren't many differences between Java and Kotlin, making it a great language to switch to if you already know the former. There's a small learning curve, sure, but that's true for switching to any language. There will always be small things that trip you up repeatedly until you get used to them.

One thing to get used to is the difference in the way Kotlin declares properties.

In my original draft of this post, I tried to say something like, "There's only one way to declare a variable in Java." And then I started typing and... no, it's just as complex as it is in Kotlin, they're just done differently. I say all that to say: don't let the unfamiliarity catch you by surprise.

Declaring Properties

If you're coming from Java, you've probably been declaring variables like this:

String anotherString = "Hey!"

@Nullable String aDefinitelyNullableString;
@NonNull String aDefinitelyWontBeNullString = ""

final String aFinalString = "Ye shall not pass!"

We have the lawless variable first, the one where we're unsure of whether the value will be null or not later on. This is followed by some that clearly labeled, showing whether or not they can contain a null value and lastly one that has a value that definitely will not change. Pretty simple.

In Kotlin, some different assumptions are made, a lot for the sake of Null Safety.

var mutablev1: String = "CAN be changed"
var mutablev2 = "CAN be changed"

val immutablev1: String = "Can't be changed"
val immutablev2 = "Can't be changed"

There are two things to tackle here. First, it's all non-null by default. You have to go "out of your way" to make a value nullable. (I'll show you how in the next section.) Secondly, there are two new keywords we have to be aware of: var and val. var means that the value can be changed in the future and val means it can not be, as if you made a final variable in Java.

Liquid error: internal

Kotlin Null Safety

?

If you want to go "out of your way" to make a value nullable, you simply add a ? to the end of the property type.

var nullableMutable: String? = null

After you mark something as nullable, you'll get plenty of warnings within your code that you should be checking if that value is null before being used.

!!

Similarly, if you have a nullable property that at some point later on you know is going to be not-null for whatever reason, you can tell you code that you are 100% confident in its non-nullness by adding !!. For example:

private var importantCustomer: Customer? = null

fun getCustomerOrder(): Order? {    
    return orderService.getOrderForCustomer(importantCustomer!!)
}

.let

Let's say you're not 100% sure, though. importantCustomer could be null, right? You can either wrap getCustomerOrder() in a null check, or you can wrap the return. Or...

private var importantCustomer: Customer? = null

fun getCustomerOrder(): Order? {
    return importantCustomer?.let {
        orderService.getOrderForCustomer(it)
    }
}

I use the let extension function pretty often. It's essentially the same thing as adding a null check. In Java, it would look like this:

@Nullable Order getCustomerOrder() {
    return importantCustomer != null ? orderService.getCustomerOrder(importantCustomer) : null;
}

And while I don't think Kotlin has a "pretty" ternary operator like Java does, it does allow you to do similar things based on null responses.

private var importantCustomer: Customer? = null

fun getCustomerOrder(): Order {
    return importantCustomer?.let {
        orderService.getOrderForCustomer(it)
    } ?: Order.BLANK_ORDER
}

lateinit

In Java, you can annotate a variable with @NonNull and you can be sure the compiler will let you know that it's supposed to be non-null and will remind you that you need to initialize it. But there's no way to say, "Hey, this can't be null but I don't feel like setting it right now. I'll get to it later, I promise."

In Kotlin, you can!

lateinit var customerId: String

fun functionOne() {
    if (customerId == null) {
        //  Doesn't matter
    }
}

fun functionTwo() {
    customerId = "4815162342"
    if (customerId 3 == null) {
        // Doesn't matter. 
        // Can't be null. 
        // You should get a lint warning about this.
    }
}

If I were to run this code, calling functionOne() first causes the app to crash. customerId hasn't been set yet. But by setting it first in functionTwo(), it works. And now you can call functionOne() because it knows what customerId is now.

Liquid error: internal

lazy

You've seen that piece of code in Java before, the getter that checks to see if the variable is null first. If it is, it sets it, then just returns that variable.

int sloth;

private String getSloth() {
    if (sloth == null) {
        sloth = getRandomNumber() * 12;
    }
    return sloth; 
}

In Kotlin, the same concept exists, more or less, in the keyword lazy:

val sloth: Int by lazy {
    getRandomNumber() * 12
}

fun getTheSloth() {
    Timber.d("Got the sloth: $sloth")
    Timber.d("Just checking it again: $sloth")
}

I'm going to be honest: I realized while typing this up that I've been using lazy wrong for a whiiiiile. The example above has the way it probably should be used. What I always did was val sloth = lazy { } That's not wrong per se, however it returns a Lazy object; you would need to do sloth.value to get the value, but it also comes with sloth.isInitialized(). The method above actually gives you back the value so you can use it normally. Use whichever method works best for you.

Liquid error: internal

Wrap Up

That's all I can cram in this week. This should cover the bases for switching from Java to Kotlin, yes? If you have any specific questions, let me know in the comments below, or you can reach me on Twitter @gatlingxyz.

This post originally appeared on my blog, Gatling.XYZ. You can check
out the original post here and maybe you'll find something else you like, too.

#MakeTheChange: From Java to Kotlin

Tavon — Mon, 17 Feb 2020 13:34:36 +0000

So, you've decided to watch From Justin to Kelly?

Oh, wait. That's next week's post. Sorry. Wibbly wobbly. -Reads correct script- Ahem.

So, you've decided to switch from Java to Kotlin?

Switching from one programming language to another can feel intimidating and daunting. There's so many new things to learn, so many things that look similar but have a change that trip you up, and just so many surprises. As an Android developer, we had to weigh our options: did we want to switch to Kotlin just because it was new and shiny, or was there some benefit? Could it wait? Is there a way to try out just a little bit?

Automatic Java to Kotlin conversion

Android Studio came prepared with a solution once Kotlin was adopted as an officially supported language for Android apps. By clicking Code -> Convert Java File to Kotlin File, Android Studio will perform some basic transformation of Java to Kotlin for you. I personally think that's the best place to start if you're trying out Kotlin for the first time. Take a small class you know and understand well and convert it, looking over the changes and similarities. Be warned, Android Studio doesn't always do it the best way, but it's more than enough to get started with.

public class MainActivity extends Activity {

    @Override  
    protected void onCreate(@Nullable Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.id.activity_main);  
    }

}

class MainActivity: Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  
        setContentView(R.layout.activity_main)  
    }

}

From this quick example of a basic Activity, you can see that... not much is different. In Kotlin, everything is public by default, so we can leave that word out. extends (and implements) is transformed into a simple :. The @Override annotation is shifted to just become override and in line with the function name.

For me, the biggest change is that parameters and their types have shifted positions. Bundle savedInstanceState is now savedInstanceState: Bundle? (the question mark just means that it's Nullable). Also, lines don't end in semicolons, but you can add them if you want and it will still compile!

Data Classes

One of my favorite types of classes in Kotlin is Data classes. Here's a regular class in Java, with a constructor, getters, and setters.

public class YourObject {

    private String title;
    private int count;
    private @Nullable  String description;
    private boolean isActive = true;

    public YourObject(String title, int count, @Nullable String description, boolean isActive) {
        this.title = title;
        this.count = count;
        this.description = description;
        this.isActive = isActive;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public int getCount() {
        return count;
    }

    public void setCount(int count) {
        this.count = count;
    }

    @Nullable
    public String getDescription() {
        return description;
    }

    public void setDescription(@Nullable String description) {
        this.description = description;
    }

    public boolean isActive() {
        return isActive;
    }

    public void setActive(boolean active) {
        isActive = active;
    }
}

This, my friend, is why I love Data classes:

data class YourObject(var title: String, var count: Int, var description: String?, var isActive: Boolean = true)

DO YOU SEE THIS?!

Kotlin doesn't really do getters and setters (but then they do but it's... nevermind); it prefers property access syntax (that's what Android Studio calls it; pretty much, it wants you to use the variables directly). Data classes are also why I've moved away from builders. I feel as if named parameters fulfill the same purpose. Here's an example:

val item = YourObject(  
    title = "A Year In Love",  
    count = 525600,  
    description = "How do you measure a year in the life?"  
)

Using our Data class from before, we can create an instance of that class using named parameters. Everything feels neat and orderly. You can do them in any order (if you use the naming syntax, otherwise you have to do them in order). Your parameters that have default values aren't required (in constructors and methods).

Also, bonus love for data classes: they come with a .copy() method.

val aCopy = item.copy(description = null, 
                        title = "A Copy With No Description")

Interfaces and Abstract Classes

Interfaces

Interfaces and Abstract classes function relatively the same and even look very similar. There are some small benefits on the Kotlin side, though.

public interface TestInterface {  
    void someInterfaceMethod();  
    String howAboutAnother(String someParam);  
}

interface TestInterface {
    fun someInterfaceMethod()
    fun howAboutAnother(someParam: String): String

    fun forFunsies() {
        //  Some default implementation
    }
}

The Kotlin example behaves the same, however, you can do something special with them, blurring the line between Interface and Abstract class so please use it wisely! In Kotlin interfaces, you can have non-required, default implementations of functions.

Abstract Class

There's less difference between a Java Abstract class and a Kotlin one, though there is one thing to note. Before I get into that, here's an example of an Abstract class in Java, with a class extending it:

abstract class AbstractJavaClass {

    abstract void someMethod();

    final void anotherMethod() {
        //default implementation  
        //this method can NOT be overriden, 'cause it's final
    }

    void yetAnotherMethod() {
        //default implementation  
        //this method CAN be overriden
    }

}

class ImplementationJavaClass extends AbstractJavaClass {
    @Override
    void someMethod() {
        //you're forced to implement this method

        anotherMethod();
        yetAnotherMethod();
    }

    // You can NOT override "anotherMethod" 

    @Override
    void yetAnotherMethod() {
        super.yetAnotherMethod();
        // you have the option of overriding this one, though
    }


}

Similarly, here is an Abstract class in Kotlin with an associated extending class:

abstract class AbstractClass {  

    abstract fun someMethod()  

    fun anotherMethod() {  
        //default implementation  
        //this method can NOT be overriden  
    }  

    open fun yetAnotherMethod() {  
        //default implementation  
        //this method CAN be overriden  
    }  

}  

class Testing(): AbstractClass() {  

    override fun someMethod() {  
        //you're forced to implement this method  

        anotherMethod()  
        yetAnotherMethod()  
    }  

    // You can NOT override "anotherMethod"  

    override fun yetAnotherMethod() {  
        super.yetAnotherMethod()  
        // you have the option of overriding this one, though  
    }  

}

You'll notice in my Java example I explicitly labeled a method as final. I did this to show the similarity in Kotlin: in Kotlin, all functions are final by default. The same is true for Classes as well. To make them non-final, you need to add open before it. (An open class would start off as open class ClassName)

Interoperability: Use Java and Kotlin together!

If you want to get started with Kotlin, dive right in! You can use Kotlin inside your existing Java applications and files, and existing Java inside your Kotlin files.

At my current company, there's been a slow conversion of Java to Kotlin, and a good 80%-90% of our main Android application is now in Kotlin. And I dread having to dredge through the untamed Java territory. But I know that when I do get to the lawless West of Java-land, I can still use a lot of my Kotlin code. Even my extensions!

I name my extensions classes in Kotlin based on the class I'm extending. For instance, if I was adding an extension to the Throwable class, I would make a file called ThrowableExtensions.kt. And, while I can't use the extension exactly like I would in Kotlin, if I need it in Java it's available to me in an automatically-generated class called ThrowableExtensionsKt, and I can access my extension function statically, passing in the object I would be acting on.

... that sounds confusing. 😂 Here's an example:

# in a file called ThrowableExtensions

fun Throwable.log() {
    /// my extension code
}

public void someErrorMethod(Throwable throwable) {
    ThrowableExtensionsKt.log(throwable)
}

For the full code of my Throwable extension (and other useful ones!), visit my previous blog post on five super-useful Kotlin extensions I use every day.

#MakeItBetter: My Everyday Kotlin Extension Functions

Tavon ・ Feb 10 '20 ・ 4 min read

#kotlin #android #discuss

... And one* more thing

* = Actually, there's way more than one more thing.

Kotlin has a lot of different tricks up its sleeves, like val vs var (and even vs lateinit var). There are lazy variables, too! Oh, and classes can have Companions! But this post has gone on long enough. If there's something about Kotlin you'd like me to go over, let me know in the comments below or on Twitter @gatlingxyz .

This post originally appeared on my blog, Gatling.XYZ. You can check
out the original post here and maybe you'll find something else you like, too.

#MakeItBetter: My Everyday Kotlin Extension Functions

Tavon — Mon, 10 Feb 2020 16:03:34 +0000

This post originally appeared on my blog, Gatling.XYZ. You can check
out the original post here and maybe you'll find something else you like, too.
👨🏾‍💻 And now, without further ado...

Once I tried Kotlin, I was hooked. There is just so much to it that I can't live without anymore, one of which being Kotlin Extension Functions, or just Extensions. If you're unfamiliar with Kotlin, Extensions are a way to add more methods (and even properties) to another class without actually modifying that class. This is useful in the case of wanting to add additional functionality to a third-party library you don't have access to. I've come up with a few that have been invaluable to me, and I use them every day.

1. View.show()


fun View.show(show: Boolean) {
    this.visibility = if (show) View.VISIBLE else View.GONE
}

My codebase is set up with MVP and I frequently make calls to my view to show and hide progress spinners when I make API calls. In my View, I can quickly show or hide a view: progressSpinner.show(true)

Tada! I rarely use View.INVISIBLE so there's no need to attempt to handle that case; if I were to need it, I'd specifically code for that scenario when it arises.

2. Throwable.log()


fun Throwable.log() {
    if (this !is SocketTimeoutException && this !is UnknownHostException && this !is HttpException) {
        Timber.e(this, this.message)
        Crashlytics.logException(this)
    }
}

As part of RxKotlin, when I subscribe to an API call I supply it with two consumers: one for success (this::onGetDataSuccess()) and another for error/failure (this::onGetDataFailure()). The error consumers must take a Throwable parameter, and the very first line of that function is normally the same for me. Here's a quick example of what an error consumer looks like for me:


private fun onGetDataFailure(throwable: Throwable) {
    throwable.log()
    // one two skip a few...
}

And now my Throwable has been logged to my loggers of choice with one simple line.

3. LocalDate.toEpochMili() && LocalDateTime.toEpochMili()


fun LocalDate.toEpochMilli(zoneId: ZoneId = ZoneId.systemDefault()): Long {

    return this.atStartOfDay().atZone(zoneId).toInstant().toEpochMilli()

}

fun LocalDateTime.toEpochMilli(zoneId: ZoneId org.threeten.bp.ZoneId.systemDefault()): Long {
    return this.atZone(zoneId).toInstant().toEpochMilli()
}

We use LocalDate and LocalDateTime in our application (the Threeten version, not the standard, but this could presumably work with that as well), and it amazed me that there wasn't a simple way to turn that object into milliseconds. Before these extensions, things were not pretty. But now? Easy peasy.

Bonus: Here is its lesser-used cousin, Long?.toLocalDateTime():


fun Long?.toLocalDateTime(zoneId: ZoneId? = ZoneId.systemDefault()): LocalDateTime? {
    if (this == null) {
        return null
    } else {
        return Instant.ofEpochMilli(this).atZone(zoneId).toLocalDateTime()
    }
}

And to get a LocalDate from this LocalDateTime, call .toLocalDate() on the LocalDateTime object.

4. T?.orNull()


fun <T> T?.orNull() = listOf(null, this).random()

I know what you're thinking. "Why?????" First, I'll start by saying I only use this one in my unit tests. When I'm making an object and stuffing it with random data, sometimes that data can be null in the real world. So, when I make my Fakers (just an Object class with a method that creates a "fake" version of a real object using random variables), I sometimes set up a variable to return null instead of an actual value. Here's a quick example:


object class SomeDataFaker {

    fun basic() = SomeData(
        name = Randomizer.name(),
        text = Randomizer.sentence().orNull(),
        moreData = MoreDataFaker().basic().orNull()
    )

}

The name must not be null, but the other two can be, and my code should be able to handle any oddities should either of those come back null. If I need to handle specific cases I make sure to set the variable to have a value or null, but when I just need some data that could be anything, throwing some nulls in there gives me some peace of mind that the code will be able to handle them.

How to make your own

Making an Extension Function is easy. You can make them private for a given class, or public for your entire application to use. When I make my Extentions, I make them in an appropriately named file specific(-ish) to whatever class I'm extending. This makes it easier to find when I have to bravely go into legacy code territory that's still in Java. Here's a quick example:

# in a file called ClassImExtendingExtensions.kt

fun ClassImExtending.functionName(someParam: String) {
    // "this" refers to the instance of ClassImExtending
    // You can do all kinds of things here, as you've seen above.

    this.existingVariable = someParam
}

Are there any custom extension functions you use regularly,? Any tips on improving mine? Let me know by leaving a comment or contacting me on Twitter @gatlingxyz.

DEV Community: Tavon

Let's Code Flutter: 3 Useful Widgets

GestureDetector

LayoutBuilder

ValueListenableBuilder

Let's Code Flutter: Widget Notifications!

Listening for Notifications

Make your own Notification

My Current Dilemma

Let's Code Flutter: Animations!

Let's Code Flutter: Making the switch

Building a layout

Your main arsenal

Text

Row & Column

Visibility

Center

MenuItem

StreamBuilder

Let's Code Kotlin: Goodbye Builders, Hello Data Classes

The Java Way

The Kotlin Way

.copy

Learn In Public

Storytime: Exactly One Result

Let's Code Kotlin: Scoped Functions (let, apply, also, run)

.let { }

.apply { }

.also { }

.run { }

Bonus: with

Recap!

Let's Code Kotlin: For & While

For

While

Let's Code Kotlin: If, Else, When

If & Else

When

#MakeTheChangePt2: Kotlin Properties

Declaring Properties

Kotlin Null Safety

?

!!

.let

lateinit

lazy

Wrap Up

#MakeTheChange: From Java to Kotlin

Automatic Java to Kotlin conversion

Data Classes

Interfaces and Abstract Classes

Interfaces

Abstract Class

Interoperability: Use Java and Kotlin together!

#MakeItBetter: My Everyday Kotlin Extension Functions

Tavon ・ Feb 10 '20 ・ 4 min read

... And one* more thing

#MakeItBetter: My Everyday Kotlin Extension Functions

1. View.show()

2. Throwable.log()

3. LocalDate.toEpochMili() && LocalDateTime.toEpochMili()

4. T?.orNull()

How to make your own

`.let { }`

`.apply { }`

`.also { }`

`.run { }`

Bonus: `with`