Flex panel with Maximize, Restore capability

var addthis_pub = ‘prosenjit23′;

Recently I have been working with Adobe Flex 3 for a project of mine. Flex offers a lot of UI components out-of-the-box that can be used as is. One of them is the Panel control. The Panel is essentially a container to house other components like data grids, etc. Panels are useful when creating dashboard applications. Unfortunately Flex does not offer inbuilt maximize or restore functions on the Panel controls. Rather it is left to the developers to devise their own  mechanisms. Long story short, I had a need for it and Flex did not offer it. And so I started scouring the net for samples. There were loads of good ones but their implementations were much too complicated for my needs. Reluctantly I started working on my own prototype.

<pre style="text-align:justify;"><?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
	width="598" height="620">
	<mx:Script>
		<![CDATA[
			import mx.core.UIComponent;
			import mx.managers.SystemManager;
			import mx.controls.Alert;
			import mx.collections.ArrayCollection;
			import mx.managers.PopUpManager;
			import mx.containers.TitleWindow;
			import mx.core.IFlexDisplayObject;
			import mx.containers.Panel;

			// Button constants
			private static const _RESTORE_LABEL_:String = "Restore";
			private static const _MAXIMIZE_LABEL_:String = "Maximize";

			[Bindable]
			private var currWidth:int; // Stores the current width of the panel to be resized
			[Bindable]
			private var currHeight:int; // Stores the current height of the panel to be resized
			[Bindable]
			private var currTop:int; // Stores the current y coordinate of the panel to be resized
			[Bindable]
			private var currLeft:int; // Stores the current x coordinate of the panel to be resized
			[Bindable]
			private var isMaximized:Boolean = false; // Stores the current state of the panel as a boolean
			[Bindable]
			private var currIndex:int; // Stores the current index of the panel to be maximized

			/**
			 * This function orchestrates what method
			 * is called on the button click event depending on
			 * its label value.
			 */
			private function maxRestore(thePanel:Panel, minRestorBtn:Button):void
			{
				if(minRestorBtn.label == _RESTORE_LABEL_)
					restore(thePanel, minRestorBtn);
				else if(minRestorBtn.label == _MAXIMIZE_LABEL_)
					maximize(thePanel, minRestorBtn);
			}

			/**
			 * This method maximizes the specified panel to occupy the
			 * whole displayed screen area. This method can be tuned to
			 * occupy the area of its parent component rather than the parent
			 * application.
			 */
			private function maximize(thePanel:Panel, minRestorBtn:Button):void
			{
				if(!isMaximized)
				{
					// Save previous position info
					currWidth = thePanel.width;
					currHeight = thePanel.height;
					currTop = thePanel.y;
					currLeft = thePanel.x;
					currIndex = thePanel.parentApplication.getChildIndex(thePanel);

					// Set the maximized flag to true
					isMaximized = true;

					// Set current info
					thePanel.width=this.width;
					thePanel.height = this.height;
					thePanel.x = 0;
					thePanel.y = 0;

					var parentApp:UIComponent = thePanel.parentApplication as UIComponent;
					parentApp.removeChildAt(currIndex);
					parentApp.addChild(thePanel);

					// Set the button properties
					minRestorBtn.label = _RESTORE_LABEL_;
				}
			}

			/**
			 * This method restores the panel to its original location
			 * and size on the screen.
			 */
			private function restore(thePanel:Panel,minRestorBtn:Button):void
			{
				if(isMaximized)
				{
					var parentApp:UIComponent = thePanel.parentApplication as UIComponent;
					// Set the maximized flag to false
					isMaximized = false;

					// Set the button properties
					minRestorBtn.label = _MAXIMIZE_LABEL_;

					// Restore the original size and location information
					thePanel.width = currWidth;
					thePanel.height = currHeight;
					thePanel.x = currLeft;
					thePanel.y = currTop;

					// Now relocate the panel to its original position
					// in the child stack.
					parentApp.setChildIndex(thePanel,currIndex);
				}
			}
		]]>
	</mx:Script>

    <mx:Resize id="resize" /> <!-- This helps in the resize effect -->
    <mx:Move id="moveEffect" /> <!-- This helps in the move effect -->

	<mx:Panel id="upperPanel" x="47.5" y="35" width="500" height="142" layout="absolute"
		resizeEffect="{resize}"
		moveEffect="{moveEffect}" backgroundAlpha="1.0"
		borderAlpha="1.0" title="Top Panel">
		<mx:TextInput x="136" y="19"/>
		<mx:Button x="304" y="19" label="Button"/>
		<mx:ControlBar width="100%" alpha="1.0">
            <mx:Spacer width="100%" alpha="1.0"/>
            <mx:Button id="upperPanelMaxBtn" label="{_MAXIMIZE_LABEL_}" click="maxRestore(upperPanel, upperPanelMaxBtn)"/>
        </mx:ControlBar>
	</mx:Panel>
	<!-- This panel has the capability to maximize and restore -->
	<mx:Panel id="maxminPanel" name="maxminPanel" x="47.5" y="195" width="500" height="184"
		layout="absolute" resizeEffect="{resize}"
		moveEffect="{moveEffect}" backgroundAlpha="1.0"
		borderAlpha="1.0">
		 <mx:title>Middle Panel</mx:title>
		 <mx:DataGrid top="10" right="10" bottom="10" left="10">
		 	 <mx:columns>
		 	 	 <mx:DataGridColumn headerText="Column 1" dataField="col1"/>
		 	 	 <mx:DataGridColumn headerText="Column 2" dataField="col2"/>
		 	 	 <mx:DataGridColumn headerText="Column 3" dataField="col3"/>
		 	 </mx:columns>
		 </mx:DataGrid>
		 <mx:ControlBar width="100%" alpha="1.0">
            <mx:Spacer width="100%" alpha="1.0"/>
            <mx:Button id="maxminPanelMaxBtn" label="{_MAXIMIZE_LABEL_}" click="maxRestore(maxminPanel, maxminPanelMaxBtn)"/>
        </mx:ControlBar>
	</mx:Panel>
	<mx:Panel id="lowerPanel" x="47.5" y="403" width="500" height="197" layout="absolute"
		resizeEffect="{resize}"
		moveEffect="{moveEffect}" backgroundAlpha="1.0"
		borderAlpha="1.0" title="Bottom Panel">
		<mx:TextInput x="104" y="35"/>
		<mx:ControlBar width="100%" alpha="1.0">
            <mx:Spacer width="100%" alpha="1.0"/>
            <mx:Button id="lowerPanelMaxBtn" label="{_MAXIMIZE_LABEL_}" click="maxRestore(lowerPanel, lowerPanelMaxBtn)"/>
        </mx:ControlBar>
	</mx:Panel>
