Android Kotlin Tips For Beginners

Austin Humes

While the Android team here at MJD had heard of Kotlin before and began to dabble in it, it wasn’t until we attended AnDevCon Boston 2016 that we became more familiar with it and started thinking about using it in a production project. A few weeks ago we started our first Kotlin app for a client. As with picking up any new language, there was a bit of a learning curve. If you’re new to Kotlin and are considering using it in one of your projects, here’s some things I wish I would have known that will hopefully help you

Prepare to Dig Around.

The Kotlin official documentation is amazing, and there’s a great Kotlin/Android introduction on that recently came out, but there is not much out there for specific questions you may have about working with Kotlin in Android. This can be pretty frustrating when you just want to create something that you have done hundreds of times in Java, but can’t figure out how it works in Kotlin, and the few examples you come across online don’t quite apply to your situation. One example I can think of where this happened for me was in hooking up a RecyclerView to a custom adapter and item click listener.

Convert Java File to Kotlin File = Life Saver.

While trudging through a situation like the RecyclerView/custom adapter, sometimes I just bit the bullet and wrote everything in Java, then used the “Convert Java File to Kotlin File” functionality in Android Studio (under the Code menu). This is a really helpful tool to see how something could be done in Kotlin. I say could because as we’ll see, there is more than one way to write something in Kotlin.

The most time consuming part of working with Kotlin is getting used to the things that will save you time.

Kotlin is a very concise language, allowing you to achieve the same result with less code, especially boilerplate code. Because of that, I found myself writing code that seemed to be the same length as Java code, and then later slimming it down to take advantage of Kotlin’s strengths. For example, there is no more wrapping a statement in a null check:

