I've been pretty busy lately. Last weekend we released the result of all this hard work: www.geniografico.com. I'd love to get your feedback and I hope you want to help me spread the news!
Monday, June 8, 2009
Monday, February 23, 2009
Auto-sizing the height of a TileList
Would you like the TileList component to auto-size to its content? If you have a fixed width OR height you could use the following hack (the example is based on a fixed width of 4 columns):
<mx:TileList
id="tl"
columnWidth="160"
rowHeight="160"
columnCount="4"
verticalScrollPolicy="off"
horizontalScrollPolicy="off"
updateComplete="upd()"
dataProvider="{xx}">
private function upd(): void
{
var rc: int = Math.ceil(xx.length / tl.columnCount);
if (tl.rowCount!=rc) tl.rowCount = rc;
}
It's important to turn of the scroll policy to prevent the vertical scrollbar from appearing and disappearing.
<mx:TileList
id="tl"
columnWidth="160"
rowHeight="160"
columnCount="4"
verticalScrollPolicy="off"
horizontalScrollPolicy="off"
updateComplete="upd()"
dataProvider="{xx}">
private function upd(): void
{
var rc: int = Math.ceil(xx.length / tl.columnCount);
if (tl.rowCount!=rc) tl.rowCount = rc;
}
It's important to turn of the scroll policy to prevent the vertical scrollbar from appearing and disappearing.
Monday, January 26, 2009
Dynamic objects and the Flex profiler
In certain situations it can be handy to use dynamic objects. The advantage of dynamic objects is that you can add properties at runtime (something you can't do in Java or C#). Dynamic objects are slower than 'normal' objects but there's another problem: if it's an object of type 'Object' (for example because you wrote { id: 123 } to create a dynamic object on the fly) it doesn't show up in the profiler and therefore it's hard to track the memory used by these objects. Therefore I'd recommend to declare specific dynamic classes in bigger applications. This way you cannot only track their memory usage in the profiler but you also know which type of content is in your dynamic objects (and therefore which dynamic content is eating up your memory).
package
{
public dynamic class CustomerObject
{
}
}
Before people start flaming: this post is not a recommendation to use dynamic objects because in most cases it's better not to use dynamic objects in the first place!
package
{
public dynamic class CustomerObject
{
}
}
Before people start flaming: this post is not a recommendation to use dynamic objects because in most cases it's better not to use dynamic objects in the first place!
Wednesday, January 21, 2009
Adobe Flex - Silverlight compiled size
I promised to provide some details on the compiled size of the application I built in Adobe Flex and Silverlight:
Flex application
Flex framework = 551 KB
Application = 279 KB
Total = 830 KB
Silverlight
XAP file = 994 KB
--> application DLL + AppManifest.xaml = 85 KB (compressed)
--> Silverlight framework = 348 KB (compressed)
--> Telerik controls used = 560 KB (compressed)
Some remarks:
The Telerik controls cause the Silverlight application to be bigger than the Flex application. I had to use them however given the bugs in the Silverlight combobox and popup controls.
The Flex framework makes a big part of the Flex application. It's however important to note that it can be cached cross domain and therefore doesn't need to be downloaded again after clearing the browser cache. In case of Silverlight each new deploy of the application requires the Silverlight framework as well as the 3rd party controls to be re-deployed.
Flex application
Flex framework = 551 KB
Application = 279 KB
Total = 830 KB
Silverlight
XAP file = 994 KB
--> application DLL + AppManifest.xaml = 85 KB (compressed)
--> Silverlight framework = 348 KB (compressed)
--> Telerik controls used = 560 KB (compressed)
Some remarks:
The Telerik controls cause the Silverlight application to be bigger than the Flex application. I had to use them however given the bugs in the Silverlight combobox and popup controls.
The Flex framework makes a big part of the Flex application. It's however important to note that it can be cached cross domain and therefore doesn't need to be downloaded again after clearing the browser cache. In case of Silverlight each new deploy of the application requires the Silverlight framework as well as the 3rd party controls to be re-deployed.
Tuesday, January 20, 2009
Size Matters (when comparing Adobe Flex and Silverlight)
I've been developing an administrative application the last couple of weeks. I actually developed it twice: the first version was done using Adobe Flex, the second version was done using Microsoft Silverlight.
Because Silverlight was new to me (I know, use and love .NET however for server side development) I couldn't compare development time. Therefore I decided to compare the size of a number of application files.
Some value object class
Adobe Flex: 19 lines
Microsoft Silverlight: 164 lines
Main reason for the difference: Adobe Flex has a [Bindable] attribute
Some data entry screen (without datagrid)
Adobe Flex: 61 lines of MXML + 25 lines of Actionscript
Microsoft Silverlight: 108 lines of XAML + 53 lines of C#
Main reasons for the difference: Form layouting and field validation is better in Adobe Flex
Some data entry screen (with datagrid)
Adobe Flex: 170 lines of MXML + 198 lines of Actionscript
Microsoft Silverlight: 261 lines of XAML + 315 lines of C#
Main reasons for the difference: Form layouting and binding is better in Adobe Flex
My conclusion: it takes 1.5 to 2 times more lines (and in reality therefore hours) to develop an application using Microsoft Silverlight compared to developing the same application using Adobe Flex.
Because Silverlight was new to me (I know, use and love .NET however for server side development) I couldn't compare development time. Therefore I decided to compare the size of a number of application files.
Some value object class
Adobe Flex: 19 lines
Microsoft Silverlight: 164 lines
Main reason for the difference: Adobe Flex has a [Bindable] attribute
Some data entry screen (without datagrid)
Adobe Flex: 61 lines of MXML + 25 lines of Actionscript
Microsoft Silverlight: 108 lines of XAML + 53 lines of C#
Main reasons for the difference: Form layouting and field validation is better in Adobe Flex
Some data entry screen (with datagrid)
Adobe Flex: 170 lines of MXML + 198 lines of Actionscript
Microsoft Silverlight: 261 lines of XAML + 315 lines of C#
Main reasons for the difference: Form layouting and binding is better in Adobe Flex
My conclusion: it takes 1.5 to 2 times more lines (and in reality therefore hours) to develop an application using Microsoft Silverlight compared to developing the same application using Adobe Flex.
Tuesday, December 23, 2008
Some objective comparison of Adobe Flex and Microsoft Silverlight
In the past I've read a number of posts comparing Silverlight to Flex. Often the authors remain very vague on why Flex is better than Silverlight. We all know by now that the Silverlight plug-in isn't near the installed base of the Flash player but there's more than that. Therefore I think it's about time to give an overview of my recent experience.
I've been developing a proof of concept application in Silverlight after having developed the exact same proof of concept application in Flex. Just to be clear: I have much more experience with Flex than Silverlight but I'm pretty sure that the information below is based on facts, not fud.
1. Binding - Both technologies support binding but binding in Silverlight is way more cumbersome. First of all you need a special hack (using StaticResource) to bind UI components together. Even worse is the fact that you need to dispatch property changed events yourself (in Flex you simply specify the [Bindable] attribute on class and/or property level). A direct binding to an expression is also not an option in Silverlight. The fact that there's 2 way binding in Silverlight is an advantage for Silverlight because the current version of Flex is limited to 1 way binding (the upcoming release of Flex has 2 way binding).
2. Data communications - In Silverlight you're more or less stuck with SOAP and JSON for the time being (you could consider using WebOrb or FluorineFx - this gives Silverlight AMF support).
3. Layouting - Thank God there's Flex. Need to layout a data entry form? In Flex you can use Form and FormItem. In Silverlight you need to use Grid, RowDefinition and ColumnDefinition. Not too bad if you didn't have to specify Column and Row IDs because what do you need to do when you need to insert a line in your form... right... renumber everything. There are also no 'right' and 'bottom' properties in Silverlight - pretty annoying.
4. Exception handling - This is a 'bad in both cases' topic. In Flex there's still no global exception handler. Silverlight has one but for some strange reason the screen goes blank after certain exceptions. In other words: there's global exception handler support in Silverlight but it doesn't work...
5. Code behind - To me it's not essential but the fact that there's no out of the box support for code behind in Flex is a pitty. The fact that there's no out of the box WYSIWYG design support in Visual Studio 2008 is probably much more problematic for developers starting with Silverlight (or do you really expect them to constantly switch between slow blend and quick visual studio???).
6. Multi-language - I haven't completely figured out the multi-language support in Silverlight but it's already clear to me that it's way easier to implement in Flex. Just to be clear: the internationalization in Flex is also far from perfect. You need to take care of date formats, decimal and thousands separator support yourself because there's no application global setting in Flex (which is problematic when using validators and binding).
7. Validation - although not perfect in Flex (do they really think all telephone numbers are formatted the US way...), the support in Silverlight is simply absent. You will need to develop validators and the nice red "error tips" yourself.
8. Generics and LINQ - currently there's no support for generics in Flex (actually Actionscript).
What's even worse: there's no LINQ (or something similar) in Actionscript. Silverlight comes with LINQ and that is definitely an advantage (you can't use it for database querying however). Support for partial classes and extension methods is another advantage of Silverlight over Flex. It's clear that we're in need of Actionscript 4 (even if that results in non-compliance with Ecmascript).
9. Components - The Silverlight component set is smaller than the Flex component set (eg. a menu bar component is missing). This might change quicky however. There are already more 3rd party component development companies working on Silverlight controls than companies working on Flex controls.
10. Browser compatibility - Although there are some issues with Flash player running in Google Chrome - the situation is much better compared to Silverlight. That one just doesn't work in Google Chrome.
I'll probably discover more differences during the coming weeks. If so I'll post a new overview over here.
I've been developing a proof of concept application in Silverlight after having developed the exact same proof of concept application in Flex. Just to be clear: I have much more experience with Flex than Silverlight but I'm pretty sure that the information below is based on facts, not fud.
1. Binding - Both technologies support binding but binding in Silverlight is way more cumbersome. First of all you need a special hack (using StaticResource) to bind UI components together. Even worse is the fact that you need to dispatch property changed events yourself (in Flex you simply specify the [Bindable] attribute on class and/or property level). A direct binding to an expression is also not an option in Silverlight. The fact that there's 2 way binding in Silverlight is an advantage for Silverlight because the current version of Flex is limited to 1 way binding (the upcoming release of Flex has 2 way binding).
2. Data communications - In Silverlight you're more or less stuck with SOAP and JSON for the time being (you could consider using WebOrb or FluorineFx - this gives Silverlight AMF support).
3. Layouting - Thank God there's Flex. Need to layout a data entry form? In Flex you can use Form and FormItem. In Silverlight you need to use Grid, RowDefinition and ColumnDefinition. Not too bad if you didn't have to specify Column and Row IDs because what do you need to do when you need to insert a line in your form... right... renumber everything. There are also no 'right' and 'bottom' properties in Silverlight - pretty annoying.
4. Exception handling - This is a 'bad in both cases' topic. In Flex there's still no global exception handler. Silverlight has one but for some strange reason the screen goes blank after certain exceptions. In other words: there's global exception handler support in Silverlight but it doesn't work...
5. Code behind - To me it's not essential but the fact that there's no out of the box support for code behind in Flex is a pitty. The fact that there's no out of the box WYSIWYG design support in Visual Studio 2008 is probably much more problematic for developers starting with Silverlight (or do you really expect them to constantly switch between slow blend and quick visual studio???).
6. Multi-language - I haven't completely figured out the multi-language support in Silverlight but it's already clear to me that it's way easier to implement in Flex. Just to be clear: the internationalization in Flex is also far from perfect. You need to take care of date formats, decimal and thousands separator support yourself because there's no application global setting in Flex (which is problematic when using validators and binding).
7. Validation - although not perfect in Flex (do they really think all telephone numbers are formatted the US way...), the support in Silverlight is simply absent. You will need to develop validators and the nice red "error tips" yourself.
8. Generics and LINQ - currently there's no support for generics in Flex (actually Actionscript).
What's even worse: there's no LINQ (or something similar) in Actionscript. Silverlight comes with LINQ and that is definitely an advantage (you can't use it for database querying however). Support for partial classes and extension methods is another advantage of Silverlight over Flex. It's clear that we're in need of Actionscript 4 (even if that results in non-compliance with Ecmascript).
9. Components - The Silverlight component set is smaller than the Flex component set (eg. a menu bar component is missing). This might change quicky however. There are already more 3rd party component development companies working on Silverlight controls than companies working on Flex controls.
10. Browser compatibility - Although there are some issues with Flash player running in Google Chrome - the situation is much better compared to Silverlight. That one just doesn't work in Google Chrome.
I'll probably discover more differences during the coming weeks. If so I'll post a new overview over here.
Sunday, December 14, 2008
Flip book using the nice component built by Ruben Swieringa
I've created a mini-site for a family member using the flip book component built by Ruben Swieringa:
http://klepsydra.vdeprojects.com.
What do you think? Would it make sense to build a Flex-based CMS solution for creating this type of projects? Do you think there's a demand for a CMS to build this type of mini-sites?
http://klepsydra.vdeprojects.com.
What do you think? Would it make sense to build a Flex-based CMS solution for creating this type of projects? Do you think there's a demand for a CMS to build this type of mini-sites?
Subscribe to:
Posts (Atom)
