NSUserActivity results

In my viewController, I'm creating an NSUserActivity, attaching an CSSearchableItemAttributesSet, assigning the activity to the viewController's userActivity property, and then calling becomeCurrent on the activity as below:


NSUserActivity *userActivity = [[NSUserActivity alloc] initWithActivityType:activity.uniqueIdentifier];
CSSearchableItemAttributeSet *attribs = [self attributesForActivity:activity]; //sets title, contentDescription
userActivity.contentAttributeSet = attribs;
userActivity.eligibleForSearch = YES;
userActivity.eligibleForHandoff = YES;
userActivity.eligibleForPublicIndexing = YES;
self.userActivity = userActivity;
[self.userActivity becomeCurrent];


But nothing is showing up. I've tried running this on the simulator and on an iPhone 5 device, but nothing is happening. Can't see any log files to indicate anything is amiss.


If I use Core Spotlight and add the same item to the index, it shows up immediately on both device and simulator. Is the NSUserActivity integration not working yet?

Hey OblivioN. Actually your use is a bit different than why we're trying to use NSUserActivity in a loop (we just want shortcuts into major areas of the app).


For another very similar use to the one you described, we are using CSSearchableItem + CSSearchableIndex. We're using the following format for our Spotlight item IDs (since domainIdentifier on the CSSearchableItem isn't provided to willContinueActivity...which would be really helpful):


"<type_prefix>|<item_id>"


That lets us differentiate between different types of incoming items since they all come in with activity type CSSearchableItemActionType and no real further information. So if we were indexing recipes an item ID for us would look like:


"recipe|b948e24a-d33f-4d39-b97b-13c08cd2f414"


Then we look up b948e24a-d33f-4d39-b97b-13c08cd2f414 in the recipe database to pull out the rest of the information we need.


I imagine you could use a similar delimited encoding of your own devising to put the basic info you need at retrieval time in the ID.

Hello Jason,


Thank you very much for your suggestion. I still have some questions. When you mentioned "pull out from Database", you are talking about the local database in the client or your backend server? We were planning to call our backend to get all the information we need, but we saw in WWDC 2015 Search Api Seesion video, they suggested not to using any loading when showing the destination page when press search result. So that I was trying to find a way to avoid extra loading from our backend. I would except Apple provide some kinda of solution if they suggested that way.


Don't know if you guys are using backend server for that or not, Please let me know. If there is no other way to avoid the loader on resume, i would let my team know, so we can move foward with the easier solution. Wish pdm can give a more official answers on this part.


Thank you once again.

We're using a local SQLite DB for our Spotlight data, but I would do the same thing for the the data from our REST APIs we need to index.


I watched the same video and I interpreted their comments as meaning you don't want to pop-up a "Loading ..." interstitial while you grab the content. So my approach would be to:


1.) Store 3 or 4 of the crucial data fields in the index ID itself using a delimiter. That would allow me to present the detail view immediately and fill it with enough info to get the user started, while I loaded the rest of the data in the background and updated the detail view as it came in.

2.) Also, when you pull the content originally from the server, I would take the result and store it in a private NSURLCache instance (you could also use a SQLite database instead) used only for caching indexed records and set them with a very long expiration stored under a special URL like recipe://uuid. THEN index it with Spotlight. On retrieval I would immediately try to fill the detail view with content from the custom NSURLCache instance (recipe://uuid), and in the background fire off a web request to the API to pull the current data...then update it when it arrives (reindex it, update the cache too).


Combined you'd always have at least the minimum amount of data to show a user, and optimally all of the data when the cache has it, and then any staleness would be updated within a few seconds.


-J

So I FINALLY got it working. Here are a few comments


- setup your .plist as follows

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
  <string>com.stockswipe.stocksSwiped</string>
  <string>com.stockswipe.stocksViewed</string>
</array>
</plist>

- setup your function as follows

@available(iOS 9.0, *)
func createNSUserActivity(title: String, contentDescription: String, image: NSData?, uniqueIdentifier: String, domainIdentifier: String) {

    let attributeSet:CSSearchableItemAttributeSet = CSSearchableItemAttributeSet(itemContentType: kUTTypeImage as String)
    attributeSet.contentDescription = contentDescription
    attributeSet.thumbnailData = image

    let activity: NSUserActivity = NSUserActivity(activityType: domainIdentifier)
    activity.title = title
    activity.keywords = NSSet(array: [title, contentDescription]) as! Set<String>
    activity.userInfo = ["symbol": title]
    activity.contentAttributeSet = attributeSet

    activity.eligibleForSearch = true
    activity.eligibleForPublicIndexing = true
    activity.requiredUserInfoKeys = NSSet(array: ["title", "userInfo", "contentAttributeSet", "eligibleForSearch", "eligibleForPublicIndexing"]) as! Set<String>

    userActivityTest = activity
    activity.becomeCurrent()
}

important was to create var userActivityTest = activity which stores that activity.

NSUserActivity results
 
 
Q