</mx:Application></pre>

This is, like I said, just a prototype. The MXML file contains a couple of methods that take in the Panel controls as parameters and work their magic. For production use, I would surely extend the Panel control to create a custom one and wire it up with the necessary behavior. I would have loved to upload my SWF file to this blog but unfortunately WordPress does not permit that (for some ridiculous reason).

The moment a UI library offers widgets like panels and windows it becomes quite obvious that people would want to have minimize, maximize, restore and resize capabilities on them (and no the resize and move effects do not help much since they do not manipulate the z-ordering of components).Unfortunately Adobe does not think it is necessary. Personally I think the guys at Adobe are being extremely lazy about this. Of course there is always an excuse of being busy doing bigger and better things. Well so much for making lives easier for developers.

var addthis_pub = ‘prosenjit23′;

JavaScript is the future of RIA

A few days back I had written an article about JavaScript being the future of RIA. Adobe Flex, Microsoft Silverlight, etc. are all nice and good to have. The fact of the matter is that a whopping percentage of people still prefer JavaScript when it comes to implementing RIA solutions. 

To corroborate this claim of mine, I had been running a poll for quite some time now. After having got around 550 odd votes I think the time is now right to publish the results. The winner by a far and clear margin is JavaScript. Flex comes second. Here is graphic showing the results:

With the release of the new breed of web browsers that run on-steroid JavaScript engines this dominance of JavaScript in the field of RIA is most likely to increase.

The data presented here is not sponsored by any camp or company. Its strictly a poll that I ran in my personal capacity.

JavaScript for RIA gets yet another boost from WebKit SquirrelFish

Rich internet applications or RIAs are becoming a defacto standard for web applications. The selling point of RIAs is to provide responsive web applications that behave more like desktop applications than traditional web apps. Initially JavaScript seemed to be the only option for creating RIAs but it suffered from certain maladies, most important ones being performance and cross-browser compatibility. Taking advantage of this, Adobe came up with Flex and more recently Microsoft offered Silverlight. Both these platforms took away a portion of developers who were working on providing RIA capabilities in brower based apps.

