How to create a dial keypad with autolayout?

[Steve Mykytyn]

Having done this a number of times with springs and struts, I thought a
telephone dial keypad would be a good way to learn the ins and outs of auto
layout

- 5 rows of three buttons each
- Each button has a label (2) and optional label below (abc)
- The width of the buttons always the same.
- The height of each button changes between 3.5 and 4 inch iPhones

Seems like this should be a straightforward use of auto layout, but I can't
seem to get to a solution that does not have a very large number of
constraints, which are very finicky if you try to adjust them.

It's also very difficult to start with a row of three buttons, say, get
that right, then duplicate that row and add/fix up constraints?

Suggestions please?
___

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 to create a dial keypad with autolayout?

[Kyle Sluder]

On Sat, Aug 31, 2013, at 08:59 AM, Steve Mykytyn wrote:
> Having done this a number of times with springs and struts, I thought a
> telephone dial keypad would be a good way to learn the ins and outs of
> auto
> layout
> 
> - 5 rows of three buttons each
> - Each button has a label (2) and optional label below (abc)

When you say "optional," I assume you're okay with always reserving the
space for that label? Otherwise this isn't easy in spring s-and-struts
_or_ auto layout.

> - The width of the buttons always the same.

Add equal width constraints to all the buttons. (And probably equal
heights, too.)

> - The height of each button changes between 3.5 and 4 inch iPhones

You have two options here:
1. Define the height of your buttons using constraints that relate by
some multiplier to the height of your superview. Sadly, you can't do
this in IB. (It would be worth filing a bug!)
2. Leave the height of your views undefined and let their height be
defined by the margins relative to the superview.

> 
> Seems like this should be a straightforward use of auto layout, but I
> can't
> seem to get to a solution that does not have a very large number of
> constraints, which are very finicky if you try to adjust them.
> 
> It's also very difficult to start with a row of three buttons, say, get
> that right, then duplicate that row and add/fix up constraints?

What version of Xcode are you using?

--Kyle Sluder
___

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 to create a dial keypad with autolayout?

[Robert Vojta]

Hi Steve,

I had some free time, so, I made sample project for you ... (Xcode5 & iOS 7
SDK ...). You can get it here: http://d.pr/f/VOX4

Look at two classes:

DPDialPadButton & - (id)initWithNumber:(NSString *)number label:(NSString
*)label;
DPDialPadView & - (void)setupDialPadButtons;

You can run this sample project on iPhone 4 or iPhone 5. There's no device
check in this sample project, because everything relates to the parent view
size. So, it does work on both iPhones. Basically in a view with any size
(if it's not too small).

HTH,
Robert



On Sat, Aug 31, 2013 at 5:59 PM, Steve Mykytyn  wrote:

> Having done this a number of times with springs and struts, I thought a
> telephone dial keypad would be a good way to learn the ins and outs of auto
> layout
>
> - 5 rows of three buttons each
> - Each button has a label (2) and optional label below (abc)
> - The width of the buttons always the same.
> - The height of each button changes between 3.5 and 4 inch iPhones
>
> Seems like this should be a straightforward use of auto layout, but I can't
> seem to get to a solution that does not have a very large number of
> constraints, which are very finicky if you try to adjust them.
>
> It's also very difficult to start with a row of three buttons, say, get
> that right, then duplicate that row and add/fix up constraints?
>
> Suggestions please?
> ___
>
> 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/robert%40tapmates.com
>
> This email sent to rob...@tapmates.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

Mutating message sent to immutable object

[Gerriet M. Denkmann]

I have an NSObjectController called objectController with content bound to 
locationDictionary.
@property (strong) NSMutableDictionary  *locationDictionary;

And an NSArrayController called arrayController which has its content bound to 
objectController.myArrayKey.
This array contains column-dictionaries.

And an NSTableView (non View-based) whose columns are bound to arrayController. 
The keys in the  column-dictionaries of course correspond to the identifiers of 
the columns and each element in objectController.myArrayKey represents one row.


locationDictionary is set from standardUserDefaults
NSDictionary *a = [ standardUserDefaults dictionaryForKey: 
kToolbarLocations ];
NSDictionary *b = a[ someIdentifier];
self.locationDictionary = b;

But when editing the tableView this (sometimes, not always) crashed.
So I changed the last line to:
self.locationDictionary = [b mutableCopy];
This worked better, but still the occasional crash:  "Mutating message sent to 
immutable object"; the message being: setObject:forKey: (obviously trying to 
change one of my  column-dictionaries)

