developer.casgrain.com

It might be interesting to extend the implementation to support a GPS device, if available.

This is an awesome idea. Good work!

-W

Thanks! Everybody please be sure to file a Radar with Apple to ask for Core Location to be supported on the desktop (or really, where it’s really useful is a laptop). If enough people explain how useful it can be for road-warriors, we might get a very accurate official implementation in Snow Leopard…

Very cool, great job!

What license has this been released under? I didn’t see it in the zip anywhere.

Philippe,

I work for Skyhook and just wanted to correct your statement that we require a paid license. We offer an SDK to any developer who wants to integrate it into an application. You can get the SDK here: http://www.skyhookwireless.com/developers

We think this is a great project and we are happy to help out in any way we can. Feel free to email me directly — rsarver skyhookwireless com — if you have any questions.

Best, rs

I’m curious about the pattern used in the CoreLocation implementation files – specifically, the internal object that is being held on to by instances of those classes. What’s going on here – is it for thread-safety, or something else, or is it just a matter of programming style? Finally, is it common in Cocoa, or is this a somewhat unusual usage?

Why not use the iPhone as GPS device and build an IP connection using CoreLocation on the phone sending the data to the DesktopCoreLocation framework. Could be done in various stages like the phone does with carrier locating when GPS is not available yet.

Your presentation was great! Go Canada!

You couldn’t give us an Application demo without having to build it?

Some notes:
– in performSelectorOnMainThread:withObject:, both the receiver and the object are retained. That means you don’t have to do the retain/release dance you’re currently doing.
– your internal object has all its properties marked “assign”. That’s almost certainly not what you want. Specifically, the delegate should be assign, all others should be retain or copy. You’ll have to add a dealloc method, but the rest of your code will be much simpler (e.g. in updateLocation: you won’t have to worry about that ipAddress var which is currently only valid by sheer luck).
Generally, you want to copy any possibly mutable objects (specifically strings), retain all noncopyable objects (like NSThread), and assign only delegates, data sources and the like.
– likewise, is there any reason internal isn’t a property?

HTH, and nice work!,
Johannes

If you’re running it on a system that isn’t online at the moment, you could fall back on the less precise “nearest major city” stored by Mac OS X:

BOOL GetCityLatLong(Location *outLocation) {
id city = [[NSUserDefaults standardUserDefaults] objectForKey: @”com.apple.TimeZonePref.Last_Selected_City”];
if (city && [city isKindOfClass: [NSArray class]] && [city length] >= 2) {
/* First two elements are the L/L. */
if (outLocation) {
outLocation->latitude = [[city objectAtIndex: 0] doubleValue];
outLocation->longitude = [[city objectAtIndex: 1] doubleValue];
}
return YES;
}
return NO;
}

And, I should say, you can listen for @”NSSystemTimeZoneDidChangeDistributedNotification” distributed notifications and update your reported location when they occur.

Тоже думаю добавить в закладки, интересный блог.