The MossyBlog Times Archives 2007 - 2009 : Flex

Silverlight and Flex working together.

scbarnes — Mon, 20 Aug 2007 18:32:23 GMT

I've talked about this a lot, even produced some demos for presentation on the subject, yet there is one online you can see today.

The guys at Switch On the Code have put together a demo of using Flex Sliders to manipulate a Silverlight ball. They also posted a tutorial on how they were able to make it happen.

I did wonder why they didn't make reference to the ExternalInterface API (i.e. send the data back from Silverlight to Adobe Flex?) Anyway, it's yet another example of how the two runtimes can work with one another easily enough - provided you are open to the idea.

I'd classify these guys "Prototypers"

Web On The Piste (New Zealand).

scbarnes — Mon, 13 Aug 2007 04:48:40 GMT

I'll be attending and speaking at the first "Web On The Piste" in New Zealand next week. This is a conference being organized by both Straker and Gruden, two companies in which I've had a lot of positive dealings with over the years. It's shaping up to being hopefully a permanent fixture on my conference calendar going forward (that and the Queenstown Skiing surely helps the cause).

"..Web on the Piste is scheduled for the 22nd - 23rd of August , 2007 at the ultimate in venues, Queenstown, New Zealand. We are bringing world leaders in Rich Internet and associated technologies as speakers and instructors for 2 days of Flex, AJAX, SPRY, Apollo and Flash as well as covering server-side back end technologies such as ColdFusion, .Net, Java and PHP and some sessions on mobile based content delivery..."

I think I'll be both on a "Panel Discussion" and will talking about how one is able to re-use some of their Adobe Flex skill set with Silverlight (don't worry it won't be a political mess and It's targeted at those folks whom have *already* made the decision to try Microsoft Silverlight but have a Adobe Flex background).

I'm looking forward to meeting some of the New Zealand RIA folks who I met at WebDU early this year whilst also catching up with some of the Aussie Adobe Community folks as well.

Special warm thankyou goes towards Straker & Gruden for making some bold steps towards organising this event for the first time.

We gave birth to RIA.

scbarnes — Tue, 24 Jul 2007 23:32:45 GMT

Adobe's Mike Downey and I were throwing comments back and forth on twitter.com this morning, it was derived from Brad Becker (ex Flash Product guy @ Macromedia and now Microsoft staffer) post on RIA.

Brad posted this a few months ago when JD @ Adobe got all fired up over Rich Interactive Applications vs Rich Internet Applications. Adobe will argue until they are blue in the face that Microsoft are attempting to Hijack the term RIA and .. blah blah blah.

Honestly, whom named RIA (Microsoft or Adobe) has become irrelevant. If you look at the history of RIA overall, it's something that we have always hinted at but never could quite get there.

VRML for example would have to by far my earliest memory of the "RIA" concept. You have a rich 3D world in which you can interact with, but of course in the late 1990's there was only so much you could do in terms of client-to-server side interaction.

In 2000, I remember seeing Erik's attempt at WebOS.com, which was by far the earliest iteration of RIA / AJAX I've seen. You may know of Erik today as one of the brains behind Google Gears, WebFX and Bindows.NET

I was working on Billabong's website's in 2000, when I first started to use Flash + Remote Servers, but it was with Flash 5 and all I could do was bring in variables remotely via PARAM or URL string. RIA was my intent but couldn't execute.

I've been on the Macromedia ride ever since, but like all the previous iterations of "RIA" it just hasn't been executed. There have been success stories of RIA working today, but it hasn't changed the landscape and I say this as if it has we wouldn't be seeing AJAX. There is no need for AJAX if "FLASH" RIA were to succeed? one cancels out the other and many have argued this case.

Silverlight and Flash Player are advanced, no question in this but both Adobe and Microsoft can't own RIA because it's realistically an idea or belief that was first formed many years ago and whilst Adobe will have you believe they are the founders of RIA, they simply built a campaign around it.

It's like saying AJAX is owned by Jesse James Garrett or he invented AJAX? (he did? I'm sure Google and Microsoft both had a large role to play in this, Microsoft with XmlHttpRequest and Google in its mainstream use).

