Development: Phase 2

This week starts the second major period of GSoC, so we decided to define goals for the forthcoming weeks. In the first half of the GSoC program, development has been focused on defining the necessary interfaces and algorithms that could deal with event sharing and aggregation. The main goal for the next phase is to make these functions better and implement several services based upon them. There are two aspects which should be considered:

• make Historify more useful for device owners.
• make the Bridge interface effective and easy to use for app developers.

To achieve these goals, the following tasks should be done:

a. Make Historify itself better and more usable:

• new UI including:
• action bar
• easy to reach functions.
• recent events and recently contacted persons.
• search and filter functions for contacts and events
• asynchronous event loading for improved response time
• further improvements:
• "Grand History" were all events are shown
• user's profile picture
• etc

b. Create a client app to showcase SharedSource functionality. This app will be a Facebook client which will use the site’s public API to collect interaction data (e.g. private messages, photo tagging) between the phone’s user and their contacts and store them in a local database. The collected data will be posted to Historify by registering a SharedSource. 

c. testing and finalizing the library and the showcase apps (LendMe and Facebook) as well as writing API docs and tutorials for developers. Provide SharedSource and QuickPost test tools for developers.

d. finalize the Timescape provider.

Can I QuickPost?

Writing an application that is intended to use the QuickPost interface, it is elementary to determine that Historify is installed and the Bridge is enabled on the user’s device. If Historify is not present in the current environment, it is unnecessary to call the QuickPost function or even display the UI elements used for QuickPosting. To make it easier for app developers, the new function canQuickPost() has been added to the client library. What it does, is a simple API call to determine that there is a Service able to handle the QUICK_POST Intent:

Intent intent = new Intent();
intent.setAction(Actions.ACTION_QUICK_POST);
List<ResolveInfo> info = context.getPackageManager().queryIntentServices(intent, PackageManager.MATCH_DEFAULT_ONLY);

LendMe showcases how to use this new function to find out that QuickPosting is possible. The application is able to change its functionality and to show/hide UI elements accordingly.

Ways of adding data

We are near the end of the second period of development, right before mid-term evaluation, and the first version of the different Intent interfaces are implemented and ready to use. The following diagram summarizes the functional elements and demonstrates the different approaches of adding event data to Historify.

The Bridge is set of helper classes for firing Intents (client side), and a Service that receives the requests (implemented in Historify’s application package) and able to handle the REGISTER_SOURCE and the QUICK_POST Intent actions. On the diagram, the client app A uses the REGISTER_SOURCE Intent to publish its EventProviderA provider as an external source of events, while app B - instead of storing and sharing the events - uses the QuickPost interface to reach the QucikPostsProvider via the Historify Bridge.

The client side of the bridge is available as a java library called historify-bridge.jar. The sample applications (HelloSharedSource, HelloQuickPost, LendMe) are already using the interface functions via this library.

At least, the Timescape Compatibility is a special Historify client for mapping the data of the Timescape Plugins into fields understood by Historify in order to achieve interoperability. It is under development at the moment.

EVENT_INTENT and CONFIG_INTENT

Two source attributes has been added to improve application interoperability:

EVENT_INTENT: The action of an Intent fired by Historify in case of the user selects an Event on the timeline. The action could be provided by a client when registering SharedSource or when posting via the QuickPost interface. Client applications could use this field to define a callback for handling the event click (e.g. displaying a detailed view of the event). To let the client know that which event has been clicked, a few attributes of the event (id, key, contact lookup key) are provided as Intent extras.

CONFIG_INTENT: The action of an Intent fired by Historify in case of the user selects the ‘More’ button of a Source on the source configuration Activity. Based on this field, the client application could define an Activity to let the user customize the behavior of the client (e.g. which type of data is shared) and integrate it seamlessly with the source settings of Historify.

There are already implemented examples demonstrate how to utilize these actions: The internal providers Messaging and Telephony define an EVENT_INTENT action which launches a dialog-styled Activity displaying the event data and a button to let the user get in touch with the contact (see Figure 1.). The LendMe showcase application defines the EVENT_ITENT as a callback to its ItemsActivity showing the Item associated with the Event.

Fig. 1: EVENT_INTENT handling by the internal sources.

The way how the CONFIG_INTENT works is observable by browsing the Sources (see Figure 2). If a source has a registered CONFIG_INTENT (currently QuickPosts and HelloSharedSource do that), an image button is shown, and by clicking on it the user could launch the Activity that handles that Intent. In case of the QuickPosts source, the config Activity currently displays a list of the applications that posted via the QuickPost interface (see Figure 3). HelloSharedSource’s config Activity is the main Activity of the application.

Fig. 2: Sources with a CONFIG_INTENT display a 'More' image button.

Fig. 3: CONFIG_INTENT of the QuickPosts provider launches an internal activity.

Handling icons of sources and events

On the timeline (and on the source settings activity) small icons are used to identify the different sources and/or event. These icons could come from various sources (content uri, client application's app icon, default source icon).

Now Historify handles these different situations by defining the following fields:

- A Source could define an icon_uri field, which is a URI identifying the icon drawable associated with that source. Client applications could provide this value while registering their SharedSource. If no icon_uri has been provided by the client, Historify uses the client app's launcher icon.

- In case of certain Sources it might be necessary to use different icons for each event on the timelime. For example, QuickPost is a special source that stores Events from different applications, so it might be useful to display the icon provided by the caller application instead of the default QuickPost icon. To realize scenarios like this, the new icon_loading_strategy field has been added to the sources table, which could be set to useSourceIcon (default) or useEventIcon.

- If the icon loading strategy is set to useEventIcon, the icon shown on the timeline is not loaded from the Source's icon_uri field, but the Event's icon_uri field. So providers that define custom icons for each timelime event (like the QuickPost provider) could provide a value associated with the particular event instead of the source.

Based on these attributes, timeline icons could be fully customized, as shown on the figure below.

The first event is provided by the HelloSharedSource external source (launcher icon is used), while the second one is provided by the internal QuickPost provider (the icon of the LendMe app is used, since the post came from that application).

QuickPost use case demo

Finished developing the functional demo of  LendMe.

LedMe is lending recorder application in which the user could keep record of her borrowed / lent belongings and also able to send generated threatening reminder messages to ask the contact to return the item she borrowed.

The aim was to build an application that actually uses the Historify QuickPost interface, it's kind of a demonstrational app. The events which are posted are the start and the end of a lending session. See screenshots, they are self-explanatory.

Hello, QuickPost!

Now Historify supports the second method of information sharing: QuickPost. This method provides a simple and easy-to-use interface for 3rd party app developers: there’s no need to register any receivers or providers like in case of SharedSources, since the event data is posted via a single intent call fired by the HistorifyBridge helper class and handled by the BridgeService.

The posted events are stored in an internal event provider of Historify (QuickPostsProvider) which shall be handled as any other internal providers.

To test the QuickPost function, a simple demo (HelloQuickPost) app is available which posts events to the timeline of a user-specified contact.

What to do in the remaining 2 weeks of this development period?

-          Basic lending recorder app to demonstrate the use cases of QuickPost

-          Review the different interfaces, check consistency, create client library (.jar)

-          Improve Historify’s functionality (source configuration, detailed event info, refreshing UI as new data is posted, etc.)

-          Create a special SharedSource for managing the data of Timescape extensions.