Welcome 2016! The new year is finally here.

For some, the Gregorian’s calendar birthday is an event worth celebrating as much (if not more so) than their own, while others may dismiss it as nothing more than a simple change of digits. But let’s admit something – when a new year arrives, it doesn’t go unnoticed. With everyone around rating the past year’s best and worst in numerous categories, I too find the occasional thought popping in, asking myself “what can I do different, better, from now on?”

So it got me thinking. I’ve been enthralled in the world of mobile development for quite some time now. I’ve seen things; I’ve done some; I’ve been around the mobile block.

Thinking of programming in general, and mobile programming in specific, I’ve gathered these 6 New Year’s resolutions that are not only how I wish to better myself, but also how I hope my fellow app developers are nicer to one another, code-wise.

#1: Refactor Your Code ASAP

Refactor your Code ASAP

Okay, I know. Whenever you’re writing code or building a feature, you’re dying to just see it work. Too often, the initial thought of implementation doesn’t go as well in practice as in theory, and it’s back to the drawing board. There are a lot of detours on the way, and honestly, who can be bothered with seemingly meaningless things like readability at a time like this? You just want to prove your concept, watch it working, then you’ll get to all of these things.

Only you won’t. Setting off with the best intentions at heart, you’re forgetting that at the end of that tunnel awaits another tunnel. Another time-crunching task. And even if you go back and refactor your code in hindsight, chances are you won’t cover everything. You’re bound to miss a method or class here and there. Which may be fine. Or it may be the open door tempting the big nasty time-consuming bugs of the future. So when you’re writing a method or a class, big or small, earth-shattering in brilliance or as trivial as they come – refactor.

If you’re copying code from someplace else in your project – take it, move it and build a method out of it.

If your method’s code has gone too long and can no longer fit into a single screen view with minimal scrolling – chop it, divide it and make a couple or more methods of it.

If you’ve hardcoded a number or a string, any property of any significant, do everyone a favor and give them an eviction notice – they belong in constants.

If you’ve named your fields, parameters, variables and whatnot with names that can baffle a horse – rename them.

And if you can minimize code duplication via generics, inheritance, etc. – do that.

Not afterwards, not tomorrow, not in an hour – do it now, no excuses. You’ll be so proud of yourself when you’re done and you won’t have to go back and nitpick at your own code. And it’s so much easier to take action on the fly than in retrospective.

Code Refactoring Example
Example of Simple Refactoring: Before and After

#2: Comment, Comment, Comment (inline your code)

Now if you could get by with a few flimsy excuses about postponing your refactoring, there are no acceptable “my dog ate my methods” when it comes to commenting your code. Honestly, if I could take a page from soap operas and give myself amnesia every time I finish writing some piece of code just to see if I can understand it without prejudice, I would.

The basics here are very simple: document your methods, no matter how trivial, and document your code. Almost every line of your code should be documented and explained, even if you think a fifth grader can understand it. That way you and everyone else who would attempt to read your code in the future would have a fighting chance in understanding it, rather than starting a guessing game or wasting valuable time.

