Our vision for Kotlin is to enable the use of a single expressive, performant, strongly typed language across all components of a modern application. Kotlin 1.1 makes two major steps towards this goal.
Second, we’re introducing support for coroutines. As a lightweight alternative to threads, coroutines enable much more scalable application backends, supporting massive workloads on a single JVM instance. In addition to that, coroutines are a very expressive tool for implementing asynchronous behavior, which is important for building responsive user interfaces on all platforms.
Below we describe these two changes further. In other news: we’ve added type aliases, bound callable references, destructuring in lambdas and more. See the details in our What’s new page (check out the runnable examples!).
There’s no sense in re-inventing the wheel when you’re working on Android apps, especially if you’re just starting out. In this 360AnDev talk, we will cover a range of libraries you can include in your Android apps that will help you tackle the problems other people have already solved. Whether you’re loading data from a web API, showing & caching images, or storing & syncing data, there’s a library you can pull in to help you out!
Kotlin may seem like a new kid on the block – itʼs been officially released only in February. Its history however dates a few years back and itʼs mature and stable enough to be used for developing solid reliable applications. Therefore at Allegro we decided to give it a chance – we built our new shiny server-side system using Kotlin as its primary language and we do not regret it.
One of the first features a Kotlin developer learns is the languageʼs approach to handling
null values. It is quite interesting – especially at times like these when the most popular way of handling this problem is to use some kind of Option monad. As weʼll soon see Kotlin actually does not introduce any new special wrapper type – it uses regular Java types albeit with slight variance.
One concern that people will raise about converting to Kotlin is the number of methods added by its standard library. Thanks to massive libraries like the support library and GMS, many apps are in danger of bumping up against the Dex method limit. I used the dexcount gradle plugin to break down the method count before and after the rewrite. The end result is that the total method count after proguard decreased by 10% from 5491 to 4987 (not counting GMS or appcompat). The code count decreased by 30% from 12,371 lines of Java, to 8,564 lines of Kotlin.
With the growth of the Internet of Things, connecting Android applications to Wi-Fi enabled devices is becoming more and more common. Whether you’re building an app for a remote viewfinder, to set up a connected light bulb, or to control a quadcopter, if it’s Wi-Fi based you will need to connect to a hotspot that may not have Internet connectivity.
From Lollipop onwards the OS became a little more intelligent, allowing multiple network connections and not routing data to networks that don’t have Internet connectivity. That’s very useful for users as they don’t lose connectivity when they’re near Wi-Fis with captive portals. Data routing APIs were added for developers, so you can ensure that only the appropriate app traffic is routed over the Wi-Fi connection to the external device.
Failsafe is a lightweight, zero-dependency library for handling failures. It was designed to be as easy to use as possible, with a concise API for handling everday use cases and the flexibility to handle everything else. Failsafe features:
Supports Java 6+ though the documentation uses lambdas for simplicity.