Teoti Graphix, LLC

Hi,

I really think what I am doing here is healthy for the Apache Flex community that reads it. I have for the most part tried to keep opinions out of these summaries, not always. If I have any parents, animal lovers etc, you will know that when a new child enters the house there is, no sleep for some, hectic communication to family and friends, and an understanding that in the beginning life requires your to give “a little” bit more to your new born baby.

Yeah, I’m a sentimental guy and love my children, I also love the fact that I now know others in the community have an investment into Apache Flex like we have had with the renegades of Flash back in early 2000s.

Apache Flex Logo Contest

The Apache Flex logo contest was the PPMC members first vote on a draft document. It was approved unanimously and will be published on the site I would guess Monday morning (pending).

There is one requirement that will need to be upheld for your image to even appear on the site with other applicants;

Do not use anything the even resembles the Adobe Flex logo of past, present or future. This is the easiest way to get a “thanks but no thanks“.

Spoon Visibility

Jonathan Campos reminded the community that there are already active Spoon members on the list, Garth, Kevin and Nick some others are on vacation.

He also noted that Spoon is preparing for an open public call for the community.

Again what is Spoon?

Spoon is a nonprofit corporation created by some community members to promote, educate, and contribute to the Flex framework.

http://www.spoon.as/

Coding conventions

This topic is still going and from reading every post that has come through the doors, I would say that 3/4 of community members want to keep the standards close to what already exists here;

http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions

Once the conventions are agreed upon, Jonathan suggests that they should be committed by svn and are protected by the votes of the PMC.

Basically all this means is, if you have problems with them in the future, bring it up on the list for discussion, we don’t want the community changing them at their will on the wiki. (this would negate the meaing of convention anyway)

BlazeDS

Continuing on the topic of BlazeDS and where it’s home will be Alex commented on that fact that there is little to no initial committers for the project.

Anne pointed out that without a core development team (initial committers), she cannot see how BlazeDS would survive as an Apache project.

“To graduate from incubation the project needs, among others, to show that it has an active community. (this doesn’t have to consist of committers only)”

Alex did point out that the rpc.swc is included in the Flex contribution.

Flex Road map

This was something that in a round about way was brought up at the beginning of the week and I have more information written about in the Flex-Dev summaries.

I would like to post a link here of Sebastian Mohr who is a PPMC member and initial committer. He has put a huge amount of time into this information and I think it’s worth your time checking it out and giving him some feedback.

http://code.google.com/p/masuland/wiki/WhatsWrongWithFlex

JIRA

JIRA will be up when it’s up. As noted earlier in the week, there is a HUGE amount of migration happening and it’s not as easy as just flipping a switch like wordpress or something.

I’ll let the community know on this blog the moment Apache Flex JIRA is online. Then kill the server with more bug and feature requests!

Conclusion

Hey it was Saturday and we voted, if that doesn’t say something then you don’t want to listen to what we are all saying.

Happy Sunday,
Mike

Hi,

Day three of I would say the “brainstorming” session in the flex-dev@apache.org mailing list.

Flex logo

The community is still invited to think about logos for the flex website. There have been quite a few ideas floating around and plenty of opinion. It’s nice to see that one of the more popular designs that has been submitted on the mailing list is by a very humble Carlos Rovira, that insists a contest needs to be held and voted on by the community.

We are trying to get a page on the website describing this, I think I might just try to get that up with the information that has been submitted already so folks can take a try with their own idea.

Flex SDK full code reformat

As mentioned there has been discussion on code conventions and having some type of singular look to the code in the core SDK. Alex has mentioned his main concern is not tabs or spaces, just that 4 spaces equals one tab.

It’s up in the air but Rick Winscot has been investigating running the Flex Formatter on the command line so Alex can do one full pass through the SDK.

I do agree with some thoughts that have been brought up, the main idea is that the frameworks code looks uniform, how we get there is another story and whether devs care is another one.

Flex mobile components

Alex pretty much summed up Adobe’s position on the current state of mobile components.

Q: What is the future of mobile AIR components from Adobe?

A: Mobile AIR Components are being donated to Apache.

Q: Will we continue to see new mobile Flex components from Adobe?

A: No, but I hope to see some from Apache.

Non shameless plug here, I have released the mobilui toolkit1 mobile set and plan to release more mobile components having support from the community.

Product Page – http://www.teotigraphix.com/components/toolkits/MobileUIToolkit1

Q: Will we see AS3 mobile components from Adobe (rather than built in Flex)?

A: No. Adobe is not planning to develop new components outside of Apache.

Q: When they promote future AIR mobile content, will they reference any new Apache Flex mobile components that we develop?

