SteveX Compiled

Tomorrow this time I should have my iPad (3rd generation). I'm looking forward to it. The retina display will look as good as everyone says it does, and that's about it as far as what I'm looking forward to.

Yes, the camera is better, but I've taken maybe 5 pictures with my iPad and I don't see that changing. And I didn't get an LTE-capable version, so that innovation is lost on me.

I do have some concerns about this new iPad.

It's thicker, and heavier than the old one. Not by much, and I'm sure that will fade into the background in time, but as Gruber says, it's a compromise. And I'm sure it's a compromised they worked really hard to not have, and that's what worries me.

The new iPad has a much bigger battery, reportedly 70% bigger, but has the same battery life, around 10 hours. This means more power consumption, and power consumption means heat. The iPad has no fan, no vents, so no way for heat to get out of the thing. Early reviews are reporting that they can feel it getting hot in one particular area.

Heat scares me.

I've seen three MacBook Pro systems die to the nVidia chip problem, where heat makes the GPU separate from the motherboard and basically bricks the system. Heat can be a killer, and the iPad wasn't really designed to dissipate heat. I'm afraid that in an effort to get the retina display into the iPad, Apple made some tradeoffs that are going to come back to bite them.

I don't know if this is going to be a problem or not, but it's the one thing I'm worried about with the new iPad.

A few days ago, I released my second iPad application, Resume Maker.

Two things that motivated me to create this particular application. One is that I'm currently unemployed, so I have been thinking about resumes.

But the second, more significant reason is that I've recently been asked by a couple of different people to help them put together a resume for themselves, which shows me that there are people that need a resume, and don't know that much about putting one together.

A resume is essentially a data capture and presentation problem. It's not really a free-form document. There is particular information that is usually presented in particular ways. So, Resume Maker takes a form-based approach to building a resume, where you supply information in input forms, and a custom rendering engine pours this data into a template that produces a resume.

This works pretty well. I used my own resume as well as the ones I created for friends to come up with the built in template, and it produces a nice, professional result. Here's a sample resume generated by the app.

There're a lot of different directions I can go with this product I'm looking forward to feedback from the first purchasers to help define what features are most important for future versions.

Some obvious features are more control over the appearance of the resume, including margins, fonts, and even additional templates. I'll be working on all this in the first update, assuming user requests don't suggest a different direction.

Check it out in the app store: Resume Maker

In iOS (and, actually, in almost any user interface) it's best to do as much work in background threads as possible, so your main thread is free to keep the UI smooth. To this end, I've been loading images from PDF files in the background using this sort of pattern (in pseudocode - this isn't a working example):

[cc]
- (void)loadImageInBackground
{
// Use Grand Central Dispatch to queue up loading an image on a thread
dispatch_async(renderQueue, ^{
// Open the PDF, render the page into an UIImage
UIImage *image = [self loadImage];

// Transition back to main thread to update the UI
dispatch_async(async_get_main_queue(), ^{
// Assign the UIImage to a UIImageView
imageView.source = image;
});
});
}
[/cc]

This works pretty well, and made for a very responsive UI, but when the user was rapidly scrolling through a document, the app was running out of memory. After some time in Instruments looking at where the memory was going, I found out that while scrolling, the main thread could wind up being too busy to dispatch the second part of the rendering, the part that passes the bitmap from the secondary thread back to the main thread.

The line above that says "Transition back to main thread" is where the problem starts. At this point, we've loaded an image, and we're waiting for a chance to update the UI - but that chance isn't coming soon enough, and we end up with an image taking up memory and nothing to do with it but wait. Meanwhile, the main thread, where the user is scrolling madly, is queueing up more background image processing. Eventually, it's too much and the app dies.

The fix? Wait for the render queue to clear out before queueing up any more work. Here's what that looks like:

[cc]
// Wait for any current background render to complete
dispatch_sync(renderQueue, ^{});
[/cc]

The dispatch_sync call ensures that the renderQueue is empty before we add anything else to it, because it synchronously queues up a job at the end of the queue. Once the job runs, the queue is empty and we can put more work on it.

I've been using the ~/Library/Mobile Documents folder in Lion to test adding files to my iCloud-enabled iOS app's Documents folder, and that's been working great for me, up until 10.7.3.

If you've got an iOS device and have iCloud enabled, take a look in ~/Library/Mobile Documents. (You can do this from Finder by picking "Go to Folder…" on the Go menu and typing it in). You should see folders there with names like these:

[cc]
com~apple~Keynote
com~apple~Numbers
com~apple~Pages
RZACDNSPFQ~com~joeisanerd~icatcher
28Y2DX2P93~net~stevex~CloudTester
[/cc]

That last one is my test app. The folder name is the developer's team identifier (so any apps from the same company will start with the same string) and the rest is the bundle identifier of the app.

Before 10.7.3, the Ubiquity daemon (Ubiquity is Apple's developer name for the iCloud services) would run all the time. It's called 'ubd' and you can see it in Activity Monitor. Or you could, before 10.7.3.

With 10.7.3, they decided that the Ubiquity daemon didn't need to be running unless there was some app that used the iCloud services, and so it's not running by default. But it's easy enough to bring back.

There are two ways: One is to run it. You can simply invoke it:

[cc]
/System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Support/ubd
[/cc]

But if you "man ubd" you get this warning not to do that:

---

NAME
     ubd -- ubiquity daemon, part of Mobile Documents

SYNOPSIS
     ubd

DESCRIPTION
     ubd is the ubiquity server process. It is primarily used for "Mobile Documents".

     There are no configuration options to ubd, and users should not run ubd manually.

SEE ALSO
     special_file_handler(8)

---

But there is another way. Simply run an app that uses iCloud. These aren't really easy to come by right now but here's a free one that you can get from the Mac App Store: Sticky Notes. Get that app and run it, and take a look in Activity Monitor. The ubd process should show up, and your Mobile Documents will be syncing.

It's obvious from this only-on-when-required behaviour that Apple doesn't intend for the Mobile Documents folder to be a DropBox-style synchronization service. I'm actually surprised that documents other than the ones used by the running app (in this case 2E337YPCZY~it~bloop~memo) are synchronized, and maybe this is a change they'll make in the future. So don't get too used to how this works today.

Side note: You can get all sorts of interesting information on how to use ubd by invoking it with the "--usage" option. I'm not sure they expect us to be poking around here - for example, one of the switches has this note:

apple2: Register in the 'csbonjour.apple.com.' domain.
To see & be seen in this domain, you must be inside
the Apple firewall and must have 'apple.com' in your
DNS search path in the Networking Pref Pane.

So play at your own risk.

I'm amazed at how easy it is to create a PDF on iOS.

[cc]
CGRect pageRect = CGRectMake(0, 0, 850, 1100);
UIGraphicsBeginPDFContextToFile(outputFlePath, pageRect, nil);
UIGraphicsBeginPDFPage();
CGContextRef pdfContext = UIGraphicsGetCurrentContext();

[self drawMyPageInContext:pdfContext];

UIGraphicsEndPDFContext();
[/cc]

That's it. You'll have a PDF in the file identified by outputFilePath that has whatever you drew in the drawMyPageInContext method. Beautiful.

There are plenty of pages that will help you add an Xcode project to Git, but I couldn't find anything on connecting Xcode to an existing Git repository. Here's how you do that.

Here are the steps for Xcode 4.2:

1. From the main Xcode window, select File / Source Control / Repositories…
2. Tap the little + button at the bottom of the repository list at the left, and select Checkout or Clone Repository.
3. Enter the location of the repository (which looks something like git@server.com:path/project.git), and hit Next.
4. Enter the name for the local project, and click Clone.
5. Select the location on your local file system for your local repository.

That's it - you'll have your project ready to open in Xcode, connected to a local repository, and ready to Push or Pull changes with a remote repository.

Note that for this to work your system needs to be configured with an SSL key that matches the repository. There are plenty of other pages that cover how to do this, so I won't cover it here. Instead, start with this page.

For the first time in a long, long time, I've released some software that I built myself, for myself. The app is called MealPlan and it's available for the iPad.

I even built a website for it, here. "Fall Day Software" is an entity I created to own the app, but it's just me so far.

Here's what the app looks like:

Click to see a larger version.

It's a pretty simple app. The goal is to help you plan out what meals you're planning to make over the next few days. I think there are people who will instantly get this, and people who will say "why would you want that?". If you're the sort of person who has ever tried to do this in a spreadsheet, then this app is for you.

I spent a lot of time thinking about the workflow around planning meals. This isn't the first app to tackle this problem, but I think it's the most efficient. The goal is to spend as little time as possible fiddling with the app, and more time getting the job done. So to populate the meals for a week, here's what you do:

(This is in the simulator so you see a mouse pointer (horror) instead of your finger doing the work, but you can see the workflow).

And once you've entered enough data into the app, you can use the Magic Wand to help you plan things. This is a huge time saver. Here's how this works:

You tap the magic wand and any empty meal tiles are populated with pseudo-random choices from previous days. Any choices you like you can tap on to lock them, and when you're done, you can choose to keep just the tiles you locked, keep all the choices, or cancel the whole operation.

The app is a native Objective-C application. MealPlan for the PlayBook is a Flex based application, but for the iPad, I wanted to take advantage of printing, native email support, and various other features of the iOS platform that were just awkward from Flex.

Some plans for future versions:

• iCloud support - the app already uses UIManagedDocument to store data so iCloud support isn't a big leap. This would really work well with...
• iPhone support, for viewing your meal plan while you're in the grocery store.
• Customizable meals. Not everyone wants "Breakfast, Lunch, and Dinner".
• Meal properties - like being able to associate a recipe link or calorie count with a meal.

Where the app goes from here really depends on the feedback I get from this release.

I know this isn't going to be a blockbuster app, but I'm hoping people who want this sort of app will find it and like it.

So here's that link again. MealPlan. Go give it a try, and let me know what you think. Thanks. :)

There have been rumours that Rogers and Bell, the two big telecom providers in Canada, have Apple iTV television sets in their labs for testing. That's an interesting rumour for a couple of reasons.

Why would Rogers or Bell care about a new television? Why would Apple involve them? If the rumour is true, then there's more to this device than just being a television set.

When a customer subscribes to television from one of these companies, they need to get a hardware box that acts as a decoder and often as a PVR. This is an expensive box - several hundred dollars typically - and is usually tied to a contract.

So today, you buy whatever TV you like, and you hook it up to a box that you rented from your service provider.

What if.. Apple's new TV integrates the provider's box into the TV.

This would mean you'd be buying a TV that's locked to Bell, or a TV locked to Rogers, the same as happens for cell phones. This would let the service provider subsidise the TV.

The cost of a TV these days isn't that much different from the cost of an iPhone. An unlocked iPhone 4S costs $649 in Canada. You can get a 50" TV set for that kind of money.

If the TV can be locked to the provider and tied to a contract, then they can subsidise it. Walk into a Bell or Rogers store, sign up for a 3 year contract, and pick up a new 50" TV for $199.

What's the upside for Apple? It's hard to say at this point. Perhaps Apple uses the iTunes store model a revenue share with the provider - so you rent a movie for $4.99 and the provider gets 70% of that and Apple keeps 30%. This arrangement would also let the TV provider, which is also typically the ISP, exclude their own streaming media from bandwidth caps, something that's hindering Netflix today.

The 3 year contract model for the TV would also answer one of the questions people have about why Apple would get into the TV business: How to get users to upgrade more frequently, since people typically buy a TV and keep it for many years. If you could get a new TV every 3 years for $199, wouldn't you?

So there's been some blog chatter this week about the mute switch on the iPhone. Of course it's not really called a mute switch, and it doesn't really "mute" the phone. It's really just a signal to the OS that the user would like less sounds.

I fall firmly on the "the mute switch should really mute the phone" side of the fence, at least optionally.

If I'm in a location where I'm expecting my phone to be silent out of respect for something (like, in a movie, at a live performance, or at a funeral) then even if I have an alarm configured for that time, I don't want it to go off. It's going to embarrass me if it goes off. And yes, I even include the "Find My iPhone" sound in the list of sounds I don't want my phone playing in these situations. There are some times when I want to know that my muted phone really isn't going to make a sound.

But the difference is I don't expect the phone to stay that way.

John Gruber mentioned that when he mutes his phone while in a movie, he almost never remembers to unmute it. That's a common problem, but it's not a hard one to solve.

There was a feature on an old phone I had, that would let you mute the phone for a period of time. "Mute for 2 hours", for example. When you think about it, mute is almost always situational. You want your phone muted for a while, and usually you know how long. This would do away with the problem of "I muted my phone for a movie but then I missed my alarm clock the next morning because my phone was still muted".

Better yet, make the phone muting part of a meeting setting. When I put the appointment in my calendar to go to a movie for 2 hours on Thursday, I'd like to set the phone to mute right there. That way there's no chance I'll forget to mute it, and no chance I'll forget to unmute it.

This seems like an obvious feature but I've never seen any phone support it.

I'd been having this problem for a while and decided to dig into it today. I have shares from a Lion box, but when I'd attempt to connect from Windows 7, it would just refuse my credentials.

Here's the solution that worked for me.

Edit this file in a text editor:

/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist

You'll need permissions to edit it. Run your editor using sudo, for example.

Add the following keys:

[cc]
AllowKerberosAuth
AllowNTLM2Auth
KerberosRealm
***COPY-THE-LocalKerberosRealm-VALUE***
[/cc]

Don't forget to edit this to copy the LocalKerberosRealm value into the KerberosRealm value.

Once you've done this, save the file, turn SMB sharing off and back on, and you should be able to log in. I'm not convinced this is "the fix" for everybody, but it worked for me.