Adding Pinterest sharing to your iOS app

Update: It looks like this latest version of Pinterest has removed the URL scheme to post directly to the app. I do hope they add it back in with another update.

I’ve been working on a new version of the iOS app, Wedding Dress Look Book by The Knot, and I wanted to add in sharing features for the most popular networks. This a wedding dress browsing and sharing app, it has to be the top three social networks, Facebook, Twitter, and of course, Pinterest. I know that Pinterest doesn’t have a public sharing API yet, but I use there app on my iPhone, and I have a good idea of how it works. For Facebook and Twitter I find out that iOS supports URL Schemes, which allow me to just open an app as I would open Safari. Just change the protocol, http for regular URLs, to the name of the app. I found a site that has a list of all sorts of apps that support this, fb:// for Facebook, twitter:// for the Twitter app etc. Unfortunately they didn’t have Pinterest, but an easy guess of pinterest:// launched the app right away, though I didn’t know of the options, and I still couldn’t find any documentation. I started to think about how the Pin It bookmark works, the URL scheme must be inside that JavaScript file that Pinterest loads onto the site in mobile Safari. After running the file, http://passets-cdn.pinterest.com/js/pinmarklet.js, through a Javascript Beautifier we can see Pinterest developers speak lolcat with plenty of hazSite and hazIOS. That was it!

51
52
53
54
55
56
if (a.v.hazIOS) {
	a.w.setTimeout(function () {
		a.w.location = "pinit12://" + e
	}, 25);
	a.w.location = "http://" + e
} else a.w.open("http://" + e, "pin" + f, a.a.pop)

Pinterest’s URL scheme is pinit12, I’m guessing 12 is a version number. A little more digging around and I came up with a list of working parameters.

URL Scheme: pinit12://pinterest.com/pin/create/bookmarklet/?

  • media: a direct link to the image or I think an encoded image (base64?)
  • url: the URL of the source website where the image was found
  • description: 500 characters max
  • is_video: self describing

Since this code isn’t officially supported it is subject to change, and thankfully there is a way to future proof your app from having a broken link. You are able to check if a URL can be opened without actually opening it in iOS. The trick then is prepping your URL, seeing if it can be opening, and only then displaying the option to share with Pinterest. Using a UIActionSheet, with ARC enabled, this is what I came up with.

int count = 1;
UIActionSheet *sheet = [[UIActionSheet alloc] initWithTitle:@"" delegate:self cancelButtonTitle:nil destructiveButtonTitle:nil otherButtonTitles:@"Email", nil];
 
NSString *post = [NSString stringWithFormat:@"pinit12://pin/create/bookmarklet/?media=%@",@"http://yourdomain.com/yourimage.jpg"];
NSString *escapedStringURL = [post stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSURL *url = [NSURL URLWithString:escapedStringURL];
 
if ([[UIApplication sharedApplication] canOpenURL:url])
{
    [sheet addButtonWithTitle:@"Pinterest"];
    ++count;
}
 
[sheet addButtonWithTitle:@"Cancel"];
[sheet setCancelButtonIndex:count];

This way, in case the URL scheme changes from pinit12 in the future it won’t break your application.

It has been added as a URL scheme to http://wiki.akosma.com/IPhone_URL_Schemes, most links seem to hit that listing. Thanks @akosmasoftware!

iOS and Android, A Comparison for New Mobile Developers

The interest in mobile application development is continually growing. Even developers who are least open to change are starting to come around to the idea of developing on a mobile platform. Choosing between the two most popular platforms, Android and iOS, isn’t as simple as it may seem on the surface. Developers need to know what to expect from each platform before even starting a napkin drawing of their next great app idea. Between laying out an application’s interface, memory management styles and the native coding language available, understanding the similarities and differences of iOS and Android platforms will help programmers new to mobile development choose which platform is right for them.

The reduced display real estate on mobile devices will affect how a developer approaches conveying information effectively. Developers coming from web or desktop development will find the screen size very restrictive, so they must think farther ahead about how they will layout an application before they even begin coding. The vast range of available display densities and ratios for the Android and the limited number available for iOS will define how a developer new to mobile must approach creating an application’s interface. There are only two layouts for iOS, the iPhone size and the iPad size, and this means less time coding, testing and thinking about layout. However, every other application for iOS has the same restrictions on size and ratios, and that means standing out from the crowd on iOS will require extra design time. Since there are very little hardware restrictions for Android device manufactures, developers working on Android have a wider range of devices they must consider when developing and testing. Creating Android layouts requires thinking flexibly, letting the user interface flow and scale to a wide range of ratios and resolutions. The two platforms are very similar when it comes to cutting a layout into usable graphics, because both support three major pixel densities. Basic Android applications should support high, medium and low pixel densities ranging from 240 dpi (dots per inch) down to 120 dpi, while iOS applications should support the standard display’s 320×480 resolution, Retina display’s 640×960, and the iPad’s 1024×768 resolution. Each platform’s layout methods will define how a developer conceptualizes and creates visually appealing applications.

To make well designed, responsive, and beautiful applications, developers will have to carefully manage their memory. Memory management is approached very differently on iOS than on Android, and developers new to the mobile concept of reduced memory availability on mobile devices need to be aware of how each platform will handle allocations. Android uses automatic garbage collection, which will periodically run to see what objects in memory no longer have references to them and then remove those objects at that time. Some new mobile developers might get the impression that this makes memory management an after-thought, but that would be a mistake, because automatic garbage collection alone won’t keep an application from running out memory. Garbage collection automatically frees up unused objects, but the developer is still responsible for removing all references to objects to allow them to be garbage collected. These devices have very little memory available, and something as rudimentary as displaying images without making sure they are properly removed after they have finished being used will quickly turn into a big problem. iOS applications, which do not offer any form of automatic garbage collection, require developers to keep track of every object they allocate and release it explicitly from memory when they are finished using the object. This means that iOS memory overhead has the ability to always be at its lowest possible point with correct allocation tracking. Keeping track of memory reference counts can add a lot of extra lines of code to an application, but there is a new compiler feature for iOS, called Automatic Reference Counting, which adds these lines automatically at compile time. These two varied memory management styles are a part of each platform’s native programming language.

The native languages, Java for Android and Objective-C for iOS, are both object-oriented languages but offer very different coding styles that will greatly influence a new mobile developer’s decision of which platform they choose to pursue. Objective-C stays very close to its C roots, with each class consisting of a header and an implementation file. The header file defines what code will be written in the implementation file. Java files, which are more modern than Objective-C files, are made of a single class file that doesn’t have any separate header files. Both languages share a set of standard C primitive types like int, bool, char, float and double, which most developers will find familiar. They are both statically typed languages, which means that variables, functions and assignments are checked for type compatibility when the application is compiled. Their object-oriented styles allow developers to utilize a wealth of existing coding patterns such as Model-View-Controller and Singletons. When defining what a particular class will do, Java uses interfaces and Objective-C uses protocols. The interfaces of Java don’t need to be used in simple applications, but in Objective-C, protocols are heavily used because the primary method of passing information around is by way of delegates. While the difference in these two native languages may be great, the similarities of static typing and object-oriented design make either of them worthy choices. A developer who is already familiar with either one of the language backgrounds, Java or C style, might consider learning the other for the different perspective and challenges each language presents on mobile development.

Whether a developer goes with iOS or Android, the mobile space is opening up with new opportunities every day. Every existing company has some application in the mobile world and new companies are being created using only mobile applications. Mobile application development is a valuable skill to have, and a developer looking to stay current and relevant for the future of his or her career will want to learn more. Understanding the differences in how the platforms layout their interfaces, knowing how the memory is managed for each operating system and finding out which native language interests or fits developers best will give an eager developer the push they need to get started now. Knowing the basics about either of these two great platforms will give developers interested in iOS or Android enough information to choose which one they will want to learn more about. Any developer can, with a little research, find the right platform.

Three or More: Monster Match – My first iOS App Store game was approved

My first game, Three or More: Monster Match, was approved for sale on the App Store last night! It’s been a fun time since I started learning Objective-C in August to sending off my game for approval on October 5th. At one point I even considered stopping development and shifting gears into a more familiar language when Apple removed language restrictions on compiled native Flash apps not too long ago.

All development was done in Objective-C in the XCode IDE using the Cocos2d for iPhone framework which was very easy to understand and use. Coming from other languages I was in for a big shock when I had to worry about memory management and actually optimize for my iPod Touch development device I picked up. Getting used to finding my way around Mac OS X was fun as well.

All in all it felt very rewarding to stick with Objective-C as my development language and getting approved last night was an amazing feeling. From sitting down with Learning iPhone Programming: From Xcode to App Store and iPhone Game Development: Developing 2D & 3D games in Objective-C in August to now it feels like it has been a lot longer than it was. Right after I submitted I was already working on new versions of the game.

I was very nervous that I submitted a Halloween themed game for October on October 5th but thankfully it was approved by the 14th! Only 9 stress filled days of waiting, pretty low will all the horror stories I hear about getting approved.

Go get the game and let me know what you think!