The primary focus of this release is the introduction of support for mono (Mac, Linux),
monotouch (iPhone, iPad), and mono for Android.

This version also supports Windows Phone “Mango” (SDK version 7.1).

You can now reuse your business code across .NET, Silverlight, Windows Phone, and
these newly supported platforms as well. As demand grows to build applications that
must work on various mobile devices, the ability to directly reuse your business classes
is compelling!

Version 4.2 also includes a number of enhancements to the existing CSLA 4 rule engine,
along with various other features and bug fixes. Check out the change
log for more information.

Our next step is to provide support for Silverlight 5 in CSLA 4 version 4.3, followed
by support for WinRT (Windows 8) in version 4.5. The expectation is that your existing
CSLA-based business classes will continue to work in Silverlight 5 and WinRT, providing
even more long-term reuse, maintainability, and cost-effective development.

CSLA 4 version 4.2 releasedhttp://www.lhotka.net/weblog/PermaLink,guid,7d3ffd97-bf3b-42cc-b701-357bc0b6b76d.aspxhttp://www.lhotka.net/weblog/CSLA4Version42Released.aspx
Thu, 01 Dec 2011 20:30:06 GMT<p>
CSLA 4 version 4.2 is now released and available for download.
</p>
<ul>
<li>
<a href="http://www.lhotka.net/cslanet/download.aspx">CSLA download page</a>
<li>
<a href="http://nuget.org/List/Search?packageType=Packages&amp;searchCategory=All+Categories&amp;searchTerm=csla">NuGet</a>
</li>
</ul>
<p>
The primary focus of this release is the introduction of support for mono (Mac, Linux),
monotouch (iPhone, iPad), and mono for Android.
</p>
<p>
This version also supports Windows Phone “Mango” (SDK version 7.1).
</p>
<p>
You can now reuse your business code across .NET, Silverlight, Windows Phone, and
these newly supported platforms as well. As demand grows to build applications that
must work on various mobile devices, the ability to directly reuse your business classes
is compelling!
</p>
<p>
Version 4.2 also includes a number of enhancements to the existing CSLA 4 rule engine,
along with various other features and bug fixes. Check out the <a href="http://www.lhotka.net/Article.aspx?id=2607a4ef-e6a9-4801-aa0b-518c51267339">change
log</a> for more information.
</p>
<p>
Our next step is to provide support for Silverlight 5 in CSLA 4 version 4.3, followed
by support for WinRT (Windows 8) in version 4.5. The expectation is that your existing
CSLA-based business classes will continue to work in Silverlight 5 and WinRT, providing
even more long-term reuse, maintainability, and cost-effective development.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=7d3ffd97-bf3b-42cc-b701-357bc0b6b76d" />CSLA .NETMonoDroidMonoTouchWP7http://www.lhotka.net/weblog/Trackback.aspx?guid=9ee9d2fb-9963-4111-9297-d22aa41ce0c9http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,9ee9d2fb-9963-4111-9297-d22aa41ce0c9.aspxRockford Lhotka

The Beta 1 release of CSLA 4 version 4.2 is now available for download on the CSLA
download page.

This version adds support for:

Windows Phone 7.5 “Mango”

mono

mono for iOS (iPhone/iPad)

mono for Android

Of course it continues to support .NET 4 and Silverlight 4.

This release also includes numerous bug fixes and small enhancements. In particular,
Jonny has done a lot of work to make the business rules subsystem more flexible and
powerful. See the change
log for a list of all changes.

At this point we have spent zero time or effort on the samples. Most samples will
continue to run when bound against the 4.2 assemblies, but some may encounter minor
issues. The samples in the download are still bound to the 4.1 assemblies. We will
be updating the samples during the 4.2 beta phase.

Because of the organizational changes of mono from Novell to Xamarin, the 4.2 release
has taken a lot longer than any of us would have preferred. I am pleased that we’re
entering the beta phase, and can now move deliberately toward a release.

If you are using 4.1, I strongly recommend that you test your code against
4.2. In part to help us identify any outstanding issues, and in part because the bug
fixes and enhancements to the rules subsystem may be very helpful to you.

CSLA 4 version 4.2 beta 1 releasehttp://www.lhotka.net/weblog/PermaLink,guid,9ee9d2fb-9963-4111-9297-d22aa41ce0c9.aspxhttp://www.lhotka.net/weblog/CSLA4Version42Beta1Release.aspx
Tue, 04 Oct 2011 20:07:55 GMT<p>
The Beta 1 release of CSLA 4 version 4.2 is now available for download on the <a href="http://www.lhotka.net/cslanet/download.aspx">CSLA
download page</a>.
</p>
<p>
This version adds support for:
</p>
<ul>
<li>
Windows Phone 7.5 “Mango”</li>
<li>
mono</li>
<li>
mono for iOS (iPhone/iPad)</li>
<li>
mono for Android</li>
</ul>
<p>
Of course it continues to support .NET 4 and Silverlight 4.
</p>
<p>
This release also includes numerous bug fixes and small enhancements. In particular,
Jonny has done a lot of work to make the business rules subsystem more flexible and
powerful. See the <a href="http://www.lhotka.net/Article.aspx?id=2607a4ef-e6a9-4801-aa0b-518c51267339">change
log</a> for a list of all changes.
</p>
<p>
At this point we have spent zero time or effort on the samples. Most samples will
continue to run when bound against the 4.2 assemblies, but some may encounter minor
issues. The samples in the download are still bound to the 4.1 assemblies. We will
be updating the samples during the 4.2 beta phase.
</p>
<p>
Because of the organizational changes of mono from Novell to Xamarin, the 4.2 release
has taken a lot longer than any of us would have preferred. I am pleased that we’re
entering the beta phase, and can now move deliberately toward a release.
</p>
<p>
If you are using 4.1, I <em>strongly recommend</em> that you test your code against
4.2. In part to help us identify any outstanding issues, and in part because the bug
fixes and enhancements to the rules subsystem may be very helpful to you.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=9ee9d2fb-9963-4111-9297-d22aa41ce0c9" />CSLA .NETMonoDroidMonoTouchWP7http://www.lhotka.net/weblog/Trackback.aspx?guid=547eb93e-e9d8-4a83-8eff-6e21c4c2fea0http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,547eb93e-e9d8-4a83-8eff-6e21c4c2fea0.aspxRockford Lhotka

There is now an alpha release of CSLA 4 version 4.2 available for download:

The big initiative for version 4.2 is to add support for the following platforms:

Linux and OS X (via Mono)

Android (via MonoDroid)

iPhone and iPad (via MonoTouch)

This alpha release does not include binaries for these platforms, but does include
code and sln files (for Visual Studio and/or MonoDevelop) you can use to build the
source on each of the platforms.

At this point in time we have the following:

CSLA 4 builds and runs on mono in Windows and Linux.

Core CSLA 4 functionality (Csla.dll) should be the same as on .NET 4.

ASP.NET code using CSLA objects should work using Csla.Web.dll

The Windows Forms support with Csla.Windows.dll is limited due to incompatibilities
in data binding between real Windows Forms and the mono implementation of Windows
Forms.

CSLA 4 builds and runs on Android. Use the MonoDroid tools in Visual Studio to build
Csla.dll.

You should find behaviors and features for Android identical to that provided for
WP7.

There is not currently an equivalent to Csla.Xaml.dll for Android.

No testing has been done around the use of any remote data portal channel – only the
local data portal has had any testing.

CSLA 4 builds and runs on iOS (iPhone/iPad). Use MonoDevelop on OS X to build Csla.dll.

You should find behaviors and features for iOS identical to that provided for WP7.

There is not currently an equivalent to Csla.Xaml.dll for iOS.

No testing has been done around the use of any remote data portal channel – only the
local data portal has had any testing.

Please remember, this is an alpha release, in the early stages of testing and stabilization.
Any help you can provide in terms of testing and resolving issues is appreciated!
Direct inquiries to http://forums.lhotka.net.

Other changes of note to existing .NET, SL, or WP7 users include:

When an async rule completes, rules for affected properties are now also run

BackgroundWorker from Csla.Threading is now available in WP7

Some cleanup work was done around CslaIdentity – this shouldn’t be a breaking change,
but the internals are now quite different

Fix a bug in non-generic GetProperty where field wasn’t always set to the correct
default value

