3 ms·

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 mu

by gte910h 14y ago

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)

natfriedman 14y ago
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 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-the-fourth-edition 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).
- king_magic 14y ago
  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.
- gte910h 14y ago
  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.
- redth 14y ago
  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 https://github.com/Redth/WshLst
danabramov 14y ago
>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.
ConstantineXVI 14y ago
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.
- gte910h 14y ago
  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?
  - ConstantineXVI 14y ago
    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 http://developer.android.com/design/index.html

by gte910h 14y ago

natfriedman 14y ago

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 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-the-fourth-edition 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).

king_magic 14y ago
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.
gte910h 14y ago
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.
redth 14y ago
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 https://github.com/Redth/WshLst

danabramov 14y ago

>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.

ConstantineXVI 14y ago

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.

gte910h 14y ago
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?
- ConstantineXVI 14y ago
  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 http://developer.android.com/design/index.html