A: No way to know for sure. 4.6 has a pretty good set of components already. I would bet if Apache Flex makes some really great mobile components, they will, since it will help AIR. Adobe has been promoting Jquery for HTML for a while now. I think it is roughly the same model.

Alex finishes it off with

It will totally depend on how well Apache Flex works as a community.

Couldn’t have said it better myself.

GIT support

Do we have GIT support for the Flex SDK?

Bertrand answers;

There’s http://git.apache.org/ where we can ask to have a git mirror
of Flex once the code is in.

I don’t think this allows for directly committing pull requests, but
people are working on it. For now, AFAIK you have to create an svn
patch from your git changes, which is quite easy.

Summary, I’m sure a lot of devs including myself will use GIT on our local computers than commit that code to the svn repo on svn.apache.org.

SVN Whiteboard

The Flex SDK will contain a whiteboard root folder that will hold all the future innovations of the Flex SDK and beyond. If you are a developer you will definitely want to check this out and update constantly.

Check it out here; http://svn.apache.org/repos/asf/incubator/flex/whiteboard/

Tink has committed the first whiteboard in the navigators folder. These components will but up for review to be included in the first release of Apache Flex.

We are working on getting an Accordion and TabNavigator implementation that parallels the mx version.

BlazeDS

BlazeDS has come up and where it’s home should rest. Most community members feel that it should exist in it’s own project even though it has dependencies on the Flex SDK.

The obvious argument is that Flex is client and BlazeDS is server, that alone constitutes a separate project.

Other community members are not convinced that Adobe is going to move all rpc code which will then create licensing issues with the LCDS product. I have to admit, I am not one to talk on this subject so don’t take my word for it as in Reading Rainbow.

TabNavigators and other new components

Any of you that read my blog will know I am direct, action oriented and don’t like to play games. Consequently I have been raring to go with this Apache Flex project since I have somany years invested and feel it’s worth my time to give it all I got right now.

That being said, sometimes I say to much, but maybe that is a good thing. Maybe I’m speaking for other less vocal developers that feel the same way as me. Maybe not, I do make myself a target sometimes.

I am in full agreement that the “kitchen sink” as it is consistently called should not be jammed into an SDK that were are trying to trim the fat out of anyway.

Now for closing, my own verbatim comment to this on the list;

My thought, create an extension, branch what ever you call it of flex component extensions that are officially supported by the committers of Apache Flex (me, you and others). Have it merge in things from the FlexLib, show the community that using components saves time and is supported as a fundamental development ROI. This might actually re-ignite the 3rd party ecosystem benefiting the people like you and I that aren’t quite satisfied with “traditional” consulting model.

Conclusion

Some days are more emotional to some than others, this one was a good and bad one for me. Good that I see so much future to an Flex SDK that can be better, bad that I might not be able to convince the community to change there bad habits.

Thanks for reading,
Mike

The second installment of flex-dev@apache.org summaries.

I think I will write these as long as I have time and the community seems interested in a quick glance at something you might otherwise need to be completely involved in to get the full gist.

Apache CMS Website

http://incubator.apache.org/flex/

• non committers submit patches to JIRA
• committers review and commit the patches

Note: JIRA is not up and running yet.

I want to contribute to the Apache Flex web site but I’m not a committer, how do I do it?

Answer for now;

Non-Apache committers can still checkout the site in svn and submit patches to the list. Otherwise they may access the CMS using username anonymous and an empty password and use the Mail Diff feature mentioned above to send patches to the list from the CMS.

How to create a visually appealing Flex Apache website;

• Allow the community to contribute videos, tutorials, documentation, links to examples, etc.
• Allow the community to embed SWFs in the pages.
• Improve the layout based on what the Flex community already expects, IE flex.org for example.
• Create a wiki running on either MoinMoin or Confluence.

Creating a wiki would allow the community to contribute and create structures for content, examples and how-tos.

When established and proven content is produced on the wiki a committer can then move that content from the wiki into the actual svn portion of the Apache Flex svn website.

Dave Fisher of apache.org has also pointed out that the Apache Flex website as it stands right now is just a skeleton. This means community involvement with ideas and designs are required to take it to the level the Flex community is used to.

Dave also points out;

If there are services that the Apache Flex needs and a good case is made it is my experience that Apache Infrastructure will work hard to it particularly if this is backed up with sustainable support from the project.

Falcon compiler source code / Falcon architecture

More information on the Falcon compiler;

• Performance improvement is still mainly leveraged by Flash Builder and incremental compiles.
• The compiler’s MXML handling is still up in the air, the first drop may not even handle MXML at all.
• The focus is on AS compiling since that is what Adobe will be using it for internally.
• Adobe is pushing to get a drop before their team “considers” the compiler done.

Branch Strategy

