I realized I have been avoiding leaving tips in Foursquare because I didn't have a good way to post them from my website. So today I added the ability to syndicate my posts as Foursquare tips.
I have three different ways my posts can end up as tips on Foursquare:
That last one is interesting, because it doesn't quite map to the normal way tips end up on Foursquare. But I realized that sometimes I write text in my checkins that is actually more like a tip anyway, so I wanted to give myself that option.
I'm probably most likely to use the first option of replying to one of my own checkin posts to leave a tip. Since my checkins appear in my reader, I can actually post directly inline from the reader to go back and leave tips.
I also made the decision to not try to syndicate these automatically, instead I have to manually click the syndication option before my site will attempt to syndicate the post.
Here's what a checkin post on my website looks like:
And here's what that tip looks like syndicated to Foursquare:
Overall this was pretty straightforward to do. The hardest part was dealing with finding the Foursquare venue URL from my own internal storage of my posts for the three different options.
The Foursquare API for this is reasonably well documented (Add a tip to a venue), but there were a few gotchas. It's not immediately obvious from that page that you need to include the access token as a post body parameter, and you also need to include an API version string. These are documented elsewhere in their docs, so it didn't take too long to find, but if you just start out reading the specific API method you want to use, it's not mentioned there at all.
There is also a parameter in the API docs called "url" which is described as "A URL related to this tip" with an example value of "http://blog.zagat.com/taco-survey-results-are-here". At first I was excited that I may be able to link my Foursquare tips back to my website. But every time I tried including a URL in the request, I got back a generic error "bad tips/add request". Leaving out that parameter made the API call work. Oh well.
So hopefully this will encourage me to leave more tips on Foursquare! I find the tips very helpful when I travel, so I'm happy to contribute back to this data set!
An interesting feature of the Swarm app is how it handles photos uploaded to checkins. If you check in and attach a photo, the checkin is actually created before the photo is uploaded. If you're on a spotty Internet connection, you'll see this because your checkin will exist and you'll get points for it, but there won't be a photo yet. The app will then continue to upload the photo separately, retrying if it fails. This is actually a really great app design on the part of Foursquare, but does lead to some tricks with the API.
Since OwnYourSwarm uses Foursquare's realtime API, it will receive a POST request almost immediately, often before the photo exists at the API. This means the initial Micropub request might be missing the photo.
Today I made OwnYourSwarm send a Micropub update request to update your post after the photo is uploaded. When you post a checkin, if there is no photo, then OwnYourSwarm queues a background job on a 15-second delay. It will then check after 15 seconds to see if a photo exists, and sends an update request with the photo URL if so. If still no photo is found after 15 seconds, it will wait another 30 seconds and try again. This continues for the following schedule: 15 seconds, 30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes, 30 minutes, 1 hour. We'll see if this is too much polling, but the rate limits on Foursquare are relatively high. (500 requests per user per hour). This does mean that every checkin with intentionally no photo will be requested from Foursquare 8 times.
I had originally planned on using this same polling schedule to later pull back responses to your checkins (likes, and comments), but Ryan pointed out that I can probably use a simpler and more efficient polling schedule since the Foursquare API provides a method to return the last N checkins.
Now that I can post checkins on my website, the next step is to automatically copy my checkins from Swarm! I still like the experience of Swarm, and I still get value out of their analysis of my checkins, so I don't see myself leaving Swarm anytime soon. This way, I get the best of both worlds.
Today I created an initial draft of OwnYourSwarm, a service that will convert your Swarm checkins to Micropub requests, and post them to your site. This is an early draft of the service still, but it should be functional enough to post basic checkins to your site.
Similar to OwnYourGram, you first authorize the application to post to your Micropub endpoint, then you sign in with Swarm. Once your account is connected, any time you check in on Swarm, the checkin will be converted to an h-entry and posted to your endpoint.
The dashboard will show you your latest checkin in both Swarm's JSON format as well as the h-entry that it sends to your endpoint.
You can click the "send again" button to have it re-send the last checkin to your endpoint again, which is useful while you're initially setting up your server to support checkins.
To start with, I took a shortcut to make OwnYourSwarm include the photos from your checkin. Since in the Swarm app, the photos are uploaded after the checkin is created, the checkin will actually hit OwnYourSwarm before any of the photos are at the Swarm API. Eventually I want to enhance this to poll Swarm until photos appear, but for now, the shortcut is I wait 30 seconds after receiving the ping from Swarm before downloading the checkin. This will work fine for the majority of cases, however will fail when for example you're on bad wifi and a photo doesn't upload immediately. I will fix this later.
I've documented the next few things I want to add to enhance this on GitHub.
OwnYourSwarm is live today! It's definitely still experimental, but feel free to try it out if you'd like!
Checkins can easily be faked. The Foursquare app does a reasonable job of preventing fake (and accidental fake) checkins, but it's still possible. If checkins weren't posted on Foursquare, but instead were posted on each person's own website, the possibility of fake checkins is much greater. What would it look like to have a way for a venue to know (and republish) checkins that it knows were real?
The checkin post would need to include some piece of information that could only have been discovered by physically being at the venue.
The venue's TV screen always displays a 4-digit code and instructs people to include that code in their checkin post on their website.
When someone posts a checkin on their site, they link to the venue URL, so their site sends a Webmention to the venue's website.
The venue's Webmention receiver then looks at the checkin post, and verifies that the special code is included and that it has not already been used.
By providing people this code in the physical location, there is no way for someone to know the code unless they were actually there!
I've only had Foursquare's new "Swarm" app for a day, but I'm already super impressed. By trimming out all of the search/review features, they're able to focus the app on providing a great checkin experience and providing more ways to connect with your friends.
Congrats, Swarm, you just earned a place on my home screen.
Here are a few of my first impressions after using the app for a day:
This is a huge improvement! As soon as you tap the "check in" button, this screen opens with a venue pre-filled. So far it's done a pretty good job of choosing the right location when I open, since it appears to draw from my previous checkin history rather than just sorting by what's nearby. By pre-filling the location, it only takes two taps to check in!
I'll be interested to see how smart it is about choosing a location for me. Seems like it could get pretty accurate if it also factors in the time of day I'm checking in. (e.g. I usually check in to Barista around 10am so if I'm anywhere nearby and checking in at that time, chances are that's where I am.)
Something I've been wanting to do forever is search my checkin history! I'm surprised it took them this long to finally launch this feature, but it's fantastic!
I can't even say how many times I've wanted to know the last time I was at a place, or find out the last time I ate sushi. Now I can type the name of a venue, or even a category, and I'll see all my previous checkins!
I was definitely surprised to see a "plans" feature implemented by Foursquare! I remember years ago, many startups trying to implement this in one way or another.
The feature within Swarm is well executed, but I haven't spent enough time with it to know if it's truly valuable yet. I hope to get some chances to try it out for real in the next couple weeks. This great Portland weather sure helps!
The new layout of the home screen showing nearby friends is great! Having the list sorted by distance is way more useful than showing a timeline of all my friends' recent checkins regardless of their location.
Neighborhood sharing is something I've experimented with in the past myself, actually. For a while, a few of us were using an app we wrote using the Geoloqi API which would post to Facebook every time we entered a new city.
I'm hopeful that this will be a useful feature of Foursquare! However it's hard to tell after only one day. I'm definitely excited for it though! I've always thought that even this little bit of information would be more useful than no information, and it certainly doesn't take any extra battery power to collect location information at this level.
The sign-in experience was fantastic. I launched the app and it prompted me asking if I was "Aaron Parecki". It occurred to me that since iOS has no way for apps to communicate with each other, they must have implemented something clever! I asked Ryan Arana if he happened to know of any APIs that would let them do this, and he immediately pointed to the
identifierForVendor method on
UIDevice, which returns an identifier guaranteed to be unique across all apps by the same developer.
The way I imagine this would work is when the app launches, it sends the identifier to Foursquare's API which returns my Foursquare account info if it matches the same identifier for my Foursquare account. Then there must be an API method that returns a Foursquare access token given the vendor identifier. A very clever way of doing single-sign-on across multiple apps!
Overall, I'm super impressed with the app update, and it is definitely encouraging me to continue using Foursquare rather than replace it with my own homebrew solution on this site. Long-term, I will likely set up a realtime import of my Foursquare checkins similar to what I did with importing my Instagram photos using OwnYourGram.