BackgroundTaskBuilder Implementation #4831
Conversation
Signed-off-by: godlytalias <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
dev/WindowsAppRuntime_UniversalBGTaskDLL/WindowsAppRuntime_UniversalBGTaskDLL.vcxproj
Show resolved
Hide resolved
Signed-off-by: godlytalias <[email protected]>
Signed-off-by: godlytalias <[email protected]>
Signed-off-by: godlytalias <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: godlytalias <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
@mominshaikhdevs It will work in Medium IL & High IL apps. API would work in AppContainer apps as well, however the behavior of background task feature flow is to be tested. |
|
It will be best to have a proper test for them. otherwise we will be getting weird cases, where some portion of these APIs work in fine in MediumIL and HighIL but not in AppContainer. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
As we are approaching to the Experimental 1 release snap date, merging the PR. Please review and I will incorporate the comments in upcoming PRs. Thanks |
|
|
||
| winrt::Windows::ApplicationModel::Background::IBackgroundTask bgTask = nullptr; | ||
| winrt::hresult hr = CoCreateInstance(comClsId, nullptr, CLSCTX_LOCAL_SERVER, IID_IBackgroundTask, reinterpret_cast<void**>(&bgTask)); | ||
| bgTask.Run(taskInstance); |
There was a problem hiding this comment.
This is gonna AV if CoCreateInstance failed. and bgTask is still nullptr.
There was a problem hiding this comment.
Thanks @jlaanstra for the review, This method gets called from Broker Infrastructure and not handle any error results, Isn't it fine to throw exception here in that case? It will kill the backgroundtaskhost.exe process that gets created by broker infrastructure in that case.
Downside of silently handling the error would be that, broker infrastructure thinks that the task executed successfully, but the call haven't reached the application side.
There was a problem hiding this comment.
This won't throw an exception. You'll try to invoke a function on a nullptr which will terminate. If you want to throw you should throw the hr.
There was a problem hiding this comment.
Yes, It may not make much difference from BI side as the BI will just get to know that the backgroundtaskhost process got disconnected as it runs down. However I see that it is better to throw the right exception which may help during debugging.
API Spec : #4822
Issue : #3840
Added implementation to support the registration of Background Tasks with full trust COM Components. Current BackgroundTaskBuilder is designed for UWP applications and many of the Background Task triggers are not supported for full trust COM Components and are supported only to be registered with Windows Runtime components that is to be launched with backgroundtaskhost process. Due to this, WinAppSDK desktop applications won’t be able to directly register the full trust COM components to be launched with background task triggers and have to do workaround of including the Windows Runtime components in the project.
In this implementation, a BackgroundTaskBuilder API internally registers the entry point of background task as the UniversalBGTask runtime component which then forwards the call to the full trust COM component registered by the application.
Testing
Pending Action Items
Dependent Work Items