There is a long discussion about the svn release/branching strategy being talked about. This is definitely something that needs to be concluded and there has been multiple suggestions which makes coming to a conclusion a bit harder.

Flex Logo – Community Participation

The Apache Flex community is starting a contest or initiative to re-brand the Flex logo suited for the Apache Flex website.

More details to come that will be located on the Flex Apache website.

Note: For the selected logo, the author will need to donate them to the project according to the Apache individual contributor license;

http://www.apache.org/licenses/icla.txt

Apache Flex first release

Among the most talked about subjects, this is close to #1. The discussion revolves around the fact there are some that want a polarity release to Adobe’s 4.6 release. Others say that releasing a mirrored release will cause confusion in the community.

What do you think?

Apache Flex source code commit

There have been more issues that Alex and Carol have encountered with pulling the OS source from Adobe’s so first commit seems to be at least pushed off until late next week.

Conclusion

All in all is all we all are, to get Apache Flex moving we need community support, input and resolution. I think the initial community is allowed a bit of time to get on the right foot. Sooner than later we will be stepping on our left foot forward into the right direction.

Thanks for reading,
Mike

Hi,

I brought up something on the flex-dev mailing list yesterday about adding api to the new compiler that would allow access to the compiler’s internal AST.

The problem I have right now is I am blind, I know what a compiler should have, I know how I implemented my parser framework asblocks and jasblocks with a DOM wrapping the low level AST nodes.

But I have no idea what to expect from the Falcon parser/compiler once us tool developers get to see it’s code. Please check out the thread “Proposition :: ASDoc and compiler adjustments” to find more information about what was being talked about.

The image below shows an AIR application written on top of SpringAS 2 that I have developed for my component development documentation using the asblocks (AS3 read/write), sx-plugins, SpringAS 2 framework. It’s pretty self explanatory but, for those on the mailing list that wanted a use case, here it is and this is my driving motivation because I know how powerful this is.

All the parsing and code writing is done with AS3! There is no Java in this application.

Imagine an application like this being made using the Flex compiler to document the Flex SDK, that would be called poetic justice.

Right Click the image to view Full Size

Mike

Hi,

The Apache Flex era has started and there seems to be quite an interest brewing in the flex-dev mailing list of the apache.

To summarize some of the topics;

The Flex Website

The new temporary website for Apache Flex is located at;

http://incubator.apache.org/flex/

There is a great chance for the community to voice their opinions for a design and content.

Flex SDK Source code

It’s been mentioned that the source code is going to be committed hopefully by Monday. The testing suite is a lot harder to move over and there are JIRA issues from moving from Adobe to Apache. Alex is letting the committers know “I would like to discourage commits of anything significant until we have a way to verify your changes are safe.“.

Committer information

The Apache Way was brought up saying a roadmap is more like working for a company, Apache developers work on what scratches their itch or they feel is necessary bug fixes etc. It’s also noted the the flex-dev mailing list is the defacto communication center for SDK change.

It’s also been brought up that the Spoon project aims at creating an SDK roadmap on a more architectural level. If your interested in more an ordered enhancement with leadership, your invited to check out the Spoon initiative.

“Spoon is a nonprofit corporation created by some community members to
promote, educate, and contribute to the Flex framework.”

http://www.spoon.as/

Also check out;

http://tv.adobe.com/show/flex-community-summit-december-2011/

Another important thing to note about Apache;

“If it doesn’t happen on list it doesn’t happen.”

This means that the development of the Apache Flex SDK is a community venture. The practice of going off into your corner and creating something without the community digesting it is likely to get vetoed after you commit it or submit a patch to a committer.

There was also a discussion about large commits and component splintering. It seems that the consensus is the same as above, anything and everything needs to be discussed and approved through the consensus.

Flex Modularity

The future of interfaces, DI and composition was brought up dealing with the amount of modularity and Inversion of Control the core framework should have.

This is a hot topic and likely to be the center of some major conversations in the future.

Flex Mobile

The question of Flex Mobile came up and there is definitely a commitment from developers to make it a priority.

Jeffry Houser says;

“Be sure to let your clients know that AIR is the technology behind things like Photoshop Touch. Most of my clients have taken that as a continued commitment to the platform.”

This is a very good point, why would Adobe make an application such as Photoshop Touch and be ready to phase out AIR for mobile, highly unlikely.

Framework RSLs

It’s noted that .SWZ will not be hosted by Adobe. This discussion is still ongoing as to how signed RSLs will be handled.

Flex SDK code conventions

Flex SDK coding conventions(the lack there of) were brought up and it seems there is a consensus that there needs to be a base standard for all code in the core SDK.

The FlexFormatter is a great choice but only works with eclipse. There is another option albeit down the road and that is to plugin into the actual compiler, create hooks, DOM api and create a formatter using the compiler’s AST.

This is going to be a major area of development and committing from myself dealing with the compiler and asdoc tool.

One thing that needs to happen is a round of formatting needs to be executed on the majority of the framework sooner than later, so commits do not get unruly.

Falcon compiler

Adobe hopes to contribute the Falcon compiler at some later time with a cleaner code base. This is great news for all of us compiler tooling nuts.

The bad news is it’s not available right now and we don’t even know when it will be.

We are asking for some documentation at least on how it’s designed, so at least developers can start to think about strategies.

Devs have voiced their opinion that sooner than later is beneficial for everyone.

Conclusion

Being an initial committer, this is more than I could have even hoped for. I am really starting to see the direction of Apache Flex and it’s rising from the ashes of 11-09-2011.

I have one really acidic blog post dealing with the way that day made me feel as a passionate development, seeing what’s in the mix now and that the community is now the driving force, the chard remains of that emotion can finally be put to rest.

All I know is there are some smart developers in the group that have a passion for what Flex can be, thanks for reading.

Mike

Hi,

Well just a quick note to those that are following the direction of Flex, now ApacheFlex podling. I think an important thought we should be thinking about now is how can the SDK and tools be transformed into something that does something new. This thought is for the future and needs to stay in sight if the SDK and tools are to evolve with the changing times.

I will still stand with my opinion that the idea of Flex is powerful as an abstraction to a programming problem that is ever present in the rich graphical and data centric world we live in today. Having written a framework for AS3 reading and writing source code, that is all it is; a language that describes lexical meaning of a problem to be expressed.

So what the heck does this mean? I see compilers as a gateway of transforming something to something else. We have compilers everywhere from text to speech, music sound to notation, color to paintings. ApacheFlex can take our technical imagination into places where is was not able to go. For now, Flex is AS3 and AS3 is the Flash Player, allowing a language that is proven to work well, minus the fat and needless abstraction with to many dead ends, the idea of Flex can become whatever we want it to be with a mature language such as ActionScript3 to express in a very easy way how to get there.

A new framework from the ground up, who knows but I’m glad I get to put my programming/development skills where my mouth is now.

A lot of us just want to see the podling child grow up a bit and become a first class citizen in the new mobile and desktop melting pot we call technology.

Mike

Hi,

I’m writing this blog post to clear up any confusion I may have given the community over my last blog post “Flex’s future :: A component developers take“.

It seems that some may judge a book by it’s cover and I never really liked that space in life. So here is the content of the book whose cover was read in that post.

I have worked with the Flash Platform in many incarnations. I have seen the Flex SDK from the beginning when it was the Flash component framework around Flash 6, to the AS2 version of the V2 component framework Macromedia released as an update to an otherwise sloppy AS1 prototyped component framework. The next evolution came with Flex. Flex used the component framework existing in Flash and built upon it, I saw that transition as well.

The moral of this story is there are many chapters to my book and the Flash Platform. My post came from a deep emotional issue of how Adobe so thoughtfully announced the reconfiguration of their company leaving developers like myself hanging from their bootstrap.

I have been told that the Flex SDK does have the “crap” I was talking about due to the conversion from AS2 and AS3, thus the UIComponent’s monolithic size. Plainly put, object creation was expensive in AS2, not so in AS3 but Adobe could not just switch everything to composition in a heart beat. I think any competent developer knows that even a refactoring might not take care of the bloat-design that is existent in the UIComponent.

So what to do?

Flex now called Apache Flex is being open-sourced and the community can change the direction of what it actually is, what it can be and how it can get there.

I’m honored to be selected as an initial commiter to the Flex SDK and will try hard to reinvent Flex in the language a lot of us hold dear to are heart, ActionScript.

My blog post did not at all mean I am throwing mud at Adobe or the Flex SDK, if you read my post again, I said these problems were there all along and nothing was done about them. This problem lead to the SDK not reaching it’s full agile potential in my opinion.

In closing

I love ActionScript and I love flex, when you commit a percentage of your life to something, you have a right to talk about, rant about it and laugh about it. To all those that read this, AIR is not dead on mobile and the Flex SDK can become an accessible cross platform development alternative.

For Flex-ActionScript, HTML5 and JavaScript, who knows what the innovative community can dream up, we will just have to wait and see.

Mike

Hi,

After months of development and research, Teoti Graphix, LLC has released the MobileUI Toolkit 1. Our first toolkit in a series of time saving AIR mobile Flex component toolkits.

The MobileUI Toolkit 1 focuses on;

