Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido
Accepted Solution

GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

I can't believe just how much of the invocation framework BlackBerry broke in OS 10.2. Several of my bound invocations were broken when 10.2.0.424 rolled out, but I thought I had everything working again by switching from using InvokeQuery to InvokeManager/InvokeRequest but I just noticed that one of my unbound invocations doesn't work right now either.

 

My app lets users share a web page title and URL with basically the same list of invoke targets as the BlackBerry browser does (i.e. BBM, text, email, NFC, etc.). Under BB10.0 and 10.1 this worked perfectly, but now I notice that with 10.2 the share selector page doesn't show any candidate targets. This is how my app was doing it:

 

    InvokeQuery* shareQuery = InvokeQuery::create().parent( this ).invokeActionId( "bb.action.SHARE" ).uri( "http://dummy" );
    this->shareAction = InvokeActionItem::create( shareQuery ).imageSource( QUrl( "asset:///images/action-share.png" ) ).title( tr( "Share Article" ) );
    success = QObject::connect( this->shareAction, SIGNAL(triggered()), this, SLOT(shareActionTriggeredHandler()) );
    ASSERT( success );
    this->addAction( this->shareAction, ActionBarPlacement::InOverflow );

...and the shareActionTriggeredHandler() slot looks like this:

 

void MyApp::shareActionTriggeredHandler() {
    QVariantMap metadata;
    metadata["subject"] = <subject string>;
    metadata["description"] = <url>;
    this->shareAction->setMetadata( metadata );
}

As I said, this worked properly right up until BB10.2. When triggered it used to show a long list of share targets, including all my email accounts, Remember, BBM, NFC, Text, etc., but now the share selector page just shows an empty list.

 

Unbound Share Targets

Based on feedback from a BlackBerry Development Advisor, it was determined that the culprit for the broken bound invocations was InvokeQuery, so I changed to using the InvokeManager/InvokeRequest method. To make things much easier to use I developed (and published on this board) an Invoker class that wrapped everything up neatly and included a Builder to make using it even simpler. This worked great for bound invocations, so I tried changing my unbound invocation to use it:

 

    ActionItem* shareAction = ActionItem::create().imageSource( QUrl( "asset:///images/action-share.png" ) ).title( tr( "Share Article" ) );
    success = QObject::connect( shareAction, SIGNAL(triggered()), this, SLOT(shareActionTriggeredHandler()) );
    ASSERT( success );
    actionSet->add( shareAction );

 

...and now the shareActionTriggeredHandler() slot looks like this:

 

void MyApp::shareActionTriggeredHandler() {
    QVariantMap metaData;
    metaData["subject"] = this->label->text();
    metaData["description"] = this->link;

    Invoker invoker;
    invoker.setAction( "bb.action.SHARE" );
    invoker.setMetaData( metaData );
    invoker.setUri( "http://dummy" );
    invoker.invoke();
}

With this code I no longer get an empty share target list. Instead I go straight to the "compose email" card, which is also not what is supposed to happen. It looks like unbound invocation in BB10.2 is not matching candidate targets properly with invocation.

 

Does anyone know another way of doing an unbound invocation that still works as expected under BB10.2?



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

Ok, I solved it. For some obscure reason there are many different ways to do invocations, which is a good thing since when BlackBerry breaks one or more of them there are others you can try. I rewrote my invocation to use Invocation explicitly rather than through InvokeActionItem:

 

ActionItem* shareAction = ActionItem::create().imageSource( QUrl( "asset:///images/action-share.png" ) ).title( tr( "Share Article" ) );
success = QObject::connect( shareAction, SIGNAL(triggered()), this, SLOT(shareActionTriggeredHandler()) );
ASSERT( success );
actionSet->add( shareAction );

 

void MyApp::shareActionTriggeredHandler() {

    QVariantMap metaData;
    metadata["subject"] = <subject string>;
    metadata["description"] = <url>;

    InvokeQuery* shareQuery = InvokeQuery::create().parent( this ).invokeActionId( "bb.action.SHARE" ).uri( "http://dummy" ).metadata( metaData );
    Invocation* invocation = Invocation::create( shareQuery ).parent( this );
    QObject::connect( invocation, SIGNAL(armed()), this, SLOT(shareArmed()) );
}

void MyApp::shareArmed() {
    qobject_cast<Invocation*>( sender() )->trigger( "bb.action.SHARE" );
}

...and now the share works the way it used to and displays all the same share target candidates that the BlackBerry browser does.

 

It is amazing just how badly BlackBerry borked invocations with BB10.2. The only invocation in my app I DIDN'T need to change was the one that opens BlackBerry World on my app page so users can leave a review.



Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Retired
Posts: 249
Registered: ‎07-14-2008
My Device: Not Specified

Re: GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

I used the same invoke parameters as you did in your query but I used my good old invokeclient sample from github. It worked fine when I selected "platform invoke" from the overflow menu of the app. Can you do the same and let me know if that works for you?

 

https://github.com/blackberry/Cascades-Samples/tree/master/invokeclient

 

Shadid

Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

If you look closely at my second post where I said I managed to get it working, you will see that I did indeed do it the same way as in your sample code, and yes, it did work.

 

The issue here though is that the method I used in my first post used to work fine under OS 10.0 and 10.1, but stopped working under 10.2. I don't know what was altered in the invocation code for OS 10.2, but a quick perusal of this board shows that it broke the invocation logic of many, many apps and left developers scrambling for workarounds.

 


shaque wrote:

I used the same invoke parameters as you did in your query but I used my good old invokeclient sample from github. It worked fine when I selected "platform invoke" from the overflow menu of the app. Can you do the same and let me know if that works for you?

 

https://github.com/blackberry/Cascades-Samples/tree/master/invokeclient

 

Shadid






Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

Ok, I THOUGHT I had solved it, and I did, but only for BB10.2. Using this new method it is now BROKEN on 10.0 and 10.1! Now when I run my app on <BB10.2 the share invocation doesn't happen at all. So, to summarize:

 

  • Using my old method the share invocation triggers Ok on all versions of BB10, but on 10.2 the list of candidate targets is empty.
  • Using the new method the list of share targets is restored, BUT...
  • Using the new method the invocation fails completely on BB10.0 and 10.1.

I don't know what BlackBerry is playing at with invocations. For such a key service on an OS that stresses the "flow" between applications, invocations is a labryinthine cesspool. There are at least three different poorly documented ways to implement every type of invocation, but every new major OS update breaks the previous working methods. THIS HAS TO BE FIXED!

 

You can't tout the wonderful flowing UI of BlackBerry 10 if you keep changing the way the most basic element of that navigation works without informing developers, and if you keep breaking formerly working apps every time you bump up the minor version number. C'mon BlackBerry, get your act together on invocations!

 


greenmr wrote:

Ok, I solved it. For some obscure reason there are many different ways to do invocations, which is a good thing since when BlackBerry breaks one or more of them there are others you can try. I rewrote my invocation to use Invocation explicitly rather than through InvokeActionItem:

 

ActionItem* shareAction = ActionItem::create().imageSource( QUrl( "asset:///images/action-share.png" ) ).title( tr( "Share Article" ) );
success = QObject::connect( shareAction, SIGNAL(triggered()), this, SLOT(shareActionTriggeredHandler()) );
ASSERT( success );
actionSet->add( shareAction );

 

void MyApp::shareActionTriggeredHandler() {

    QVariantMap metaData;
    metadata["subject"] = <subject string>;
    metadata["description"] = <url>;

    InvokeQuery* shareQuery = InvokeQuery::create().parent( this ).invokeActionId( "bb.action.SHARE" ).uri( "http://dummy" ).metadata( metaData );
    Invocation* invocation = Invocation::create( shareQuery ).parent( this );
    QObject::connect( invocation, SIGNAL(armed()), this, SLOT(shareArmed()) );
}

void MyApp::shareArmed() {
    qobject_cast<Invocation*>( sender() )->trigger( "bb.action.SHARE" );
}

...and now the share works the way it used to and displays all the same share target candidates that the BlackBerry browser does.

 

It is amazing just how badly BlackBerry borked invocations with BB10.2. The only invocation in my app I DIDN'T need to change was the one that opens BlackBerry World on my app page so users can leave a review.






Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.
Developer
Posts: 1,178
Registered: ‎03-20-2013
My Device: Red LE Developer Z10
My Carrier: Fido

Re: GRRRR: _UNBOUND_ invocations broken in BB10.2 as well

