Differences

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

--- uf:application [2008/09/05 11:39] – * tvcutsem
+++ uf:application [2009/11/18 14:41] (current) – adding elisag
@@ Line 1: / Line 1: @@
 ===== 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 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.
-Applications can:
+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).
-  * Access a user's profile (but not change it?)
-  * Access a user's flocks (but not change them?)
+===== Programmers Perspective =====
-  * Create new flocks (and thus new proximities)
+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.
-  * Store their settings persistently
-  * Be installed at runtime
+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.
-  * 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:
   * does the entire app. needs to be an isolate?
   * will we copy physical ''.at'' source files?
+<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.