• A PopUp that is an inversion of control type manager decorating SkinnablePopUpCtontainer subclasses such as the Dialog and TextDialog.
• An Alert API that uses static methods but is not at all tied to static methods for open and close, the PopUp class can even be extended.
• An enhanced MobileButton that adds a longClick event and longClickDelay style.
• A vertical and horizontal Picker component that is not based off of the List. This is important for memory and performance needs.
• A simple ProgressBar component that allows for primary, secondary and indeterminate progress levels plus left and right layout directions.
• A very powerful and skinnable/styleable RatingBar component that subclasses the ProgressBar.
• A WebView component that wraps the StageWebView and adds UIComponent layout logic.
• A SkinnableStageWebview that can be used to create composite WebView components with controls.
• A WebViewBrowser that has actually implemented the SkinnableStageWebview with skinparts to make a simple OS browser.

This is a very highlevel description of what this toolkit offers. Teoti Graphix, LLC has been creating Flex components for a while now and knows how to create extensible component frameworks. You not only receive these finished polished components but have a place to jump off and create even more complicated components based off of the core framework.

The toolkit was designed in a way to promote extension by abstracting core classes in the PopUp framework and other various classes into a common library project in our development. This means as new toolkits are released they all will include the core components. For more information on this you can check out the Reference Book on our site and see what is contained in the UICommon kit.

Images

I thought about posting them here, I had in a previous post but I’m sure if you are interested you can take a second and just check out the product page that has all this information condensed and outlined.

Product Page: Mobile UI Toolkit 1

Support

Our support is one on one answers and even helpful information. Just look at the wealth of information and dedication on this blog and you will get an idea of the commitment we put into our products. There is a technical forum that is available for all customer users.

Our reference book has a very good image and screenshot layout for fast and concise understanding.

• Reference Book

Documentation

Our documentation is second to none. A lot of the documentation and asdocs are written well before the actual component is finished. Good documentation is clear communication and shows the true intent of the component and it’s capabilities. We do not want to sell products to people that don’t need what the product offers. Instead of spending time and money on fancy advertising and flashy adds, we invest time where it counts, documentation, examples and asdoc code comments.

Our ASDoc documentation;

See – MobileUI Toolkit 1 ASDocs

The ASDoc documentation is created by our own hand written Java ActionScript Paser and Documentor JASDoc, using the one and only as3-commons-jasblocks framework! Yes that is right, that documentation in the above link is ALL created with our opensource as3-commons-jasblocks parsing framework with a custom Java application written for the documentor. Now here is a developer that really loves his ActionScript!

You may notice some interesting additions like implemented by, Host component links and more.

You will also notice that all the example packages that hold the product examples contain the source code and image! So you can quickly look at the image, scroll down to the source and see how it was implemented in MXML.

Conclusion

What you get by purchasing components by Teoti Graphix, LLC is supporting an experienced ActionScript Flex programmer and helping to push the community forward through this support. The components we offer are supported and feature requests are available, so when you purchase you have the option of asking for new things. The odds are, if your request is possible, it will probably get implemented, no red tape here.

Currently we are working with Android and have a proto application for viewing these components in an apk. If you are interested in this for viewing purposes please contact me (Contact Mike).

Also if there are a couple iOS users out there that like this component toolkit say with an iPad and iPhone, we are willing to give away a couple free licenses for testing the components in the iOS mobile devices. We mainly program Android and do not even have iOS developer licenses.

Thanks,

Mike

Hi,

Reading some blog posts and other information about the Future of Flex, I am getting a clear image of the future. If Adobe hangs onto all run-times such as Flash Player, AIR and maintains their position that Flex is a money loser, Flex is dead.

Teoti Graphix, LLC has made decent money on 3rd party Flash and Flex components since 2004 and with Flash back to 2002. I just read the following in a great article;

The Fading of the Flex Framework

“If the 3rd party Flex component market never took off, why does Adobe think there is a large community willing to spend time (which equals money) doing what Adobe is no longer willing to do — fix and further the hot mess that is the Flex SDK?”

I belong to the 3rd party component market, no one ever talks to me. I have had quite large businesses contract flex components for their applications. See the thing is here, Adobe never cared about the 3rd party component developers. So to say that the market never took off is not accurate, the market never existed because Adobe didn’t see money in it for them.

I talked to Matt Chotin Adobe(when he still existed) many times about creating an ecosystem that extended the Flex framework through a component ecosystem and there by establishing good coding standards for components. The best Adobe came up with was the pitiful Flex Exchange which was and is a joke. It’s like a ghost town of outdated crap.

I have spent the last 3 months creating a mobile toolkit that offers some very useful mobile components for AIR applications. Does it make me sick to my stomach sometimes that companies(individuals) are willing to laugh at spending 149.99$ for 10 professional, documented and supported components? Not to mention have the ability to ask for new features from me. Get one on one support from a real person.

