views:

185

answers:

5

We're the developers of a relatively complex non-game iPhone 3 application, and we're beginning an ambitious rewrite to take better advantage of iOS 4. There's a significant social element to the app, so we started thinking that we'd like to make it available on as many modern mobile platforms as possible:

  • iPhone/iOS
  • Android
  • Windows Phone
  • BlackBerry OS
  • Symbian

There are several approaches to cross-platform development, and they all have limitations. No solution manages to take advantage of all a device's functionality the way a native application can. Given the complexity of our app, I'd simply like to maximize "logical" code reuse without resorting to a cross-platform framework. I'm envisioning tools that will make developing and testing apps against multiple platforms a little more seamless. What can we do to make developing on 5 platforms take less than 5 times the effort?

+5  A: 

Push as much of the functionality as you can back to a shared web server, and try to make only the UI specific to the platform.

Beth
+2  A: 

I know you said no cross-platform frameworks, but perhaps something to look at:

Write all the core logic in javascript. Unit test that at will. Then use tools like Appcelerator to turn that logic into native code.

Then import that logic code into your native platform projects for each of those platforms, and build out the other features you feel can't be achieved properly in any other way.

For platforms they don't support right now, you might be able to find a js to native code converter, or indeed a way of hosting a js environment within those platforms.

Nik
A: 

None of these will play nice together. It's not in their perceived best interest to do so.

The best bet is to dumb everything down and keep it simple. Simplicity always wins when you are trying to sandbox multiple hostile interests.

Look to XML for all data, and then have 5 binaries to read it or push it all to a web server via PHP. All these mobile platforms will function nicely with XML because it's in their best interest to do so. Worry about branding and appearances AFTER you get the core functionality off the ground.

NOTE: Javascript is the last thing you should be looking at in the beginning. It rarely plays nicely on all platforms in the same way. So make sure that your JS layer is independent of your data layer. DO NOT INTEGRATE THEM. That would be bad. You want your Android JS to be potentially different than the JS you push on the Blackberry for example. Because you won't know how quirky it will end up being until you try it out and test your methods.

Geekster
A: 

Well, you can look at JQTouch, SensaTouch or maybe wait for a while to see the jqueryformobile to finally get published. If you are not in a hurry, I would already start working in jQuery, since two out of three from this list are (will be) based on jQuery as plugins

MilanAleksic
A: 

I'm currently thinking to this problem , and my solution would be to put all the logic server side and use an approach like Model-View-Presentation, a series of events fired by the UI that should instead be specific for the client

emas