CSLA 4 version 4.2 alpha releasehttp://www.lhotka.net/weblog/PermaLink,guid,547eb93e-e9d8-4a83-8eff-6e21c4c2fea0.aspxhttp://www.lhotka.net/weblog/CSLA4Version42AlphaRelease.aspx
Sat, 26 Mar 2011 23:13:06 GMT<p>
There is now an alpha release of CSLA 4 version 4.2 available for download:
</p>
<ul>
<li>
<a href="http://www.lhotka.net/cslanet/download.aspx">Download CSLA 4 version 4.2.0</a>
</li>
</ul>
<p>
The big initiative for version 4.2 is to add support for the following platforms:
</p>
<ul>
<li>
Linux and OS X (via Mono)</li>
<li>
Android (via MonoDroid)</li>
<li>
iPhone and iPad (via MonoTouch)</li>
</ul>
<p>
This alpha release does not include binaries for these platforms, but does include
code and sln files (for Visual Studio and/or MonoDevelop) you can use to build the
source on each of the platforms.
</p>
<p>
At this point in time we have the following:
</p>
<ol>
<li>
CSLA 4 builds and runs on mono in Windows and Linux.</li>
<ol>
<li>
Core CSLA 4 functionality (Csla.dll) should be the same as on .NET 4.</li>
<li>
ASP.NET code using CSLA objects should work using Csla.Web.dll</li>
<li>
The Windows Forms support with Csla.Windows.dll is limited due to incompatibilities
in data binding between real Windows Forms and the mono implementation of Windows
Forms.</li>
</ol>
<li>
CSLA 4 builds and runs on Android. Use the MonoDroid tools in Visual Studio to build
Csla.dll.</li>
<ol>
<li>
You should find behaviors and features for Android identical to that provided for
WP7.</li>
<li>
There is not currently an equivalent to Csla.Xaml.dll for Android.</li>
<li>
No testing has been done around the use of any remote data portal channel – only the
local data portal has had any testing.</li>
</ol>
<li>
CSLA 4 builds and runs on iOS (iPhone/iPad). Use MonoDevelop on OS X to build Csla.dll.</li>
<ol>
<li>
You should find behaviors and features for iOS identical to that provided for WP7.</li>
<li>
There is not currently an equivalent to Csla.Xaml.dll for iOS.</li>
<li>
No testing has been done around the use of any remote data portal channel – only the
local data portal has had any testing.</li>
</ol>
>
<p>
Please remember, this is an alpha release, in the early stages of testing and stabilization.
Any help you can provide in terms of testing and resolving issues is appreciated!
Direct inquiries to <a href="http://forums.lhotka.net">http://forums.lhotka.net</a>.
</p>
<p>
Other changes of note to existing .NET, SL, or WP7 users include:
</p>
<ul>
<li>
When an async rule completes, rules for affected properties are now also run</li>
<li>
BackgroundWorker from Csla.Threading is now available in WP7</li>
<li>
Some cleanup work was done around CslaIdentity – this shouldn’t be a breaking change,
but the internals are now quite different</li>
<li>
Fix a bug in non-generic GetProperty where field wasn’t always set to the correct
default value</li>
</ul>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=547eb93e-e9d8-4a83-8eff-6e21c4c2fea0" />CSLA .NETmonoMonoDroidMonoTouchhttp://www.lhotka.net/weblog/Trackback.aspx?guid=d20a1cbe-db9f-45cb-b1eb-6830581d68f2http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,d20a1cbe-db9f-45cb-b1eb-6830581d68f2.aspxRockford Lhotka

A few weeks ago I posted about my initial efforts to port CSLA 4 to MonoDroid. The
idea being that business classes created for WP7 could be used on Android as well.

That inspired some people – which is awesome!

Stuart Bale volunteered to help port CSLA 4 to MonoTouch, for iOS (iPhone/iPad).

Jonny Bekkum (a long-time CSLA team member) volunteered to port CSLA 4 to mono – the
open source implementation of .NET that runs on Linux, Windows, and other platforms.

Kevin Ford volunteered to finish what I’d started by getting CSLA 4 ported to MonoDroid
(in reality, he’d already started a parallel effort, and then merged his work into
mine).

Initial code for all three projects has been checked into the svn code repository.
Jonny has some test apps running in mono, so there’s some confidence in that code.
Kevin has a small test app running in Android, so there’s some confidence there too
(though it is earlier in the process). The MonoTouch port is the hardest of the three
due to some limitations of MonoTouch, and we don’t know for sure that the current
code works (though it does build in MonoDevelop).

My current plan is that CSLA 4 version 4.2 will be the release that includes support
for mono, Android, and iOS – in addition to the existing support for .NET, Silverlight,
and Windows Phone. That’ll be exciting!

