View Single Post
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#330
Originally Posted by ruff View Post
This type afaik is used for internal mapping - to create a pin-like object from platform event, so that might need to keep. What we need to remove though is that part from blobdb where we assign icons based on the type (BlobDB::insertNotification) - maybe move it to notification - so that should be able to cast itself to the TimelineItem.
The enum I mentioned is just an incomplete copy of the resources section of the layout.json.auto, mapping icon names to integer ids. Katharine recommended that we use those URIs instead, and that file as the reference as they can be used by any pin source anyway.

Originally Posted by ruff View Post
Ideally platform integration layer should come up with proper json document and just feed it to the timeline engine. In that case we can remove of course all these proxy objects like notifications and calendar-events working purely with the timeine api to manage all kind of notifications. Or with raw TimelineItem - to avoid double conversion (for one-offs).
Yes, that sounds clean. I think it's best to stick with the JSON - it can be marshalled/unmarshalled by the TimelineItem itself. We'll have to see if the proxy objects can be removed - it would certainly be much easier to implement support for multiple actions in one place - the reminders need a dismissal.

All this is taking us further and further from RockWork though. My last merge request contained JS fixes for app compatibility that must affect them too, but it's been sitting there for almost a month. I had hoped to clean up and trickle the changes back as we went, but at this rate I'll have to hope for a re-merge in the future instead.
 

The Following 4 Users Say Thank You to abranson For This Useful Post: