Export / Import Charts…

…with a little help of Cascades Invokation Framework

Images of your charts are stored at the folder you defined from App – Settings, so you can easy send them to your friends or colleagues. But what about the data and all the properties and colors you set to create a good looking chart ?

This data is stored inside your APP’s sandbox, so it’s a safe place, but you cannot access it from other applications or File Manager.

The good news: I implemented an easy way to transfer the data without making it public visible.

If your friend doesn’t know about ‘ekkes Express Charts’ you can invite him / her easy from Home Page Action Bar via BBM.

Here’s the workflow if you want to send the data to a friend or colleague:

1. Exporting

Viewing or editing a single chart data you can export this one from Action Bar – Overflow menu:

Sending more then one chart data you can do a long-press on the List Page and select all the charts you want to export:

ekkes Express Charts will collect the data, create an attachment and open a predefined Message Composer:

Now if you click on a file with extension .eecimp ekkes Express Charts will be invoked 🙂

In your app you can detect if the app was launched by the user or if the app was invoked and then do what you want to do.

I told you that the data transfer was safe letting you data private. How is this done ?

Inside the application – sandbox all data is stored as JSON. (I wrote about using JSON a blog entry here)

If you take a look at the content of the .eecimp file you’ll see something like this:

{
"exportedCharts" : "AwPuJ1JzovCJXJ.....4os370QllfA=="
}

It’s a JSON, but I scrambled the content with a key known by my app. So your data is protected and my app, too because if someone creates a fake .eecimp file it will open the app, but I can simply detect that I have to ignore the content.

Over all you see: with a little help of Invokation Framework you can create smooth workflows – not only inside your app – also between two apps as I demonstrated here.

This was only the first part of using Invokation Framework inside ‘ekkes Express Charts’ – read more about invoking my app from BlackBerry EXPRESS or 3rd party apps here: (TBD)

You need a unique invoke-target id, the type (card.previewer or card.composer), the action (in this case OPEN and SHARE) and one or more mime-types. I have defined some targets: a card.previewer, a card.composer and “APPLICATION”. Cards will be integrated in clients workflow – APPLICATION will open the target Application itself.

Inside your target app you can test from where your application was launched:

The most important decision: I’m using different documents as QML Root: main.qml for the full-blown app launched from Invocation or from Homescreen and Uploadcard.xml if launched as Card embedded into another app (the client-app).

Why am I doing this ? If launched embedded I only need a small part of the application:

My tip: only instantiate what you need ! Always think about performance and memory-footprint ! This is also important if you plan to get a certification “Built for BlackBerry 10”

Using another root object as QML Document it looks much better:

If you’re providing more then one Card or you need different pages depending on the data you got from the client, then you can instantiate what you need lazy – but thats another story for a blog post.

Now I want to describe a sample workflow between two applications:

File Upload 2 ODS: the client app

OpenDataSpace: the target app

Both applications are available from BlackBerry AppWorld and the sources from Github – this should make it easy for you to follow.

The Client APP

File Upload 2 ODS is a simple App using Cascades FilePicker to browse files, select a file and the upload this file to the cloud. Instead of developing all the code by yourself you can use the UploadCard from OpenDataSpace.

The easiest way to get exactly what you need is to do a “bound invocation” – a bound invocation knows the target id where a unbound unvocation does a query and gets a list back for all targets providing something for a given mime-type.

To Invoke Card from the Client using a bound Invocation you can do it all from QML or you can do it from C++.

First step the user is doing: pick a file from FilePicker, then invoke the target app. (I will write another blog about the FilePicker, so we concentrate now on Invocation Framework)

This is the QML – way to embed a Card from target app:

InvokeActionItem {
id: shareAction
ActionBar.placement: ActionBarPlacement.OnBar
query {
// little trick: always use same mime type, because query needs a mime type
// ODS then takes a look at file path suffix and ignores the mime-type
mimeType: "image/png"
invokeActionId: "bb.action.OPEN"
invokeTargetId: "io.ods.bb10.card.upload.previewer"
}
onTriggered: {
// next trick: all properties from query are read-only
// but we can use the data, which is read-write to provide the URL
data = picker.selectedFile
}
},

We’re using an InvokeActionItem and provide the Action (OPEN) and the target id.

Tip: We cannot do a bound invocation from InvokeActionItem out-of-the-box because a query is used and a query always needs a mime-type. The trick is to provide a valid mime-type of the target together with the target id – then only one result will be found. Another trick: all query-parameters are read-only, so we cannot use the URI to provide the file path – we’re using the data and fill the value in onTriggered {}
Here’s the C++ way to invoke the target. In QML we’re using a normal ActionItem and call the C++ function:

Seemless Workflow

All Pages from the target are seamless integrated into the workflow 🙂
The User goes thru the Pages (provided by the Target App) and uploads the file to the cloud or he went back without uploading using the BACK Button or peeking over the threshold.

The Target App sends a ChildCardDone – signal and the client receives this in a slot. The signal includes a message with the reason and data, so you can check it easy and go on with the workflow or notify the user.

If you want to notify the UI (QML) you can send a Signal (cardSuccess / cardCanceled) where the Page is connected to.

You see: only less code is needed as glue code between the Invocation Framework and Target / Client APPs.

The best thing: the user doesn’t know that he used another app under the hood: the target app is invisible and the Card is embedded into the client app.

BTW: The Cascades FilePicker itself also uses the Invocation Framework: you’re getting a ChildCardDone Message with reason ‘save’ if the user selected a file and with reason ‘cancel’ if the user canceled. To make it easy to handle from the ChildCardDone I’m using the same reasons to let the client know what happened.