Hacker News Reader

Comment by gte910h | Hacker News Reader

The vast majority of the code in most apps is not core code, it's display code. That's STILL entirely device specific.

I think the C# advocates oversell how much it is reusable

If you STARTED with a great pile of C# code, say, running on the desktop or server, then wanted to port that to an iOS device, then you have a point.

One big problem with non-native code is that example code is almost always written in native code, and can be hard/impossible to get new features working once you try to translate across the language barrier (mobile gets REALLY finicky about when X or Y is called, especially for things like animations)

View on HN

That's actually not what we see with our customers and their apps.

Here is a real-world example of code sharing percentages for an iOS, Android, and Mac app written in C#: http://lipsky.me/blog/2012/9/11/touchdraw-code-reuse-updated

And here is another one across iOS, Android, Mac, and Windows, also in C#: http://praeclarum.org/post/31799384896/icircuit-code-reuse-t...

Both of these apps are using 100% _native widgets_ for their user interface, and I think it's fair to say that both of them are fairly UI-heavy. And yet they average >70% code sharing.

It should also be pointed out that these apps were written from scratch. In fact, Jon Lipsky didn't even know C# before he started writing TouchDraw (the first app I linked).

Not all code is created equal. That 30% that needs to be rewritten for each device could be difficult to tune for each platform. Personally, I'd like to see some more information on what exactly was reused.

Those charts need 3 wedges: Shared non-interop layer code, interop layer code, and non-shared code. If 50% of that green wedge is interop layer code, you see why this isn't good.

Additionally, you really want "Time spent per area", which is very different from LOC in some cases.

But thanks for showing real data for named projects. Mine is from some LOC counts on customer projects (and not directly sharable), and from Mono____ advocates in the Atlanta iOS group.

Let's not forget WshLst example which uses MvvmCross to achieve about 70% code reuse for UI heavy apps that use the specific UI bits on each platform:

https://github.com/Redth/WshLst

Xamarin's examples for MonoDroid are (IMHO) pretty solid, to the point where I'll go to them first instead of the Android docs (even though I'm writing Java[0]).

It's true you have to re-write the UI code on every platform, but it's still the same language on all platforms, so less of a barrier vs. a total ground-up rewrite. Frankly, I see that as a plus, else you end up with badly cloned iOS-like UIs everywhere.

[0] Should note that I'd happily be using MonoDroid if I had a say in the matter.

I've looked at MonoDroid as I really hated Appcellerator when I tried titanium, and the default Android toolchain is painful.

I too was worried about the accidentally importing iPhone UI into Android. Any tips on avoiding it?

Just one: don't try to. :)

As I said, you have to write separate UI on each platform, and you use the native toolkits (there's no fancy abstract cross-platform UI kit in Mono), so there's little chance of looking much out of place as long as you follow local conventions. It bewilders me to see native Android apps going out of their way to clone iOS widgets and stylings. Not as common lately though; you see it more in usage of PhoneGap and similar, since there's nothing stopping you from shipping an iOS-like CSS on Android.

PS: In the case of Android, I'd flip through [0], and check out Google's apps on a proper device to get the lay of the land.

[0] http://developer.android.com/design/index.html

>One big problem with non-native code is that example code is almost always written in native code, and can be hard/impossible to get new features working once you try to translate across the language barrier

I have not found this to be true for ObjC -> C# translation. In fact, it's the opposite: translating code is pretty straightforward, and CoreAnimation calls are no exception.

Reply on news.ycombinator.com