We the community are the ones whom own RIA, not Microsoft or Adobe. They simply enable and market the idea of what RIA should be.

Silverlight: Project vs Prototype.

scbarnes — Tue, 24 Jul 2007 21:36:49 GMT

I get a lot of emails about how one should approach Silverlight and whether they should hold off until the control/layout frameworks are feature complete.

My answer is simple, focus on what you have today as it will be something in which if you invest now will aide you once the framework(s) / future features hit.

I say this from experience, as when I was first given access to Adobe Flex many years ago, it was without a Debugger, No Editor and the framework was being pieced together as I was shown. It was admittedly frustrating at first, but It helped me understand how the technology was starting to take form, it was because of this that I understood how the framework inside Adobe Flex intersects with various other pieces / API's found within the technology.

This is about prototyping, not project building per say. If you can put together a Silverlight piece that does nothing but make round circles bounce off one another, then this is the absolute right attack posture for Silverlight.

If you walk away from a Silverlight presentation and immediately want to build your next RIA and have no or little experience with doing so, chances are you will fail. I say this as despite both Microsoft and Adobe making really strong aggressive advancements in producing RIA, there is still a mindset needed to be undertaken. There are still limitations throughout and it's about understanding RIA first and foremost. It's about playing with the technology physics and getting a feel on how it can assemble and most important of all, it's about knowing the tools you are about to invest a lot of money and time into.

Producing RIA can be fun, but start of with basic prototypes and later the projects will come more naturally.

If you have prototypes, let me know as I want to compile a list of them to show folks both internally and externally.

Going Flex to Silverlight: Understanding our DisplayList API.

scbarnes — Sun, 27 May 2007 12:49:39 GMT

Disclaimer: This is part two of my Going Flex to Silverlight series, where I'll be talking about how one is able to transfer concepts they have learnt in Flex world but are looking to explore what Silverlight also has to offer. Whatever reason they have chosen, is entirely up to them and this isn't to be taken as a feature for feature comparison.

In the Adobe Flex (ActionScript) to create a child element/object within the code base, you would punch out something like this:

	var txt:TextField = new TextField();
	txt.x = 100;
	txt.y = 0;
	txt.text = "Click for more info...";
	addChild(txt)

Which would then render MyButton onto the DisplayObjectContainer in question (provided it derives from a DisplayObject).

Inside Silverlight, there is a similar approach but instead of just limiting to syntax code, one is able to piece together elements within elements through loading XAML at runtime. In that, you can access XAML pieces parked on your host, bring them in at runtime and instantiate them (children and all) through the CreateFromXAML. example:

    // Retrieve a reference to the control.
    var control = sender.getHost();
    
    // Define a XAML fragment and create it.
    var xamlFragment = '<TextBlock Canvas.Top="200" Text="Click for more info..." />';
    textBlock = control.content.createFromXaml(xamlFragment);

    // Add the XAML fragment as a child of the root Canvas object.
    sender.children.add(textBlock);

As you can see, there are some similarities in approach, suffice to say that one is mode of approach. It's also important to note that you are also able to create child elements through managed code such as C# using Flex style syntax - which - can be found in both WPF and Silverlight. Yet, if you prefer JavaScript you can use the CreateObject(type) approach, which is similar I guess to the Coldfusion approach to life as well (CreateObject is used to instantiate Coldfusion Classes inside managed code).

Another cool feature within the CreateFromXAML bag of tricks, is that you can also create XAML pieces loaded in via .ZIP files themselves similar to I guess Flex Modules API. This is done via CreateFromXamlDownloader Method.

