Reunion Push Notifications API spec #458
Conversation
ghost
added
the
hulumane
changed the title
|
👋 @hulumane, I see this is marked [draft], are you looking for feedback yet? |
|
@riverar Yes we are looking for active feedback. There are still a few loose ends with the GetActivationArgs pattern that needs to be discussed. |
|
@andrewleader @danielayala94 @sharath2727 Please note the first Public API draft |
|
Where does this work land, in terms of the Roadmap (https://github.com/microsoft/ProjectReunion/blob/main/docs/roadmap.md) timeline? |
@riverar - we are tentatively targeting this to land by the end of 2021. As soon as our plans become more solidified, we will get it added to the official roadmap. Of course, this is not final yet, but we plan to keep the community updated with this. |
| ## Registration of the Push Activator for Win32 (Inproc) | ||
| If a Win32 app needs to subscribe to Push triggers inproc, the code in Main would follow the pattern below: | ||
| * The Registration will take in a CLSID of the COM server as part of the Activator setup. The registration API will simply be a thin wrapper around the BackgroundInfra WinRT APIs and abstract away the COM details from the developer. | ||
| * The app will query ApplifeCycle APIs to retrieve an ActivationKind. (Note: This is covered in a seperate AppLifeCycle API spec.) |
There was a problem hiding this comment.
@andreww-msft FYI. Will need a link to your spec to show how we are addressing the new Activation Kinds as discussed in yesterday's meetup. Thanks
|
@ShawnSteele This needs to go through the Public API review process |
andrewleader
added
the
area-Notifications
andrewleader
changed the title
|
|
||
| // Check to see if the WinMain activation is due to a Push Activator | ||
| // Note: This API is currently not present in Reunion but will be included as part of the AppLifecycle Public API spec. | ||
| auto activation = AppLifecycle::Activation(); |
There was a problem hiding this comment.
https://osgwiki.com/wiki/Marshal-By-Value_for_ActivatedEventArgs describes the "by value" cases of activation. that works for designs that don't require references.
There was a problem hiding this comment.
@ChrisGuzak Externals can't see this resource, can you provide an excerpt?
There was a problem hiding this comment.
The document describes a common way for in-Windows types to declare "I know how to marshal myself using a valueset rather that COM's marshal-by-reference default." The type dumps its data into a ValueSet which is itself serialized into a binary blob and squirted to the other process where it's reconstituted into a fresh in-target-process instance of the original type. It lets us reduce IPCs between platform and app components for many of the ...ActivatedEventArgs types since many of those are just "here's a string/uri/number/etc to act on." Currently it relies on an undocumented handshake between COM and the marshaling system, which is why it's limited to Windows.* types.
We look forward to bringing this to the platform SDK since it's of general use, especially in the work that @aeloros is doing around activation.
| auto pushArgs = args.as<IPushNotificationActivatedEventArgs>(); | ||
|
|
||
| // Call TakeDeferral to ensure that code runs in low power | ||
| pushArgs.GetDeferral(); |
There was a problem hiding this comment.
RECOMMEND: Follow standard deferral pattern from API design patterns repo
|
|
||
| runtimeclass ChannelResult | ||
| { | ||
| ChannelResult( |
There was a problem hiding this comment.
DISCUSSION: Start of a pattern - allowing apps to create types they can use for testing or driving their own state machines.
hulumane
force-pushed
the
user/pavanh/push-spec
branch
from
d53965d to
4bd173c
Compare
…w Channel wrapper runtimeclass
|
|
||
| **Push Channels**: All the Push APIs are dependent on the caller app having an identity at the minimal. However, even packaged Win32 apps that have an identity cannot use our Public APIs to subscribe to Push Channels because they may not be store provisioned. Sideloaded UWPs that aren't store distributed have exactly the same problem. | ||
| **Push Channels**: All the Push APIs are dependent on the caller app having an identity at the minimal. <br/> |
There was a problem hiding this comment.
"having an identity." (drop "at the minimal.
hulumane
dismissed stale reviews from andrewleader and DrusTheAxe
The concern with winrt::guid was addressed. The new c++ winrt nuget packages allow us to pass in GUID strings when constructing a guid.
No description provided.