dog

Archive for the ‘Cocoa’ Category

I Don’t Want to Be Counted, I Just Want Links

Tuesday, November 8th, 2011

I am an avid Google user and even though the quality of results has suffered in the last few years, I still use Google almost exclusively when researching a topic. When the question is simple, a visit to Wikipedia or Stackoverflow will suffice but when things get complicated I tend to open several of the search results for browsing. Inevitably the time comes when I realize I want to open a previous result that was prematurely closed but is now key – unfortunately Google has left my history useless.

I’ll never find that page even though I distinctly remember having “Step by Step” in the title and a favicon that had some sort of diagonal stripes.

Why is my history so useless? Is my computer broken or has Google broken the internet? Google actually displays the actual link under each title of the page to let users know what page they will be visiting. The link is also the actual href attribute of the link and is displayed at the footer status bar during a mouse over. But why isn’t it the link I get when I click or copy it? Because when the time comes to use a link Google uses Javascript to replace the link with a redirect to their own servers in order to keep track of what links users are clicking on (except when the link points to their own Google domain like images or maps).

As wonderful as that information might be to Google in improving their results rankings and knowing what results I favor most, it’s messing with my history as well as my ability to copy and paste a link (“Copy Link” shown above picks up the modified link) for a blog post or to email to a friend.

There must be a way to get the old direct-to-result Google back. There are no options to disable this behavior that I could find, not even in the name of privacy. After some searching I ran into a Japanese gentleman with the same linking sensibilities as mine who has written a Grease Monkey script that solves the issue. But in this day and age I want a simple Safari Extension that I can install and manage natively in Safari. After poking around for such a script (Dear Apple, could we please have search functionality in the extension gallery) I decided to build my own. I know nothing about Safari Extensions or programming one, but I am a Mac developer and I know what I want, so I started developing.

One hour and three lines of code later I present to you Google Direct. The Safari Extension that will remove the redirects from the Google links by stripping the “onmouseover” events Google uses to trick the href link into the replacement link.

With Google Direct Safari extension installed I am a happy camper, my history is looking unique and identifiable (the same results but now with names and favicons).

‘Copy link’ also gives me the crisp, short, original URL instead of a indecipherable mess:

http://en.wikipedia.org/wiki/Croissant

Vs.

http://www.google.com/url?sa=t&rct=j&q=croisants&source=web&cd=1&
ved=0CCgQFjAA&url=http%3A%2F%2Fwww.cooks.com%2Frec%2Fsearch%2F0%2C1-
0%2Ccroisants%2CFF.html&ei=cCG4TtSiI6TX0QHD5NTRBw&usg
=AFQjCNF7fQtjSwE9hpdNkIV9Ytl7orz-Og

Are there any downsides? Depends on where you stand. I am indeed depriving Google of knowing what links I followed and approximating how long I stayed (how long it took me to come back and click on another link of the same result set). On my side of the fence, where I usually stand, it’s an added bonus that I now also control a little more of my privacy with my new extension.

P.S. I ended up using Fine Cooking Classic Croissants recipe for making croissants. Now it has an elegant white orange hat and a title that was easy to spot in my history when I went back two days later – after tasting the results – to add it to my permanent bookmarks.

Detecting PPC Code Before Mac App Store Submission

Friday, June 3rd, 2011

Since the Mac App Store is Intel only, developers have to submit applications that are stripped of all PPC code. Slowly more and more developers are building their applications Intel only, given that the latest versions of OS X, Snow Leopard and soon Lion, are Intel only. The Pedias rely on a large number of external frameworks, so it was not as simple as changing the build setting in Xcode. While the transition happens here is an easy command we used to find PPC code used in our applications.

find Bookpedia.app -exec file {} \; | grep "ppc"

Of course run in Terminal while inside the build directory and change Bookpedia for your app name. Should any frameworks or libraries be reported to contain PPC code, you can strip the PPC without rebuilding by using the lipo command.

lipo -remove ppc AFramework.framework/AFramework -output AFrameworkIntel

I stored these new Intel-only versions of the frameworks to be used by Xcode when building our software for the Mac App Store. Of course there is also the option of doing the stripping to the entire app after building with the ditto command (but I prefer to do modifications before Xcode’s final code signing step, even though Mac App submissions are re-signed for any changes during upload).

ditto --rsrc --arch i386 x86_64 Bookpedia.app Bookpedia-AppStore.app

Hope some developers with larger apps will find this useful.

Conditionally Building Mac App Store Applications to Exclude Sparkle

Wednesday, February 9th, 2011

A lot of developers are in the process of rebuilding their apps for the Mac App Store. One of the guidelines is not using any update mechanism and leaving the updating to the App Store. Like most developers we also use the Sparkle framework to do our non-App Store updates and figuring out how to build a version of your application without Sparkle can be frustrating. Some developers have already solved it in clever ways – our favorite being Gus Mueller from Flying Meat who uses a script to run a find and replace:

Then when my build script is run for App Store builds (-s) it’ll use /usr/bin/sed against Acorn’s project.pbxproj and replace all instances of Sparkle.framework with Noop.framework. Then the automated build takes place, and Noop.framework gets copied in instead of Sparkle.

But we feel there’s still space for another solution on how to conditionally include Sparkle:

1. You should have a configuration for the App Store. It can be created under the project settings “Configurations” tab. You should duplicate your Release configuration for these new settings.

2. Remove Sparkle from being automatically included in all linker calls. To do this remove it from under the Targets–>Link Binaries With Libraries.

3. Under all your regular configurations (Debug, Release, …) add Sparkle to the linker flags. Open the build setting and set “other linker flags” to “-framework Sparkle”.

OTHER_LDFLAGS = -framework Sparkle

4. You now need to remove Sparkle from the Mac App Store application folder after building it. Create a new custom script build phase to run at the end of your build (Custom Package Processing above) and make the script the following (do make sure that the value of $CONFIGURATION matches the name you set  your new configuration for Mac App Store releases):

#!/bin/sh
# Remove Sparkle Framework for MacAppStore
if [ $CONFIGURATION == MacAppStore ]
then
rm -rf "$TARGET_BUILD_DIR/$FRAMEWORKS_FOLDER_PATH/Sparkle.framework"
fi

The above takes care of the physical framework and linking but you still need to remove any code that calls the Sparkle framework. To do so set a variable in the Mac App Store build that you can use in your code to conditionally include Sparkle calls.

5. In your Mac App Store build setting set a flag, we use:

OTHER_CFLAGS = $(OTHER_CFLAGS) -DMacAppStore

6. Encapsulate all  your sparkle code with #ifdef preprocessor directives.

#ifndef MacAppStore
[[SUUpdater sharedUpdater] checkForUpdatesInBackground];
#endif

7. Don’t forget to update your interface if necessary. Remove any menus and check for update preferences. Include the menus programmatically for non-Mac App Store builds at applicationWillFinishLaunching:

#ifndef MacAppStore

// Insert Check For Updates menu
NSMenu *mainMenu = [NSApp mainMenu];
NSMenu *appMenu = [[mainMenu itemAtIndex:0] submenu];
NSMenuItem *uploadMenu = [[[NSMenuItem alloc] init] autorelease];
[uploadMenu setTitle:NSLocalizedStringWithDefaultValue(@"Check for Updates", nil, frameworkBundle, nil, nil)];
[uploadMenu setTarget:self];
[uploadMenu setAction:@selector(checkForUpdate:)];
[appMenu insertItem:uploadMenu atIndex:1];

#endif

The same method can be used for the eSellerate registration engine. The linker flags would be, “-lEWS -lValidateUniversal” and you would remove both the libEWS.a library and the compressed .zip version of the engine. Hoping the following proves useful to a few developers. Code on.

TV – Apparently It’s All the Rage

Friday, August 22nd, 2008

Dan at RowdyPixel.com has created a plug-in for TV Rage for those with a lot of TV season episodes. The plug-in has been crafted in order to download information specific to each single episode. In fact you have to include the season and episode number as part of the search to be able to determine the exact episode. “Burn Notice 02×01″ would download information for season two, episode one of Burn Notice. This is incredible useful for those keeping linked video files for each episode inside DVDpedia.

 

It’s not just a simple search plug-in, it also includes a level of flexibility unprecedented in any other plug-in. Under the plug-in menu you will find the “TVRage Options…” command that will let you change a number of settings on how to store the information, including the order of title-season-episode information. Head on over to rowdypixel.com to download and install the plug-in as well as to learn more about it. Please post any feedback in our forum and do not hesitate to donate to rowdypixel.com if you find the plug-in useful.

Options

Thank You Core Animation Engineers

Friday, April 4th, 2008

The newest version of the Pedias includes a Cover Flow view. Lucky for us, Apple’s Core Animation framework is excellent and so intuitive that it made Cover Flow possible. Apple even provides a sample application from which we copied our implementation; saving us lots of time. Not only does it provide the Core Animation code but also threading to load only the covers that are needed in the background thus keeping the Pedias responsive and light.

It’s not until I started programming with Core Animation that I realized how convenient it truly is. It takes care of everything no matter what happens in between. For example if a user clicks the forward arrow and then the back arrow, core animation reverses the animation without a stutter. It lets me take advantage of the graphic card in your computer without having to learn OpenGL; which is quite complex.

We are really excited how movies, books, games and CDs fade, fall in, pop, slide, scroll and twist in our new Cover Flow view and all without much code. If you are a Cocoa programmer, dive into Core Animation; if you are a Pedia user take our new version out for a spin. Either way, head on over to our videos page for a quick glimpse of the new Cover Flow view