// extract elements from json to the list:
int elementsCount = jsonArray.size();
for (int i = 0; I < elementsCount; i++) {

 No matter how trivial or small the piece of code looks to be – always add a comment

The only exception I can think of to the above is if the comment is repetitive of a method’s name when invoking it.

// extract elements from json to list:

 Here I’ll concede and say you may forego the comment, but just this once

William Shakespeare once said “brevity is the soul of wit”. So keep your comments short and concise as possible, but don’t be afraid to get a bit lengthy to make your point. And if you’re handling some extreme case scenario you’ve encountered, use it as an example. Simple words can only go so far, context is very important as well.

#3: Dude, Why My App Keeps Crashing?

Dude, Why My App Keeps Crashing?

Often I’d use an app whose content keeps me coming back but its quality keeps me at bay, and I use the app a lot less than the app publisher would probably want. And quality is very important. So if I see an app that constantly crashes or has annoying unforeseeable behavior, I think twice before spending what little free time I have using that app. No one’s getting any younger, why waste it in frustration and agitation?

It’s not always feasible to wrap all of your code in try/catch blocks (but you should attempt to do so nonetheless). And not all of your code is really your own. However, there are so many SDKs these days that offer app developers crash reporting tools and analytics, that it astounded me to learn from the data we gathered as SafeDK that less than 50% of apps use any of them.

So if you’re going to make just one New Year’s resolution to better your app, let it be this one: add crash reporting to your app. Learn what your problems are and attempt to fix them. Sometimes it can be as simple as reading comments users have posted on your app at the App Store or Google Play.

Show your users you care about keeping them by hearing their feedback. No one’s going to stay for the long haul with an app that has bad user experience, no matter the content.

#4: App Permissions and Self Control

I have a little confession to make – smartphones are making me a little paranoid. It’s not that I believe that big brother is actually watching me specifically (it’s not, right? anyone?), but I can’t help wonder about all my private data gathered by so many companies. And how it gets passed around, sold from one entity to another, my privacy is nothing more than a simple commodity, usually in the promise of serving me with ads or content targeted especially for me.

Which is why I find trouble installing apps that require lavish permissions. Sure, like a kid in front of a bonfire, I can now take comfort in Marshmallow (as an Android user), but not all apps are following it yet, and revoking or simply refusing to grant permissions are still a Russian roulette, a wildcard of app behavior. I’m still uncertain which apps will sustain the lack of permissions.

Point is I’m skeptical of any apps that require permissions that aren’t integral to their functionality. And looking around, I can see I’m not alone. Honestly, the apps that prevail on my phone are those I can trust. And permissions make a very important first impression when it comes to trust.

So if my New Year’s resolution is to only use apps that don’t request unnecessary permissions, I would like to hope that app developers will take a step back and look at their permissions as well. Just because users don’t have to grant them everything, it doesn’t mean they should ask for everything. I personally have no interest in allowing simple game apps to access my location, and any app looking to vibrate my phone isn’t going to be vibrating nothing for me.

#5: Be Kind, Rewind

Kindness truly is a virtue not to overlook. When it comes to free mobile apps, it looks more and more as if developers care more about their capital than their users. Mobile app users are bombarded with constant ads, dismissed with a simple “but you’re getting the content for free” if they dare raise their eyebrows.

But no. Users, even non-payers, deserve basic respect. I’ll let you in on a little secret – apps are dime a dozen. There are so many apps out there offering users almost the same experience, it’s easy to switch an app with a better one, and keep enjoying the core features. Very few apps are ‘one of a kind’ and even they have rivals trying to take a bite out of their market share.

So I hope you make the New Year resolution of being respectful not just to mankind, but to your users as well. Don’t blast them with ads just because you can; Consider how much battery your app is consuming (usually by excessive location accesses); Consider how much private data you’re collecting; Think if you can move unnecessary heavy network consumption only to Wi-Fi; Think if you can mitigate some of your constraints in code to improve their experience or their trust in you (can you rely only on network-based location and ‘never mind with GPS’?);

And here’s a wacky notion – Show your users that you care by simplifying the menus or other important options. Trust me– Users who care about these issues will be much more inclined to come back to an app they feel comfortable with, rather than one they worry about.

#6: Hanging by a Thread

Consider Threads when Writing Your Mobile App Code

2016 may be leap year, but there’s one thought process you shouldn’t be quick to leap over. Thread-safety. All the cool kids are talking about it. Well, if they don’t, they should.

When you write a piece of code, stop to think “Can this be run concurrently or in parallel by more than a single thread?” In server-code, I’d assume you’ll be aware of that and your answer would usually be a resounding yes. But in client code… think about it. Think about it carefully.

Ever since computer architecture has virtually given up on improving on single-thread execution (Moore’s Law reaching saturation, transistors’ can no longer be made smaller without major current leakage disadvantages and so on), the focus has been shifting towards multithreaded and multicore execution.

Now, smartphones have so many processes and threads running at a time, related to so many separated apps, you always have to think about that. For instance, are you, Android developers, aware that any code you write in your Application class may be executed also when a background service begins? Do you remember that a service can start in parallel to the app launch and you’ll have two threads running the same class, practically at the same second?

Therefore, think about it very carefully. When in doubt, remove doubt by making your code thread-safe. You don’t have to start locking every variable, but at least consider using concurrency libraries and structures. And if you’ve reached the conclusion that your code will only be run by a single thread past, present and future, you can always add a small comment to remove doubt. Just to help ‘future you’ remember that you’ve at least considered it.

Happy New Year!

My New Year resolution for 2016 is to summarize my thoughts into small readable lists:

  • Don’t put off refactoring your code. Do it as quickly and immediately as possible.
  • Always comment any piece of code you write, no matter how trivial the comment may look.
  • Use crash reporting tools. It’s ridiculously easy.
  • Are you scaring users out of using your apps by asking for ‘ho so many’ permissions? Might be time to rethink them.
  • Improve your user experience as much as possible, and don’t neglect issues as network and battery consumption.
  • Always be on the lookout for threads that may entangle you.

So… What are your New Year’s resolution when it comes to mobile development?