Do you also think that Adobe Flex lacks a component library update? Yes, I know Spark is around the corner but after more than 2 years I'm not looking for less, I really need more. New components, new functionality within the existing components.
As far as I'm concerned Adobe doesn't have to come up with these components itself. Third party components with a decent licensing scheme (comparable to the 3rd party components available for Silverlight) would be perfect. Apart from ILOG Elixir (that comes with problematic licensing options) there's hardly anything out there. Even Dough Mcune with his fantastic Flexlib library seems to have given up.
But @ Adobe nobody seems to care, at least not in a positive way. Otherwise they wouldn't attack Flashden, probably the biggest Flash marketplace out there.
So Adobians, please tell me today instead of tomorrow if you're not serious about your own development products anymore! I start wondering whether you are being paid by Microsoft to let Flex die silently...
Monday, October 26, 2009
Wednesday, August 26, 2009
FP-444 and other neglected Adobe Flex jira bug/feature posts
Did you also read the recent blog post by Ted Patrick that resulted in lots of comments on the fact that nothing seems to happen with most of the Adobe Flex related bug/feature posts? The most notable throughout all the comments was FP-444 (possibility to catch global exceptions - let alone that the Flash Player starts ignoring events after such an exception...). It's open for years and a lot of Adobe Flexers really want this functionality. Do you think in the mean time someone at Adobe took 10 minutes to add a comment to this bug to explain the status of it? No. Does this leave a good impression with prospects? No. Do you think big customers trust such a supplier? No. Will Adobe eventually do something about the near stand still of these bug postings? I hope an Adobian finds 10 minutes to write a positive comment on this blog post in order to give confidence to the community that they choose the right RIA platform...
Monday, June 8, 2009
Launch of Geniográfico.com
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, 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.
Subscribe to:
Posts (Atom)