UPDATE: Finally got it right. With slightly changed code it works in all versions of BB10. When I changed to the "new" invocation methond I was doing this:

 

void MyPage::shareActionTriggeredHandler() {
    QVariantMap metaData;
    metaData["subject"] = <subject>;
    metaData["description"] = <description>;

    InvokeQuery* shareQuery = InvokeQuery::create().parent( this ).invokeActionId( "bb.action.SHARE" ).uri( "http://dummy" ).metadata( metaData );
    Invocation* invocation = Invocation::create( shareQuery ).parent( this ).onArmed( this, SLOT(shareArmed()) );
}

void MyPage::shareArmed() {
    Invocation* invocation = qobject_cast<Invocation*>( sender() );
    invocation->trigger( "bb.action.SHARE" );
    invocation->deleteLater();
}

This works fine with BB10.0 and 10.1, but the invocation wasn't happening at all under 10.2. Turns out that the deleteLater() was the culprit. It seems that timing must be slightly different under 10.2 and it is not safe to call deleteLater() in the armed() signal handler. Doing it this way works under all OS versions:

 

void MyPage::shareActionTriggeredHandler() {
    bool success;
    Q_UNUSED( success )

    QVariantMap metaData;
    metaData["subject"] = <subject>;
    metaData["description"] = <description>;

    InvokeQuery* shareQuery = InvokeQuery::create().parent( this ).invokeActionId( "bb.action.SHARE" ).uri( "http://dummy" ).metadata( metaData );
    Invocation* invocation = Invocation::create( shareQuery ).parent( this ).onArmed( this, SLOT(shareArmed()) );
    success = QObject::connect( invocation, SIGNAL(finished()), invocation, SLOT(deleteLater()) );
    Q_ASSERT( success );
}

void MyPage::shareArmed() {
    Invocation* invocation = qobject_cast<Invocation*>( sender() );
    invocation->trigger( "bb.action.SHARE" );
}

Note that now the deleteLater() is executed in response to the finished() signal from the invocation. I guess the first way under BB10.2 the invocation was getting deleted before the armed() signal handler had a chance to fire. Since the documentation explicitly states that the finished() signal indicates that it is safe to call deleteLater(), it was probably just a fluke that it worked Ok under BB10.0 and 10.1.

 

Note also that in the second code sample above, the armed() signal is attached to the shareArmed() slot with the onArmed() builder clause, but the finished() signal is attached to deleteLater() with QObject::connect() instead. This is because you CANNOT do this:

 

Invocation* invocation = Invocation::create().onFinished( invocation, SLOT(deleteLater()) );

That won't work because the "invocation" in the first parameter of onFinished() doesn't actually exist until AFTER this line finishes executing.

 

Hope this helps others avoid the traps I fell into.


greenmr wrote:

Ok, I THOUGHT I had solved it, and I did, but only for BB10.2. Using this new method it is now BROKEN on 10.0 and 10.1! Now when I run my app on <BB10.2 the share invocation doesn't happen at all. So, to summarize:

 

  • Using my old method the share invocation triggers Ok on all versions of BB10, but on 10.2 the list of candidate targets is empty.
  • Using the new method the list of share targets is restored, BUT...
  • Using the new method the invocation fails completely on BB10.0 and 10.1.

I don't know what BlackBerry is playing at with invocations. For such a key service on an OS that stresses the "flow" between applications, invocations is a labryinthine cesspool. There are at least three different poorly documented ways to implement every type of invocation, but every new major OS update breaks the previous working methods. THIS HAS TO BE FIXED!

 

You can't tout the wonderful flowing UI of BlackBerry 10 if you keep changing the way the most basic element of that navigation works without informing developers, and if you keep breaking formerly working apps every time you bump up the minor version number. C'mon BlackBerry, get your act together on invocations!

 


greenmr wrote:

Ok, I solved it. For some obscure reason there are many different ways to do invocations, which is a good thing since when BlackBerry breaks one or more of them there are others you can try. I rewrote my invocation to use Invocation explicitly rather than through InvokeActionItem:


 





Developer of Built for BlackBerry certified multiFEED RSS/Atom feed reader and aggregator.  multiFEED Icon

Play nice: Clicking Like Button on posts that helped you not only encourages others to continue sharing their experience, but also improves your own rating on this board. Also, don't forget to accept a post if it solves your problem or answers your question.