Re: UIDocument + NSFileWrapper crashes on opening
On Jun 20, 2013, at 22:05 , Markus Spoettl wrote: > It seems that the default implementation of UIDocument uses an NSFileWrapper > initialized with the NSFileWrapperReadingImmediate reading option. > > When I create a NSFileWrapper not using that option it works, meaning it now > opens and loads the package document it previously crashed on. I wonder what > surprises I will run into with lazy wrapper loading like that. Initial tests > show no problems when changing the document and saving the whole thing. For > now it seems to work exactly like on OSX. > > What is interesting too is that my application was able to create the whole > wrapper structure when it first created the package. It would have required > the same amount of memory to hold the wrappers in memory before they get > written to the disk by UIDocument. Maybe it has to do with the fact that it > is creating the structure incrementally and relatively slowly while > downloading objects over the network. Reading the UIDocument from disk on the > other hand requires it to load everything instantly. Maybe there's some > system safeguard in place that kills apps whose memory usage increases too > rapidly. I think the short answer is that your files are being memory-mapped rather than read via I/O. That means the result is dependent on the VM swapping caused by your pattern of access. That's assuming you actually read all of the files. If you don't access the data, it won't have any performance impact. You might get away with this on iOS, but on OS X it's all going to come unstuck if the document file is on a disk that doesn't allow memory mapping, such as a network volume. One of these days I'm going to write an experimental app that tries to figure out what happens when. ___ 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: UIDocument + NSFileWrapper crashes on opening
On 6/20/13 11:52 PM, Quincey Morris wrote: OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand when needed? No, NSFileWrapper provides *lazy* loading, in the sense that you don't need to load a file until/unless it's actually needed. It doesn't provide any mechanism for evicting file contents from memory -- not that I can find, and I looked hard. If you need to read all the files, they will all eventually be in memory. Yes, but the important word is "eventually". It seems that the default implementation of UIDocument uses an NSFileWrapper initialized with the NSFileWrapperReadingImmediate reading option. When I create a NSFileWrapper not using that option it works, meaning it now opens and loads the package document it previously crashed on. I wonder what surprises I will run into with lazy wrapper loading like that. Initial tests show no problems when changing the document and saving the whole thing. For now it seems to work exactly like on OSX. What is interesting too is that my application was able to create the whole wrapper structure when it first created the package. It would have required the same amount of memory to hold the wrappers in memory before they get written to the disk by UIDocument. Maybe it has to do with the fact that it is creating the structure incrementally and relatively slowly while downloading objects over the network. Reading the UIDocument from disk on the other hand requires it to load everything instantly. Maybe there's some system safeguard in place that kills apps whose memory usage increases too rapidly. This is doubly irritating, because if the file contents is an archive, or otherwise needs to be converted or expanded, then both the raw data and unarchived data are in memory.** This is distinct from *incremental* loading, which loads the raw data in pieces and only temporarily. This cannot -- in practical way -- be done with NSFileWrapper. While you can't have a filewrapper load one file incrementally, you sure can use NSFileWrapper to load the contents of a folder structure's files incrementally, one file at a time. Regards Markus -- __ Markus Spoettl ___ 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: UIDocument + NSFileWrapper crashes on opening
You just saved me days of work. Thanks very much! Regards Markus On 6/20/13 11:52 PM, Luke the Hiesterman wrote: By default, UIDocument does eager reading. You can override that in -readFromURL:error:. Luke On Jun 20, 2013, at 2:37 PM, Markus Spoettl wrote: On 6/20/13 11:16 PM, Luke the Hiesterman wrote: Probably exactly as you said. Try overriding -readFromURL:error: to implement incremental reading. OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand when needed? Is NSFileWrapper on iOS doing things differently than on OSX in that regard? What kind of folder hierarchy/size can it read? 140MB doesn't seem enormously big (of course it does depend on what it does with it). Regards Markus -- __ Markus Spoettl -- __ Markus Spoettl ___ 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: UIScrollView challenge: allow zoom out to see full content
Bah, the idea of making the image match the aspect ratio doesn't work because it doesn't support changing ratios (e.g. rotation). On Jun 20, 2013, at 16:11 , Rick Mann wrote: > I have a basic UIScrollView working with pinch zoom and pan under autolayout. > There are still issues, including very jumpy zoom, and I still need to find > the right way to add some subviews that need to "stick" to the image as it > zooms. > > Another challenge is this: allowing the user to zoom out far enough to see > the whole image while a) keeping the image centered, and b) without exposing > any views that might be behind the scroll view. > > The image will rarely have the same aspect ratio as the scroll view. > > The second requirement is not an absolute requirement. Currently I have > placeholder art behind the scroll view that appears when there's no image to > show, because I set the alpha of the image view to 0. I can also hide and > show the placeholder art when I do this, or make the scroll view opaque and > hide it instead of the image (that is, in fact, what I will likely do). > > One way to get the image to zoom out nicely (stay centered) is to ensure it's > rendered with the same aspect ratio as the UIScrollView. This may be the most > expedient way. The image is generated from data and rendered onto a black > background, so it's reasonable to do the math to create another image of the > correct aspect ratio that totally fits the generated image. > > But it seems like autolayout and UIScrollView should be smart enough to do > this anyway. Currently, if I allow zooming out to a scale less than 1.0, the > image scoots over to the upper-left. But really, it seems that autolayout and > UIScrollView should know how to handle this for me. > > Suggestions? Thanks! > > > > -- > 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/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: NSDocument and Large File Import?
On Jun 20, 2013, at 5:41 PM, Quincey Morris wrote: > On Jun 20, 2013, at 14:22 , Karl Moskowski wrote: > >> So, when importing the asset upon new document creation, actually import it >> to a temp directory, then upon save of the document, hard-link to the temp >> asset (via NSFileManager methods)? How would you delete the original hard >> link from the temp directory? Just delete the temp directory itself >> non-recursively? (I couldn’t find any unlinking APIs.) > > Even easier, you just delete the file. When you hard link, there's nothing at > all unusual about the files (other than the fact they they are hard-linked to > the same disk data). The data itself is, in effect, reference counted, so it > won't disappear until the last file using it is deleted. Of course! Just delete one of the hard links. The other, and its referenced data, are still around. >> In modern document-based apps, this would be via the “Duplicate” menu, right? > > That's one scenario Another scenario is when a new document has been > autosaved, which is typically to a local hard disk, and then the user chooses > a different volume when prompted to save on closing the window. > > I may have slightly overstated the case earlier. If your embedded asset file > never changes after being created, they you likely won't have any code to > clone it yourself, since the NSDocument default behavior does this for you. > However, if you don't have an existing file wrapper to trigger this, as when > the document is first created, you need to do the cloning yourself. It is possible that the embedded asset could change — the user could re-import another asset to take its place. —Karl. smime.p7s Description: S/MIME cryptographic signature ___ 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
UIScrollView challenge: allow zoom out to see full content
I have a basic UIScrollView working with pinch zoom and pan under autolayout. There are still issues, including very jumpy zoom, and I still need to find the right way to add some subviews that need to "stick" to the image as it zooms. Another challenge is this: allowing the user to zoom out far enough to see the whole image while a) keeping the image centered, and b) without exposing any views that might be behind the scroll view. The image will rarely have the same aspect ratio as the scroll view. The second requirement is not an absolute requirement. Currently I have placeholder art behind the scroll view that appears when there's no image to show, because I set the alpha of the image view to 0. I can also hide and show the placeholder art when I do this, or make the scroll view opaque and hide it instead of the image (that is, in fact, what I will likely do). One way to get the image to zoom out nicely (stay centered) is to ensure it's rendered with the same aspect ratio as the UIScrollView. This may be the most expedient way. The image is generated from data and rendered onto a black background, so it's reasonable to do the math to create another image of the correct aspect ratio that totally fits the generated image. But it seems like autolayout and UIScrollView should be smart enough to do this anyway. Currently, if I allow zooming out to a scale less than 1.0, the image scoots over to the upper-left. But really, it seems that autolayout and UIScrollView should know how to handle this for me. Suggestions? Thanks! -- 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: NSDocument and Large File Import?
On Jun 20, 2013, at 15:12 , Mike Abdullah wrote: > There should be no need to do this. If you need a location on disk for the > document, just trigger an autosave so that the system effectively creates a > temp location for you to use (-[NSDocument autosavedContentsFileURL]) In principle I agree this is a neat approach, but in practice I think it doesn't help that much. If you take this approach, you have to do the following steps before you can actually import your data: 1. Ask the user for the source of the data (assuming a file or URL is being used as the source of the data). 2. Create a NSDocument instance. 3. Go through the document startup sequence, including creation of the window controller. 4. Put special handling in the window controller to deal with the special case of having no imported asset file yet. 5. Start importing the data. 6. Display progress/cancel UI while import proceeds, and (likely) prevent the user from interacting with the document window until it ends. If you import to a temp file *first* you get rid of a lot of complexity of timing at the UI level, at the cost of having the document save know how to deal with an asset file that's a temp file. As I suggested earlier, you may have essentially that code in the save anyway. ___ 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: NSDocument and Large File Import?
On 20 Jun 2013, at 20:52, Karl Moskowski wrote: > > On Jun 20, 2013, at 3:44 PM, Jens Alfke wrote: > >> Yup, it’s an untitled document so it doesn’t have a persistent manifestation >> yet. >> >> A typical solution for your problem is to create a temporary directory >> somewhere (using the APIs for that purpose) and treat that as the document’s >> storage. Then on first save you can move that to where you were told to save >> (which might have to involve a copy-then-delete.) >> >> An important detail is that if the document is closed without saving, you >> should remember to delete the temporary directory, otherwise you’ve just >> eaten up part of the user’s available disk space until the next reboot. > > Thanks, Jens. > > If we have to do that level of manual work, I think our preferred direction > will be to go the Xcode-style route, and ask for a save location early. > However, I’ll ask my colleagues for their opinions. > > Anyway, would the best place to implement either of these approaches be in a > NSDocumentController subclass or in the NSDocument subclass? There should be no need to do this. If you need a location on disk for the document, just trigger an autosave so that the system effectively creates a temp location for you to use (-[NSDocument autosavedContentsFileURL]) ___ 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: UIDocument + NSFileWrapper crashes on opening
By default, UIDocument does eager reading. You can override that in -readFromURL:error:. Luke On Jun 20, 2013, at 2:37 PM, Markus Spoettl wrote: > On 6/20/13 11:16 PM, Luke the Hiesterman wrote: >> Probably exactly as you said. Try overriding -readFromURL:error: to >> implement incremental reading. > > OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing > sub-wrappers instead of actual data of contained files/folders, which can be > read on demand when needed? > > Is NSFileWrapper on iOS doing things differently than on OSX in that regard? > > What kind of folder hierarchy/size can it read? 140MB doesn't seem enormously > big (of course it does depend on what it does with it). > > Regards > Markus > -- > __ > Markus Spoettl ___ 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: UIDocument + NSFileWrapper crashes on opening
On Jun 20, 2013, at 14:37 , Markus Spoettl wrote: > OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing > sub-wrappers instead of actual data of contained files/folders, which can be > read on demand when needed? No, NSFileWrapper provides *lazy* loading, in the sense that you don't need to load a file until/unless it's actually needed. It doesn't provide any mechanism for evicting file contents from memory -- not that I can find, and I looked hard. If you need to read all the files, they will all eventually be in memory. This is doubly irritating, because if the file contents is an archive, or otherwise needs to be converted or expanded, then both the raw data and unarchived data are in memory.** This is distinct from *incremental* loading, which loads the raw data in pieces and only temporarily. This cannot -- in practical way -- be done with NSFileWrapper. I spent a lot of time going round in circles about this, so I'm speaking up here in case I've missed something obvious, in which case someone will jump in and correct me. But AFAIK NSFileWrapper isn't the way to go for managed, incremental loading. ** What makes this acceptable in a lot of cases is that NSFileWrapper may read files by memory mapping them. This can perform as well as, or better than, a properly functioning cache, at the expense of using up additional VM address space. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 14:22 , Karl Moskowski wrote: > So, when importing the asset upon new document creation, actually import it > to a temp directory, then upon save of the document, hard-link to the temp > asset (via NSFileManager methods)? How would you delete the original hard > link from the temp directory? Just delete the temp directory itself > non-recursively? (I couldn’t find any unlinking APIs.) Even easier, you just delete the file. When you hard link, there's nothing at all unusual about the files (other than the fact they they are hard-linked to the same disk data). The data itself is, in effect, reference counted, so it won't disappear until the last file using it is deleted. > In modern document-based apps, this would be via the “Duplicate” menu, right? That's one scenario Another scenario is when a new document has been autosaved, which is typically to a local hard disk, and then the user chooses a different volume when prompted to save on closing the window. I may have slightly overstated the case earlier. If your embedded asset file never changes after being created, they you likely won't have any code to clone it yourself, since the NSDocument default behavior does this for you. However, if you don't have an existing file wrapper to trigger this, as when the document is first created, you need to do the cloning yourself. ___ 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: UIDocument + NSFileWrapper crashes on opening
On 6/20/13 11:16 PM, Luke the Hiesterman wrote: Probably exactly as you said. Try overriding -readFromURL:error: to implement incremental reading. OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand when needed? Is NSFileWrapper on iOS doing things differently than on OSX in that regard? What kind of folder hierarchy/size can it read? 140MB doesn't seem enormously big (of course it does depend on what it does with it). Regards Markus -- __ Markus Spoettl ___ 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: Detect a Retina display
And if that's not possible, make an informal protocol (aka interface on
NSObject), just so the compiler knows what the method looks like:
@interface NSObject (RemoveWhenUpgradingSDKs)
// or NSView, NSScreen, NSWindow if you prefer narrowing it down to just the
class you care about
- (NSRect)convertRectToBacking:(NSRect)aRect;
@end
On Jun 20, 2013, at 8:22 AM, Sandy McGuffog wrote:
> What you need is to set base SDK to most recent (10.8), and set deployment
> target to 10.6
>
> Sandy
>
> On Jun 20, 2013, at 5:11 PM, Thierry Cantet wrote:
>
>> Hello Richard,
>>
>> I have tried your solution, however it does not work.
>>
>> I have these messages when I try to build with the base SDK set to 10.6 :
>> (Warning)Instance method '-convertRectToBacking:' not found (return type
>> defaults to 'id')
>> (Error)No viable conversion from 'id' to 'NSRect' (aka 'CGRect')
>>
>>
>>
>> Le 20/06/13 16:18, Richard Heard a écrit :
>>> No retina devices can run 10.6, therefore you can safely assume 1.0.
>>> This means you can use a runtime check for the selector, and if its not
>>> available default to a 1.0 multiple
>>> eg:
>>>
- (NSRect)backingBounds {
if ([self respondsToSelector:@selector(convertRectToBacking:)]){
return [self convertRectToBacking:self.bounds];
}
return self.bounds;
}
>>>
>>> -Richard
>>>
>>> On 20/06/2013, at 11:49:18 PM, Thierry Cantet >> > wrote:
>>>
Hello !
I have a quick question concerning Retina displays.
My software uses OpenGL for displaying the pixels. However, on a Retina
screen, OpenGL behaves strangely.
There is a fix (
https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
) that requires you to use :
NSRect backingBounds = [self convertRectToBacking:[self bounds]];
GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
backingPixelHeight = (GLsizei)(backingBounds.size.height);
glViewport(0, 0, backingPixelWidth, backingPixelHeight);
inside the drawRect method.
The main issue is, the /convertRectToBacking/ method exists only since OS
X 10.7, and my software still supports OS X 10.6 (so I need to build it
with a 10.6 SDK, and not 10.7).
I could drop the 10.6 support, but that is not an option for now.
I have looked for another way, and I found the /backingScaleFactor/ method
(it returns the scale factor, which is 2 for Retina displays, and 1 for
other screens). But then again, this method is available only from 10.7.
So, my question is, is there any way of detecting a Retina display, but
usable with 10.6 ?
Thanks in advance :)
--
Thierry CANTET
___
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/heardrwt%40gmail.com
This email sent to heard...@gmail.com
>>>
>> --
>> Thierry CANTET
>>
>> ___
>>
>> 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/mcguffogl%40gmail.com
>>
>> This email sent to mcguff...@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/lrucker%40vmware.com
>
> This email sent to lruc...@vmware.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: NSDocument and Large File Import?
On Jun 20, 2013, at 4:30 PM, Quincey Morris wrote: > On Jun 20, 2013, at 4:07 PM, Karl Moskowski wrote: > >> In fact, I think that will almost always be the case, so the >> link-to-an-external asset approach may not be practical. Anyway, would that >> approach work with Sandbox restrictions? What about potential iCloud sync in >> the future (forgetting for a moment the issues of file size)? > > It's not an external asset in this case. When you create the clone by hard > linking, there are two independent files sharing the same disk storage. The > clone file is "in" the document package normally. > > NSDocument already does hard-linking for files within a package which > (according to the wrapper you return) haven't changed since the last save, > assuming the file system supports it, so the mechanism is already compatible > with sandboxing and iCloud. So, when importing the asset upon new document creation, actually import it to a temp directory, then upon save of the document, hard-link to the temp asset (via NSFileManager methods)? How would you delete the original hard link from the temp directory? Just delete the temp directory itself non-recursively? (I couldn’t find any unlinking APIs.) > My point was, though, sort of the opposite. In your document save, you will > necessarily need a mechanism to transfer the asset from an existing document > package to a new document package. The "problem" of transferring an asset in > a temp file to a package isn't really an additional burden, since it can > likely use the same mechanism. In modern document-based apps, this would be via the “Duplicate” menu, right? > If you haven't considered the normal save behavior (in the situation of a > destination different from the source), then your save strategy is already > broken, and you aren't ready to think about the creation behaviour. —Karl. smime.p7s Description: S/MIME cryptographic signature ___ 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: UIDocument + NSFileWrapper crashes on opening
Probably exactly as you said. Try overriding -readFromURL:error: to implement incremental reading. Luke On Jun 20, 2013, at 2:01 PM, Markus Spoettl wrote: > Hello everyone, > > I have an iOS 6 app that uses UIDocument to implement loading and saving of > my app's data. The document data is loaded from and saved to a NSFileWrapper > (representing a file package containing many files and folders), handed from > and to the document in -loadFromContents::: and -contentsForType::. > > This all works well for small documents but I now have a case where a > document the app created in a previous session apparently is too big to be > loaded. > > My app vanishes about 1-2 seconds after UIDocument calls -readFromURL:error: > before my implementation of -loadFromContents::: is even called. There is no > crash and no useful information (to me anyway) logged to the console. It just > logs that my app was killed but gives no reason. > > I *suspect* UIDocument tries to load the whole package containing its 140MB > of data in about 1000 files and couple of 100 folders and then chokes on it. > > The system had no problem creating the file package and saving it to the > "disk", but it sure can't load it. > > I have tried on the simulator and using the same data as on the device it > works, the data loads just fine. > > I'm pasting the console output of a typical session from the time the app is > started via Springboard until it crashes/vanishes. Maybe it contains a clue I > don't see. > > Does someone know what may be going on? I'm using Xcode 4.6.3 and iOS 6.1.3 > (iPad Retina). > > Thanks! > Regards > Markus > > ___ > > 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/luketheh%40apple.com > > This email sent to luket...@apple.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: UIDocument + NSFileWrapper crashes on opening
Seems the log didn't make it in the initial post, not sure why. On 6/20/13 11:01 PM, Markus Spoettl wrote: I'm pasting the console output of a typical session from the time the app is started via Springboard until it crashes/vanishes. Maybe it contains a clue I don't see. Jun 20 20:52:08 Flatfish kernel[0] : launchd[136] Builtin profile: container (sandbox) Jun 20 20:52:08 Flatfish kernel[0] : launchd[136] Container: /private/var/mobile/Applications/2AB076E0-7F97-424E-81DB-C2701B968CCC (sandbox) Jun 20 20:52:08 Flatfish librariand[106] : client process 136 does not have a valid com.apple.developer.ubiquity-container-identifiers entitlement Jun 20 20:52:09 Flatfish com.apple.launchd[1] (com.apple.accountsd[112]) : (com.apple.accountsd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:09 Flatfish com.apple.launchd[1] (com.apple.accountsd[112]) : (com.apple.accountsd) Exited: Killed: 9 Jun 20 20:52:09 Flatfish kernel[0] : vnode: table is full Jun 20 20:52:09 Flatfish kernel[0] : 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Jun 20 20:52:09 Flatfish com.apple.launchd[1] (com.apple.mobile.installd[109]) : (com.apple.mobile.installd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:09 Flatfish com.apple.launchd[1] (com.apple.mobile.installd[109]) : (com.apple.mobile.installd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.afcd[118]) : (com.apple.afcd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.afcd[118]) : (com.apple.afcd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.crashreportcopymobile[133]) : (com.apple.crashreportcopymobile) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.crashreportcopymobile[133]) : (com.apple.crashreportcopymobile) Exited: Killed: 9 Jun 20 20:52:10 Flatfish kernel[0] : vnode: table is full Jun 20 20:52:10 Flatfish kernel[0] : 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Jun 20 20:52:10 Flatfish kernel[0] : vnode: table is full Jun 20 20:52:10 Flatfish kernel[0] : 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Jun 20 20:52:10 Flatfish kernel[0] : vnode: table is full Jun 20 20:52:10 Flatfish kernel[0] : 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.lsd[130]) : (com.apple.lsd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.lsd[130]) : (com.apple.lsd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish kernel[0] : vnode: table is full Jun 20 20:52:10 Flatfish kernel[0] : 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage Jun 20 20:52:10 Flatfish com.apple.launchd[1] (UIKitApplication:com.apple.mobilemail[0x1dc][108]) : (UIKitApplication:com.apple.mobilemail[0x1dc]) Exited: Killed: 9 Jun 20 20:52:10 Flatfish backboardd[26] : Application 'UIKitApplication:com.apple.mobilemail[0x1dc]' exited abnormally with signal 9: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.mediastream.mstreamd[111]) : (com.apple.mediastream.mstreamd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (UIKitApplication:com.apple.mobilephone[0xebcb][107]) : (UIKitApplication:com.apple.mobilephone[0xebcb]) Exited: Killed: 9 Jun 20 20:52:10 Flatfish backboardd[26] : Application 'UIKitApplication:com.apple.mobilephone[0xebcb]' exited abnormally with signal 9: Killed: 9 Jun 20 20:52:10 Flatfish MyApp[136] : shared connection error: Connection interrupted Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.tccd[110]) : (com.apple.tccd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.librariand[106]) : (com.apple.librariand) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.mediastream.mstreamd[139]) : (com.apple.mediastream.mstreamd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.mediastream.mstreamd) : (com.apple.mediastream.mstreamd) Throttling respawn: Will start in 1 seconds Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.accountsd[138]) : (com.apple.accountsd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch. Jun 20 20:52:10 Flatfish com.apple.launchd[1] (com.apple.accountsd[138]) : (com.apple.accountsd) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (UIKitApplication:com.apple.mobilemail[0x21ae][137]) : (UIKitApplication:com.apple.mobilemail[0x21ae]) Exited: Killed: 9 Jun 20 20:52:10 Flatfish com.apple.launchd[1] (UIKitApplication:com.apple.mobilemail[0x21ae]) : (UIKitApplication:com.apple.mobilemail[0x21ae]) Throttling respawn: Will start in 2147483647 seconds
UIDocument + NSFileWrapper crashes on opening
Hello everyone, I have an iOS 6 app that uses UIDocument to implement loading and saving of my app's data. The document data is loaded from and saved to a NSFileWrapper (representing a file package containing many files and folders), handed from and to the document in -loadFromContents::: and -contentsForType::. This all works well for small documents but I now have a case where a document the app created in a previous session apparently is too big to be loaded. My app vanishes about 1-2 seconds after UIDocument calls -readFromURL:error: before my implementation of -loadFromContents::: is even called. There is no crash and no useful information (to me anyway) logged to the console. It just logs that my app was killed but gives no reason. I *suspect* UIDocument tries to load the whole package containing its 140MB of data in about 1000 files and couple of 100 folders and then chokes on it. The system had no problem creating the file package and saving it to the "disk", but it sure can't load it. I have tried on the simulator and using the same data as on the device it works, the data loads just fine. I'm pasting the console output of a typical session from the time the app is started via Springboard until it crashes/vanishes. Maybe it contains a clue I don't see. Does someone know what may be going on? I'm using Xcode 4.6.3 and iOS 6.1.3 (iPad Retina). Thanks! Regards Markus ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 13:07 , Karl Moskowski wrote: > In fact, I think that will almost always be the case, so the > link-to-an-external asset approach may not be practical. Anyway, would that > approach work with Sandbox restrictions? What about potential iCloud sync in > the future (forgetting for a moment the issues of file size)? It's not an external asset in this case. When you create the clone by hard linking, there are two independent files sharing the same disk storage. The clone file is "in" the document package normally. NSDocument already does hard-linking for files within a package which (according to the wrapper you return) haven't changed since the last save, assuming the file system supports it, so the mechanism is already compatible with sandboxing and iCloud. My point was, though, sort of the opposite. In your document save, you will necessarily need a mechanism to transfer the asset from an existing document package to a new document package. The "problem" of transferring an asset in a temp file to a package isn't really an additional burden, since it can likely use the same mechanism. If you haven't considered the normal save behavior (in the situation of a destination different from the source), then your save strategy is already broken, and you aren't ready to think about the creation behavior. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 12:52 PM, Karl Moskowski wrote: > If we have to do that level of manual work, I think our preferred direction > will be to go the Xcode-style route, and ask for a save location early. > However, I’ll ask my colleagues for their opinions. IMHO it’s nicer to support untitled documents. It’s a simpler experience for the user. I sometimes create documents for temporary use with no intention of saving them, or I may get partway through making a document and then change my mind and don’t want a junk file being left behind. I think the reason Xcode wants the location ahead of time is because it interacts with all kinds of dev tools to which the path to a file is really important, so having a project in some random temporary dir would seem weird. —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: NSDocument and Large File Import?
On Jun 20, 2013, at 3:53 PM, Quincey Morris wrote: > On Jun 20, 2013, at 12:06 , Karl Moskowski wrote: > >> I’m creating a document-based OS X app. The document itself will be a >> package, with most of the its properties archived in a plist (via >> NSFileWrapper). However, the document package will also contain a >> potentially — probably, even — large asset file that’s too big to keep in >> memory. The first step of the new document workflow is that the user chooses >> the asset to import. It’s then displayed for editing. >> >> My problem arises in the creation phase. After the new NSDocument object is >> instantiated (in either -init or -initWithType:error:), but before the >> document is saved, I don’t have an on-disk location to which to import, as >> far as I can tell; all of the URL-ish properties and methods of NSDocument >> are nil. It’s a modern app, with the various autosave methods returning YES, >> and when the app quits, the new document is in "~/Library/Autosave >> Information”. > > Consider what happens later, when an existing document needs to be re-saved. > Since, in general, your save method must handle the case where the save is to > a different location (Save As, for example), you need a mechanism to clone > the large file. (You could hard link it when possible, but there'll always be > situations where you have to copy it -- saving to a network volume, for > example.) > > With a little care, you should be able to use the same code for new > documents. Import the asset into a temp file. At save time, you'd notice that > the asset file isn't in the save destination, so you'd clone it. > > There are other approaches, but this one fits most neatly in the NSDocument > architecture, if it suits your use case. > >> Should I be taking the approach of Xcode, where the “New > Project” process >> asks the user to choose a location for the project, and it’s saved >> immediately? Or is there a property or method I’m missing that gives the >> autosaved new document’s location? > > I think this is a different issue. It's mostly about whether it makes sense > for the user to have an untitled-document experience for your app. > > If the import takes a long time, you can do it *before* creating the > NSDocument instance, or *after* the document creation process is complete > (that is, after makeWindowControllers is called). That's because you want a > long import to have UI (progress/cancel), and the middle of a NSDocument > 'init…' is not the place to do that. > > If you choose "before", then it's probably easier to have the user choose the > save location before, too. If you choose "after", then it's probably better > to maintain the untitled document experience for the user (if you want one). > > I've found from experience, though, that the implementation of both > approaches amounts to much the same code, just in different places. From an > implementation perspective, neither is preferable to the other. Thanks, Quincey. It could take a long time to do the import, and the user will likely have to "pre-edit” the asset in some UI at least a bit first. In fact, I think that will almost always be the case, so the link-to-an-external asset approach may not be practical. Anyway, would that approach work with Sandbox restrictions? What about potential iCloud sync in the future (forgetting for a moment the issues of file size)? —Karl. smime.p7s Description: S/MIME cryptographic signature ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 12:06 , Karl Moskowski wrote: > I’m creating a document-based OS X app. The document itself will be a > package, with most of the its properties archived in a plist (via > NSFileWrapper). However, the document package will also contain a potentially > — probably, even — large asset file that’s too big to keep in memory. The > first step of the new document workflow is that the user chooses the asset to > import. It’s then displayed for editing. > > My problem arises in the creation phase. After the new NSDocument object is > instantiated (in either -init or -initWithType:error:), but before the > document is saved, I don’t have an on-disk location to which to import, as > far as I can tell; all of the URL-ish properties and methods of NSDocument > are nil. It’s a modern app, with the various autosave methods returning YES, > and when the app quits, the new document is in "~/Library/Autosave > Information”. Consider what happens later, when an existing document needs to be re-saved. Since, in general, your save method must handle the case where the save is to a different location (Save As, for example), you need a mechanism to clone the large file. (You could hard link it when possible, but there'll always be situations where you have to copy it -- saving to a network volume, for example.) With a little care, you should be able to use the same code for new documents. Import the asset into a temp file. At save time, you'd notice that the asset file isn't in the save destination, so you'd clone it. There are other approaches, but this one fits most neatly in the NSDocument architecture, if it suits your use case. > Should I be taking the approach of Xcode, where the “New > Project” process > asks the user to choose a location for the project, and it’s saved > immediately? Or is there a property or method I’m missing that gives the > autosaved new document’s location? I think this is a different issue. It's mostly about whether it makes sense for the user to have an untitled-document experience for your app. If the import takes a long time, you can do it *before* creating the NSDocument instance, or *after* the document creation process is complete (that is, after makeWindowControllers is called). That's because you want a long import to have UI (progress/cancel), and the middle of a NSDocument 'init…' is not the place to do that. If you choose "before", then it's probably easier to have the user choose the save location before, too. If you choose "after", then it's probably better to maintain the untitled document experience for the user (if you want one). I've found from experience, though, that the implementation of both approaches amounts to much the same code, just in different places. From an implementation perspective, neither is preferable to the other. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 3:44 PM, Jens Alfke wrote: > Yup, it’s an untitled document so it doesn’t have a persistent manifestation > yet. > > A typical solution for your problem is to create a temporary directory > somewhere (using the APIs for that purpose) and treat that as the document’s > storage. Then on first save you can move that to where you were told to save > (which might have to involve a copy-then-delete.) > > An important detail is that if the document is closed without saving, you > should remember to delete the temporary directory, otherwise you’ve just > eaten up part of the user’s available disk space until the next reboot. Thanks, Jens. If we have to do that level of manual work, I think our preferred direction will be to go the Xcode-style route, and ask for a save location early. However, I’ll ask my colleagues for their opinions. Anyway, would the best place to implement either of these approaches be in a NSDocumentController subclass or in the NSDocument subclass? —Karl. smime.p7s Description: S/MIME cryptographic signature ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 12:06 PM, Karl Moskowski wrote: > My problem arises in the creation phase. After the new NSDocument object is > instantiated (in either -init or -initWithType:error:), but before the > document is saved, I don’t have an on-disk location to which to import, as > far as I can tell Yup, it’s an untitled document so it doesn’t have a persistent manifestation yet. A typical solution for your problem is to create a temporary directory somewhere (using the APIs for that purpose) and treat that as the document’s storage. Then on first save you can move that to where you were told to save (which might have to involve a copy-then-delete.) An important detail is that if the document is closed without saving, you should remember to delete the temporary directory, otherwise you’ve just eaten up part of the user’s available disk space until the next reboot. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: Looking for a good starting point to create a shared data resource between iOS apps
On Jun 20, 2013, at 11:01 AM, Michael Crawford wrote: > Do localhost (127.0.0.1) TCP sockets work between two different apps? Yes, and there are systems like Audiobus (http://audiob.us) that use it for live audio streaming between apps. The tricky part, I think, is keeping both apps running at the same time since one will be in the background. Audio apps can do this because iOS lets them keep running to play background audio. This doesn’t sound relevant to Alex’s question, though, because he presumably doesn’t want both apps to have to be running at the same time to share the data. > Now here's why sandboxing really cannot hope to keep two apps from > communicating: What you say is true, but I don’t think it’s been Apple’s goal to keep apps from communicating. After all we already have mechanisms like registering URL schemes and opening URLs. Apple is just limiting the types of communication to avoid channels malware can use to attack other apps. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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
NSDocument and Large File Import?
I’m creating a document-based OS X app. The document itself will be a package, with most of the its properties archived in a plist (via NSFileWrapper). However, the document package will also contain a potentially — probably, even — large asset file that’s too big to keep in memory. The first step of the new document workflow is that the user chooses the asset to import. It’s then displayed for editing. My problem arises in the creation phase. After the new NSDocument object is instantiated (in either -init or -initWithType:error:), but before the document is saved, I don’t have an on-disk location to which to import, as far as I can tell; all of the URL-ish properties and methods of NSDocument are nil. It’s a modern app, with the various autosave methods returning YES, and when the app quits, the new document is in "~/Library/Autosave Information”. Should I be taking the approach of Xcode, where the “New > Project” process asks the user to choose a location for the project, and it’s saved immediately? Or is there a property or method I’m missing that gives the autosaved new document’s location? Thanks. —Karl. smime.p7s Description: S/MIME cryptographic signature ___ 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: Looking for a good starting point to create a shared data resource between iOS apps
Do you have to be able to get at the data when you're not connected to the Internet? If not, you could store it on an HTTP server. Do shared memory segments work on iOS? I would expect not because of the sandbox, but maybe they do. Do localhost (127.0.0.1) TCP sockets work between two different apps? Now here's why sandboxing really cannot hope to keep two apps from communicating: In military security, one has to have the proper clearance (Secret, Top Secret), "compartment", and one must have a "need to know" to do one's official job. One is not permitted to store data from two different compartments on the same computer. For example if you design warheads, then you can't also have a design for a missile guidance system. Otherwise the two could communicate, and leak information out of the compartment, or to a lower clearance level. An example of this that I was once given, in a network security course at the 1989 Interop conference, is that a process in one compartment could exec a bunch of subprocesses, and then a process in a different compartment could examine the load average. They could then send binary bits back and forth, by exec'ing more or fewer subprocesses! One can't launch subprocesses on iOS, but one can launch threads, use up more or less memory, eat up more or less CPU time. Some wag wrote a Linux filesystem that stored one sector of data per GMail message. When you wanted to read a file, you'd just use POP to get the right message. If you can do that with GMail from the LInux kernel, there simply has to be a way for your apps to share data. (Bradley Manning's helpful contribution to WikiLeaks shows that the DoD specifications for data security were being ignored. Those specs are still in force, just not applied in practice.) -- Michael David Crawford mdcrawford at gmail dot com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ ___ 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: iOS 6, VoIP, and -viewDidLoad
Thanks for the suggestion. I found that -viewDidLoad does indeed get called even thought the app does not come to the foreground. This is a good thing as far as I'm concerned. No doubt Apple figured a lot of apps would break if they started an app and -viewDidLoad was never invoked. -Michael On Jun 20, 2013, at 12:54 PM, Fritz Anderson wrote: > On 20 Jun 2013, at 11:20 AM, Michael Crawford wrote: > >> When iOS automatically restarts a VoIP app that has crashed or been removed >> by the watchdog for some reason, does -viewDidLoad run when the app is >> automatically restarted? >> >> I ask because when this type of restart occurs, it appears to happen >> silently, without presenting the restarted app's window in the foreground. >> Since this condition is kind of difficult to test or duplicate on my device, >> I though some of you might have experience with this behavior and could tell >> me what you observed. >> >> I am trying to trigger this behavior by allocating huge amounts of memory on >> a timer and then leaking it on purpose but so far, instead of getting a >> memory warning and then subsequently having the app evicted due to memory >> pressure, malloc simply returns nullptr. I've tried this with allocation >> units of 100 megabytes and then with 1 megabyte. > > > The watchdog shuts the app down peremptorily, without warning. I'd think you > could get the same effect simply by calling abort(), perhaps in a background > task. > > — F > > -- > Fritz Anderson > Xcode 4 Unleashed: 4.5 supplement for free! > http://www.informit.com/store/xcode-4-unleashed-9780672333279 > ___ 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: Looking for a good starting point to create a shared data resource between iOS apps
On 2013-06-20, at 10:37 am, Alex Zavatone wrote: > I've reviewed the AppPrefs source on developer.apple.com and am interested in > creating a small set of shared data accessible for all apps on our iOS > devices. I have resorted to Keychain Services for achieving this kind of thing on a micro scale. So long as your apps share a common ancestor identifier (e.g. BUNDLESEEDID.com.example.*) then they can all have access to the same keychain items. This is a rather greasy approach, but NSUserDefaults is wholly sandboxed between apps on iOS. > Is a proper approach to use NSUserDefaults and then populate an app's bundle > that contains the root.pList when the preference pane is displayed, or is > this not possible based on how preferences work? The Settings.bundle in an iOS app is built into the app bundle and cannot be modified. b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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
Looking for a good starting point to create a shared data resource between iOS apps
I've reviewed the AppPrefs source on developer.apple.com and am interested in creating a small set of shared data accessible for all apps on our iOS devices. With this in mind, it would be nice to have a little app that has a preference pane that contains some specifics, but have these items also available to other apps that care to read them (or write to them). Is a proper approach to use NSUserDefaults and then populate an app's bundle that contains the root.pList when the preference pane is displayed, or is this not possible based on how preferences work? Just looking for advice on the possible paths to take or if any of my assumptions are completely off base. If sandboxing prevents this, may it burn forever in the fire of a thousand suns. Cheers. ___ 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: iOS 6, VoIP, and -viewDidLoad
On 6/20/13, Michael Crawford wrote:
> I am trying to trigger this behavior by allocating huge amounts of memory
> on a timer and then leaking it on purpose but so far, instead of getting a
> memory warning and then subsequently having the app evicted due to memory
> pressure, malloc simply returns nullptr. I've tried this with allocation
> units of 100 megabytes and then with 1 megabyte.
But seriously folks...
I expect you could trigger the watchdog by blocking the GUI thread.
Just put a button somewhere in your app that, when clicked, enters an
infinite loop. On OS X, that would cause the Spinning Pizza Of Death
to occur. I expect that on iOS, the system would wait a little while
to determine whether you've just stopped consuming events, and then
kill your app.
To stimulate a crash, try this:
+ (void) crash
{
realCrash( 0 );
}
+ (void) realCrash (int) denominator
{
return 2 / denominator;
}
That's to avoid compiler warnings.
The abort() call usually works by executing an illegal instruction as well.
I'll send you my bill in the mail.
Mike
mdcrawf...@gmail.com
--
Michael David Crawford
mdcrawford at gmail dot com
Custom Software Development for the iPhone and Mac OS X
http://www.dulcineatech.com/custom-software-development/
___
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: iOS 6, VoIP, and -viewDidLoad
On 20 Jun 2013, at 11:20 AM, Michael Crawford wrote: > When iOS automatically restarts a VoIP app that has crashed or been removed > by the watchdog for some reason, does -viewDidLoad run when the app is > automatically restarted? > > I ask because when this type of restart occurs, it appears to happen > silently, without presenting the restarted app's window in the foreground. > Since this condition is kind of difficult to test or duplicate on my device, > I though some of you might have experience with this behavior and could tell > me what you observed. > > I am trying to trigger this behavior by allocating huge amounts of memory on > a timer and then leaking it on purpose but so far, instead of getting a > memory warning and then subsequently having the app evicted due to memory > pressure, malloc simply returns nullptr. I've tried this with allocation > units of 100 megabytes and then with 1 megabyte. The watchdog shuts the app down peremptorily, without warning. I'd think you could get the same effect simply by calling abort(), perhaps in a background task. — F -- Fritz Anderson Xcode 4 Unleashed: 4.5 supplement for free! http://www.informit.com/store/xcode-4-unleashed-9780672333279 ___ 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: iOS 6, VoIP, and -viewDidLoad
On 6/20/13, Michael Crawford wrote: Michael A. Crawford? Did you at one time work for Apple? Did you at one time get a lot of phone calls and emails meant for me? I had long grown weary of pointing out to callers to look for our middle initials in the corporate phone directory, so I'd just make up answers to whatever questions they had. Perhaps that's why Apple almost went bankrupt back in the day. (I was a system software engineer, and if I understand correctly, he was one of the top people in the MIS department. No doubt shortages of essential components were due to me getting calls meant for him.) Good Times. Michael D. Crawford -- Michael David Crawford mdcrawford at gmail dot com Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/ ___ 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
iOS 6, VoIP, and -viewDidLoad
When iOS automatically restarts a VoIP app that has crashed or been removed by the watchdog for some reason, does -viewDidLoad run when the app is automatically restarted? I ask because when this type of restart occurs, it appears to happen silently, without presenting the restarted app's window in the foreground. Since this condition is kind of difficult to test or duplicate on my device, I though some of you might have experience with this behavior and could tell me what you observed. I am trying to trigger this behavior by allocating huge amounts of memory on a timer and then leaking it on purpose but so far, instead of getting a memory warning and then subsequently having the app evicted due to memory pressure, malloc simply returns nullptr. I've tried this with allocation units of 100 megabytes and then with 1 megabyte. -Michael ___ 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: Detect a Retina display
What you need is to set base SDK to most recent (10.8), and set deployment
target to 10.6
Sandy
On Jun 20, 2013, at 5:11 PM, Thierry Cantet wrote:
> Hello Richard,
>
> I have tried your solution, however it does not work.
>
> I have these messages when I try to build with the base SDK set to 10.6 :
>(Warning)Instance method '-convertRectToBacking:' not found (return type
> defaults to 'id')
>(Error)No viable conversion from 'id' to 'NSRect' (aka 'CGRect')
>
>
>
> Le 20/06/13 16:18, Richard Heard a écrit :
>> No retina devices can run 10.6, therefore you can safely assume 1.0.
>> This means you can use a runtime check for the selector, and if its not
>> available default to a 1.0 multiple
>> eg:
>>
>>> - (NSRect)backingBounds {
>>> if ([self respondsToSelector:@selector(convertRectToBacking:)]){
>>> return [self convertRectToBacking:self.bounds];
>>> }
>>> return self.bounds;
>>> }
>>
>> -Richard
>>
>> On 20/06/2013, at 11:49:18 PM, Thierry Cantet > > wrote:
>>
>>> Hello !
>>>
>>> I have a quick question concerning Retina displays.
>>> My software uses OpenGL for displaying the pixels. However, on a Retina
>>> screen, OpenGL behaves strangely.
>>>
>>> There is a fix (
>>> https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
>>> ) that requires you to use :
>>>
>>> NSRect backingBounds = [self convertRectToBacking:[self bounds]];
>>> GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
>>> backingPixelHeight = (GLsizei)(backingBounds.size.height);
>>> glViewport(0, 0, backingPixelWidth, backingPixelHeight);
>>>
>>> inside the drawRect method.
>>>
>>> The main issue is, the /convertRectToBacking/ method exists only since OS X
>>> 10.7, and my software still supports OS X 10.6 (so I need to build it with
>>> a 10.6 SDK, and not 10.7).
>>> I could drop the 10.6 support, but that is not an option for now.
>>>
>>> I have looked for another way, and I found the /backingScaleFactor/ method
>>> (it returns the scale factor, which is 2 for Retina displays, and 1 for
>>> other screens). But then again, this method is available only from 10.7.
>>>
>>> So, my question is, is there any way of detecting a Retina display, but
>>> usable with 10.6 ?
>>>
>>> Thanks in advance :)
>>>
>>> --
>>> Thierry CANTET
>>>
>>> ___
>>>
>>> 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/heardrwt%40gmail.com
>>>
>>> This email sent to heard...@gmail.com
>>
> --
> Thierry CANTET
>
> ___
>
> 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/mcguffogl%40gmail.com
>
> This email sent to mcguff...@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: Detect a Retina display
On Jun 20, 2013, at 9:11 AM, Thierry Cantet wrote: > I have tried your solution, however it does not work. > > I have these messages when I try to build with the base SDK set to 10.6 : >(Warning)Instance method '-convertRectToBacking:' not found (return type > defaults to 'id') >(Error)No viable conversion from 'id' to 'NSRect' (aka 'CGRect') You need base SDK set to 10.7 in order to be able to see 10.7 declarations and use them, and deployment target set to 10.6 in order to allow your code to load on 10.6. -- 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: Detect a Retina display
Hello Richard,
I have tried your solution, however it does not work.
I have these messages when I try to build with the base SDK set to 10.6 :
(Warning)Instance method '-convertRectToBacking:' not found (return
type defaults to 'id')
(Error)No viable conversion from 'id' to 'NSRect' (aka 'CGRect')
Le 20/06/13 16:18, Richard Heard a écrit :
No retina devices can run 10.6, therefore you can safely assume 1.0.
This means you can use a runtime check for the selector, and if its
not available default to a 1.0 multiple
eg:
- (NSRect)backingBounds {
if ([self respondsToSelector:@selector(convertRectToBacking:)]){
return [self convertRectToBacking:self.bounds];
}
return self.bounds;
}
-Richard
On 20/06/2013, at 11:49:18 PM, Thierry Cantet
mailto:thierry.can...@tvpaint.fr>> wrote:
Hello !
I have a quick question concerning Retina displays.
My software uses OpenGL for displaying the pixels. However, on a
Retina screen, OpenGL behaves strangely.
There is a fix (
https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
) that requires you to use :
NSRect backingBounds = [self convertRectToBacking:[self bounds]];
GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
backingPixelHeight = (GLsizei)(backingBounds.size.height);
glViewport(0, 0, backingPixelWidth, backingPixelHeight);
inside the drawRect method.
The main issue is, the /convertRectToBacking/ method exists only
since OS X 10.7, and my software still supports OS X 10.6 (so I need
to build it with a 10.6 SDK, and not 10.7).
I could drop the 10.6 support, but that is not an option for now.
I have looked for another way, and I found the /backingScaleFactor/
method (it returns the scale factor, which is 2 for Retina displays,
and 1 for other screens). But then again, this method is available
only from 10.7.
So, my question is, is there any way of detecting a Retina display,
but usable with 10.6 ?
Thanks in advance :)
--
Thierry CANTET
___
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/heardrwt%40gmail.com
This email sent to heard...@gmail.com
--
Thierry CANTET
___
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: Detect a Retina display
No retina devices can run 10.6, therefore you can safely assume 1.0.
This means you can use a runtime check for the selector, and if its not
available default to a 1.0 multiple
eg:
> - (NSRect)backingBounds {
> if ([self respondsToSelector:@selector(convertRectToBacking:)]){
> return [self convertRectToBacking:self.bounds];
> }
> return self.bounds;
> }
-Richard
On 20/06/2013, at 11:49:18 PM, Thierry Cantet wrote:
> Hello !
>
> I have a quick question concerning Retina displays.
> My software uses OpenGL for displaying the pixels. However, on a Retina
> screen, OpenGL behaves strangely.
>
> There is a fix (
> https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
> ) that requires you to use :
>
>NSRect backingBounds = [self convertRectToBacking:[self bounds]];
>GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
>backingPixelHeight = (GLsizei)(backingBounds.size.height);
>glViewport(0, 0, backingPixelWidth, backingPixelHeight);
>
> inside the drawRect method.
>
> The main issue is, the /convertRectToBacking/ method exists only since OS X
> 10.7, and my software still supports OS X 10.6 (so I need to build it with a
> 10.6 SDK, and not 10.7).
> I could drop the 10.6 support, but that is not an option for now.
>
> I have looked for another way, and I found the /backingScaleFactor/ method
> (it returns the scale factor, which is 2 for Retina displays, and 1 for other
> screens). But then again, this method is available only from 10.7.
>
> So, my question is, is there any way of detecting a Retina display, but
> usable with 10.6 ?
>
> Thanks in advance :)
>
> --
> Thierry CANTET
>
> ___
>
> 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/heardrwt%40gmail.com
>
> This email sent to heard...@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: Detect a Retina display
On Jun 20, 2013, at 7:49 AM, Thierry Cantet wrote:
> Hello !
>
> I have a quick question concerning Retina displays.
> My software uses OpenGL for displaying the pixels. However, on a Retina
> screen, OpenGL behaves strangely.
>
> There is a fix (
> https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1
> ) that requires you to use :
>
>NSRect backingBounds = [self convertRectToBacking:[self bounds]];
>GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width),
>backingPixelHeight = (GLsizei)(backingBounds.size.height);
>glViewport(0, 0, backingPixelWidth, backingPixelHeight);
>
> inside the drawRect method.
>
> The main issue is, the /convertRectToBacking/ method exists only since OS X
> 10.7, and my software still supports OS X 10.6 (so I need to build it with a
> 10.6 SDK, and not 10.7).
> I could drop the 10.6 support, but that is not an option for now.
>
> I have looked for another way, and I found the /backingScaleFactor/ method
> (it returns the scale factor, which is 2 for Retina displays, and 1 for other
> screens). But then again, this method is available only from 10.7.
>
> So, my question is, is there any way of detecting a Retina display, but
> usable with 10.6 ?
>
> Thanks in advance :)
if ([self respondsToSelector: @selector(convertRectToBacking:)]) {
GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width)...
--
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
Detect a Retina display
Hello ! I have a quick question concerning Retina displays. My software uses OpenGL for displaying the pixels. However, on a Retina screen, OpenGL behaves strangely. There is a fix ( https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW1 ) that requires you to use : NSRect backingBounds = [self convertRectToBacking:[self bounds]]; GLsizei backingPixelWidth = (GLsizei)(backingBounds.size.width), backingPixelHeight = (GLsizei)(backingBounds.size.height); glViewport(0, 0, backingPixelWidth, backingPixelHeight); inside the drawRect method. The main issue is, the /convertRectToBacking/ method exists only since OS X 10.7, and my software still supports OS X 10.6 (so I need to build it with a 10.6 SDK, and not 10.7). I could drop the 10.6 support, but that is not an option for now. I have looked for another way, and I found the /backingScaleFactor/ method (it returns the scale factor, which is 2 for Retina displays, and 1 for other screens). But then again, this method is available only from 10.7. So, my question is, is there any way of detecting a Retina display, but usable with 10.6 ? Thanks in advance :) -- Thierry CANTET ___ 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: positioning two UILabels with auto layout problem
Hi, or you can use visual format, which is much shorter … NSDictionary *viewsDictionary = NSDictionaryOfVariableBindings( _firstLabel, _secondLabel ); [self addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:[_firstLabel(>=16)]-16-[_secondLabel(>=16)]" options:0 metrics:nil views:viewsDictionary]]; … or look at some of my macros … https://github.com/robertvojta/mDevCamp-2013/blob/master/Auto%20Layout%20Demo/TMAutoLayout.h … and your code can be much shorter … TMALVariableBindingsAMNO( _firstLabel, _secondLabel ); TMAL_ADD_VISUAL( self.view, @"V:[_firstLabel(>=16)]-16-[_secondLabel(>=16)]" ); R. ___ 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
