Hi
On 2012.08.16 22:17, Stephan Steiner wrote:
Hi
I guess I'm missing something. I'm developing a mobile version of a client
that is already available on PCs in multiple forms. Those different clients
are meant to share as much code as possible in order to cut down on
repetitive work. So, there's a bunch of libraries that are to be shared
amongst clients (and they build against standard .NET 4.0)
Here's where it gets tricky:
I'm creating derived classes from some of the base classes in my libraries,
and override methods where I need to behave differently for Android. While I
can step through the overridden code just fine, I cannot step into any
method that is defined in a base class. And to make matters worse, even
though the base class has proper error handling and should never throw an
exception in the method I'm calling, I started getting Unhandled Exceptions
(specifically a System.ServiceModel.EndpointNotFoundException). If I run the
exact same method with the same parameters in a PC based client, not only
can I step through it, but there are no exceptions (and when I do something
wrong on the PC client, then the exception is properly caught, and logged).
It seem like You are having
1. common assembly/dll built against desktop/client version netfx 4 and
2. delta (derived subclasses) assembly for Android and/or other platforms
If this is the case - I would strongly suggest not to do so!
We had a case (SharpSNMP based app) which worked flawless for several
months and suddenly started
to explode in our face - after some update. Colleague of mine just
dropped desktop version of
SharpSNMP into MA project and it worked - for a while.
Workflow:
* share code through linking and extensive use of partial classes
o VS add existing class/code file as link (add existing item +/
Add as link (not just **Add**)
this is very tedious, but can be avoided with tools such as VS
productivity tools, power
commands and VS project linker for whole projects
o for code sharing - common subset (lowest/smallest common
denominator) is mandatory.
This would be platforms that supports minimal set of
features/capabilities - in our experience
WP and Silverlight (example: only async methods***, no
UdpClient, XmlSerialization etc, etc)
+ put all common code that can be extracted (compiled) into
this project
+ link it in other projects (like onion add features) again
our experience levels from inside
# MT and MA - those are the same for BCL, but separation
in more projects allows
separation of build processes for each platform - so
what guys from Xamarin do
with msbuild/xbuild does not concern us (until needed)
they can do optimizations
and we have faith in them
# RIA
could be before MA/MT - matter of decission
# desktop/client
# server (asp.net)
Sample (our workflow for business logic layer, with service layer
usually more platform specific code, UI is very specific):
* in VS create lib projects for each platform
o BL.WP
o BL.MA
o BL.MT
o BL.dClnt (desktop client - if not hosting services) etc
o BL.Srvr.ASPnet (if needed)
* change properties for each project
o Default Namespace (recommended - I had problems with compilation
if this was not the case)
o Assembly name (prefix before dll or exe)
optional - I doubt someone will deploy App.dClnt.exe on other
platforms, but when searched
or browsed BL.MT.dll would be clear it is dll with business
layer for MonoTouch...
* with VS Project Linker add project links
o MA, MT, dClnt etc - get their source project BL.WP
Project linker nomenclature:
+ source project - where .cs physically resides
+ target[ing] project - where links to .cs files appear
* start implementing/porting layer BL in **common denominator** = WP
o add class
partial class Person in Person.cs (Name, Last, first , gender,
date of birth)
see comment**
o this adding of class will make project linker to add links to
this class to all targeting projects,
so Person.cs appears as link in all other projects
* add platform specific code samples:
this means add new code file or partial class file in each project
when needed
we do it manually
o copy class file (partial - remember?)
o remove everything inside, but namespace and classname
o rename it with some meaningful suffix Person.WP.cs , Person.MA.cs
+ WP
Person.Silverlight.cs (Silverlight.cs suffix will tell
Project linker not to add links in targets)
+ MT/MA
Person.MT.cs (MT.cs suffix is our convention)
+ desktop (this is my IceCreamSandwich)
Person.WF.cs or Person.WPF.cs or whatever, **but** inside:
[Serializable]
partial class Person{}
Note: attributes are sorta "additive" across partial classes
and this attribute will not
colide with Silverlight (Wp and/or RIA) serialization cos it
is in desktop project.
For Silverlight add Person.Silverlight.cs with:
[DataContract]
partial class Person{}
o so in each target project You end up with
+ link to Person.cs and
+ one or more Person.<sufix>.cs with deltas for platform
Got it?
** I cannot understand why VS still has project item (Class.cs) not as
partial - it does not hurt, but helps a lot
Some suggestions to MonoDevelop guys (M. Hutchinson and others) to make
MD a lot better w/o much
effort to add some features from (VS power commands, productivity tools
and project linker) such as:
* copy +/ paste as link for files and folders
* copy as reference, add as reference for projects and refs
in(reference lists) although MD edit references is
a lot better then native VS reference adding
* linking projects like Project Linker
o but with configurable exclusion patterns
Project Linker does not link (propagate links) for files with
extensions
+ *.Silverlight.cs or *.WPF.cs (and some others I believe)
* some ops on classes (this is possible with item and project
templates and we do it, but to add some sugar
to MD)
o make partial
o make partial and split 2 files with partial keyword!
o join dependency (DependsOn in .csproj) to make code readable
I'm doing that with axml file and it code behind
Cons:
* complexity
with adding platforms number of projects linearly grows
n-layers on m-platforms will cause n*m projects
we can discuss this, but adding single platform is adding complexity
in itself and linear
growth is not bad (this is what I have heard)
* tools
need to install and to get them know
Pros:
* cleaner code
no #ifdefs
* projects are compiled separately (oh yeah and packaged)
meaning optimizations etc is up to build process and not our concern
*** MT and MA allow sync methods (WebClient). If this is allowed and
possible it does not mean that this is
OK. Try not to use them, but for proof of concepts. Mobile devices (I
would say not only mobile apps, but any
app that behaves nicely) should be responsive - implying async is good
and forget about sync methods ASAP.
Tools:
I'm preparing small writeup how to port/migrate/expand existing apps or
libs to target more platforms
based on experience with Google GData and SharpSNMP (there are few more
others ready to be published
on github).
Do I need a different approach to the whole code sharing issue,
I could bet on it... Try this above and tell us Your results -please -
this is for all of us...
and why do I
get unhandled exceptions that are supposed to be handled?
Voodoo?
The reasons could be various and burried very deep into runtime and I
guess even Jon could not give
You answer right now.
For time beeing (until You try other approach) just assume: Voodoo!
cheers
mel
Regards
Stephan
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Stepping-into-standard-NET-libs-tp5711361.html
Sent from the Mono for Android mailing list archive at Nabble.com.
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
--
Miljenko Cvjetko dipl.ing. ET
Direktor/CEO
Projektant rjes(enja/Solution Architect
Razvojni programer/Senior developer
Voditelj projekta/Project Manager
IX juz(na obala 13
Kajzerica Zagreb
T: 385 1 7775555
M: 385 91 557 447 3
F: 385 1 7779556
e: mcvje...@holisticware.net
w: http://www.holisticware.net
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
