Xojo Blog Create a “Recent Items” Menu

21

That apple document I linked to above says what places are supposed to be “safe”

22

And the Xojo blog says to put them in the root of ApplicationData - that’s the issue?

Never mind - I see the other issues you point out, thanks.

23
  1. bad place to put them - create a dir for YOUR app (preferably named using the bundle ID or something)
  2. you may NOT be able to use them when your app is restarted IF those recent items are outside the locations your app has access to by default (see above)

So this “solution” wont work in general for App store apps

THATS the problem
It purports to solve a problem but it does so in a way that WONT work if you put your app in the app store

24

There are multiple workarounds, which I found by tearing apart an AppKit application and writing the appropriate code for Xojo. The two key functions use NSDocuments.

[NSDocumentController noteNewRecentDocument:<NSDocument>]

There is an alternative API to use a NSURL, but I have found using a NSDocument to be more reliable.

I think I now understand the problem with the Temporary folder, however you shouldn’t store application data here as the folder gets reset when the system reboots (and sometimes during the night while your Mac is meant to be sleeping.

There are some issues that my customers and I have experienced since 10.15.

  1. A permissions error can prevent apps from directly accessing the Temporary folder.
  2. Apple offer an atomic saving function, which creates a subfolder in the temporary folder (this works even when the application cannot directly access the temporary folder), however it does NOT clean up the subfolder.
  3. There is a 512 item limit per folder, when enough apps have used the Apple atomic solution enough times, the Temporary folder becomes inoperable until these files are deleted.

Reasons as to why Security-Scoped Bodgemarks are bad.

  1. They’re fragile and can break if the wind changes, my customers have experienced them all breaking with a minor OS update.
  2. When they break, you get nothing, no file name, no file path and sometimes no value in the error. So you must store meta-data with SSBs so you can at the very least tell the user the name of the file, that your application can now no longer open.
  3. You have 90 seconds to do what you need to do, after 90 seconds you lose access. If this happens enough times, you lose access to the application container (prefs and everything).
  4. They’re not compatible with lazy loading API. If you use SSBs to reference images, you must draw that picture somewhere before you release access to the file, otherwise some users simply get blank images.
  5. They’re not compatible with Xojo’s SQL database, AFAIK they will work with Apple’s CoreData.
  6. They’re expensive to create (i.e. slow).
  7. You must build a different solution to use content in your application’s bundle (clipart per say) or content within the system folder, they are only for use of User files. I’ve had apps rejected from the App Store which used SSBs to reference clipart in my application’s bundle.
25

thanks… too bad that doesn’t help without context… context which I have searched for… and the closest I could find was a “text processor” which gave no indication how to just “load the file into a string or array”… from what I can tell the use cases I would have, don’t lend themselves to NSDocumentController…

26

Of course I always make a subfolder for my app, doing otherwise would be very untidy to say the least.

Got it, and understand the displeasure with the blog post now. Should have been vetted and disclaimers included.

I’m more grateful than ever that I don’t have to write apps for The App Store :slight_smile:

2 Likes
27

For pure preferences, not recent items, I believe the cleanest way would be to use NSUserdefaults.

1 Like