With the popularity of Flex and to a limited extent Silverlight, JavaScript seemed to be heading for certain death until recently. The announcement of TraceMonkey from Mozilla and the subsequent release of Google Chrome that incorporated a JavaScript virtual machine called V8, JavaScript seems poised to make a come back. Both TraceMonkey and V8 have put the JavaScript engines on steroids and the reported boosts in performance are impressive. TraceMonkey is slated to be released with Mozilla Firefox 3.1 but interested people can have a taste of it by using the v3.1alpha releases from Mozilla’s web site. Chrome has already drawn rave reviews with its fast performance and responsiveness of JavaScript apps.

The latest salvo in this war between JavaScript and other technologies comes from WebKit. WebKit forms the core of brilliant web browsers like Apple Safari, KDE Konqueror and Google Chrome. The programmers at WebKit recently announced their own improvements in the JavaScript engine called the SquirrelFish Extreme. This new engine is supposed to be more than twice as fast as its previous incarnation. Here’s a graphic to show the performance boost:

According certain other studies SquirrelFish is reported to have beaten Google’s V8 and Mozilla’s TraceMonkey on performance. Click here for that study.

So is SquirrelFish Extreme the fasted JavaScript engine yet? Well we would have to wait for some more data to decide that one. But one thing is for sure – JavaScript is here to stay.

With all this attributed importance to JavaScript by the major players, the indication is stronger than ever that RIA developers would switch over to JavaScript once its major problems are sorted out. The work that is being done seems to be concentrating on this very aspect. 

Is this the second coming of JavaScript based applications? Just wait and watch.

The future of RIA is JavaScript not Flex or Silverlight

With the advent of Web 2.0 a new concept became the most sought-after technology for web applications. Popularized by Google’s GMail, rich internet applications or RIA very quickly became the need of the hour. At the heart of RI applications was JavaScript, a scripting language for the web, that was in existence long before Google was even born. Google, with its GMail, demonstrated what could be achieved with JavaScript and thus paved the way for the next generation of web applications.

JavaScript had its own problems. The biggest of them was probably cross-browser compatibility. Led by Microsoft through its Internet Explorer web browser, JavaScript quickly became a victim of non-standard usage. Microsoft, in order to prove its dominance over Netscape, supplied browser objects and functions that could be used to generate ‘cool’ effects in a web page easily. These were never ratified by any standards bodies. Since Microsoft was dominant on the desktop and also bundled IE with its Windows operating system, the exponential growth of IE in popularity apparently vindicated their arrogant violation of established standards. Netscape died under Microsoft’s onslaught and so did the standards of JavaScript. Developers started writing applications that were IE specific. It was not uncommon to see applications labeled “Best viewed in Microsoft Internet Explorer”.

The arrival of Mozilla’s Firefox web browser changed all this. Users, plagued by IE’s numerous vulnerabilities and instability, adapted to Firefox. Firefox implemented a more standards compliant version of JavaScript. So developers started writing rich applications that used standards compliant JavaScript. Even then there was one more problem with JavaScript and that came to the forefront due to RIAs. This was performance. 

Some of the leading vendors saw an opportunity in this short coming of JavaScript. Notable amongst them is Adobe and more recently Microsoft. Adobe’s Flash technology was initially meant to serve the multimedia needs of web applications. Flash was great for animations and effects, for video and audio playback, for slide shows and image manipulations, but it was never meant for rich internet applications. So enter Adobe Flex, a technology based on Flash, but offering widgets and controls for business applications. Cross-browser compatibility was achieved but at the cost of an added Flash plug-in. Not to be undone by Adobe, Microsoft entered into the fray with its Silverlight software. Silverlight did all the cools things that Flash did and also needed a plug-in to run. It seemed like JavaScript was doomed.

Mozilla and Google had different plans. Mozilla’s Firefox 3.1 browser, still in testing, and Google’s recent Chrome web browser breathed a new life into JavaScript applications. In Google Chrome, Google introduced the V8 JavaScript virtual machine that offered significant performance boosts for existing applications. Mozilla has incorporated the new TraceMonkey JavaScript engine that has reportedly achieved performance boosts of up to 85%!!! With these two products JavaScript is surely set to make a come back.

