4 ms·

The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in

by jmmcd 14y ago

The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in three languages is a Wrong thing to do. DRY. Big companies can get away with it because they can throw manpower but it's still wrong.

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 ago
  I'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.

by jmmcd 14y ago

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 ago
I'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.