Delays in awaking iOS app

[Gerriet M. Denkmann]

I have an app with a button.
I start the app, then put the iPhone to sleep.
I wake the phone up and press the button repeatedly, until something happens.

There is an NSLog() in applicationWillEnterForeground: and in the action method 
of the button.
The time difference between these two is 1.1 ... 1.4 seconds.

Did the same with Time Profiler in Instruments: 1.357 seconds elapsed time, 
Running Time 0.044 sec.
That is: my app was doing nothing for about 1.3 seconds.

This is really annoying: one wakes up the phone, the app looks responsive, so 
one taps the button - and nothing happens.
One has to wait a second, tap the button again - and then it works.

How can I find out what is going on?
How to avoid this?

Gerriet.

iOS 7.0.4

P.S. Made a new Single View Application (which has nothing except a Done button 
in a Toolbar at the bottom) and did run it on iPhone 4s:

2014-01-29 21:52:55.540 TestRestart[624:60b] -[T1RAppDelegate 
applicationWillEnterForeground:]
2014-01-29 21:52:55.552 TestRestart[624:60b] -[T1RAppDelegate 
applicationDidBecomeActive:]
2014-01-29 21:52:56.949 TestRestart[624:60b] -[T1RViewController donePressed:]
2014-01-29 21:52:57.157 TestRestart[624:60b] -[T1RViewController donePressed:]
2014-01-29 21:52:57.365 TestRestart[624:60b] -[T1RViewController donePressed:]
2014-01-29 21:52:57.557 TestRestart[624:60b] -[T1RViewController donePressed:]

Again a delay of 1.397 beween applicationDidBecomeActive and the first reaction 
to my button.




___

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: Preserving undo actions on deleted targets

[Michael Starke]

As far as I know (and I use this in my application) if you use the

NSUndoManager prepareWithInvocationTarget:

the proxy that wraps the NSInvocation retains the target. Thus using a 
[[undoManager prepareWithInovationTarget:myObject] remove] call should 
ensure the object lives as long as the undo stack is valid. Works for 
me. If not, I might have a bug there lingering too :)


-Michael

On 29.01.2014 16:30, Matthew LeRoy wrote:

I’m wondering if someone can provide some guidance or best practices on how I 
might preserve actions on the undo/redo stack when the target of those actions 
is deleted?

For example, say I have an application that allows me to add and remove records 
to and from a list — employee records, items in an inventory control system, 
anything really. I have model objects which represents each record, and those 
model objects register undo actions whenever their attributes/properties are 
changed. (I’m fairly certain this is the recommended best practice.)

I also want to be able to delete records, and to be able to undo that deletion. 
The Undo Architecture documentation clearly warns not to leave actions on the 
undo stack whose targets have been deallocated, and points to 
removeAllActionsWithTarget:. OK, so when I delete a record and thus delete the 
corresponding model object, I just call removeAllActionsWithTarget:modelObject 
— easy. But then I realize that now any undo actions that targeted that object 
are gone, and even if I undo the deletion I can’t keep undo-ing any changes 
which were made to that object prior to it being deleted (e.g. undo changing 
the name of an employee, changing the unit cost of an inventory item, etc).

I *think* the right approach here is to not delete/dealloc the model objects 
when their corresponding records are removed/deleted, but instead just remove 
the objects from the collection of “live” objects and hold onto them somewhere 
else for the purposes of re-inserting them in the collection if the deletion is 
undone. I suppose my model code for deleting a record from the live collection 
should register an undo action which calls “undelete” or “insert”; and the code 
for “undelete” or “insert” (and probably “add” as well) should register an undo 
action which calls “delete”?

I also shouldn’t call removeAllActionsWithTarget:modelObject, because there’s 
no way to re-insert those actions back into the undo stack if the deletion is 
undone and the model object is re-inserted back into the “live” collection. 
Instead, I just have to trust that the only way for the undo actions which 
target the “deleted” model object to get sent is for the undo action which 
undeletes the object to be sent first (because it is higher on the undo stack), 
thus putting the object back into the live collection. I don’t need to worry 
about undo actions getting sent to deallocated objects, because the objects 
aren’t getting deallocated.

Am I on the right track, or is there some other recommended pattern here?

Matt
___

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/michael.starke%40hicknhack-software.com

This email sent to michael.sta...@hicknhack-software.com



--
___m i c h a e l   s t a r k e
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com

___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com

___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitz - dresden
___

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: Preserving undo actions on deleted targets

[Keary Suska]

On Jan 29, 2014, at 8:30 AM, Matthew LeRoy wrote:

> I *think* the right approach here is to not delete/dealloc the model objects 
> when their corresponding records are removed/deleted, but instead just remove 
> the objects from the collection of “live” objects and hold onto them 
> somewhere else for the purposes of re-inserting them in the collection if the 
> deletion is undone. I suppose my model code for deleting a record from the 
> live collection should register an undo action which calls “undelete” or 
> “insert”; and the code for “undelete” or “insert” (and probably “add” as 
> well) should register an undo action which calls “delete”?

Well, if you want the "delete" action to be undoable, then yes, you would 
register an undo action for it. As the object of an action the "deleted" object 
should be retained by NSUndoManager, so you don't have to track it yourself.

> I also shouldn’t call removeAllActionsWithTarget:modelObject, because there’s 
> no way to re-insert those actions back into the undo stack if the deletion is 
> undone and the model object is re-inserted back into the “live” collection. 
> Instead, I just have to trust that the only way for the undo actions which 
> target the “deleted” model object to get sent is for the undo action which 
> undeletes the object to be sent first (because it is higher on the undo 
> stack), thus putting the object back into the live collection. I don’t need 
> to worry about undo actions getting sent to deallocated objects, because the 
> objects aren’t getting deallocated.

Yes. In my experience, manipulating  NSUndoManager's stack is an exercise in 
frustration, as NSUndoManager's gets itself into an inconsistent state. IMHO 
this is largely due to the opacity of the class, and the near complete lack of 
introspection available.

For completeness I would add that I find it best that each root object in your 
data hierarchy have its own undo manager that it disposes of when the object 
deallocates. This is, for instance, how the document architecture handles it.

HTH,

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

Preserving undo actions on deleted targets

[Matthew LeRoy]

I’m wondering if someone can provide some guidance or best practices on how I 
might preserve actions on the undo/redo stack when the target of those actions 
is deleted?

For example, say I have an application that allows me to add and remove records 
to and from a list — employee records, items in an inventory control system, 
anything really. I have model objects which represents each record, and those 
model objects register undo actions whenever their attributes/properties are 
changed. (I’m fairly certain this is the recommended best practice.)

