views:

131

answers:

4

I want to write an app that will stream MP3s from a server to any of the three major smartphone operating systems in the US (iPhone, Blackberry, and Android).

Here is the tradeoff I'm concerned with: if I write the app natively, it will make for the best user experience and give me the capability to add many more features if I want, but I will have 3 separate codebases, which violates the DRY principle.

If I use one of the frameworks out there to write it in Javascript/HTML (e.g. Rhomobile Rhodes), then I have one codebase for all the major platforms, so I'm not violating DRY and the development process is simpler in that respect, but a) the user experience will suffer, and b) I did some simple tests using SoundManager to play MP3 files with Javascript on the iPhone, and it started sucking right away (e.g. the second phase of the experiment after "cool, I can play an MP3" was "I have no access to ID3 tags? That sucks.").

I'm wondering if someone experienced in developing for multiple mobile platforms could confirm or dis-confirm my impression: is cross-platform development with Javascript and HTML viable (particularly for a multimedia app)? Or is "developing and maintaining three separate native codebases" the way to go here?

Thanks in advance.

Edit: this question assumes that I have to do this as an app. I understand that it may be much better to just serve up mp3s and let the users iPhone/Android/Blackberry Media Player handle them, but for my purposes those solutions are outside of the framework of this question.

A: 

Excuse my ignorance , what is the DRY principle?

Lemonsanver
Don't Repeat Yourself. Upon looking at the Wikipedia article for the term (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) it appears that I may have used it incorrectly to apply to code duplication. In which case, feel free to substitute the phrase "code duplication."
Jordan
+2  A: 

I would go with "developing and maintaining three separate native codebases". As you said, you will offer a more integrated and native user experience and offer features that are not (yet) available via HTML/JavaScript.

I have built and maintained successfully an app that was running on Android, iPhone, J2ME and Symbian and it's not such a big problem.

Stelian Iancu
A: 

Thanks, check out Jango , www.jango.com , its all HTML / JS by the looks of things. Works real well.

Lemonsanver
+2  A: 

Having worked on several of the mobile apps for Pandora (primarily BlackBerry), I can tell you that it would be very difficult (if not impossible) to get the user experience the way we wanted it without doing each one as a native application. Cross-platform frameworks may be suitable for a "typical" mobile app that navigates around some tree menus, displays information, makes a few calls to backend services, etc. But I have yet to see one that exposes a comprehensive multimedia API. I can understand why, too -- each platform definitely has its quirks when it comes to playing media. Even something as simple as pre-loading the next track in a playlist requires custom code. Or selecting which audio path to route audio onto (bluetooth? headphones?) On BlackBerry, streaming audio has special networking requirements because you can't use the default BIS or BES transports - it must be over Direct TCP, WAP2, or Wi-Fi (if available). So again, more custom code.

If it's any consolation, it is possible to share a bit of code between BlackBerry and Android - i.e. business logic that does not use native APIs. Since BlackBerry uses J2ME it is just a subset of the J2SE that Android uses.

Marc Novakowski
I agree based on the additional information, basically deciding between something like PhoneGap and native.From my own experience you can make very compelling apps using the JS/HTML app frameworks, however for an audio media player native is probably better. Another issue you would run into is supporting background audio playback.
cistearns