New Object Storage

OK, Here we go again...

My latest evolution of the object storage is as follows:

Each object can contain an instance per component.

This means that a markup object can contain the following instances:

UIMarkup - Html markup instance for display

FSHtml - Html parser instance

FSXml - Xml parser instance

FSFile - File stream instance

The idea is that the markup object is also a markup object, also an xhtml file, also an xml file, also a file stream and so on.

These components are attached at run-time to an object and there are no rules on attachment.

You create an object using CoreObjectNew, retrieve an instance using CoreObjectInstance, destroy an object using CoreOjectFree and store a handle to an object/instance using CoreObjectStore.

Here are the prototypes:

bool CoreObjectNew(CoreObject ** ppObject);

bool CoreObjectFree(CoreObject ** ppObject);

bool CoreObjectInstance(CoreObject * pObject, CORE_OBJECT_CALLBACK callback, uint32_t size, void ** ppInstance);

bool CoreObjectStore(CoreObject ** ppLocation, CoreObject * pObject);

Its a lot to swallow but once you understand it, its very easy to use.

The object does not contain the instances, the object is an instance. You can just cast any instance directly to a CoreObject pointer. To cast an object to a component you use the component's cast function like this:

UIElement * pElement;

CoreObject * pObject;

CoreObjectNew(&pObject);

UIElementCast(pObject, &pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

You can also use the shorthand New method on a component as follows:

UIElement * pElement;

UIElementNew(&pElement);

UIElementMove(pElement, 50, 50);

UIElementResize(pElement, 100, 120);

UIElementShow(pElement, true);

The advantage of this design is that each component does only what it needs to and allows objects to be passed freely between components. Each component can access only its own instance on an object so there is complete data hiding.

I have finished writing the object storage and I am now going to start working on UIElement which deals with drawing to the UIDisplay component. I know that previous demos were slow, so I am seeing what I can do about baking drawing performance directly into the new design.

If you have any questions, ask away...

To answer currently know questions:

1. I will be testing the code on the PalmOS simulator, if I found that I have a valid code base (a.k.a demo code) I will try get my hands on a PalmOS device to test it out. So yes, there will be a platform dependent code base for PalmOS.

2. I don't know when Screens will be released, my curse is that I am a perfectionist and feel that there is no point releasing just another middle ware if I have nothing unique to show. I have a rule that if some code is hard to write, the design is probably wrong. So far that has been the #1 reason for all the rewrites over the years.

3. The drawing model for Screens is like a markup model, you create elements, fill in thier properties and the display draws them by itself. This is like the WPF model, not like the GDI model in windows.

4. I don't know if Screens will be ported to Linux/MacOS, but I don't see any problems doing so in the future. The platform dependencies are a minimum. If I get passed the previous demo I showed last april, then I will be buying a Mac for porting purposes to the iPod touch.

Enjoy!