I also want to be able to delete records, and to be able to undo that deletion. 
The Undo Architecture documentation clearly warns not to leave actions on the 
undo stack whose targets have been deallocated, and points to 
removeAllActionsWithTarget:. OK, so when I delete a record and thus delete the 
corresponding model object, I just call removeAllActionsWithTarget:modelObject 
— easy. But then I realize that now any undo actions that targeted that object 
are gone, and even if I undo the deletion I can’t keep undo-ing any changes 
which were made to that object prior to it being deleted (e.g. undo changing 
the name of an employee, changing the unit cost of an inventory item, etc).

I *think* the right approach here is to not delete/dealloc the model objects 
when their corresponding records are removed/deleted, but instead just remove 
the objects from the collection of “live” objects and hold onto them somewhere 
else for the purposes of re-inserting them in the collection if the deletion is 
undone. I suppose my model code for deleting a record from the live collection 
should register an undo action which calls “undelete” or “insert”; and the code 
for “undelete” or “insert” (and probably “add” as well) should register an undo 
action which calls “delete”?

I also shouldn’t call removeAllActionsWithTarget:modelObject, because there’s 
no way to re-insert those actions back into the undo stack if the deletion is 
undone and the model object is re-inserted back into the “live” collection. 
Instead, I just have to trust that the only way for the undo actions which 
target the “deleted” model object to get sent is for the undo action which 
undeletes the object to be sent first (because it is higher on the undo stack), 
thus putting the object back into the live collection. I don’t need to worry 
about undo actions getting sent to deallocated objects, because the objects 
aren’t getting deallocated.

Am I on the right track, or is there some other recommended pattern here?

Matt
___

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

Xcode 5 & Obj-C++

[Peter Teeson]

I have a project in which I want to take advantage of the C++ Standard library 
(primarily because of the container classes - including the special ones).
FWIW the project has to traverse a directed acyclic graph  (yes I know about 
the boost lib).
For the rest of the project Obj-C and Cocoa is sufficient.
 
All the searching I've done has not turned up anything current about how things 
work 
these days with Xcode 5 and llvm. There is the  2005 ObjC++.pdf which I have 
but Xcode has changed a lot since those days.

I understand that the file extension needs to be .mm to mix Obj-C and C++.
But other than a command line template, which is for C++, there does not seem 
to be one for ObjC++.

Are there any current docs that my search didn't find and that you can point me 
to?
Or advice you can offer to help me?

TIA and respect….

Peter




___

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: Xcode 5 & Obj-C++

[Abdul Sowayan]

Peter,

On Jan 29, 2014, at 12:02 PM, Peter Teeson 
mailto:ptee...@icloud.com>> wrote:

I have a project in which I want to take advantage of the C++ Standard library
(primarily because of the container classes - including the special ones).
FWIW the project has to traverse a directed acyclic graph  (yes I know about 
the boost lib).
For the rest of the project Obj-C and Cocoa is sufficient.

All the searching I've done has not turned up anything current about how things 
work
these days with Xcode 5 and llvm. There is the  2005 ObjC++.pdf which I have
but Xcode has changed a lot since those days.

I understand that the file extension needs to be .mm to mix Obj-C and C++.
But other than a command line template, which is for C++, there does not seem 
to be one for ObjC++.

There are several ways you can do this, I mention two here:

1- As you mentioned, change the file extension to .mm

2- In your build setting (depending on configuration) you will see either of 
the two below

GCC_INPUT_FILETYPE

Compile Sources As

You can change this setting to compile all your files as Objective-C++, 
regardless of the file extension.


Are there any current docs that my search didn't find and that you can point me 
to?
Or advice you can offer to help me?


Well, I’m not clear as to what information you’re trying to find. Can you 
elaborate?

Thanks,
Abdul



TIA and respect….

Peter




___

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/asowayan%40vectorworks.net

This email sent to asowa...@vectorworks.net

___

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: Xcode 5 & Obj-C++

[Scott Ribe]

On Jan 29, 2014, at 10:02 AM, Peter Teeson  wrote:

> But other than a command line template, which is for C++, there does not seem 
> to be one for ObjC++.

Yep. Never has been.

> Are there any current docs that my search didn't find and that you can point 
> me to?
> Or advice you can offer to help me?

Just dive in. It's not hard. Unfortunately, I haven't done this from scratch 
since Xcode 2, so I can't tell you exactly what to do but...

Name a file .mm. Include some C++ headers. Write some C++ code. See how far you 
get ;-)

-- 
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

Re: Preserving undo actions on deleted targets

[Jerry Krinock]

Matt, you have written a good essay illustrating the many twists, turns and 
corners you get into when trying to track Undo yourself.  Redo adds even more 
complexity.

On 2014 Jan 29, at 07:30, Matthew LeRoy  wrote:

> Am I on the right track, or is there some other recommended pattern here?

My recommended pattern is to use Core Data in any app that requires Undo to 
really work.  Boom -  Undo is done, and Apple has covered the edges and corners 
much better than I'd ever have time to.  Admittedly, using Core Data introduces 
other issues, but, unlike home-made Undo, these issues are finite and 
manageable.

On 2014 Jan 29, at 08:07, Keary Suska  wrote:

> In my experience, manipulating  NSUndoManager's stack is an exercise in 
> frustration, as NSUndoManager's gets itself into an inconsistent state. IMHO 
> this is largely due to the opacity of the class, and the near complete lack 
> of introspection available.

Use an Undo Manager which is not opaque…

http://apptree.net/gcundomanager.htm


___

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

Customizing a Mac Installer Package

