Part of my home studio audio setup: a microphone on an arm
Part of my home studio audio setup: a microphone on an arm

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” effect, but it’s never that good — especially when you have long hair or a complex background. What about the built-in microphone? That’s also picking up noise from everywhere, including the laptop’s own fan. …


Image for post
Image for post
We got a bunch of warnings across several Firebase instances using Firestore…

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, syx.it (private sessions, email and physical addresses, mobile numbers), and does not contain passwords. Only people selected as speakers for the last two years had their data copied over to Firestore and, as such, only they have been exposed. …


Image for post
Image for post

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.

The committee

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:


Image for post
Image for post
“Colors explosion at sunrise — Scottish Highlands” by Edoardo Brotto—on flickr

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.


Image for post
Image for post
“The Ridge” by Edoardo Brotto — on flickr

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.


Image for post
Image for post
“Neist Point at sunset — Isle of Skye” by Edoardo Brotto — on flickr

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?

1-2. Simple vals and vars

The simplest and most common way to declare a property is to have a val or var in a field-like…


Image for post
Image for post
“Pink Flamingos at sunrise” by Edoardo Brotto — on flickr

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 counter-productive and obfuscating the meaning. …


Image for post
Image for post
“Buzzard at sunset” by Edoardo Brotto — on flickr

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 to be checked. …


Image for post
Image for post
“Griffon” by Edoardo Brotto — on flickr

tl;dr by lazy is very convenient but is underestimated and needs to be understood; oftentimes, lateinit vars are a valid if not superior alternative. Think about your use case before picking which one to go with!

The first pattern we’re looking at is the use of by lazy for properties. For example, in an activity:

As you can see, all properties in this activity have a Lazy delegate. The displayMetrics is probably lazy because resources don’t exist before the activity’s Context is created — that is, before super.onCreate() is executed. All the other properties depend on resources and thus have to be lazy, otherwise their initialisation would cause displayMetrics' lazy initialiser to be invoked before onCreate(), crashing the app. …


Image for post
Image for post
“Stunning light and contrast in the Dolomites” by Edoardo Brotto — on flickr

When debugging apps, we sometimes start putting logging statements all over the code to figure out what’s going on:

About

Sebastiano Poggi

"It depends" 🤷‍♂️ - Google Developer Expert for Android, Flutter and Identity. A geek 🤓 who has a serious thing for good design ✨ and for emojis 🤟

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store