function onDownloadCompleted(sender, eventArgs)
{
    // Determine whether the download was successful.
    if (currentDownloadProgress != 1)
    {
    	alert("Failed to succesfully download zip file");
        return;
    }

    // Retrieve the XAML content from the downloaded package file.
    var jacketBrowserXaml = sender.getResponseText("jacketBrowser.xaml");

    // Create the objects from the XAML content.
    var jacketBrowser = control.content.createFromXaml(jacketBrowserXaml);

    // Add downloaded XAML content to the control.
    sender.findName("root").children.insert(0, jacketBrowser);

    // Retrieve a reference to the Image object representing the jacket.
    var jacketImageSlice = sender.findName("jacketSlice");

    // Set the Source property of the Image object to the specific jacket image
    // within the downloaded Zip package file.
    jacketImageSlice.setSource(sender, "rotation01_green.png");
}

The children collection there after has also all the typically Method calls made available for you then to find different elements by various means. Yet, if you are unsure of where an element exists within the XAML DOM itself but do remember it's name, one is able to then use the FindName Method

function onLoaded(sender, eventArgs)
{
    // Retrieve a reference to the control.
    var control = sender.getHost();

    // Retrieve a reference to the specified object.
    var object = control.content.findName("myTextBlock");

    // If a valid object reference, display an alert dialog box.
    if (object != null)
    {
        alert(object.toString() + " found");
    }
}

This is also the very similar to the way Flex does it inside Flash.display.DisplayObjectContainer's in that it would allow something along the lines of:

	var target:DisplayObject = container.getChildByName("myTextBlock"); 
	trace(container.getChildIndex(target)); // 0

This however would be done on the same node level as the actual Parent of the child. The FindName method however searches the entire Silverlight hierarchy for the element that have the name you provided.

Summary
There is a lot that Silverlight has on offer and when you dig deeper into what it has today, even in it's alpha state, there is a lot of goodness to be found. I'll continue to expose some of these gems going forward, and if you want me to discuss a topic of some kind, drop me an email on it. That being said, one thing I'd like you all to take away from this post is that the CreateXAMLFromDownloader is a massive step forward if you ask me in terms of performance / architecture design & development for applications should they enter the Silverlight path post its release.

More Info: http://msdn2.microsoft.com/en-us/library/bb412361.aspx

The basics of a Silverlight Control

scbarnes — Sun, 13 May 2007 17:25:06 GMT

I've been sitting here for the past few days really getting my head deeper into Silverlight and I'll post more example's of going from Flex to Silverlight later this week. I will however branch out a bit here and illustrate one nugget that I wish someone had of sat over my shoulder and told me about prior to embarking on Silverlight 101.

InitializeFromXaml is your friend.

In C# (Managed Code) I was struggling initially on how the hell do I create children within a Canvas tag for example. In that how does Orcas know how to assemble the pieces together so that I have not only nested children via C# but at the same time, ensuring Silverlight runtime knows as well (ok, one in the same I guess).

How about some code:

XamlPath = "com.mossyblog.MyFile.xaml";
System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream(XamlPath);
actualControl = this.InitializeFromXaml(new System.IO.StreamReader(s).ReadToEnd());

A bunch of stuff happens here in 2 small lines of code, but basically it reads in the file path I pass in (XamlPath) and invokes this.InitializeFromXaml() to effectively read in the file and instantiate this control.

It's important to make mental note of this as when you write your own controls inside Silverlight, you will need to do this for all Controls (unless you extend Canvas or something along those lines).

