I'm VP of Engineering at Tasktop Technologies, improving the effectiveness of developers worldwide via Tasktop's revolutionary task-focused interface, built on the Eclipse Mylyn open source framework. David has posted 28 posts at DZone. You can read more from them at their website. View Full User Profile

Android vs iPhone Development: A Comparison

07.06.2009
| 74977 views |
  • submit to reddit

A few months ago I ventured into the world of Mobile development and created an application (Hudson Helper) for both iPhone and Android. This article is about my experiences, comparing Android and iPhone development with a focus on tools, platform and the developer experience.

Before going much further I should note that my comparison is with considerable bias. I’ve spent the past 12+ years in Java development, having spent much of my career building developer tools. Since January of 2004 I’ve been building plug-ins for Eclipse, and before that plug-ins for NetBeans. This bias is somewhat tempered with several years of C and C++ development. With this background I find that I’m very critical of developer tools. Developer productivity is key — anything that takes away from the flow of a developer in the zone is a real problem.

Language, Programming Model and Platform

Language

The language of choice for iPhone development is Objective-C. Objective-C is a language based on C with extensions for object-oriented concepts, such as classes, inheritance, interfaces, messages, dynamic typing, etc. The Java language is used when developing for Android (though it doesn’t actually get compiled to bytecode).

Java is a no-brainer. I have to say that it’s nice not to have to learn a new language to target mobile. Existing skillsets don’t come easy — so reuse of expertise is worth a lot.

It took a little while to wrap my head around some of the language features available with Objective-C. I soon discovered that I really loved certain language features, such as message passing (instead of calling methods), categories and named arguments. I did find however that the syntax of Objective-C is cumbersome. I’m still not used to ‘+’ and ‘-’ for static and member methods, too many parentheses are required, and in general I just felt like I had to type way to much to express a simple concept. The IDE didn’t help much with this either (more on that later).

One thing that really became clear to me is that Objective-C, though it may have been visionary for its time, is really a language of the '80s. Certain issues such as split header and implementation files and violation of DRY are really time-wasters, and not small ones at that. I found myself constantly switching back and forth between files, which not only has a cost in navigation (which file to open?) but with every file opened your sense of context must be recreated (where’s the caret, what’s selected, where am I in the file, how is this file organized).

As far as DRY, must I really do 5 things to declare a property?? (declare in the class definition, again to declare getter/settter, initialize in the init method, @synthesize in the implementation, release in dealloc). Here’s what I mean:

Server.h

@interface Server : Updatable {
NSString *name; <-- declare the property
}
@property (nonatomic,retain) NSString *name; <--- declare the property again

Server.m

@synthesize name;  <-- implement getter/setter

-(void) dealloc {
[name release]; <-- release memory
}

If you ask me, everything in Server.m should go away. Another gotcha here is the positional relevance of @synthesize.

Java has a similar problem with properties, though not quite so bad — and the IDE helps you write your getter/setter.

Pointers in Objective-C, though powerful, are also another time-waster. This is where Java really shines with its garbage collection. I found that I was constantly considering whether allocated objects were freed appropriately. Code flow is poor since application logic is littered with memory management. I only have so many brain cycles available — why do I have to think about this other cruft that’s not really a core concern of the application domain? Of course this gets even worse when trying to figure out where things went wrong if you make a mistake. Zombies help, but still don’t make it obvious if you’ve accessed something that was deallocated. Other issues include deallocating something twice, autoreleasing something twice. I also found it non-intuitive when to retain return values from methods.

Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial. @synthesized getters and setters for properties with retain should not be called in these methods. So many conventions and rules to remember!

Though I understand why there’s a separation of alloc and init, it’s still overly wordy to specify [[aloc Foo] initWithArg: arg]. Why not just [new Foo arg]? Or how about new Foo(arg) -- oh, wait, that’s just like Java!

Objective-C’s imports and forward-declarations (@class) are a pain. Though these issues exist with Java development, Eclipse’s JDT is so good that I’ve almost forgotten what it’s like to write an import. All you have to do is Ctrl+Space to auto-complete a class name or Ctrl+Shift+O to organize imports and voila!

Of course Java is not perfect either, however this fact is hidden from me due to the fact that I’ve been living in Java for a very long time. Sometimes I wish that Java were more Groovy-like, however I’m used to it and the tooling is so good.

Platform

On Android I found that I could readily use the Java runtime classes. Some, but not all, of the standard Java RT classes are available on Android. I didn’t find this a problem, since most of the standard Java IO, network and regex libraries are available. Android RT classes appear to be based on Harmony, which has been around long enough to be stable.

With iPhone on the other hand, finding the functionality that I needed was painful. Classes and methods are poorly organized. When to look for a static method versus a class with members was not clear to me. Also depending on the framework used, naming conventions and code organization would differ. I suppose this is the legacy of an older platform. Areas where functionality was lacking that I found painful were regular expressions, string handling and XML parsing. I ended up using the excellent Regex Kit Lite for regular expressions. For XML parsing I implemented a parser abstraction over libxml, only to discover later that I may have had an easier time with NSXMLParser which is a lot more like SAX.

On the iPhone when things didn’t work as expected I had to resort to Google and hope that others had encountered the same problem. This technique was hampered by Apple’s earlier NDA policy, which meant that iPhone content is pretty thin on the net. In some cases I would resort to guesswork and experimentation to find a solution.

Android has the benefit of being open source. Within minutes I had the full Android platform source code on my system, and had re-built the SDK from sources to ensure that the source I had matched the runtime classes in the emulator. So not only could I see how things were implemented in the Android platform and learn by example, I could step through the platform code in the emulator and discover why my code wasn’t producing the desired results.

In general I found the layout, organization, and naming conventions of Android platform classes was consistent and predictable. This made it much easier to learn.

Programming Model

The iPhone platform does a great job of encouraging an MVC design pattern. With this design pattern built in to the platform, building the UI was simple and I didn’t have to figure out how to organize the UI component design myself. It also means that when looking at sample code, it’s all organized in the same way.

Android also does a good job with design patterns, though their concepts varied significantly from the iPhone. With Android’s support for multiple processes and component reuse, the platform itself provides support for Intents and Activities (an Intent is just a variant of a command). The design results in a better user experience, however it does introduce some complexity for the developer: when starting one Activity from another, an Intent is used to communicate any parameters. These parameters cannot be passed by reference — only by value. Where on the iPhone it’s simple to have screens sharing the same data structures, on Android this requires some forethought. Apparently Android applications can manage the back button and have everything occur inside a single Activity, however this is not the norm.

Both Android and iPhone provide a way of declaring user preferences in XML. Both platforms provide a default UI for editing those preferences, which is great. Android’s XML format is extensible allowing custom UI components to be integrated, which makes user preferences a breeze. iPhone developers that wish to customize preferences will have to implement a UI from scratch, which is a lot more work.

Testing and Continuous Integration

I’m of the opinion that every development effort should include unit tests. Teams of size greater than one should also include Continuous Integration.

Android developers will be happy to know that they can write JUnit tests. I could even launch these from the Eclipse UI after some classpath fiddling. Though I didn’t try it, I assume that it’s trivial to run these from Ant and your favorite CI server such as Hudson.

I did see some iPhone unit test documentation with the iPhone SDK but didn’t take the time to explore it — so I can’t comment there.

Resources

Apple does an excellent job of providing lots of resources for developers. Important concepts are explained in videos, which makes grasping concepts easy — however I did find that videos progressed slowly and I was watching for what seemed like hours to find information that should have taken minutes. Luckily Apple also provides lots of sample applications and code to demonstrate API usage.

Android developers also have access to loads of resources. The guide and API reference are installed with the SDK, so everything is available when offline (which for me is important since I do a lot of my work in transit). I found the Android development resources better organized and spent less time looking and more time finding. In particular the ApiDemos sample app provides a great starting point. I also downloaded many open source Android projects for ideas on architecture and API usage. This is an area where Android has the advantage, with Apple’s previous NDA policy there isn’t much out there in terms of open source for iPhone.

Tooling

For me tooling was a real shocker. These are the categories of tooling that I’ll cover: IDE, UI builder, debugger, profiler. Almost everything else is related to provisioning, and in that area I didn’t notice much in the way of differences between Android and iPhone.

IDE

Android development leverages the excellent JDT tools, which are pretty much stock and standard with every Eclipse installation. I’ve used these tools now for many years and they’re excellent. Everything Java is indexed, the IDE has a rich model of the source code, and refactoring is so seamless that it has changed the way that I work.

Perhaps the best feature of JDT is its incremental compiler, which provides immediate feedback with errors and warnings as you type. This eliminates the code-compile-wait-for-feedback cycle that was so common in the '80s and '90s. Errors and warnings are updated in the Java editor as I type, giving me instant feedback. I didn’t realize just how valuable this feature is until I was coding Objective-C in XCode — when I became acutely aware at how waiting for compiler feedback can break the flow of programming.

Other key features that make Eclipse so amazing to work with are:

  • content assist
  • quick-fixes
  • organize imports
  • open type (CTRL+Shift+T)
  • refactorings

Integrated javadoc and content assist is quite possibly the best way to learn an unfamiliar API. In Ecipse not only are all classes and methods immediately available in the context in which you’re writing code, their documentation is presented alongside.

Content Assist with Integrated Javadoc

XCode is so shockingly bad that I almost don’t know where to start. Here’s a minimum list of things that I think need fixing in order for XCode to become a viable IDE:

  • Content assist that actually works. Content assist provided by XCode is often wrong, and almost always suggests a small subset of what’s actually available.
  • A decent window/editor management system. XCode and it’s associated tools (debugger) like to open lots of windows. Want to open a file? How about a new window for you! Very quickly I found myself in open-window-hell. The operating system’s window management is designed for managing multiple applications, not multiple editors within an IDE. It’s simply not capable of providing management of editors in an environment as sophisticated as an IDE.
  • A project tree view that sorts files alphabetically. Really!
  • Integrated API documentation. I found that I was constantly switching out of the IDE and searching for API documentation using Appkido. This may seem trivial, but it really breaks the flow.

One area of Eclipse that simply can’t be matched is Mylyn. Integrated task management and a focused interface introduce huge efficiencies into any project, small or large. If you haven’t yet tried out Mylyn, it’s definitely worth your time to take a look. A good place to start is Mylyn’s Getting Started page.

UI Builder

iPhone app developers are given a pretty good UI builder. It does a great job of showing the UI as it will actually appear. It’s flexible and can model some pretty sophisticated UIs, so I was impressed. I found that using it was a little tricky — I had to read the documentation two or three times before I could really figure out how to use it properly.

The Android UI builder I found pretty useless: it can’t display UIs how they’ll actually appear, and it’s UI is way too inefficient. I found that I coded all of the UIs directly in the XML source view of the UI builder. There the content assist and validation were pretty good, making it the easiest way for me to build a UI.

Debugger

Having used to the Java debugger in Eclipse I was shocked at the state of the debugger in XCode. With Eclipse I can see and modify variable values. Not so in XCode. Maybe this is simply the state of affairs when debugging native code, but it sure affects the usefulness of the debugger. XCode often seemed confused as to the type of an object and presented me with a pointer value and no detail. This is a sharp contrast to Eclipse, where I can drill down through an object graph with ease.

I found the XCode debugger UI extremely difficult to use. Clicking on the stack to show code in an editor caused new windows to open, eventually resulting in dozens of windows open. In addition I found that watch expressions rarely worked for me.

Profiler and Heap Analysis

An area where Apple development tools excel is in profiling and heap analysis. These tools seemed mature and easy to use. With no prior experience with these specific tools I was able to gain a better understanding of my app within minutes, find and fix several memory leaks and improve performance.

XCode Memory Leak Detection

Android developers must use Android’s traceview application, which I found worked well but required significantly more effort to configure and operate. I was surprised to find that the source code must be changed in order to get the trace files required for analysis.

I’m not sure if Android can provide heap dumps in hprof format. If it can then the awesome MAT tool could be used to analyze heap usage. According to this article Android can produce hprof heap data, though I haven’t tried it.

App Store

It goes without saying that the iPhone app store is excellent in that you can sell into many countries worldwide with a single setup. I was able to provide my Canadian bank account number, sign a few legal agreements and I was up and running.

Getting an app into the store however is frustrating to say the least. Apple must approve every app before it is accepted into the store. Mine got rejected multiple times. Each time it was rejected I was given almost no information about why. When I emailed them to clarify the problem, I received what looked like a canned response indicating that I should refer to previous correspondence. If it weren’t so frustrating I would have found it funny. I highly recommend reading Brian Stormont’s Avoiding iPhone App Rejection from Apple and Dan Grigsby’s Part 2 follow-up.

Of course once I started selling Hudson Helper I realized that Apple won’t send me any money unless the payout is greater than $250. This is true not only of the first payout, but every payout. Google market on the other hand requires a minimum of $1 for each payout. Both the iPhone app store and Google market take about %30 of your app selling price. $0.99 applications have to have high volume, or they’re simply not worth your time.

The Google market by comparison to the Apple app store is terrible in that you can only sell into a handful of countries. You also can’t see or install apps that cost money on a developer phone. Actually you can, but not if the app has copy protection — which is almost every non-free app. On the other hand when you upload your app to the app store it’s available within minutes, so you don’t have to worry about an approval process.

To set up a merchant account with Google market, I had to provide a US address and bank account number, since Google doesn’t support Canada. For me this was a pain, but not too bad since I live within a few kilometers of the US border. I rode my bike down to the US and opened an account with Horizon bank. The bank required a passport and driver’s license, so no problem there. Why Google doesn’t support more countries I don’t know. At the very least Google market should accept alternate payment methods for countries that are not supported by Google checkout.

Summary

Android’s platform and developer tools are excellent. Leveraging Java and the Eclipse IDE are major winning factors for Android. Apple’s developer tools are shockingly bad by comparison. The Objective-C language and platform APIs are cumbersome and poorly organized. Overall when developing for the iPhone I felt like I was back in 1993. These factors combined in my estimation make application development about three times more expensive when developing for iPhone. The only area where Apple’s developer tools excelled was in profiling and heap analysis.

Apple’s app store from a user’s standpoint and from a worldwide coverage standpoint are excellent. In this area Google market for Android is weak.

Development for iPhone may improve as tools such as iphonical (MDD for iPhone) and objectiveclipse (Eclipse plug-in for Objective-C) emerge.

We may see a shake-up in the mobile market, with at least 18 new Android handsets being released this year. Until that happens, iPhone will remain a market leader and developers will have to put up with XCode and Objective-C.

For me, my love is with Android. Sure, the iPhone is great — but can you install a new Linux kernel?

From http://greensopinion.blogspot.com/

Published at DZone with permission of its author, David Green.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

James Jamesson replied on Mon, 2009/07/06 - 4:44am

Google needs a focus, and it is the search. No comparison is necessary. Android didnt fly and wont fly. Unlike andriod, IPhone is made by a focused hardware and software company not by a search engine service provider. Google should focus on what they are best at, the www search. All the other products they have are either beta or alpha quality.

Artur Biesiadowski replied on Mon, 2009/07/06 - 5:30am

Android phones are made by dedicated hardware companies. Do you suggest that decoupling hardware manufacturer from OS provider is bad thing? Somehow I enjoy world of Linux and Microsoft more than IBM and Apple as far as development is concerned. On top of that, this article is about quality of development environment, not about the phones themselves - and sorry, but android development environment is generally a lot nicer and more open place.

I would probably not go into Objective-C versus java discussion - too much 'taste' involved here, plus discussing it on javalobby it bit counterproductive.

Oliver Plohmann replied on Mon, 2009/07/06 - 7:29am

I found the XCode debugger UI extremely difficult to use. Clicking on the stack to show code in an editor caused new windows to open, eventually resulting in dozens of windows open.

The is the way to develop in Objective-C as inspired by the Smalltalk IDE. It's conceptually a different approach. The eclipse folks knew why they left it as an option for former Smalltalk people and other people used to IDEs on a higher level than VisualStudio to be able to have several browsers of a different kind open at the same time.

Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial.

 This is always non-trivial when memory management is manual and not done by a GC. In Objective-C 2.0 there is an optional GC. However, it cannot be turned on for iPhone development, because a cell phone has tougher memory restrictions than a PC application. You cannot have ease of use for the programmer and memory efficiency at the same time. This has nothing to do with weakness of Objective-C. It is made for efficient memory usage. I know Java developers that use Java for embedded things. They are constantly in trouble, because their application another time has run out of memory and there is almost nothing they can do while the customer is getting mad at them. If this is what you prefer, stick with Java.

@synthesized getters and setters for properties with retain should not be called in these methods.

You don't have to use @synthesized if you don't want to.

Objective-C’s imports and forward-declarations (@class) are a pain.

Forward declarations in Objective-C work exactly the same way in Objective-C as in C++. You have to split those things apart, otherwise the compiler would get into an endless loop and also separate compilation would not be possible. You seem not do understand that Objective-C like C++ or many other languages is a statically linked language and not a dynamically linked language like Smalltalk, Java, Ruby, Groovy. Those things are conceptually different and this has nothing to do with good or bad. In Objective-C you cannot run into a situation where something compiles but does not link at runtime as in Java and that is a good thing on an embedded device.

Objective-C is made with efficiency in mind. You can fill an Objective-C method with C code without a problem since Objective-C is an extension to C. In Objective-C 2.0 you can put an C++ object into an Objective-C collection if for performance reasons you are making use of a C++ library. By contrast, calling C functions in Java when you have a performance problem is a big pain. Your comparison only works in a brave new world where memory and cpu resources on your embedded device is never an issue.

When you write such an article you should mention that you are aware of the differences, but you belong to that camp or that other camp and therefore you tend to see things this way or another way. Not having done so gives reason to the suspicion that you are comparing oranges and apples without knowing.

 Cheers, Oliver

James Jamesson replied on Mon, 2009/07/06 - 8:40am in response to: Artur Biesiadowski

I would not comment on your taste of development environment because that is your taste. What I see from the market though, development taste of individuals does not count. Apple has created a superior development ecosystem for IPhone and made an excellent penetration with ITunes app store. Android on the other hand will take its place in the market as yet another Linux based experiment however this time from an internet search provider(!). If it is better suited for the platform, Objective C would be preferred over Java or vice versa. I would never pursue a discussion on language superiority because that is nonsensical. Languages are just tools for the goal, and yes I would prefer this forum to be Java only.

Serge Bureau replied on Mon, 2009/07/06 - 8:38am

Not really objective or even accurate account of the IPhone development kit. It is decade ahead of anything Google can even dream. Firts objectiveC is dynamic, without loosing efficiency by keeping C roots. It is in fact totally loosing C++ in the dust and most modern dynamic languages. But the best part is the libraries (frameworks on the IPhone), they are just fantastic. How about having a webenabled view in one line of code ? And not any browser view, the best , Safari. All the libraries are doing 95% of the job, only your add on is what you concentrate on. The delegate pattern while not a new concept is the only place I have seen all over the libraries, Google and SUN should go learn. Look at the UIToolkit, and then go cry looking at SWING. In more than 10 years there is no real browser component of any value, even if you pay, no valuable text editor component, no valuable multimedia player. Also the fact that objectiveC is dynamic you can add all the capabilities you wish and be working in the new code as well as the old one. I do Java for 14 years, objectiveC and the IPhone framework made me realise that Java failed on most issues. And that C++ is a pathetic language.

Artur Biesiadowski replied on Mon, 2009/07/06 - 9:19am in response to: Serge Bureau

Look at the UIToolkit, and then go cry looking at SWING. In more than 10 years there is no real browser component of any value, even if you pay, no valuable text editor component, no valuable multimedia player.

How from Android topic you went to Swing?

Topic is about:

1) Java-the-language versus Objective-C

2) Android development tools versus iPhone development tools (environment)

As far as point 1 is concerned, you can use Scala on Android and get best of both worlds. How many other languages can you use on iPhone if you happen to not like Objective-C?

Casper Bang replied on Mon, 2009/07/06 - 10:30am

SDK and developer experience is highly subjective, although this is a fair attempt at comparing them. Few people would argue against how the Android SDK offers both newbies and seasoned Java developers a way into mobile phone development. I doubt if the success of the iPhone has anything to do with SDK.

That, plus the expected 900% growth this year (20 Android phones to launch) is likely to ensure Android will gain in on the iPhone, which has at least one years advantage on the marked. Particular Americans seems to favor the iPhone so I think their view is tainted, largely ignoring the international marked. I expect Android to steal significant marked from the top #1 handset supplier, Nokia.

In the end, it all comes down to choice. Do you want to avoid the Apple tax? Be able to select from a multitude of phones? Install a larger memory? Carry an extra battery? Run Flash, Java and other non-Apple-sanctioned stuff? Develop from Windows or Linux? Write in alternatives such as Scala, C#, Python or Lua? Write a multitasking application?

...then Android is a clear winner!

Osvaldo Doederlein replied on Mon, 2009/07/06 - 10:08am

Good writeup. I've got my toes wet on the ihone SDK, admittedly not months like you, just a few days; but I had the same impresion. Some of the iPhone backers criticised you for not 'getting' Obj-C or manual memory mgmt but I think they are off base.