YES, see the joke is on those that didn’t pass their Math statistics class and can’t see the tree from the forest. Before developing software I was a Land Surveyor in the construction industry. You know the most valuable thing to a builder/contractor is their tools. They know spending more money on a good tool will save them twice as much money in the end. This is not BS spewed from my mouth, this is reality in industries that have been around for 1000′s of years, how long has the software industry been around? … Not even close to being a mature market place.

You see, Flex never got passed diapers in my eyes with the way developers approached it’s code. It was wam bam out the door who cares if it’s still dripping with crap. And hey, copy and paste that crap right into the next batch of crap, because in the end you have nothing but crap. The Flex SDK has a lot of crap supporting it and even inside it.

No, real component developers(I am talking software in general) care about their code and if anything is wrong will fix it. A component developer or as I like to put it, a tool developer cares about “his/her” niche in the grand ecosystem. This is why proprietary systems do work still because they “own” what they release and take pride in it (not like the freaking wasteland of dead flex code out there, yeah hey GO GREEN! The worlds dead open-source servers waste a HUGE amount of energy). With my components, I still give you the option to spend a little more and get all the source code.

For Flex to thrive in the next 5 years, the Spoon project MUST transform it’s image from the diaper wearing, over bloated non standard code dripping SDK that it is into something that is a respectable piece of software that solves a purpose and is not trying to be something it’s not (ehhem Flash dirty Catalyst).

Spoon NEEDs to create a 3rd party component ecosystem because those developers COULD give back to the SDK on a low level and being paid by there components on the other hand. (Like moi) But if they want to continue to devalue my skills as a tool dev, I’ll be on the next train as the city is nuked.

To answer one more statement;

“why does Adobe think there is a large community willing to spend time (which equals money) doing what Adobe is no longer willing to do”

There are real tool developers that could make a good living selling components. If this was the case I, like others can fill the shoes of many Adobe employes. With less red tape, 10 times more bug fixes and feature enhancements could be possible.

In closing

As I stand here with over 8 years of Flash and Flex experience, not one person from Adobe or Spoon has contacted me (yeah I volunteered and am on the mailing list). This is why Flex is dead because babies can’t communicate and are dependent on mama which is Adobe. In a way it actually makes me feel sad, as the outsider from Meredith New Hampshire that doesn’t get invited to the “party” this time. On the other hand it actually may be a sign from the Universe that Java Android UI components are respected/valued with ROI and that is my destiny.

We will see.

Mike

PS These opinions are mine and Teoti Graphix, LLC shares these opinions happily. I am what I am.

The Callout container pops up above application content when initiated by some type of user interaction or programmatic trigger. The Callout is a subclass of the SkinnablePopUpContainer which implements the open() and close() aspects of the Callout container.

The Callout can be modal open(owner, true) or non modal open(owner, false).

What Is The Callout

The Callout is a SkinnablePopUpContainer that implements custom logic for the following;

• The callout’s arrowDirection – ArrowDirection.RIGHT, ArrowDirection.UP, ArrowDirection.LEFT, ArrowDirection.DOWN, ArrowDirection.NONE

Styling The Callout

contentBackgroundAppearance

The contentBackgroundAppearance style of the Callout allows the visual appearance of the contentGroup to be framed by an inset, flat or none border.

NOTE: The red Rect background is to show the bounds of the contentGroup. Use the backgroundColor and backgroundAlpha to actually set the color of the background, you don’t add the Rect like I have below, it’s for explanation only.

inset

Note the beveled white border and top inset shadow on top of the contentGroup.

flat

Note the bevel is gone and the contentGroup is still masked by the cornerRadius of the Callout skin.

none

Note the inset and mask is not present, the contentGroup is displayed without any border frame.

Skinning The Callout

The Callout component uses the CalloutSkin class to create it’s skin parts based off of the MobileSkin. Skins based off the MobileSkin are a bit more complicated for new developers to wrap their heads around since they don’t follow the Spark MXML pattern for creating skins. The Callout skin is adjustable by creating a subclass and setting protected property values.

Protected Properties that can be adjusted

• dropShadowVisible:Boolean – Whether the drop shadow of the Callout is visible.
• useBackgroundGradient:Boolean – Whether the Callout adjusts the background gradient by a 15% lighten and 60% darken algorithm.
  • This brightness adjustment affects the backgroundColor style when set.
• contentCornerRadius:uint – Adjusts the corner radius of the contentBackgroundColor style mask mentioned above.
  • This property only applies to the inset and flat contentBackgroundAppearance style value.
• contentBackgroundInsetClass:Class – The Class used to render the inset and drop shadow show in the inset image above.
  • Default – spark.skins.mobile*.assets.CalloutContentBackground – this is an FXG asset.