That being said if you use the example UI Framework (Located in the Alpha 1.1 SDK) you can effectively bypass a lot of this by simply extending the ControlBase Class (which does it's own automatic lookup in terms of path finding and appropriate level of instantiation)

Creating Children from within a Custom Control

After you master the "How" for bringing in XAML files as controls within your code-behinds, it's now a bit of a head scratching exercise on how one is able to then instantiate sub-children within?

If you do a "this." and await intelli-sense you're not going to see any methods like "add()" which is what you need right?

Well again, looking at the SDK examples you will note the following in some parts:

((Canvas)ActualControl).Children.Insert(0, content);
[via ListBox.cs]

Inside ControlBase class, there is a public property named AcutalControl, which then points to a private property called actualPath which was given it's value based off the result of this.initializeFromXaml() method invocation (Important to note kids).

This specific type returned from doing this is FrameworkElement (which basically means all roads lead back to this guy). Now, FrameworkElement does have Add children methods if you were to read-up on it via the XAML documentation (WPF folks will love it). In Silverlight however, if you were to typecast it as a Canvas element (which is legal) you effectively are then able to use Children.Add( myChild ) approach to life.

Example:

public VideoThumbNail()
{
    this.setXamlPath("APAC07.Carrousel.VideoThumbNail.xaml");
    this.createChildren();
    this.measure();
    this.updateDisplayList();
}

public void createChildren() {
base.createChildren();

ImageThumbNail it = new ImageThumbNail();
((Canvas)ActualControl).Children.Add(it);

}

I wrote my own event management approach to Silverlight simply because I was bored and thought it may help Adobe Flex Developers understand Silverlight by using similar concepts found within Adobe Flex 2.0.1 framework.

I'm not kidding, with enough time I think I could easily code-port the framework into Silverlight (given Adobe Flex soon will be open source - it may even be legal! hehe).

I hope this helps folks understand how the creation of children happens with managed code inside Silverlight development space. It's pretty straightforward once someone shows you at the start and then from there on out it's just downhill all the way (not as scary).

Back to coding, as I need this demo finished by Wednesday for the APAC Sharepoint conference where I'll be showing folks how Sharepoint + Silverlight can play a role with one another.

Going flex to Silverlight: The basics (easy stuff first).

scbarnes — Thu, 10 May 2007 10:38:01 GMT

Introduction

This is going to probably annoy some, and signal mixed messages but overall the approach I am taking is to provide a context driven learning path on how to go from Adobe Flex coding to Microsoft Silverlight. I really don't want these posts to be fuel for the "Flash Killer" BBQ's as that's counter-productive, it's intended to be more focused on helping folks whom are curious about Silverlight (for whatever reason they chose) and are about to embark on the ramp-up in learning about it.

It's important no matter what bloodline you come from to be at least aware of the basics of Silverlight, what it has to offer going forward and lastly how easy it may make life for you (depending on your project / context).

In light of this, I'll be doing a lot of these "If only I knew" style posts, as one thing I learnt very fast coming over to the Microsoft feeding tank was how easy life really is for the average .NET developer and Silverlight is no different.

Hopefully this won't be turned into a "Flex vs Silverlight" piece but more of a way to empower Adobe Flex developers to gain an understanding of Silverlight through a more context driven discussion (e.g. "You know how you do x in Flex right? well in Silverlight they do it this way")

Namespaces

Typically in MXML to load in controls within your project, you would do something along the lines of this:

<mx:Application xmlns:appCntrls="com.mossyblog.controls.*"/>

<appCntrls:MyButton/>

Essentially, appCntrls:MyButton is a pointer to a file in the com/mossyblog/controls/MyButton.as (or mxml) but done so through tag based approach. It's actually quite useful in doing this as you're effectively creating your own XML vocab along with custom properties (attributes) and in Flex can even go further by nesting tags within tags (similar to DOM in essence)

Life in Silverlight is really no different, except when you make namespace declaration you're also telling the CLR where to compile the end result (DLL) , which is an interesting thing to note. As within Adobe Flex typically to do this you'd start to look into strategies around mx:Modules or Runtime Shared Libraries, which can be extremely powerful when used appropriately.

In Silverlight, to do this you simply type:

<app:MainView xmlns:app="clr-namespace:com.mossyblog.controls;assembly=MyBinDir/com.mossyblog.controls.dll">

There's more to this, but I'll discuss this another time (i.e. what does Assembly mean along with the specifics of clr-namespace)

Note: In Adobe Flex generally the xmlns (default) points to a URI path which is consistent globally (In essence this points to the framework manifest file which in turn points to the components and their respective name / path pairs within), same deal in Silverlight only it's "http://schemas.microsoft.com/client/2007" which gives the compiler the core framework reference pointer locations (will expand on this in future posts).

GEOM / Graphic Tags.

Inside Adobe Flex your entire tag based approach to life is driven from components that have a specific purpose (Usually not so much around Assets but more so in specific Navigation/Layout/Form style controls etc). In that you would rarely ever see the tag <Line> as what purpose would this serve in Flex? You could easily write a .AS file called Line.as which inside that uses the LineTo style approach to life (i.e. render a line using the drawing API + Flash.Geom Objects). That or you would typically use bitmap assets to handle a lot of the creative elements, but overall you have a lot of possibilities in Adobe Flex to handle this but are usually kept inside the actual components themselves.

In Silverlight, you're using the XAML language itself and what this means is that whenever you have a vector based asset inside your application, you in turn will see tags that outline what that "asset" is made-up off in terms of properties and semantically marked up description (i.e. you'll hear the words brush thrown around a lot for example).

