6 ms·
It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a
by markmm 14y ago
It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a bit of caching.
Once you have built it in one framework it will be much faster porting it to the others. I know it requires 3 updates when you add a new feature but it's not a major pain and you get native apps running very fast.
- drbawb 14y agoI'd also add that I don't think it necessarily violates "DRY". I think "doing it wrong" would be _porting_ the same code to 3 platforms. A blind port to three different mobile platforms is going to look out of place on at least 2/3 of them. Unless you're talking game development (where you pretty much invent the UI and UX from scratch), each OS has very well established human interface guidelines. I largely agree with you, but I think GP is incorrect in assuming it's 3 parallel branches of the same code. The three ports should all be different, in some cases _drastically_ different, or they're bad ports. The business logic may be the same, but the presentation should not. Also you point out a very good way to separate the business logic without rewriting it three times. Though I wonder if you could write the business logic in C as well? I know it could be used as a lowest common denominator between iOS and Android. Android does provide the NDK and JNI so you could bind to C libraries, and Objective-C (IIRC) would allow you to link C libraries as well. Not sure what the Windows Phone toolkit looks like these days, though, so I can't comment on that.