Image Effects with Xamarin.Android

A while ago I was working on a sample app to demonstrate basic image editing abilities using ColorFilter to adjust an image brightness, contrast and saturation.

Color filters are great, but they are comparatively slow on large images, while looking for better options I learned that we could use Effects that are available in Android API Level 14

The effects in Android uses GPU and OpenGL textures to perform all the processing for maximum performances. The EffectFactory provides the list of various effects that can be applied to an image not just basic adjustments like brightness and contrast.

I have ported one of the Google’s sample to Xamarin.Android to demonstrate these effects, this should be a useful getting started sample for developers like me :)

The GitHub repository includes the full solution for the app in the screenshot if you want to run from it: monodroid-samples

Why set-only properties are bad design practice?

Last week my team member from Cambridge was reviewing my code; while he was going through a class he noticed a set-only property and told it is really bad idea to have one in the class. As we both kind of busy, he asked me to read the Property Design section from “Framework Design Guidelines” [ISBN: 978-81-317-2978-3] book.

Luckily I have copy of book, it is clearly mentioned in it that.

“DO NOT provide set-only property or properties with the setter having broader accessibility than the getter

If the getter cannot be provided, implement the functionality as a method instead.”

But it is nowhere in the book given the reasons not use it. So, here in this post I will try to list the reasons, why set-only properties are bad design practice.

It is quite obvious, if OO is meant to better represent the real world, a set-only suggest that our modelling is pretty off.  Set-only properties are uncommon and properties are used to for dumb sets just to store a value without much processing.

If I can set a property on something but never get it, I will never know if something else changes/overwrites the value that I set. That could be a problem if I rely on the value that I set, and I am unable to persist it until the time that I would want to get it.

Using a method instead of a set-only property will be less confusing for a fellow developer. The name of the method usually indicates set or get, but property names don’t normally indicate that something can only be set and not be gotten. I suppose if the property were something like “ReadOnlyBackgroundColour” it would not be confusing to the other developers, but that would just look weird.

We can see lot of example of this in .Net framework; AppDomain has a method called SetCachePath instead of having a set-only property called CachePath. These small things may not feel important while writing code, but makes huge positive impact on readability and maintainability of code base.