In the process of upgrading a Flex application at work, I've come across a particuliar issue regarding how the PopUpManager works in AIR. In a Flex application you are likely to have code that looks like this:
var win:MyView = PopUpManager.createPopUp( this, MyView , true ) as MyView;
PopUpManager.centerPopUp( win );
win.dataProvider = someData;
The code above creates an instance of MyView (which extends TitleWindow) and displays it as a model window and finally passes it some data so that the user can complete a task. The code above will work in an AIR application in the main application window, but not in subsequent NativeWindows!
So if your AIR application creates a new window (an instance of Window or NativeWindow) and within that window you run the code above, you will see nothing. So you will start wondering where is the instance of MyView? Is it off the screen somewhere? Who knows where it is, you can't see it and your users won't either. It simply doesn't work.
I searched the Flex bug base and did find a bug about this: SDK-12565. Basically it says that the windowing system is not integrated into the PopUpManager and that it should be. So custom controls like the CompletionInput control which I've used for a long time don't work inside NativeWindow instances. So If this issue affects you in any way and want it corrected sooner rather than later, then vote for bug SDK-12565.
2008-06-09
UEFA.com uses Flex for MatchDay interface
Being a soccer fan, I am currently following the Euro 2008 tournament that started this past weekend. So today because I was at work, I followed the two games on the UEFA.com website and to my surprise, they are using Flex for their MatchDay interface! That's very cool and shows once again that Flex is being used world wide. Gone are the page refreshes, the UI now auto-updates itself with the latest data on the game and the main view displays the field showing where the latest action occured as described in the match ticker. So if you are a soccer fan, definitly worth a look.
I am anxious for the first game by Greece tomorrow, I'm hoping for a positive result! Go Greece!
I am anxious for the first game by Greece tomorrow, I'm hoping for a positive result! Go Greece!
2008-06-05
Flex easy to learn for Java developers
Since the first release of Flex back in 2004 the main target audience has been Java developers. And this continues to be true even today, especially when you consider the server-side compliments of BlazeDS and LiveCycle Data Services are both Java based solutions. And this is also easily apparent in the real-world and I see it first hand everyday at my company, where everything we built is in Flex and Java.
One of the guys I work with the most, Jade, has developed Java Applets in the past and he picked up Flex very easily, to the point where he is using it for his own personal home projects. Another good example is our architect, who worked with me recently on a brand new project. I let him do a portion of the Flex UI and at one point he even went as far to create a new validator component that received the error messages from the server-side. Like I said, its easy to pick up :) One last example, I upgraded one project from Flex 2 to 3 with another fellow developer at his request, so that he could some of the new APIs that deal with Bitmaps objects.
The similarities between the two languages is uncanny and that really helps bring people over. Thus we use the best technology for creating UIs - Flex - and continue to use Java on the server-side to implement the business logic. It's the best of both worlds.
To get into more details, read my Flex/Java article on the Developer Center.
One of the guys I work with the most, Jade, has developed Java Applets in the past and he picked up Flex very easily, to the point where he is using it for his own personal home projects. Another good example is our architect, who worked with me recently on a brand new project. I let him do a portion of the Flex UI and at one point he even went as far to create a new validator component that received the error messages from the server-side. Like I said, its easy to pick up :) One last example, I upgraded one project from Flex 2 to 3 with another fellow developer at his request, so that he could some of the new APIs that deal with Bitmaps objects.
The similarities between the two languages is uncanny and that really helps bring people over. Thus we use the best technology for creating UIs - Flex - and continue to use Java on the server-side to implement the business logic. It's the best of both worlds.
To get into more details, read my Flex/Java article on the Developer Center.
Always find out the "real question"
Our job as software developers is not only to code, but more importantly to solve problems. Many times we get people who come to ask us to add feature A or B to an application to make it more productive, which is reasonable. There are other times however when we must dig a little further when someone is asking for a new feature, to really know if it is the right solution. My favorite way of doing this is by responding to their question by saying "What is your real question?". Don't just settle for "can you add this other button", or "can you make this faster", but figure out what the end-user is really doing, what he/she is looking to accomplish, what daily task needs to be completed. Because the feature they are asking for, might in fact not be the real solution to their problem.
Best example of this came a couple weeks ago when someone ask me to improve the performance of a report system. Upon learning the details I saw that what the user was doing was running queries the report engine wasn't build for. And upon further questioning, I figured out that all they needed was to enter a record identifier to retrieve all associated records and display them in a grid. Now doing that, is must simpler and faster than trying to re-write a reporting engine to deal with a specific use case.
So remember, don't just do what people say, ask questions, find out what the real need is, what the end goal is and if needed, go sit next to the end user and observer for while, you will be enlightened.
Best example of this came a couple weeks ago when someone ask me to improve the performance of a report system. Upon learning the details I saw that what the user was doing was running queries the report engine wasn't build for. And upon further questioning, I figured out that all they needed was to enter a record identifier to retrieve all associated records and display them in a grid. Now doing that, is must simpler and faster than trying to re-write a reporting engine to deal with a specific use case.
So remember, don't just do what people say, ask questions, find out what the real need is, what the end goal is and if needed, go sit next to the end user and observer for while, you will be enlightened.
Subscribe to:
Posts (Atom)