Smartt Code

Tuesday, May 29, 2012

Back in the day when C was the only kid in town, there was a default namespace. This global default namespace is what I would argue was the primitive Java package. Packages are a way of dividing up code; not only for visual organization but functional organization. There is no way to know that com.packageOne.myClass's toString() method could be different from com.packageTwo.myClass's toString() method without that com.whatever coming before it.

With the advent of C++, the standard namespace is std, and many C++ programmers use the line using namespace std to declare the standard namespace as std. std contains functions such as cout and others. The developer, however, can create a namespace called myStd and define a completely DIFFERENT cout function and have no clashes.

How do we do this wonderful piece of programming? Below is an example a header file containing a bunch of defined namespaces:

The above code defines four different namespaces; each namespace contains the same function definition, but the returned char * for each function is different. It is this simple to make a namespace, by the way. Below, I present my main implementation:

Notice that I define the same Captain namespace again at the top, and define a function in it. C++ is smart enough to recognize that both of these functions are in the same namespace, Captain. This is powerful, because it lets you create multiple .cpp or .h files that share the same namespace (like classes that share the same package in Java). The namespaces are referenced directly, and the scope resolution operation (::) is used to get reference to those methods. Notice that I omit the using namespace std and opted to call its functions directly. If I wanted to, I could have used using nsmespace Captain and for the Captain::function calls, I could have just called them without using the scope resolution operator

Lastly, here is the output:

Namespaces are something that C++ developers should take advantage of. They can make large projects much cleaner. Note, however, that you should never, ever, ever have a program contain std::cin, because buffer overflow is one of the easiest way for hackers to exploit your program.

Tuesday, May 22, 2012

In my young days (not too long ago mind you), I started out with C++. I have always had a fondness for the language, despite the simplicity and support for Java. I wanted to write a simple post, so I decided to make a cute little interface and implement it in C++. C++ does not have actual interfaces like Java; however, a careful programmer can create pure virtual classes that can behave like interfaces. Implementing classes have the responsibility of overriding those virtual functions so that they are meaningful.
To implement the interface, the sub class would have to be an extension. In the land of Java, multiple inheritance is so frowned upon that the language prevents the developer from even doing it; C++ doesn't have such a restriction. Therefore, one can follow the same design patterns in Java (if they are careful).

A Brief Demonstration

In C++, virtual functions can allow late binding. This means that I can create classes that are implementations of the interface and later assign those instances to function arguments or pointers of type IMyInterface. The following code set will demonstrate that:

The above class is a standard C++ class called IMyInterface. Clearly, it is labeled as an interface. There is only one function defined in the class, using the keyword virtual. It returns a type of char *, which is kind of like a String (for this example, I wanted to avoid as much of the STL as possible, despite the fact that I declare it as my default namespace at the top of the page).

The following code samples are implementations of that interface (in reality, extensions of a class):

The first code snippet has some useless traffic, but notice that it does override the virtual function. The latter class has no excessive traffic, and overrides the virtual function. The following is the run-time snippet that I am going to execute:

The first two lines create our instances of the implementations of IMyInterface; both are separate instances of their respective types, but are sub classes of their common parent type.

The third line calls a function that accepts a point to an IMyInterface instance. This function calls the interface method IMyInterface::returnContent(). At execution time, late binding will occur calling the instance's implementations version of the function.

The third line passes anotherImpl into the function.

myThirdClass is not a type of IMyInterface *. Therefore, I pass in an address reference using the ampersand operator. This address reference will serve as the pointer to the instance myThirdClass.

I added a statement to hold up execution of the code so that I can get a print-screen of the execution:

When developing C++, keeping little tricks like the above in mind can save quite a bit of code. Don't fear the pointer, embrace the pointer (since all Java developers do, implicitly).

Friday, May 18, 2012

As a bit of fun, I decided to create my own flex button bar component. This button bar component is designed for implementation with any type of Flex button; but not only that, it can accept images or other types of IVisualElements as buttons. The following explains the implementation of the code. This button bar can be used in web, desktop, and mobile Flex applications.

The Interfaces

Two interfaces are defined for this little library project. IButtonBar should be clear enough to understand. It defines the underlying characters of my bar. I give the user the ability to set the height and width of the buttons, as well as the skin class for the buttons.

