mariakleiner
commented
5 years ago Some technical details here:
Manifest Modalities are declared in the particle spec, for example: https://github.com/PolymerLabs/arcs/blob/master/particles/PipeApps/AndroidAutofill.arcs#L20 As far as Runtime is concerned these are just strings, so you can just specify one without any special support being needed. There is some logic however for ui-rendering-particles within the same recipe should have consistent modalities (non empty intersection, because in theory particle could list multiple modalities it supports) - otherwise the recipe is considered unresolved (and I’m afraid there is no good error message for this - something i need to fix).
Particle implementation
Here is a JS particle output method that emits the rendering content:
https://github.com/PolymerLabs/arcs/blob/master/src/runtime/particle.ts#L279
For example, a dummy autofill particle (used in the prototype) which emits the autofill candidate as its rendering content:
https://github.com/PolymerLabs/arcs/blob/master/particles/PipeApps/source/DummyAutofillResponder.js#L54
Similarly there is an output method in the Java particle base class:
https://github.com/PolymerLabs/arcs/blob/master/src/javaharness/java/arcs/api/ParticleBase.java#L13
(I don’t have usage examples right now in the repository, but i made some of these in various demos, so it should work).
Renderers Each modality there needs to be a Renderer class, implementing UiRenderer API: https://github.com/PolymerLabs/arcs/blob/master/src/javaharness/java/arcs/api/UiRenderer.java
The renderer needs to be registered in a UiBroker. If the Renderer is within the Arcs Service, add it to the RendersModule: https://github.com/PolymerLabs/arcs/blob/master/src/javaharness/java/arcs/demo/ui/RenderersModule.java#L25 If it is part of another Android service, use the AIDL registerRenderer method: https://github.com/PolymerLabs/arcs/blob/master/src/javaharness/java/arcs/android/api/IArcsService.aidl#L25 In the prototype we are using the AndroidUiBroker (which is an implementation of UiBroker interface) to register the renderer, for example: https://github.com/PolymerLabs/arcs/blob/master/src/javaharness/java/arcs/android/demo/service/ArcsAutofillService.java#L43
Sorry, the renderers registration is currently suboptimal, there is a refactoring happening soon.
Please, ping me if you have any questions.
As requested by @yuangu-google, here's a specification of what we would like for the notification surface.
Background
The end product is for a Kotlin WASM and JS particles to be able to create Android notifications in the "Android prototype" codebase. This should happen by creating and registering a Renderer for a new modality ('notification' ?). A particle should be able to create a notification by specifying that modality, consuming a slot and rendering into that slot. @mmandlis and @sjmiles are the folks to ask questions regarding that design and support in implementation.
Stage 1 (P0): Read Only Notification
The notification should use a standard system template. The particle can provide following attributes:
Small icon is a required attribute, but I recommend starting with an icon that is constant for all notifications and specified in the renderer. We don't have the handling of images figured out yet in Arcs, so allowing overriding the icon per-particle on Android may be tricky. If you do find that specifying an Android resource from a particle is feasible, we can add small icon to the above list.
We explicitly don't target initially:
We can add above at a later stage if we find there is demand for that.
We'll need to create a notification channel. I think one channel for Arcs is fine, and giving it a name "Arcs" is ok for a start. We can put urgent priority as a default to trigger "heads-up" behaviour, which would be good for demoes. This can be overridden by the user.
Stage 2 (P1): Support for Notification Actions
We would like to make notifications more useful, to do that we will support:
Both tap and action buttons work in terms of pending intents - so there's an open question how to define a pending intent in Kotlin WASM (without android libraries presumably) and in JS. We can add an auto-cancel attribute to the list of attributes we support as well - it is useful with tap actions.
Intents can deep link into another app (e.g. contacts app to add a phone number from the context as a new contact), which is great, but we should also have a way for a notification tap or a button tap to be reflected as an Arcs UI Event. This will require a bit of design - I presume the Renderer component will be receiving the intent and forwarding the received information to the respective particle as a UI Event. @mmandlis said that UI Events are not yet wired through the system, so there's an opportunity for some E2E work that connects all the pieces.
We don't bother for now with the direct reply action or progress bars.
Stage 3 (P2): Updateable and cancellable notifications
The last bit is to make:
This may be easy if we track the particle that rendered through the stack, or it may require some extra plumbing - to be figured out.