Re: How do you handle reading a plist if it may be an array or a dictionary?
> On 9 May 2021, at 2:29 pm, Alex Zavatone wrote: > >> It sounds like you might need to rethink your data model a bit. > > That’s what I’m trying to do! : D I meant the internal data model, as in how your program represents the data in memory and in respect of what API it provides to its clients, irrespective of the input file format. We would need to know more about the particulars of your app in order to offer more meaningful advice in that regard. > This might be a fun case for a dict or array wrapper class for my dict or > array plist reader thanks to your tips. My inclination is to suggest that's probably not a good approach, because it feels like you'd be reacting to a symptom of the data model design, rather than improving the design. >> No, you have it backwards. That method is useful if you want to create a >> plist file out of an array, dictionary, etc. To do the opposite, use >> propertyListWithData:…. > > Huh? + (NSData *)dataWithPropertyList:(id)plist returns an NSData object. Right. That's not what you need; you want to do the reverse. > Isn’t the propertyListWithData the one that creates a property list out of > NSData? Not in the typical meaning of the phrase. It's a poorly-named method. It returns a "property list object" (the important part being "object"), by which it means an object of a class which is suitable for representing a property list (such as an array, dictionary, etc.). -ben ___ 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
Re: How do you handle reading a plist if it may be an array or a dictionary?
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 > wrote: > > Alex, > >> On May 9, 2021, at 15:15, Steve Mykytyn via Cocoa-dev >> 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
Re: How do you handle reading a plist if it may be an array or a dictionary?
> On May 9, 2021, at 2:15 PM, Steve Mykytyn wrote: > > You're creating your own problem here. If you are controlling what the > configuration plist is, make it a dictionary at the top level with three keys > and entries: Yup. I sure am. Creating it because I want to solve it. It’s a flavor of my white label architecture configuration that I created when I rewrote SendWordNow in 2015. The entailed moving the app into a framework and had a white label launcher app that read a config file based on my stuff from back in 1998 when I made a Director App wrapper engine and specially based config files. (I need to add more meaningless buzzwords. : D ) But this needs to be a more simple case tolerant as there are several apps that I’m making for a client that can either start with a dictionary at the top of the plist or an array and I need to make it forgiving for them. > 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. > I like this. This can handle the next stage of security which is really going to make people happy. > 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. Lots of goodness here, Steve. Thanks for giving me the reason to explain. And I can’t wait to tell the client about how we can now show that we are even more security aware so that the sec eval team realizes that we are adding security check boxes that we can check off. Very nice. I like this a lot. Where should I send the check? Cheers, Alex Zavatone ___ 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
Re: How do you handle reading a plist if it may be an array or a dictionary?
> On May 8, 2021, at 9:55 PM, Gerd Knops wrote:
>
> NSPropertyListSerialization returns an id.
>
> From there you can do
>
> if([object isKindOfClass:NSArray.class])
> {
> NSArray *array=object; // Not really needed, but gives hints to the
> compiler
> ...
> }
> else if([object isKindOfClass:NSDitctionary.class])
> {
> ...
> }
> ...
>
Well, hell! There we go. Thanks Gerd! That’s great!
Best,
Alex Zavatone
>
>
>> On May 8, 2021, at 19:32, Alex Zavatone via Cocoa-dev
>> wrote:
>>
>> Well, what I’m not sure about are how to store the results internally. Do I
>> declare both an NSArray and an NSDictionary and check to see which one ended
>> up getting the proper result?
>>
>> Is there a class of object that is a collection that is - either an array or
>> dictionary? Of course, that’s what a collection is, but I’ve never come
>> across needing to structure code to handle ether an array or a dictionary.
>>
>> In the text of the article, “A property list is itself an array or
>> dictionary that contains only NSData
>> , NSString
>> , NSArray
>> , NSDictionary
>> , NSDate
>> , and NSNumber
>> objects.”
>>
>> It seems like just stalling the inevitable.
>>
>> + (NSData
>> *)dataWithPropertyList:(id)plist
>> format:(NSPropertyListFormat
>> )format
>>
>>options:(NSPropertyListWriteOptions
>> )opt
>>
>> error:(out NSError
>> * _Nullable
>> *)error;
>>
>> OK. So once I get an NSData object, then I need to decode it and see if
>> it’s an array or dictionary, which ends up being the same problem I already
>> have.
>>
>> So, what would be the next step after that?
>>
>> Thanks, Ben.
>>
>> Alex Zavatone
>>
>>
>>> On May 8, 2021, at 7:25 PM, Ben Kennedy wrote:
>>>
>>> Sounds like NSPropertyListSerialization is what you’re after.
>>>
>>> https://developer.apple.com/documentation/foundation/nspropertylistserialization
>>>
>>>
>>>
>>> b
>>>
>>> Sent from my iPhone
>>>
On May 8, 2021, at 5:12 PM, Alex Zavatone via Cocoa-dev
wrote:
I’m reading a configuration plist like so.
NSFileManager *fileManager = [NSFileManager defaultManager];
BOOL success = [fileManager fileExistsAtPath:filePath];
if (success) {
_configurationDictionary = [[NSMutableDictionary
alloc]initWithDictionary:[NSDictionary
dictionaryWithContentsOfFile:filePath]];
In some cases, I want the plist to be a dictionary. In others, I want it
to be an array.
How would anyone recommend to make this a generic method to that could
handle if the contents of the plist was an array or a dictionary?
Thanks in advance.
Alex Zavatone
>>>
>>
>> ___
>>
>> 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/gerti-cocoadev%40bitart.com
>>
>> This email sent to gerti-cocoa...@bitart.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
Re: How do you handle reading a plist if it may be an array or a dictionary?
> On May 8, 2021, at 7:42 PM, Ben Kennedy wrote: > > >> On 8 May 2021, at 5:32 pm, Alex Zavatone wrote: >> >> Well, what I’m not sure about are how to store the results internally. Do I >> declare both an NSArray and an NSDictionary and check to see which one ended >> up getting the proper result? > > Call -[propertyListWithData:options:format:error:], and examine what kind of > object it returns. Process or store it accordingly. > >> Is there a class of object that is a collection that is - either an array or >> dictionary? Of course, that’s what a collection is, but I’ve never come >> across needing to structure code to handle ether an array or a dictionary. > > It sounds like you might need to rethink your data model a bit. That’s what I’m trying to do! : D > I mean, you could hold the object in a variable of type `id` or `AnyObject` > (ObjC or Swift, accordingly), but that will just create hassles for > consumers. What format makes the most sense for the model? Transform the > other one into it if needed. That’s what I was trying to avoid. I’d simply like to see if there is a better way, but it might be OK to bring it in as id, check the class and then save as either dictionary or array. Once it’s read only once it’s in. This might be a fun case for a dict or array wrapper class for my dict or array plist reader thanks to your tips. > >> + (NSData *)dataWithPropertyList:(id)plist >> >> OK. So once I get an NSData object, then I need to decode it and see if >> it’s an array or dictionary, which ends up being the same problem I already >> have. > > No, you have it backwards. That method is useful if you want to create a > plist file out of an array, dictionary, etc. To do the opposite, use > propertyListWithData:…. > Huh? + (NSData *)dataWithPropertyList:(id)plist returns an NSData object. Isn’t the propertyListWithData the one that creates a property list out of NSData? Anyway, thanks man! Good stuff. Thanks and happy Sunday. Alex Zavatone. ___ 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
Re: How do you handle reading a plist if it may be an array or a dictionary?
Alex, > On May 9, 2021, at 15:15, Steve Mykytyn via Cocoa-dev > 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 > 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
Re: How do you handle reading a plist if it may be an array or a dictionary?
You're creating your own problem here. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
