Core Data lockup with parent/child contexts on iOS 5.1

I ran into an interesting Core Data lockup problem recently. It only arises on iOS 5.1.

I have a master-detail setup, and the master tableview has 3 different sorting schemes. I wrote a method for each of these schemes to create an NSFetchedResultsController, initialize it with proper sort descriptors, give it a cache name, and perform the initial fetch.

When the tableview appears, I fire off the appropriate method to get the NSFetchedResultsController I’ll use immediately. But then I wanted to warm up the caches for the other two modes, in a background GCD queue. Here’s what it looked like:

– (void)warmUpCachesExcepting:(NSInteger)dataviewMode

{

    dispatch_async( dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

        NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc]

                                    initWithConcurrencyType:NSPrivateQueueConcurrencyType];

        childContext.parentContext = self.staticdataMOC;

        if (dataviewMode != tailNumberDataviewMode) {

            @autoreleasepool {

                [[self class] tailNumberFetchedResultsControllerForContext:childContext

                                                                  delegate:nil];

            };

        }

        if (dataviewMode != ownerDataviewMode) {

            @autoreleasepool {

                [[self class] registrantFetchedResultsControllerForContext:childContext

                                                                  delegate:nil];

            };

        }

        if (dataviewMode != manufacturerDataviewMode) {

            @autoreleasepool {

                [[self class] makeAndModelFetchedResultsControllerForContext:childContext

                                                                    delegate:nil];

            };

        }

        [childContext release];

    });

}

Create a new managed object context, set its parent to my original MOC, go to work on the child. This code worked fine on iOS 6. When I switch sorting orders, the change is snappy. 

When I tested this code on an original iPad running iOS 5.1, the app would hang. I did some digging on Stack Overflow and other places, and saw comments suggesting that parent/child contexts had some problems on 5.1

As it turns out, I don’t need to pass results back to the parent MOC. I just wanted a separate context for my background thread. I changed the setup to create the new MOC and then point its persistent store coordinator back to the original MOC’s PSC.

                       NSManagedObjectContext *workingContext = [[NSManagedObjectContext alloc]

                                                      initWithConcurrencyType:NSPrivateQueueConcurrencyType];

                       workingContext.persistentStoreCoordinator = self.staticdataMOC.persistentStoreCoordinator;


Works like a charm now. I didn’t dig deep enough to see exactly where and why I was hanging.

iOS 6 maps are better for applications

I’m very happy to see the new look brought to iOS maps via Apple’s switch to an in-house solution. Much noise has been made about the errors and the lost detail. I think the lost detail is an improvement.

The other night, a friend and I did a side-by-side comparison of my app HistoryPointer on iOS 6 and iOS 5 (bonus points if you can figure out where we were sitting). HistoryPointer displays a bunch of points of interest on a map (further details aren’t especially relevant). On the top is the HistoryPointer running on iOS 6 (with maps from Apple); on the bottom it’s running under iOS 5 (with maps from Google).

IMG 1009

Photo

To my eye, the iOS 6 version is much easier to read when you’re looking for the overlaid points of interest.There are fewer labels on the Apple map than on the Google map. The color scheme is less intrusive. There are some problems with label placement on the Apple map: State Route 99, for example, near the right-hand edge, is missing its street name (Aurora Avenue) on the Apple version even though other less important streets are labeled.

I see lots of potential in this move. There’s a control panel to adjust label size on map views. There’s obviously some dynamic label generation and pruning going on. I like the prospect of enhancements to MapKit to allow programmatic control of many of these parameters. Imagine what you could do with API to do these things:

  • adjust the size of (or omit!) certain kinds of labels.
  • control the orientation of the map to maximize the use of the screen space. North doesn’t always have to be up.
  • apply a custom color scheme, so that your overlaid data is easier to read.
  • omit certain kinds of features. Not everyone wants driving directions. There are many applications where the streets, highways, and manmade features are simply clutter.

Think about the possibilities. How would you like your app’s MKMapView to be different? File those radars! I have several of my own in mind.

Drobo FS and Lion: update

I just had a phone call from a Drobo senior engineer. He was very frank and direct. It was the sort of conversation two developers have when nobody from management is in the room.

Without going into detail, I have to say that I was impressed. They have of course been testing this setup thoroughly, since the very first Lion developer previews. The Drobo engineer outlined for me the testing procedures they’re using right now, to try to replicate the failures some of us are seeing. They haven’t been able to replicate it. If you can’t make something bleed, it’s hard to kill it.

If you’ve ever shipped software, you’ve faced this situation. A customer experiences some bug, maybe even an intermittent one, that you can’t reproduce yourself. It is maddeningly frustrating for both the developer and the customer.

We were on the phone for 45 minutes. He had very specific logfiles that he wanted from my system. He laid out for me the plan they have for killing this problem, and the multiple approaches seem very sound to me.

They do indeed need the performance tests that first-level support has been asking us to run.

Based on what I learned today I’m going to hang in there for a while longer.

I have created a new Time Machine share on the FS, and I’m running a backup to it now from one of my Lion machines. It’s working fine. I’m going to give it a couple more hours, then kill it, and apply the procedure that Sébastien used. The only change I’ll make is to mount the shares manually using SMB, instead of having to play Beat The Clock.

One other update is that my Snow Leopard machine, which was (immediately after the new firmware) seeing absurdly low throughput, is now functioning fine. I didn’t touch anything. I just let it work.

Drobo FS problems under Mac OS X Lion

I’ve been very disappointed with my Drobo FS during the switch to Lion. I had been using the FS for Time Machine for 3 Macs, and it had been a stable operation for 6 months.

The Lion problems seem to stem from the tighter AFP requirements in Lion. Drobo was clearly not ready. The latest firmware update has made matters worse.

When I upgraded my first machine to Lion a week ago, Time Machine could not connect to the FS. I filed a support ticket with Drobo, and received this astounding response:

We are currently in the process of a firmware update to fix apple’s more stringent AFP requirements. This is just not an issue with drobo. Although we are working on a solutionto fix the issue I do recommend making a complaint to apple if enough customers complain about what they did they may roll it back.

Read that last sentence again. Drobo wanted their customers to ask Apple to change the low-level data communication specs on a major OS upgrade, after the upgrade was released. I was dumbfounded.

Anyone who is in the software business has missed a deadline. I was inclined to cut Drobo some slack for not being ready. But that request for me to lobby Apple on their behalf really left me wondering. Were they simply not able to write a driver that worked with the new spec? Were they planning to drop Mac support? Or were they just behind schedule?

There was one other funny thing happening. When I booted the Lion machine, the Accounts/Login screen appeared, and I could move my cursor around with the mouse. But mouse clicks were ignored. It was impossible to log in! If I shut down the Drobo FS, I was able to log in to the Lion machine. I suspect some background process was hung, waiting for the Drobo. This happened every single time I booted the Lion machine.

On Monday, 4 days after Lion was released, Drobo posted a new version (1.2.0) of the firmware for the FS. Their release notes claimed that it fixed the Time Machine incompatibility. I installed it last night, and things got much worse.

With the new version of the Drobo FS firmware, neither of my machines that are still running Snow Leopard can reliably connect to the Time Machine backup shares. One machine, a Mac Mini that sees very little filesystem activity, takes 20 to 30 minutes to connect to the Drobo. The 5 to 8 MB of data transfer takes about 30 minutes. The other machine, a MacBook Pro, has not yet managed to connect to the FS for a backup. I am seeing frequent Finder freezes (every few minutes) on both Snow Leopard and Lion, and occasional crashes that require a hard reboot.

If you have machines that will remain on Snow Leopard for a while, I suggest that you not install the latest Drobo FS firmware, because it will break Time Machine and make your Finder creep. If you’re in an all-Lion environment, then it doesn’t matter which version of the firmware you use, since neither of them works.

One Twitter follower suggested the Promise DS 4600 as a Drobo replacement. I’m going to give Drobo a few more days before I give up on them completely. I have Backblaze installed on all the machines too, so it’s not a crisis for me yet.

The creation date of the latest FS firmware is July 19, two days before Lion was released, and 6 days before the firmware was released. I have a hunch that things are very busy at Drobo right now.

UPDATE Friday, July 29

I just called Drobo Support. The technician acknowledged that the 1.2.0 firmware does not solve Lion compatibility. He gave me instructions for downloading and running the test suite at http://www.aja.com/ajashare/AJA_System_Test_v601.zip to measure network performance. I haven’t done that yet.

One commenter suggested downgrading the firmware to the previous version. The Drobo support person told me that that would require the datapack to be reset, resulting in total data loss.

My personal advice is still that you skip the 1.2.0 firmware update and wait for their next attempt.

data capture from Yaesu FTM-350R

 

 

Yaesu’s FTM-350R mobile APRS radio has very sparse documentation on how to communicate with the radio. It’s possible to listen to the data output in 3 different formats: Packet, waypoints, or GPS output. Here are some captures of the various output formats, using a radio with the version 1.2 firmware update applied.

All of these files were capture from a Yaesu FTM-350R with firmware version 1.2. For all captures, the comm settings between radio and computer were 4800-N-8-1, XON/XOFF handshaking.

 

The “packet 9600” file was capture from the Puget Sound area’s two 9600 baud APRS channels on 144.350 and 440.800. “packet 1200” was captured on the 1200 baud frequency of 144.390.

 

The different modes were selected using the E16 menu, option 2: “GPS OUT’, “PACKET”, or “WAYPOINT”. The “startup” file was capture with “PACKET” chosen.

 

Here’s a brief excerpt of the Packet format. The full sample files are attached.


K7MHL-9>T7TSRQ,WW7RA,SOMTN,WIDE2* [12/21/10 12:16:36] <UI R>:
`2\ao C>/`"46}443.325MHz Mike HL_"

 

K7MHL-9>T7TSRQ,WW7RA,BALDI,WIDE2* [12/21/10 12:16:38] <UI R>: `2\ao C>/`"46}443.325MHz Mike HL_"

K7PAL-9>EH4PSW,WIDE1-1,WIDE2-1 [12/21/10 12:16:41] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA*,WIDE2-1 [12/21/10 12:16:42] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA,SOMTN,WIDE2* [12/21/10 12:16:43] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

K7PAL-9>EH4PSW,WW7RA,BALDI,WIDE2* [12/21/10 12:16:44] <UI R>: `22SnSkk/>"5!}444.700 103.5 QA

WW7RA>ID [12/21/10 12:16:45] <UI>: WW7RA/R DISABL/B

KB0CVX>T7PPQT,SOMTN,WIDE1* [12/21/10 12:16:47] <UI>: `2M<l#W@/ APRS AD7AB-9>4WPWVQ,BALDI*,WIDE2-1 [12/21/10 12:16:49] <UI R>: '29^l"3>/]"4n}TM-D700A at conference.


73

Hal N3YX

PACKET (monitoring 1200 baud frequency):

packet 1200 12-21-10.pdfPACKET (monitoring 9600 baud frequency):

packet 9600 12-21-10.pdf

Startup sequence:

startup 12-21-10.pdf

GPS output:

GPS 12-21-10.pdf

Waypoint output:

waypoints 12-21-10.pdf

Brent Simmons: Notes from Mac programming class guest lecture

Last week, Brent Simmons was kind enough to visit the Mac programming class I’m teaching. He’s posted the notes from his talk online:

Notes from Mac programming class guest lecture: “The idea behind the lecture was to talk about what makes a great Mac app. I took that as an excuse to talk about everything from work habits to UI to marketing. “

(Via Brent Simmons inessential.com.)