eg:
<Line x:Name="HeaderTextLine" Opacity="0" X1="25" Y1="62" X2="635" Y2="62" StrokeThickness="4">

The overall point is that you're combining the drawing tag elements with future form/layout components and default controls as they eventually come. It can be somewhat of an initial shock as coming from a Adobe Flex environment you're typically used to seeing specific tags like Accordion, Button and so on only (also custom tags like <MyForm> etc). Silverlight offers you the same approach as this, but the important piece out of all of this to understand is that with XAML all assets are marked-up in an XML format (except if you prefer to use bitmap of course).

Basic stuff right? (Let me know if that did not make sense).

However, you really don't need to be to worried about the specifics of hand-coding these tags, as Expression Blend for example takes over that burden and automagically spits this out into inline code for you (yay!). This is good thing as if you're a code nutter like me, you can wrap these pieces into composite components, which house the XAML code within (just like you'd make your own MXML component out of the Adobe Flex Framework primitives etc).

Next Post.. Code-behinds and XAML

P.S
If there is a part of Silverlight you want me to cover in this "How to" approach, please leave comments as I'll do it! :)

Flex Open Source, what's changed?

scbarnes — Fri, 27 Apr 2007 06:24:49 GMT

I've been getting a lot of requests for comments on this subject and I'll be brief. As I think it's a politically hot topic and I don't want to get into that level of discussion (no good can come from it).

Flex SDK was free anyway.
Flex compiler is now free for all to use. That being said in the past, projects like http://osflash.org/swf was always there? I mention this as I get what they are doing but I only see this as being a way of leaning on the community to do more for them, and to be honest, enough already :) you've asked too much as-is.
Entry barrier for FLEX hasn't changed, people still need to scratch their heads and figure out how to go from no idea what ActionScript 3.0 / MXML is to learning the code base and then figuring out how the framework gels together. It's good but keep in perspective, the game hasn't changed just the playing field is no longer concrete, but grass (fertile growth is where I'm heading).
Why stop at FLEX the language, I think the real room for innovation should be around Flex Builder 2.0.1 (FB) so if CFEclipse + FB were to marry, that would be some taste stuff.
Server-side pieces are still going to be a price hurdle and I don't foresee that changing (something's got to pay the FLEX Engineers bills day in day out).

