By SkySigal on 8/22/2008 2:32 PM

I'm currently working on a MVP (Model View Provider) based application that has to work on Compact Framework (CF) as well.

To get there with the most code-reuse between the two platforms, first thing I did was downloaded the MobileClientFactory and did a lot of changes and then merged the code with a desktop version of CAB in order to get one code base for both platforms.

This has worked quite well -- although CAB in general is a bit of a slow slug. Also, and this is the rough part, it seems to come from a department in MS that is underfunded or something, because versions are few and faaaar in between. So you're always wondering when you are going to be sandbagged by newer and better technology coming out of left field.

So 6 months ago, or so, when I first saw mention of the Unity project, I was quite excited that there might be a newer/fresher version coming along...

Turns out...might have to wait a bit longer for a better (and portable) framework:

Read More »

By SkySigal on 5/2/2008 2:00 PM

I guess that's what I'm ticked off about, and always have been with the MSPP products....they're not following the 80/20 rule for the core architecture....So you end up with assemblies that can do a whole lot of stuff, but at the price of being massively over-engineered for common day tasks, leaving us in a quandary over which route to follow:

a) Use clean well developed architecture, for even small projects, putting them on a good foot, but at the risk of adding +++Mb's of code to a tiny 200k app.

b) Avoid the bloat, but by avoiding the use of the better architecture patterns, continue with outdated and inefficient rewriting of the wheel code...

c) bake your own, and fork, and all the woes that go with that...

 

As far as I can see their management mistake it a) the tacking on of Enterprise architecture on to core libraries, and therefore getting in the way of seeing that it should be Core libraries for 80% of the scenarios, then Enterprise extensions for the remaining 20%...

And there is a serious disconnect between their products and platforms other than desktop (I'm thinking here about how long it took for them to address WPF, Web, Mobile and now Silverlight).

Grumble.

By SkySigal on 5/2/2008 1:26 PM

One of the best finds I made in the last 2 (has it been 3?!?) years was finding Microsoft's Patterns and Practices Composite UI block.
At first, the idea of using yet another external, that weighed quite a bit, just to add a couple of attributes, sounded...wrong.
But then, when I got it...wow! Especially the EventBroker part...it really changed the design of all my software projects.

But once I was hooked -- the reality set in. V.1 was ported to CE -- but then V.2 wasn't. Then the CE version was dropped. What about ASP.NET? Then WPF came out and CAB was not updated. Finally it was (years too late). Then Silverlight came out...no V there...In other words, it appears that MSPP is herding cats, and not delivering a unified direction to follow (I have a LOT to grumble about MSPP's management, but this is not the right time or place for that).

I looked around for a port job already done, and did find mention of 'SCAB' (Cab for Silverlight) on the web, but the zip I downloaded was just a skeleton, that had no code in it...(ie, they hadn't even started)...

Because I need it now, I set out to port CAB to Silverlight myself -- at least the essentials: WorkItem, EventBroker, Commands, Services. (Workspaces is maybe not a portable solution, but I will look into it later).

As I see it the problems that have to be addressed are: a) the dependency of MSPP's CAB on local config files, WinForms, and finally, the size....270k at the smallest!
I think I would like to see enough to do CAB in Silverlight in about 60k.

The first part of the puzzle is the the EventBroker, which you massaged into being its own assembly with no dependencies: you'll find XAct.SmartClients.EventBroker here.

You'll notice that I did not want to automatically lock myself into a WorkItem architecture -- it will accept it, but it will also accept any other object as a Context object.And the size looks nice...at present 21k in Debug mode... and I think doesn't have dependencies on any namespace/assembly that Silverlight doesn't support.

Anyway...this first part works:

I'll next be tackling the Commands architecture...which you'll find on the same link when I am done.