package com.bars.interfaces {
import mx.collections.ListCollectionView;
/**
* Interface for ButtonBars. This defines a generic set of properties that are expected.
* @author Charles
*/
public interface IButtonBar {
/**
* Used for button rendering. At a minimum, this should contain some sort of data object that
* has a label property or a property defined in <code>IButtonBar::labelField</code> for a label
* and an option skinClass property for button skin rendering.
* @param list
*/
function set dataProvider(list:ListCollectionView):void;
/**
* Get a reference to the dataProvider.
* @return
*/
function get dataProvider():ListCollectionView;
/**
* Sets the selected index of the last button.
* @param index
*/
function set selectedIndex(index:int):void;
/**
* Index of the last clicked button or set index.
* @return
*/
function get selectedIndex():int;
/**
* Return the content associated to the button.
* @return
*/
function get selectedItem():Object;
/**
* The object property in the data provider that is to be label for the button.
* Implementors of this interface should have the default value be "label"
* @param value
*/
function set labelField(value:String):void;
/**
* The object property designated for the button label.
* @return
*/
function get labelField():String;
/**
* The height for each of the buttons.
* @param value
*/
function set buttonHeight(value:Number):void;
/**
* The height for each of the buttons.
* @param return
*/
function get buttonHeight():Number;
/**
* The width for each of the buttons.
* @param value
*/
function set buttonWidth(value:Number):void;
/**
* The width for each of the buttons.
* @param return
*/
function get buttonWidth():Number;
/**
* Add the class reference for the button skins.
* @param value
* @return
*/
function set skinClass(value:Class):void;
/**
* Get the class reference for the skin.
* @return
*/
function get skinClass():Class;
}
}

The second interface is IButtonFactory. This interface defines a single method to that is intended for the creation of IVisualElements. Buttons implement the IVisualElement interface, but many other components implement that interface. The importance of this factory interface will be reveal later.

Button Factories

IButtonFactory components are used in the implementation of the IButtonBar; thus, I will cover the two implementations I have created for this demonstration. These factories are simple enough and won't require much explanation:

Both classes make buttons, the first a typical spark button and the latter a radio button. Properties such as height, width, and label as well as the style skinClass are set. The key about this factory is that it returns an IVisualElement. Therefore, this factory interface can be used to create non-button components. Also notice that these button factories are singletons. There is no need to create multiple instances of this class, so I chose to make these factory immutable singletons that produce buttons. If the bar that uses this factory is implemented all over an application, there will only be one ButtonFactory and/or RadioButtonFactory used.

Implementation of the Button Bar

ButtonBarBase is, as its name-stake indicates, a base class implementation of the IButtonBar interface. The intent of this class is to be generic enough for sub-classes to use, and if needed, strategically override methods. Notice that this class extends Group; this is for layout support as well as IViewPort support. If a background is needed for this bar, it can be wrapped in a SkinnableContainer, which DOESN'T have IViewPort support. Below is the code in its entirety:

The constructor accepts an argument of type IButtonFactory; this is the principal component used for button creation. It also initializes an internal data provider array collection as well as add a FlexEvent.CREATION_COMPLETE event to the class. The reason why this creation complete event is added is to prevent component drawing until all of the component parameters had a chance to be set.

The dataProvider method relies on the isCreated state. This state exists so that the component is not needlessly redrawn (an optimization). The dataProvider is set into a protected class variable, and if the component is created, the redrawComponentButtons method will be called so that the component can be reconstructed. Also notice that an event listener is added to the passed in ListCollectionView; this event will notify this object that dataProvider has changed, which will also order the redrawing of this component.

Setting the selected index will do one of three things:

If the index set in is the current index and not -1, the function does nothing.

If the index set in is not -1 and different, then the selectedItem is updated and a change event is dispatched.

If the index set in is -1 and different, then the selectedItem is set to null and a change event is dispatched.

The change event does two things: objects composing this view component will be notified that there is a change, and the selectedItem getter method will be called to update components that bind to the selectedItem getter. The selectedIndex getter also behaves identically, except instead of returning the content associated to the button, it returns the index of that content.

Button height and width setting is a bindable feature. Both the buttonHeight setter and the buttonWidth setter will update each button's width and height, dispatch an event that causes a binding to the height and width getters, and can be listened for in objects using this object. I use a generic method setButtonProperty to change the height and width properties..

redrawComponentButtons is used as both a listener function and something to be called by the class. This function tears down the internal dataprovider by removing the created buttons events. This is done to prevent memory leaks. This method calls constructView.

constructView builds the component. This is called when the data provider value is set when the component's creation complete event has already been called, or when the component's creation complete event is called. This method processes either an XMLListCollection or an ArrayCollection of objects. The labelField property is used to fetch the appropriate label from the content provided, defaulting to "label" for the label field. Also notice the use of the button factory in this component. This button factory will actually create the components, eliminating the need for subclasses to have to override this method for their own buttons.

addComponentsAndRedraw adds the elements to this object, and invalidated the size of the component and the display list.

The clickHandler
handles button clicking. It uses the internal data provider to match the button that was clicked; and if there is a match, the selectedItem and selectedIndex are updated. Appropriate events are dispatched because of this. This is the only method is a genuine candidate for override in subclasses.

The beauty of this base class is that is does all of the work. This will be shown below...

MobileButtonBar

The MobileButtonBar is a subclass of ButtonBarBase. The whole class is as follows:

Notice that the constructor doesn't have any parameters, and that the ButtonFactory instance is passed in to the base class. This is a simple and clean example of the power of the base class implementation.

MobileRadioButtonBar

This implementation of the ButtonBarBase required an override of the clickHandler method; however, most of the implementation is left to the parent class. Notice that this uses the RadioButtonFactory instance.

Wednesday, May 2, 2012

Using Flex 4 skins, a single GUI component does not need to be extended to change appearance. If the developer creates a clever underlying object extending either the SkinnableContainer or SkinnableComponent Flex components, a highly extensible and easy to use visual component can be created. Demonstrated in this post is something I like to call a "Fancy Component", which demonstrates how a single underlying component can be reused with different skins.

The first code snippet is the definition of the FancyComponent object, which is an extension of the Flex SkinnableContainer. There are three SkinParts defined, all of which are required to render this component. The skin parts are s:Image, s:TextArea, and s:Button. Pay attention to the names of these variables, as they will be important later on.

The FancyComponent overrides a function of the parent called partAdded. This is the principal function responsible for adding skin parts to this container. After calling the parent implementation, notice that I use if-else logic to see if the incoming skin part is one of the parts I have defined. Also notice that if it is a part that I have defined, that I am doing something to it: for the image I am setting its source, for the textArea I am setting its parameter textFlow, and for the closeButton I am setting label and adding a MouseEvent listener to it. The class has public variables for setting those values set in the partAdded function (imgSrc, msgText, and closeButtonLabel respectively).

Skinning isn't the only thing occurring the FancyComponent. In the constructor, I added a FlexEvent to this object to listen for the creationComplete event. When the event fires, this object will remove the event and set up a fade effect on the object. When the closeButton is clicked, the whole container will begin to fade away. Overriden is the effectFinished function, with special handling to remove the closeButton's event listener and to dispatch an event called closeMe. The event is defined as metadata above the class declaration; this allows implementing objects to explicitly assign functions (like a button's click parameter when defining it in mxml).

With the underlying component defined, skins are now created. Below are two different skins. Notice that there are common features to each of the skins:

Each component contains a spark group with id contentGroup.

Do you remember the skin part variable names? Within the contentGroup, I have image, textArea, and closeButton as ids for their respective components in the FancyComponent object (s:Image, s:TextArea, s:Button). When the skin is rendered, partAdded in FancyComponent will be called and each of these mxml components will have their appropriate attributes set.

Notice that the skins are different, and that they are simple and free of any implementation details. The implementation details are handled by the FancyComponent. Therefore, the developer can use this same FancyComponent in different ways by laying out differently the image, textArea, and closeButton components.

The last step is to implement the FancyComponent. Below is mxml that does this. Since we have defined required SkinParts in FancyComponent, the MINIMUM requirement for any skin assigned to the FancyComponent would be those components. Also, the FancyComponent cannot be rendered without a skin that implements those SkinParts.

Implementation

<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx" xmlns:components="com.charles.components.*" backgroundColor="#000000"><fx:Script><![CDATA[import com.charles.assets.Assets;import mx.controls.Alert;]]></fx:Script><fx:Declarations><!-- Place non-visual elements (e.g., services, value objects) here --></fx:Declarations><s:layout><s:VerticalLayout/></s:layout><components:FancyComponent width="300" height="300" imgSrc="{Assets.exclaim}" closeButtonText="Close Me!" skinClass="com.charles.skins.ModernSkin"><components:msgText><s:TextFlow><s:p>This is a <s:span fontWeight="bold">fancy</s:span> component. What is rather interesting is that thanks to the underlyingclass and skin class, you don't really care about anything but putting in theimportant information you desire.</s:p></s:TextFlow></components:msgText></components:FancyComponent><components:FancyComponent width="300" height="210" imgSrc="{Assets.exclaim}" closeButtonText="Close Me!" skinClass="com.charles.skins.AlternativeModernSkin" closeMe="{Alert.show('Notice this!', 'listening for closeMe');}"><components:msgText><s:TextFlow><s:p>This is a <s:span fontWeight="bold"> fancy </s:span> component. What is rather interesting is that thanks to the underlyingclass and skin class, you don't really care about anything but putting in theimportant information you desire.</s:p></s:TextFlow></components:msgText></components:FancyComponent>
</s:WindowedApplication>

This is only a small taste of what clever component development and skinning can do. If you find this appealing, you might want to experiment with SkinParts that aren't required ([SkinPart(required="false")]). This means that a single component can be multi-purposed both visually and functionally (for example, you can have a three buttoned component that optionally implements two of the buttons, therefore fade effects and other features such as text areas need be applied once, and the partAdded method will handle the cases where the non-required skin parts are present).