So I changed the line again to:
self.locationDictionary = [b veryDeepMutableCopy];  
which converts NSArrays to mutable, and the elements thereof into mutable 
dictionaries.

Now I don't see any crashes anymore.

Two questions:
1. Is there a better way to do this (letting NSControllers change the stuff to 
mutable automagically)?

2. Why did this even occasionally work before I made my veryDeepMutableCopy? 
NSUserDefaults tells me about dictionaryForKey: "The returned dictionary and 
its contents are immutable, even if the values you originally set were mutable."

Does this really mean:  "The returned dictionary and its contents are mutable 
or immutable depending on our whims. You better not rely on their mutability 
state."

Gerriet.


___

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: Mutating message sent to immutable object

[Ken Thomases]

On Aug 31, 2013, at 9:10 PM, Gerriet M. Denkmann wrote:

> NSUserDefaults tells me about dictionaryForKey: "The returned dictionary and 
> its contents are immutable, even if the values you originally set were 
> mutable."
> 
> Does this really mean:  "The returned dictionary and its contents are mutable 
> or immutable depending on our whims. You better not rely on their mutability 
> state."

That's _always_ what it means when an API gives you an immutable object.  It 
means the design contract is that you're not allowed to mutate it.  It doesn't 
mean the object is inherently immutable.  A class may have a property that 
returns an immutable NSString but it may simply return a reference to an 
NSMutableString instance variable.  The object is mutable for internal 
implementation reasons.

From 
:

> Use Return Type, Not Introspection
> 
> To determine whether it can change a received object, the receiver of a 
> message must rely on the formal type of the return value. If it receives, for 
> example, an array object typed as immutable, it should not attempt to mutate 
> it. It is not an acceptable programming practice to determine if an object is 
> mutable based on its class membership—for example:
> 
> if ( [anArray isKindOfClass:[NSMutableArray class]] ) {
> // add, remove objects from anArray
> }
> For reasons related to implementation, what isKindOfClass: returns in this 
> case may not be accurate. But for reasons other than this, you should not 
> make assumptions about whether an object is mutable based on class 
> membership. Your decision should be guided solely by what the signature of 
> the method vending the object says about its mutability. If you are not sure 
> whether an object is mutable or immutable, assume it’s immutable.
> 
> A couple of examples might help clarify why this guideline is important:
> 
>   • You read a property list from a file. When the Foundation framework 
> processes the list, it notices that various subsets of the property list are 
> identical, so it creates a set of objects that it shares among all those 
> subsets. Afterward you look at the created property list objects and decide 
> to mutate one subset. Suddenly, and without being aware of it, you’ve changed 
> the tree in multiple places.
> 
>   • You ask NSView for its subviews (with the subviews method) and it 
> returns an object that is declared to be an NSArray but which could be an 
> NSMutableArray internally. Then you pass that array to some other code that, 
> through introspection, determines it to be mutable and changes it. By 
> changing this array, the code is mutating internal data structures of the 
> NSView class.
> 
> So don’t make an assumption about object mutability based on what 
> introspection tells you about an object. Treat objects as mutable or not 
> based on what you are handed at the API boundaries (that is, based on the 
> return type). If you need to unambiguously mark an object as mutable or 
> immutable when you pass it to clients, pass that information as a flag along 
> with the object.

Regards,
Ken


___

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