If you are a developer on any of these three new targets, we’d appreciate any help
in testing the code to see if it works, and to find solutions to anything that doesn’t
work. Please post any issues or comments on the forum at http://forums.lhotka.net –
thanks!

CSLA 4 mono platform porting updatehttp://www.lhotka.net/weblog/PermaLink,guid,d20a1cbe-db9f-45cb-b1eb-6830581d68f2.aspxhttp://www.lhotka.net/weblog/CSLA4MonoPlatformPortingUpdate.aspx
Wed, 09 Mar 2011 23:16:38 GMT<p>
A few weeks ago I posted about my initial efforts to port CSLA 4 to MonoDroid. The
idea being that business classes created for WP7 could be used on Android as well.
</p>
<p>
That inspired some people – which is awesome!
</p>
<ul>
<li>
Stuart Bale volunteered to help port CSLA 4 to MonoTouch, for iOS (iPhone/iPad).</li>
<li>
Jonny Bekkum (a long-time CSLA team member) volunteered to port CSLA 4 to mono – the
open source implementation of .NET that runs on Linux, Windows, and other platforms.</li>
<li>
Kevin Ford volunteered to finish what I’d started by getting CSLA 4 ported to MonoDroid
(in reality, he’d already started a parallel effort, and then merged his work into
mine).</li>
</ul>
<p>
Initial code for all three projects has been checked into the svn code repository.
Jonny has some test apps running in mono, so there’s some confidence in that code.
Kevin has a small test app running in Android, so there’s some confidence there too
(though it is earlier in the process). The MonoTouch port is the hardest of the three
due to some limitations of MonoTouch, and we don’t know for sure that the current
code works (though it does build in MonoDevelop).
</p>
<p>
My current plan is that CSLA 4 version 4.2 will be the release that includes support
for mono, Android, and iOS – in addition to the existing support for .NET, Silverlight,
and Windows Phone. That’ll be exciting!
</p>
<p>
If you are a developer on any of these three new targets, we’d appreciate any help
in testing the code to see if it works, and to find solutions to anything that doesn’t
work. Please post any issues or comments on the forum at <a href="http://forums.lhotka.net">http://forums.lhotka.net</a> –
thanks!
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=d20a1cbe-db9f-45cb-b1eb-6830581d68f2" />CSLA .NETmonoMonoDroidMonoTouchhttp://www.lhotka.net/weblog/Trackback.aspx?guid=13bc5204-7a66-4525-acb8-2856ea0fc273http://www.lhotka.net/weblog/pingback.aspxhttp://www.lhotka.net/weblog/PermaLink,guid,13bc5204-7a66-4525-acb8-2856ea0fc273.aspxRockford Lhotka

I’ve started the process of porting CSLA .NET version 4.1 to MonoDroid.
I expected this to be relatively easy because I’ve already got a version of CSLA 4
running on WP7, and from everything I know about MonoDroid it should be pretty comparable
(excluding anything to do with XAML and UI concepts of course).

After a couple hours of trying to get the Android emulator to run on my machine, I
discovered that the hybrid C++ and Java worlds really don’t “get” Windows. They interpret
Windows configuration in different ways. I’m not sure which one is lame and out of
date (by around a decade), but either C++ or Java apparently needs help…

Fortunately some googling (with Bing of course )
turned up the answer in the form of an environment setting named ANDROID_SDK_HOME
that both C++ and Java will honor. The problem is that my User directory isn’t on
the C drive, and either C++ or Java can’t handle this concept. Setting ANDROID_SDK_HOME
to the path of my actual User directory solves the issue so the emulator works as
expected.

The Android emulator is extremely slow, but functional. Just deploying my
tiny little test app takes several minutes, and my computer is no slouch. It is clear
that Android developers don’t round-trip very fast in terms of running their code
to see if it works. I feel sort of like I’m back in 1992 on a VAX where the compile-link-run
cycle took minutes. I’m obviously very spoiled with the performance of things like
the WP7 emulator or the ASP.NET development web server, where the compile-debug/run
cycle takes seconds (at most).

The process of getting CSLA 4 to at least build in MonoDroid took around 4 hours of
work. Not that I’m done, but the code does compile at this point. The holdups and
issues are:

MonoDroid doesn’t have ObservableCollection and a set of related types, so I’ve started
implementing them myself

MonoDroid doesn’t know about “Add service reference”, it only knows about “Add web
reference”, and that means I need to create a new data portal proxy/host pair

