Applications need to be explicitly added to a Flockr before they can be used. From then on the flockr sees the application in a launch screen (similar to the Home screen on the Apple iPhone). Running applications have controlled access to flockr information via the framework such as the flockr profile. This is a common functionality found in a range of social networking applications.
In addition, Urbiflock applications have access to the user's flocks and the flockrs who have installed the same application on their devices. Every application has two different interfaces which allows it to interact with the framework: a local and a remote one. This distinction between local and remote interfaces has been introduced for reasons of security: methods defined in the local interface can only be called by local objects or the flockr, while other flockr's can only invoke methods defined in the application's remote interface. This allows the application to enable local objects, which can be trusted, to call different operations on the application than remote objects (e.g. changing the application's settings).
Applications are simply containers for some named pieces of code that can make use of the features of the framework, that can be easily launched from the UrbiFlock application launcher, and that can be shared over the network.
The most important property of an application in Urbiflock is that it should be easy to share it with your friends. Applications should thus be mobile entities that can be passed to your friends and received from your friends. This is still TODO.
The mobility requirement needs some thought in how we are going to structure applications:
.at
source files?Every application should implement at least a start() method. This method should launch the application. It is called by the application launcher when the application button is clicked.