Stop using your IDE’s drag-and-drop

Think about when you were a beginner at programming, when you were just starting out. Now if your main tool as a beginning programmer was a plain-old text editor like mine was, you probably enjoyed and might still appreciate a more hands-on approach to learning, where you know what’s happening under the hood. Maybe you later on graduated to using an IDE because you either had to (like with Android Studio), or because you found it saved time.

But if you started out learning with an IDE, there’s a decent chance that you used helpful IDE “features” like drag-and-drop, and later realized you had to learn to write raw XML to design layouts anyway.

Obviously this isn’t true for everyone so I don’t mean to generalize, but my point was to illustrate the issue I have with drag-and-drop: it’s a level of abstraction no programmer should strive for.

Generally speaking, I’d say the more abstracted things are, the better. No one writes web apps in assembly. But using drag-and-drop and ignoring generated code completely is generally a bad idea, at least in standard Android development. The drag-and-drop functionality in Android Studio isn’t mean to completely replace raw XML coding (that’s why you always have the option to switch to text), it’s meant to reduce the amount of typing you’d otherwise need to do to get views and view groups. It’s essentially like the “add new activity” wizard: it provides you with stub code that you’re supposed to edit to suit your particular needs, saving the need to write everything from scratch.

When you drag and drop things and ignore the code that gets generated, you’re relying on the IDE to format your code according to your coding conventions (you have those, right?) and any optimizations you may need to do, depending on how complex your layouts are. That, or you just don’t care about any of that stuff, which is Bad Practice™.

Don’t get me wrong, I have nothing against using drag-and-drop for the purpose it is supposed to serve, i.e. to save time. I see the value in dragging and dropping views or widgets and then customizing the code. Point is, you should be aware of what the code does, and relying solely on drag-and-drop cripples this awareness.

Now this isn’t true 100% of the time. There are cases where your IDE generates code that you’re not expected to look at. The most obvious example would be auto-generated code that’s temporary and regenerated on every build (e.g. files in /build and /app/build directories in Android Studio). Another example could be Django’s migrations, but those are still part of your project and you should be ready to get your hands dirty with them if needed.

As a general rule of thumb, anything that you don’t exclude from your version control system should be considered code that you should be willing to work on, and if that’s not the case, you need to ask yourself why.

Show a custom crash screen in Android

No one likes it when your app crashes. Many of us as developers do our best to thoroughly test an app before releasing it for everything from random bugs to crashes, and your app crashing after release is probably one of the worst things that could happen post-release. But no matter how much you try to cover every case, there’s always that one weird device with a weird OEM that you missed that managed to crash your otherwise perfect app. It happens.

Problems with the default crash dialog

Well then.

There are a few things wrong with this:

  1. It’s a generic message, and it’s the same for every app that might crash. Your app isn’t special anymore, and all your branding is irrelevant here.
  2. You depend on your user’s Android system to display whatever message it’s programmed to display. In this screenshot I was using an Oreo (API 26) emulator, but different Android ROMs handle this differently. Some show nothing at all.
  3. You can’t tell your user what to do next. Again, Oreo apparently does let you restart your app, but some other versions don’t. You don’t control the message.

So what can you do then? Well the answer is simple: make your own crash screen.

Now bear with me, I know what you’re thinking. “Well maybe your app shouldn’t crash at all.” Let me be clear: by all means, do everything within your power to make sure your app doesn’t crash. Apps aren’t supposed to crash and that’s not something we should be aiming for.

But my point here is, it might still be worth handling, let’s say, the 0.1% probability of your app crashing on some device. It’s probably the last thing you’d want to do with your app, but hey, at least you can rest assured that your users will always see a friendlier message if it does come to the worst.

Displaying a custom crash screen

I’ve used the Custom Activity On Crash library in the past and I’d recommend it to anyone looking to display a custom error activity. It relies on the Thread.setDefaultUncaughtExceptionHandler method to launch a custom activity any time an exception of any sort occurs in your app. It is fully customisable – you can either modify the default activity or even use your own.

You might want to configure .minTimeBetweenCrashesMs() to be zero – it’s the time that must pass after the app crashes before the custom activity is launched and apparently it’s used to prevent crash loops. Problem is, if the time is too long, your users will see the system crash screen instead of your custom activity. I haven’t had a problem with setting it to zero – crash loops, as far as I know, shouldn’t happen unless the error activity itself has an uncaught exception (and I’m sure you can get that one activity right).

If you want, you can of course try implementing your own solution using the exception handler. But do try the library to see if it fits your needs – it most likely does, so you’ll be able save yourself the trouble of reinventing the wheel.

How to restore your Android Studio project

If you’ve ever entered the wrong Git command (like the dreaded git reset hard command) and lost all your precious uncommitted work, you’re probably familiar with the pain and the feeling of panic. Well if you were using Android Studio, you just might be in luck. Here I’ll show you a neat little feature Android Studio has that can help you restore your Android Studio project back to a previous point.

In the Project navigation to the left, right click on “app”, then select “Local History” → “Show History”.

You should see the following window.

Here, you can click on the various “checkpoints” that Android Studio made over the course of your project, and you can see changes to individual files and even restore to an older point in time.

Now obviously this isn’t a replacement for a proper file versioning system like Git, but it works just fine if you’re the only one working on a small project as well as for situations like these, so it’s pretty useful to know.