Many folks in our industry are familiar with unit testing, and practice it daily. Some folks get to the extreme of considering tests more important than production code, while others think it’s just a waste of time, but unit tests have saved my bacon more times than I care to admit. They’re a great way to ensure correctness, and adherence to business rules.
You may have been writing tests for a long time now, and yet not ever use one of the best tools there are: mocks, fakes and stubs. …
You probably have heard that JFrog, the company behind Bintray and JCenter, is shutting down these (mostly free) services soon. Whether you’re the author or a user of any of the nearly 800,000 libraries that are exclusively available on JCenter, you’re probably wondering what’s going on and how to deal with this.
As a result of JCenter and Bintray shutting down, many library authors who published their libraries to JCenter with entirely made up groupIds now face a very painful migration to Maven Central, having to also pick a new groupId which they can assert they control. Contrary to…
Most people are just fine with the integrated webcams in their laptops, because after all, if you’re in a meeting where everyone uses their crappy built-in webcam and microphone, there’s no point in doing any better. But what if you need to record or stream some quality content? Say, giving a talk, hosting a webinar, presenting something important…
Well in that case, you may find that the built-in webcam and microphone can be inadequate. My Macbook’s webcam output for example is a blurry mess where everything is in focus, including the background. Sure, many apps now have a “blur background”…
First of all, thanks to Doug Stevenson for an enlightening chat last week around Droidcon Italy. He opened my eyes on why the emails we were getting about Squanchy Firestore rules pointed at a bigger problem than we initially thought. And many thanks to Daniele Conti for fixing it! 🙌
Over the last week or so, we’ve discovered and patched a security issue leading to potential leakage of some PIIs (Personally Identifiable Information) about speakers on two Squanchy instances for Droidcon Italy 2018, and 2019. Potentially exposed data is limited to what collected on the CfP platform for Droidcon Italy…
It’s only been three weeks since the Droidcon Turin CfP has closed, and we have already published the full schedule for the event. As customary for our CfP committee, we are committed to full transparency, and this year we decided to make our retrospective public.
First of all, I want to once again thank the members of the committee for all the time and effort and love they keep pouring into making this conference contents the best we can possibly have. They are:
In the first part of this article we saw the new APIs introduced in Android Pie that allow us to have coloured elevation shadows. Our ambition had been crushed by the cruel design of elevation shadows APIs, which impose abysmal values for the alphas, thus making even the most lively shadow a pale disappointment.
I recently wrote an article about elevation in Android, showing how you can hack around framework restrictions to obtain elevation shadows that are different than what the Material Design guidelines mandate.
Since then, there’s been a few interesting developments on the topic, and this follow-up article will cover them. Come for the shadows, stay for the code!
As a side note, I have recently pushed a major update to the app that accompanies last year’s blog post. Uplift has now hit version 3, and there’s a lot more than meets the eye in that release.
tl;dr Kotlin properties are awesome and super powerful, but each form comes with a bunch of gotchas. Make sure you fully understand them before deciding what type of property you use!
Kotlin boasts an excellent support for properties. No more you are limited to the bare-bones fields that Java offered; no more envying C# developers for their fully-fledged properties!
Just look at this non-exhaustive list of ways to declare a property:
But what if I told you that there’s some non-trivial implications that depend on the way a property is declared?
The simplest and most common way to declare…
tl;dr property syntax is great but you should avoid properties hiding expensive operations in their custom getter/setter as it can be misleading for those using the API from outside. Prefer functions instead in those cases.
Unlike Java, Kotlin has first-class properties. In Kotlin, a property can be read-only — or not, can have delegates (such as
Lazy), and it can be a simple field-backed property or have custom getters and setters.
In this article we’re going to be focusing on these custom getters, and we’ll try to understand when it’s ok to use them, and when instead it might be…
Welcome to a series of posts covering various aspects of Kotlin programming for Android developers, from patterns spotted in various codebases to various gotchas and protips. We’ll try to understand if these patterns are good, when they work and when there are better alternatives.
As with all things programming, obviously, there is no absolute truth. The developer’s motto should be “it depends”! Never take anything for granted, always do your own reasoning. Maybe things written in the past aren’t valid anymore — IT moves fast. Maybe things don’t apply in the specific case you’re working on — assumptions always need…