montanaflossco / flint Goto Github PK

Subsystems that want to participate in contextual logging need access to the loggers and this can be done with adding an argument for the loggers or context, but that is quite invasive to internal APIs.

We should be able to do something like this:

public func withContextualLogging(_ block: () -> Void) {
    let previousActionQueueLogger = action.queue.getSpecific(key: actionQueueLoggerKey)

    action.queue.setSpecific(key: actionQueueLoggerKey, value: request.context.logs.development)
    block()

    // Restore the previous context specific logger
    action.queue.setSpecific(key: actionQueueLoggerKey, value: previousActionQueueLogger)
}

... and add an @objc func FlintContextualLogger() -> Loggers? free function that ObjC can call to get the current logger.

The problem here is that it is never valid to do that even on a serial queue if you are not inside the withContextualLogging block, but this could be a good enough pattern.

With automatic activities, e.g. for a Document Open, we need to be able to cancel/resign the current activity when that is no longer the correct activity to advertise.

In this example it would be in the Document Close handling that we'd need to do this. Perhaps a convention of the form cancelsActivity = true would be enough, and that would be defined on the DocumentCloseAction.

However this may tie in with a bigger idea related to endsBreadcrumbTrail = true. Are these the same high level concept? If so maybe we just need a terminatesStack = true property, and we "do the right thing" for both?

This seems like a natural progression.

Add alert at startup to explain

This becomes useful if using Features and Actions to populate user-facing UIs, e.g. tool palettes, in-app purchase stores etc.

This would allow you to see logging from subsystems in place where the action execution occurs, making it much easier to tie things togather.

This would not be in time order, it would be in time order of action but within each action there'd be log entries from later in time, grouped by the action request ID. So you can see which later logging related to a given action via the contextual logger.

e.g. a multi-document app on macOS will only advertise one current activity, for the foremost window. When switching windows (activate) they may need to re-advertise their activity (research this in docs). It may be that multi-window paradigms retain but resign their current activity automatically and this is not a problem.

This also happens on iOS where if you switch away from the app and return, it is no longer advertising the current activity

At the moment the dispatcher will log if it takes too long to call completion, however we want to have some safeguard here to save people from forgetting to call completion, which is easily done.

So again look at returning a .longRunning outcome, which must be received quickly, and that will disable the detection of the missing completion, but we still expect it to call completion again later (we don't pass "longrunning" on to the caller") with failure or success.

The issue here is we capture prod and dev focus logs separately. Do we want to display (in Flint UI) and export these individually or in a combined view?

The restoration stuff is not propagated to Flint.continueActivity

This should return a structure containing the "executors" for each mapping, and Flint._registerURLMappings should iterate over these and register them

We don't want to spam observers on every single event. We should batch up rapid changes

It should be easy to disable action stack tracking if you're not interested in it as a feature, as it will just add overhead

It seems that a title is probably useful/required on all NSUserActivity instances so we should make this easy to do right by using if let titledInput = input as? Titled ... and pull the title from it so you don't have to implement prepare just for a Handoff/suggestion activity

We should be able to do this anywhere a feature is mentioned in the debug UIs.

Show them in a fixed font with word wrapping

The idea is all ancestor features of a feature must also be available, and we need to implement this. So essentially available = fullFeatureAncestry.reduce(true, { return $0 && $1.isAvailable == true }

We can probably do this with a generic constraint on some extra overloads on ActionSession and the two binding classes.

Using Input to pass in dependencies is not the greatest. The actions have static stateless perform but they need to access dependencies. Using singletons in Action impls makes them annoying to test.

So consider dependencies of type T:Any or similar on Action, and see if we can not have to specify that at all when not relevant

There is no debug output for NSUserActivity

Suggested by James Dempsey, this could be used to make features unavailable unless e.g. Photo Library and Camera permissions are granted to the app.

This seems simple enough, but we need to think about what we can do on the other side of it, and whether our checks for status would/should trigger a confirmation alert.

You may want to support Routes but not have them used for NSUserActivity.

When the activity is published we need it to be easy to clear the auto url (or add it only if needed after), and when performing the incoming activity, we need an API to extra whatever is needed to execute it if not using urls (important for retrofitting to existing apps)

See if we can make it read more like a story.

Even if subsystems use the contextual logger, they should still be able to supply their own scope or you won't know in the logs whether it is from "Networking" or "DB" etc.

For crash loggers to gather a report post-crash, we need these things to have been persisted to disk before the crash.

Go through all the actions and find those with handoff / other activity types that require registering in NSUserActivityTypes and list them for copying + pasting or similar.

That or we log them all in dev builds,