Feature request: Expose the currently indexing item to js

[hessius]

Currently the console outputs the currently indexing items directly in xcode, would be great if this could be exposed in js as well, both for conditionals but also to be able to determine (and show) progress

[MarcoEidinger]

@hessius: I am curious: how many items do you plan to put into the index? A new function could be introduced to pull the info how many items are remaining to be indexed. I did such a change for a different plugin (unzip a folder and copy files ) as the activity was very time-intensive. I am not sure how time-intensive the indexing is. Therefore my question

[hessius]

@MarcoEidinger
I'm indexing a whole lot of items ;)
on a 5s with almost no storage (which should be about the slowest device still in popular use after this year's iPhone upgrade) this takes about five minutes, maybe a bit more, in the sim around 30 seconds. The indexing seems to go on in the background after closing the app but not very reliably and in my experience very slowly, therefore I'd prefer if users stayed in the app, but with no visual progress indication or visual cue that something is happening that's hard to reliably get the user to do (I do have a non-obscuring infinite progress bar, but those infinite ones are pesky, as a use you can't be sure somethings actually happening)

[MarcoEidinger]

The current used iOS API allows only a completionHandler which makes it difficult for the plugin to handle the feature request. Essentially the plugin would need to do introduce and handle a batch logic.

iOS offers batch processing an special API (see https://developer.apple.com/reference/corespotlight/cssearchableindex) but the plugin would need to take more responsibility (consider and protect concurrent access from multiple threads).

My current advise would be that the consumer of the plugin will call the setItems function with smaller data portion which comes down to batch handling on the consumer side.

@johanblomgren should judge as plugin owner

[hessius]

Smart! In my experience the completion handler is delayed a couple of seconds compared to what would be expected looking at the console output, if one were to split the items into 10 or 20 parts that would mean a whole lot of extra time. I'll have to test and see

[johanblomgren]

@MarcoEidinger Precisely - the plugin would need to take into consideration multithreaded access and it would introduce more complexity. Also, callbacks invoking JavaScript functions on the WebView will not be reliable if at all work when the app is running in the background (which may cause issues if one relied on such a callback to for example hide a spinner/progress bar). One could introduce another callback for reporting back current indexing progress when the app returns from the background.. but then again, we're introducing a lot of complexity.

However, I agree with @hessius that such a feature (i.e. continuous callbacks) would be helpful for reacting to indexing state. I'll see if I can investigate the delay you're mentioning - there should be none.