Related
I'm developing an application for Android, and I'm thinking that it's functionality might be useful on other (Java-running) platforms (say a regular desktop app -- although I hope that the other platform(s) involved are immaterial to the question at hand).
It's unlikely that the UI will be in any way portable (there's just too much of a difference between a good touch-capable, 4in screen UI, and a mouse-and-keyboard 19in screen UI), so I'm happy enough reimplementing that separately.
However, the core "business logic" (ugh, horrid word) and model (data storage) classes could, in theory, be reused in managing the core app. I've noticed that there aren't a lot of classes I'm writing that don't end up referencing some Android-specific bits (I've got XML resources files, images, and SQLite databases, as examples). Basically everything I've written so far has at least one Android-related import.
My question is twofold:
What tools are available out there to help me use Android-related classes and features (eg resources, databases) on non-Android platforms; and
What classes, features, etc of the Android platform should I completely avoid using (for the sake of simplicity, let's exclude UI-related items) due to non-portability, and what should I use instead to improve portability.
Answers that consist of "hahahaha, you're doomed" are OK, as long as there's some rationale provided.
(P.S. I'd make this community wiki if that was still available; this seems like a perfect CW question to me -- a list of Android portability tips and tools)
Looks like you have already identified the key point by keeping UI and biz logic / model separate.
Also sqlite itself is used not only in Android. But of course the way you interact with it (e.g. SQLDBOpenHelper) is different again.
So I guess having the biz logic and model as separate as possible is the way to go.
You can then put a wrapper around it (e.g. "Data Access Object " pattern which talks to the specific DB).
Still keep in mind that the users experience is best when you are as specific to a platform as possible on the UI side.
Example: there is an App (Push & Ride) on the Android market, which seems to run in a J2ME emulator. So screen input does not use the normal soft (or hard) keyboard of the device, but a simulated phone keyboard with the "abc" "def" combos on the number keys, which makes data entry a bit strange.
This app is for sure very portable (and its functionality is really great), but it just does not feel right.
When you want to go multi-platform, you may perhaps also look at things like Appcelerator or Adobe AIR
I started off doing something similar - I wanted to write an app for Android, Blackberry and J2ME. Conceptually, you can layer your design such that platform-specific components (UI, network access, data storage) are separated from the core business logic.
In practice, I don't find this satisfactory. The issues I faced all related to the core version of Java being different in the different platforms (in Blackberry it is based on J2Se 1.4, while Android used Java 6 as base). This led to annoyances like
Not able to reuse code that uses generics
My preferred classes not being available uniformly (for example, forced to use Vector over List)
I have opened discussions regarding this on SO (here and here), but couldn't reach a conclusion.
The logging layer can be made portable by using the Simple Logging Facade for Java(SLF4J) which is available for java/log4j and for android.
Also,you can try this out
http://wp7mapping.interoperabilitybridges.com/Home/Library?source=Android
Contains documentation and tools to map your android app to windows phone
Also read this,even though it contains instructions specific to android - windows phone interop,im sure they apply to other platforms as well
http://windowsphone.interoperabilitybridges.com/media/49652/wp7_guide_for_android_application_developers.pdf
What I do is create a web service outside of the android app which can be used by the android app as well as other systems (websites, windows apps, iphone apps etc).
A simple REST web service which supports JSON is a good example to fetch data and also insert/update data. JSON is particularly suitable because its so lightweight, and doesn't require alot of bandwidth which is great for slow mobile connections.
This way you can store your models/data storage outside of the android app, and it can be used by other apps very easily.
The database layer can be made more portable by using android jdbc or by using a database abstraction layer/object relational mapper/ActiveRecord implementation.
Has anyone tried make android.database(.sqlite) runnable on a non android system?
If you carefully separate business logic from UI and android perks you would be able to reuse it in desktop environment. Android is quite different from it in intialisation and application lifecycle - abstracting creation and setup of BL is also necessary.
Usefull pattern for this purpose would be dependency injection. There are different frameworks around, and some are more suited for android (like roboguice) or desktop (spring or picocontainer or guice).
Android appliactions are very constrained in memory, and this puts limits on what frameworks you can use there. So you may need to abstract data storage as well ( hibernate comes handy on desktop / server side , but too heavy for mobile device)
I'm inclined to suggest trying out the new native extensions for Adobe Air. It allows you to create a device-specific chunk of native code, and connect it to the Air framework, accessing it as you would other objects in Air. (cf. http://www.adobe.com/devnet/air/articles/extending-air.html). This allows you to keep the Android-only code as is, and then replace that code with iOS, Windows DLL, etc. code as needed.
This doesn't solve the problem of translating Java code to other languages/platforms, of course. Still, some of the logic you are doing natively may very well exist already cross-platform in Air. For example, you can access the camera in Air in all supported OSes without writing any device-specific code.
You will probably need to go beyond the current Air classes, so some examples may help:
Android speech-recognition
iOS batttery
Windows and Mac tutorial
NE tutorial
I am currently trying to implement a database compatibility layer for Spring-Boot-JPA/Android-Room:
"compatibility layer" means my Service-layer-code is pure-non-android-code that can be used in android and in spring-boot. The Service-layer-code uses a common java-repository-interface that is either implemented in android-room or in JPA.
Currently i am stuck here:
Howto use methods of CrudRepository<T, ID> (or SimpleJpaRepository<T, ID>) in a Spring-Data-Repository-Fragment method?
Edit: My bad, I meant objective-c, not c#. Some reason I got it into my head it was c# the iphone used. So the answers for c# were great, thanks, but theyre a bit irrelevant, sorry about that.
I've had a look but can't find anything that answers this, though a few have shortened the question by answering parts of it. Between a small group, we were planning on doing some work on iPhone and Android, the 2 seperate for the most part but helping each other out, and with some guys doing graphics work split between them.
But we were thinking about the possibilities of moving things between the two, not necessarily apps, maybe just useful classes or something. Looking at objective-c and Java, they seem to have about the same features that the biggest obstacle would be system interface stuff, so we were wondering whether, if we created an abstraction over these on each system so they could be given the same input (which unless I'm wrong wouldn't put too much strain on the system?), would there be any problems in writing something to convert between objective-c and Java, worse than the locations of methods in the sdks? Or are there key features or something in one language that the other doesn't have which we've missed that would mean the only way to do it would be rewriting from scratch.
I wouldn't waste time trying to find commonality between iOS and Android.
Cross-platform is almost always a waste of time and resources unless the cross-platform capability is central to the apps functioning. That is especially true for platforms such as iPhone and Android which have custom OS and work very tightly with the hardware.
Cross-platform development environments add rather than reduce complexity long term. Yeah, it sounds neat but usually you get 90% what you want easily and then you hit a roadblock that destroys all the savings you made and then starts putting you in the hole. There are simply to many compromises and square pegs jammed into round holes.
Unless your app could in theory work from a generic web page, cross-platform is not for you.
In the specific case of Objective-C and Java, although Java is descended from Objective-C they have no modern interoperability. You can't use code from one on the other.
You should spend the time to learn each platform's specific API. There are no shortcuts.
Tools like XMLVM, Codename One and iSpectrum tell us that you can actually cross-compile Java code (from an Android app or creating one from scratch) to Objective-C code that is running on an iPhone without having to install any virtual machine on the Apple side of things.
I suggest watching Developing iPhone Applications using Java
Unfortunately Apple's license
agreement for the iPhone SDK prohibits
the porting of the Java virtual
machine to the iPhone. In this
presentation we introduce an Open
Source Java-to-Objective-C
cross-compiler as well as a Java-based
implementation of the Cocoa library.
With the help of these tools, iPhone
applications can be written in pure
Java. Using the Java version of Cocoa,
it is possible to run a Java-based
iPhone application as a Java
desktop/applet application that can be
cross-compiled to run natively on the
iPhone. The talk will discuss the
challenges of the Java-to-Objective-C
cross-compiler as well as the
Java-based version of Cocoa. Details
are available at http://www.xmlvm.org/
and for more insight a more recent talk about Cross-Compiling Android applications to the iPhone from Frebruary 2010 is available here, which is documented at http://www.xmlvm.org/android/ :
Android is an Open Source platform for mobile devices. Initiated by Google, Android has received much attention. Android applications are developed using Java, although a special compiler converts class files to a proprietary, register-based virtual machine that is used on Android devices to execute applications. Android defines its own API for writing mobile applications. With the help of XMLVM it is possible to cross-compile Java-based Android applications to native iPhone applications.
The Android application is written in
Java and makes use of an Android
specific API. XMLVM offers a
compatibility library, written in
Java, that offers the same API as
Android, but only makes use of the
Java-based API for Cocoa Touch. During
the cross-compilation process, both
the application and the Android
compatibility library are
cross-compiled from Java to
Objective-C and linked with the Cocoa
Touch compatibility library to yield a
native iPhone application.
From the 2008 talk about building Java applications for the iPhone http://www.xmlvm.org/iphone/ :
Apple's iPhone has generated huge
interest amongst users and developers
alike. Like MacOS X, the iPhone
development environment is based on
Objective-C as the development
language and Cocoa for the GUI
library. The iPhone SDK license
agreement does not permit the
development of a virtual machine.
Using XMLVM, we circumvent this
problem by cross-compiling Java to the
iPhone. Just like a Java application
can be cross-compiled to AJAX, XMLVM
can be used to cross-compile a Java
application to Objective-C. The
cross-compilation is also accomplished
by mimicking a stack-based machine in
Objective-C.
If you focus on abstracting away things like system interactions, and stick to the common subset of the languages, you can probably build classes that would require little or no modification to move from one language to the other.
C# does have a better implementation of generics than Java, in that C#'s generics retain strong typing at run-time.
C# also has LINQ, which as far as I know has no equivalent (yet) in Java. LINQ provides a SQL-like query capability, built into the language and fully supported by the .NET frameowrk, that lets you query object collections, and does so in a very functional-language style. LINQ can be extended by query providers to work with other data formats, such as XML and SQL, once the query provider provides an object model that translates to the other format. LINQ also makes parallelization very easy for multi-core work. It's a huge extension to language capability.
This topic is often filled with the dogma of technology jihadis, so I shall try and steer clear of that in my answer.
In my experience, I would largely agree with people saying that trying to share code between the two platforms would be difficult. However, there are some important exceptions:
I would consider cross-platform development where your business logic:
is non-trivial;
should be standardized across platforms; and
has well defined interactions with the outside world (e.g. network stack or UI).
(bonus) is written already.
Apple is the rate determining step here, given the now infamous 3.3.1 restrictions on source code languages. You can write code in Javascript according to the bundled Webkit, C, C++ and Objective C.
If you don't want to install extra languages on a 'droid, you can use the Java that compiles down to dalvik code, the Javascript as per the slightly different build of webkit or something from the NDK. Then you'll be looking at C/C++. You could cross-compile Objective-C, but I haven't had any experience of that.
The clean separation of business logic from UI and networking is important, as you'll be looking to write adapters for the networking layer, something else for the UI.
I would not attempt to write cross platform UI code in C/C++, and would either write something that used HTML/CSS/JS, or more likely write something completely custom to take advantage of the different UI metaphors on each platforms - e.g. there is no analogue to the notification bar on the iPhone. Animation on the iPhone is orders of magnitude simpler to implement than on Android.
If you don't need the UI to be massively integrated with the OS, then a webview and some HTML5 may be sufficient. Titanium is a good option here, and my colleagues in the know tell me it is better (i.e. compiles, not interpreted) than PhoneGap. Again I don't know.
Going the other way in complexity, Open GLES is available on both platforms.
It should also be noted that SVG is not available on the current crop of Android OSes.
If you actually want to do cross phone development, as long as it is not something really computationally expensive, I would probably go with PhoneGap.
PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
As far as I can tell, it's pretty much the only cross platform toolkit that is allowed in the iPhone app store.
If you're dead set on native development, I think you'll find that unless you're making a game and targeting c, it will be a lot of work to port. The frameworks are very different and the way of building UI is very different. That said, to answer you're direct question of objective-c vs. java, it's not that bad. It is different enough, though, that an abstraction tool would not be that easy - not like Java vs C#. Objective-c does not have garbage collection (on the iPhone anyway), for example, and the syntax is very different. Objective-c is more loosely typed in the way that it does method calls (messages in objective-c). That said, they aren't wildly different in terms of programming paradigms. They are both object oriented imperative languages. They both have classes and methods, public and private. If you wanted to port the code by hand, it wouldn't be the end of the world, I just think you might wind up spending a lot more time trying to build an abstraction layer.
If you're thinking about doing Android development my best advice is to go for java. There is no benefit at all of writing a complete abstraction (assuming you can) layer to convert from C# to Java. As for the IPhone development dont doubt about using Objective-C for the same purpose.
You can't develop for the iPhone in the same language as for Android. For the iPhone, you can only program in Objective C, it's developed by Apple. You can't use it for android, and the only way to do iPhone development is with that language (it's in the user agreement).
As for C# vs. Java, the whole principle is different. Java is one language for every platform, .Net is one platform for every language. They are not compatible. You can use Java on Android, but I'm not sure if you can use C# (.Net) as well.
Anyway, you'll have to build two different apps for these two mobile operating systems.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just finished a relatively large project for the Android, and it's left a bitter taste in my mouth with the knowledge that it will never run on one of the most ubiquitous handsets this side of the solar system (the one by that fruity little club).
So, for my next project, I want to write it in a way that makes most of the components easily transportable between the iPhone and Android platforms. The way I'm thinking of doing this is by coding most of it in Objective-C, and then adding the platform-specific parts in more Objective-C and Java respectively. On the Android side, this will require using the the NDK.
My knowledge of C is good, but my knowledge of Objective-C is close to zero, and I have no desire to learn C++. How sane is the approach above, and is there a better one? Is there any way I can code in Java and still reach the un-hacked iPhone market? And how likely is it that the people I know (iPhone users) will have an Android phone by next year?
Step back and think about what in the end you will logically be able to share.
The UI models are fairly different, the components are different. In the end what you might be able to share is data object classes, possibly some algorithms. It's not even like you could realistically end up sharing network code as in the old days because you aren't directly using sockets, you are using HTTP libraries.
So will all of the effort you are putting into this really find a payoff in the end? It seems to me the end result will be a brittle mess that is hard to update, and is mediocre on both platforms instead of being great on either.
Why are you writing applications? To make life easier for you, or your users?
Others have said basically this, but I'd like to make it more explicit. Your best bet is probably to write:
Cross-platform data models & core logic, using:
bits of GNUstep (Obj-C), or
CF-Lite (C), or
Whatever you'd like, as long as it's cross-platform :P
iPhone-only interface code, using Cocoa Touch (Obj-C)
Android-only interface code, however they do it for the Android.
That's as close as you can get; any attempt to write cross-platform interface code will undoubtedly result in a mediocre app on both platforms. But making all the rest of your code portable and just wrapping a device-specific interface around it is done all the time and has been worked great for some iPhone developers.
Objective-C without Cocoa is not so useful and won't bring you much closer to haveing a working iPhone codebase. You'd probably be better off writing your core in C with Core Foundation and using either Java or Objective-C for the platform specific parts. Apple has open sourced a large chunk of Core Foundation as CF-Lite, and it's toll-free bridged with Cocoa on OS X (i.e. you can use many CF classes interchangeably with their Cocoa counterparts).
My guess, which has no experience to back it up, is that you probably could write Obj-C with Google's NDK somehow, given that GCC exists for ARM, is open source, has an Obj-C compiler and a basic Obj-C runtime (which if it doesn't already probably could be hacked up to work on a new architecture), etc.
That might also be a lot of work for questionable benefit.
And of course "Obj-C" (without the NS classes) means something very different than "Cocoa", which is what most people really mean when they say "Obj-C". You might be able to re-use some of GNUstep for some that, but... Honestly, I doubt it. Sounds again like a lot of work.
So, yes, I think it is possible. It's also a lot of work and I don't think it's worth it.
Given what you've said, if I were attempting this, I would be tempted to write as much of your core logic as possible in C, then wrap it with two separate GUIs for each platform.
Coming at this from a different angle... I know that you said you wanted to try and stick with Java, but if you know C# then you could go with the MonoTouch framework for the iPhone. Mono is essentially and open source implementation of the .Net stack. The Mono team is working on bringing Mono to the Android so you could basically write a shared C# library for your business logic and have different Views/Controllers per platform. This would all be in C# of course and it is a bit more expensive, but it does solve the problem of writing everything in different languages.
I believe it is called MonoTouch on the iPhone and MonoDroid on Android.
The Apportable SDK is an Objective-C approach to write once and deploy to both IOS and Android. It will cross-compile a running IOS Xcode project to an Android SDK.
See here for sample apps that run on both platforms in minutes after download.
I'm not sure about Android but with the iPhone you can essentially write straight C as long as you wrap it up in Objective-C classes.
The Objective-C runtime has not been ported to Android yet. It shouldn't be too much work, but still, without a working knowledge of the language I doubt you'll have an easy time porting it.
What you are trying to do is going to be hard for a generic application, but should be possible for games, if you choose to develop the game in plain C (which is supported by both the Android NDK and the iPhone). You'd have to write up some glue code to pass input events from the Obj-C and Java environments into your C code, but that shouldn't be much of a problem - Objective-C allows you to directly call into your C code and there are plenty of example projects which do exactly this for Android.
I haven't tried this myself or finished watching the talk yet, but there is a Google Tech Talk on Developing iPhone Applications using Java up on YouTube that looks pretty promising.
XMLVM is a project which is capable of translating (some) Android applications to the iPhone. For more infromation, visit http://xmlvm.org/android/
I realize this may be a tad late, but it seems the industry is going in the direction of web apps these days to achieve app portability. That is, embedding a web-browser in your "skeleton native app", and writing javascript, css and html for Android, iOS and the other major smartphone platforms.
There are tools that help you with this. You might want to check out PhoneGap and Sencha Touch, but there are many more. Note that this approach may not be ideal for real-time/animation-intensive apps.
Here is a talk from facebook's mobile # scale conference where two teams (dropbox and orchestra) used similar approaches. Dropbox used C++ to create libdropbox and Orchestra (mailbox) used Objective-c to create libmailbox.
Again, they wrote their front ends in the platform native language and used their cross platform libs for core logic and data.
Key benefits I took away: Mailbox went from ios to android in 5 weeks because it was just building UI code. Dropbox can beta test changes to core functionality that are in the shared library with Android beta deployments were it's easier to do massive deploys at scale for beta builds.
If you can wait until later this year (exact amount of time unknown), Adobe will have AIR for Android and a compiler to iPhone. Thus you can write an app in AIR for the Android and use most of the same code to compile to the iPhone.
http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/
Even if you can't wait see: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html where it explains the similarities between ActionScript and Cocoa.
Also check out: http://labs.adobe.com/technologies/air2/ for the AIR version capable of using the touch screen.
So you can soon write once and deploy to Android and iPhone using ActionScript 3.
Are there any good open source frameworks for developing computer system emulators? I am particularly interested in something written in Python or Java that can reduce the effort involved in developing emulators for 8-bit processors (e.g. 6502, 6510, etc.).
Isn't the 6510 in the C64?
You might be able to make use of the java libraries that emulate c64 code
http://www.dreamfabric.com/c64/
http://www.jac64.com/jac64-java-based-c64-emulator.html
If you aren't afraid of C++ try this general purpose one:
http://cef.sourceforge.net/index.php
You may want to check out VICE, which can emulates a variety of Commodore 8-bit computers: "the C64, the C64DTV, the C128, the VIC20, almost all PET models, the PLUS4 and the CBM-II (aka C610)". That includes 6502, 6510 and 8502 processors. VICE is released under GPL and is written in C.
I've developed a complete emulator for the MIX machine (Knuth's imaginary computer from TAOCP) in Perl a few years ago. The source code is well documented and the simulator is runnable, so one can practice with examples. It wasn't too difficult and I don't recall needing any special framework. The machine's registers are just state variables in the simulator, and the rest is interpreting instructions and changing this internal state.
Do you have more specific questions? Perhaps it will then be easier to point you in the right direction.
I'm a highly skilled Java dev contemplating learning iPhone development. Mac only dev aspects aside, how much of a leap would learning the mobile application stack be? Sure I understand that its closer to C in how one should approach it, and with that comes memory management and so on.
My queries would also include
How well is OOP/OOAD supported?
Is there some API(s) which enable unit testing?
I'd encourage those who answer to quote external sites and references to help elaborate the detail
The development language is Objective-C, which is pure C with a very thin object wrapper over the top. They syntax is kind of weird looking, but it's pretty easy to get to grips with if you know C once you get over the message calls - myself I have a solid C background and only started picking up Objective-C a month or two so back but I'm finding it really rather pleasing - more so than C++.
The difficulty you're going to have if you have only coded Java is pointers and memory management. Memory management isn't conceptually hard as it's simply (!) a question of keeping track of what you are allocating and releasing, plus XCode seems to come with good tools for detecting leaks (although I haven't used these in anger yet) - and as iPhone programs are relatively small it's not like coding a big system program where this can be extremely tough. The major conceptual difficulty you are likely to have is simply getting your head around pointers as they are used extensively (as in just about on every line of code) and you do need to grok these completely. One of Joel's reoccuring themes on the podcast is the difficulty some coders get using pointers, so I'd recommend you take that carefully and possibly pick up a good book - perhaps the original K&R.
Someone may like to correct me, but although the Cocoa API appears excellent, there seem to be few libraries available outside the framework (unlike C++ or Java). For instance I had to add my own queue and stack classes - although the NSMutableArray makes that extremely easy.
All in all though I'm certainly finding it one the most fun platforms to play with I've used for a while.
A few months ago I was a Java web programmer who hadn't touched C since college. Now I've got one iPhone app completed (for my day job, stuck in the bureaucracy there so it's not in the app store yet) and my second app nearing completion.
To answer your question the biggest hurdles are understanding the conventions (Delegate pattern, Categories, etc.), getting a grasp on memory management, and working with XCode (a good IDE but definitely steps behind Eclipse and IntelliJ).
I also think the documentation in the Apple Developer Center website is well-written, and a good developer can get up and running quickly.
To more specifically answer your question, I haven't tried Unit Testing yet but I think the OOP is great - my domain objects in my iPhone apps are as robust and powerful as those I've written in Java.
I came out of college as Java developer. My first (real) job was Mac Development. Transitioning from a language I know (my starting point was Java) to something like Objective-C was fairly easy, code-wise. To maximize your time developing iPhone / Mac Applications, you have to make use of XCode and Interface Builder. Once you get the hang of attaching events and GUI outlets (the objects your UI want to communicate with), you'll be set for normal iPhone app development.
Here are the steps I went through learning Objective-C (the programming language for iPhone development) having my Java background:
Learn the basic OC object-oriented concepts. Subclassing (Inheritance), protocols (Java Interfaces), object properties (Bean properties), methods (you have to explicitly indicate the "parameter entry" labels, unlike in C / C++ / Java where you guess the parameter ordering).
Understand the difference between Objective-C, Cocoa, Aqua, and C. Then learn about how to use frameworks. Frameworks are pretty much the same as Java Packages.
Familiarize yourself with using these Foundation classes: NSString, NSArray, NSDictionary, NSSet, NSURL, NSAutoreleasePool.
Study more about Interface Builder. I thought before that the Visual Basic way of programming limits the programmer. I was wrong. It is better you "visualize" the app first before you get the hang of how things go in it. Take note about the keywords IBAction (analogous to making an EventListener), Outlets (you only have a few objects "exposed" for your UI elements), Views (UIView in case of the iPhone, everything that's "visible" in the application can be considered a "view"), and Controllers (there are ready-made controllers that you could use to populate Table Views, flip Card Views, etc.).
Learn how to deploy your app through the iPhone Developer Portal. You cannot send any iPhone app to any device if you don't have this "right". Yeah, I know it sucks, but you have to go through this process, anyway, if you want to sell your apps.
BTW, you could use the following for unit testing iPhone code: iPhone Unit Testing
Hope this one helps. :)
Objective-C is an object oriented language so, as far as OOP is concerned, pretty much anything you can do in Java you can do with Obj-C.
I don't have any experience with it but here's at least one resource on OCUnit, the objective-c equivalent to JUnit: http://developer.apple.com/tools/unittest.html
The biggest problem I'm having with the transition is definitely the memory-management aspect. Learning the syntax and APIs is pretty straight forward but life's tough without the GC!
EDIT: Oh yeah, the second biggest problem is XCode, the IDE used for Mac/iPhone development. Refactoring support is minimal and I find it a pain to navigate between files. Expect this to slow you down quite a bit, too.
For unit testing there are a few options, OCUnit was linked above. There is also google-toolbox-for-mac.
The OOP in objective-c is good, fairly clean. You will encounter old school C functions on occasion as well.
The API used is called Cocoa-Touch, and is built on Cocoa, which was built from NextStep, so there is a great history of design and refinements out there.
No garbage collection on the iPhone. The golden rule is "If you alloc, then you release". There are plenty of questions on SO regarding memory management, so I won't go into details here.
The major hurdle is the design / architecture differences. iPhone apps and java apps are build using different conventions. So consume as much objective-c / cocoa / cocoa-touch code as you can find / stand.
Spend some time working with Interface Builder, it can be aggravating, but that usually means your not understanding what its up to. Once you have a clear view of how IB works, and what it can do for you, you will really appreciate it.
Cocoadev.com is a handy resource for picking up design and code examples.
Cocoadevcentral.com has an excellent collection of articles, including desktop cocoa development. His learn objective-c article is one of the best you will find.
Get an Apple Developer Connection account if you don't have one yet. You don't have to pay for this one, but will get you into the documentation and tools.
ADC iPhone
iPhone Reference Library API Docs, guides, sample code, The official Apple stuff.
I wouldn't say that I'm an expert in any language but I'm competent in a few. Most of the code I've written recently has been "enterprise"-type stuff.
Assuming you're comfortable learning a new API and language, the biggest difference I found is how constrained the iPhone is in terms of CPU performance and available memory. I'm very used to trading off a bit of memory for better performance -- almost unconsciously -- or being a little wasteful because I've got eight cores at my disposal. That's a really bad idea on the iPhone!
The other hard thing is making sure that it's iPhone-y. Making a good app is not just a matter of shrinking the GUI down, you really need to think about presenting the data effectively.
The technical aspects are all pretty much sorted. The unit test side is less advanced than on the Java side. On the other hand I find that I can be much more productive and less error-prone in Objective C than Java, and this is probably due to the object model which is quite different (you tend to delegate rather than inherit).
Well, Java was based on Objective C and Smalltalk, which are object oriented languages. The big issues will be syntax (which is not entirely C based like C++ and Java), pointers and manual memory management.
This is based on some very old Objective C knowledge, but I do know that when I switched from Objective C to Java (around 2000), it was pretty easy since the underlying concepts were pretty close.
Based on Objective C
Memory management
It is worth mentioning that you can use C++ and C++ objects within your Objective-C code, often referred to as Objective-C++. This can be a valuable approach to separating your data model and other platform-independent code (written in standard C++) from your UI code (written in Objective-C using the Cocoa framework).
If you understand the idea of OOP through your Java experience, and if you have a basic idea of what pointers and memory management are, then the last obstacle in your way will be the alien syntax.
Syntax: I found this tutorial, among others, very clear and concise. In my mind, I conceptually mapped Objective-C and Java infrastructure, which you can do for the most part (i.e. a message is for the most part a method, a protocol is an interface, and so forth). Once you get over the initial shock, you will find that Objective-C development for UI applications can be rather intuitive and pleasant.
Structure: I don't program UI so much, so I found that I needed to get a better grasp of the MVC paradigm.
You may also find some cool language features, such as categories, that you wish you had in Java. I likewise find the lack of some other constructs, such as the lack of static members.