The release of Kotlin 1.1 brings many welcome improvements to the language: val properties with custom getters can take full advantage of type inference and inlining; they introduced the T.also { it -> } extension method, which is to T.apply {} what T.let { it -> } is to T.run {}; and data classes can inherit from interfaces and base classes, just to name a few. But the two biggest changes are full support for JavaScript as a compilation target (possibly a huge deal, if you’re a full stack dev and reluctantly work with JavaScript), and coroutines(!!!).
If you’re like me, you’ve grudgingly put up with Java for years, for the sake of getting things done on Android. With Kotlin picking up steam as a viable, modern alternative, things are looking much better for all of us. Whenever possible, I do all my Android work in Kotlin.
To reap the fullest benefits of Kotlin, though, we can’t just fall back on old habits; it’s very easy to write code in a familiar Java style. In fact, allowing this was a design goal of Kotlin, to make it easier to transition between languages. But the real power and beauty of Kotlin is where it differs from Java, sometimes drastically. Let’s take a look at some examples of code patterns I’ve run across in production code, and different ways we can improve upon them.
Spread the good word, friend:
The gist is, if you pair your phone with the watch from the Bluetooth settings screen instead of the Wear app, the watch will happily connect and try to update/sync, but your phone will never figure out that they’re connected. The first walk-through I read indicated this was how you were supposed to do it, but current versions don’t support this flow. Either this was inaccurate, or an update broke compatibility.
So to save yourself the grief I went through of having to FACTORY RESET YOUR WATCH SO YOU CAN RE-PAIR IT (!!!), make sure you enable Bluetooth in the phone settings, and you can see the watch, but don’t pair with it from there! Do it from the Wear app.
Full, accurate (if spartan) instructions can be found from Google: https://support.google.com/androidwear/answer/6056630?hl=en
Spread the good word, friend:
Fellow nerd and game developer Alex Ferbrache (@AlexFerbrache) asked Andy Nguyen (@pixelatedpost) at San Diego’s Pocketwatch Games (@pocketwatchg) to file LEADtoFIRE bugs in the form of interweb click-bait headlines. The results are magical and speak for themselves.
My current favorites: “Once you see this GIF you’ll realize units have spawned wrong this whole time!” and “When I was losing a match I thought it couldn’t get any worse. Then something amazing happened.”
Alex says he regrets the dark magic he’s unleashed upon the world. I say, bring it on! You can follow the original posts and discussion threads here and here.
Spread the good word, friend:
Just over two weeks ago I released :Firth pre-alpha1 into the wild. It had progressed to the point where it was starting to be able to do what I’d intended it for–implement small DSLs with relatively little code. It was fairly small, simple, and fast, in the grand scheme of things. Writing code in :Firth was a joy, the syntax was clean and easy to understand, and I was generally happy with what I’d built. So I cut a release, made a little announcement, and waited to see what people thought.
Their feedback? The response was overwhelmingly positive. I did get some technical notes and observations, though: it’s too big, too complicated, and it’s totally incomprehensible.
Ouch. Confusion about how it works and how to read the code is mostly a a cultural issue. To Forth veterans, the REPL with the “ok” prompt should be perfectly mundane and familiar. The idiosyncratic : colon definition syntax ; and reverse-polish notation take some getting used to, but they aren’t especially difficult except insofar as they’re so different from pretty much all mainstream languages.
Spread the good word, friend:
So what is :Firth? It’s a programming language. It’s a compiler-interpreter implemented (currently) in Lua. It’s performant, portable, embeddable, stack-based, extensible, and self-modifying. It’s free and open source. It’s more of a compiler construction toolkit for defining DSLs, than a programming language as we normally think about them.
What :Firth definitely is not is FORTH. I describe it as Forth-like, because it shares many idioms and mechanisms with Forth. ANS Forth is definitely the #1 influence on the design of the language and implementation thereof. But, I’ve diverged from that starting place, sometimes dramatically. These differences emerge when I just want to get something working as fast as possible, when I decide to do things differently for technical reasons or personal preference, or when I just can’t be chuffed to look up how Forth does something (or DPANS is too opaque for a relative outsider).
Spread the good word, friend:
Some of you may have noticed that AndroidStudio really wants you to develop for Lollipop–so much so that if you try to create a new project for any of the 4.x versions, it will be broken out of the box. Now, I’m not sure how widespread this problem is, so as a disclaimer, I’ll say I have this problem every time, with the most up-to-date version of AndroidStudio from the Beta channel, on my machine. Here’s some relevant system configuration data:
- Mac OS X 10.8.5
- AndroidStudio 1.1.0
- javac 1.6.0_65
- Android SDK Build Tools 21.1.2 (with a few older versions still installed)
AndroidStudio 1.1.0
Spread the good word, friend:
Welcome to part three of my series on creating cool looking shaders of the not-quite-night-vision-but-still-looks-pretty-good variety. You can go check out part 1 or part 2 if you missed either of those. Go ahead, I’ll wait…
Hi again! Let’s jump right in, shall we? This time, we’re going to put a little effort into maintaining the overall energy-per-pixel to the greatest extent that is convenient and easy. After all, we are pretty damn lazy. Adjusting the contrast will skew things, but the main point is that full-color, gray, and green modes should otherwise all look approximately as bright as each other.
Spread the good word, friend:
Welcome back! This is part two of my series detailing the step-by-step creation of a night-vision-style fragment shader. You can check out part one here if you haven’t yet. We’ll be building on the code from previous article, but it’s not very complicated at this point.
Let’s add some code to crank up the contrast. As an added bonus, we’ll add a flag to pick green or grayscale rendering, to give us some options when defining the look of our games.
Spread the good word, friend:
Lately, I’ve been intrigued by shaders that emulate other visual effects and certain camera technologies. I’ve been considering doing a night vision kinda thing for my current project for quite some time, but I’ve been feeling kinda ambivalent about the whole thing. Recently, I got Zombie Gunship from the Humble Mobile Bundle, and they do the effect very impressively.
This got me thinking, what would it take to implement something like this? The primary requirement, other than looking badass, would be that I don’t have to re-author any graphics assets. I’d want all my geometry and textures to just work. Because I am lazy. The secondary requirement would be that the shader code should be as simple as I can make it, again because I am lazy (but also for efficiency’s sake).
