Re: OK - I must be missing something simple here.
Re: OK - I must be missing something simple here.
- Subject: Re: OK - I must be missing something simple here.
- From: Rick Aurbach <email@hidden>
- Date: Tue, 21 Jun 2016 18:55:34 -0400
- Acceptlanguage: en-US
- Thread-topic: OK - I must be missing something simple here.
> On Jun 21, 2016, at 3:40 PM, Alex Zavatone <email@hidden> wrote:
>
>
> On Jun 21, 2016, at 3:23 PM, Rick Aurbach wrote:
>
>>> On Jun 21, 2016, at 3:14 PM, Alex Zavatone <email@hidden> wrote:
>>>
>>>
>>> On Jun 21, 2016, at 2:24 PM, Rick Aurbach wrote:
>>>
>>>> On Jun 21, 2016, at 2:00 PM, email@hidden<mailto:email@hidden> wrote:
>>>>
>>>> Message: 1
>>>> Date: Tue, 21 Jun 2016 12:54:57 -0500
>>>> From: Alex Zavatone <email@hidden<mailto:email@hidden>>
>>>> To: Cocoa dev <email@hidden<mailto:email@hidden>>
>>>> Subject: OK - I must be missing something simple here.
>>>> Message-ID: <email@hidden<email@hidden">mailto:email@hidden>>
>>>> Content-Type: text/plain; charset=us-ascii
>>>>
>>>> I've got a little iOS project with SIP and it's quite convenient to have a graphic indicator that shows the connected state of the client to the server. Top right makes the most sense, and it's cleanest to use a UIBarButtonItem to hold the graphic and as the enumerated registration state changes, it's watched by KVO and just changes the graphic by changing the button, nice and straight forward.
>>>>
>>>> Well, I got a request to put this in other places and I the code that I had to build the UIBarButtonItems created those items by creating a UIButton first and then used that view to init the UIBarButtonItem with initWithCustomView:myOtherButton.
>>>>
>>>> This works like a charm. I have a dictionary of UIBarButtonItems that are keyed of the stringified enum name and they are instantly swapped out as needed whenever the watched state changes.
>>>>
>>>> So, I thought, "well, since I build these UIBarButtonItems from the UIButtons in the first place, I'll just keep an additional dictionary of buttons around that then just swap them in and out of an iBOutlet slot in the storyboard as needed.
>>>>
>>>> Um. Is this even possible? Can you assign a UIButton instance that you have in code to an IBOutlet for a UIButton in the storyboard? This does work perfectly for the nav bar's rightButton with barButtonItems, but is this even possible in code?
>>>>
>>>> I'm missing something here. Or I'm not. Any ideas?
>>>>
>>>> Thanks,
>>>>
>>>> Alex Zavatone
>>>>
>>>>
>>>> I think I must be a bit dense here, but why not just keep a dictionary of images and swap the image for the button instead of the button itself?
>>>>
>>>> Rick Aurbach
>>>
>>> That's what I did, but since I already had the buttons, I was wondering, "can I do this?" And it turns out it's not exactly clear how or if it's possible. At least to me.
>>>
>>> Initally, when trying to add graphics to the Nav bar I started out with a dictionary of images, but it's pretty much pain trying to stuff images in there, but stuffing in prebuilt UIBarButtonItems is really smooth and trouble free.
>>>
>>> It would be nice to treat the IBOutlets as slots to rects but that doesn't appear to be anything I've got spare time for at the moment. Still have Friday's bugs to report before the sun goes down.
>>
>> I agree that I probably wouldn’t put the images directly in the dictionary either. But I might put the image file name in there and allocate it as needed. I’ve certainly done something similar when building buttons which have a different appearance in different states…
>>
>> Rick Aurbach
>
> The reason why I am using a dictionary is that I have an NS_Enum for the SIP connecting states that the user cares about
> Connection not yet attempted
> Connection requested and in progress
> Connection successfully established
> Connection failed or a disconnect issued
>
> With the NS_Enum, I have a method that returns the English string (above) for the appropriate enum value.
>
> This allows us to handle the connection state when it changes through a simple switch, but if we need to simply look up a result based on the current value of the enum, this allows us to have a look up table that is keyed off the string description of the enum state and we can just go, "just return the appropriate image for whatever the current state of the thing is". And it looks it up in the dict and returns the preallocated item.
>
> This is what I used to swap out the UIBarBarButtonItem within the framework's storyboard's main view controller's nav bar to keep the connected state button always showing the expected color/graphic.
>
> Now that I'm asked, "hey, that little graphic looks great when it's in the framework's UI in its storyboard, but can you make it available in whatever app is linking to our framework and not in a UINavigationBar", I prefer to have a self observing data structure that can already have what it needs and be nice and encapsulated so that it can be used from the storyboard of the app that's embedding our framework.
>
> A dictionary might seem too bulky, but it provides a perfect look up table mechanism in this case.
>
> What would be better in your book?
>
> Thanks for your time.
>
> Alex Zavatone
Okay, Alex. You asked for it.
Working from the top of my head, my data structure would be something like an array of dictionaries (indexed by the enum’s raw value) or perhaps an array or dictionary of structures (i.e., Swift structs). Each dictionary or structure would contain a key or property for the user-facing text string, another for the image file name, etc. And I would extend UIButton to include this dictionary or structure as a property of the button (with appropriate initializers, getter/setters, etc). I might even include a get/setConnectionState function which handled the internals of the state change, so that all you needed to do when the state changed was send the button a message announcing the new state.
Now don’t take any the above too seriously; I’m just reacting to the information you’ve given me and I’m sure there are many details and ramifications to which I am uninformed. But you asked… :-)
Rick Aurbach
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden