Today, we explore the question “Where does initialization occur around the lifecycle of a view?” This is topic my teammates hotly debated over for months, so I’ve decided to see for myself. This blurb covers two ways of inflating a custom view for comparison: via layout resource and programmatically.
Space Coast, Florida has one of the world’s most unique environments in the world. The St. John’s River is one of 3 rivers in the world to flow north, and for Brevard County, the Indian River and the Banana River are estuaries, which are warm part-salt/part-fresh water bodies, giving home to unique denizens like bottlenose dolphins, pink shrimp, horseshoe crab, manatees, comb jellies, and more. Trying to keep the unique ecosystems healthy in Brevard County is a challenging responsibility to hold from giving fire to trees to preserve scrub jays, netting and protecting turtle nests, and enforcing manatee wake zones.
So you’ve aced the interview! You’re sitting in relief knowing you’ve passed the weeding process, only to get hit with perhaps one of the more difficult questions in any interview process:
How much are you looking for compensation?
Searching for jobs is nerve-wrecking by itself; I often spend so much energy trying to get through those interviews it’s hard not to freeze up from sudden context-switching. Since I’ve started working in tech, I’ve been through dozens of serious interviews in search for finding the jobs that were right for me: I’ve more than doubled my salary in just two years.
Someone probably told you that you don’t have the ability or the means to solve a problem. Someone probably told you “don’t worry about it”. Someone probably told you you can’t be the engineer you want to be.
Like many women in engineering, I got my start in my career by working a job being assigned a lot of menial, repetitive tasks. When there was too much work to handle, I turned towards automation and native desktop development to do the jobs I didn’t want to do! At first, it got me in a lot of trouble. Later on, I…
For those that haven’t heard yet, GraphQL is a hot new query language for your API. The setup between ourselves and the API team had several bumps and wild cards, but we really had a great time exploring a new framework responsible for creating a GraphQL client with Android. While it took us a while to really get going, I found that working with GraphQL on Android really feels a lot more modern and a lot less clunky in comparison to the complex network layer usually required for CRUD APIs.
Today, I’m going to talk about the benefits of using Kotlin data classes — in particular, working with them in unit testing. I’ve discovered some neat things about Kotlin data classes while rewriting
Android features, and thought I’d share insights I’ve gained through a fun example!
Note: this blurb only covers working with JUnit and Mockito for those who have yet to work with MockK.
Note: This doesn’t necessarily cover Mockito-Kotlin 2 — there are lots of changes and improvements done there that may or may not apply to nhaarman’s Mockito-Kotlin library
Unit testing is meant to test the “business logic” of your application — when these tests are run, they are executed on the development machine (host).
Writing tests in Android can seem really daunting, but it is so important for your code, especially as it grows in size and complexity! Writing solid unit tests for your classes gives you the following benefits:
At Conference for Kotliners, I spoke on TornadoFX-Suite, a barely-passible open source project intended on allowing users to upload TornadoFX project source code to the application, which would parse and analyze the subsequent code to generate simple UI tests.
I had only just revealed initial discoveries and proposals at Conference for Kotliners, but between my nerves and waiting to share these discoveries publicly, I’m pretty sure I just threw up a bunch of words in excitement.
I’d like the chance to follow up and slow down just enough to really highlight the significance of what we’ve really stumbled on with…
As much as I really love JDK 8, it’s past time to upgrade my TestFX-Suite to use JDK 11. Actually, Oracle released their latest version JDK 12 on March 19 of this year and will expect to push more frequent updates, but as TornadoFX is kept up with tender-loving care from the community in their spare time, the migration for TornadoFX to JDK 11 was a huge undertaking for us and that’s where we happen to be at.
Perhaps that will be a conversation that will need to be had in the future on our end.
In the meantime, let’s…
In an epic exploration of Kotlin, the next frontier in modern metaprogramming, we have TornadoFX-Suite, a small project that analyzes uploaded TornadoFX code which in turn detects relevant UI elements and writes UI tests.
TornadoFX-Suite works — barely. If a user looked up documentation and followed along with the instructions, then sure, TornadoFX-Suite works.
Sigh…. yeahhhhhh. It is my hopes that in the next year, this can turn into something more serious than a research project with lots of data points and growth in framework configurations. Code analysis, which is achieved through Abstract Syntax Tree parsing, will become stronger as…
software engineer and crocheting enthusiast