My favorites | Sign in
Project Home Downloads Wiki Issues
READ-ONLY: This project has been archived. For more information see this post.
Search
for
APILayers  
The API within jarvar.
Featured
Updated Mar 29, 2012 by jackokring

The API is within 6 packages, they are divided by use.

  • uk.co.peopleandroid.jarvar - The main Foundation and Function API classes.
  • uk.co.peopleandroid.jarvar.sl - The ScriptLanguage implementation classes.
  • uk.co.peopleandroid.jarvar.prims - Is used by ScriptLanguage.
  • uk.co.peopleandroid.jarvar.platform - Has the abstract classes and implemetor must override to make a platform package. These are Audio, Video, Keys and Storage.
  • uk.co.peopleandroid.jarvar.functions - Various functions including J2ME support Mith for maths.
  • uk.co.peopleandroid.jarvar.internals - Various internals which would clutter the main API packages.

The main API package contains 4 programming layers described below.

Foundation API

The foundation API is the hardware abstraction from the many platforms supported. It provides a common way of programming the various platforms. It includes Classes that ensure this.

Script API

The script API allows a custom language to be made for interaction with a program. This is a flexible way of dealing with user macro automation. Editing the behavior of jarvar programs by the user is not just possible, but is encouraged. Scripting is a users right. The classes are visible in the main package so that useful data structures may be reused, and so that a deeper interaction with ScriptLanguage is possible. You are not advised to add or change any subclasses of Prim unless the Script API can not achieve your purpose. You are also not advised to alter any classes in the SL package ever.

It is not essential to learn this API to use ScriptLanguage, as the Compiler class provides access to the VirtualMachine. You can safely ignore this API if you do not want to extend ScriptLanguage.

Function API

The function API allows direct jarvar access to many of the Functions which are available through Scripting, as the Functions exist the methods are made public. This API layer is different from the internals package, as internals are designed for the one purpose of constructing jarvar and ScriptLanguage, and not generally useful for other things. They are static methods, of useful classes.

Final API

As the name says, it's the last one. Consider recording of sound or video, which will end up as a file, and so can really be done by a file selection instead of complex embedded media handling, and so it's not in this API. In fact this API is empty. No suggestions will be accepted. Some may think this a tad too restrictive, but cross platform API design would be hindered by any 'but not on this platform' functionality, or not, as the case could well have been.

If you wish to extend anything you write, using any API you have access to, then feel free. But, it will not become part of this cross platform API. Such an environmental dependence is not in this API. Maybe you could consider writing an extension API for a custom platform which greatly simplifies the platform specific features people want, and I'm sure it will be used.

There is no restriction on using the jarver API within specific platform applications. Using the API is not considered to be modifying the API for the purposes of the BSD license. It thus maybe freely distributable with any open or closed code, as long as the API has not been edited or added to.

Powered by Google Project Hosting