What is the difference between vertical and horizontal views in iOS?

[nicholasacosta775]

Sent from my iPhone hi, I want to know if I should use a vertical or a 
horizontal view in an iOS app that I am trying to write. Basically, I am using 
stack views. What is the difference between these two views? If I use a 
vertical or horizontal view, what will happen to my app? Is it better to use 
one over the other?

Thank U.
___

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: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Keary Suska]

> On Feb 27, 2016, at 3:59 PM, Ben Kennedy  wrote:
> 
> 
>> On 27 Feb 2016, at 11:17 am, Carl Hoefs  
>> wrote:
>> 
>> Yes, that works, thanks! I just thought there might be a "preferred" way to 
>> do it. I guess I was hoping for something like:
>> 
>> [myTableView selectRowAtIndexPath:indexPath 
>>animated:YES 
>>  scrollPosition:UITableViewScrollPositionMiddle
>>triggersDelegateCallback:YES];
> 
> What gain would that afford you, though?
> 
> I believe that the table view API is designed this way to afford the 
> programmer control and flexibility. Perhaps your didSelectRow:... 
> implementation calls some private method to do the business logic, say -[self 
> fireTheRockets]. In that case, you could simply call fireTheRockets directly 
> here instead.
> 
> By contrast, the delegate API provides your code a means to act on external 
> events (user input) brokered by the table view. Perhaps in such a case there 
> is additional UI-related work not suitable for inclusion in fireTheRockets.
> 
> This decoupling enables you to separate these concerns.
> 

Except that it doesn’t follow. There is no design necessity that the object 
programmatically setting the selection is the same object as the delegate, nor 
that those two objects know anything about each other. Also if a delegate 
implements such a delegate call it is signaling that it needs to know every 
selection change regardless of how it is accomplished (since it has not way of 
knowing in advance how it was accomplished, unless you decide to couple the two 
objects). This results in a much more reliable and extensible decoupling since 
no other object should know those internal signaling mechanics and should have 
confidence that any other object interested in the selection will be dutifully 
notified. In fact, this is how NSTableView works. Why UITableView doesn’t, 
seems worthy of a radar.

Best,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Ben Kennedy]

> On 27 Feb 2016, at 11:17 am, Carl Hoefs  
> wrote:
> 
> Yes, that works, thanks! I just thought there might be a "preferred" way to 
> do it. I guess I was hoping for something like:
> 
> [myTableView selectRowAtIndexPath:indexPath 
> animated:YES 
>   scrollPosition:UITableViewScrollPositionMiddle
> triggersDelegateCallback:YES];

What gain would that afford you, though?

I believe that the table view API is designed this way to afford the programmer 
control and flexibility. Perhaps your didSelectRow:... implementation calls 
some private method to do the business logic, say -[self fireTheRockets]. In 
that case, you could simply call fireTheRockets directly here instead.

By contrast, the delegate API provides your code a means to act on external 
events (user input) brokered by the table view. Perhaps in such a case there is 
additional UI-related work not suitable for inclusion in fireTheRockets.

This decoupling enables you to separate these concerns.

-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: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Ben Kennedy]

> On Feb 27, 2016, at 11:01 AM, Carl Hoefs  
> wrote:
> 
> The problem is that the delegate callback associated with selecting that row 
> doesn't occur. And indeed, I have since found that the documentation for this 
> method says:
> 
> "Calling this method does not cause the delegate to receive a 
> tableView:didSelectRowAtIndexPath: message."
> 
> Is there a method to call (or some other way) that will do this?

Why not just call that method yourself?

b



___

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

Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Carl Hoefs]

iOS 9.2

At certain times I need to update the data source for a table view. Then I 
cause the row that was updated to be selected using UITableView's 
-selectRowAtIndexPath::: method. That much works fine. 

The problem is that the delegate callback associated with selecting that row 
doesn't occur. And indeed, I have since found that the documentation for this 
method says:

"Calling this method does not cause the delegate to receive a 
tableView:didSelectRowAtIndexPath: message."

Is there a method to call (or some other way) that will do this?
-Carl


___

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