As things stand, JavaScript has overcome its two worst adversaries – cross browser compatibility and performance. With the availability of brilliant libraries like Yahoo UI Toolkit, Dojo toolkit, etc. that help ease development of RIAs, JavaScript is here to stay and the way to go for future applications. For a JavaScript performance comparison study click here.

Of Flash, Silverlight, HTML and AJAX

With the advent of Rich Internet Applications(RIA), a plethora of new technologies have been developed and are now available. Choosing one amongst them is not an easy task. Each of these technologies have their own pros and cons. This article takes an objective look at the major ones.

HTML and AJAX

HTML has been around since the earliest days of the Internet. It basically is the language in which web pages had to be authored. It is simple to learn and easy to use. With tools like Adobe Dreamweaver, hand coding of HTML has become a thing of the past. However, by itself HTML often proves to be insufficient for more advanced needs. Most of these shortfalls can be surmounted by using JavaScript. A more recent occurrence is AJAX. Though it is not a new technology, but the way Google used it in its e-mail system brought it to the forefront and sparked off the RIA revolution. AJAX takes advantage of certain browser objects to communicate with back end systems in an asynchronous manner. The advantage is that existing knowledge of JavaScript and HTML is enough to get working with AJAX. A lot of libraries like the Yahoo Toolkit, Dojo Toolkit, GWT, DWR, etc. are now available that make life much easier to use AJAX. In the JEE arena, RichFaces, ICEFaces, etc also help to implement AJAX behavior to existing and new enterprise applications.

The most irritating problem with HTML and JavaScript was the different ways in which the same markup looked and behaved on different browsers. Ever since the browser wars these differences have become lesser and lesser and browser functionality has seen a convergence. With the W3C maintaining a standard for these technologies, things look brighter.

HTML and JavaScript have been around for some time now and have been tested thoroughly. Add to this the ready availability of resources skilled on these and they still seem to be the best bet for new applications.

Adobe Flash

Adobe Flash started off its life as a way of enabling rich media content on web pages. This it delivered very well. Flash is very capable in handling video, audio and other types of contents withing a web page. In relatively recent times, Adobe released Flex – an RIA platform based on Flash technology that is intended for developing enterprise applications. I have had the fortune of working with this technology and I have to admit there is a learning curve.

Flex is a lot different to work with when compared to HTML and JavaScript. ActionScript is a full blown object oriented language unlike JavaScript and takes some time getting used to. Flex is also a stateful platform. This has both its benefits and demerits. However there are certain things that, in my opinion, people should consider before opting for Flex.

First, do you really need Flex? Flex applications compile to .SWF files that are downloaded on the client computer during the first request. For a complex application, these files can be of reasonable size and loading times can increase.

Second, Flex apps are ultimately Flash applications and are dependent on the Flash plug-ins in the browser. So even though, browser dependency is made redundant, the various versions of the the plug-in can still create problems. For instance if a Flex application is targeted for version 7 of the Flash plug-in, it may produce some nasty surprises when running on version 9. Even though upgrading the Flash plug-in is relatively a painless task, downgrading it, if at all possible, is going to be more of a challenge.

Third, are there enough skilled resources available to sustain maintenance of Flex applications? This is a very serious question that needs to be considered. Enterprise applications typically go through multiple releases and have quite a long lifetime. During this period the application has to be maintained and new functions have to be added to it. Is there a sufficient pool of developers available today to do so? If not, will we have sufficient pool of developers in the future? No one can tell.

Fourth, Flex is a proprietary product that runs on a proprietary plug-in from Adobe. So there is always a chance of vendor lock-in.

Microsoft Silverlight

This is the newest kid on the block and Microsoft touts it to be a Flash killer. Was this really necessary? I mean what is it that Flash does so badly that it needs to be killed for? To me it seems yet another attempt by Microsoft to dominate a certain segment. Flash is quite dominant in the streaming media industry and Microsoft does not like it. It wants to own this monopoly and that is why Silverlight. So instead of Adobe its going to be Microsoft. Either way a company is going to have a monopoly. So what difference does it make to us users? Nothing really.

Everything said, HTML stills seems to be the more prudent choice amongst the technologies mentioned above. It has a standard, delivers it promise and can be made to accomplish more by using AJAX or one of the AJAX libraries.