The Biggest Problem With Android: Tools, Tools, Tools!

This weekend, I spent all my free-time with my CodePath team working on an app called Hush!, an anonymous chat apps for Facebook friends. This is our final project for CodePath, due now in less than two weeks. To really get going on in, we decided to participate in the Launch Hackathon this weekend.

However, the 12:30pm on Sunday submission time came and went with us just hunched over our screens, still working. The same app would have been no problem for me to make in a weekend on iOS, but we ran into some really crazy problems, not with coding, but with using the Android tools.

Here is a list of a few Android Tool issues I’ve run into both in this project and the others I’ve done during CodePath:

Installation

Given the very detailed CodePath guide to getting set up on Android, it took me a total of at least 5 hours to get Android ready for coding! I can’t imagine how long it would take if you had to google around to figure it out on your own.

I teach a weekend iOS course at General Assembly, and the reason I can teach it in a weekend, is because the only setup that is needed is the installation of XCode. Done! I can’t imagine teaching a similar Android course.

IDE Issues

For the most of my CodePath assignments, I’ve been using Android Studio, which I now find to be incredible after trying out Eclipse one week (that was my most frustrating week at CodePath!). However, Android Studio is not the standard in the industry yet, and you can’t have a project where one person works in Eclipse and the other in Android Studio.

So when my team chose Eclipse for our final project, since my teammates are more experienced Java engineers with lot’s of experience in Eclipse, I had to go along and also use Eclipse! And it’s honestly been a nightmare for me. Eclipse is just not intuitive. Debugging is incredibly hard, and even autocomplete takes work (you have to click Control + Space to trigger autocomplete vs it just happens in Android Studio).

Also, it might be that my computer is older (3+ years), but both Eclipse and Android Studio are extremely slow on my computer. I have to take a while for it to open, then it is common for my Android Studio to freeze, and for my Eclipse to just crash sometimes. If you have Android Studio and Eclipse open at the same time, things might conflict / not run properly!

Git Issues

One of the biggest obstacles my team ran into this weekend was coordinating via Github. Every time we download the latest code, errors pop up that may take hours to debug.

In fact, one of my teammates spent half a day on Saturday trying to get Git working. It’s almost becoming a new ritual to delete our local folder, clone the code into a brand new folder, create a new workspace in Eclipse, and go from there (which also requires linking the dependencies, but more on that next!).

By now, we’ve figured out most issues and can work around them, but it’s definitely a time suck every time one of us pushes code and we need to sync it locally!

And we don’t even have conflicts yet! Working with the Storyboard XML conflicts in iOS, and having so much of Android being XML-based, it makes me pretty worried on working in teams on Android!

Simulator / Device Issues

In iOS, I pretty much use the Simulator the whole time. It’s nice to see your code run on the screen as you’re coding, without turning your head down, picking up the device, etc. In Android, the Simulator is RIDICULOUSLY slow!!!!

The fastest simulator out there is Gennymotion, it is not Google Approved, and it a nightmare to set up. We spent about 1.5 hours in class one night getting it up and running! And it was actually not that fast, especially compared to what I’m used to on iOS. M

My teammate ran into serious issues on Gennymotion this weekend, that were due to Gennymotion, but he didn’t know that. So after hours of debugging, he figured out to run the app on his devise, and the app worked fine!

So, on recommendation of a friend, I bought a Nexus 7 tablet to test on. Well, to enable developer mode on my device, so I can run my code on it, I had to find some very obscure settings and tap on it 7 times. Wut?!!!

It’s nice to test on a device, but I find that when other people download my app, it looks completely different! The device segmentation is a serious problem if you like your app looking good for all users! There is a simulator for every device, but with the slowness of the simulators, it’s hard to imagine trying out your app on all the devices!

External Libraries

Another nightmare here… managing external libraries! Luckily, Android Studio, this problem is on the way of being better solved with gradle, but in Eclipse it’s intense. You pretty much have to have a copy of the library in your workspace, and make sure to properly link it.

Oh, and when someone else downloads your code, the linking will probably break! (see Git issues section above!).

Oh, and there will be library conflict issues. It took us about 2 days to get the Facebook SDK working, because they had a library dependency (a very popular necessary library) in their project that conflicted with our library dependency!

Conclusion

You can probably feel my frustration, and I haven’t even gotten tot he coding part! The amount of time you spend debugging tools in Android and getting set up vs coding is just completely unacceptable. For those wondering, I’m not interesting in doing Android professionally.

However, it is a fast moving industry, and I always try to be open-minded about the latest programming frameworks. Next up, I’ll write a about a few things I learned from Android that I think are actually cool!

Enjoy the article? Join over 14,500+ Swift developers and enthusiasts who get my weekly updates.

  • MP Rogers

    You’re absolutely right about the tools: Google promotes Eclipse and Android Studio, and neither of them are even close to being ready for prime time. Android might have more marketshare than iOS, but based on the tools (i.e., Eclipse and Android v. Xcode), it’s pretty clear that Apple cares a *lot* more about its developers.

  • CK

    Haha, this post definitely makes me a bit scared going into Android bootcamp for CodePath…

    • The CodePath bootcamp itself is really great. It’s not their fault Android is so awful to work with!

  • Ivan Schuetz

    Just a little clarification, the XML in Android doesn’t cause team synchronisation problems. The main problem with storyboards in iOS is that this comprises a lot of screens in the app (frequently all of them), so it’s very likely that there will be conflicts, as it’s likely that more than 1 person will have to make changes to the UI somewhere in the app at the same time. Android doesn’t have anything like storyboards. The layout files are limited to individual components, similar to nibs in iOS. Also, in Android the XML files are designed to work directly with them, opposed to iOS where you usually work only with the interface builder. Most programmers edit the XML instead of working with Android’s interface builder. Thus, given the case 2 people is working in a component at the same time, you will understand the XML and have not much more problems solving the conflict than if it was Java code. Of course it doesn’t make a lot of sense to have many people working in a UI at the same time, since this can lead to awkward designs and conflicting layout rules, but that’s a different story.

  • Jamie

    So glad to find this article. Just spent 4 hours grappling with git in eclipse for an android project. What an absolute nightmare.