Sunday, June 19, 2005

Why should I use the kernel API?

So the kernel will be released soon but it wont have the user interface APIs, so why should you as a developer even consider the kernel API's? The kernel provides two key elements: The object storage and the thread functionality which are basicly interconnected. As a developer one of the key things we do is store data. This could be a document, temporary data such as proccessing or any data you manipulate with your application. With PalmOS you currently have four options: Dynamic Memory, Feature Memory, Records and Resources. All these API's are very low level and wont do much more than give you chunks of memory and allow you to read/write to them and resize them. Resources do allow you to tag each chunk with resource and typeIDs but nothing more. Screens Object storage provides you with the ability to store data in its structured form without having to parse it in into structures to manipulate it. Each object can be based on multiple types which are like classes if you are used to C++/# or Java programming. You get basicly most of the advantages of object oriented languages into C but Objects are persistent untill you remove them so you dont need to revert to byte streams when you want persistent storage. The multi-threading APIs allow you to split your code into multiple functions that run simutaniously. This is not pre-emptive multi-threading, its cooperative however you dont need to specify yield points because any Screens API call can yield, so its easier to code than cooperative but is not as robust as with pre-emptive multi-threading. Data comes in many forms and I feel that the object storage will satisfy your needs if you check it out. Because you can do the Screens API calls in your current PalmOS applications, its easy to improve your existing application instead of rewriting it. Remember that the kernel is free to use in your products without licencing and that there will be alot of documentation available and email support to help you with integration.

No comments: