This little write up might be a fun read. Hey, it’s Sunday. Why not? > On May 9, 2021, at 4:27 PM, Sandor Szatmari <admin.szatmari....@gmail.com> > wrote: > > Alex, > >> On May 9, 2021, at 15:15, Steve Mykytyn via Cocoa-dev >> <cocoa-dev@lists.apple.com> wrote: >> >> You're creating your own problem here. > > Agreed, If you have control. I would either make all top level objects > arrays, or dictionaries. If your writing the plist and its a dict, wrap it > in an array, or vice versa, embed arrays in a dict with meta data keys, as > suggested. Of course, if you have the flexibility to do this. > > If not, I’d create a single point of access to read the plists and have logic > inside to handle the non-homogeneous top level objects and return a > consistent data structure for consumption. > > Sandor
Thanks Sandor. What’s awesome about this list is just how many collective brain cells we all have with all of the experience here. It’s probably worth a little explanation and the end result might actually be a little fun (did I say it’s fun? Because it’s fun.) example of my rumored white label approach and a very very lightweight example of config based app architecture that supports this white label thingie. It’s actually for clients who say “we are codey” but really aren’t in the way that they need to be. They are solid, they are smart. But not as Xcode engineers and that’s why my crew is here. I’m creating a standard flavor of two config file types that will let them use to create new apps. They are really good people and have a clue, but based on my experience, I need to over plan to make sure things are handled predictably. We made a little app engine that they can adjust and tweak. Some of the apps are using array data structures and other are using dictionary ones because the main screen has different navigation methods to load data that they can click on. The apps need to be able to be duplicated, republished and tweaked. My architecture is to map the name of the app to the name of a folder reference that automatically lists all files dropped into its folder. It will then list if the expected folder and file exists and if it doesn’t, it will list what’s there. In the config file, this is what is read and what populates the main screen’s nav item and when selected, the tapped on index is what is displayed in the next screen. This allows the client to 1. Duplicate the app and rename it. 2. Add an assets catalog with the proper items in it for icons and such. 3. Add a folder within the “App Specific Assets and Data” folder that is the name of their new app. 4. Add a plist to the “App Specific Assets and Data” folder : the name of their app : appName " - config data.plist” file. 5. Populate the plist with the data for their new app. Run the new app and it’s all brand new. Cool? There will be a few parse classes based on the result of the data, but at least now, I can still make it generic enough to load it into the app and store it with the help that everyone’s shared with me today. Cheers all! Alex Zavatone > >> If you are controlling what the >> configuration plist is, make it a dictionary at the top level with three >> keys and entries: >> >> idString - something that confirms to you that this is one of yours >> array - the array you want in some cases >> dictionary - the dictionary you want in some cases. >> >> Then you deserialize it, confirm it's one of yours, and branch on which of >> the latter two keys is not null. >> >> This kind of situation can arise if you are configuring multiple apps out >> of the same code base. >> >> If you're not controlling the configuration plist, just use >> NSPropertyListSerialization as noted previously and branch on what you get. >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com >> >> This email sent to admin.szatmari....@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
