Best Practices

This one is a major point. Before embarking on my next app project I will definitely start using Android Studio as an IDE and not just use it for the SDK build tools: a mistake I made for my ReadEase OCR app project. This is for a few reasons. One being that it would give me access to much more official documentation. This might seem like a minor point but it would have made the development process a lot easier and improved efficiency significantly. Another reason for this is that there is a larger support community available for android studio: this means that if you loom up an issue, it's more likely to be solved already, and when you post a question it's more likely to get an answer. A third reason is that Crashlytics is much easier to integrate into you app if you build it from within android studio, which makes ongoing lifecycle support for your app so much easier.

I would say that this goes for any project you undertake: if there's established and popular frameworks that you can use to build something: find out what they are and use them!

This might seem obvious, but it is something I haven't done from the start. I think an important point about this is that there is rarely only one document/tutorial you can read. There are often several, each of which can shed light on certain issues.

When you're stuck on an issue, using hello world to troubleshoot can help you establish if the configuration is right. But I would take it a step further, I would say you want to keep configurations and settings as close to the hello world, ie default settings as you can. Sometimes just deleting certain settings can fix an issue!

This practice is a sort of insurance against making stupid changes that mess up your project. By this I mean that, when you document every environment variable change, every configuration setting change, and every code change, you can more easily pinpoint causes of errors, and you can also save yourself time and effort in trying to work out "where did I save this file?", or "what did I change in this file?". This is particularly useful when unexpected errors crop up when you haven't intentionally changed anything. Certain actions can have unintended consequences, like deleting dependencies or files, and so even if you think that what you are doing isn't going to mess up the project, it's best to record it so that if that does happen, you at least can say "ok since it last worked I did this, this and that", and then use those actions as a springboard to diagnose the issue.

​

This is actually the motivation for a project that automates this documentation process. This project is as of now an aspiration, but I think it could potentially be useful.

This has been a common cause of errors for my project: saving something in the wrong place and not knowing why it isn't working. Fortunately this is quite an easy issue to fix when you make an effort. Keep track of where things are, which OS they are on, and where other things are looking: if a file is looking for a module in one directory but it's in another, it will just say "module not found", it won't tell you you've saved it in the wrong place. This should be one of your first thoughts when an error message pops up.

This is, much like reverting to default settings, somewhat of a hail mary in terms of troubleshooting. That being said, it can sometimes help to just copy a project into a new directory, and start again, or, just close a tab, and start the process again in the same place. This can also give you more detailed logs, which you can use to get a more detailed picture of what the code is doing before it fails, and thus better find out why it has failed.