I am using the Simple.OData.Client library, and I need to be able to cancel a request before it completes. None of the async methods accept a Cancelation-Token. Am I missing something?
I just pushed to NuGet Simple.OData.Client pre-release 3.0.0-rc2 that adds support for cancellation tokens, so you can try it or wait until the final 3.0 is released (in a couple of weeks).
Related
We are currently using botframeworkAdapter.processActivityDirect to process MS Teams activity from webhook. However, botframeworkAdapter is deprecated and it is recommended to move to CloudAdapter.
I'm having trouble figuring out how to migrate to CloudAdapter because it seems like there isn't a way to process activity without http request and response object. We are processing activity asynchronously through job queues and workers so we don't have access to the original request.
BotframeworkAdapter allows this through processActivityDirect. Wondering if there is a way to achieve this somehow with CloudAdapter. I made a feature request in botbuilder-js repo but just asking in case anyone has ideas.
CloudAdapter.process seems to be the only way to process activity, which seems limited number of options compare to BotframeworkAdapter.
This issue is being addressed here - https://github.com/microsoft/botbuilder-js/issues/4349 where a PR has been raised to Add new method to expose same functionality as BotFrameworkAdapter.processActivityDirect.
Summary
I am using the Bot Framework REST API to create and update Microsoft Teams posts.
I have found that I can only update the last two posts of a conversation, but cannot find documentation that describes this restriction.
It is not possible to identify the failed updates from the API response, as the HTTP response code and body is always the same, regardless of whether the update works or not (200 with the id of the "updated" activity). I would expect the response to indicate the failure, and so this appears to be a Teams bug.
Detail
I can create conversations and create replies to conversations using the Bot Framework REST API without issue (using the create conversation and send to conversation endpoints). My problem arises if I try to update these messages.
Given a conversation that looks like this:
parent_message
|_ child_message_1
|_ child_message_2
|_ child_message_3
If I attempt to use the update activty endpoint to update each one of these messages, I observe that:
I can always update parent_message.
I can update child_message_3 and child_message_2, but not child_message_1. In each case the HTTP response is a successful HTTP response (200 response code, with a JSON body that contains the id of the updated message), regardless of whether the update succeeds or not.
If I add another message, child_message_4, then this will be updatable, but child_message_2 will no longer be updatable. I assume this is because now child_message_2 is no longer one of the last two messages.
I see the same behavior if another user adds messages to the conversation, ie. if a user were to make two posts to the conversation I would no longer be able to update any of my own child messages as they are no longer one of the last two messages.
My questions are:
Does anyone know if this restriction is by design? If so, can you point to some documentation on this?
Is it possible to determine when an update fails? As mentioned, the HTTP response always reports success so I'm unable to find a way to do this. Is this a bug in Teams?
Thanks for reporting this. We are able to repro this at our end and we are tracking it here: MicrosoftDocs/msteams-docs#2011
Please follow this issue for updates/progress/questions.
Updates: This is fixed.
This appears to be a bug, but I think the bug is different from what you think it is. Go ahead and "refresh" the conversation and you should see the updates in effect. If you're using the web app then you can refresh the page, but since you're probably using the desktop or mobile app then you could try switching to another conversation and back, or you might have to sign out and sign in again.
I have an app that uses in-app purchases (IAP), specifically auto-renewable subscriptions.
Occasionally it seems that, when a subscription automatically get renewed, the local receipt doesn't get updated automatically. As a result, checking locally if an active subscription is available results false. Performing the same validation remotely (using Apple servers) returns true.
How and when is the local stored receipt updated or is this something that can only be triggered manually? If so, does this need to happen using SKReceiptRefreshRequest or SKPaymentQueue's restoreCompletedTransactions? Based on Apple's documentation the former seems to be the way to go:
A request to refresh the receipt, which represents the user's transactions with your app.
Unfortunately, this fails, perhaps because it thinks there's noting to update? However there is: as the local receipt is outdated as it doesn't contain the renewed subscription status.
I want to ensure I'm doing things correctly and this behavior (that again happens occasionally) is not something on Apple's end.
Thanks for any feedback.
I am trying to launch glympse app by using an intent and receiving the information through broadcast. Is there any way that I will be notified about the events occurring like ticket removed, expired, updated etc?
There sure is.
We created a library project to make this easier for you. It can be found here: https://github.com/Glympse/glympse-app-sdk/tree/master/Android/GlympseIntentsLib
A sign-in is required to view these documents that might be helpful.
Tutorial: https://developer.glympse.com/Content/client/app/guides/Glympse_Intents_Tutorial.html
Reference Docs: https://developer.glympse.com/Content/client/app/guides/Glympse_Intents_Reference.html
Specifically, check out the method CreateGlympseParams.setCallbackAction(String). This will allow you to set an action which will be used to broadcast a message back to your app.
Another option is to use CreateGlympseParams.setEventsListener(EventsListener). With this method, you can supply an object that implements GlympseApp.EventsListener. Using this method, our library handles the broadcast under the covers and your object's methods will be invoked as the event occur.
I'm working with the the Release Candidate of Visual Studio 2010 using Wf4 to write a new workflow for approving resource requests. In my workflow, I would like for a request to expire after a few days if no approval has been made for the request. We did this in WF 3.5 (Visual Studio 2008) by adding a Delay timer into an EventDrivenActivity parallel to the EventDrivenActivity that was awaiting an approver to come and approve the request. If the Delay expired before an approval was made, the EventDrivenActivity would terminate the request. Does anyone know if there is a similar mechanism for doing this in WF4?
In WF4 this is done in the same way using a Pick activity. A Pick has multiple PickBranch children, each with a Trigger and an Action. The Trigger for each is executed and will contain the Delay, Receive or whatever else you are waiting for. The Action than contains whatever needs to be executed. Only the Action associated with the first Trigger to complete is executed, the other triggers will be canceled and the other actions skipped.