Comments on: Tutorial: Migrating Data

By: RickH

RickH — Tue, 13 Oct 2009 11:44:41 +0000

Hi. I stumbled across this thread while researching a similar problem to Ilya’s, and have a bit more info. Although my App1 created a custom named pasteboard and put a string into it without issues, and it was definitely marked persistent, App2 couldn’t find that same pasteboard afterward. More testing finally revealed the problem: App1 of course used create:YES, but App2 was using create:NO to check for the data’s existence. For whatever reason, even if the pasteboard already exists, I had to pass create:YES on the second call to successfully find it to retrieve from it. create:NO always returns nil, whether the data has been saved or not. I know this thread is done, but maybe this will help some future Googlenaut like myself.

By: Ilya

Ilya — Sun, 20 Sep 2009 19:31:06 +0000

To answer my own question, setting the value of the type to nil does seem to remove it.

By: Ilya

Ilya — Sun, 20 Sep 2009 19:23:37 +0000

Thanks again for your response, Alex. The #define is an Objective-C string, but maybe the system didn’t like it for some other reason. I’m for following your advice and using the general pasteboard, but I’ve got one question. Since the general pasteboard cannot be removed, and UIPasteBoard doesn’t seem to offer a method for removing objects, how do I get rid of the data I’m passing after I’ve retrieved it? Would setting it to nil do the trick?

By: Alex

Alex — Sun, 20 Sep 2009 05:59:32 +0000

I’d be guessing it’s your name then. Sure you #defined an Objective-C string @”name” and not a C string “name”? Usually that kind of thing crashes in short order, but sometimes it just fails silently.

Good way to check that (or if there’s some other problem with your name) would be to use the -pasteboardWithUniqueName: call, get its name, mark it persistent, and see if that works.

If that doesn’t produce any enlightenment I’d just skip past the problem and use the general pasteboard since it works and worry about this for 1.1 if the app becomes a hit. There’s no particular downside to doing that besides other applications can mess with the data, which in most circumstances probably isn’t a showstopper concern.

By: Ilya

Ilya — Sun, 20 Sep 2009 05:37:28 +0000

Here is my code for creating the custom pasteboard:
UIPasteboard *myPasteboard = [UIPasteboard pasteboardWithName:GTKPasteBoard create:YES];
myPasteboard.persistent = YES;

GTKPasteBoard is a #define.

By: Ilya

Ilya — Sun, 20 Sep 2009 05:12:09 +0000

Thank you for your prompt reply, Alex.

When I use the general pasteboard the data appears to be saved and retrieved successfully. So it looks to be an issue with the custom pasteboard handling. Anything special I should do with the pasteboard beyond creating it and setting the persistent property? Also, how undesirable would it be to use the general pasteboard instead of a custom one for passing application-specific data (using a custom type) between two apps? Thanks again for your help.

By: Alex

Alex — Sun, 20 Sep 2009 04:36:22 +0000

First off I’d try using the general pasteboard instead of a custom pasteboard. That’ll narrow it down to either your pasteboard handling or your data handling, which is a start.

By: Ilya

Ilya — Sun, 20 Sep 2009 03:56:17 +0000

having a problem with pasteboard persistence. i create a custom pasteboard with a unique name and set its persistent property to YES, but upon quitting and restarting the app or on quitting and launching another app the pasteboard is not found. any ideas? thanks

By: Alex

Alex — Mon, 17 Aug 2009 19:32:40 +0000

Haven’t got around to it yet — still waiting for a final 3.1 SDK before we have something to be sending it to…

By: Michael C

Michael C — Mon, 17 Aug 2009 18:58:16 +0000

@Alex:

How did it work out ? Was the UIPasteboard able to handle 100 MB ?