My apologies that it took so long to get this up, but I've finally posted the slides from my presentation with Adnaan Ahmad on behalf of . The full-length video presentation of the session will be available very soon on , along with all of the other incredibly fascinating sessions from 360|Flex 2011.
Originally this session was supposed to be on how to optimize the designer-developer workflow in the enterprise using Flash Builder 4 and Flash Catalyst CS5. However, Adobe surprised us the first day at their keynote when they announced the release of iterative versions of both Flash Builder and Creative Suite. As a result, Adnaan and I scrambled for the next day or two to update our presentation accordingly. We didn't really have to do that, but of course we didn't want to seem like we were behind the times.
Nonetheless, when I upgraded to 4.5 and CS5.5, I ran into some compatibility issues because we had used the "Burrito" and "Panini" pre-release versions of Flash Builder and Flash Catalyst respectively to build the product we were demoing in our session, so I had to backtrack to those versions unfortunately. Nonetheless, I did talk about many of the great new features of these new releases, particularly the ability to round-trip between Flash Builder 4.5 and Flash Catalyst CS5.5! Enjoy!
I recently wrote an article for Adobe titled "Optimizing Workflow with Flash Catalyst CS5", which was recently published at . The focus of the write-up is to assist designers, developers, and project managers fine-tune the application development life cycle when using Flash Builder and Flash Catalyst CS5. There's a lot of really good pointers in it, so its definitely worth a look.
I'm also going to be doing a talk on the subject with my colleague Adnaan Ahmad from at this upcoming in Denver from April 10 - 13, so be sure to check it out because it is going to be full of fun surprises!!!
As I mentioned in my last post, I recently wrote a series of articles called "Cloud computing service models" for IBM developerWorks. Each of the articles focuses on one of the three major classifications of cloud computing, namely: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The objective of the series is to help educate people on cloud computing and understand the difference between the three types. Other topics of interest in the series include: what to look for in a service provider and how to protect yourself and your company from vendor lock-in. Here are the links to the articles:
I recently wrote a series of articles that will be published next month on the topic of cloud computing, and there was one thing that really stood out about the current state of cloud computing. A few years ago, cloud computing was mostly an abstract concept with varying definitions depending on who you asked. Things have changed though. It is evident that a large portion of the Information Technology and business sectors have gotten better at understanding cloud computing. However, when cloud computing is broken down into the three classifications of cloud computing, namely: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), most people find it very hard to understand the difference.
The most prevalent confusion seems to be with Platform as a Service. I've experienced IT professionals confusing Platform as a Service with Infrastructure as a Service so many times in the last few months that I lost track. The articles I wrote go into great detail on these classifications and their differences as a result of this, and I will post links to them here when they are published. In the meantime, I thought I would post a brief description of Platform as a Service and the players involved to assist in our continued understanding of cloud computing and it's three major classifications.
Platform as a Service is like a middle-tier between infrastructure and software, consisting of what is known a "solution stack". The solution stack is what sets companies apart who offter Platform as a Service. If you are a decision-maker for your company, this is something you will need to explore in greater depth before making a decision to jump on board the PaaS train. Let's take a quick look at the top three contenders in the PaaS arena to give you an idea of the differences between them:
Force.com. Force.com pages use a standard MVC design, HTML, and other Web technologies such as CSS, Ajax, Adobe Flash® and Adobe Flex®.
Windows Azure™ platform. Microsoft's cloud platform is built on the Microsoft .NET environment using the Windows Server® operating system and Microsoft SQL Server® as the database.
Google App Engine. Google's platform uses the Java™ and Python languages and the Google App Engine datastore.
In conducting research for this article, I took the opportunity to spend some time with Google App Engine, Force.com, and Windows Azure. With App Engine, you have a Java run time environment in which you can build your application using standard Java technologies, including the Java Virtual Machine (JVM), Java servlets, and the Java programming language—or any other language using a JVM-based interpreter or compiler, such as JavaScript or Ruby. In addition, App Engine includes a dedicated Python run time environment, with a Python interpreter and the Python standard library. The Java and Python run time environments support multi-tenant computing so that applications run without interference from other applications on the system.
With Force.com, you can use standard client-side technologies in an MVC design pattern. For example, if you're using HTML with Ajax, your JavaScript behaviors and Ajax calls will be separate from your styling, which is held in CSS, and the HTML will hold your page layout structure. With Windows Azure, you're using the Microsoft .NET Framework with a SQL Server database.
Hopefully this was helpful in providing you with a means for comparing PaaS competitors and understanding what is available to you. If you did find it useful, you will definitely want to read the articles I mentioned earlier. Although I cannot disclose any further information about these articles right now, I promise to post links the moment each one is published.
Although its been a hectic year, it has definitely been one of many new and interesting experiences. Some of you may know about the book I've spent the last 2 years working on with my esteemed colleagues: Tariq Ahmed, John C. Bland II, and Joel Hooks - titled Flex 4 In Action (Manning Press). Well, I'm very proud to say that the book was officially released today! And the nice people over at Manning Press are offering the book today at HALF PRICE, if you enter the code: dotd1110 in the promotional code box when you check out!
This is a 640-pager that includes some great content that you won't find anywhere else, including an entire chapter dedicated to architectural design with Flex 4 that Joel Hooks and I wrote together. Since I'm really big into building enterprise-grade Flex and AIR applications, that chapter is my favorite, mainly because of the full-blown rundown on Robotlegs that Joel Hooks gives you.
Additionally, if you've run into difficulty understanding the difference between the component architecture from Flex 3 to Flex 4, and all of the great features you gain in terms of scalability when building Flex 4 components, then chapters 17 and 18 are for you. The very intelligent John C. Bland II also shares some of his "top secret" tricks, tips, and techniques for adding that extra "pizzazz" to your applications, while Tariq Ahmed gives you all of the necessary information that you will need to know prior to building your first Flex 4 application.
The book is live as of today for purchase from , and is available for until November 15.
And don't forget to leave a review letting us know how you liked it after you read it :))
Well, the time so many of us have been eagerly awaiting for the last two years has arrived, and its no surprise that the twitter-verse, facebook-verse, linkedin-verse, and other social media universes are buzzing quite loudly with the news already, before it even had a chance to hit the tabloids (no surprise there). I'm sure there are many Flex developers wondering:
What can I expect to see in this new release?
Is it a lot different from the public beta 2 that was on Adobe Labs for Max?
There's a lot to cover, but here is the start to what will likely be a lot of upcoming posts...
One of the most significant things to take place after the beta 2 was the porting of the rest of the Flex 3 components (with the exception of DataGrid, AdvancedDataGrid, and OLAPDataGrid) to the Spark library, complete with the wonderful new Spark architecture, which adds a huge amount of scalability by separating the display logic from the encapsulated functionality of the component. Personally, that is one of the things I'm most excited about.
Additionally, code hinting and code generation is now a LOT more useful, which becomes exponentially more apparent as your Flex 4 applications get more and more complex. What does this mean for you as a Flex developer?
3 words: WRITE CODE FASTER!
Its true, as you get used to taking advantage of the code hinting, code generation, and service generating features (among other things), you'll notice that your workflow will improve dramatically. I admittedly have been using the Pre-release and beta versions of Flash Builder 4 (but with SDK 3.4 or 3.5) for enterprise clients for over a year now. While everyone else was still coding in Flex Builder 3, I was consistently able to complete a task comparatively quicker using Flash Builder 4. Unfortunately, being on the version 3 SDK, I didn't get the level of code-hinting that you get when using version 4, but the code generating facilities and enhanced project navigation alone made it so much easier to build very complex Flex apps.
Of course, a lot of work was also done on stabilization and A LOT of bug fixes!
Now that v4 is out of beta, I'm excited about the fact that clients will be much more inclined to use it, and rightfully so. The bottom line is simple: Flex 4 SDK and Flash Builder 4 extend their predecessors by leaps and bounds. The great news is that there is a lot of support for backward compatibility to ease the transition from 3 to 4 for apps that are in active development and want to take advantage of the features that ship with the new releases.
Ironically, today also marks the day of having completed our revisions to the chapters of , being published by Manning Press. Our revisions come as the result of the extremely valuable feedback given to us by our reviewers, to whom we are very grateful.
One of the primary reasons we have microarchitectures and design patterns in the first place is to maximize simplicity in application code. The problem is that not every architect understands this. Often we find architectures and design patterns being used in ways that do nothing more than increase complexity, which is counter-intuitive. This is why it is important to understand the framework that you are working with before you begin development on a production project that uses it, and Swiz is no exception.
A common characteristic among second-generation micro-architectures is that they are built to empower the developer, rather than over-power. One thing that all of these second-generation microarchitectures have in common, is that they use some form of and , as defined by the great in his book (Addison Wesley, 2002). With that in mind, you will first learn a bit about how these design patterns work from a conceptual standpoint before you get your hands dirty.
A Quick Background on Inversion of Control & Dependency Injection
Generally speaking, a good microarchitecture should allow the developer to decide how to implement an effective model based on the unique characteristics of the application. As previously stated, it should never force the developer into a specific model implementation. The Flex Framework is largely based on principles of Inversion of Control (IoC). In fact, this is true for most event-driven user interface development toolkits and frameworks such as Java Spring, EJB 3, Spring.NET, the ColdSpring framework for Coldfusion, Needle for Ruby, and FLOW3 for PHP 5.
The Inversion of Control pattern originally comes from another pattern described in a very important book published in 1995 that is often referred to as the "gang of four" or "gof" book, titled (Addison-Wesley). If you do not have this book already, I strongly suggest you add it to your collection as it considered a staple by every good developer I have ever met. One of the 22 design patterns described in this book is the Factory Method Design Pattern. IoC is a derivative of this pattern.
Why does ActionScript works well with IoC?
As you have learned, the ActionScript language is an object-oriented language in which objects are instantiated by declaring new instances, like so:
private var thisObject:ThisObject = new ThisObject(params...);
In contrast, IoC instantiates and registers a specific set of pre-defined objects at runtime, and injects them into each other using a concept known as Dependency Injection. By injecting these dependencies at runtime, the dependencies can be quickly and easily modified because the objects remain loosely coupled. The objects are loosely coupled because their dependencies are not "hard-coded" into the classes. This makes managing large code bases much easier.
Objects and object properties can then be wired up through binding. That means that all of your views and components can have what they need before anything ever even shows up on the stage!
With other implementations like Java Spring, an application's objects and implementations can be declared in an XML document. However, this particular method is not possible with Flex due to the order of operations that happen at application startup. More specifically, an application is not ready to parse an XML document until after it's objects have already been instantiated.
Coding Flex Applications with Swiz
Swiz caters specifically to enterprise level Flex development by providing a solid architectural foundation derived from proven enterprise application development patterns. This includes:
Minimizing dependencies to promote loose coupling
Inverting the flow of control
Dynamic mediation
Swiz meta data: Autowire
The Autowire tag is used for component wiring, while the Mediate tag is used for dynamic mediation of events during the bubbling phase of the event cycle. Placing the Autowire meta data above the property of an object tells Swiz that it should inject a specified property from another class into this property. This is written as follows:
[Autowire]
[Bindable]
public var mainViewPModel:MainViewPresentationModel;
In the example above, the MainViewPresentationModel class is injected at runtime by Swiz as a result of the Autowire tag being placed above it. It is also made bindable in this instance so it can be referenced from properties of MXML components. Let's say you have a Boolean property in MainViewPresentationModel called calendarVisible. Then, let's say that when the application enters a certain state, calendarVisible gets set to true. (Note that calendarVisible should also be bindable in this case). In the MXML view that has the presentation model autowired into it, you could now state the following:
Ok, so what's so special about that? Well, now let's say you have an event called mainStateChanged, which is mediated in the controller class (more on event mediating in a moment). When the event is fired, the controller that is mediating it picks it up during the bubbling phase, and initiates the setting of calendarVisible to true. Since we're binding to that value in the visible property of the component, the calendar will immediately become visible! Ok, now that you've got that figured out, it's time to learn about mediating events.
Using the Mediate Tag
The first and most important thing I should note in regard to using the Mediate tag, is that events should ONLY be mediated in controller classes. If you place Mediate tags all over the application, mediating events in the model and the view for example, your application will be seem just as much like spaghetti-code as it would if you used no framework at all. Remember that Swiz gives you much flexibility, but with that flexibility comes a responsibility to use best practices when writing your code.
If you are already familiar with the publish-subscribe design pattern, then understanding event mediation should come fairly easily. The following code demonstrates the use of the Mediate tag:
[Mediate( event="DataEvent.SHOW_DATATIP", properties="index,data" )]
public function showDataTip( index:int, data:ArrayCollection ):void {
var itemData:String = data.getItemAtIndex(index).toString;
var dataTip:DataTip = new DataTip(itemData);
addChild(dataTip); }
In the example demonstrated above, Swiz will always be listening for the DataEvent.SHOW_DATATIP event during application runtime. When Swiz finds a Mediate tag, it binds the specified event to the method that appears on the next line. When the event is fired, Swiz automatically calls that method.
In order to declare events with the ClassName.CONSTANT syntax as it is in the example code, you must tell Swiz where your events are located using the eventPackages property of the SwizConfig object that you declared in your main application file. Otherwise, you will need to use the fully qualified path when specifying the event that should be mediated.
Flash Camp Phoenix was held in front of a sellout crowd on Friday, and everyone considered it a huge success. I consider this a huge success for the local Phoenix Flash Platform community as this was the FIRST Adobe-based event held in the Phoenix-metro area and the turnout was HUGE. Some of the highlights of the even included Christian Saylor's inspiring session on User Experience, Ryan Stewart's keynote which announced Adobe's upcoming plans for the Flash Platform. Additionally, Sarge Seargent from Adobe did an awesome session on Flash Media Server and the direction of the Open Source Media Framework and Flash video on the web. Kevin Fauth also kept things interesting with his comedy routine on programmatic drawing (you have to see it to believe it).
I was asked to publish my presentation from my session on "Building Custom Spark Components in Flex 4", so I have included it below:
It's been hard not to notice the adamant (and sometimes extreme) stance that a number of Apple fans have taken in Apple's defense to the shocking evidence that Apple has not been telling the entire truth with regard to their reasoning for not allowing Flash on iPhones/iPods. First, let me be perfectly clear: I own 2 MacBook Pro's, 2 iPhone 3GS', an iPod Nano, a ton of Apple software, and to top it off - I bought my Dad a new iMac and my sister a MacBook for Christmas. I love Apple's products. This is my way of pointing out that this post is not meant to be a defensive response to the attacks against the Flash Platform. If anything, this should help clarify some things for the seemingly misinformed...
Argument: "[Flash] crashes my browser/system"
I've read a substantial number of claims that Flash is an awful product in the last 2 days because it "...crashes my browser". I've read people say they have Flash disabled as a result of this, and some go as far as to say "Make a product that doesn't suck and maybe Apple will include you on its devices".
How these people are misinformed
From a technical standpoint, this is a ridiculous claim. The Flash plug-in is actually incredibly lightweight compared to the majority of plug-ins that people bog down their browsers with. The problem is not in Flash itself, but rather in the poor programming practices on the part of the developers that are writing the programs that crash your browser. If your CPU pins at 100%, it is usually the result of a recursive loop that is firing an event, which calls back on the method to fire the event again. This occurs on an exponential curve, which is why your CPU gets pegged so quickly. If Java applets won over Flash many years ago, you'd be seeing the same thing. It doesn't matter what language it is, when developers don't take a best-practices approach to the code that they write, the end user suffers. I see the same stuff happen in the worlds of Java and .NET. Its negligence and carelessness. Developers have a responsibility to uphold when they build a client-side application, and if that contract is broken, well, your browser crashes.
As one would expect, the average response to this logical reasoning is something along the lines of: "Well then its the fault of the programmers writing Adobe code..." which of course is then somehow tied back to Adobe using a similarly unreasonable argument. So here's a question - what do you think these developers were doing before they started writing Flash programs? They didn't appear out of thin air. In fact, the larger percentage of Flash Platform developers come from the Java development community. In the world of application development, some individuals simply do not care to follow standards and conventions in programming best practices, and that is where it ends. If you don't pick up the trash in your house, you end up with a messy house that is hard to move through. If developers do not pick up their trash as a matter of convention in their programming, then you're running a crappy program. You can't blame that on the Flash Virtual Machine. It's just not logical.
Argument: "Adobe is trying to monopolize the web with a closed format"
I have to be honest, this one made me laugh. Here is an actual quote from a comment that was left on the Flash Platform team's blog site:
You Adobe people are frelling hypocrites, open standards indeed... Your claims will hold water when you donate the Flash platform to the open source movement. Until then you're just spewing hypocritical BS about open standards.
Now, I'm not sure what a frelling hypocrite is, but I assume it is much like a regular hypocrite (couldn't help it). Regarding the last point about these same people that are declaring shenanigans on Adobe because of programmers that write bad code, what do you think would happen if the "Flash Platform was donated to the open source movement" as this person suggests? It gets better too. Included in the package of extremely passionate claims of blasphemy and wrong-doing against Adobe comes the next major reasoning as to why Flash should not be allowed on Apple devices...
Argument: "Flash is loaded with security problems"
Here's an example of how extreme this gets. The following quote is also pulled right from a comment left on the Flash Platform's blog site:
"Adobe Flash is a complete piece of junk. When Adobe fixes all the security problems and bugs in Flash, maybe then it deserves more widespread adoption. I can't wait until the day that Flash is gone."
This essentially takes us round-trip right back to the very reason that the Flash Player is NOT a "donation" to the "open source movement". I find it interesting that one would refer to Adobe as being "hypocrites" in this regard; and yet, it just shows how far beyond reason the people that are so actively protesting Flash in Apple's defense truly are.
The truth here is so blatantly obvious that I am perplexed as to how so many people do not see it. It is very simple: it is inconsistent with Apple's business model to allow Flash on their mobile devices. Apple makes a massive amount of money by controlling (and taking their cut) of the money that is paid for media consumption by owners of Apple mobile products. Uh...DUH! The only reason this whole thing became so controversial is because Apple was not up front and honest about it. Instead, they made promises to include Flash and then went back on those promises...multiple times. The claim was that Flash was simply too resource-intensive, so Adobe began development of a lightweight SDK that catered just to the iPhone. It was not until the announcement of the iPad; a machine with far more than enough resources to run the full-blown version of Flash, did it become so glaringly obvious that they had been giving Adobe the run-around all this time. I don't know about you, but I don't like it when I feel like someone has not been completely honest with me...but that's just me. Apple's runarounds caused many business strategists a lot of frustration, so while the community may be reacting in such an extreme fashion, Adobe really hasn't been all that vocal about anything yet (probably too busy watching all of this back-and-forth bickering going on...what a PR nightmare!).
This is capitalism at its finest folks, it has nothing to do with the technology. In the end, its all business and its all about the numbers on the bottom line. it's the country we live in. But that doesn't mean we the people do not have the power to facilitate change.
With that said, I will conclude with this -
As long as Adobe and Apple - two of the strongest technological innovators in the world - are unable to find a way to collaborate in the effort of furthering the advancement of mobile technology, WE ALL LOSE.
Ryan Stewart has some interesting things to say on the topic as well, not only from the standpoint of an Adobe Evangelist, but from the standpoint of an Apple consumer.
Although I've been in pretty deep finishing the book Flex 4 in Action, some recent conversations along with Apple's iPad announcement this morning inspired me to blog about my take on the current state of the web as I've been following market trends in media consumption for a little while now.
HTML 5 vs. Flash
For some odd reason, I'm seeing more and more people putting the new HTML 5 spec up against Flash, largely due to the lack of support from Apple with regard to the iPhone, iPod touch, and now the iPad. As a side note, I love Apple, but did the marketing dept decide to take the year off and leave Jobs in charge of branding? WTF is an iPad? It sounds like a feminine hygiene product. Anyway, I digress.
First, its tough to compare HTML 5 to Flash. To me, one might as well try and argue that eggs taste better in the morning than spaghetti does in the evening... Eggs in the morning makes sense, right? It's a good breakfast food. Similarly, who doesn't like a good bowl of spaghetti once in a while for dinner? Seems to make sense... spaghetti = dinner food, as eggs = breakfast food.
To take a more pragmatic approach, this reminds me of Web Designer Magazine's infamous "AJAX vs. FLASH" issue late in 2009. After furiously trying to find a way to pin the two technologies up against each other in a head-to-head, winner-takes-all, fight to the death; the author ultimately gave up and concluded that each technology had it's own unique and specific purpose that filled a particular void that the other did not. They same could be said for why we have so many different programming languages and frameworks...I mean, have you seen the number of frameworks for Java alone? I'm not sure how Java devs are able to keep from going mad! And yet, every one of those frameworks has a very specific role and purpose.
Adobe Flash Platform vs. Apple Mobile Devices
The Flash Platform is the undisputed champion in RIA and is continuously running circles around the contenders, the most notable being Silverlight - which has been weak considering the number of .NET shops that have chosen Flex for their client side RIA development. Even more interestingly, the data provided by major research firms suggest that the iPhone will soon lose its dominance to Google's Android platform, and has been reiterated by a number of different research companies now. WHAT?! ....its true, and the reason is that the public is generally dissatisfied with the full-nelson choke hold that Apple puts on its technologies. Apple lost massive market share last year in Music sales from the iTunes store - primarily to Amazon - because Apple wanted to keep the DRM choke hold on their tunes and Amazon had something else in mind. Even when Apple finally submitted to the pressure and let go of DRM, so many people (myself included) already had a bad taste in their mouth and didn't really care to go back, and the rest are STILL unaware of the fact that Apple's tunes are even DRM-free!
The research suggests that we can expect something similar to happen with the iPhone. A massive (and growing) number of powerful and innovative technologies are under development, all on the Flash Platform and all for different media consumption platforms (eg. cable boxes, mobile, computers, etc.) because we have the ability to seamlessly hook a variety of platform-specific client interfaces to the same network data source, which could be providing its data in near-"real time". Google's more "open" philosophy will eventually dominate (that is, assuming they can get a better handle on user experience), since developers ultimately decide what stays and what goes, and well, I work with 103 superstar Flex-developing iPhone owners whose patience with Apple's un-kept promises to support Flash on the iPhone has run very thin.
Where do we go from here?
As far as HTML 5 having any impact whatsoever on the web (let alone on the Flash Platform) in the next two years... all I have to say is - don't hold your breath. The market is actually in an unusually predictable state right now given the gradual and consistent advancements in technology, the philosophies of company leaders, and what we can derive from the trends of the last decade.
Anyway, that's my take on things for what it's worth.