[Bradley O'Hearne]

Hello, 

I am working on an app which for the present version, must be installed via an 
installer package. The next version will be a Mac App Store app, so this won’t 
be a concern then. But for the time being, the app has its own package 
installer. 

In Xcode (current version), when you create and distribute an archive, and 
attempt to export the option for “Mac Installer Package” it creates an 
installer package that we need to customize. Presently we are using the sorely 
outdated and deprecated PackageMaker app which came with auxiliary tools 
several Xcode versions ago. Aside from the obvious reasons this is undesirable, 
it makes building a two-step process where it only need be one, and also has 
presented some signing issues in the past. 

What I am trying to accomplish is being able to customize the installer with 
some simple branding and addition of a few extra files which need to be 
installed, and I would like do drive it all from Xcode, such that exporting the 
“Mac Installer Package” in the UI creates this custom installer — I don’t know 
if there’s a way to have that process hook a config file, or something like 
that, but that’s the idea. 

Can this be done, and if so, can someone point me in the right direction? 

Thanks, 

Brad
___

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: Layer needs display if presentation layer moves?

[Seth Willits]

It was an endless series of compounding errors yesterday for some reason, but I 
finally managed to get it to work. In retrospect it is easy, but not easily 
discoverable. 



Here's the finished demo project:
http://www.sethwillits.com/temp/CATest_PresentationLayerTracking.zip

In this project a bunch of boxes fly around when you click on the view. Each 
box has a line drawn from the view's origin to the box's lower left corner, and 
the "tricky" part: those lines appropriately follow the boxes while they're 
animating.




I'll try to briefly describe this for posterity:

There's a ConnectionsLayer instance which has a nodeLayers property which is an 
array of all the of boxes' layers. On mouseDown in the view, each box's layer 
is randomly positioned, and then noteNodePositionsChanged is called on the 
connections layer. The ConnectionsLayer's drawInContext simply draws a line 
from the origin to the .position of the presentationLayer of each layer in 
nodeLayers. (The presentationLayer may be nil, so if it is, use the model 
layer's position.)

Now the "tricky" part is this:

- ConnectionsLayer has a private property: @property int nodePositionsDidChange;
- +needsDisplayForKey: returns YES for "nodePositionsDidChange" (calls super 
for anything else)
- noteNodePositionsChanged calls:
[self addAnimation:[CABasicAnimation 
animationWithKeyPath:@"nodePositionsDidChange"] 
forKey:@"animateForNodePositionsChange"];


The nodePositionsDidChange property itself is never set or get. It's simply 
there so that we can "animate" it, and Core Animation will recognize (via 
+needsDisplayForKey :) that while this property is animating, the layer should 
be redisplayed. Boom. (It's a bit voodoo that it can animate even though the 
value doesn't change at all, but there you go.)



The only "negative" part to this approach is that even if none of the boxes 
change positions, if noteNodePositionsChanged is called then it will redraw 
many times for whatever the duration of the animation is. So for efficiency's 
sake, noteNodePositionsChanged should only be called if a box's position 
actually did change. Ideally, we wouldn't need to call noteNodePositionsChanged 
manually at all.


Hopefully that helps anyone else looking for this in the future.


--
Seth Willits



___

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: Layer needs display if presentation layer moves?

[Kyle Sluder]

On Wed, Jan 29, 2014, at 11:44 AM, Seth Willits wrote:
> 
> - ConnectionsLayer has a private property: @property int
> nodePositionsDidChange;
> - +needsDisplayForKey: returns YES for "nodePositionsDidChange" (calls
> super for anything else)
> - noteNodePositionsChanged calls:
>   [self addAnimation:[CABasicAnimation 
> animationWithKeyPath:@"nodePositionsDidChange"] 
> forKey:@"animateForNodePositionsChange"];
> 
> 
> The nodePositionsDidChange property itself is never set or get. It's
> simply there so that we can "animate" it, and Core Animation will
> recognize (via +needsDisplayForKey :) that while this property is
> animating, the layer should be redisplayed. Boom. (It's a bit voodoo that
> it can animate even though the value doesn't change at all, but there you
> go.)
> 
> 
> 
> The only "negative" part to this approach is that even if none of the
> boxes change positions, if noteNodePositionsChanged is called then it
> will redraw many times for whatever the duration of the animation is. So
> for efficiency's sake, noteNodePositionsChanged should only be called if
> a box's position actually did change. Ideally, we wouldn't need to call
> noteNodePositionsChanged manually at all.

Interesting that you chose this approach. I haven't gotten around to
writing it up yet, but the past day or so of thinking through the
problem, but I was coming to the conclusion that the only way to get
this to work reliably would be to not rely on implicit animations at
all.

Instead, when you wanted to animate the subtree, you'd need to add
explicit CAAnimations to the entire tree.

//begin
@implementation MyView
- (void)animateLayerTree {
  [CATransaction begin];

  // Generate a CALayer -> NSValue(CGPoint) map
  NSDictionary *sublayerToPositionMap = [self
  _generateMapOfSublayersToNewPositions];

  CAAnimationGroup *connectionsAnimGroup = [CAAnimationGroup animation];

  for (CALayer *sublayer in sublayerToPositionMap.allKeys) {
CGPoint oldPosition = sublayer.position;
CGPoint newPosition = [sublayerToPositionMap
objectForKey:sublayer].pointValue;
sublayer.position = newPosition;

CGPoint oldConnectionEndpoint = [_connectionsLayer
convertPoint:oldPosition fromLayer:sublayer];
CGPoint newConnectionEndpoint = [_connectionsLayer
convertPoint:newPosition fromLayer:sublayer];
[connectionsAnimGroup addAnimation:[MyConnectionsAnimation
animationOfLineNamed:sublayer.name
  fromPoint:oldConnectionEndpoint toPoint:newConnectionEndpoint];
  }

  // The connections layer returns YES for
  +needsDisplayForKey:@"connections"
  // TODO: Support retargeting animations mid-flight
  [_connectionsLayer addAnimation:connectionsAnimGroup
  forKey:@"connections"];

  [CATransaction commit];
}
//end

This at least avoids the possibility that CA might stop sending
-setNeedsDisplay for a key which never changes, and it feels less
"magic".

--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: Layer needs display if presentation layer moves?

[Kyle Sluder]

On Wed, Jan 29, 2014, at 12:14 PM, Kyle Sluder wrote:
> [connectionsAnimGroup addAnimation:[MyConnectionsAnimation
> animationOfLineNamed:sublayer.name
>   fromPoint:oldConnectionEndpoint toPoint:newConnectionEndpoint];
>   }
> 
>   // The connections layer returns YES for
>   +needsDisplayForKey:@"connections"
>   // TODO: Support retargeting animations mid-flight
>   [_connectionsLayer addAnimation:connectionsAnimGroup
>   forKey:@"connections"];

Also, I'm not quite happy with this pseudocode. It would be a lot nicer
if you could add an animation for a key _path_, rather than just a key.

But I suppose instead of an animation group, you could just paste a
prefix to the layer name and add a bunch of individual animations
directly to the connections layer.

The joys of writing code in the Compose window.

--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: Xcode 5 & Obj-C++

[Jens Alfke]

On Jan 29, 2014, at 9:02 AM, Peter Teeson  wrote:

> I understand that the file extension needs to be .mm to mix Obj-C and C++.
> But other than a command line template, which is for C++, there does not seem 
> to be one for ObjC++.

It's honestly not any different. You're writing Objective-C code but you can 
use all of the extensions that C++ adds. (Or alternatively, you're writing C++ 
code but you can use Objective-C types and message objects. It depends on your 
use case.)

So for example you have an Objective-C class that wants to use std::vector. 
Cool, just add "#include ", then use std::vector wherever you want.

Just avoid using C++ syntax or types in the class header, otherwise you won't 
be able to #import it from any non-Obj-C++ source files. (Or alternatively you 
could just make all of your source files use Obj-C++.)

—Jens
___

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: Preserving undo actions on deleted targets

[Keary Suska]

On Jan 29, 2014, at 10:27 AM, Jerry Krinock wrote:

> On 2014 Jan 29, at 08:07, Keary Suska  wrote:
> 
>> In my experience, manipulating  NSUndoManager's stack is an exercise in 
>> frustration, as NSUndoManager's gets itself into an inconsistent state. IMHO 
>> this is largely due to the opacity of the class, and the near complete lack 
>> of introspection available.
> 
> Use an Undo Manager which is not opaque…
> 
> http://apptree.net/gcundomanager.htm


Absolutely, and I have found it invaluable to troubleshoot state issues, but 
unfortunately it is not App Store safe (read: basis for rejection), as it 
relies on a private method call for proper NSDocument change tracking...

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: Delays in awaking iOS app

[Rick Mann]

I've seen behaviors like this with other apps, i.e. the Google Hangouts app. 
The keyboard will be active from a chat, and I'll leave the app. Then I'll get 
a notification that a message came in, go to the app, and there's some period 
of time before the keyboard becomes responsive.

I think I only see this in iOS 7. On 6.1, it's much faster, but I'd be curious 
if you see the same difference in your tests.

On Jan 29, 2014, at 07:02 , Gerriet M. Denkmann  wrote:

> 
> I have an app with a button.
> I start the app, then put the iPhone to sleep.
> I wake the phone up and press the button repeatedly, until something happens.
> 
> There is an NSLog() in applicationWillEnterForeground: and in the action 
> method of the button.
> The time difference between these two is 1.1 ... 1.4 seconds.
> 
> Did the same with Time Profiler in Instruments: 1.357 seconds elapsed time, 
> Running Time 0.044 sec.
> That is: my app was doing nothing for about 1.3 seconds.
> 
> This is really annoying: one wakes up the phone, the app looks responsive, so 
> one taps the button - and nothing happens.
> One has to wait a second, tap the button again - and then it works.
> 
> How can I find out what is going on?
> How to avoid this?
> 
> Gerriet.
> 
> iOS 7.0.4
> 
> P.S. Made a new Single View Application (which has nothing except a Done 
> button in a Toolbar at the bottom) and did run it on iPhone 4s:
> 
> 2014-01-29 21:52:55.540 TestRestart[624:60b] -[T1RAppDelegate 
> applicationWillEnterForeground:]
> 2014-01-29 21:52:55.552 TestRestart[624:60b] -[T1RAppDelegate 
> applicationDidBecomeActive:]
> 2014-01-29 21:52:56.949 TestRestart[624:60b] -[T1RViewController donePressed:]
> 2014-01-29 21:52:57.157 TestRestart[624:60b] -[T1RViewController donePressed:]
> 2014-01-29 21:52:57.365 TestRestart[624:60b] -[T1RViewController donePressed:]
> 2014-01-29 21:52:57.557 TestRestart[624:60b] -[T1RViewController donePressed:]
> 
> Again a delay of 1.397 beween applicationDidBecomeActive and the first 
> reaction to my button.
> 
> 
> 
> 
> ___
> 
> 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/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


-- 
Rick





signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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: Preserving undo actions on deleted targets

[Matthew LeRoy]

On Jan 29, 2014, at 11:07 AM, Keary Suska  wrote:

> As the object of an action the "deleted" object should be retained by 
> NSUndoManager, so you don't have to track it yourself.

*light bulb*
For whatever reason, I had it in my head that neither the target of the undo 
action nor the parameter(s) were retained — but now that I read the docs more 
carefully, I see that the parameter to the action (“object” in the 
documentation) is retained, in both the simple 
(registerUndoWithTarget:selector:object:) and invocation-based 
(prepareWithInvocationTarget:) cases.

This also answers another question I was going to ask:

if I were manually holding onto model objects which had been removed as part of 
some undoable/redoable action, it occurred to me that any object which got 
removed as part of an undo (e.g. undoing an “add”) would need to be held onto 
in case of a redo. But, if the user performed some other undoable action 
instead, then the redo stack will be cleared and any objects I was holding onto 
(in case they needed to be re-added as part of a redo) would no longer be 
needed. Thus, I would need some way of being notified when the redo stack gets 
cleared so that I could release any such objects.

But if the NSUndoManager is the one retaining those objects, then presumably 
the objects will get released automatically when the redo stack gets cleared. 
Plus, any additional actions which target those objects would have to also be 
on the redo stack, below the “redo add object” action, and so those actions 
will also get removed when the redo stack is cleared and there’s no concern of 
any lingering actions whose target is the now-deallocated object.

> For completeness I would add that I find it best that each root object in 
> your data hierarchy have its own undo manager that it disposes of when the 
> object deallocates. This is, for instance, how the document architecture 
> handles it.

My app is document-based and I am indeed using the undo manager for each 
document in exactly this way.

Many thanks for the pointers!

Matt
___

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: Xcode 5 & Obj-C++

[koko]

On Jan 29, 2014, at 1:48 PM, Jens Alfke  wrote:

> 
> On Jan 29, 2014, at 9:02 AM, Peter Teeson  wrote:
> 
>> I understand that the file extension needs to be .mm to mix Obj-C and C++.
>> But other than a command line template, which is for C++, there does not 
>> seem to be one for ObjC++.
 

All my projects are Obj-C and C++ mixed so rather than change any file 
extension I just set in the Language section of Build Setting Compile Sources 
As Objective-C++

-koko
___

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: Preserving undo actions on deleted targets

[Graham Cox]

On 30 Jan 2014, at 8:03 am, Keary Suska  wrote:

> Absolutely, and I have found it invaluable to troubleshoot state issues, but 
> unfortunately it is not App Store safe (read: basis for rejection), as it 
> relies on a private method call for proper NSDocument change tracking...


It does?

I'm using it in an App Store app without it ever having come up as an issue. 
Have you actually had this flagged as an issue by The Keepers Of The Store™?

If you're referring to:

- (void)_processEndOfEventNotification:(NSNotification*) note


I'm not sure that counts as using private API as such. It's just a stub for a 
method that NSDocument calls on its undo manager, and as you can see it's only 
a notification handler (containing no code). It's needed because NSDocument 
doesn't check whether the undo manager implements it before calling it, so it 
will cause an unrecognised selector exception if it's not there, but it's not 
actually calling any private API itself anywhere - NSDocument is.

If you subclassed NSUndoManager, you would be "using" this private method, but 
since GCUndoManager isn't a subclass, the stub is needed so that the 
replacement object mimics the original correctly, in accordance with the idea 
of duck-typing. If anything, Apple should be either checking for the existence 
of the method before invoking it, or making it public.

--Graham
___

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: Xcode 5 & Obj-C++

[Uli Kusterer]

On 29 Jan 2014, at 18:02, Peter Teeson  wrote:
> All the searching I've done has not turned up anything current about how 
> things work 
> these days with Xcode 5 and llvm. There is the  2005 ObjC++.pdf which I have 
> but Xcode has changed a lot since those days.

 I talked about ObjC++ on NSBrief a while ago: 
http://nsbrief.com/113-uli-kusterer/ It’s a very comprehensive summary of all 
the tricks and techniques I commonly use, plus an introduction into how the 
whole thing behaves.

> I understand that the file extension needs to be .mm to mix Obj-C and C++.
> But other than a command line template, which is for C++, there does not seem 
> to be one for ObjC++.

 It’s not needed. You can just add .mm files to a project created from the 
ObjC++ template and it’ll work. IIRC you don’t even have to add the -lc++ 
option to add the C++ standard library anymore.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: Preserving undo actions on deleted targets

[Graham Cox]

On 30 Jan 2014, at 3:03 am, Michael Starke 
 wrote:

> NSUndoManager prepareWithInvocationTarget:
> 
> the proxy that wraps the NSInvocation retains the target. Thus using a 
> [[undoManager prepareWithInovationTarget:myObject] remove] call should ensure 
> the object lives as long as the undo stack is valid. Works for me. If not, I 
> might have a bug there lingering too :)


This isn't quite the case.

The target of an undo invocation is not normally retained. NSInvocation *can* 
be set to retain its target, but under normal circumstances when it's used by 
NSUndoManager, it does not. If you think about it, that's correct, because 
otherwise retain cycles would all too easily be set up, e.g. NSDocument retains 
NSUndoManager which retains the NSInvocations that wrap the undo actions. If 
the target of an undo action were NSDocument itself - quite reasonably, because 
NSDocument typically owns your data model - then you have a situation where the 
document will never be released because the undo manager is retaining it (many 
times for a large undo stack).

Instead, the target isn't retained, but the parameters to the invocation are, 
if they're objects. In normal circumstances, this is correct, safe and gives 
proper memory management, even in the case of adding or deleting objects, 
because for those operations, the target of the undo is NOT the objects being 
added or deleted, but the object that OWNS the added or deleted objects, i.e. 
some higher entity in your data model. For this case, the objects being 
added/deleted are parameters to the operation, not the target, so they're 
retained. Because of this, other undoable operations where the target *is* the 
added object work correctly, e.g. if you added an object and then changed its 
state, both operations can be undoable, because the add operation targeted a 
higher level object and retained the added object as a parameter, and the state 
change targeted the added object, which is being retained by an earlier 
invocation. It makes correct memory management sensitive to the ordering of 
undo tasks within the stack, but that's OK as long as you make sure every thing 
you do to your data model is undoable - which you probably want. If you leave 
out e.g. adding or deleting, but make all state changes to these objects 
undoable, chances are sooner or later you'll get into trouble.

If your head is spinning and your mind boggled, welcome to the club. Undo does 
that to you.

My simple guidelines for Undo nirvana are: 1. Undo *everything*. 2. Always make 
the target the object that owns the state you're undoing.

Rule 2 means, for objects being added or deleted, that the target should be the 
container of the added or deleted objects, not the added or deleted objects 
themselves.

A further thing to note is that one nice thing about NSUndoManager (there's a 
nice thing? who knew!) is that if you make every operation on your data model 
undoable, higher level code can cause several operations to be performed one 
after the other if necessary and Undo will group these all together 
automatically so Undo should "Just Work™" in reversing all of these operations. 
There's nothing that says that all of the targets within a group must be the 
same, and you'll find that the order of tasks in the stack and the retains 
involved are exactly correct to ensure memory management is correct as well.

--Graham



___

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: Xcode 5 & Obj-C++

[Rui Pacheco]

To those of you doing Objective-C++ apps, is there a difference in terms of 
performance or memory usage?

I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less 
memory than the Chocolat editor which seems to be done exclusively in Cocoa.

On 30 Jan 2014, at 00:04, Uli Kusterer  wrote:

> On 29 Jan 2014, at 18:02, Peter Teeson  wrote:
>> All the searching I've done has not turned up anything current about how 
>> things work 
>> these days with Xcode 5 and llvm. There is the  2005 ObjC++.pdf which I have 
>> but Xcode has changed a lot since those days.
> 
> I talked about ObjC++ on NSBrief a while ago: 
> http://nsbrief.com/113-uli-kusterer/ It’s a very comprehensive summary of all 
> the tricks and techniques I commonly use, plus an introduction into how the 
> whole thing behaves.
> 
>> I understand that the file extension needs to be .mm to mix Obj-C and C++.
>> But other than a command line template, which is for C++, there does not 
>> seem to be one for ObjC++.
> 
> It’s not needed. You can just add .mm files to a project created from the 
> ObjC++ template and it’ll work. IIRC you don’t even have to add the -lc++ 
> option to add the C++ standard library anymore.
> 
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
> 
> 
> ___
> 
> 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/rui.pacheco%40gmail.com
> 
> This email sent to rui.pach...@gmail.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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: Xcode 5 & Obj-C++

[Jens Alfke]

On Jan 29, 2014, at 3:16 PM, Rui Pacheco  wrote:

> To those of you doing Objective-C++ apps, is there a difference in terms of 
> performance or memory usage?
> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less 
> memory than the Chocolat editor which seems to be done exclusively in Cocoa.

You can't generalize. In theory C++ is more efficient, but it's perfectly 
possible to write bloated code in C++ and plenty of people have done it. (In 
particular, big class libraries can result in humungous vtables, and templates 
and inlining can cause code-size explosions.) 

It's also all too easy to write unmaintainable code in C++, and that's often an 
even more important factor to a developer than performance. Objective-C is 
simpler, but it's also clearer.

—Jens
___

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: Preserving undo actions on deleted targets

[Keary Suska]

On Jan 29, 2014, at 3:44 PM, Graham Cox wrote:

> 
> On 30 Jan 2014, at 8:03 am, Keary Suska  wrote:
> 
>> Absolutely, and I have found it invaluable to troubleshoot state issues, but 
>> unfortunately it is not App Store safe (read: basis for rejection), as it 
>> relies on a private method call for proper NSDocument change tracking...
> 
> It does?
> I'm using it in an App Store app without it ever having come up as an issue. 
> Have you actually had this flagged as an issue by The Keepers Of The Store™?
> 
> If you're referring to:
> 
> - (void)  _processEndOfEventNotification:(NSNotification*) note
> 
> 
> I'm not sure that counts as using private API as such. It's just a stub for a 
> method that NSDocument calls on its undo manager, and as you can see it's 
> only a notification handler (containing no code). It's needed because 
> NSDocument doesn't check whether the undo manager implements it before 
> calling it, so it will cause an unrecognised selector exception if it's not 
> there, but it's not actually calling any private API itself anywhere - 
> NSDocument is.
> 
> If you subclassed NSUndoManager, you would be "using" this private method, 
> but since GCUndoManager isn't a subclass, the stub is needed so that the 
> replacement object mimics the original correctly, in accordance with the idea 
> of duck-typing. If anything, Apple should be either checking for the 
> existence of the method before invoking it, or making it public.



I haven't had the misfortune of a rejection on that basis but it is good to 
know that I can keep it in my next app. I should have said, "may be" rather 
than "is"--I was extrapolating from a different case a colleague experienced 
where they experienced a rejection from calling a private method, but I think 
that was iOS, and maybe the rules are more stringent there. I haven't read the 
latest App Store guidelines so I can't be sure. Hopefully the inconsistencies 
in approvals are a thing of the past...

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: Xcode 5 & Obj-C++

[Uli Kusterer]

On 30 Jan 2014, at 00:16, Rui Pacheco  wrote:
> To those of you doing Objective-C++ apps, is there a difference in terms of 
> performance or memory usage?
> 
> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less 
> memory than the Chocolat editor which seems to be done exclusively in Cocoa.

 Give the nature of C++, it’s not surprising that performance can often be 
better. They generally tend to put a higher emphasis on performance than on 
programmer comfort, maintainability etc. Also, C++ can do a lot of mean tricks 
due to the more static nature of the language. E.g. their method dispatch is 
not easy to keep binary stable across releases, so is really badly suited for 
API design in dylibs or frameworks, but probably only needs two pointer 
dereferences and one addition to resolve a method, while ObjC actually has to 
perform the look-up at runtime, but therefore works much better as a library 
API.

 I don’t usually have to drop down to C++ unless:

1) I’m in very performance-critical code, like device drivers, video decoders 
etc.
2) I need my code to be cross-platform, because C++ is really the most reliably 
available OO-language everywhere from Android to Windows to iOS.

 Unless you’re in one of those situations, I wouldn’t drop down to C++ just 
because it “is probably faster”. It helps nobody if your app crashes faster 
because all that code you rewrote that you’d get for free in ObjC or C# or the 
ADK is buggy. The more people use a piece of code, the more likely it is one of 
them found a bug got it fixed. Tested code is always better than new, “fast” 
code.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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: Xcode 5 & Obj-C++

[SevenBits]

On Jan 29, 2014, at 6:41 PM, Uli Kusterer  wrote:

> On 30 Jan 2014, at 00:16, Rui Pacheco  wrote:
>> To those of you doing Objective-C++ apps, is there a difference in terms of 
>> performance or memory usage?
>> 
>> I’ve noticed that TextMate 2, which is done in Objective-C++, consumes less 
>> memory than the Chocolat editor which seems to be done exclusively in Cocoa.
> 
> Give the nature of C++, it’s not surprising that performance can often be 
> better. They generally tend to put a higher emphasis on performance than on 
> programmer comfort, maintainability etc. Also, C++ can do a lot of mean 
> tricks due to the more static nature of the language. E.g. their method 
> dispatch is not easy to keep binary stable across releases, so is really 
> badly suited for API design in dylibs or frameworks, but probably only needs 
> two pointer dereferences and one addition to resolve a method, while ObjC 
> actually has to perform the look-up at runtime, but therefore works much 
> better as a library API.
> 
> I don’t usually have to drop down to C++ unless:
> 
> 1) I’m in very performance-critical code, like device drivers, video decoders 
> etc.
> 2) I need my code to be cross-platform, because C++ is really the most 
> reliably available OO-language everywhere from Android to Windows to iOS.
> 
> Unless you’re in one of those situations, I wouldn’t drop down to C++ just 
> because it “is probably faster”. It helps nobody if your app crashes faster 
> because all that code you rewrote that you’d get for free in ObjC or C# or 
> the ADK is buggy. The more people use a piece of code, the more likely it is 
> one of them found a bug got it fixed. Tested code is always better than new, 
> “fast” code.

Unfortunately, sometimes you have to use C++, because there are many cool and 
useful libraries for it, as I’m sure most of you know. Many people (but not 
all) use C++ not because they want to or think it’s “fast”, but because they 
have to to leverage an existing library or codebase.

> 
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
> 
> 
> ___
> 
> 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/sevenbitstech%40gmail.com
> 
> This email sent to sevenbitst...@gmail.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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: Delays in awaking iOS app

[Gerriet M. Denkmann]

On 30 Jan 2014, at 04:05, Rick Mann  wrote:

> I've seen behaviors like this with other apps, i.e. the Google Hangouts app. 
> The keyboard will be active from a chat, and I'll leave the app. Then I'll 
> get a notification that a message came in, go to the app, and there's some 
> period of time before the keyboard becomes responsive.
> 
> I think I only see this in iOS 7. On 6.1, it's much faster, but I'd be 
> curious if you see the same difference in your tests.

I do not have any device with iOS 6. But I am absolutely certain that had I 
seen this delay in iOS 6, I would have investigated it (as it is so annoying); 
which means that there was no noticeable delay before iOS 7.

> 
> On Jan 29, 2014, at 07:02 , Gerriet M. Denkmann  wrote:
> 
>> 
>> I have an app with a button.
>> I start the app, then put the iPhone to sleep.
>> I wake the phone up and press the button repeatedly, until something happens.
>> 
>> There is an NSLog() in applicationWillEnterForeground: and in the action 
>> method of the button.
>> The time difference between these two is 1.1 ... 1.4 seconds.
>> 
>> Did the same with Time Profiler in Instruments: 1.357 seconds elapsed time, 
>> Running Time 0.044 sec.
>> That is: my app was doing nothing for about 1.3 seconds.
>> 
>> This is really annoying: one wakes up the phone, the app looks responsive, 
>> so one taps the button - and nothing happens.
>> One has to wait a second, tap the button again - and then it works.
>> 
>> How can I find out what is going on?
>> How to avoid this?
>> 
>> Gerriet.
>> 
>> iOS 7.0.4
>> 
>> P.S. Made a new Single View Application (which has nothing except a Done 
>> button in a Toolbar at the bottom) and did run it on iPhone 4s:
>> 
>> 2014-01-29 21:52:55.540 TestRestart[624:60b] -[T1RAppDelegate 
>> applicationWillEnterForeground:]
>> 2014-01-29 21:52:55.552 TestRestart[624:60b] -[T1RAppDelegate 
>> applicationDidBecomeActive:]
>> 2014-01-29 21:52:56.949 TestRestart[624:60b] -[T1RViewController 
>> donePressed:]
>> 2014-01-29 21:52:57.157 TestRestart[624:60b] -[T1RViewController 
>> donePressed:]
>> 2014-01-29 21:52:57.365 TestRestart[624:60b] -[T1RViewController 
>> donePressed:]
>> 2014-01-29 21:52:57.557 TestRestart[624:60b] -[T1RViewController 
>> donePressed:]
>> 
>> Again a delay of 1.397 beween applicationDidBecomeActive and the first 
>> reaction to my button.
>> 
>> 
>> 
>> 
>> ___
>> 
>> 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/rmann%40latencyzero.com
>> 
>> This email sent to rm...@latencyzero.com
> 
> 
> -- 
> Rick
> 
> 
> 


___

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: Delays in awaking iOS app

[Rick Mann]

All I can say is to write a bug. I did, regarding the Hangouts keyboard delay.

On Jan 29, 2014, at 16:00 , Gerriet M. Denkmann  wrote:

> 
> On 30 Jan 2014, at 04:05, Rick Mann  wrote:
> 
>> I've seen behaviors like this with other apps, i.e. the Google Hangouts app. 
>> The keyboard will be active from a chat, and I'll leave the app. Then I'll 
>> get a notification that a message came in, go to the app, and there's some 
>> period of time before the keyboard becomes responsive.
>> 
>> I think I only see this in iOS 7. On 6.1, it's much faster, but I'd be 
>> curious if you see the same difference in your tests.
> 
> I do not have any device with iOS 6. But I am absolutely certain that had I 
> seen this delay in iOS 6, I would have investigated it (as it is so 
> annoying); which means that there was no noticeable delay before iOS 7.
> 
>> 
>> On Jan 29, 2014, at 07:02 , Gerriet M. Denkmann  wrote:
>> 
>>> 
>>> I have an app with a button.
>>> I start the app, then put the iPhone to sleep.
>>> I wake the phone up and press the button repeatedly, until something 
>>> happens.
>>> 
>>> There is an NSLog() in applicationWillEnterForeground: and in the action 
>>> method of the button.
>>> The time difference between these two is 1.1 ... 1.4 seconds.
>>> 
>>> Did the same with Time Profiler in Instruments: 1.357 seconds elapsed time, 
>>> Running Time 0.044 sec.
>>> That is: my app was doing nothing for about 1.3 seconds.
>>> 
>>> This is really annoying: one wakes up the phone, the app looks responsive, 
>>> so one taps the button - and nothing happens.
>>> One has to wait a second, tap the button again - and then it works.
>>> 
>>> How can I find out what is going on?
>>> How to avoid this?
>>> 
>>> Gerriet.
>>> 
>>> iOS 7.0.4
>>> 
>>> P.S. Made a new Single View Application (which has nothing except a Done 
>>> button in a Toolbar at the bottom) and did run it on iPhone 4s:
>>> 
>>> 2014-01-29 21:52:55.540 TestRestart[624:60b] -[T1RAppDelegate 
>>> applicationWillEnterForeground:]
>>> 2014-01-29 21:52:55.552 TestRestart[624:60b] -[T1RAppDelegate 
>>> applicationDidBecomeActive:]
>>> 2014-01-29 21:52:56.949 TestRestart[624:60b] -[T1RViewController 
>>> donePressed:]
>>> 2014-01-29 21:52:57.157 TestRestart[624:60b] -[T1RViewController 
>>> donePressed:]
>>> 2014-01-29 21:52:57.365 TestRestart[624:60b] -[T1RViewController 
>>> donePressed:]
>>> 2014-01-29 21:52:57.557 TestRestart[624:60b] -[T1RViewController 
>>> donePressed:]
>>> 
>>> Again a delay of 1.397 beween applicationDidBecomeActive and the first 
>>> reaction to my button.
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 
>>> 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/rmann%40latencyzero.com
>>> 
>>> This email sent to rm...@latencyzero.com
>> 
>> 
>> -- 
>> Rick
>> 
>> 
>> 
> 


