Why it’s hard to find Android developers
blog.sephiroth.it
blog.sephiroth.it
Absolutely no problem finding candidates but finding one that had done more than 'Android Programming for dummies' type stuff is painful. The majority of people have written a TODO list app and nothing else, not even any other programming of any sort and expect £60-70k. It does make me worry that comp sci education will end up being pushed down this route as it fulfills the UK government's sudden focus on 'programming'.
Also, having done a bit of Android programming, around the TODO type app level, it's a horrible tool chain. Even people we already have don't want to be paid to take training to do it.
Consequentially we contracted our Android front end out to an Indian company in the end who did a decent job for the money. No complaints.
Next iteration is Xamarin.
In 24 hours I got 12 CV's (we're skipping recruiters), reduced down to 3 we actually want to see.
I reckon we'll have a shortlist of 10 applicants, cut down to 3-4 interviews on Friday.
I'm an Android contractor myself, and it's true, there's a lot of chaff around.
What's your recruitment process?
Plug in an iPhone, and (after jumping through the byzantine code-signing system) you'll be able to deploy development code to it (from an OSX environment). If your app runs on one iPhone, it probably runs well on another, barring some screen geometry concerns.
Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"). You might also have to worry about ancient devices that can't be updated to a modern Android version, and have egregious platform bugs. Comparatively, it's a mess.
You can't even get started on iOS without having a Mac, a $99/year subscription and worrying about creating app ids, profiles and other strange things through the developer portal.
Nothing is as bad as Apple's brain-dead method of tracking files in its projects. They create UUIDs for each entry, instead of doing something more file-specific. This results in merge conflicts when more than one person works on a project. Poor design.
Sorry I need to call BS on that. Developing on your android device is approximately a thousand times easier than the entire Apple developer/certificate/code-signing dance. Running the app under debugger is also a single button click experience. To top it all, all of this is free and runs on multiple desktop platforms (Linux, windows or OSX). The relative shortage of Android developers in SF and NYC is much better explained by the original article than any sort of difference in ease of starting out in either platform.
But RELEASING your app is much easier on Android (the Play store) than on Apple's store.
We had developed some apps for some customers and it was always a chore to release them into the Apple app store.
Somebody paid us money to make an app for them and then we can't release it on IOS because you think it has no sense for people and that it was written with the wrong toolset.
It would be no problem if there was an easy way on IOS devices to use another, more open store.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway. This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes. In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
[0] https://developer.android.com/guide/topics/graphics/hardware...
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there. That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
[1] http://grepcode.com/file/repo1.maven.org/maven2/org.robolect...
It is my opinion that the main reason many Android apps lack quality compared to iOS is not Apple's review-process but the crippling SDK.
PS: If I google "Android SDK sucks" i get a lot of results. If I google "iOS SDK sucks" I mostly get the same results about Android.
I most often just use Json (because with Google Gson, you can just serialize it into an object without boilerplate).
I found it easy to start, and the documentation is quite extensive and easy to follow. This differs from my iOS experience, as xcode worked in a different way every new release, and the documentation on how to write things changed every time too, from what I could tell?
1. You will need Android support eventually (to go global, because users demand it, etc.).
2. If you try to add Android support later, you'll screw it up in ways that will be difficult to fix (e.g. porting iOS apps too slavishly, not taking advantage of Android-specific platform benefits, building a corporate culture that treats Android as second-class, etc.), especially since most of the best Android talent will want nothing to do with you.
I'm an app developer and we make a lot of money developing apps that never end up in the app stores. They are in-company apps, both Android and iOS apps.
There is a very big app market that you will never see.
It's also much, much easier to quickly iterate on Android without two-week delays between updates and a capricious review system.
But I just can't bear to return to Java, I'm not sure I ever had job satisfaction working with Java.
That we'll be able to have a cleaner interface to the platform, and have access to a better toolchain and programming environment.
I doubt it will happen, but one can hope.
Now management might change this point of view, but that was the official statement.
Just search for the Android devs fireside at Google IO 2014.
On the other hand, Rust seems higher performance and might be more suited for apps, but Google doesn't have much control over it. However they don't have control over Java either, and they could create a "fork" of Rust if needed, just like they did with Java/Dalvik.
When it comes to traditional apps, though I'm not sure how the existing Java APIs could be mapped to Go in a way that made any sense at all (I mean... technically you could do it via bridges to and from cgo<->ndk, but having it make sense in Go and be reasonably future maintainable seems like it would be a huge undertaking, even for Google). Seems more likely that something like Go+go-qml+Qt would be more practical, though I have yet to play around with the Android port of Qt enough to see if it is reasonably "native" feeling.
Languages for writing client side apps have always sucked. They sucked in the 90's when targeting Windows (ok Delphi wasn't too bad), they sucked in the 2000's when targeting MacOS X and they suck now when targeting mobile. Of all the languages that mainstream operating systems have used, Java is by far the least worst. Especially because you can use any JVM-compatible language and are not really restricted to Java. For example Kotlin is looking like it's going to be pretty nice, pretty soon.
Go would be nowhere near a useful upgrade on the status quo.
I've also never understood why Android is hated on as far as profits go. Sure nobody wants to buy anything, but (in my experience) ad eCPMs are comparable.
And I'll take Android's layout schemes over managing the house of cards that is auto layout in Interface Builder. If you're lucky you can get auto layout to do what you want with a ton of pointing and clicking but good luck maintaining that mess when you come back to it a few weeks from now. WYSIWYG tools have no place in a professional developer's toolkit, IMO. Leave that stuff to the designers.
Merging xibs and Xcode project files is another hell lying in wait for anybody doing Mac or iOS development on a team.
I'll grant you that the iOS documentation is generally better and certainly the APIs for dealing with multimedia on a lower level are far better on iOS. But for the typical listview-hitting-a-json-api kind of app life is generally easier in Android, in my experience.
The Android documentation is spectacularly good, IMO, though admittedly it is more reference focused than tutorial focused (which works for me, YMMV). Eclipse sucks but Android Studio is pretty nice, and in either case you don't need to use an IDE if you don't want to. I use Sublime Text 2 and command-line builds most of the time, using Android Studio only when I want to do on-device visual debugging.
The Java thing is a bit more true, the language can feel somewhat painful at times, especially since it is frozen in time at Java 6 for the most part, with a few little bits of Java 7 thrown in at random with little to no clear guidance from Google on where it is headed post-Oracle lawsuit.
Also there are places where the OS APIs are a bit too Java-esque in terms of being overly abstracted without a compelling reason why. Also the whole activity/fragment lifecycle and the way services work is a bit weird at first for people used to writing traditional apps, but any competent developer will learn to live with it pretty quickly. It still tends to be a sticking issue anyway because of the fact that a lot of designers (who are mostly iOS-centric, as the original article alludes to) don't really "get it" and thus design in ways that don't fit the OS app lifecycle (and don't get me started on their "pixel perfect" designs).
All that aside I had no idea Android Developers were seen as hard to find. Maybe I need a raise!
First, android has had a culture of "free, ad-sponsored" applications, whereas iOS apps have always been about paying for the stuff (not surprising if you understand a bit of apple and google businesses).
As a consequence (or because of the fact) iOS users are more likely to spend money than android users. This means that if you're doing a mobile shopping app, you expect iOS users to be much more likely to buy your products. So it's not just about market share, it's about market share times purchasing power.
That's for the market, now on the other end, about developers, saying "android" has a large market share, is not relevant. You want to speak about android market share per OS/api version. I did start developing on android, but the minute you click on the "create new project" you need to ask yourself how many android users you want to ignore (in double digit percentages). If you want to have the maximum market share you need to develop with 3 years old apis, and you'll probably frustrate users that have brand new devices. In my experience, that's where project owner decide to postpone the decision to start the android version of their product.
Then, if you make it up to this point, you need to decide what screen size you want to support and how many different version of your UI you will need to design. Note that you still haven't started a single line of code yet !
Finally, you start coding and realize the toolchain sucks pretty much. Xcode is obviously much better than anything on the market and i won't even start talking about the simulator (which is important as soon as you need to test on different screen sizes).
All in all, most of the time android feels like developing for a second grade market, having second grade devices, with second grade tools, on 3 years old apis. No wonder developers don't rush for it..
By far most of the time is being spent finding out why something doesn't work on a Model X which is sold only in South Korea and is kinda like a model sold here except with totally different chipset and different driver version. In the end you report a bug to the driver manufacturer and receive an answer "This has been fixed in our internal release" and it will never be supplied to the current phones in the market.
Sure there is a similar effect in other areas, but it's not nearly as bad as it is in mobile.
With Android Wear the whole ecosystem will attract new talent. And the new Material Design seems to be well accepted from designers.
So the apps quality should be better and company will be willing to have a great product in both platforms.
http://blog.teamtreehouse.com/java-basics-for-android-develo...
http://developer.android.com/training/index.html
Edit to add that applications are usually developed in the Java programming language using the Android Software Development Kit, but other development tools are available.
Edit: here's a link https://www.udacity.com/course/ud853