It doesn’t look like the System.ServiceModel assembly that comes with MonoDroid actually
works – my one remaining build error has to do with this assembly – and this probably
means some other client-side data portal elements will be affected (like LocalProxy)
– I think this indicates some bad factoring on the part of CSLA in terms of the client-side
data portal implementation though, so in an odd way this might be beneficial in that
the problem highlights a design flaw that needs fixing

There are some bugs in MonoDroid in VS, where setting some project properties “doesn’t
take” – change the property values in VS and they aren’t saved to the project file
– but edit the project file in a text editor and the changes are honored – not a big
deal, and MonoDroid is in an early beta, so this sort of thing is to be expected

There’s no XAML or directly comparable concept on Android, so I’m not even trying
to port Csla.Xaml, only the core Csla project – I’ll probably need to create a Csla.Android
project with UI components appropriate to the Android UI technology

I mocked up the initial types to implement ObservableCollection, and it won’t take
a lot more effort to make them have the functionality required by CSLA. I don’t feel
the need to completely replicate those types – only the parts CSLA cares about.

Creating a data portal proxy/host pair isn’t hard, the data portal is designed with
this sort of flexibility in mind. However, this will be the first non-WCF proxy/host
pair I’ve built on the Silverlight/WP7 code base, so I’m looking forward to establishing
that it is as easy as it should be.

The unexpected dependencies on System.ServiceModel are probably the most worrisome
aspect of this project so far. I suspect unraveling the dependencies and fixing the
design/implementation may lead to some breaking changes in the Silverlight/WP7 code.
On the other hand, if my early suspicions are correct, the design is probably flawed
and I’ll be able to improve things as a result.

The question is whether I leave the SL/WP7 code alone and just fix the dependencies
in the Android code base. That’s probably what I’ll do in the 4.x timeframe, because
I really try to avoid substantial breaking changes in point releases…

The loss of Csla.Xaml is not ideal. At the very least I think a Csla.Android project
will need ViewModelBase and ViewModel, but I suspect other Android-related UI components
may be required.

Anyway, I’m quite impressed by MonoDroid. It seems pretty complete, pretty functional,
and pretty well integrated into Visual Studio. Other than my issues with the emulator
configuration the install was painless.

To head off this question before it is asked: I do expect I’ll create a version for
MonoTouch at some point.

But MonoDroid has a much lower barrier of entry since it installs on Windows and works
in Visual Studio. MonoTouch requires a non-trivial cash outlay to buy a Mac, and a
non-trivial time outlay to learn the Mac, MonoDevelop, some Mac svn implementation,
etc. Where I’ll probably have a working version of CSLA 4 for Android in under 20
hours, I strongly suspect it will take more than twice that long (and a lot of money)
to get a version working in iOS.

In this regard I must give kudos to Google, Android and MonoDroid – they have a much
lower barrier to entry than Apple currently provides.

Porting CSLA 4 to MonoDroidhttp://www.lhotka.net/weblog/PermaLink,guid,13bc5204-7a66-4525-acb8-2856ea0fc273.aspxhttp://www.lhotka.net/weblog/PortingCSLA4ToMonoDroid.aspx
Thu, 20 Jan 2011 05:30:11 GMT<p>
I’ve started the process of porting CSLA .NET version 4.1 to <a href="http://monodroid.net/">MonoDroid</a>.
I expected this to be relatively easy because I’ve already got a version of CSLA 4
running on WP7, and from everything I know about MonoDroid it should be pretty comparable
(excluding anything to do with XAML and UI concepts of course).
</p>
<p>
After a couple hours of trying to get the Android emulator to run on my machine, I
discovered that the hybrid C++ and Java worlds really don’t “get” Windows. They interpret
Windows configuration in different ways. I’m not sure which one is lame and out of
date (by around a decade), but either C++ or Java apparently needs help…
</p>
<p>
Fortunately some googling (with <a href="http://bing.com">Bing</a> of course <img style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" class="wlEmoticon wlEmoticon-smile" alt="Smile" src="http://www.lhotka.net/weblog/content/binary/Windows-Live-Writer/Porting-CSLA-4-to-MonoDroid_14308/wlEmoticon-smile_2.png" />)
turned up the answer in the form of an environment setting named ANDROID_SDK_HOME
that both C++ and Java will honor. The problem is that my User directory isn’t on
the C drive, and either C++ or Java can’t handle this concept. Setting ANDROID_SDK_HOME
to the path of my actual User directory solves the issue so the emulator works as
expected.
</p>
<p>
The Android emulator is <em>extremely</em> slow, but functional. Just deploying my
tiny little test app takes several minutes, and my computer is no slouch. It is clear
that Android developers don’t round-trip very fast in terms of running their code
to see if it works. I feel sort of like I’m back in 1992 on a VAX where the compile-link-run
cycle took minutes. I’m obviously very spoiled with the performance of things like
the WP7 emulator or the ASP.NET development web server, where the compile-debug/run
cycle takes seconds (at most).
</p>
<p>
The process of getting CSLA 4 to at least build in MonoDroid took around 4 hours of
work. Not that I’m done, but the code does compile at this point. The holdups and
issues are:
</p>
<ol>
<li>
MonoDroid doesn’t have ObservableCollection and a set of related types, so I’ve started
implementing them myself</li>
<li>
MonoDroid doesn’t know about “Add service reference”, it only knows about “Add web
reference”, and that means I need to create a new data portal proxy/host pair</li>
<li>
It doesn’t look like the System.ServiceModel assembly that comes with MonoDroid actually
works – my one remaining build error has to do with this assembly – and this probably
means some other client-side data portal elements will be affected (like LocalProxy)
– I think this indicates some bad factoring on the part of CSLA in terms of the client-side
data portal implementation though, so in an odd way this might be beneficial in that
the problem highlights a design flaw that needs fixing</li>
<li>
There are some bugs in MonoDroid in VS, where setting some project properties “doesn’t
take” – change the property values in VS and they aren’t saved to the project file
– but edit the project file in a text editor and the changes are honored – not a big
deal, and MonoDroid is in an early beta, so this sort of thing is to be expected</li>
<li>
There’s no XAML or directly comparable concept on Android, so I’m not even trying
to port Csla.Xaml, only the core Csla project – I’ll probably need to create a Csla.Android
project with UI components appropriate to the Android UI technology</li>
</ol>
<p>
I mocked up the initial types to implement ObservableCollection, and it won’t take
a lot more effort to make them have the functionality required by CSLA. I don’t feel
the need to completely replicate those types – only the parts CSLA cares about.
</p>
<p>
Creating a data portal proxy/host pair isn’t hard, the data portal is designed with
this sort of flexibility in mind. However, this will be the first non-WCF proxy/host
pair I’ve built on the Silverlight/WP7 code base, so I’m looking forward to establishing
that it is as easy as it should be.
</p>
<p>
The unexpected dependencies on System.ServiceModel are probably the most worrisome
aspect of this project so far. I suspect unraveling the dependencies and fixing the
design/implementation may lead to some breaking changes in the Silverlight/WP7 code.
On the other hand, if my early suspicions are correct, the design is probably flawed
and I’ll be able to improve things as a result.
</p>
<p>
The question is whether I leave the SL/WP7 code alone and just fix the dependencies
in the Android code base. That’s probably what I’ll do in the 4.x timeframe, because
I really try to avoid substantial breaking changes in point releases…
</p>
<p>
The loss of Csla.Xaml is not ideal. At the very least I think a Csla.Android project
will need ViewModelBase and ViewModel, but I suspect other Android-related UI components
may be required.
</p>
<p>
Anyway, I’m quite impressed by MonoDroid. It seems pretty complete, pretty functional,
and pretty well integrated into Visual Studio. Other than my issues with the emulator
configuration the install was painless.
</p>
<p>
To head off this question before it is asked: I do expect I’ll create a version for
MonoTouch at some point.
</p>
<p>
But MonoDroid has a much lower barrier of entry since it installs on Windows and works
in Visual Studio. MonoTouch requires a non-trivial cash outlay to buy a Mac, and a
non-trivial time outlay to learn the Mac, MonoDevelop, some Mac svn implementation,
etc. Where I’ll probably have a working version of CSLA 4 for Android in under 20
hours, I strongly suspect it will take more than twice that long (and a lot of money)
to get a version working in iOS.
</p>
<p>
In this regard I must give kudos to Google, Android and MonoDroid – they have a <em>much
lower</em> barrier to entry than Apple currently provides.
</p>
<img width="0" height="0" src="http://www.lhotka.net/weblog/aggbug.ashx?id=13bc5204-7a66-4525-acb8-2856ea0fc273" />CSLA .NETMonoDroid