The general consensus from my extended network of mobile developer friends and acquaintances:
Android is harder to develop for than iOS - you will spend more time and effort on building something nice than you would in iOS. Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming. No one I know is doing WebOS (Palm) development.
Also, the money in mobile development is almost always from making apps for companies and organizations that want to have their own app (e.g. consulting). This is from my knowledge of how my friends are making a living. Yes, they have their own apps but to succeed in the direct to consumer device marketplace is really is more about being a better marketer, designer than a mobile developer.
The consumer who downloads your program only sees the tip of the iceberg (the UI, the functionality, the user experience). Does it make them feel cool (or appear cooler to their peer group) and/or add some bit of value to their life workflow? They don't care how it was made. Note: This is why HTML5 apps are at a disadvantage - there is only so much you can do with Canvas.
Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming.
Which is incorrect, because WP7 and Silverlight are comprised of .NET technologies. There are some new APIs, but C# developers can make extremely smooth transitions, similar to Mac OS X->iOS.
I apologize for spreading misinformed data. Please forgive me.
The last MSFT experience I have is circa VB6/ADO. I will chastise my .Net acquaintance for giving me the impression that WP7 was hard for .Net/C# devs - and, myself, for spreading misinformation.
Personally, when I looked at it (about 2 yrs ago), I didn't know where to start. How did you learn XAML, MVVM? Just brute force and practice? I'd love to be able to do a Zagat-like WP7 app. To be able to know what the custom part of that app development was.
I didn't know where to start. How did you learn XAML, MVVM?
Personally I'd start by using Blend. While the drag and drop approach is largely criticized, it's a great tool for seeing the Xaml get built as you build the UI. And the actual markup generated is quite good.
You don't need to know or use MVVM to do Silverlight apps. It can be useful, but I wouldn't try to learn that first. And if you make use of databinding whenever possible, you'll almost have to contort yourself to not do MVVM (although you'll be data-bound against properties in the code behind... this is easy enough to change).
The Zagat app is beautiful, and honestly, really straightforward to do most of the Silverlight stuff I saw. Like literally, I think if you know C#/.NET you could get a similar looking app up in a week.
The hard part... having the Zagat data. But seriously, a C#/.NET dev should be able to be modestly proficient in Silverlight over a weekend, IMO.
I don't want to launch my own apps, I just want to consult. I've only recently learned to develop for Android (did some very cheap consulting gigs - including porting a small game for practically free).
- Launch a couple of apps into the Market, and get some good numbers (number of downloads, rating). Yes, this is easier said than done, but this is essential for your learning too
- Have a personal page where you showcase your applications. Ideally accompanied by a blog
- Update your LinkedIn
I'm not interested in consulting, but I've had several requests. Usually they have had a look at the three of the things I mention above.
I guess generic advice by freelancers on finding clients should help you too.
Put Android Developer in your profile on LinkedIn. I don't know how successful it ultimately ends up being, but you'll certainly get spammed with recruiters trying to find Android developers.
That sounds like an inverse lamentation. I'm pretty sure I remember a couple of dev's in the cocoa blog world complaining about the amount of unsolicited consulting requests they got after launching a couple of somewhat popular apps.
Two things: Device fragmentation and the UI layout
Device fragmentation means that you will need to test your app on multiple Android devices and operating systems to ensure the experience you built is up to par with what the user sees
UI layout: To build a decent UI requires taking the wayback machine to Java Swing and GridBagLayout. It is getting better though with Gingerbread.
Third thing: Too much decoupling in the development environment
I can. My opinion might be biased because I don't do iOS development (but all my friends do), instead I do Android, WebOS and Bada development.
So, here are a few reasons:
1. On iOS, if you use the native interface the app would look good. On Android, it will look like crap :-)
2. On iOS you have predefined UI effects and transition, on Android you'd have to do custom
3. iOS is faster, and has a much higher memory limit than Android. Allows apps to use more resources (because it's not multi-tasking)
4. iOS doesn't have a capped app size. Most Android phones have application storage limited to around 10Mb. Android introduced lately support for installing apps on external storage but.. check #5
5. Fragmentation. You currently have to suppor 2 major Android versions (4 minor). Believe me, that really caused me a lot of problems in the past 2 years
6. Screen sizes. On Android, you currently need to support 5 different screen size ratios, as well as over 10 screen sizes. handle that!
for #2, we're simply in the woods. Android has support for some basic transitions, but because of the nature of the OS, you can't use them to create screen/tab transitions. So, the usual process for this is:
1. move object X pixels
2. wait Y milis
3. go back to 1 until you're done.
on #6 Android has support for a limited range of display setups, making it fairly easy to provide different UI resources for small, medium and large screens. If you want to start supporting different aspect ratios (the Droid is a good example), you have to either start detecting resolution at runtime and modify layout accordingly, or make sure you build your layout in such a way that it will adapt itself to the aspect ratio. The later is preferred, but always needs extensive testing (hopefully on real devices) because every minor OS version messes up something (1.5 has problems with PNG transparency, 1.6 with 'center' positionings, etc...).
I was under the assumption that view classes on android were harder to work with compared to a UIView, which can be subclasses and re-worked with new behavior.
Or, at least that's the reason my friend gave for not developing an interface beyond the default UI for his app.
I have no experience with iOS development, but in Android you can extend classes for views and provide custom behavior for most things you'd want to customize. You also can configure quite a lot of the look and feel of the interface entirely using configuration files - this includes animations when you do things like touch buttons, border styles, colors, fonts, etc. I find it fairly easy to work with.
We could do with a good GUI for designing interfaces, but it's not horrible once you grok the layouts work. Google have acknowledged publicly that the current UI builder in Eclipse isn't good, but there's no public schedule that I'm aware of for when that will be improved.
I became a full time android developer about 45 days ago and had been dabbling before that for about 2 months. A few points and comments about the article.
- If you are going to pick up a phone to do android development, my recommendation would be a used original Droid or the HTC Desire. And its not because these are good phones but because these are the phones that I see a lot of people using. I have a Nexus One and I find that it is too powerful and does things other android phones can't. (read on)
- Understand what device fragmentation means for your development. Are you creating a form based native application? Different handsets generally handle native layouts, text and buttons very similarly so fragmentation may not be a huge issue. Are you creating a game or an application that uses video/audio? Prepare to be buried in a multi-dimensional matrix of hell :) As an example, take for example streaming raw AAC audio from the internet. Android as a base platform does not support this in hardware or kernel, but some sprint phones do support this.
- Keep in mind the relative power of the different devices. As with most emulators, the Android emulator has slow draw times and fast network times (though network can be adjusted). Just keep in mind that, if you have a device, where does it rank in the spectrum of devices. Developing an android app that runs 'smoothly' on a Nexus One can leave a lot of customers having a 'jerky' experience. Some of this, in my experience, is also cause by poor design decisions.
How hard is it? Doing something trivial is, by design, trivial. A todo list app would take you, with knowledge of any other programming language, less then 8 hours. I find that the expensive part of the process is knowledge of the fringe, as with all things. Things like knowing how button requests cascade, how a view hierarchy should be organized or how to stream media (can you tell I'm hung up?) are the sorts of things that aren't extremely well documented and take more time to understand than similar concepts for web programing (IMO).
> As an example, take for example streaming raw AAC audio from the internet. Android as a base platform does not support this in hardware or kernel...
Have you tried streaming OGG audio? I've been looking at doing an streaming audio app, and by all accounts, OGG is properly supported by base Android. I'm willing to add an OGG encoder backend because I already had to do that once to get iPhone/AAC support, but if OGG doesn't really work then I might try a different approach.
In my experience streaming raw OGG has worked well. I have very limited experience with anything besides raw AAC as, thats what all my clients were using.
Developing on the N1 was perhaps a mistake. We became used to the speed of it. When I finally started testing on the Droid I had to go back and do a bunch of UI optimizations.
Thanks for the offer. I've been trying to get started with Android development, but I keep getting stuck in the first stages of learning java. I have worked extensively with C and Matlab before, but I have no idea of OOP concepts. Frustrated with Java, I've been learning Python and that's going along at a nice clip. I really want to get over this hump. I have tried skipping the Java tutorials and directly looking at the source code of applications, and after a month of trying, still can't make head or tail of it. I'd appreciate any pointers you may have.
Buena suerte! You'll ease into it. I have a friend who is struggling with OO as well. He really gets lost in the decoupled nature of the language and development environment.
Take a look at Bruce Eckel's free book "Thinking in Java" (3rd Ed)
Thanks for great comment. It adds a lot to my post. As you have written the biggest problem is the Android versions fragmentation (but it is getting to look better) and many of devices on the market (as I have written you will never be sure if your app works well on all of them).
My biggest obstacle in getting into Android development is thinking of ideas for apps to make. It seems especially hard to think of simple ideas that would make a good first project.
When I try to sit down and do a "toy" app to learn the platform better I find myself getting bored because I'm not excited about the app I'm making.
Does anyone have an advice on finding or coming up with ideas?
Or better yet, does anyone need a simple app made? (Maybe I should do an offer HN if that's still around).
>My biggest obstacle in getting into Android development is thinking of ideas for apps to make.
I just got a Droid X. I had been trying to brainstorm ideas for dev'ing on it but realized on my commute home yesterday that was the wrong way, for me, to go about it.
Basically I need to just use the phone and anytime I think "wow, i could really use X to do Y" go and try to find X, and if I can't maybe work out a plan for developing X myself.
Like on my commute, I have several routes I can take. I got the idea to make an app that collects statistics based on time of day, route, speed/traffic that will help predict which route is the best depending on when I leave the office.
And hey! It already exists. But can I compete? Or should I just be happy someone already did the work for me?
I can easily say more than 80% (might be well more than that, just taking android into case) of users are non technical and taking their needs in a mobile phone might turn out to be a great idea.
You don't even need to use an IDE if you don't want to. Google, in typical hacker-friendly fashion, has provided pretty complete instructions for developing in your environment of choice. Personally, I use vim, but in case you're not as masochistic/in love with vim as I am, the instructions should work just as well for your favourite code munger.
Even better is using Eclipse with the Vrapper plugin to get Vim emulation from inside the IDE. There are some limitations, but for when I need to work on Java code, it's much better to use Eclipse+Vrapper than to go without any of the IDE benefits.
If it is not considered off topic, I'd like to hear if anyone has used Rhomobile* to develop an android app. Even better if you can share experience as a Rails programmer making the jump.
* Rhomobile/Rhodes is a Ruby framework for developing Android and iOS apps from the same codebase.
Any answer to such a question is at least a little 'how long is a piece of string' in nature. It might help if you added some examples. How competent is competent. How hard is hard.
From where you started, how long did it take to be able to create a basic own use app with a quanta of usefulness. If it makes it easier, compare it to starting in php. In the time it would take a non web programmer to learn enough to make a do list app, how far would you get in android?
It took me about a month to write my first useful app - "WP Stats" for Android. I think it is quite fast especially I have not even known Java too well...
Excuse me if this is a little off-topic, but the article just reminded me of it. There seems to be a recent trend over here of stories in HN appearing before the actual news. See speculation about recent NASA and Apple announcements. Sometimes, I can't find later stories that tell "the answer".
What ever happened to new Google Phone? I was first planning to buy the Desire for programming, like you. But the possibility of a "clean" phone has me waiting...
Yesterday google has presented new Nexus S and most probably it will be available for sale in a few days/weeks and it will come with Android 2.3 (Gingerbread). So it may be really good idea to wait for it :)
> It is helpful to test your app with real touch screen but for most cases an Android phone emulator (that is included in Android SDK) is really enough.
This is a very good way to release complete garbage.
Not really. Trust me, there will come a point when it's phone or nothing, and that point comes sooner than you think. Like ALL mobile emulators, the android emulator is slow, buggy, and frustrating to use.
What phone do experienced Android developers recommend getting? The Droid X, Droid 2, and HTC Incredible are seemingly the most popular ones people are buying in the stores, but I was thinking of getting a Droid 1 or Nexus One for development. The Droid 1 is a bit slower and I think it is best to develop for slower hardware than for faster hardware, and the Nexus One is seemingly the fastest to be updated. Any recommendations?
Original Droid and you can have updates very soon after N1 gets them thanks to Cyanogen. You also will be working with a bit more limited resources - less memory, and slower processor, which should help save you from writing stuff that will only run well on the N1. The Droid is very capable for foreground processes, but once you start running too much, the memory constraints kick in - this can be useful to test if you rely on a background service.
Once the Droid is rooted and has a good recovery image loaded, you can back up and go from "Stock" to some aftermarket ROM for testing a variety of scenarios if needed.
I would recommend testing with an HTC Incredible as well - with that, there's the possibility of switching between Stock HTC build and Cyanogen using the bootloader (requires "rooting"). I'm finding quirks with SenseUI (most annoyingly, the keyboard throwing the same event multiple times) that I would have never caught without the device in my hand.
Also, keep in mind depending on what you're doing, some built in Vendor app (Verizon, etc) might interfere, so testing on a purely stock Google build phone might cause you to miss something.
Nexus one. Hands down the best phone given that carriers can't cripple it or clutter it up with crappy apps or extra branded ui. Use it on T-Mobile with their out-of-contract plans.
I'm going to disagree with most. Don't get the Nexus One if you plan on having customers. Its far to powerful to accurately tell you what experience your typical users will have. I have three, Nexus One, myTouch3g and G1. I find that the myTouch gives me a pretty good representation of a user handset (though mine is currently at 1.6 and nearly 65% of my users seem to be on 2.1+)
I have been wondering for very long whether there are VM images for all Android releases including custom ROMs? Can they even be virtualized? Agree that cellular and other features like GPS might not work but at least we can test with different setup right?
Go for something cheap. The charm if you have tmo is $250.
You have to code to OLD versions often to get huge marketshare due to the fragmented install base so the updateability isn't as important as just buying a cheap one every year or so.
The hardest part of becoming an Android developer is the steep learning curve - Google doesn't exactly do you a lot of favors with it's documentation there. However, relative to the learning curve, it's no more difficult to pick up the requisite bits of software and start learning than it is to become, say, a Rails developer (I've done both professionally).
Developing apps for Android isn't especially hard - much of the documentation is geared toward that.
Developing on Android itself (porting to new devices, adding functionality, etc) is insanely difficult and very poorly documented (if at all).
Funny, from my experience i'd have said the exact opposite. Then again I started out on J2ME feature phones, so "difficult" porting is a pretty relative term for me ;)
Stopped reading as I found a grammatical error on the first line. I mean, I could just accept that articles that people put on their personal websites might not be copy-edited by professional editors and that despite errors they might be useful or interesting. Probably easier to just dismiss the whole article though.
"Ask HN: Jumping into Android Development"
http://news.ycombinator.com/item?id=1347170
The general consensus from my extended network of mobile developer friends and acquaintances:
Android is harder to develop for than iOS - you will spend more time and effort on building something nice than you would in iOS. Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming. No one I know is doing WebOS (Palm) development.
Also, the money in mobile development is almost always from making apps for companies and organizations that want to have their own app (e.g. consulting). This is from my knowledge of how my friends are making a living. Yes, they have their own apps but to succeed in the direct to consumer device marketplace is really is more about being a better marketer, designer than a mobile developer.
The consumer who downloads your program only sees the tip of the iceberg (the UI, the functionality, the user experience). Does it make them feel cool (or appear cooler to their peer group) and/or add some bit of value to their life workflow? They don't care how it was made. Note: This is why HTML5 apps are at a disadvantage - there is only so much you can do with Canvas.