bloland

I’m running into a tricky issue with the applications I build, and wonder if anyone can offer some advice. Sorry for the length of the preamble, but here goes:

My goal is to build apps that remember user settings - so when the user turns the volume down in a certain section, then closes and reopens the app, the new volume for that section is automatically retained.

The problem is that apps don’t seem to allow internal information to be updated. For example if coll data is stored internally (Save Data With Patcher is checked), any changes made to it (with nsub followed by a write message, for example) are lost when the app is closed and reopened.

My solution has been to create patches that load _external_ text files (with default values) into coll objects, then alter those values when the user changes the settings. This is great as long as Max can find the external text documents. I handle this by making sure they are in the same folder.

The new problem is with new security features apple has implemented. Without getting too far into the woods with those details, suffice to say it’s rather complicated to assure that an app and a few text documents _actually_ end up in the same folder after download (try googling App Translocation) .

Has anyone else dealt with this successfully?

I’m on a Mac running Sierra, experimenting with Max 8 (though behavior seems the same in 6 and 7).

My solution has been to create patches that load _external_ text files (with default values) into coll objects, then alter those values when the user changes the settings. This is great as long as Max can find the external text documents. I handle this by making sure they are in the same folder. 

I’m running into a tricky issue with the applications I build, and wonder if anyone can offer some advice. Sorry for the length of the pream

storing-data-in-an-app-max-8

Hi, I have also run in to this situation. In the end I ended up replacing up all coll-s object with the dict object which can be included in the pattrstorage system. But obviously I have to rewrite quite a lot the coll system to the dict system. Now all the new patches that I made are mostly built with the dict option instead of coll.

Hi, I have also run in to this situation. In the end I ended up replacing up all coll-s object with the dict object which can be included in the pattrstorage system.  But obviously I have to rewrite quite a lot the coll system to the dict system.  Now all the new patches that I made are mostly built with the dict option instead of coll. 

Yeah, I've been planning to switch over to using dict and pattr, despite the required rewrites.

The problem is the same though, no? Dict uses a similar format: either embed the data within the dict object, or save it as an external data file. This leaves me with the same problems. I either:

- embed the data, then create an app, in which case I can't save changes to that data at all, or

- save the data as an external file, which can be changed, but needs to be in the same folder as my app.

Or am I missing something specific about dict?

Yeah, I've been planning to switch over to using dict and pattr, despite the required rewrites.
The problem is the same though, no? Dict uses a similar format: either embed the data within the dict object, or save it as an external data file. This leaves me with the same problems. I either:
- embed the data, then create an app, in which case I can't save changes to that data at all, or
- save the data as an external file, which can be changed, but needs to be in the same folder as my app.

The data file (either for coll or dict) can be saved in different locations than the folder in which the app is.

The first strategy is to store it inside the app folder structure. For instance the Resources folder is a good candidate. This requires knowing the full path to the file upon opening or saving, i.e. knowing where the app is located.

Another option is to create a folder in the User/Library/Application Support folder and store the files there as preferences. Through the shell object creation of folders is possible.

The data file (either for coll or dict) can be saved in different locations than the folder in which the app is.

The first strategy is to store it inside the app folder structure. For instance the Resources folder is a good candidate. This requires knowing the full path to the file upon opening or saving, i.e. knowing where the app is located.

Ok, thank you, I think that did the trick. I _had_ tried storing the data file inside the app (in Resources), but had failed to supply a specific path to the write command when altering that file. As a result a new data file was created in the same folder as the app, which led to the same problem.

Took me a minute to figure out how to report the path of an app (; max sendapppath receive-object-name), but now all seems to be functioning well.

I do like your first option best as it is entirely self contained and mobile should the user switch machines.

Storing data in an App (Max 8)