If you take a look at Adobe's developer site there is a lot of hype about Flex. Up until a few weeks ago I had no idea what Flex was or what it would do for me. Our current Web Viewer is written for Flash 7 in Actionscript 2. While not a good programming environment for a C style person like me, it gets the job done. This is where Flex comes in.

With the introduction of Actionscript 3, Adobe has created a true object orientated programing language. This makes some of the interesting things you can do work the way you would think. Actionscript 3 is part of Flash 9 and those of you that stick with writing Flash Applications will have the ability to use it, and its predefined libraries, with the introduction of Flash Professional 9.

But who wants to wait for that? If your willing to learn a new layout method you can take advantage of Actionscipt 3 now by using Flex. Flex replaces the need for a time line and graphical layout environment. Flex introduces a new MXML format for describing the layout of objects and their properties. This powerful ability is useless without a rich set of interface objects. With Flash you are stuck creating all of these objects yourself. Flex, on the other hand, defines just about anything that you find in a standard interface. Things like buttons, scroll bars, progress indicators, menus, etc. can be found in the Flex library. For a preview of what's available check out the Style Explorer over on Adobe's web site.

Using Flex to build applications is relatively quick once you get a handle on the new MXML format and familiarize yourself with the API. MXML's xml base makes it easy to add and modify the interface. Good Actionscript 3 integration makes it simple to add small code chunks to control interface items or complete classes for more complex operations. While young, Flex is positioned to be a great programing environment. Stay tuned for more information on setting up and using Flex.

Building interfaces with Interface Builder is straight forward and simple. Visual Objects like windows and views support a wide range of methods that are called when the user interacts with the interface. It's possible to easily monitor events like the mouse moving or being pressed. For most applications this is more than enough control to do most tasks. However it is sometimes necessary to do something different. The Mapwing software on the Mac can make it seem like all the windows are key. No matter what window is selected certain events are sent to the window the mouse is over. This is useful for making the mouse cursor change and allowing one click to activate a window and perform an action.

One of these behaviors is provided by the NSResponder class, which NSWindow and NSView are derived. Overloading the acceptsFirstResponder method and returning YES provides the behavior of clicking an object and making the window key at once. This allows the programer to decided when this behavior is appropriate, adding simple logic to control the return value allows you to turn this feature on and off at run time.

The other behavior, sending events to the window the mouse is over not the key window, is not supported by NSResponder or any other class. To gain this functionality it is necessary to intercept events as they enter the application and reroute them to the appropriate responder. Events enter Cocoa Applications through NSApplication. Events (mouse, keyboard, and control) are sent to the sendEvent: method. NSApplication's default implantation takes these events and depending on their type dispatches them to different receivers, normally the NSWindow object defined by the window property of the event. With a little poking around in NSEvent and the Foundation Functions we can come up with some code to figure out what window the mouse is over. It is then a simple task of changing the event to reflect this new window. You can then call the sendEvent: method of that window with the event or pass the modified event to super and let it take care of the dispatching. It is very important to take care when modifying how NSApplication's sendEvent: works. Some of the events that pass through it are important to the proper operation of your application. NSEvent defines many different types of events, it's best only to change events of the type you want to control. Messing with events that are of type NSAppKitDefined or NSSystemDefined can produce odd behaviors. While I have found it necessary to change the behavior of some of the sub types of these events extreme care must be taken. To do this modification it will be necessary to create a custom subclass of NSApplication if you haven't already. If you've never done this check out Apple's documentation about NSApplication they have some tips and warnings that may be helpful. While your looking at the documentation check out the other things that NSApplication controls it maybe helpful to you to change their behaviors also.

Hopefully this was helpful to you, if you have any questions about this or any other Cocoa programing topic feel free to ask.

After Steve Job's announced that Apple would be changing over to Intel CPUs many developers scrambled to figure out what they would need to weather this migration. Many users have no idea what this change even means for them, and rightfully most shouldn't need to worry about it. I'm going to give a little technical overview of the changes that are coming to the Mac. I'll then go over the steps that developers are taking to make this transition as seamless as possible. I hope that this will clear up some things for you.

First, this change is much different than going from a G3 to G4 or even a G5. These processors changes required modifications of the main logic board, but the processor architecture did not change. A processor's architecture describes how the processor interprets data and what operations it does (its instruction set). Since the mid 90's Apple has used PowerPC chips. This architecture is considered RISC (reduced instruction set computer). The idea behind a RISC is to have as few operations as possible and to make those operations execute very fast. In contrast the Intel CPU is x86 which is CISC (complete instruction set computer). CISC have instructions to do very complex operations. The penalty of this is that all instructions are slower. Immediately you might think that RISC is better, but this is not always the case. RISC processors have the downfall of being very difficult to program. The art of writing assembly programs seems pointless to most programers, and for the most part they are correct. But at some level all programs become compiled into assembly. This compiling step is currently much better for the x86 processor and very efficient code can be created from higher level languages with little trouble. This isn't to say that the same program couldn't be done better for a RISC computer, it would just take more work. One reason for this is the popularity of the x86 architecture, which has been used on common desktops for the past 20 years. This has also caused the x86 processors to become very optimized resulting in extreme performance. These optimizations make up for any speed loss the Intel chips suffer from their architecture.

At this point most users are saying, "thats nice, what's it going to do for me?" This is hard to say at this point. We can speculate about a few things though. Most importantly is better performance. It's no secret that Intel is putting more money into desktop processor research and design than IBM or Freescale (Motorola processor devision spin-off). More research means faster more efficient processors. Intel has shifted from pushing MHz higher to getting more computations per watt. This will give laptops longer battery lives and reduce the heat produced by the processor. These two things will lead to faster, smaller computers. It may be some time before these things are seen in Macs. There are rumors that there will be Intel Macs released in January, but as always Apple is keeping any hard facts under wraps.

By this point in time every developer has at least thought about migrating their applications to x86. This is a very important step as PowerPC binaries don't run natively on Intel chips. Apple has provided the Rosetta software to do on-the-fly translation, but this is not a final solution. Emulating an environment is inherently slow and is usually avoided when possible. For applications being developed with Xcode this should be an easy fix (unless you are using the Velocity Engine which is another discussion). Upgrade to the most recent build of the GCC (GNU Compiler Collection) and Xcode, turn on cross compiling and give it a try. If you already made the transition to GCC 4.0 there shouldn't be too many problems. In my experience the transition to 4.0 was more interesting than working out the dual binary builds. If you have problems check out Apple's Developer site, they have added a lot of resources for making this transition.

If you have any questions or comments feel free to post them.