Ambient-Oriented Programming

User Tools

Site Tools

Trace:
uf:application

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
uf:application [2008/09/05 11:52]
tvcutsem 		uf:application [2009/02/27 16:13]
alombide
Line 1: Line 1:
 ===== Applications ===== ===== Applications =====
  
-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.+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.
  
-Applications can: +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.
-  * Access a user's profile (but not change it?) +
-  * Access a user's flocks (but not change them?) +
-  * Create new flocks (and thus new proximities) +
-  * Add actions ("buttons") to the flock viewer (example: Guanotes can add a "Send Guanote" button to each flockr in a flock view) +
-  * Store their settings persistently +
-  * Be installed at runtime +
-  * Be copied to another flockr at runtime +
-  * Be minimized, stopped, paused, restarted?+
  
 The mobility requirement needs some thought in how we are going to structure applications: The mobility requirement needs some thought in how we are going to structure applications:
Line 18: Line 10:
  
 <note>How can applications communicate with one another? Directly through far refs to "remote application interfaces" or via a "facade" (the remote flockr that owns the remote application?</note> <note>How can applications communicate with one another? Directly through far refs to "remote application interfaces" or via a "facade" (the remote flockr that owns the remote application?</note>
 +
 +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.
 +
 +===== Local API =====
 +  * name()
 +  * owner()
 +  * registerApplicationListener(type, listener): registers a listener that listens for new applications of type type that appear in the network.
 +  * start(): does nothing if not overridden. Is called by the launcher.
 +  * pause(): does nothing if not overridden.
 +  * unpause(): does nothing if not overridden.
 +  * stop(): takes offline the application. Is called when the application is closed.
 +  * export(asType): exports the application such that other Flockr applications can discover it and interact with it.
 +
 +===== Remote API =====
 +  * name()
 +  * getOwnerAndProfile(): returns the remote interface to the application together with the profile of the Flockr that hosts it.
 +  
uf/application.txt · Last modified: 2009/11/18 14:41 by elisag

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki