TimescapeCompatibility: Events shown up

The TimescapeCompatibility (TC) module is common a SharedSource designed to map the events provided by the Timescape extension to the format understood by Historify.

To showcase the current state of TC a simple Timescape Extension was implemented, which generates a single event for the first contact in the user's address book.

Here are some screenshot of the extension running on a Sony Ericcson device.

With the help of the TC, the extension could also work on non-SE devices. The following screenshots demonstrate how the extension and the generated event are integrated to the environment of Historify.

Current limitations of the Timescape Compatibility module:
- Since Historify does not support events not addressed to contacts, only the events associated with a particular contact are shown.
- Timescape supports status updates, which function currently does not have an equivalent in Historify.
- TC could not be installed to Xperia devices due to conflicting content provider names.
- On non-SE devices, extensions must set the
<uses-library android:name="com.sonyericsson.eventstream_1" android:required="false" />
in their manifest, if not, the extension could not be installed on the device.

Timescape Compatibility: SampleTimescapeExtension

To test the capabilities of the Timescape-compatible SharedSource, a simple Timescape extension has been implemented. The following screenshot shows the extension running on the Xperia emulator provided by Sony Ericsson.

Historify alpha screenshots

The first alpha version of Historify containing core functionality is now ready for testing. The following screenshots guide you through the different views. You might compare them to the ones experienced on your device. As demo client apps you could use the also available LendMe and HelloSharedSource.

INTERACT_INTENT

A new Intent has been added for Sources and QuickPostSources to increase Historify's usability: with the INTERACT_INTENT, external applications could register their customized shortcuts to the timeline's 'Interact' menu. The showcase app LendMe uses this function to launch an Activity for adding new borrowed / lent items (see figure).

New layout for the Timeline

The Activity displaying the flow of events is intended to be the most frequently used view of the application, so it is top priority to make it user-friendly and well usable. To facilitate dealing with the events, a new layout has been developed (see figure 1). The aim of this post is to introduce the new functions. Note that the Timeline Activity is under development, so several elements described here are not fully implemented yet.

Fig.1. New timeline

As you might observe, the layout is divided into several regions. On the top is the action bar displaying the name of the contact and an easily accessible "..." menu, which contains shortcuts to the main functions of the application.

The next region, the "top panel" displays the avatars of the user and the contact as well as a button titled "h?". This button is for opening the timeline options popup window. By accessing this feature the user could configure source filters for a particular contact. In the previous version these filters were configurable in the Sources Activity. This Activity titled "my sources" has also been redesigned, and now is for configuring sources only (see figure 2).

Fig.2. Configure sources

The avatars on the panel are also touchable. Clicking the user's avatar launches the "my preferences" Activity where the user can provide a custom image as her avatar. Clicking the contact's avatar opens a menu where will be shortcuts for creating new events for the different sources (e.g. call the contact, create a new entry in LendMe, write a message on Facebook). External applications could provide an Intent to launch their customized activity for that purpose (e.g LendMe could launch an activity for adding a new entry where the contact field is already filled with the selected contact's name).

Since the top panel occupies relatively large portion of the screen, the timeline options window also contains a button for hiding the panel. If the panel is not shown, the h! symbol on the actionbar becames touchable. Clicking on it opens the so called h-menu, where the functions of the top panel are accessible via menu elements. The h-menu also provides an option for restoring the top panel to its original state. When hiding the panel, a tooltip message informs the user about this feature (see figure 3).

Fig.3. Message about restoring the top panel

Finally, the last region is for displaying the events, similar to the previous version of the application. Since the bubbles are not always the best way to display large ammount of information, the style of the timeline will be configurable in the "my preferences": the user could choose between the "Bubbles" and the "Rows" theme.

New layout for Contacts

The new layout of the ContactsActivity includes the action bar with the search function, which could help the user find a particular Contact she's looking for.

New welcome screen

As part of the UI improvements of Historify, a new welcome screen has been added (see Figure). This view includes the first version of the action bar (temporary without any functionality), a list of recently contacted people as well as links to the "Contacts", "Favorites", "Sources" options available in the previous version. The next task is to rewrite the UI of these screens, too.

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.