I think it's positive and gutsy approach by Adobe, but at the same time I'm not sure whether the community carry it forward, as they're busy still learning the individual pieces (getting better daily) but this is a long term investment and when I read posts from Adobe staffers like "Sho" where they say the word "hope" - I get nervous. I also think the community have done enough already, so I'm not subscribing to the approach of slapping a post-it note on the side of FLEX and say "DIY GUI, you do better". (I've been wrong before so no guarantee's I'm right on this one)

I see both positive and negative pieces to this story, and the real pressure will be on Adobe in terms of steering the project in a direction that's universal. I think one person today said "Once you open source a project, there is no undo".

In the spirit of MIX07 Vegas, Adobe are essentially "Letting it ride, double or nothing"... (Which is just super for a few friends of mine in cubicles right now hoping to hell Flex risk they took pays off).

Zinc vs Apollo.

scbarnes — Wed, 25 Apr 2007 07:16:31 GMT

Jaspal Sohal (CEO) Multidmedia, a company whom own the software "Zinc" has made some official comments on where they sit against Apollo.

We can't be certain at this point on which of the two are better, as Apollo is still in alpha. Yet, if the race were to be called tomorrow, I must admit I'd go with Zinc simple for its features and maturity. I've used Zinc for years when it had it's former name, so I'm also probably biased.

You make your own decision though (personally Peps vs Coke argument mostly)

Apollo is a cross-OS runtime that allows developers to leverage their existing web development skills (Flash, Flex, HTML, Ajax) to build and deploy desktop RIA’s."

Within the Flash Community, this has naturally raised questions about the impact Apollo will have on Zinc. Well, the answer to this question is actually in Adobe's own description of Apollo. Many designers and developers have been under the impression (and many still are!) that Apollo is a "SWF2EXE" tool which creates standalone Projector files in the same way that Zinc does. This is not true.

[ Continue Reading ]

Thanks Silverlight, you just validated RIA (Wrong, here's why)

scbarnes — Sun, 22 Apr 2007 06:06:15 GMT

In 2002 one of the guys ( Jeremy Allaire) whom I owe my house & lifestyle to, came up with an idea that Rich Internet Applications (RIA) should exist in a certain way, with a certain direction going forward. I trusted his idea, as the last one was Coldfusion and it paid off for me so I went with it (had been using Flash prior to this so figured it wouldn't hurt).

Redsquares were evil.
I spent enormous amounts of time trying to either extend Flash's V1 Framework to suite my own needs or beat it with a version of my own framework. I was vocal about it, saying how hard and annoying it was and had zero love for "mix-in" approach (Decorator pattern to all you design pattern folks). I ended up supporting ghostwire.com's components as they were more mature and decided to build on from them.

The running joke in my cubicle in these days was "Barnesy, you going to upgrade to a blue circle" as for weeks on end, I'd have a Redsquares on my screen which represented a placeholder for code.

Point, I wanted RIA to succeed like the next guy, but it meant time and energy to build it.

Royale with Cheese please.
Around 2003. I remember reading up on DENG, this idea that Claus had where you could use Flash to read XHTML pages and it would render accordingly (as Flash had most of the primitives in place). I thought this was awesome as from there you could extend upwards and take a normal web page to the next level, so it was kind of like having a runtime within a runtime.

I decided to have a go at using this concept by reading in XML that would produce runtime applications that talked to Coldfusion. I posted about it on Macrofun.pvpers.com a blog I ran at the time. Libby Freligh (Former Product Manager for Flex) contacted me offline and asked if I would be interested in seeing this project Macromedia was working on, called Royale.

They showed me FLEX and I was hooked. I loved it's concept and it was 10 times more mature then anything I could ever come up with and so I built a career from there on out around it. I wanted RIA as badly as Jeremy had painted it.

Price is what killed RIA.
I got a call one day, it was missed one at that. I remember hearing the message "Scott, we are about to release the price tag and I know you don't like it, but could you not blog about it for a while" (as inside the GMC List for FLEX, we were told ahead of time and I was vocal about it). My blog at this time, Mossyblog.com was one of the first generation of Flex related blogs outside Macromedia and so I guess they thought folks would read and get spooked.

I hated the price tag, but I felt I owed Macromedia for letting me in on the Alpha, Beta and RC stages, so I complied. I also thought if more people use it, then it has to be a good thing for me right?

Wrong, the uptake was painfully slow, for weeks on end I'd get no love in the FLEX space and went back to coding Coldfusion 80% of the time.

People wanted FLEX SWF's outside the server but were told in order to use FLEX you must house the product on the server itself. Yet everyone whom knew FLEX agreed that the server was taking up valuable CPU and caught on that it was due to price tag that kept the reason for it's existence in place.

They got greedy.

Flex 2.0 came out and it was free.
Finally FLEX was given back to the people, the RIA movement in 2002 would move on and I even wrote an article for MX Developers Journal celebrating this. I thought, this is what we need, the RIA concept will take the world by storm and life would be good.

Adobe acquires Macromedia was the headline in blogs and I got nervous about all of this at the same time. I didn't know what was going on with Flash anymore and so I waited patiently. In doing this, A friend told me about Microsoft's movements have gotten mature, I had already known about XAML but didn't realize how mature it had become until around this time.

I was thinking "why would they want to enter the RIA space" as these guys aren't built for this kind of thing, design is foreign to them.

Can't beat them, join them.
I began to learn more about Microsoft, how Windows Form Development was easy to use and so on. These guys had their act together and once you got past the whole "Microsoft is evil" campaigns, you start to uncover that Microsoft has a valid offering here. If only they would use the technology in smarter ways. I caught onto WPF in its early form, and later WPF/e (Silverlight) and I started to see a picture immerge.

Late last year, I saw a job advert ("Developer Evangelist") and I actually thought it was Adobe, so I figured hell yeah, why not. I got a phone call it was Microsoft, and I was shocked. I made the interviews and got the job and was sent to Seattle for chip implants.

I arrived and was shown around the product stacks, meet some of the brainstrust behind WPF and Silverlight, and was amazed at the level of thinking they have around the products. They got it, it's not about runtime it's about experience, going beyond the browser and doing so in as many ways as possible that reflect the developers themselves.

Good Experience (HTML/CSS/AJAX), Great Experience(Silverlight), Ultimate Experiences(WPF).
These are the three tiers of emerging technology coming out of Microsoft and they are going to offer developers three channels of distribution. It's not about Flash being a killed, it's about offerings.

Did Microsoft come to the table late? or is Adobe just not equipped to handle Jeremy's theory? Are we competing? or did Microsoft just grow impatient with all this RIA development happening at snails pace? I don't think it's an evil plot, I just think it's Microsoft catching onto the simple fact that DHTML (AJAX) development still to this day happens in a wide variety of solutions. In order to help these web applications go beyond the browser were possible, they came up with the above three tiers of execution.

Adobe will do their thing and they will eventually do it well, much better than what they are doing today. I hope LiveCycle doesn't end up being the new price tag killer for the FLEX 3.0 equation and I'm seeing signs of this in Apollo (hence why I'm so vocal about it). I look back on the first days of RIA, FLEX & so on and ponder as to where we would all be if Flex 1.0 was given away and was integrated with Flash Professional instead of going after Enterprise aggressively as they did.

Microsoft are getting back to basics, empowering developers & designers to talk with one another through languages like XAML. Make no mistake, this isn't about validating Adobe, it's about focusing on the user experience.

I've been doing RIA both pre-2002 and post-2002, Jeremy put the ideas to words but i'd love an update to this RIA paper though.

2004 FLEX 1.0 compared to 2007 FLEX 2.0.1 you be the judge.

scbarnes — Sat, 21 Apr 2007 06:45:34 GMT

Note: This is Scott Barnes, talking clocked off the Microsoft pay roll (weekend now) and in talking about my hobby development in Adobe Flex (yes I do still use it and mentor other Flex Developers with my experience in it - so can we suspend the Microsoft is evil thing heh).

I was discussing earlier today Flex 2.0.1 questions and where I think the future of Adobe would head towards and why I think at times, they have a really fantastic product range but get caught up in Price issues.

At any rate, I went through some archives of my previous blog (www.mossyblog.com) and remembered in 2004 I did a rant on why "FLEX Hurts", here's the thing - it's still kind of true today (price is cheaper in some parts, but pieces are still here today).

This isn't a "anti-Adobe" post, it's more of a reflection on where we have come from, in order to know where we are going and if you read the posts and you're sitting back going "Yeah, that's still here today" then I'd recommend you do something about it and voice your opinion, as it's now 2007.

FLEX :: Part 5 - HALO, SKINS, WHAT THE…

FLEX :: Part 4 - Usability problems, a thing of the past.

FLEX :: Part 3 - Language no longer a barrier.

FLEX :: Part 2 - Rapid Development!

FLEX :: Part 1 - The hidden costs!

I compare my experiences from FLEX 1.0 days to now and I have to admit, there is still some existing ones around while others are fixed (yay!)