In Part 1 I demonstrated how we can use
AndroidView to render traditional Views inside our Compose UI. For this part, we are now going to make newly created Compose UI components work inside traditional Views and Layouts with another special class,
Note: Just like in part 1, I am not going to deep dive into Jetpack Compose and I do assume you have some basic knowledge of how to use Compose. However, it should be fairly easy to follow along without knowing too much.
You are probably wondering why would anyone want to put Compose UI into older…
Like most Android developers following the development of Jetpack Compose you are probably wondering if you will need to rewrite your views or your entire app from the ground up. Well, it turns out, you might not have to, in fact, just like the days when we were all beginning to adopt Kotlin, we can slowly adopt new views and even make our current UI work with Jetpack Compose. It may actually be even more useful to interop between the two while Jetpack Compose becomes the default and your team gets more comfortable building UI in this new world.
This question seems to come up a lot. Especially if you are just starting out with Android development. It’s simply because there is nothing obvious built into the Android SDK enabling developers to hook into application lifecycle events. Activities and Fragments have all the callbacks under the sun to detect lifecycle change, but there is nothing for the whole application. So how do you detect when a user backgrounds and foregrounds your app. This is an example of how your could detect Application lifecycle events. …
If you have started using the new Android Arch components you have probably reached a point and asked, “How do I handle a click or single event in my ViewModel?”. You have probably found this article because you have the same issue I had when trying to handle single events. This is just an idea so feel free to comment about other solutions and your thoughts 💭.
A potential solution. Stateless LiveData.
No one likes a null, so we are going to use it to our advantage here. The idea is simple. I will explain in code first:
So you just started targeting Android Oreo and you have forgotten about thoses Services you created to update your widgets in the background.
You may or may not be aware that when you start targeting Android Oreo there are execution limits for background Services. In summary you can only start background Services from something that is considered to be in the foreground - foreground is defined in the link above. WidgetProviders are BroadcastReceivers for Widgets, therefore starting a Service from a WidgetProvider would be considered background.
Just to note: These backgound execution limits do not affect Bound Services. If you…
Some languages, such as Go, allow for multiple returns. In Go its commonly used to return an error or the expected result.
In Kotlin we don’t necessarily have multiple returns, but we can achieve the same result using destructuring.
Destructuing is a way of breaking down an object properties into individual variables. For example, lets say we have a normal data class with 3 properties
In the example above you can see we have created a simple Car data class and used parenthesis to pull out the properties and assign them to individual values. This is destructuring.
I wanted to implement a simple event bus with RxJava and Kotlin that did not require any if statements, switch statements, when statements, reflection or any other nasty-ness when deciding which consumers should receive the events. I am assuming any readers have used RxJava before but the idea is simple.
All we do here is create a Kotlin object (RxBus), which will ensure the RxBus is a singleton. We then instantiate a private PublishSubject<Any> on the RxBus and expose a publish method on the RxBus to send onNext(Any) events into the publisher.
The bit that makes the bus flexible…
Before I started working with Kotlin, like most Android developers I developed applications in Java and in-between I learned Swift for iOS. One of the things I liked about Swift was the guard let syntax. Just seeing the guard keyword at the top of the method body was an instant indication that this function is going to return early or handle some potential errorneous parameter. So I started playing around with the ways you can achieve this in Kotlin. This guide is just to provide some ideas about how to achieve guard statements in Kotlin. …
Senior Android Engineer @Plex