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!

Update: 26 and learning

Hi anyone who still checks this blog, I now I have not updated for a long time. I moved to Jerusalem with my family, had a lot of work to do at my full time job and my son started kindergarden. Alot has changed since I first started Screens is 2001. Screens is not dead, actually on the contrary... I never stopped working on Screens and have in fact tested a few of my ideas at work and they have worked really well. I am very happy with the component object model and do plan to start writing code again. I don't have my lifedrive anymore but the code should be usefull no matter where it runs. Once I start getting into coding again specifically for Screens I will update you and write some editorials... I have alot of them down the pipeline, so keep tuned... Zakai Hamilton

Random Thoughts

1. Don't rely on a compiler extension when doing platform indepedent code

You will never know when your code will hit a compiler you did not anticipate. Keep it cleanand simpleand don't try to be smart. Consistency is key in writing alot of components. Avoid using tricks because their value will decrease over time because you will lose track of the tricks you used.

2. Using a 'better' language (C++, C#) will not reduce the real complexity which is the number of components you need to write and thier dependencies and relationships.

3. Consistency in API function and component naming is sometimes more important than the implementation itself since the implementation can be refactored while an API mostly cannot be changed.

Just a few things that come to mind when writing code for Screens. I am still active on the project and spend between 1-2 hours a day on Screens now thanks to my HP Mini-Note 2133.

I have not got to the graphics code just yet, but I am very close to try it out.