fbpx

Made in USA: Enterprise Application Services

webkit Archives - Ayoka - Made in USA Enterprise Application Services

Adobe Flex Custom Item Renderers vs WebKit HTML Renderer

July 16, 2009
|
0 Comments
|

Adobe Flex user interface controls provide a great deal of power for creating beautiful UIs. Of these controls, the DataGrid control can be used to display a formatted table of data. Most often we would want to display images or something other than just plain text; to do this requires the use of custom item renderers.

Item renderers are not mapped to the dataprovider in a one-to-one fashion, meaning that they can be used to display different kinds of data from the dataprovider. Although this might be a simple and impressive way to display data, you might run into performance and memory issues if used inappropriately. The choice of when to use custom item renderers depends on the size of your data, i.e., the number of items that are going to be displayed.

Memory profiling can be used to check the amount of memory that is being used to display the dataset. You will probably notice a sharp rise in memory usage when more widgets are used to encapsulate an item or when the number of items being rendered is large. This is because when the renderer is updated the components might still be holding reference to the old values from items that were being rendered before and as a result there might be more number of renderer objects that are created than that are seen visible at the current instance of time.

A better way would be to use the open source WebKit HTML renderer included in Adobe AIR runtime environment. The AIR HTMLLoader class, wrapped in mx:HTML component, provides methods and events for controlling how the content is loaded and rendered. The mx:HTML component can be used with other Flex containers to render items. The component also provides a way to use JavaScript to carry out event driven operations. The code sample below shows how ActionScript and Javascript objects listen for events dispatched by both AIR and JavaScript objects.

Code sample:
Adobe Flex Custom Renders vs Webkit HTML Renderer

The above code renders a collection of image files as thumbnail views and displays the image file path when a double click event occurs on any of the images.

How will a Microsoft opensource-based browser affect developers and consumers?

November 13, 2008
|
0 Comments
|

You may have heard the rumors going around that Microsoft is considering switching Internet Explorer’s rendering engine to WebKit, the opensource rendering engine used in Safari and Chrome, and wondered how this could affect us as developers and consumers of web applications. Regardless of whether or not this rumor has any basis, Microsoft has certainly changed its attitude quite a bit with respect to software development and open source.

Microsoft is reacting much more quickly to emerging web standards, doing things like supporting cloud-friendly licenses for its operating systems and server software, as well as creating a roadmap for its own cloud computing platform, Azure. It’s also becoming more involved in the open source community, to the extent that the latest versions of ASP.NET will standardize on jQuery for advanced scripting instead of developing their own propietary JavaScript framework.

For developers, switching to Webkit means that there are two main rendering engines to contend with, the other being Mozilla’s Firefox and both are open source projects. This gives us a lot of flexibility and options for creating third party APIs, just as Adobe has integrated WebKit into AIR and provided a whole new API for accessing that. This also could mean that client side Javascript may become more standardized, and the need for ugly code branching would be diminished. In summary, the issues we encounter on a daily basis including the following become much easier to deal with:

  • Rendering differences
  • Javascript incompatibility
  • Inconsistent event models
  • Browser-based testing

For consumers, this means that there is another major supporter for WebKit, which will continue to drive innovation as well as create competition so that Firefox, Opera, and others continue to evolve their browsers as well. Consumers also benefit from:

  • Faster and more robust Javascript engine
  • Less discrepencies between different browsers
  • Faster introduction of new features

So if this is a win-win situation for everyone what is stopping such a browser from being released by Microsoft? Well besides the business decisions involved, I’m pretty sure that the tight integration of IE with Windows and other Microsoft products will be a huge factor in how this can actually be implemented. It’s not easy to change such a critical part of a product’s technology without breaking things all over the place, even with extensive testing and development resources.