Category: Apple

Delurking for a quick code snippet. I needed to have AppleScript check to see if a file exists before doing something. Initially I was trying to do this with a bare if *filepath* exists, until ninety seconds of searching revealed something obvious. You need to tell the Finder to do it.

For example…


tell application "Finder"
if exists file "Macintosh HD:Users:chrisb:Documents:test file.txt" then
display dialog "it exists"
else
display dialog "it does not exist"
end if
end tell


Like everyone else yesterday, I downloaded the iPhone Tracker app and peeked into the cached location database.

Nothing too unexpected (there’s a cluster of NYC data too), but I quickly noticed some spurious data. Specifically the cluster of data at Edwards Air Force Base (just to the left of the lake in the center) and the scattered plots just south of CA-58 in the Tehachapis. I figured that the location data was cached cell tower locations instead of GPS tracks which today’s follow-up stories seem to confirm. A Ihnatko commenter nails it:

Second:
Look at the timestamps on the data: rows occur as big clumps with IDENTICAL timestamps, ranging over a wide region. It’s not saying you were in a couple dozen locations all at once; it’s listing off all the visible cells (and their estimated locations, and the quality of the estimates) at a particular instant.

That’s the real reason you see data points in places you haven’t been: it’s not an artifact of the imprecision of cell triangulation. It’s one of the cells that was used *for* triangulation; i.e., your phone was able to detect a faint signal from a cell site at that approximate location.

Third:
Scroll back in time in the tracker tool, to the earliest weeks around home. (Helps if you choose a week when you didn’t travel anywhere). They’re probably almost empty, and the few data points that exist are in outlying areas you haven’t been to. Is this because you weren’t using your shiny new iPhone much in the first few weeks? Of course not! It’s because every other cell that was seen at that time has been observed again, more recently — so the corresponding row has been updated with a more recent timestamp. The remaining points for those weeks from long-ago represent the few cells that your phone *hasn’t* seen since then.

Apple isn’t trying to keep a location history at all; that’s just a side-effect of the thoroughness of this cell location caching.

Yes, in nefarious hands, this data can be used to track past locations — but only on the order of showing the most recent time your phone visited a given city. For a wide and frequent traveller, this could be upsetting. For someone that mostly sticks to just a few cities, the database reveals practically nothing.

To be fair, Android phones also caches location in a similar way (and there’s an app to read it out). so ease down on the “Big Steve Is Watching You” paranoia, but I got to wondering…

Could a location cache with false data be written to the phone? Could these location caches be introduced as evidence if regular call log/cell tower information is unavailable? How soon until someone devious enough frames a mark by changing the phone files to indicate that they were someplace they weren’t.

If you use this idea in a screenplay, I’ll only charge a modest 8%.

I don’t have anything to add to the generous helpings of fear and expectations surrounding the Apple announcements tomorrow morning, except for this (which is a restating of my first experience with the iPhone): if the iPad feels like a little bit of the future leaking into today then Apple will sell a gajillion of them.

Soon after upgrading my MacBook Pro (three year old 2.2 model) to Snow Leopard, I noticed the Battery menu item was giving me the “Check Battery” warning. Not a tremendous deal for me as 95%+ of the time I’m working on the grid and not on battery, but it was puzzling enough to get me to pursue it. Apparently, Snow Leopard has much improved battery monitoring but a lot of people out there are interpreting this as “Snow Leopard broke my battery” rather than “Leopard never told me anything about my battery.”

So I followed Apple’s instructions… reset the SMC a couple times and ran a full-discharge/recharge of the battery – to no effect at all. It’s a three-year old laptop and admittedly the battery wasn’t really holding a charge anyway, but I still have a couple months of extended AppleCare warranty left. Made an appointment with the AppleStore at The Grove and after a short wait, the Genius ran a detailed diagnostic on the battery from some sort of iPod-based app. The battery was indeed “bad” and not merely “depleted.” An important difference that determines whether your battery is dysfunctional (and covered under warranty) or just worn out from regular wear-and-tear that’s not covered.

The resolution? Apple replaced the battery free and now I’m happily computing again with 100% battery power for the < 5% of the time when I actually need it. Conclusions:

1. Always get AppleCare on any Apple laptop. Between this new battery and a hard drive replacement a year and a half ago the outlay for AppleCare has paid for itself. To repeat again: always get AppleCare on a laptop.
2. There must be some sort of fallacy/madness-of-crowds definition for the phenomenon of when providing more information causes less reasoning. Strangest recommendation was the advice to downgrade back to 10.5 strikes me as getting annoyed at a dashboard warning and putting a piece of tape over it.

Unlike some people I know, I actually have a pretty good track record with iTunes. No missing files, no ambient weirdness, handles the big music library I have with little to no indigestion. However there’s one particular behavior that sends me into player rage.

1. In the podcast section, hit the circle-i button to bring up the podcast information button.

2. Now attempt to close this window with command-W.

The main iTunes window closes and not the podcast window. One question… WHY?

Unsolicited testimonial…

I’ve been so accustomed to switching computers via FireWire target disc mode that when it came time to upgrade the quaint 5400rpm/160GB internal drive on my notebook to a speedy new 7200rpm/320GB drive I was all ready to plunge into the hassle of booting both drives on a second computer and then cloning. I figured there had to be some locked or in-use files that wouldn’t copy over no to mention the morass of file permissions that needed to be tracked.

Carbon Copy Cloner (donation-ware even!) couldn’t do all that by itself, that’s way too unnervingly easy. In the end it was that easy: hook up the new drive via FireWire, tell Carbon Copy Cloner to clone to the new drive, open up the case and replace new drive with old drive, and finally shame yourself for thinking in Mac OS 9 still.

I immediately jumped on FontShuffle as soon as I ran across it, but it immediately gave me an idea. If I were advanced enough of a programmer I’d try it myself but I’m nowhere near that point. Here it is:

Take a picture of a font sample, and the app identifies it. Take more pictures to get a better match. That’s it.

It’s analogous to how TinEye can dig up information on an album by simply taking a picture of the cover. Call the app FontEye for now. I strongly suspect that you could sell a copy to every single person on Typophile’s Type ID board.

Remember that you heard it here first!