• backgroundCornerRadius:Number – The corner radius of the backgroundColor style fill.
• frameThickness:Number – The thickness of the backgroundColor frame.
  • This is comparable to the contentGroup's padding from the edge of the Callout.
• borderColor:Number – The stroke color of the backgroundColor fill.
• borderThickness:Number – The thickness of the backgroundColor border frame.
• arrowWidth:Number – The width of the arrow skin part in the vertical direction and the height of the arrow skin part in the horizontal direction.
• arrowHeight:Number – The height of the arrow skin part in the horizontal direction and the width of the arrow skin part in the vertical direction.

A simple MyCalloutSkin override

In the code below, the non commented lines are the protected variables of the subclass that are affecting the MyCalloutSkin skin.

MXML

<s:Callout>
	<s:Rect width="100%" height="100%">
		<s:fill>
			<s:SolidColor color="#FF0000"/>
		</s:fill>
	</s:Rect>
	<s:VGroup paddingTop="5" paddingRight="5" paddingBottom="5" paddingLeft="5">
		<s:Label text="contentGroup"/>
	</s:VGroup>
</s:Callout>

CSS

s|Callout {
	contentBackgroundAppearance:none;
	skinClass:ClassReference("skins.MyCalloutSkin");
}

skins.MyCalloutSkin

package skins
{
 
import spark.skins.mobile.CalloutSkin;
 
public class MyCalloutSkin extends CalloutSkin
{
	public function MyCalloutSkin()
	{
		super();
 
		// assuming a 160 DPI for simplicity
		dropShadowVisible = false;
		useBackgroundGradient = false;
		//contentCornerRadius = 0;
		//contentBackgroundInsetClass = null;
		//backgroundCornerRadius = 20;
		frameThickness = 50;
		borderColor = 0xFFCC00;
		borderThickness = 10;
		arrowHeight = 15;
		//arrowWidth = 10;
	}
}
}

A simple MyCalloutSkin override of inset

In the code below, the non commented lines are the protected variables of the subclass that are affecting the MyCalloutSkin skin with an inset contentBackgroundAppearance style.

CSS

s|Callout {
	contentBackgroundAppearance:inset;
	skinClass:ClassReference("skins.MyCalloutSkin");
}

skins.MyCalloutSkin

package skins
{
 
import spark.skins.mobile.CalloutSkin;
 
public class MyCalloutSkin extends CalloutSkin
{
	public function MyCalloutSkin()
	{
		super();
 
		// assuming a 160 DPI for simplicity
		dropShadowVisible = false;
		useBackgroundGradient = true;
		//contentCornerRadius = 0;
		//contentBackgroundInsetClass = null;
		backgroundCornerRadius = 0;
		frameThickness = 50;
		borderColor = 0xFFCC00;
		borderThickness = 5;
		arrowHeight = 30;
		//arrowWidth = 10;
	}
}
}

Note:

• The useBackgroundGradient property is now true.
• The backgroundCornerRadius property is set to 0.
• The borderThickness property is now set to 5.
• The arrowHeight property is now set to 30.

You will also notice that the contentGroup has an inset border above it with a white border. This is the FXG asset mentioned above. The contentCornerRadius property relates to the actual corner radius used IN the FXG asset. The contentCornerRadius property matches the backgroundColor style’s inset mask to the DPI dependent FXG asset’s corner radius so the skin correctly masks the FXG inset resolution used.

Skinning the contentBackgroundInsetClass

You may be wondering if the FXG inset graphic is skinnable and the answer is yes. If you are new to skinning or FXG you would not be aware that FXG is compiled to native graphics and becomes a SpriteVisualElement during runtime. This means that any SpriteVisualElement can replace the default contentBackgroundInsetClass. Also note that if you choose to replace this class with your own implementation, you will need to supply DPI dependent versions if you plan on creating a DPI independent application.

CalloutInset.fxg

<Graphic version="2.0" xmlns="http://ns.adobe.com/fxg/2008"
	scaleGridLeft="6" scaleGridRight="294" 
	scaleGridTop="15" scaleGridBottom="194">
 
	<!-- invisible fix for scaling -->
	<Rect x="0" y="199" width="300" height="1">
		<fill>
			<SolidColor color="#ffffff" alpha="0"/>
		</fill>
	</Rect>
 
	<!-- Content Shading Top -->
	<Rect x="0" y="0" width="300" height="10"
			topLeftRadiusX="0" topLeftRadiusY="0"
			topRightRadiusX="0" topRightRadiusY="0">
		<fill>
			<LinearGradient rotation="90">
				<GradientEntry ratio="0" color="#000000" alpha="0.6"/>
				<GradientEntry ratio="0.5" color="#000000" alpha="0"/>
			</LinearGradient>
		</fill>
	</Rect>
 
	<!-- Content Highlight -->
	<Rect x="0.5" y="0.5" width="299" height="199" radiusX="0" radiusY="0">
		<stroke>
			<SolidColorStroke color="#FFCC00" alpha="0.8"	weight="2"/>
		</stroke>
	</Rect>