Speaking for me, I have large prevous experience with C++ and decent knowledge of Smalltalk, [both quite rusty now I admit] so learning Obj-C was a matter of hours for me. In fact, I'm old enough to have read Brad Cox's classic Object-Oriented Programming, An Evolutionary Approach, when I was in the college. But Obj-C is sufficiently old, so I had completely forgotten about it by the time the iPhone appeared.

I agree with your comment that this language is a relic from the 80's... there's no way to masquerade that. And don't get me started with the frameworks, they have a design that's also miserably dated (the OO paradigm evolved a lot since the NeXT days). Or with XCode, I'll rather pull a tooth than use that monstrosity on a daily basis.

FACT: both Obj-C and the OpenStep family of frameworks were total flops after the NeXT days, except for the MacOSX/iPhone niches; they would be RIP many years ago if Apple didn't keep these technologies artificially alive by making them mandatory for their platforms. The GNU folks even implemented free compatible compilers and libraries, and these are some of the most ignored Free platforms ever (gcc-objc and GNUstep).

Apple did some improvements in Obj-C 2.0 but they din't impress me. See for example GC: it's just the level of sophistication of Java's GC back in 1996 - conservative algorithm, and unlike Java it won't become significantly better in future releases, because there are big hard limits to the GC design space in a language that's not fully managed. 90% of the high-end stuff we got used in the best JVMs, simply cannot be implemented. I think the Mac apps only get away with such GC because they don't rely heavily on it - they can easily mix in manual or custom memory allocation whenever things get tough.

My general impression is that MacOSX/iPhone developers only put up with the inadequacy of Obj-C because it's forced through their throats by Apple. Not only Apple controls their platform with a iron fist, but that platform is still sufficiently small that you can't rely on the market to provide significant competition - there are no real alternatives to XCode and Obj-C, and AFAIK, you can't avoid the frameworks to write first-class Cocoa/iPhone applications (although you could wrap them in a layer of modern frameworks in other language).

Apple fans like to give the argument that they're making piles of cash writing iPhone apps. Good for them, and this is good evidence of qualities of the platform (including its non-technical sides like marketing); but it's not evidence from the quality of the SDK. You can be very succe$$ful, and grow an enormous application market, with horrible languages and SDKs. Other hugely despised-but-successful langs/SDKs don't let me lie: se COBOL, Windows 3.x, VisualBasic... or even Java, for the Java-haters.

James Jamesson replied on Mon, 2009/07/06 - 11:33am in response to: Casper Bang

A 900% growth? Where and how did you come up with that figure? I am pretty sure the phone sets produced running Android will be available only to experimentally small markets to test their acceptance by the consumers first. Sony and Samsung will not commit large volumes without seeing its success. The price tag of the phones will be close to that of IPhone's because android's hardware demands for equal consumer experience do not sum up cheaper. Although I am a happy S60 based Nokia user, I would prefer IPhone over an Android based phone anytime.

Casper Bang replied on Mon, 2009/07/06 - 12:07pm in response to: James Jamesson

The 900% is not something I make up, it's been reported by various sources over the last 6 months. The price tag of an Android device is lower, at least in Europe where phones are less subsidized and contracts are limited to 6 months. Here users are more likely to upgrade a phone and there's better HSDPA coverage, hence the reason for why all the Android devices come out in Europe before the US.

I'm curious, what do you base your iPhone preference on, have you actually tried i.e. the Magic? I just demonstrated Sky Maps and Wikitude to a proud iPhone owner, it was fun to see him drop his mouth.

Don't get me wrong, the iPhone is a great consumer product - but I don't see how that excludes Android from taking a serious part of that markedshare for all the reasons I already mentioned. You're aware of the Dream, Magic and Hero from HTC. Samsung just launched their Galaxy with sweet AMOLED screen. Sony-Ericsson are launching a monster of an Andorid phone later this year with 1GHz snapdragon CPU, 4" touch screen and 8MP cam with flash. It seems even Nokia are aware of this and preparing to join the Android club.

James Jamesson replied on Mon, 2009/07/06 - 12:11pm in response to: Casper Bang

Well, I really doubt the android will be that much of a success. But I respect your judgement. We shall see how it is going to end up this year (next year?). Who is buying phones anyways? the economic crisis will strike back heavier this fall. We have been in a temporary economic relief zone for the past 4 months. I for one aint buying anything unless absolutely necessary till summer of 2010.

Michael Parmeley replied on Mon, 2009/07/06 - 1:02pm

Nice article.

