Re: Accessing array in thread safe way

[Brian Lambert]

No.

Assuming the property you describe is declared something like this:

@property (strong, atomic) NSMutableArray * myArray;

Then what's atomic is getting and setting the entire array.  That is
[project setMyArray:[[NSMutableArray alloc] init]]; would be atomic.

Once a caller obtains the array by calling:

NSMutableArray * theArray = [project myArray];

And starts messing with it:

[theArray someMethod];

The array contents are not protected.



On Tue, Mar 6, 2012 at 11:51 AM, Jan E. Schotsman  wrote:

> Hello,
>
> I have an array of progress values (number objects) for subprojects, from
> which I calculate the overall progress .
> The array is an atomic property of the project class.
>
> Is it safe to access this array from multiple threads, using methods like
> objectAtIndex and replaceObjectAtIndex?
>
> Jan E.
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: Accessing array in thread safe way

[Brian Lambert]

Spin locks are useful in certain situations.

First of all, on a single-processor system, it's never a good idea to use a
spin lock because all it will do is burn up the waiting thread's scheduling
quantum while preventing a thread that's holding the lock from getting
scheduled so that it can complete its work and release the lock.

A spin lock is useful in multi-processor environments when you know that a
lock will be held for a *very short period of time*.  In this case, spin
locks can help you avoid excessive context switching because a waiting
thread will often be able to spin (do something else) while waiting for a
lock to be released, acquire the lock, and do its work, all within its
scheduling quantum.

In many simple scenarios, especially when contention is very low,
@synchronized will be the best choice because it's trivial to get right and
high-performance.

In other scenarios, a fair readers-writers lock will be ideal.


On Thu, Mar 8, 2012 at 9:52 AM, Jan E. Schotsman  wrote:

>
> On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote:
>
>  Maybe this will helps you, here is my thread-safe subclass of
>> NSMutableArray: http://code.google.com/p/**cogeopensource/source/browse/*
>> *trunk/CoGeOpenSource/**CoGeThreadSafeMutableArray.m
>>
>
> Thanks for the code.
> I have two questions:
>
> 1. If you believe that OSSpinLock is faster than NSLock why don't you use
> it for your thread-safe mutable array class too?
>
> 2. Once you start using an enumerator for the array you probably need  a
> explicit mutex after all. Isn't it simpler to just use
>  @synchronized(array) wherever the array is accessed?
>
> Jan E.
>
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: Accessing array in thread safe way

[Brian Lambert]

I should have said, "relatively".  As in, good enough for many scenarios
where it will be used infrequently and keeping the code simple makes sense.

Of course, you're right, Charles.

1,000,000 integer increments synchronized by @synchronized, OSSpinLock, and
NSLock:

PerfTimer[95716:403] 1,000,000 @synchronized ++value: [118 ms] [117,813,038
ns]
PerfTimer[95716:403] 1,000,000 OSSpinLock ++value: [8 ms] [8,444,567 ns]
PerfTimer[95716:403] 1,000,000 NSLock ++value: [63 ms] [63,049,168 ns]
A million operations in ~100 ms is fast. A million operations in ~10 ms is
WICKED fast.

Brian


On Thu, Mar 8, 2012 at 12:14 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 1:19 PM, Brian Lambert wrote:
>
> In many simple scenarios, especially when contention is very low,
> @synchronized will be the best choice because it's trivial to get right and
> high-performance.
>
>
> @synchronized is easy-to-use, for sure, but it is far from
> high-performance.
>
> The first result that Google turns up for benchmarks comparing
> @synchronized, mutexes, and OSSpinLocks shows @synchronized to be almost an
> order of magnitude slower than the competition:
>
> http://perpendiculo.us/?p=133
>
> Charles
>
___

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: Accessing array in thread safe way

[Brian Lambert]

Cool! Thanks for that.

My tests were run on an 27" iMac 3.4 GHz Intel Core i7. Code was compiled
with -O3 (Fastest).

The PerfTimer I used is my own.  I blogged about it here:
http://www.objective-brian.com/334
Feedback is welcome.

Brian


On Thu, Mar 8, 2012 at 1:20 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 2:51 PM, Brian Lambert wrote:
>
> > I should have said, "relatively".  As in, good enough for many scenarios
> where it will be used infrequently and keeping the code simple makes sense.
> >
> > Of course, you're right, Charles.
> >
> > 1,000,000 integer increments synchronized by @synchronized, OSSpinLock,
> and NSLock:
> > PerfTimer[95716:403] 1,000,000 @synchronized ++value: [118 ms]
> [117,813,038 ns]
> > PerfTimer[95716:403] 1,000,000 OSSpinLock ++value: [8 ms] [8,444,567 ns]
> > PerfTimer[95716:403] 1,000,000 NSLock ++value: [63 ms] [63,049,168 ns]
> >
> > A million operations in ~100 ms is fast. A million operations in ~10 ms
> is WICKED fast.
> >
> > Brian
>
> Another interesting option is mentioned in Apple’s GCD man pages;
> dispatch_sync can actually be used as a locking mechanism, like so:
>
> __block NSUInteger value = 0;
>
> dispatch_sync(myLockQueue, ^{
>value++;
> });
>
> This results in something almost as simple as @synchronized, and quite a
> lot faster. Here are the results I get when running it on my MBP. All my
> results do take about twice as long as yours; I suspect you have a rather
> nice machine. :-)
>
> 2012-03-08 15:14:56.408 Lock Benchmarks[57369:403] @synchronized value++:
> 259.156942 ms
> 2012-03-08 15:14:56.429 Lock Benchmarks[57369:403] OSSpinLock value++:
> 19.486010 ms
> 2012-03-08 15:14:56.517 Lock Benchmarks[57369:403] pthread_mutex_t
> value++: 86.329997 ms
> 2012-03-08 15:14:56.645 Lock Benchmarks[57369:403] NSLock value++:
> 127.897978 ms
> 2012-03-08 15:14:56.692 Lock Benchmarks[57369:403] dispatch_sync value++:
> 45.979023 ms
>
> Not bad; OSSpinLock is the only thing that seems to be able to best it.
>
> Charles
>
>
___

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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Brian Lambert]

The short answer is that:

1) Given our current languages and tools, parallel programming is hard.
2) For the moment, it is generally the case that one thread is enough to
keep a UI updated and responding to events, thus avoiding #1.
3) When one thread isn't enough to keep a UI updated and responding to
events, other threads can be used, and then the output of those threads can
be fed to the UI thread.

On Tue, Mar 13, 2012 at 2:09 PM, JongAm Park wrote:

> Hello,
>
> While doing projects with Cocoa and Objective-C, I have always thought
> that allowing UI update only on main thread was a weak point of
> Cocoa/Objective-C.
> Especially, when gracefully terminating threads which would be better
> update some UI stuff and if main thread is required to wait until those
> threads finishes for clean exit, it can cause dead lock condition.
> In other words, the thread function may want to update UI like inserting a
> log message to a text field on a window and thus asking main thread to do
> so, and main thread is waiting to acquire a lock or waiting using "Join",
> then either the main thread and the other thread can't progress.
>
> But, I also noticed the same pattern with C# .NET. Unlike Win32/MFC and
> like Objective-C/Cocoa, it also asks a main thread to update UI widgets.
>
> Is there any reason to design threading and UI update model like this?
> At first I thought it was due to somehow Obj-C/Cocoa sticks to some old
> model, but C# .NET is fairly new architecture. They could have avoided it
> if doing so was better. So, I guess there must be some reason behind it.
>
> Can anyone explain the rationale behind it?
> Also, is there a way to gracefully terminate an app by quitting threads
> and main thread?
>
> Thanks,
> JongAm Park
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Brian Lambert]

Scott, it's not that any one thing is hard to get correct.  Arrogantly
calling someone stupid, as you've done here, doesn't help.  It's
the subtlety of getting *everything* correct.  A GUI system, and the
programs that are layered on top of it, embody a great deal of complexity.
 Allowing multiple threads to operate on the GUI causes this complexity to
permute.

On Wed, Mar 14, 2012 at 6:43 AM, Scott Ribe wrote:

> On Mar 13, 2012, at 3:09 PM, JongAm Park wrote:
>
> > In other words, the thread function may want to update UI like inserting
> a log message to a text field on a window and thus asking main thread to do
> so, and main thread is waiting to acquire a lock or waiting using "Join",
> then either the main thread and the other thread can't progress.
>
> Ouch. If you think that's a problem, then trust me, you would really make
> a mess with multiple UI threads.
>
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
>
> ___
>
> 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/brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: [Q] Why is the threading and UI updating designed to be done only on a main thread?

[Brian Lambert]

"Ouch. If you think that's a problem, then trust me, you would really make
a mess with multiple UI threads."

That isn't calling someone stupid?  Really?

Ah, OK. My inference processor must be in error.


On Wed, Mar 14, 2012 at 9:14 AM, Scott Ribe wrote:

> On Mar 14, 2012, at 10:07 AM, Brian Lambert wrote:
>
> > Scott, it's not that any one thing is hard to get correct.  Arrogantly
> calling someone stupid, as you've done here, doesn't help.
>
> I didn't call anyone stupid--that's your inference, not mine.
>
> I did point out that someone who thinks he can solve a thread deadlock
> problem by throwing more threads at it is really headed in the wrong
> direction.
>
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
>
___

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

Why so many public properties all up in my grizzle?

[Brian Lambert]

I’ve been developing iOS applications full-time for about 6 months now and
I love it. I feel pretty strong on the platform now.

I have a lingering question about something that’s really been bugging the
heck out of me, though, that I thought I would ask the list and get some
feedback on.

It seems to be the case that when people are developing a UIViewController
subclass or a UIView subclass that they expose *all* the implementation
details of that class through public properties vs. using ivars.

Here’s an example. For the purpose of this post, I’ve wrote a simple iPhone
app with one view. The link below is a screen shot of it:

https://s3.amazonaws.com/Softwarenerd/MyApp.jpg

For now, I used Interface Builder to generate the UI.  In doing so, I wound
up with:

#import 

// MyViewController interface.
@interface MyViewController : UIViewController

// Properties.
@property (weak, nonatomic) IBOutlet UILabel * labelMyLabel;

// buttonDoItTouchUpInside action.
- (IBAction)buttonDoItTouchUpInside:(id)sender;

@end

This means that my UILabel called labelMyLabel is publicly available.
Anyone who has access to an instance of MyViewController can do anything
they want to with my label, including replacing it.

Also, anyone who has an instance of MyViewController can call my
buttonDoItTouchUpInside action.

For example, in my AppDelegate, I can do:

- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
   self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen]
bounds]];

   MyViewController * myViewController = [[MyViewController alloc]
initWithNibName:@"MyViewController" bundle:nil];
   [self setMyViewController:myViewController];
   [[self window] setRootViewController:[self myViewController]];
   [[self window] makeKeyAndVisible];

   // Mess with MyViewController  HAHAHAHA FU, MyViewController
   [[myViewController labelMyLabel] setText:@"This is ridiculous"];
   return YES;
}

To me, this totally ridiculous. It breaks well-established rules of
encapsulation.

From my analysis, it appears to be nothing more than an artifact of how
rehydrating NIBs works, and it totally compromises good OO software design
by leaking all the implementation details of MyViewController to the
outside world.

Everyone, all the books, training materials, samples, and so on, just seem
to accept this style of doing things as being normal. In fact, one book I
read *encouraged* this technique of using public properties for ALL the
internal state of a class over using ivars. It said public properties were
preferable.

What in the world is the deal with this??  :-)  Can anyone explain this do
me?

Building this class without Interface builder, here’s how I coded it:

// MyViewController implementation.
@implementation MyViewController
{
@private
   UILabel * labelMyLabel_;
   UIButton * buttonDoIt_;
}

- (void)viewDidLoad
{
   [super viewDidLoad];

   [[self view] setBackgroundColor:[UIColor whiteColor]];

   labelMyLabel_ = [[UILabel alloc] initWithFrame:CGRectMake(20.0, 20.0,
280.0, 21.0)];
   [labelMyLabel_ setText:@"I dare you to press Do It!"];
   [[self view] addSubview:labelMyLabel_];

   buttonDoIt_ = [UIButton buttonWithType:UIButtonTypeRoundedRect];
   [buttonDoIt_ setFrame:CGRectMake(20.0, 49.0, 72.0, 37.0)];
   [buttonDoIt_ setTitle:@"Do It" forState:UIControlStateNormal];
   [buttonDoIt_ addTarget:self action:@selector(buttonDoItTouchUpInside:)
forControlEvents:UIControlEventTouchUpInside];
   [[self view] addSubview:buttonDoIt_];
}

- (void)viewDidUnload
{
   [super viewDidUnload];
}

// buttonDoItTouchUpInside action.
- (void)buttonDoItTouchUpInside:(id)sender
{
   [labelMyLabel_ setText:@"You pressed Do It!"];
}

@end

To me, this is how things should be. The implementation details of how my
view works are hidden.

Am I missing something?

@property sure is convenient, but it seems to be misused a lot. A class
should expose properties that are public, and hide implementation details
that are not.

Thanks!

Brian
___

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: Why so many public properties all up in my grizzle?

[Brian Lambert]

I'd like an argument, please.

Regarding this:

In the chapter called "Defining a Class", not only is declaring
an ivar in the .m file covered, but doing it in the .h file is downright
discouraged (rightly so). In practice, this feature of Objective-C...

I can't stand thus sort of subtle crap.  If it's legal to declare ivars in
the .M file and the .H file, it's crap to say it's "discouraged" in the .H
file.  Either a language is well-designed, consistent, and carefully
thought out, or, it has turned into crap.

Is there a warning level for "You did something that's totally legal, but,
discouraged."?

ivars in the .H file are totally necessary in order to use ivars with
Objective-C Category files.  I love Objective-C Category files because they
allow me to segment my implementation such that each file more or less
represents each interface that my class implements, vs, loading *all* the
implementation details into one .M file simply so I don't have to declare
ivars in the .H file.

I get why ivars in the .H file is not super fantastic, so let's not have
that debate.

Is there a way to declare ivars in the .M file AND have them accessible
from Objective-C Category files for the class?

Thanks!

Brian


On Mon, Mar 19, 2012 at 11:32 AM, Matt Neuburg  wrote:

> On Fri, 16 Mar 2012 17:11:24 -0400, Marco Tabini  said:
> >> That time has passed now, so you can now completely specify IBOutlets
> (and IBActions) in your implementation file and hide the details from the
> outside world. If you want properties, you can use a class extension like
> so to add them:
> >
> >Sorry to hijack this conversation, but I've been meaning to ask: Where is
> this documented? I stumbled on this feature (and the ability to declare
> ivars directly in the .m file), but I didn't see it explained it anywhere.
> I'm sure I'm just not looking in the right place, but I can't find it
> anywhere.
>
> See Apple's document "The Objective-C Programming Language".
>
> In the chapter called "Defining a Class", not only is declaring an ivar in
> the .m file covered, but doing it in the .h file is downright discouraged
> (rightly so). In practice, this feature of Objective-C did not swim into
> most people's ken until Xcode 4.2, when LLVM because the default compiler.
>
> In the chapter called "Categories and Extensions", declaration of private
> properties is discussed. That feature is considerably older.
>
> m.
>
> PS And of course there's also my book, which makes much of these features.
>
> PPS The trouble with language improvements like this, and with documents
> like The Objective-C Programming Language, is that there's a terminus point
> somewhere and they don't tell you exactly when it is. What I mean is, you
> can surprise yourself by adopting an improvement of this sort and then
> opening your project in an earlier version of Xcode that doesn't understand
> it. Also, different *parts* of Xcode may not understand it; for example,
> your code will compile, but the feature where you can drag from an ivar to
> the nib editor to form an outlet might not work (though now, I believe, it
> does).
>
> --
> matt neuburg, phd = m...@tidbits.com, 
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
> ___
>
> 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/brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: Why so many public properties all up in my grizzle?

[Brian Lambert]

One final note:

ivars in the .H file of a public framework is *obviously stupid* as it
leaks implementation details.

ivars in the .H file of my Foo class, which no one other than me will ever
use, should be relatively OK.  After all, I'm not trying to prevent myself
from knowing anything about my implementation of Foo.  I'm just trying to
ensure that my *intent* for my class is well-understood to other
programmers who will work on Foo in the future.


On Mon, Mar 19, 2012 at 12:27 PM, Brian Lambert wrote:

> I'd like an argument, please.
>
> Regarding this:
>
> In the chapter called "Defining a Class", not only is declaring
> an ivar in the .m file covered, but doing it in the .h file is
> downright
> discouraged (rightly so). In practice, this feature of Objective-C...
>
> I can't stand thus sort of subtle crap.  If it's legal to declare ivars in
> the .M file and the .H file, it's crap to say it's "discouraged" in the .H
> file.  Either a language is well-designed, consistent, and carefully
> thought out, or, it has turned into crap.
>
> Is there a warning level for "You did something that's totally legal, but,
> discouraged."?
>
> ivars in the .H file are totally necessary in order to use ivars with
> Objective-C Category files.  I love Objective-C Category files because they
> allow me to segment my implementation such that each file more or less
> represents each interface that my class implements, vs, loading *all* the
> implementation details into one .M file simply so I don't have to declare
> ivars in the .H file.
>
> I get why ivars in the .H file is not super fantastic, so let's not have
> that debate.
>
> Is there a way to declare ivars in the .M file AND have them accessible
> from Objective-C Category files for the class?
>
> Thanks!
>
> Brian
>
>
> On Mon, Mar 19, 2012 at 11:32 AM, Matt Neuburg  wrote:
>
>> On Fri, 16 Mar 2012 17:11:24 -0400, Marco Tabini  said:
>> >> That time has passed now, so you can now completely specify IBOutlets
>> (and IBActions) in your implementation file and hide the details from the
>> outside world. If you want properties, you can use a class extension like
>> so to add them:
>> >
>> >Sorry to hijack this conversation, but I've been meaning to ask: Where
>> is this documented? I stumbled on this feature (and the ability to declare
>> ivars directly in the .m file), but I didn't see it explained it anywhere.
>> I'm sure I'm just not looking in the right place, but I can't find it
>> anywhere.
>>
>> See Apple's document "The Objective-C Programming Language".
>>
>> In the chapter called "Defining a Class", not only is declaring an ivar
>> in the .m file covered, but doing it in the .h file is downright
>> discouraged (rightly so). In practice, this feature of Objective-C did not
>> swim into most people's ken until Xcode 4.2, when LLVM because the default
>> compiler.
>>
>> In the chapter called "Categories and Extensions", declaration of private
>> properties is discussed. That feature is considerably older.
>>
>> m.
>>
>> PS And of course there's also my book, which makes much of these features.
>>
>> PPS The trouble with language improvements like this, and with documents
>> like The Objective-C Programming Language, is that there's a terminus point
>> somewhere and they don't tell you exactly when it is. What I mean is, you
>> can surprise yourself by adopting an improvement of this sort and then
>> opening your project in an earlier version of Xcode that doesn't understand
>> it. Also, different *parts* of Xcode may not understand it; for example,
>> your code will compile, but the feature where you can drag from an ivar to
>> the nib editor to form an outlet might not work (though now, I believe, it
>> does).
>>
>> --
>> matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/>
>> A fool + a tool + an autorelease pool = cool!
>> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
>> ___
>>
>> 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/brianlambert%40gmail.com
>>
>> This email sent to brianlamb...@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: Device/Resolution independent positioning of GUI items on iOS

[Brian Lambert]

Hi Alex,

Regarding you having to "repair" code where "UI elements that have been
hardcoded in place with the approach of: Just define the CGRect and we're
all good."  I think you're seeing things as being "gross" when they are not.

"Just define the CGRect and we're all good" is what IB does.  A XIB file is
nothing more than a set of hardcoded values stored in XML vs. being
hand-coded in Objective-C.

For example, here's a label laid out in a XIB:


...
{{20, 20}, {280, 21}}
...


And here is the same label coded in Objective-C:
...

labelMyLabel_ = [[UILabel alloc] initWithFrame:CGRectMake(20.0, 20.0, 280.0,
21.0)];
...
The programmer who hand-coded the label didn't do anything better or worse
than the programmer who used IB to lay out a XIB file.  In fact, in some
cases, it's way easier to "see" UI in Objective-C vs. Interface Builder.
 In Objective-C an experienced UI coder can "see" a bunch of controls, and
all their properties, on one screen vs. having to click on each one and
inspect their properties in Interface Builder.

Best,

Brian


On Mon, Mar 19, 2012 at 12:59 PM, Alex Zavatone  wrote:

> In the current project that I'm tasked to repair from the previous two
> programmers, I've come across a load of UI elements that have been
> hardcoded in place with the approach of: Just define the CGRect and we're
> all good.
>
> Nothing is laid out in an xib file and sometimes the views are hardcoded
> or hardcoded relative to the rect/bounds of another view.
>
> Needless to say, there are a few issues when looking at the project on
> different versions of iOS and on different devices.
>
> At this point, so much is already created, I'm simply walking through the
> monolithic code and breaking it up into proper methods and new classes
> where necessary.
>
> So, while it's nice to take a 40+ line mess and turn it into two method
> calls, I'm not 100% sure on the preferred approach for programmatically
> positioning elements and simply hardcoding them for the delegate for one
> class of devices doesn't seem like the proper approach.
>
> Is the desired method or is there another way that I'm not seeing in the
> docs?
>
> TIA,
> - 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/brianlambert%40gmail.com
>
> This email sent to brianlamb...@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: Device/Resolution independent positioning of GUI items on iOS

[Brian Lambert]

That's a good point. It's really a matter of tradeoffs.

I find that in some cases the XIB is adding nothing but overhead and just
do everything in code.  Especially when the view is simple (contains a
small number of controls and views).

In other cases, the XIB is useful. Especially when there are a bazillion
controls and views in a view.  In this case, you can do things like
multi-select / move and save a lot of time.

My meta point is simply that there's nothing inherently "gross" about doing
things in code.  It's not "cleaner" to use Interface Builder.  Anything you
can do in Interface Builder you can do in code, and vice versa, and
sometimes one is better than the other.

There's a conservation of complexity.




On Mon, Mar 19, 2012 at 1:46 PM, glenn andreas  wrote:

>
> On Mar 19, 2012, at 3:22 PM, Brian Lambert wrote:
>
> > Hi Alex,
> >
> > Regarding you having to "repair" code where "UI elements that have been
> > hardcoded in place with the approach of: Just define the CGRect and we're
> > all good."  I think you're seeing things as being "gross" when they are
> not.
> >
> > "Just define the CGRect and we're all good" is what IB does.  A XIB file
> is
> > nothing more than a set of hardcoded values stored in XML vs. being
> > hand-coded in Objective-C.
> [snip]
> > ...
> > The programmer who hand-coded the label didn't do anything better or
> worse
> > than the programmer who used IB to lay out a XIB file.  In fact, in some
> > cases, it's way easier to "see" UI in Objective-C vs. Interface Builder.
> > In Objective-C an experienced UI coder can "see" a bunch of controls, and
> > all their properties, on one screen vs. having to click on each one and
> > inspect their properties in Interface Builder.
>
>
> Except that the runtime can easily substitute another XIB file dynamically
> to support different layout in iPhone vs iPad (or a different localization).
>
> If you hard code this into your code, you've got to hard code in all the
> differences in device layout as well as any localization specialization.
>
> Glenn Andreas  gandr...@gandreas.com
> The most merciful thing in the world ... is the inability of the human
> mind to correlate all its contents - HPL
>
>
___

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: Device/Resolution independent positioning of GUI items on iOS

[Brian Lambert]

In Interface Builder all coordinates are expressed in terms of a non-Retina
device, and scaled on Retina devices.  So running a XIB on non-Retina and
Retina "just works".  The same holds true for doing it in code (generally).

I'll give you an example.  One of the projects I'm working on right now is
a universal app that runs on iPhone, iPhone Retina, iPad, and iPad Retina.

I am using only 3 sets of images and two XIB's to cover all devices.

On the iPhone, I use the iPhoneFoo.xib, which is designed with Yada.png
images.  When the application is run on an iPhone Retina, the
Yada@2x.pngimages are used in places of the Yada.png images
automatically.  All
coordinates scale automatically.  It just works.

On the iPad, I use the iPadFoo.xib, which is designed with
Yada@2x.pngimages.  I simply use the iPhone's @2x image set as the
default set on the
iPad for non-Retina devices.  When the application is run on an iPad
Retina, the Yada@2...@2x.png images are used in places of the
Yada@2x.pngimages automatically.  All coordinates scale automatically.
 It just works.

This has saved me a bunch of work, and a bunch of binary app space.  I'm
pretty pleased with how iOS works in this department.







On Mon, Mar 19, 2012 at 2:04 PM, Alex Zavatone  wrote:

> Well, let's put it this way; there are other things that need to be
> cleaned up - like 900 lines of code that are called on viewWillAppear in
> one class, 8 printed pages of warnings as well as a mix of XML, JSON and
> comma delimited data structures that are fetched ala http on startup.
>
> Looking at all the other cases of how stuff is put together in this app, I
> thought it safest to ask the people who have been doing this longer rather
> than just proceed along thinking everything's just fine with this approach.
>
> Ya, I've actually gone in and modified the XML before to reposition
> elements and wasn't sure I had the full grasp on how Xcode/Cocoa does it.
>  I thought it might be relative to a base coordinate system and then at
> runtime, a 1.x multiplier might be applied to the plane that the controls
> are drawn upon.  But, I never had the time to rip through it all and get to
> the bottom of it all.
>
> So, sweet.  Thanks a bunch.
>
>
>
> On Mar 19, 2012, at 4:22 PM, Brian Lambert wrote:
>
> > Hi Alex,
> >
> > Regarding you having to "repair" code where "UI elements that have been
> hardcoded in place with the approach of: Just define the CGRect and we're
> all good."  I think you're seeing things as being "gross" when they are not.
>
>
___

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: Device/Resolution independent positioning of GUI items on iOS

[Brian Lambert]

Imagine now if someone at Apple working on Interface Builder conjured up
the notion of adding "modes" for a view design.

This is the coolest idea ever for Interface Builder.  :-)  And I don't even
think it would be *all that hard* to do.

I add a new UIViewController subclass to my project, select "With XIB for
user interface", and enter the designer.  Once there, I set the view's
orientation to "Portrait" and name this first, default mode to be
"Portrait".

I then add my controls and views to the view.  Connect everything up to my
controller.  Write all my code.  Happy times.

Next I decide I want to have a totally different layout for the view in
Landscape mode, one that autosizing won't do for me. (Right now I do this
in code...)  So, I create a new mode for the view, call it Landscape, and
set its orientation to Landscape.

In Interface Builder, I would then see two views, one in portrait mode, one
in landscape mode, each with the EXACT SAME set of controls and
connections.  Then I could simply move all the controls around on the
landscape mode view, and everything would "just work".

This generalized "mode" feature could be used for the German layout, too.
 :-)

I think this would be insanely cool.  It would allow one to build ONE XIB
with N modes for iPhone Portrait, iPhone Landscape, iPad Portrait, iPad
Landscape, LTR, RTL, and so on, all sharing a base set of controls, views,
and connections to outlets and actions.


On Mon, Mar 19, 2012 at 2:20 PM, Brian Lambert wrote:

> In Interface Builder all coordinates are expressed in terms of a
> non-Retina device, and scaled on Retina devices.  So running a XIB on
> non-Retina and Retina "just works".  The same holds true for doing it in
> code (generally).
>
> I'll give you an example.  One of the projects I'm working on right now is
> a universal app that runs on iPhone, iPhone Retina, iPad, and iPad Retina.
>
> I am using only 3 sets of images and two XIB's to cover all devices.
>
> On the iPhone, I use the iPhoneFoo.xib, which is designed with Yada.png
> images.  When the application is run on an iPhone Retina, the 
> Yada@2x.pngimages are used in places of the Yada.png images automatically.  
> All
> coordinates scale automatically.  It just works.
>
> On the iPad, I use the iPadFoo.xib, which is designed with Yada@2x.pngimages. 
>  I simply use the iPhone's @2x image set as the default set on the
> iPad for non-Retina devices.  When the application is run on an iPad
> Retina, the Yada@2...@2x.png images are used in places of the 
> Yada@2x.pngimages automatically.  All coordinates scale automatically.  It 
> just works.
>
> This has saved me a bunch of work, and a bunch of binary app space.  I'm
> pretty pleased with how iOS works in this department.
>
>
>
>
>
>
>
> On Mon, Mar 19, 2012 at 2:04 PM, Alex Zavatone  wrote:
>
>> Well, let's put it this way; there are other things that need to be
>> cleaned up - like 900 lines of code that are called on viewWillAppear in
>> one class, 8 printed pages of warnings as well as a mix of XML, JSON and
>> comma delimited data structures that are fetched ala http on startup.
>>
>> Looking at all the other cases of how stuff is put together in this app,
>> I thought it safest to ask the people who have been doing this longer
>> rather than just proceed along thinking everything's just fine with this
>> approach.
>>
>> Ya, I've actually gone in and modified the XML before to reposition
>> elements and wasn't sure I had the full grasp on how Xcode/Cocoa does it.
>>  I thought it might be relative to a base coordinate system and then at
>> runtime, a 1.x multiplier might be applied to the plane that the controls
>> are drawn upon.  But, I never had the time to rip through it all and get to
>> the bottom of it all.
>>
>> So, sweet.  Thanks a bunch.
>>
>>
>>
>> On Mar 19, 2012, at 4:22 PM, Brian Lambert wrote:
>>
>> > Hi Alex,
>> >
>> > Regarding you having to "repair" code where "UI elements that have been
>> hardcoded in place with the approach of: Just define the CGRect and we're
>> all good."  I think you're seeing things as being "gross" when they are not.
>>
>>
>
___

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

Please check out my new company, Directr...

[Brian Lambert]

*Hey!

I'm part of a team starting a new company called Directr. We're
turning **personal
moviemaking upside down by allowing **anyone to create beautiful, short,
shareable movies **in just a few minutes.*
*
*
*Starting today, we’re giving our friends a sneak peek into what **we’re
working on and announcing that we’ve raised seed funding from a **top-notch
group of investors. *
*
Check out the TechCrunch article here:
http://techcrunch.com/2012/06/29/directr/

Directr will launch later this summer but, in the meantime, we would love
your support!

It would be awesome if you could:*
*

   - Visit our site at www.directr.co where you can reserve your username
   - Follow us on twitter at http://twitter.com/directrfilms  to stay
   updated and
   - Like us on Facebook at http://www.facebook.com/directrfilms


*
*Thanks!*
*
*
*Brian*
___

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

SO SORRY!

[Brian Lambert]

Please accept my apologies for this mistake. I didn't intend to send my
last message to this list!

Brian
___

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