Power without a manual

I am waiting for september before I buy an iPad to allow my brother to draw graphics for the game.
In the meanwhile I am fixing code bugs, rewriting components and adding new components into the mix.

It is taking me a while to get used to the power of association relationships. Everyone is more or less used to inheritance and containment relationships. Association relationships is not used very much at all even in high level languages. So its not like I can use the web to find out what oppertunities are available for me. I have to find them out one at a time.

Component C Extensions

Using Extensions in Component C makes it so easy to have separation of concerns.


Here is code how to start a specific application component:

- (void)viewDidLoad {

    [super viewDidLoad];

    

    /* Link application to ios view */

    UIAppComponent->pExtension = IOSViewComponent;

    /* Link ios view to engine */

    IOSViewComponent->pExtension = MyGameComponent;

    /* Start the application and set up the view handle */

    self.view = (id) IOSViewHandle(IOSViewCast(UIAppStart()));

}

The second line links the IOS platform specific implementation to the application engine.

The third line links the game component to the IOS platform.

The fourth line starts the application and links the view to the controller.

Neither the application component or the game  are aware of the platform it is running on.

And the platform does not know what game is running.

This is a separation of concerns and allows me to port code to run on the mac and then run it on the simulator without having to modify the game code itself in any way.

Note that the application component creates the object and does not need to be passed the platform or game to run. It all works behind the scenes and that is the way it should be done.

Great Progress

Hi,

As you can see by my source forge status, I have working on the Screens components for quite a while. I am playing around with a simple game for the iPhone to test and write new components. I have finished an initial version of the application but I still lack some good graphics that I need to import before I can publish it to the AppStore. It was written using only Component C components. The game is really simple but I just wanted something to try out to test the AppStore process.

I have uploaded all the components to source forge anyway as I progress.

Event notifications

I have been active on my ScreensOS project. I did another refactoring of the components and made it simpler to understand and easier to send notifications.

To register for an event:

CoreEventRegister(pObject, CoreNodeComponent, CORE_NODE_EVENT_MOVE, MyMoveCallback);

To send an event:

CoreEventNotify(pObject, CoreNodeComponent, CORE_NODE_EVENT_MOVE);

The advantage of this design is that each message is unique per component. No need to have selectors or string hashes. Each component just defines an enum of messages either public or private.

You can also send asynchronous messages using CoreEventNotifyAsync which doubles as a timer delay if the delayInMilliseconds parameter is non zero.

Xml first alpha works

Great! FileXml parser works combined with FileChunk and FileToken.

However there is a bug in detaching objects when inside a destroy handler message. I will work on this bug next.

I gave it a simple xhtml file and it parsed it successfully. I will do some more tests on different xml files to know that I can move on to the next set of components.

You can find always the latest package of components at:
https://sourceforge.net/projects/screensos/files/

Component Handlers

I saw a problem lurking which was the callback design for components. There was no way to know when an object was being destroyed unless the component sent a notification. The component could know that its instance is being destroyed but attached objects could not know.

I met this problem in FileToken where it wanted to point to an attached FileChunk instance but would not know if the FileChunk instance was destroyed.

I made a system-wide change. Before, components implemented specific callbacks for constructor, destructor and shutdown scenarios. Now a single handler can be set for each component in its initialization. The handler can receive messages from any component. The constructor, destructor and shutdown scenarios are now sent by CoreObject as messages to the component handler. But now there is a new message CORE_OBJECT_MESSAGE_DETACH which is sent to all attached objects when a object is being detached from it. This will be used by FileToken to know when FileChunk is being detached.

You can find the latest code collection at:
http://sourceforge.net/projects/screensos/files/screensos/packages_002.zip/download

When I hit a milestone, I will add a zip to the source forge files.