I work on an experienced and diverse development team and we are preparing to approach our first mobile development which will be for Windows Mobile 6 (platform changes are not an option).
We have skills and experience in both Visual C++ and .Net technologies for Windows desktop and server development.
The mobile development will include some image processing, and read/write access to a bluetooth device. Unfortunately I can't really give any more details than that.
We are trying to choose between writing the mobile client using managed code or native code. We would use C# or C++ respectively.
My questions are:
How big is the expected performance differential between these languages? I have heard that native code is significantly faster on mobile devices, but I would love to hear from someone with experience.
Are there any major advantages to either language in terms of working with the Windows Mobile services for accessing bluetooth devices?
Is there an impact on battery life between managed or native code?
Are there any other major should-knows for us to consider?
I appreciate your feedback.
Another consideration is the issue of memory usage and module size. We have run into significant problems in mobile development simply trying to get the OS to load all our DLLs into memory. Unlike regular windows development, there is a very strict limit of 32Mb into which all modules must be loaded. We've had to perform a lot of very dirty tricks to get all our stuff loaded successfully. We have found that even if a user turns on the cell phone or uses a bluetooth device, the drivers for those devices would cause our application to fail because they would use up the space for our modules.
With all that in mind, we have been unable to add in support for .Net into our application, because of the extra module weight that this would have introduced into our application. You may need to take this into allowance, if your application has a lot of dependancies.
A very similar question was asked and answered just a few days ago. You can find useful information there.
Short answers to your questions:
Native code is faster, but for many applications the speed difference won't be noticeable. Don't use native code just for the speed, unless this is a key factor for your application. Managed applications can also run fast - it may take them longer to launch.
There is a good Bluetooth library for .NET applications. I am not aware of a similar library for C++ applications.
It is up to your design to achieve good battery life. Choice of platform doesn't matter.
In addition to the great - and long - answer in the other question mentioned by kgiannakakis I have to add a few thoughts and points.
At my workplace we've been writing applications for Windows CE 5.0 using C++ and ATL/WTL. This ends up being nice to work with and very light compared to both MFC and .Net.
The other point to take into consideration (as explained by a senior developer here) is that the .Net compact framework needs to recompile the byte code into machine code each time the application is switched to. This could potentially take a long amount of time and processor power so be careful.
Related
This question is specifically related to a recommended architecture and people's previous experiences for cross-platform WP7, iOS, Android apps developed using C#, Monotouch and Monodroid respectively. I have researched previous questions here, here and here. They provide good answers but not quite what I'm looking for. I have also found this excellent question which does go into the cost benefit so there is some overlap.
I have a requirement to develop a cross-platform iPhone/iPad, WP7 and android app for a health & fitness company, which will integrate with their website. The app requires a small amount of local data storage for offline mode and synchronisation with the website when a network is available. I am a Windows (C#/C++) developer through and through and don't really want to go down the route of three Objective C, Java and C# apps, although I will if I have to. I will also be operating as tech lead and farming out some work to a team on this project.
I would like to know if anyone here has experience with cross-platform development using Monotouch, Monodroid and WP7 and to share their experience on application architecture to re-use as much code as possible. The architecture I am considering is as follows:
My question is as follows:
Has anyone here tried something like this?
Are these frameworks (Monotouch, monodroid) worth their salt for this sort of work?
Can I setup the entire project in Visual Studio 2010 with separate projects (dlls/exe) for the Monotouch, Monodroid and Wp7 target (but shared code using 'Add as Link')?
What sort of code-reuse can I realistically expect with this (or a similar) architecture? i.e. what strategies/patterns can I use to re-use local data access, webservices, and business logic?
You might want to look into the MonoCross project which is designed to help you reuse C# code with multiple presentation layers:
http://code.google.com/p/monocross/
The authors of MonoCross (ITR Mobility) have created multiple mobile cross platform solutions for a variety of customers and have written two books on the subject one is "iPad in the Enterprise" (http://amzn.to/zAhQK6) and the upcoming "Cross-Platform Mobile Development with C#" (http://amzn.to/wM6RsF).
In the meantime, you can watch Scott Olson's presentation that he did at Monospace 2011 that describes how to use MonoCross to target multiple mobile and desktop platforms at once reusing the business logic:
http://www.infoq.com/presentations/The-Rise-of-Mono-in-the-Enterprise
They enforce a strict MVC split in their code:
(source: tirania.org)
The biggest benefit of designing an application with this model is that you can run the same application with native user interfaces on each platform. You get native iOS, Android, Windows UI and they even have an ASP.NET front-end that allows you to publish Web versions of the same business logic.
This technology was used successfully by the Medtronic sample app that is showcased by Apple in their iPad business:
http://www.apple.com/ipad/business/profiles/medtronic/
I suggest you also check out Scott's blog where he posts regularly about his experiences with cross-platform architecture.
Based on your comments your requirements are for a cross-mobile platform that will integrate with their existing services, but also work offline. You are specifically interested in C# via Mono, however you have indicated that you are not discounting other approaches.
I feel that HTML / PhoneGap / JavaScript is a route that you should explore in some detail. The WP7 version of this framework has just been released, and I have had experience of releasing an application to the marketplace using this approach.
PhoneGap wraps your HTML / JavaScript code, in the case of WP7 this is loaded into local storage. This enables the application to work entirely offline. This is true for all versions (iOS, Android etc...)
Probably the biggest issue with PhoneGap / HTML5 is the same issue we have when developing complex web based applications for the browser. The tooling for JavaScript is not great and browser differences are a constant issue. However, it is a tried and tested solution.
Finally, it is possible to create an application UI that is entirely different for each platform. By using the MVVM pattern I have managed to share all my JavaScript business logic between WP7 and iOS applications whilst having a totally different UI:
Compare this to the WP7 screens:
NOTE: I plan to have the iOS version of Property Finder in the AppStore shortly, I just need to work out how to use PhoneGap Build!
Just adding another alternative to the mix - mvvmcross
This project was developed out of experiences with monocross, mvvmlight, and opennetcf.
It's quite an opinionated mvvm framework (with my opinions in it!), it includes data-binding support for Droid and Touch, and it really does encourage code reuse between the platforms.
The source is available from https://github.com/slodge/MvvmCross, it's been used in at least a couple of large projects already and it's still under active development.
There's an introductory presentation on it on slideshare: http://www.slideshare.net/cirrious/dev-evening-monotouch-monodroid-mvvm-mvvmcross-and-databinding
One of the more fully featured samples is a conference app:
The question is very hard to answer, yet I would like to share some thoughts.
The situation with the mobile development is very similar to the development at the first half of the 90s. Phone have limited resources as computers had, mobile OSes are making their baby steps, hence the ecosystem is relatively small. They have own philosophy, tools and even languages. And this is a good thing, but leads to a headache for cross-platform development. As a result, there are many attempts to clear this a bit. People build frameworks, wrappers etc. which is a kind of abstraction and abstractions are leaky. This is extremely important for mobile devices not only the performance as numbers of CPU cycles, but also the performance of the battery, which is far more important for the user.
If I were you I would build apps in a native environment especially if you have some performance considerations. Best support, tools, educational resources etc. pays for the duplicated business logic. All in all, it's not a OS or Database Management System, codebase won't be huge ;)
That being said. Regarding Monotouch and Monodroid I would be very careful since Apple blocks iPhone OS apps created by many third-party compilers and The King doesn't really care about developers. The case that mono will be flushed to the toiled by patent infringement or proprietary software vendors is very likely. This is sad for me cause C# is my favorite language.
PS. I don't believe that HTML5 for mobile will take over any time soon.
I've been doing a lot of Windows Phone 7 games development and have started looking into porting my apps and games to iPhone and possibly Android at a later date.
From my understanding solutions such as MonoTouch are not worth the effort, so should I stear clear of such things?
I'm well versed in C++ coding and would like to do that on the iPhone if I can't use C# effectively, especially for performance critical situations which games have a lot of. I don't underestimate the power of C#, just C# on iPhone (and I think that's a fair thing to be afraid of).
Would there be any good reading material I should get into before building up code for iPhone? I'm already downloading x-code but don't know what to do beyond that, I odn't even know how to wrap C++ around objective-c but I feel that would be the best compromise given my situation.
I guess a broader question is how would I handle multiplatform programming? My currnet idea is to build three seperate development frameworks which share the same design principles as each other so porting apps between platforms is straight forward (but would still require re-writing code every time).
Is that a smart way to do it or am I just crazy?
C# on the iPhone not only works fine, but it works brilliantly. It is compiled AOT that is "Ahead of Time" (normally .NET code is compiled JIT - "Just in Time") down to machine code just like a normal compiler would produce. It's absolutely fast enough for game development and about 100 times easier to use.
I have two XNA games working on iOS and my own crowd-funded iOS port of XNA, which is also coming soon to Android (ExEn). So I can definately confirm that C# on iOS is fine for game development.
Now if you're doing a 3D game, I'd be looking into Unity. The cross-platform XNA solutions are all 2D-only - for the moment anyway. The other option is using OpenGL directly with the bindings in MonoTouch.
Basically you should do everything you possibly can to avoid having to write your game more than once. To that end, C# is an excellent choice.
You don' have to wrap c++ around objective-c. c++ compiles just fine on the iPhone. You can easily develop all your code for multiplatform games in c++. What I don't know is how c++ compiles on wp7, but that's another issue :)
From my understanding solutions such as MonoTouch are not worth the effort
I've just voted to close this on the grounds of it being subjective and argumentative...
... but while it's still open ...
In my experience, MonoTouch offers an excellent solution:
if you want to leverage a single code base and existing skills
if you want to take advantage of CLR memory management
if you can cope with the increased download size
if you don't need to link with existing Obj-C libraries (you can link to these in MT, but in my experience it's not always a straight-forward process to do so)
if you can budget for the MonoTouch license fee
For XNA in MonoTouch, see http://monogame.codeplex.com/ (latest now on GitHub)
For general iphone getting started advice, try: https://stackoverflow.com/questions/332039/getting-started-with-iphone-development
Alrighty guys, I'm writing an application that I want to be cross-platform. Up until recently I've been trying to do this in Silverlight with C# because it also runs on OS X, but with me being fairly rusty with C# in addition to being new to Silverlight I've run into headache after headache. Most of this stems from the restrictions that come along with an application that's intended to run in a browser, issues with it running differently when running from my development sever vs directly from a file://, etc.
I'd rather completely abandon the whole OS X support idea than have to completely rewrite the app for OS X, especially since I have utterly NO experience writing for it. What I'm hoping to be able to do is write a regular app in C# .NET with Visual Studio for Windows and then easily port it to OS X with Mono.
How difficult is it to bring a .NET app over to OS X with Mono? My app is fairly straightforward, there's nothing exotic going on with the forms or anything, so I'd have to assume that it'd be supported in Mono's WinForms implementation.
Are there any good resources out there on how to port an app using Mono? Or, perhaps, am I missing the entire point and it simply lets you run .NET apps on OS X and I don't need to bother with porting?
Forgive my utter ignorance on the subject, I only started considering going this route like 10 minutes ago after running into yet another annoying restriction in Silverlight.
I'll be the first to admit that I don't know my head from my ass about this subject, so be gentle.. :)
Appart from MoMa as mentioned in the other answers you might be interested in MonoMac.
With the success of MonoTouch (writing c# for iPhone), there is now also a project called MonoMac to create native UI's for OSX while using .net/mono in the background. Might be interesting for you http://www.mono-project.com/MonoMac, article on Miguel de Icaza's blog: http://tirania.org/blog/archive/2010/Apr-19.html
In addition to what has been said already, considering that Mono supports a subset of the full .NET functionality, I would probably prefer to develop on Mono, then test against Microsoft's runtime, if the aim is to run on both of those. Otherwise, you run the risk of inadvertantly using some functionality that isn't available in Mono, and have to throw a large chunk of code out the window by the time you get around to doing the cross-platform build and testing.
Mono project has a page dedicated to how to port applications,
http://mono-project.com/Guidelines:Application_Portability
However, it is never enough as your application can be unique in so many ways.
Try to port it and report issues to Mono guys whenever necessary. Besides, if you work for a firm, consider Mono's commercial support service,
http://mono-project.com/Support
There are several things you should keep in mind.
you'll have to port any usage of platform depedendent UI code
don't use platform dependentent OS calls (win32 api)
don't use "exotic" libraries (like workflow, sadly ef)
In general: abstract dependencies to such code away, so you can easily replace them with mono-specific libraries. (an adviseable pattern would be MVVM).
There is a tool called MoMA that will help you with all that. However, take the results with a grain of salt. In any case, just try it.
I'm an inquisitive .NET student without any commercial working knowledge and I have been puzzled by what exactlty are .NET languages meant for?
Q1.If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications? (My dream job is to develop standalone small Windows applications.)
Q2.Are most "major" Windows applications developed using C/C++? e.g. word processing applications like MS Word or OpenOffice; photo editing software like ACD See or Photoshop; MSN or Yahoo Messenger; disc burners... Is .NET too slow and too indirect to handle these kinds of tasks?
Q3.Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications Because it's too slow and too indirect for major software applications?
Q4.I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages? Do they use MFC to access Windows API which is also outdated in new versions of Windows(backward compatible but not encouraged by Windows)?
Q5.If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
Thanks a lot for your industrial insight!
If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications?
1) .NET is not very common for "mainstream" desktop applications, if you consider mainstream to be Photoshop, etc. This is often more due to the fact that mainstream applications are based on code that was written long before .NET came around, and those applications are never rewritten, only grown. They carry a huge amount of legacy code from previous versions.
Are most "major" Windows applications developed using C/C++?
2a) See #1.
Is .NET too slow and too indirect to handle these kinds of tasks?
2b) Absolutely not. .NET can be blisteringly fast or dismally slow. Like with any tool, it depends on who is using it.
Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications
3) Payroll or GPS are hardly simple. Line of Business (LOB) applications can be immensely complex and .NET is often a good match for these precisely because they are so complicated.
I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages?
4) That is wrong. C/C++ are not outdated, they are just different. They provide a more precise level of control over the machine in exchange for longer and more difficult development time.
If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
5) Dominance is very much inherited. Again, .NET is not slow. Mainstream applications are well-known in large part because they have been around longer than .NET, so there's no reason to expect many, if any, .NET applications as well-known or popular as Word or Photoshop. Several years in the future, it's not unreasonable to expect some famous applications to arise that are .NET-based.
Edit:
Some people seem to be confused and believe that somewhere in this answer, it is asserted that .NET is as fast as c++. The only argument present is that both .NET and c++ are fast enough to run most mainstream applications. And anyone who thinks development time in c++ and .NET are equal, all other things being equal, hasn't done much development in one of the two :)
.NET is increasingly becoming the language of choice for most Windows development, including standalone desktop applications.
That being said, C/C++ are still used heavily in this space. However, on Windows, much of the "cutting edge" work is done in .NET, or a mix of .NET with native code.
The latter is, frankly, probably where the most exciting work is happening. It allows you to have the "close to metal" feel of native code when required, but still have all of the power provided by the newest .NET framework (such as WPF) for the user interface layer and non-performance critical sections. This is becoming more common over time - for example, Visual Studio is still largely native (C++) code, but the entire user interface was written using WPF (.NET).
I do nothing but desktop Windows development. I personally prefer to use .NET for everything I possibly can - and revert to C/C++ for the very small (and increasingly smaller) portions where .NET doesn't make sense.
One issue I take with your question is that you ask a factual question ("Are most "major" Windows applications developed using C/C++?") and judgmental/causation question ("Is .NET too slow and too indirect to handle these kinds of tasks?") in one go.
It is indeed true that most Windows desktop applications (e.g. Microsoft Office, Adobe Photoshop and the likes) are written in native code. However it is also quite true that on server side, at least in Microsoft stack, it is all ASP.NET, i.e. managed code.
Consider now that performance requirements of a typical web application are much more strict than that of a typical desktop application - after all, a desktop application only have one user, when a server application may have thousands and thousands. So the causation link you imply sounds weak.
As the others have pointed out, there are many requirements at play when choosing implementation technique for your desktop app. It might be portability, tradition, existing code base, training of your developers, existence of managed wrappers for particular APIs (historically Windows was often lacking in the latter) and many other factors.
For the specific examples of "all managed" desktop apps I would cite ReSharper - it is a fully .Net desktop application with non-trivial user interface and logic. Visual Studio 2010 also have considerable portions (including UI/presentation layer) written in managed code.
There are a few main issues that, I believe, still contribute to the relative lack of commerical .NET applications (the type you buy in a box at your local software store):
Requiring customers to (possibly) download the correct version of the framework runtime and/or install it before running your app.
Where ultra-high performance is required, .NET array/collection bounds checking (managed code protection in general) is obviously slower than languages/tools that don't do this for you.
The view that JIT compilation causes slower startup times.
There is often little business value in re-writing 1000's of lines of working C/C++ code in .NET.
I'm not saying whether these issues are valid or not, just trying to answer your question as to why there is still a relative a lack of commerical (shrink-wrapped) .NET software.
.NET is certainly used for standalone applications, though determining exact percentages is next to impossible.
Yes they're mostly done with older languages. Many certainly could be done with .NET, but you'd need a lot of incentive to rewrite something as large as Word, Photoshop, etc., from the ground up.
Not necessarily, but it can look that way simply because a huge percentage of business applications can be (and are) written as database front-ends.
I don't think MS has a really unified message here -- they've certainly put a lot of work into .NET, but they also continue to develop and improve alternatives such as MFC (probably at least in part because they use it themselves).
Some of both. More than speed, C++ and C give flexibility, portability (e.g., Office for the Mac) and greater ability to distinguish your application from the others.
Most large Windows applications are C++ because they were written before .NET existed. It would be pointless spending 2 years of development time rewriting Microsoft Office (say) in .NET, only have exactly what you started with two years ago as the result.
Instead, most large software application build .NET into them slowly. Look at VSTO, for instance, for a great example of .NET interoperability in a C++ app.
On the other hand, Microsoft have released a number of software packages that were written entirely (or primarily) in .NET languages. Expression Blend was probably their first. Visual Studio 2010 (which is largely WPF-based) is the latest.
ASP.NET is very large because you control the hardware. It dosen't matter if your users are on linux or on mac. The page renders and works. When you have the hardware as a parameter, people are wary of .NET which (mono-aside) is prettymuch windows exclusive. (Mono 'works' but it's less accepted than other x-platform approaches).
.NET also requires a download to be installer (.NET Framework). There's a lot of friction for users installing things to USE your thing, it's been a small barrier in XP, but now that 3.0/3.5 is baked into vista/win7 it's becoming a non-issue.
In the past, yes. These days, not as much. (Correct me if i'm wrong, cuz it's very possible i am) I believe VStudio 2010, and Office 2007+ are now developed in .NET since they don't heavily require on maximum performance. C/C++ is still faster for games, but even some indie developers are building games for xbox/pc on XNA (DX for .NET, sorta)
No. .NET isn't as slow as it used to. There are Lots of big big applications built in .NET now because it offers a wide variety of features to develop BIG applications FASTER, BETTER, and MORE STABLE.
.NET does not use MFC. Winforms hook GDI+, and WPF hooks the Windows Presentation Foundation to do it's api calls. .NET is for the most part a re-write, but some things (like direct file-i/o, are wrapped down to the windows API)
Software is developed in C/C++ because it's a) fast b) commonly known. But with today's new programmers, it's shifting I think. I also believe the new versions of Sony Vegas have been re-written for .NET, but once again I may be wrong. The key to remember is that .NET isn't as slow as it used to be, MS has bee working on the performance issue hard because they want to sell .NET for windows development.
Windows itself is not written in .NET. There's good reason for that...
One of the major problems for .NET in mainstream applications is that the ISV's producing them would like to have portable code. Photoshop for instance has a very succesful Mac OSX version. Of course, such portability is precisely not the goal of Microsoft.
Now, for the Web this doesn't matter too much. You can use .Net on the server-side and still produce a Safari-compatible website.
IMHO the tide will come whenever IE will become a managed application.
If you want to develop LOB apps for small shops that can't afford to hire programmers, and you wish to offer max features for minimum work, write them in MS-Access. Serious.
https://stackoverflow.com/questions/2437387/is-ms-access-still-the-most-efficient-rad-tool-for-small-scale-custom-apps
We create non-game programs that run on mobile devices; iPhones, Windows Mobile, Android, Palm WebOS and the like. Our main program is written in C# for Windows Mobile and we've been asked to port it to iPhone. We are not looking forward to:
The learning curve to pick up
Objective-C, XCode, and Cocoa Touch.
The pain of maintaining two
sets of code to keep the product in
sync on two different platforms.
We've decided that as a strategy we want to create all new products on as many mobile platforms as possible simultaneously, a formidable task.
We know we'll have to bend on these, but we'd prefer to:
Avoid forcing our users to be
connected to the web to use a product.
Not have a bunch of different sets
of source code.
Support as many mobile platforms as
we can.
My question is this; What is your suggestion for the best strategy to develop for the 2 - 5 most popular mobile platforms?
EDIT: Based on the comments, I wanted to clarify that we have a product that we well-received on both PalmOS and Winmobile. It works exactly the same on both platforms, making it easy for a user to switch handhelds and still use it.
Now we're on the verge of creating many new business apps and want to expand that to other hardware/OSes. What are your suggestions to deploy on many new platforms with the minimum of pain?
Consider implementing your applications via the web. This violates your preference for "avoiding your users to be connected to the web", but consider the web for the following reasons:
If your C# applications were written the right way, you could expose a web front-end to these applications by reusing your existing libraries.
Web 2.0 is supported by nearly all modern mobile platforms.
Your developers could continue writing in the language they're used to (C#).
There are many advantages to writing web apps vs platform-specific apps.
Consider Appcelerator Titanium, Rhomobile's Rhodes, PhoneGap, xmlvm.org, or other cross-device toolkits.
I make the assumptions that you have already done your market research and actually knows that all platform will be profitable, and not just drain your resources developing for one or two.
There is no great answer unless you break the "no connect to internet" rule. But there is a good answer; plain old C.
Implement all application logic in plain old C. Then;
iPhone - Objective-C is a strict superset of C, so just use the code as is. And write a UI in Objective-C using Cocoa Touch.
Android - Android's Java have JNI for calling native code written in C. Write a thin glue layer, and implement your UI with normal Java for Android.
Windows Mobile - You can call native code from any .NET application. So write another thing glue layer, and implement your UI using C# or your prefered .NET language.
Symbian - Symbian uses a variant of C++, so just like on iPhone you can call your C code as is. Write your UI using C++ and Symbian API:s.
If you break the "no connect to internet" rule then implementing the server with your existing C# code and exposing it as a web service using HessianC# is a snap. And then Hessian implementations are available for every phone that you can install an application on, that has been sold since 2002 or so.
I suggest you to separate the core of your application and the GUI. So you can continue to develop your applications in C# for Windows mobile and iPhoneOS (thanks to monoTouch). With this strategy you have only to develop the specific GUI on Windows mobile (C#) and iPhone (Cocoa Touch).
For other mobile os you can not use a cross platform dev env (for now). You need to redevelop all you application.
So:
Windows Mobile: Core(C#) & GUI(C#)
iPhone: Core(C#) & GUI(Cocoa Touch)
Android: Core(Java) & GUI(Java)
Other: depends on OS
Virtualization
Depending on your hurry I heard that VMWare is working on a mobile virtualization product that would make it possible to unify platforms into a single execution point within VM on a mobile device. It will almost certainly support majority of smartphone platforms (Windows Mobile, Android, Symbian, Blackberry and maybe even iPhone). They (and we) would definitelly benefit the most when they'd support all of them.
If you're not in a hurry, maybe wait a bit.
With a c# application for the Iphone check out Monotouch. Its the OSS version of the .net framework for the iphone.
I'll go against the grain and give you some tough love instead of simply answering the question you asked.
My thought is, why would you want to make 2-5 versions of your application that will receive, at best, a lukewarm reception across all platforms? Because that is what you are going to get.
If you want to make applications that are well received and make users excited to use them, make them take advantage of the platform. iPhone apps should have well thought out user input and take advantage of as many platform features as possible, like mutl-touch, easy data storage, accelerometers, camera and so on.
Palm apps work great in the background so write something that takes full advantage of that. it might even be more than one app to keep to Palm's simple and small approach to apps.
Android apps can integrate much more tightly with the system, so let them do just that to the benefit of the user.
Your main benefit with any app should be that you understand the domain completely, and can describe what aspects of the problem domain work best with the strengths of any given device. Mobile apps are small(ish) and any small gain you get from trying to share code across devices (and how does that work exactly across Java/Obj-C much less Android to Blackberry library differences?) is totally lost in the distortion of your understanding through the prism of accommodation.
Try using PhoneGap! All you need to know is web technologies.
A bit late to your question. But you can use Rhodes (http://rhomobile.com/products/rhodes) to write for every major smartphone OS. Tens of thousands of other developers do. Rhodes was the first smartphone app framework and the only one to provide the benefits of Model View Controller enjoyed by web developers to native smartphone development.