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. …
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, 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. …
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 a property is to have a
var in a field-like…
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. …
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. …
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. …