If (someThing != null) {

Turns into:


What is that question mark doing there you ask? Another cool, but initially strange thing to wrap your mind around about Kotlin is how NULL is handled. Kotlin uses “nullable” and “non-null” variable types. When a variable is created and set to null, you have to put a “?” after it, and when you access that variable later, you use the “?” after it (a “nullable” variable). The variable’s property or method won’t be called if the variable is null, which avoids a NullPointerException.

There is also a “!!” operator, which is usually referred to as the “bang bang” operator (ie someThing!!.length). It’s used when you say there’s no way the variable can be null (you guessed it, a “non-null” variable). This is one place where there can actually be a NPE in Kotlin if that variable actually is NULL. There really doesn’t seem to be much benefit in using non-null objects, at least none that I’ve come across yet. Even the Kotlin docs don’t seem to like it that much: “The third option is for NPE-lovers…Thus, if you want an NPE, you can have it, but you have to ask for it explicitly, and it does not appear out of the blue”. That’s not to say that you won’t come across them, sometimes you will have to for example if an API call returns an object marked as non-null. But if you’ve initialized an object with a value, it’s safe to use !!.

Another example of how Kotlin streamlines code, by inference:

fun sum(a: Int, b: Int): Int {
   return a + b

Can be rewritten as:

fun sum(a: Int, b: Int) = a + b

That three line function turned into one because the Int return type is inferred by the result of a+b.

Object expressions and declarations are something you’ll see a lot that will be good to be familiar with ( Object expressions are similar to Java’s anonymous inner classes, and object declarations are Kotlin’s singletons.

Kotlin’s Lambda expressions ( are also convenient to use but can take a bit to understand. Take this example:

val sum: (Int, Int) -> Int = { x, y -> x + y }

This looks like it could get hairy, but all it’s doing is declaring a variable ‘sum’ that takes two Integers, adds them together, and returns the total as an Integer. Then you would just use sum(1, 2). Pretty cool huh? And then to slim it down even more, you could use inference to modify sum to be:

val sum = { x: Int, y: Int -> x + y }

Speaking of Lambdas, take a look at this code example of Kotlin in an Android fragment:

mViewClose.setOnClickListener { fragmentManager.popBackStack() }

private val settingsClickListener = { view: View ->

val settingName = (view.findViewWithTag(resources.getString(R.string.setting_name_tag)) as TextView).text

  val intent = Intent()

  intent.action = Intent.ACTION_VIEW

  when (settingName) {

      resources.getString(R.string.facebook) -> {

 = Uri.parse(resources.getString(R.string.facebook_app_link))

          openSocialLink(intent, resources.getString(R.string.facebook_site_link))


      resources.getString(R.string.twitter) -> {

 = Uri.parse(resources.getString(R.string.twitter_app_link))

          openSocialLink(intent, resources.getString(R.string.twitter_site_link))



      else -> Toast.makeText(view.context, "clicked " + settingName, Toast.LENGTH_SHORT).show()



You may notice that the first setOnClickListener has a statement in curly braces, while the second and third have parenthesis. The first is creating an inline function statement that acts as the OnClickListener’s action. The next two are using a reference to the val settingsClickListener. settingsClickListener is creating a Lambda expression as it’s value, but you’ll notice it’s also using a View. What’s that all about? Because we’re creating an OnClickListener which takes a View as a parameter, we declare an object named “view” of type View, which is passed into the function. We are then able to use the view object in our function.

Kotlin’s custom getters and setters are pretty slick and convenient. Let’s look at an example of a custom getter:

val hasCookies: Boolean
    get() = mCookieManager?.cookieStore.cookies.filter { it.domain == mDomain && !it.hasExpired() } .size > 0

There’s a whole lot of Kotlin going on in that statement, which at first may look confusing but is a great example of how Kotlin can condense your code (Special thanks to my teammate Brigham Toskin for providing that example!). First, we’re declaring a boolean value hasCookies. We also have a custom getter. A check is done on the cookie manager’s cookies list, and is running a filter that checks if the domain matches and the expiration date hasn’t occurred. If it finds any cookies in the list that match the criteria, then hasCookies is set to TRUE. Why is this done as a custom getter versus just a statement? As a custom getter, anytime hasCookies is accessed, the get() is called and the current state of the cookies is checked instead of just when it was declared.

So Far So Good (for the most part)

After working with Kotlin the past few weeks, I’ve definitely had my ups and downs with it. I can definitely see the potential of how it can lead to smaller code and quicker development time. Also, Kotlin is a lot more similar to Swift, so if necessary our iOS team can jump in and follow along if they need to, and eventually vice versa. The hardest part of acclimating to it is just getting used to the syntax and conventions since it’s different from Java’s syntax and conventions. Sometimes it feels like you’re trying to read hieroglyphics because there’s so much going on in not a lot of code, with unfamiliar symbols and keywords, where Java feels like things are more spelled out. But like anything, it takes time and focus to understand it.

All in all, I am glad our team here at MJD decided to try out Kotlin on a project. I think Kotlin has a great future in Android development, and now that we have this experience under our belt I’m confident our future Kotlin projects will be even more efficient.

Interested in more content like this? We publish everything on LinkedIn, all you have to do is follow us by clicking below!

A Better Way to Deliver Digital Products

Eric Soto

Our work at MJD Interactive is fast paced. We deliver digital experiences that have an impact on large audiences for well-known brands. We are entrusted with a brand’s reputation and are expected to succeed every single time. We juggle projects, requirements, dates and budgets to make sure we provide the best experience for our partners. However, we also are expected to wow them, delivering impactful solutions that go beyond what everyone thought possible and that few others would be able to deliver!

Amidst all this organized chaos, we have a not-so-secret weapon that we consistently wield to succeed. The secret is the Agile Methodology.

There are many flavors of Agile, but Scrum is the most popular, so that’s our focus for this article.

Agile/Scrum (or Scrum, for short), is a liberating management style for teams that has revolutionized how we create digital projects. Initially, a methodology employed for software engineering, the Agile method can be used for many projects due to its simplicity.

Though this is not a complete definition of Scrum, at its core, a Scrum Team has no manager, and no one is assigned work. Instead, in a Scrum Team (which usually consists of 4-7 people), members look at a prioritized backlog and collaboratively pick the work they know they can deliver in a calendar period called a Sprint, which is usually two weeks.

The Backlog is the responsibility of the Product Owner, who also sets the priorities for the tasks in the backlog. Officially, the backlog defines the requirements for the project but is generally not all encompassing. Think of the backlog as “what” is being built in the short term, but most definitely not the “how” it is built, nor is it everything that will be built. The backlog generally has enough work to keep the team busy for several sprints, but one of the key concepts of Scrum is that the team does not wait for a full backlog before they can begin to work.

The Scrum Team also has a Scrum Master, who is the person responsible for ensuring the smooth operation of the team. Notice how the Scrum Master is not a team leader nor a manager of the team’s work. The Scrum Master is a facilitator of the process because the team members and the product owner collaboratively decide how and when the team tackles product features. Yes, the team follows the prioritized backlog, but any team member can bring up anything at any time for discussion. It is not uncommon in projects for the backlog to contain many items that the team members themselves bring up, and that the product owner accepts and prioritizes into the mix.

Contrast this with the classic Waterfall Model of project management, where teams of experts might spend months carefully defining what a project’s requirements might be. They might spend so much time in this endeavor that by the time there is a finished specification, some of the requirements might not even be valid due to changing business, environment and competitive forces. Even worse, if some of the later requirements depend on early decisions, the entire requirements document might be obsolete or based on incorrect assumptions. For this reason, we could think of the Waterfall Model as the House-of-Cards model. A card at the bottom of the structure (a changing requirement) might topple the entire structure.

Finally, in the classic Waterfall Model, there is no product to see for a long time. It might be months or more before a product owner gets to see a hint of the product being built. By the time the business starts to see the product, it is often too late to make any meaningful changes, again contributing to the high failure rate of classic projects.

In an Agile project, the product owner (and the business) generally start to see results even after the first or second Sprint (in weeks, not months). Furthermore, the entire team (and the business) can see early on how features might really work and can quickly adjust. More importantly, we are accountable as a team.

Note, Agile teams are not “the wild west,” and they do indeed follow established patterns and practices in an organization. Just because the team is empowered to make decisions for the implementation of a project does not mean they act in a vacuum. It is very common for organizations that have central architecture groups to provide at least one member of an agile team.

Many read this and immediately think “there’s no way this works.” We can attest to the fact that it does indeed work, and very well. Furthermore, it works not just for the team members, but also for product owners, stakeholders and the people using the digital product or experience.

Imagine “seeing” progress every two weeks? What is more tangible than seeing results, regularly and consistently? Imagine delivering new features to your customers regularly (maybe once a month or more)? Then contrast that with a project where a year goes by before a new version is ready for customers – and when it is, has a much larger potential to cause disruption and anxiety (because generally, the product changed so much since the last product iteration.)

By the way, we are not alone! See the ‘State of Scrum Report 2015’ where nearly 5,000 respondents, on average, felt that Scrum is successful 62% of the time! And if a Project Management Organization (PMO) was involved, success rates jumped to over 90%. Wow!

Plus, thousands of companies create and maintain projects this way. You generally can tell who they are because they are always updating their software or product (imagine that!)

Have you noticed that your Facebook app updates, more or less every two weeks? Now you know why.

Interestingly enough, Agile is not a new concept and has been written about extensively. See Agile: The World’s Most Popular Innovation Engine and countless other articles that have been published in the last few years.

As with any concept, there are those that don’t agree with the praises of Agile.

I’ve heard folks say that Agile is an excuse for teams to avoid deadlines or engage in proper planning. These could not be farther from the truth, of course. Once you understand what Agile is, you know that Agile does indeed provide for planning (lots of it and regularly actually) as well as deadlines (every two weeks). Sure, you might not spend months in planning at the beginning of a project, but we’ve presented how that’s actually a good thing because you are planning all the time in Agile and can, therefore, learn from early small mistakes and make your digital product better. And sure, you might not deliver every single product iteration to end-customers, but you bet you’ll be delivering many more when you are incrementally producing an iteration every Sprint.

I’m not saying Agile is perfect. There are plenty of ways to screw up any project (Agile or not). What I am saying, though, is that in our practice and in what we’ve seen with others, Agile projects have a higher likelihood of producing solid results, cost-effectively and with less risk than the classic waterfall model.

To me, Scrum is second nature. To me, Agile is how you build projects. To me, Agile/Scrum is liberating and empowering, and I am apprehensive to participate in projects using a non-agile process. Honestly, working with an organization now that does not follow an Agile practice makes me question the organization and whether or not I want to be involved with them. (I wonder how successful they are. Judgmental? Absolutely! When you’ve “seen” better, it’s hard not to be judgmental.)

However, I can personally attest to the fact that Agile/Scrum has brought back joy and self-fulfillment to my projects. I’ve seen this in myself as well as my teammates who feel that they are now part of something, not just an extra hand on a project.

I can also attest to many happy clients that also feel like they participate in projects and are in full control of the process at every step. Contrast with the classic model where you give someone your requirements, they go away for three months, then come back with something that is nowhere near what you thought it would be.

If you are a leader, non-technical manager, product owner, marketing manager, C-level executive, etc., I recommend you start with ‘The Scrum Guide.’ It’s a short read, so don’t delay. Then, share this with your technical team. Getting this knowledge will allow you to support them and encourage them to move in this direction. Make it clear this is the direction you want to go in (because some Engineering teams can be stubborn about ‘a new thing.’) Also, review Introducing An Agile Process to an Organization and follow some of the ideas.

What’s in it for you? How about seeing “your product” improve every two weeks? No, you might not ship it to clients every two weeks, but YOU (and your stakeholders) will see progress, quickly, regularly. How’s that for accountability and measuring ROI?

If you are a Software Engineer, Developer, Project Team Member (or an Engineering Manager, Team Manager) you must immediately become familiar with Scrum. It will change your life (and your teammate’s lives) – believe me! Start with The Scrum Guide. It’s not very long and it’s easy to understand. Then, perhaps try How To Implement Scrum in 10 Easy Steps.

Then, JUST DO IT. Sure, you might need some buy-in from the business, but I’ve seen where Engineering teams can start moving in the direction of Scrum on their own initiative. The point is: saying “we’ll do this one day” won’t change anything. You have to start one-day, so “one-day” might as well be today!

If you hire outside resources or outsource your project development, start with The Scrum Guide but then ask your partner company about their Agile process and what role you will be playing. You should likely be the Product Owner, but if you are also contributing team members, they too need to participate in the Agile ceremonies and processes. In some cases, you also might want to provide the Scrum Master as well (even better if that person is in your PMO.)

One important consideration is that as Product Owner, you retain a critical role but it is one that comes with great responsibility considering your ongoing attention will be needed. Whereas in a waterfall project, you might work hard initially to create requirements then hand them off to a team, in an Agile project, you’ll be participating on an ongoing basis. The work might even be a little more considering you are factoring in changes and unknown factors, but it is spread throughout the life of the project as opposed to front-loaded. However, the potential for success is also much higher (and easily makes up for the extra work) since you will be able to make adjustments very quickly when compared to a classic project.

With technology moving as fast as it does these days, every organization engaged in digital projects, that wants to stay competitive and relevant, has to take a serious look at Agile. The consideration is no longer if to adopt Agile, but rather why are you not already using this method of project management.

Consider this: if internal motivation is not enough, it is very likely that your competition is already using an Agile methodology and also likely that they are outperforming you – every two weeks!

This article is by no means a full and complete definition of Agile/Scrum. For the full definition, please visit or Google “Agile Scrum Methodology.”

What Does a Digital Innovation Agency Do? A Story Mom & Dad Would Understand.

What Does a Digital Innovation Agency Do? A Story Mom & Dad Would Understand.

I love my parents. That’s them up there in the header with my daughter. We live a couple thousand miles apart, but that doesn’t stop us from talking a couple times every week. That has led to thousands of conversations over the last decade about the digital agency I help run. My mom and dad still do not know what the heck I do every day.

A couple of weeks ago I was hanging out with some friends from work and we were asked what we do by some folks at the local watering hole. We went on and on about how we work at a digital innovation agency called MJD, how we build cool digital products and experiences, that we do UX, design, and software engineering, etc. Our very polite new friends nodded as their eyes glazed over, not really understanding what we were talking about. Realizing this, I got to thinking: Why not write a post that explains how we have evolved into the digital agency we are today in terms anyone can understand? My mom and dad could read it and know that their hard earned money that put me through college actually did some good!

First Things First

Just like there are lots of different kinds of doctors (“ear nose and throat”, “family practitioner”, “cardiologist”), there are lots of different kinds of digital agencies. You’ll hear terms like “full service”, “digital marketing”, “paid media”, “SEO”, “social networking”, and many others. I’ll only explain the kind of digital agency that MJD has become over the past ten years: digital innovation through products and experiences. So this post is not going to cover a good half of what a digital agency could do, or even why we need to have the word digital in it, but it will help my parents understand what I do, help explain more why we call ourselves a digital innovation agency and what MJD specializes in.


In short, MJD is a new type of digital agency that makes the digital products and experiences that people use and interact with every day. There’s no shortage of digital things that could be made, but what resonates with us are those that enhance the human experience. A delightful interaction at a theme park that fills a child with wonder? An immersive adventure in a retail space that spurs the imagination? That’s us. A sterile workflow tool for tracking cog production in some soul-stealing enterprise hell? Not so much.

Life’s too short to churn out another banner marketing campaign that interrupts people in their daily routines; we’ll leave that to the folks that enjoy that sort of thing. What we do is unleash our technical and creative expertise on problems where digital can make a difference in people’s lives. Sure, the solutions we come up with may include mobile (iOS/Android) applications, custom software, or augmented reality—just as a soufflé includes flour, eggs, and butter. Ultimately, we seek to create something greater than the mere ingredients.

We’re a new type of digital agency that helps clients understand how digital interacts with the physical world around us.

Industry Jargon: UX

When we build a digital product or experience, our goal is to create something that enhances the real world around us, not just interrupt us to sell something. For instance, we built a mobile application for Viper that allows people to turn on their cars with a watch. (Dad, it’s kind of like Kit from Knight Rider.) We built a mobile app and website for Disney Imagineering that made their Haunted Mansion attraction come alive online, on your phone with augmented reality, and in the park with a personalized ghost story.

Our job as a new type of digital agency is to make sure that the digital layers we are adding onto these physical environments are simple and beautiful. The experience could be many things—fun, inspirational, thought provoking, educational, functional—but it is our job to make sure it’s worthwhile and valuable for those using it. There are lots of digital experiences that suck. Banner ads come to mind. Or anything that uses Papyrus font. We strive to build the opposite of “suck”.

So, how do we arrive at this understanding of what’s valuable to the user?

First, we seek to see the world from their perspective—to empathize with the folks that we’ll be building for. Through some fancy-sounding activities (“field research”, “empathy mapping”, “contextual inquiry”) we gain a meaningful understanding of what the user thinks, feels, and wants, as well as the context in which they’re doing their thing. Really, this boils down to talking with them. Asking questions, observing, listening and deeply identifying with their views. We can then take what we’ve learned through dialogue and create a way to think about who they are (“personas”).

From here, we begin to marry what we know about the user with what our clients are looking to achieve from a business perspective. Now, you could take a concept, design it all out, build out every screen, and say “okay, here’s what we think we heard the user say”, but that’s a (very) expensive way to do things. Instead, we go light and lean and sketch out our ideas—sometimes literally on paper (“prototyping”). We take these sketches and present them to test users, get their feedback, and iterate. This screen doesn’t make sense? How do I get from here to here? Okay—let’s whip out a new sketch. In this way, fixing issues and streamlining interactions can be done in minutes instead of months, which makes everybody happy. This (“user testing”) is one of the most fun parts of what we do. We get to spring new ideas on unsuspecting folks to see what they like, what they hate, or worst of all, are just kinda “meh” about.

Our goal is to only build digital products that people will find useful. There’s simply no point in spending time and money building something people won’t use.

We’re a modern digital agency that designs digital products and experiences that are beautiful, simple, useful and innovative.

Industry Jargon: Human-Centered Design

There is so much noise around us. We aim to create peace amid the digital chaos of the modern world. We do this by designing intuitive interfaces that a person won’t have to figure out in order to use. The UX process above enables us to remove all the extraneous stuff and identify the essential. From here we innovate.

Design innovation can take two paths: evolution and revolution. Apple didn’t design the first digital phone interface, but with iOS, they evolved what already existed into the best version yet seen. On the other hand, when Chuck Hull designed the first 3D printer in 1983 it was the revolution of an entire industry. Never heard of Chuck Hull? That’s because evolutionary design (Apple) is usually easier and a lot more profitable than revolutionary design. Creating entirely new industries is really hard work.

Here are some examples: Qualcomm Ventures required a site that provided easy access to information, with a forward-thinking interface that demonstrated their position in the market. We evolved the established conventions of the modern business website to create a progressive experience that highlights their investments and expertise.

For Stride Rite, we built a revolutionary shoe sizing iPad app for kids and parents. Kids no longer have to endure the cold metal of the Brannock sizing device on bare piggies. Instead, parents can just take out their tablet, aim it at their feet, and BAM! you have a foot size. This had never been done in the industry, and it created a disruption.

We’re a new breed of digital agency that builds products rather than doing marketing or advertising.

Industry Jargon: Engineering and Development

This one might not be as obvious as it sounds. It is easy to talk about building products, but rather difficult to actually do. Turns out, there’s actual science in Computer Science. Thankfully, a whole lot of smart people have developed ways to not only build great things but build them efficiently and reliably. We can quickly get in the weeds talking about how things are built (“test-driven development”, “pair programming”, “decoupled architecture”, “software development life cycle”), or what’s used to build them (“message broker”, “data store”, “Xcode”, “Kotlin”, “noSQL”), but nevermind all that. The important takeaway is that we are grateful to be able to stand on the shoulders of technology giants and produce things that are—essentially—magic.

And just like the construction and manufacturing industries that fueled economic growth when mom and dad were growing up, it’s digital products that fuel today’s growth. Instead of steel, heavy machinery, concrete, and glass, our version of the Industrial Revolution involves software, mobile apps, websites, virtual and augmented reality and data. Unlike past economies, our products have the opportunity to benefit humanity faster, and at a larger scale than ever possible. Digital products can open borders, spread ideas, enable economic prosperity, entertain, and profoundly impact our daily lives.

While that’s a few too many words for mom and dad on a phone call, it boils down to this: Through hard work, we figure out people’s needs and our client’s goals, bring them alive with crazy and fun ideation, and get our digital products and experiences in people’s hands. And that is a pretty fun thing to tell the parents.