YAC-Why I chose Kotlin and API 21+ a year ago

Part-1

If you have a Kitkat device and tried to install YAC. You can see the app is incompatible with the device. This is because I have set Minimum SDK as 21 for the app, means you can only use the app on device running lolipop or newer versions.

In the first half of the post I will share some points on why I decided to have MinSdk=21 for my app. This app is a file/directory handling app. In order to clean your files, YAC needs to know about your files, and where they live. And you know what? YAC does this nicely and it dones’t even need a permission for that, Infact only permissions this app need is Internet and Boot Receieved which are harmless and automatically granted upon install. To scan files, and to keep it scanning YAC works seamlessly without asking for permission. And having Lollipop or above really helped me that.

Lollipop has an API to handle files without even asking for permission¹ ². You can just fire an Intent to Storage Access Framework to read any file tree, which can read your files anywhere (Even in SD Card). This is not the case with older APIs. For Kitkat, all you can have is just one file, not a whole tree. And for older apis all we have are hacks, which may or may not work. And for scans, I am using JobScheduer apis. Job Schedulers are really powerful API where we can run periodic tasks based on network type, device charging or not etc… even without hampering our battery. That’s why YAC won’t appear in your top battery usage.

But wait…. backports exist for a reason right? All I needed to support my storage and old file APIs and use GCMNetworkManager or FirebaseJobDispatcher apis? Why alienating 20% users? And here is my answer, when I started, 21+ was already (If I recall correctly) on ~50% of device. This number-for various reasons I stated in reddit-will not decline anymore. And as a Solo Dev, with limited resources and time I have, I have to look forward. Users of this API levels won’t reduce. And for those users still stuck with Kitkat devices, if I put my efforts, they can use my App, but will they be able to purchase for this app? If they have such purchasing powers, why can’t and don’t they purchase an INR 6000-8000 (90-100$) phone which now-a-days come with 5.1 or 6.0. Thinking that, I have decided to stick with Lollipop as my minimum supported level. And even for some easy and proven backports, I didn’t want my code to be a mess.

But why mess? It’s just a couple of if else blocks right? Why a developer like me should not write it? Well this decision is taken along with other decisions, and the biggest of them is what to do with my code base? The hate for Java 6 is stronger when I was thinking to start, I have seen the confusion the code creates when you want to use RxJava. People are already using RetroLambda to get rid of it using lambdas, kotlin was already aroud the corner (promising more then just lambdas), picking up momentum,even without entering to stable stage. I wanted to build an app with a new language in town, and wanted to see how far I can go.

Well after a year of coding, and almost 10–11 releases later, all I can say I am impressed with kotlin. It already has the answer to things that was bugging us-the android developers-since beginning. Its null handling, data classes, functional apis (like map, filter…) out of the box, lambdas etc are all we were asking for. Having them answered is made us not only powerful, but features like higher order functions, extension function, lazy initialization have made the language more powerful.

How many times did we forget show() call on an alert dialog and debugging why our dialogs are not showing? How many times just we forgot to call notify___Changed() method and wondering why data isn’t updating on screen? Or how many times it’s just we forgot to call commit or close that lead us to exceptions? As Jake Wharton said in one of his talks. We just have to deal with so many “Ceremonial” things while we are doing work in Android. Start with context, do x, do y, do z, if you’re doing z, don’t do 4… once you’re done, call a finishing method to tell the sdk that I am done with what you’re asking, now just do your work with data I have provided. This IMO is too much to do, too much to remember and much mistake prone boilerplate. Kotlin just helps us to reduce this ceremonial boilerplate.

How do you create notification? Create a NotificationManagerCompat.Builder object with context. Pass title, content text, style, small icon, big icon etc… and then just notify with a unique Id. And in all these things, what’s more important? focus on creating object and call notify or to focus on making notifications more useful, unique and less intrusive for our users? And just because these ceremonial boilerplate we are focusing more on creating a notification then to create it right. And kotlin enables us to create a right notification, not just to create a notificaion. In my case, I have a notifymethod which accepts a context an Int and some NotificationCompat.Builder methods (yes methods like setTitle() setStyle() etc…), it will create a proper notification based on these methods and automatically sends a notification. As long as I pass context, a proper Int and proper methods (which really matters), I don’t have to worry about whether a notification fired or not..

How do you handle some callbacks? From your activity, how do you listen to-and reacto to-some changes happening in your view model ? In java, you may have an interface, make your activity implementing that interface, in your viewmodel you have that instance of the interface and call its method when something happens. If you want to make it optional, you may want your viewmodel’s interface nullable and add a null check.

Sounds too much right? But in kotlin it’s not. I am not aware about Java 8, but in kotlin all you have to do is to have a lambda as argument, and pass it as and once needed. Kotlin lets us have default argument, so I don’t have to pass an argument If I don’t want to, in Kotlin all I do is to define a default no-op method³ as default argument to a lambda, and whenever I want to listen to changes, I can pass my own lambda without worrying too much.

Upto this point, I have stated to good usecases where kotlin helps us much. But I understand without code, there is not a point to have a chitchat. But this post is too long to contain that much of code. In next post, I will talk more examples around kotlin.

Originally published here.

YAC - Android Apps on Google Play_Yet Another (Intelligent) Cleaner_play.google.com

Footnotes

1. Infact permissions are virtually asked when a UI is presented to user, If user go ahead with UI and app gets a positive response, permission is granted, we just need to add some code to keep this. If user cancels it, we don’t get permission.
2. This video from Ian Lake from 2015’s Big Android BBQ really shades a lot of light regarding to files and permissions, look at this video here. IMO, you wan’t need a file permissions, If you are going with upto 10 files, go with Context’s file methods, go with Storage Access Framework instead.

3. No-Op: Doing Nothing, Empty methods

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!