</Graphic>

skins.MyCalloutSkin

package skins
{
 
import spark.skins.mobile.CalloutSkin;
 
public class MyCalloutSkin extends CalloutSkin
{
	public function MyCalloutSkin()
	{
		super();
 
		// assuming a 160 DPI for simplicity
		dropShadowVisible = false;
		useBackgroundGradient = true;
		contentCornerRadius = 0;
		contentBackgroundInsetClass = CalloutInset;
		backgroundCornerRadius = 0;
		frameThickness = 50;
		borderColor = 0xFFCC00;
		borderThickness = 5;
		arrowHeight = 30;
		//arrowWidth = 10;
	}
}
}

Note that we now use the contentCornerRadius property to match up with the FXG radii which are now 0. The contentBackgroundInsetClass property is set to CalloutInset and the inset will now be used instead of the default defined in CalloutSkin.

Using a PNG background skin

Although the example below is rough and does not use 9 scale slicing, it does show that creating Bitmap backgrounds for the Callout is pretty simple based on what you want.

To get proper scaling and 9 scale, there is a little more work involved not covered in this example. Also, there might be logic that determines what png to use based on the arrow layout.

skins.MyCalloutSkin

package skins
{
 
import assets.CalloutInset;
 
import flash.display.DisplayObject;
 
import spark.skins.mobile.CalloutSkin;
 
public class MyCalloutSkin extends CalloutSkin
{
	[Embed(source="/assets/callout-background.png",
			scaleGridTop="44", scaleGridRight="85", scaleGridBottom="47", scaleGridLeft="16")]
	private var backgroundClass:Class;
 
	private var background:Object;
 
	public function MyCalloutSkin()
	{
		super();
 
		// assuming a 160 DPI for simplicity
		dropShadowVisible = false;
		useBackgroundGradient = true;
		contentCornerRadius = 0;
		contentBackgroundInsetClass = CalloutInset;
		backgroundCornerRadius = 0;
		frameThickness = 10;
		borderColor = 0xFFCC00;
		borderThickness = 0;
		//arrowHeight = 30;
		//arrowWidth = 10;
	}
 
	override protected function createChildren():void
	{
		// put the background behind everything
		background = new backgroundClass();
		addChild(DisplayObject(background));
 
		super.createChildren();
	}
 
	override protected function drawBackground(unscaledWidth:Number, unscaledHeight:Number):void
	{
		// create a simple png background using the superclass's layout frame logic
		var showBorder:Boolean = !isNaN(borderThickness);
		var borderWeight:Number = showBorder ? borderThickness : 0;
 
		// calculate the frame which the Bitmap will be positioned and sized to
		var frameX:Number = Math.floor(contentGroup.getLayoutBoundsX() - frameThickness) - (borderWeight / 2);
		var frameY:Number = Math.floor(contentGroup.getLayoutBoundsY() - frameThickness) - (borderWeight / 2);
		var frameWidth:Number = contentGroup.getLayoutBoundsWidth() + (frameThickness * 2) + borderWeight;
		var frameHeight:Number = contentGroup.getLayoutBoundsHeight() + (frameThickness * 2) + borderWeight;
 
		background.x = frameX;
		background.y = frameY;
		background.width = frameWidth
		background.height = frameHeight;
	}
}
}

As you can see the above image square is the callout-background.png and the Bitmap is sized and placed behind all layout assets.

Conclusion

The Callout component it quite easy to style basic. The styling gets more invloved when you want more dynamic styling than the inset background or any type of background that is not a gradient or stroked fill. I might actually set out to make a skin that is a little more user friendly for those that are looking to style with abit more CSS and are not to concerned about the impact of their application, for example maybe a tablet application.

Part 2 will focus more on the CalloutArrow placements, skinning and the CalloutButton implementation.

About the Author

Michael Schmalle has been developing Adobe Flex and the Flash Player since Flash version 5 (2002). He has numerous open source projects in ActionScript3 (including an ActionScript3 parser/lexer DOM for reading and writing AS3 source code) and Flex (user interface components). He has also been an active participant in the Flex community (just goolge him or Teoti Graphix, LLC) since 2004. He also realizes technologies change and is actively developing user interface components and applications on the Google Android mobile platform.

See Teoti Graphix. LLC.

GIT: https://github.com/teotigraphix

Twitter: http://twitter.com/TeotiGraphix/