OpenOvo's Blog

Linking Private Framework

openovo — Mon, 15 Dec 2008 02:15:54 +0000

Using Private Framework is banned by Apple. It’s the biggest violation to Apple’s sdk agrement. But who cares, that doesn’t mean we can try and experiment what we can really do with an iphone. I’ll show you here in few lines how to link at runtime your application with a private framework. In this case I will use Apple80211.

void *libHandle;
void *airportHandle;
int (*open)(void *);
int (*bind)(void *, NSString *);
int (*close)(void *);
int (*associate)(void *, NSDictionary*, NSString*);
int (*scan)(void *, NSArray **, void *);

libHandle = dlopen(“/System/Library/PrivateFrameworks/Apple80211.framework/Apple80211″, RTLD_LAZY);
open = dlsym(libHandle, “Apple80211Open”);
bind = dlsym(libHandle, “Apple80211BindToInterface”);
close = dlsym(libHandle, “Apple80211Close”);
associate = dlsym(libHandle, “Apple80211Associate”);
scan = dlsym(libHandle, “Apple80211Scan”);

The real drawback of this approach is that the framework absolute path is hardcoded in our call to dlopen, which means Apple is able, with a real small change to the OS, to breaks our app. For completeness, the last framework organization change happened with the big step between firmware 1.x and 2.x.

This code is a fragment of a wifi finder project recently implemented by myself. You can download it from here.

Dynamic Splash

openovo — Mon, 15 Dec 2008 01:48:37 +0000

iPhone apps take few seconds to launch (also more, depends on how bad is the programmer). Developers can anyway add a splash screen to their application, an image displayed for few seconds while the app is till loading. iPhone OS will always load an image named “Default.png” from inside your application bundle as a splash screen. Apple apps can replace the image “Default.png” inside the application bundle every time the application terminates, creating the nice/cool/useless effect of having a different splash screen at each startup, usually displaying the last screen of the app before closing it. The bad news for simple developer is that application bundles are cryptographically signed, you can’t modify the contents of the application bundle (by, in this case, changing the default.png resource file) without breaking the digital signature.

Seems like we are stuck with one splash screen for each application, but there is a nice workaround, from Patrick Collison:

http://collison.ie/blog/2008/11/dynamic-defaultpng-files-on-the-iphone

The simple trick is to put a symbolic link called “Default.png” in our application bundle, pointing to an accessible location on the device. In this way, our app can create different “real” splash screen at runtime.

Here a good comment from John Gruber (http://daringfireball.net/),

But I don’t think these dynamic default.png files are a good idea in the first place. I fully realize that the user’s perception of performance is often more important than actual measured-by-a-stopwatch performance, but in the case of dynamic default.png files, I think it goes too far. It is frustrating to see a complete UI that looks usable but isn’t. Dynamic default.png files make application launch times look faster, but they don’t make them feel faster. I feel like a dolt every time I get tricked into uselessly tapping UI elements on a default.png screen.

Well, probably John is right, and the dynamic default splash screen is useless, but trying to do what Apple tries to prevent us to do, is sooo good!

Fast Scrolling

openovo — Mon, 15 Dec 2008 01:08:57 +0000

Apple’s applications scroll faster!

have you ever compared the scrolling of emails or contacts with table scrolling in most third-party apps? well, Apple’s apps are way faster. It’s way faster also compared to the sample code posted by Apple for scrolling table. But in this case, there is no private API, private framework or sort of magic trick available to someone but not to everybody. The authors of Tweetie come up with the solution to the problem, and they also posted the code:

http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/

We could discuss if having a table scrolling so fast that it’s impossible to read is good or bad. Personally I like it. I would like to see how it performs in case of table cell more complicated, with some images for instance. Probably I’ll do some experiment about that in the future.

In the meantime, update your app and start scrolling faster!