After using IntelliJ, XCode is is painful to use, you are most defintely right there!

 You can get the the API doc straight from your code by holding down alt/option and double-clicking on the thing you want to look up in your code. Not as good as inline JavaDoc that Java IDEs give you, but better than leaving your code and looking it up.

 Also, NSXMLParser isn't just "like" SAX, it is SAX.

 BTW, charging $0.99 for an app that is used to view results of a free and open-source application (Hudson) seems to be in a grey area of ethical behavior. You might want to consider just making it free.

 

 

Dmitri Trembovetski replied on Mon, 2009/07/06 - 1:12pm

>BTW, charging $0.99 for an app that is used to view results of a free and open-source application (Hudson) seems to be in a grey area of ethical behavior

Why, exactly?

 

Alex(JAlexoid) ... replied on Mon, 2009/07/06 - 3:23pm in response to: Serge Bureau

 I do Java for 14 years, objectiveC and the IPhone framework made me realise that Java failed on most issues.

I hope you mean in this comparison only. Because, you know, look around - Java has definitely higher level of mobile penetration than anything else. And on the server side it's still up there, in the clouds above anything else. On the UI side, I would say that Microsoft have done it the best way as usual.

Alex(JAlexoid) ... replied on Mon, 2009/07/06 - 3:29pm in response to: Osvaldo Doederlein

Technically, you can write iPhone applications using Mono tools. Those are not freely available, but in existence.

Casper Bang replied on Mon, 2009/07/06 - 10:34pm in response to: Alex(JAlexoid) Panzin

Technically you can use Mono for Android too. And onlike on the iPhone, you are actually allowed to use JIT compilation (another thing Apple forbids). It appears the Mono runtime is actually faster than Dalvik so this should be very interesting to follow.

Osvaldo Doederlein replied on Tue, 2009/07/07 - 8:39am in response to: Casper Bang

ANYTHING is faster than Dalvik, as the latter is purely interpreted. It's the reason why Android is now offering a official native development SDK. Their VM strategy sucked as I predicted; the only apps with good performance are ones that rely heavily on APIs (GUI, I/O, etc.) which can be implemented with native code as necessary. If they don't fix Dalvik soon to have a JIT, in no time most nontrivial Android apps will have at least a little bit of native code, which throws away the benefits of a managed platform.

This step backwards is pretty weird, coming from the same Google that blessed the world with the V8 JavaScript VM. Hey, if the devices include V8, perhaps future Android apps should be written in JavaScript instead of Java, so they can run faster - THAT would be incredibly ironic!!!

Karl Pagan replied on Thu, 2009/07/09 - 12:46pm in response to: Oliver Plohmann

@Oliver

I know Java developers that use Java for embedded things. They are constantly in trouble, because their application another time has run out of memory and there is almost nothing they can do

While I agree it's easy to waste memory and shoot yourself in the foot with Java (creating tons of objects, concatenating strings, not knowing when to substr and when to copy the chars) there are very few occasions when you are truly out of heap and out of luck.

calling C functions in Java when you have a performance problem is a big pain

Calling C from Java to aleviate performance issues is a classic mistake.

Dan Dromereschi replied on Thu, 2009/07/23 - 9:52am

Very interesting article, thanks! I wish I was able to ride my bike to the closest town in the US in order to create a bank account for using it in the Google's Android app store :)

Dan

http://www.achartengine.org

Marius Kriening replied on Thu, 2009/08/13 - 10:02pm

Would be interesting to know where do you find such comparisons on a broader level somewhere for new developers to have a base of what they`re going after - maybe include how android overlaps with java, and including symbian, winmo, j2me in that comparison. -

What`s gonna be the leading language for mobile apps??? What`s the best language to develop in? the best platform & devices to market things?

"look around - Java has definitely higher level of mobile penetration than anything else"

is it gonna be the reach or the support which decides?? Or just the user experience which, apparently, is best built out for iphone & android lately.

Supportwise, developer platforms & crowd sourcings spreading everywhere, bringing Palm (SF dev contest), Sony Ericsson (opening of app store, dev content submission), WinMo (especially with latest study on how to bring iphone app on it) into the game again. Whats gonna be the future??? and why?

sara latif replied on Wed, 2009/10/21 - 3:21am

Really intersted article :)

 I want to ask a Qustion, we have a project  based on GPS system and web site, from ur experince what do u recommend to use as platform for that project? Iphone or Andriod or even windows.

I am eager to hear from you,,Thanks alot

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.