• Flying Solo with Android Development
  • By Anita Singh
  • The Nuggets translation Project
  • Translator: Boiler Yao
  • Proofread by gaozp, tanglie1993

Photo credit: www.magic4walls.com/crop-image?…

Two and a half years ago, WITH the help of a four-person Android team, I started moving from backend development to mobile development. A year later, I joined a startup that had raised a Series B round and was working on Android development. Working in a small team is a great way to keep your independence and learn from your colleagues.

But then, five months ago, I went from a small team to a place with “no team at all.” I went to a startup with six people, and I was the only Android engineer. In this new position, I finished Winnie from scratch, the APP has been released recently!

It turned out to be a big leap forward. Flying solo has always been a challenge, but it has also brought many rewards. Along the way, I’ve found that working alone has its pros and cons. But most importantly, there are things you can do to help you succeed. Here are some strategies that have worked for me so far.

Stay in touch with the community

One of my worries about going solo was that I had become so used to my old role that I feared I would have no one to discuss new ideas with and advise me.

The good news is that there are plenty of online resources to expand your knowledge and horizons. From DroidCon, 360 | AnDev such developers conference online sharing, to the Fragmented podcasts, Android Dialogs and Android Weekly timeliness in high site, You have many ways to expand your ideas.

My personal favorite is Caster. IO – code examples plus a short commentary video keep me pulsating back! Offline gatherings or communities like AndroidDev Subreddit, Google+ Communities, Slack Groups, and Twitter are great places to continue the discussion and clarify the confusion.

Review previously submitted code to maintain high standards

In particular, I recommend opening commit records to review your own code. It may seem silly to comment on your own submission, but I think it’s a good habit to have if you’re working alone. This point was also discussed in a series of android-related conversations.

I used GitHub’s built-in preview to do the first step, then put it away and come back to it later. I do my best to review my submissions just as I review my colleagues’ code to make sure I hold myself to the same rigorous standards. Looking back at your own code also helps you find bugs and error handling of boundary cases, as well as keeping your code consistent and clean.

A “bad” pattern is usually better than no pattern at all

You have to make a lot of decisions — should you use MVVM, MVP, Flux, or some other architectural pattern? Fragment or ViewGroup? What should be abstract and what shouldn’t be?

When you start a project, it’s not unusual to start with one pattern and then realize that another pattern is better, leading to some refactoring and removal of patterns.

While it may make sense to break your pattern in some cases, when you find something better, it’s best to take care to refactor and change the previous code to keep the whole thing consistent. This may sound obvious, but it’s easier to just apply new patterns to new code, so you might be tempted to do this when working alone. But this can quickly turn your code into a honey mess before you know it! Even if the pattern isn’t great, keeping the code consistent makes it easier to patch later.

Kotlin is recommended for wall cracks

Unless you’re starting from scratch, think about the next class you’re going to write.

I ended up not using Kotlin in Winnie because I wasn’t confident enough about the idea because OF my inexperience, and I didn’t want to discourage the Java backend engineers on my team from contributing code to the code base.

However, after watching Christina’s talk on Kotlin and doing some research, if I could do it all over again, I would at least try the language. Kotlin has a lot of advantages — even if it’s just preventing exceptions from null Pointers and not having to mess with Java’s clunky stereotype code — I’m blown away. This lecture by Jake Wharton is a great starting point for learning about Kotlin.

Master your own code and don’t rely too much on third-party libraries

I remember spending a lot of time in MVP choosing a library to use because there were so many of them. Spoilt by choice was a big problem, and I ended up building my own simple wheel and having fun with it.

When choosing which third-party library to use, I recommend thinking about whether you really need it and how it limits your future development — does it make unit testing harder? Will it limit the use of Android’s built-in features, such as transition animations between multiple screens? Is it still in hot development with a lot of apps using it? These considerations allow me to weigh up and make a decision.

I recommend optimizing as much as possible with as much control as possible, rather than recreating the wheel. There is a library that contains almost everything, but it’s better to implement something yourself. (Use the base components of third-party libraries and assemble them yourself as needed. )

Plan for Testing and Accessibility

If you’re taking on a project from scratch, you can do it now! Otherwise, you can do this in the code you write later.

In the face of deadline, testing and accessibility are often inferior citizens. And when you make them a low priority, it’s harder to find the time to do them because there’s no one else to share them with.

I confess that I have only just begun to do this work myself. But by writing test code in your head using dependency injection, MVP mode, exposing only the interface of the Model object to the UI, and so on, you achieve the goal of making it easier to test. From the beginning of the project, I compiled on CircleCI at the same time after every commit to do simple checks and run tests.

For Accessibility, I add content descriptions whenever I can, and use the Accessibility Scanner before publishing to find out what I need to do next. There’s no doubt more work needs to be done, but it’s a good start. Kelly Schuster’s talk gives some practical tips on how developers can make their apps more user-friendly for people with disabilities.

If time doesn’t allow for writing tests, manual testing is convenient. For example, write down different test cases (positive and negative) for each feature in a document, and make sure you do these tests before each release. Give yourself a deadline to write tests and Accessibility improvements, or you may never complete them.

Tell your iOS designers that they are wrong to seek their own conversion to Android design :-).

Don’t worry about supporting the right things on your platform! When you’re working alone, it’s your responsibility to bring others up to date with the latest Android UI patterns and code base developments.

I usually get screenshots on iOS in my work, but use the Material design specification and some good Android apps as resources to translate those designs into Android. Also, there’s nothing like referencing an official Material Design document to convince someone!

As for the code base, I introduced my CEO to our architecture and concepts like MVP, Dagger2, RxJava2 within a few months of her coming to help. I recommend keeping preaching Android concepts to people around you, because explaining your decision or teaching them a new concept helps you really grasp the concept, and sometimes makes you realize your mistakes.

Release the beta early

This is great if your APP isn’t live yet or if you’ve made major changes to your existing APP. Google Play has an Alpha and beta channel, where you can turn your beta on and off.

If you are continuing to develop an existing APP, you can still release beta versions in parallel, as long as the version is higher than the current official version. If it is an open beta, users will be able to use it by installing it on the Play Store or clicking on some links to download the install. Lantern-rollouts are a great way to test changes on a small scale.

If you’re developing a brand new APP, I recommend developing a beta as soon as possible before it hits the shelves, and then moving to open beta when it’s ready. Our first beta had very few features, but it helped us catch bugs early, get us on track for periodic releases, and get valuable feedback. It also keeps us stress-free and smooth.

Flying solo for the first time is a great learning experience because you challenge yourself in a way that you’ve never done before. You become more dependent on yourself, exercise overall control over your codebase (for better or worse), learn more about what you like, and deal with other people’s mistakes (yay). I was worried about flying solo, but with the help of the tips above, it turned out to be a fun experience. I hope these suggestions will be helpful to you as well.

Planning to fly solo or share your solo experience? It’s good to hear your voices. Comment below or ❤ This article or find me on Twitter.