There is an excellent review about Mogulus at the following link http://www.masternewmedia.org/video_internet_tv/live-video/broadcast-live-tv-online-with-mogulus-20070521.htm
Posted by flexrays on May 22, 2007
There is an excellent review about Mogulus at the following link http://www.masternewmedia.org/video_internet_tv/live-video/broadcast-live-tv-online-with-mogulus-20070521.htm
Posted in Uncategorized | 1 Comment »
Posted by flexrays on May 16, 2007
Why loading at runtime?
By loading style sheets at run time, you can load images (for graphical skins), fonts, type and class selectors, and programmatic skins into your Flex application without embedding them at compile time. This lets skins and fonts be partitioned into separate SWF files, away from the main application. As a result, the application’s SWF file size is smaller, which reduces the initial download time. However, the first time a run-time style sheet is used, it takes longer for the styles and skins to be applied because Flex must download the necessary CSS-based SWF file.
Three steps process to runtime CSS Style Sheets loading
Insert the below code into the <mx:Application/> tag
initialize = “StyleManager.loadStyleDeclarations( ’style1CSS.swf’ )“
<mx:Application
xmlns:mx=”http://www.adobe.com/2006/mxml”
layout=”absolute”
initialize=”StyleManager.loadStyleDeclarations( ’style1CSS.swf’ )”
viewSourceURL=”srcview/index.html”>
Let me know if you have any clarification.
Posted in SkinAndStyle | 6 Comments »
Posted by flexrays on May 16, 2007
Hello All,
I found the contents of the attached file – stylingandskinning.pdf – very useful source for those who wants to start learning about Styles and Skins. This file is by Andrew Trice, Cynergy System.
Posted in SkinAndStyle | Leave a Comment »
Posted by flexrays on May 4, 2007
This is taken from Peter Ent’s blog http://weblogs.macromedia.com/pent/
Thanks to Peter Ent. All the blogs posted here are for my reference. Other’s are welcome to read it. Happy Reading
I get a number of questions from people with large Flex applications that have run into a problem. For example, someone might have a TabNavigator and sometimes one of the tabs doesn’t show up or a tab remains even if the child component has been removed.
Isolating the problem can be difficult because the Flex application is large and requires data from a server or some other resource that makes it nearly impossible to send to us in Flex Product Support.
If you are involved in a large-scale development project (or think you will be), then STOP. Don’t go any further. I’ve got some advice.
There are a number of books and papers about software development and they have fancy names like the waterfall method, or simply unit testing. These are good, sound, tested techniques that might at first appear to be so much academic fluff, but there is a reason people went to the trouble of creating these design and development patterns.
I’m not going to write another book on the subject, but rather distill them into something I hope makes sense and is easy enough for you to implement. This is how I work on a problem.
The first step is research. That is, figuring out how something is going to work before incorporating it into the application. For example, suppose I think I’ll want to use a Move effect. I’ll write a separate application to explore how the Move effect works. I’ll try out its options and may be I’ll discover that it doesn’t work as I thought it did. Or may be I’ll discover that what I really want is a Move + Zoom effect and then I’ll figure out how to use Sequence or Parallel effects. The point is, I look at the application and think about the parts that I’m unsure of. I may not know if a DataGrid with 30 columns will perform well or even been easy for the end-user to use. It is this exploration of the possibilities that can give you a better feel for how Flex works and really build up your skill set.
The second step is organization. I try to think of the parts of an application as coming from 3rd party vendors. If I need a DataGrid with special features I think about it as if I could buy it from someone. This is also known as the black box approach. In other words, I don’t want any other part of the application to be able to muck with the insides of my special DataGrid. Nor do I want my special DataGrid to know anything about the rest of the application. Thinking about it this way isolates each major part and leads to the next step.
Hint: This is where custom events come into play. A custom event helps you identify what action is happening that relates to the new component classes. A custom event can be as simple as a new event type (eg, “inventoryUpdate”) or it can contain additional information (eg, the part number and name of the item being updated). Each component or group of components should have their own custom event(s).
The third step is interfaces. This is how parts mesh or fit together. It involves how one black box component interacts with another one. Obviously there are parts of a component that have to be publically exposed. Think about the Flex componets. The DataGrid does not know a thing about your application. All you can do is interact with its public functions, properties, events, and styles. If you discover that the DataGrid does not do something you want, you can create your own class, extending DataGrid and add those features. But you should create your class with the same intention – expose just those public functions and properties that get the job done.
Hint: Using actual ActionScript interfaces can really help keep parts of the application isolated. An interface provides the contract between a component and its users, but it also allows the component developer to change how the component works (or to fix bugs) without adversely affecting the rest of the application.
The last step is testing. That is, testing each of these units. Write stand-alone applications to try your components out separately and in logical combinations as they might be used in your larger application. You may discover flaws, shortcomings, or eliminate unnecessary features at this stage. If you’ve done the research step, then you’ll already have most of the testing code in place.
Hint: If in the testing phase you run into a problem you cannot solve, you have a self-contained example that you can send to someone for help.
The benefit to this approach is that you have a much more reliable application. Plus you may have created reusable components for a future application.
Further, should you need the services of the Flex Support Team, you’ll have ready-made test cases that you can send to us so we can quickly help resolve the problem.
Posted in Flex | 1 Comment »