As I described in my “How I Started to Learn Android Programming” blog post, you should start as early as possible to build actual little apps instead of consuming books and other forms of plain theory. Not long after I wrote my first line of code (at least in my adult life), I released my first app to the Playstore. And shortly after that 2 more. Of course the code was bad and the apps didn’t have many features, but I was very proud nonetheless and it was an amazing feeling. Now that I learned some more about Android programming, I think it’s a good time to review on that and talk about mistakes I made in this process, so you can benefit from it. This list isn’t ordered and it is not about the correct marketing of your product. It is more about the raw development part of creating your first little apps.
Mistake 1: Starting too big
For my first project, I actually wanted to build something like Habitica, a fully fledged gamified to-do list with a whole role playing game behind it, with levels, armor and a fighting system. This would be a project big enough for a whole development team and several years of work. Needless to say that I didn’t get past the first few screen designs. Of course I didn’t expect to finish an actual game and i knew that I would abandon it eventually, but nevertheless it was a bad approach, because it is important to actually finish something, even if it’s not that good. Not only that you have to learn about the process of releasing and maintaining something to the public, but you also don’t want to get into the habit of quitting a project when it gets too complicated. So start with something small that you know you can finish. Don’t start with crazy online features, databases and other complex stuff. I wouldn’t even use a RecyclerView for my first app. Start with some small offline app that you can get through without getting overwhelmed. Maybe something like a calculator or a timer app (my first uploaded app was a Pomodoro timer).
However, after that’s done you have to incrementally increase the difficulty and learn new, more complex stuff. Make sure to stretch yourself and improve constantly, but also get into the habit of finishing projects. Start simple and then slowly grow into concepts like databases, RecyclerViews, adapters, online features etc. Step by step. This incremental improvement combined with not getting totally overwhelmed will keep you motivated over the long term.
Mistake 2: Not taking care of configuration changes
You probably noticed that when you rotate your emulator or device while having your app running on it, the app restarts completely. This happens because the system basically kills the whole process and recreates it from scratch. Now a lot of beginners try to fix this by simply deactivating the landscape mode, so the app doesn’t change it’s orientation at all and that’s what I did as well. I thought orientation changes were not worth the effort, because the user can just use my app in portrait mode. What I didn’t know was, that this destroy-and-restart process doesn’t only happen when the device is rotated, but also after a lot of other runtime configuration changes. For example when the user goes into the settings of the phone and changes the language or the text size of the device. Go ahead and test it! Start your app, then go into your phones settings, change the text size and then go back into your app, it will be restarted. And that’s exactly why you have to take care of these configuration changes if you don’t want your app the be a buggy mess. I was afraid of that topic, because I thought it’s super complicated, but it’s actually pretty easy. I have videos on that too, for example in my “Data Persistence” playlist, so take a look at it. Important keywords here are “onSaveInstanceState” and “onRestoreInstanceState”.
Mistake 3: Not taking different screen and text sizes into account
Android runs on a ton of different devices with different shapes and sizes. Building a somewhat responsive layout is not super hard thanks to the different root layout types like RelativeLayout and ConstraintLayout, but my mistake was that I paid too little attention to smaller screen sizes and larger text sizes. Bigger screens and smaller text is of course not as much of a problem, but since we should define text sizes in sp (scale-independent pixels) to give the user the option to use our app with bigger text, we also have to account for that extra needed space in our layout or it will look messy. Make sure to use a rather small device for your xml preview and your emulator and also go into the settings and change the text size while testing your app. There are layout attributes that can help you handle larger text properly. For example you can set the end boundary of your TextView to the start of another view and make it end with “…” instead of flowing over. You can align your views so that they move when the text size increases. It’s hard to do that with plain xml code, but luckily we have a handy xml editor so I encourage you to play around with it. Experiment with the visual editor, then add details like margins and padding in xml code. Also consider providing different layouts files for tablets if you want your app to look as good as possible.
Mistake 4: Not looking into the source code and documentation.
In my first months I always wanted to have other humans explain everything to me. And at the beginning this is necessary, but you should try to become autonomous as soon as possible and (at least try to) figure out what is happening by yourself. When you hold CTRL while clicking on a method or variable (or press CTRL + B) in Android Studio, you go directly to it’s declaration in the corresponding class. This way you can see what it is doing and often the developers left some helpful comments there. A lot of questions can be (partly) solved this way and you practice reading other people’s code, which is necessary when you start working with other people. Becoming a good programmer is not so much about remembering certain code snippets, but about looking at big chunks of code and figuring out what it does and how the logic works. However, don’t get frustrated if it seems too complicated. You can’t understand everything from the beginning and there are other people who can and will help you, but at least try to figure it out and get into the habit of it. The same goes for the official Android documentation, which is usually somewhere at the top of Google results when you search something Android related. It is pretty complicated as well and a lot of these explanations are not quite understandable, but you have to get into the habit of looking there first.
Mistake 5: Being impatient
The last mistake I want to mention in this list is my impatience. One thing I was impatient about, was the whole learning process. As I described in my How My First Months of Learning (Android) Programming Felt blog post, Android programming as a beginner is super overwhelming. I felt like whenever I wanted to know about a certain topic, it forked into countless more other topics that I also had to know about. What also overwhelmed me, were all the Material Design guidelines or the huge preparations list you get when you want to upload an app to Google Play. However, with time I realized that almost all of this is not as complicated as it looks. You won’t learn this in 1 day, but if you focus on learning a little (almost) every day, then you will understand a lot of this very quickly. For example the checklist for Playstore uploads contains a lot of scary sounding words like “key signing” and “EULA” , but it’s actually pretty straight forward and there are systems in place that make a lot of these things easy for you.
Another thing I was impatient about, was the release of my app. As soon as it worked (or at least I thought so), I wanted to release it, without even testing it for a couple days. I posted one of my apps in forums and then later realized, that an important key feature made the app crash every single time. That’s not so good if there are already people using it. So take your time and test your app, preferably on different devices. Consider using Google’s alpha/beta channels to let friends test it as well. Of course my post is about your first app as a hobby developer, not about big, commercial team projects. Then this whole process needs a lot more planning.
Ok, that’s it for this list. I hope I could help you a little bit with this and keep you from doing all the same mistakes. Always remember to focus on incremental improvement and don’t let the sheer amount of information scare you away. Eat the elephant one bite at a time!