[mono-android] Shared code, not UI

Kevin Galligan kevin at touchlab.co
Thu Sep 22 11:51:21 EDT 2011


Lots of responses.  My thoughts:

- With overhead, I'm mostly concerned with size of downloadable
package, and what's hanging around in memory during runtime.  You
don't spend a long time in the space before a client complains about a
large app download, or get OutOfMemory errors.  At least on Android.
4megs-ish is impressive considering what's involved, but is also kind
of a big chunk of bytes, considering most apps we have deployed are
between 1 and 3 megs total.  One exception was a 20+ meg monster that
we did one small part of.  The client would not listen to our pleas of
restraint.

- Performance isn't that big of a concern here.  We're also not
looking for an "all or nothing" situation.  If there is logic that is
common across the apps, and can be separated from the UI, at least for
the logic portion, that would go in a common code base.  The "business
logic", as it were.  We've done apps where this would be more work
than its worth, and we've done apps where this would have been a huge
time saver.

Having said all this, I have no idea how useful it would *actually*
be.  Its pretty rare to find an app with its business logic completely
removed from how its displayed AND how its stored, which this would
really require.  This makes it even more of a hard sell.  Would you
add 4 megs of download for 10-20 logic functions?  Seems like you just
put those in a special folder and make sure any bug fixes get ported
between the platforms rather than add the overhead, or you just do it
all in C++ and call it a day.

Not that its a dead idea.  I want to eval doing an iOS and Android app
fully with C#.  I'm working with a small team, half of which are hard
core .NET guys, so if that approach would work well, we might have
something here.

Thanks again for the input.

Any NYC people on here, BTW?  Working up some ideas for meetup topics:
http://www.meetup.com/android-developers-nyc/

-Kevin

On Thu, Sep 22, 2011 at 7:29 AM, Miljenko Cvjetko
<mcvjetko at holisticware.net> wrote:
> Hi
>
> Craig Dunn
>     http://conceptdev.blogspot.com/
> has several samples (look for Restauran Guide)
>     https://github.com/conceptdev
>
> My thoughts about are inline...
>
> On 2011.09.21 21:26, Kevin Galligan wrote:
>
> The bulk of our business these days is Android ports of iOS apps.
> There are many "cross platform" solutions, but they all tend to be a
> pain and don't really work as well as one would hope.  What I've been
> trying to do is find a cross platform solution that would simply be a
> shared code block.  Like a black box logic processor that you could
> deploy on either platform, and call into it to do calculations and
> business logic.  The UI, and simpler code would be handled in whatever
> the native platform preferred.
>
>     There would be 2 concepts:
>
> sharing on binary level (PInvoke, callable wrappers (COM, .net, android,
> ...)
> sharing on source level with MonoTouch/MonoForAndroid/Mono*
>
> Cons for 1.
>
> You still need experts in underlying tech that would maintain that code if
> problems
> arise in that part.
>
> Pros for 1.
>
> Less to do. Just wrap and go...
>
> Pros for 2.
>
> For BusinessLayer only .net programmers are needed...
> Core can be shared accross projects
> In our case 3 apps currently wp7, monodroid, starting monotouch (iOS),
> silverlight,
> desktop (WF and WPF), asp.net.
> sharing not only cs code
> just writing small writeup how to share XAML code accros WP7, Silverlight
> and WPF
> unit testing
>
> take desktop version in solution add unit tests and You can cover a lot,
> really a lot
>
> Cons for 2.
>
> need to get used with new tools Project Linker/Productivity Tools etc...
> Microsoft came out few years ago with excellent tool Project Linker for
> sharing
> SL and WPF code.
> Today thanks to Mono* you can use it for far more!
> I can rember sharing SL code with desktop by tweaking assemblies!
> (let's say binary level, no thanks)
> need to find smallest common denominator for tools/features
> for us WP7 (WP7 project is source for linked cs files all other projects)
>
> going from superset app (desktop) to subset (mobile, silverlight) rewrite
> all
> code to async, sync versions are kept only in desktop and asp.net versions.
> I know that was mistake at the beginning, but at that point that was the
> fastest
> solution, never thought I will program mobile apps.
>
> faster growing number of projects in solution
> #platforms_targeted * #architectural_layers
> Most superset projects (desktop, asp.net) are almost empty
> quite a bit knowledge about diffs between .net and mono...
> remember when we hit the wall by using Observable collection for WP7, SL,
> Then MonoDroid came in.
> Cannot rember which mono base was then, but Observable Collection was not
> there)
> But everything can be done:
> pulled source fore several classes to shtuup the compiler from
> http://www.java2s.com/Open-Source/CSharp/2.6.4-mono-.net-core/System.Collections/System/Collections/ObjectModel/ObservableCollection.cs.htm
> Voila...
>
>
> The obvious choice here was Javascript, but it wouldn't be my ideal
> choice.  Something like C# is more appealing to me.  Although not
> ideal itself (I'm not sure what would be ideal yet), it seems like a
> promising option.
>
>     I'm ready to bet on Mono*
>
>
> Questions:
>
> 1) Is this possible?  Specifically, starting up and calling into a
> mono runtime on Android or iOS (and possibly windows phone in the
> future, although you might simply able to use a library there)
>
> If You go for 2nd solution
>
> cons:
>
> you'll have to rewrite iOS app in C#
>
> should not be a big problem (mobile apps are small)
> have common base for oter projects/platforms
>
> pros:
>
> common BL
> iOS xib can be reused...
> open doors for implementation on other platforms
>
> 2) What kind of overhead does the mono runtime have?  How much memory?
>  Probably a stupid question, as the project would be dead in the water
> if it didn't run well.
>
> Hard to tell depends on use... remember few reports where MonoDroid tests
> where
> faster than java equivalents.
> Test can be always tweaked to show what I want to see...
>
> Any thoughts on this approach?
>
>     A lot...
>
> regards
> mel
>
> Thanks in advance,
> -Kevin
> _______________________________________________
> Monodroid mailing list
> Monodroid at lists.ximian.com
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
>
> --
> Miljenko Cvjetko dipl.ing. ET
> 	Direktor/CEO
> 	Projektant rješenja/Solution Architect	
> 	Razvojni programer/Senior developer
> 	Voditelj projekta/Project Manager
>
> IX južna obala 13
> Kajzerica Zagreb
> T: 385 1 7775555
> M: 385 91 557 447 3
> F: 385 1 7779556
> e: mcvjetko at holisticware.net
> w: http://www.holisticware.net


More information about the Monodroid mailing list