-- 
Rick





signature.asc
Description: Message signed with OpenPGP using GPGMail
___

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: Customizing a Mac Installer Package

[Charles Srstka]

On Jan 29, 2014, at 11:36 AM, Bradley O'Hearne  
wrote:

> Hello, 
> 
> I am working on an app which for the present version, must be installed via 
> an installer package. The next version will be a Mac App Store app, so this 
> won’t be a concern then. But for the time being, the app has its own package 
> installer. 
> 
> In Xcode (current version), when you create and distribute an archive, and 
> attempt to export the option for “Mac Installer Package” it creates an 
> installer package that we need to customize. Presently we are using the 
> sorely outdated and deprecated PackageMaker app which came with auxiliary 
> tools several Xcode versions ago. Aside from the obvious reasons this is 
> undesirable, it makes building a two-step process where it only need be one, 
> and also has presented some signing issues in the past. 
> 
> What I am trying to accomplish is being able to customize the installer with 
> some simple branding and addition of a few extra files which need to be 
> installed, and I would like do drive it all from Xcode, such that exporting 
> the “Mac Installer Package” in the UI creates this custom installer — I don’t 
> know if there’s a way to have that process hook a config file, or something 
> like that, but that’s the idea. 
> 
> Can this be done, and if so, can someone point me in the right direction? 

Have a look at the pkgbuild(1) and productbuild(1) command line tools, and see 
if they are capable of building a package which is customized to your 
specifications. If so, you can put the appropriate invocations into your build 
scripts.

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: Delays in awaking iOS app

[Gerriet M. Denkmann]

On 30 Jan 2014, at 07:01, Rick Mann  wrote:

> All I can say is to write a bug. I did, regarding the Hangouts keyboard delay.
I planned to do so (but was waiting for 7.1 to appear). But I might as well do 
it now. Done: 15941951.

> 
> On Jan 29, 2014, at 16:00 , Gerriet M. Denkmann  wrote:
> 
>> 
>> On 30 Jan 2014, at 04:05, Rick Mann  wrote:
>> 
>>> I've seen behaviors like this with other apps, i.e. the Google Hangouts 
>>> app. The keyboard will be active from a chat, and I'll leave the app. Then 
>>> I'll get a notification that a message came in, go to the app, and there's 
>>> some period of time before the keyboard becomes responsive.
>>> 
>>> I think I only see this in iOS 7. On 6.1, it's much faster, but I'd be 
>>> curious if you see the same difference in your tests.
>> 
>> I do not have any device with iOS 6. But I am absolutely certain that had I 
>> seen this delay in iOS 6, I would have investigated it (as it is so 
>> annoying); which means that there was no noticeable delay before iOS 7.
>> 
>>> 
>>> On Jan 29, 2014, at 07:02 , Gerriet M. Denkmann  
>>> wrote:
>>> 
 
 I have an app with a button.
 I start the app, then put the iPhone to sleep.
 I wake the phone up and press the button repeatedly, until something 
 happens.
 
 There is an NSLog() in applicationWillEnterForeground: and in the action 
 method of the button.
 The time difference between these two is 1.1 ... 1.4 seconds.
 
 Did the same with Time Profiler in Instruments: 1.357 seconds elapsed 
 time, Running Time 0.044 sec.
 That is: my app was doing nothing for about 1.3 seconds.
 
 This is really annoying: one wakes up the phone, the app looks responsive, 
 so one taps the button - and nothing happens.
 One has to wait a second, tap the button again - and then it works.
 
 How can I find out what is going on?
 How to avoid this?
 
 Gerriet.
 
 iOS 7.0.4
 
 P.S. Made a new Single View Application (which has nothing except a Done 
 button in a Toolbar at the bottom) and did run it on iPhone 4s:
 
 2014-01-29 21:52:55.540 TestRestart[624:60b] -[T1RAppDelegate 
 applicationWillEnterForeground:]
 2014-01-29 21:52:55.552 TestRestart[624:60b] -[T1RAppDelegate 
 applicationDidBecomeActive:]
 2014-01-29 21:52:56.949 TestRestart[624:60b] -[T1RViewController 
 donePressed:]
 2014-01-29 21:52:57.157 TestRestart[624:60b] -[T1RViewController 
 donePressed:]
 2014-01-29 21:52:57.365 TestRestart[624:60b] -[T1RViewController 
 donePressed:]
 2014-01-29 21:52:57.557 TestRestart[624:60b] -[T1RViewController 
 donePressed:]
 
 Again a delay of 1.397 beween applicationDidBecomeActive and the first 
 reaction to my button.

___

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: Xcode 5 & Obj-C++

[Eric Wing]

On 1/29/14, Uli Kusterer  wrote:
> On 30 Jan 2014, at 00:16, Rui Pacheco  wrote:
>> To those of you doing Objective-C++ apps, is there a difference in terms
>> of performance or memory usage?
>>
>> I've noticed that TextMate 2, which is done in Objective-C++, consumes
>> less memory than the Chocolat editor which seems to be done exclusively in
>> Cocoa.
>
>  Give the nature of C++, it's not surprising that performance can often be
> better. They generally tend to put a higher emphasis on performance than on
> programmer comfort, maintainability etc. Also, C++ can do a lot of mean
> tricks due to the more static nature of the language. E.g. their method
> dispatch is not easy to keep binary stable across releases, so is really
> badly suited for API design in dylibs or frameworks, but probably only needs
> two pointer dereferences and one addition to resolve a method, while ObjC
> actually has to perform the look-up at runtime, but therefore works much
> better as a library API.
>
>  I don't usually have to drop down to C++ unless:
>
> 1) I'm in very performance-critical code, like device drivers, video
> decoders etc.
> 2) I need my code to be cross-platform, because C++ is really the most
> reliably available OO-language everywhere from Android to Windows to iOS.
>
>  Unless you're in one of those situations, I wouldn't drop down to C++ just
> because it "is probably faster". It helps nobody if your app crashes faster
> because all that code you rewrote that you'd get for free in ObjC or C# or
> the ADK is buggy. The more people use a piece of code, the more likely it is
> one of them found a bug got it fixed. Tested code is always better than new,
> "fast" code.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://zathras.de
>
>

- Additionally, C++ will typically increase your compile and link times.

- Binary compatibility (already mentioned) is a pain, so libraries
need to be extremely careful. Additionally, use of templates often
leads to lots more symbols and larger binary size (dynamic libraries
can't really be stripped for unused symbols).

- Often when comparing Obj-C vs. C++, method dispatch is one of the
main culprits for the performance difference. But don't forget, Obj-C
is a pure superset of C and you can always use good old C to get the
same performance benefits if you don't need/want the Obj-C features.
Other really high performance situations deal with cache and memory
layout and it turns out that much of the C++ standard library is not
well suited for dealing with this and going back to POD types and
essentially C (if not assembly) is often better for performance.

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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: Xcode 5 & Obj-C++

[Jens Alfke]

On Jan 29, 2014, at 4:28 PM, Eric Wing  wrote:

> - Additionally, C++ will typically increase your compile and link times.

Oh my yes. The C++ compiler generates huge amounts of symbolic data and nearly 
chokes the linker. The last big C++ project I worked on (Chrome) took over a 
minute just to link, which meant the turnaround was at least that long if I 
made a one-line change. By creating a RAM disk(!) to store the build output I 
was able to speed that up to 30 sec, which was painful but better.

> - Binary compatibility (already mentioned) is a pain, so libraries
> need to be extremely careful.

Anyone exposing a C++ API in a dynamic library is nuts, IMHO. Apple did so with 
IOKit and I'm sure they've regretted it ever since.

> - Often when comparing Obj-C vs. C++, method dispatch is one of the
> main culprits for the performance difference.

That's one of them. The other major one is the way that Obj-C has to allocate 
all* objects on the heap, whereas in C++ you can allocate small temporary 
objects on the stack, or embed them in other objects.

Part of knowing how to use Obj-C effectively is knowing when _not_ to make 
something an object. If there will be zillions of tiny instances, or if it has 
to be called in ultra performance sensitive code, it's better to drop down to C 
or C++ for just that specific task.

—Jens

* except for a subset of NSNumbers which the runtime cleverly hides inside 
tagged pointers, a C++-like trick

___

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: Xcode 5 & Obj-C++

[Lee Ann Rucker]

On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote:
> 
> 
> * except for a subset of NSNumbers which the runtime cleverly hides inside 
> tagged pointers, a C++-like trick


Smalltalk did it first.
___

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: Xcode 5 & Obj-C++

[Greg Parker]

On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker  wrote:
> On Jan 29, 2014, at 4:42 PM, Jens Alfke wrote:
>> 
>> * except for a subset of NSNumbers which the runtime cleverly hides inside 
>> tagged pointers, a C++-like trick
> 
> Smalltalk did it first.

Lisp probably did it before that.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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: Xcode 5 & Obj-C++

[Jens Alfke]

On Jan 29, 2014, at 4:57 PM, Lee Ann Rucker  wrote:

> Smalltalk did it first.

Actually LISP did it first, if you want to get pedantic…

(Wikipedia has let me down: the entry for Tagged Pointer is pretty lame and has 
no discussion of the history.)

—Jens
___

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: Xcode 5 & Obj-C++

[Graham Cox]

On 30 Jan 2014, at 12:02 pm, Jens Alfke  wrote:

> Wikipedia has let me down: the entry for  
> is pretty lame


FTFY ;)

--Graham



___

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: Xcode 5 & Obj-C++

[Scott Ribe]

On Jan 29, 2014, at 6:02 PM, Greg Parker  wrote:

> Lisp probably did it before that.

Hell, Lisp machines did it in hardware ;-)

-- 
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

Legal Opinion on GCUndoManager

[Jerry Krinock]

On 2014 Jan 29, at 13:03, Keary Suska  wrote:

> unfortunately it [GCUndoManager] is not App Store safe … as it relies on a 
> private method call for proper NSDocument change tracking…

I just spent the last half hour studying this and wrote my own concise legal 
opinion arguing why GCUndoManager is OK.  Now having read Graham’s post, it’s 
probably redundant.  But I’m posting it here anyhow in case I or anyone else 
ever needs it :)

Although -[NSUndoManager _processEndOfEventNotification:] is a non-public API, 
-[GCUndoManager _processEndOfEventNotification:] is NOT a non-public API.  As a 
matter of fact, it is not even an Apple API!  It’s the same as if I defined a 
class CorePerformer and innocently named a method -[CorePerformer 
_corePerformAction].  There also happens to be an Apple non-public method 
-[NSMenuItem _corePerformAction].  Certainly my definition should not result in 
an app store rejection.
___

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