Api

For several years millions have shared the places they’ve been using the Where I’ve Been website and Facebook application. The site also has an API (our Where I’ve Been API profile), which allows for much of the same functionality, such as searching countries, marking it visited and adding content such as a story or photo.

The API has an impressive array of methods. Many are accessed via OAuth, which means that users provide your application permission to access their data. Twitter, as well as several other popular APIs, also use this method, more secure than sharing passwords.

Developers of mapping mashups might take specific note of the search and place methods. Developers can find cities by latitude and longitude coordinates, which would allow for some interesting mobile applications, such as logging road trips. Additionally, countries and cities can be searched by name.

The API also contains a few other things we like to see: sample code and even a place to see the platform status (at the bottom of the page).

While the Where I’ve Been API looks useful for retrieving locations, it’s obviously been built to support the site itself. Therefore, the extensive user methods are best used for social travel sharing, the same thing that has made the Where I’ve Been product so popular.

…and we use the word refine very loosely. In the last 30 days, Apple has dropped the App Store ban-hammer on applications that display images of scantily clad women and Wi-Fi scanning/stumbling applications. The bare-naked ladies were removed because, as Apple VP Phil Schiller put it, “the needs of the kids and parents” had to come first. Wi-Fi scanning applications got the boot for making calls to a private API, which raises the obvious question… why were these applications approved in the first place? So, what is latest app genre to feel the sting of Apple’s proverbial backhand? So called “cookie-cutter” applications. Apple is beginning to reject apps that were created using application building services and do not add any specific functionality to the iPhone or iPod Touch. Or, as TechCrunch’s Jason Kincaid succinctly put it, “Apple doesn’t want people using native applications for things that a basic web app could accomplish.” Whatever the reasoning, Apple is sending a scary message to potential application developers… we can change our mind.

Read

jQuery is not always as it appears. There's a lot of cool stuff going on under the surface, and there are many methods just waiting to be discovered, and many potential usages of jQuery's API that you may not have considered before. In this article I'll be taking you through a few of the not-so-obvious things I've discovered about jQuery.

1. Understand jQuery!

When you call 'jQuery' what happens?

The jQuery function itself is very simple:

jQuery = function (selector, context) {
    // The jQuery object is actually just the init constructor 'enhanced'
    return new jQuery.fn.init(selector, context);
};

Under its skin, the jQuery function (commonly referred to as the "wrapper" function) simply returns an instantiated jQuery object — i.e. an instance of the 'jQuery.fn.init' constructor.

This is useful to know; with this information we know that each time we call 'jQuery' we're actually creating a totally unique object with a set of properties. jQuery is clever in that it gives you an object that can be treated as an array. Each of your elements (all together, commonly known as the "collection") is referenced within the object under a numerical index, just like within an array. And jQuery also gives this object a 'length' property, just as you would expect from an array. This opens up a world of possibilities. For one, it means that we can borrow some functionality from 'Array.prototype'. jQuery's 'slice' method is a good example of this — modified from the source:

/* ... jQuery.fn.extend({ ... */
slice: function() {
    return this.pushStack(
        Array.prototype.slice.apply( this, arguments ),
        "slice",
        Array.prototype.slice.call(arguments).join(",")
    );
},
/* ... */

The native 'slice' method doesn't care that 'this' is not a real array– it'll be fine with anything that's got a 'length' property and [0], [1], [2] etc.

There are some other interesting properties within this jQuery object — '.selector' and '.context' will, most of the time, reflect the arguments that you pass into 'jQuery(…)'.

var jqObject = jQuery('a');
jqObject.selector; // => "a"

One thing that's important to note is that jQuery will sometimes give you new jQuery objects to work with. If you run a method that changes the collection in some way, such as '.parents()', then jQuery won't modify the current object; it'll simply pass you a brand new one:

var originalObject = jQuery('a');
var anotherObject = originalObject.parents();

originalObject === anotherObject; // => false

All methods that appear to mutate the collection in some way return a brand new jQuery object — you can still access the old object though, via '.end()', or more verbosely, via '.prevObject'.

2. Bread-and-butter Element Creation

Central to jQuery's DOM capabilities, is its element creation syntax. 1.4 brought with it an entirely new way to create your elements quickly and succinctly. E.g.

var myDiv = jQuery('<div/>', {
    id: 'my-new-element',
    class: 'foo',
    css: {
        color: 'red',
        backgrondColor: '#FFF',
        border: '1px solid #CCC'
    },
    click: function() {
        alert('Clicked!');
    },
    html: jQuery('<a/>', {
        href: '#',
        click: function() {
            // do something
            return false;
        }
    })
});

As of 1.4 you can pass a second argument to the jQuery function when you're creating an element — the object you pass will, for the most part, act as if you were passing it to '.attr(…)'. However, jQuery will map some of the properties to its own methods, for example, the 'click' property maps to jQuery's 'click' method (which binds an event handler for the 'click' event) and 'css' maps to jQuery's 'css' method etc.

To check out what properties map to jQuery's methods, open your console and type 'jQuery.attrFn'.

3. Serialize your Inputs

jQuery provides a method that you can use to serialize all of the inputs within one or more forms. This is useful when submitting data via XHR ("Ajax"). It's been in jQuery for a long time but it's not often talked about and so many developers don't realise it's there. Submitting an entire form via Ajax, using jQuery, couldn't be simpler:

var myForm = $('#my-form');
jQuery.post('submit.php', myForm.serialize(), function(){
    alert('Data has been sent!');
});

jQuery also provides the 'serializeArray' method, which is designed to be used with multiple forms, and the 'param' helper function (under the jQuery namespace) which takes a regular object and returns a query string, e.g.

var data = {
    name: 'Joe',
    age: 44,
    profession: 'Web Developer'
};

jQuery.param(data); // => "name=Joe&age=44&profession=Web+Developer"

4. Animate Anything

jQuery's 'animate' method is probably the most flexible of jQuery's methods. It can be used to animate pretty much anything, not just CSS properties, and not just DOM elements. This is how you would normally use 'animate':

jQuery('#box').animate({
    left: 300,
    top: 300
});

When you specify a property to animate (e.g. 'top') jQuery checks to see if you're animating something with a style property ('element.style'), and it checks if the specified property ('top') is defined under 'style' — if it's not then jQuery simply updates 'top' on the element itself. Here's an example:

jQuery('#box').animate({
    top: 123,
    foo: 456
});

'top' is a valid CSS property, so jQuery will update 'element.style.top', but 'foo' is not a valid CSS property, so jQuery will simply update 'element.foo'.

We can use this to our advantage. Let's say, for example, that you want to animate a square on a canvas. First let's define a simple constructor and a 'draw' method that'll be called on every step of the animation:

function Square(cnvs, width, height, color) {

    this.x = 0;
    this.y = 0;
    this.width = width;
    this.height = height;
    this.color = color;

    this.cHeight = cnvs.height;
    this.cWidth = cnvs.width;
    this.cntxt = cnvs.getContext('2d');

}

Square.prototype.draw = function() {

    this.cntxt.clearRect(0, 0, this.cWidth, this.cHeight);
    this.cntxt.fillStyle = this.color;
    this.cntxt.fillRect(this.x, this.y, this.width, this.height);

};

We've created our 'Square' constructor, and one of its methods. Creating a canvas and then animating it couldn't be simpler:

// Create a <canvas/> element
var canvas = $('<canvas/>').appendTo('body')[0];
canvas.height = 400;
canvas.width = 600;

// Instantiate Square
var square = new Square(canvas, 70, 70, 'rgb(255,0,0)');

jQuery(square).animate({
    x: 300,
    y: 200
}, {
    // 'draw' should be called on every step
    // of the animation:
    step: jQuery.proxy(square, 'draw'),
    duration: 1000
});

This is a very simple effect, but it does clearly demonstrate the possibilities. You can see it in action here: http://jsbin.com/ocida (this will only work in browsers that support the HTML5 canvas)

5. jQuery.ajax Returns the XHR Object

jQuery's Ajax utility functions ('jQuery.ajax', 'jQuery.get', 'jQuery.post') all return an 'XMLHttpRequest' object which you can use to perform subsequent operations on any request. For example:

var curRequest;

jQuery('button.makeRequest').click(function(){
    curRequest = jQuery.get('foo.php', function(response){
        alert('Data: ' + response.responseText);
    });
});

jQuery('button.cancelRequest').click(function(){
    if (curRequest) {
        curRequest.abort(); // abort() is a method of XMLHttpRequest
    }
});

Here we're making a request whenever the 'makeRequest' button is clicked — and we're cancelling the active request if the user clicks the 'cancelRequest' button.

Another potential usage is for synchronous requests:

var myRequest = jQuery.ajax({
    url: 'foo.txt',
    async: false
});

console.log(myRequest.responseText);

Read more about the 'XMLHttpRequest' object and also be sure to check out jQuery's Ajax utilities.

6. Custom Queues

jQuery has a built-in queuing mechanism that's used by all of its animation methods (all of which use 'animate()' really). This queuing can be illustrated easily with a simple animation:

jQuery('a').hover(function(){
    jQuery(this).animate({paddingLeft:'+=15px'});
}, function(){
    jQuery(this).animate({paddingLeft:'-=15px'});
});

Quickly hovering over a bunch of anchors and then hovering over them again will cause the animations to queue up and occur one at a time — I'm sure many of you have witnessed this queuing effect before. If not, check it out here: http://jsbin.com/aqaku

The 'queue' method is similar to the well-known 'each' method in how it's called. You pass a function, which will eventually be called for each of the elements in the collection:

jQuery('a').queue(function(){
    jQuery(this).addClass('all-done').dequeue();
});

Passing just a function to 'queue' will cause that function to be added to the default 'fx' queue, i.e. the queue used by all animations done by jQuery. Therefore, this function will not be called until all current animations occurring on each element in the collection (in this case, all anchors) have completed.

Notice that we're adding a class of 'all-done' in the function above. As outlined, this class will only be added when all current animations are complete. We're also calling the 'dequeue' method. This is very important, as it will allow jQuery to continue with the queue (i.e. it lets jQuery know that you're finished with whatever you're doing). jQuery 1.4 provides another way of continuing the queue; instead of calling 'dequeue', simply call the first argument passed to your function:

jQuery('a').queue(function(nextItemInQueue){
    // Continue queue:
    nextItemInQueue();
});

This does exactly the same, although it's slightly more useful in that it can be called anywhere within your function, even within a mess of closures (that typically destroy the 'this' keyword). Of course, pre-jQuery-1.4 you could just save a reference to 'this', but that would get a bit tiresome.

To add a function to a custom queue, simply pass your custom queue's name as the first argument and the function as the second:

jQuery('a').queue('customQueueName', function(){
    // Do stuff
    jQuery(this).dequeue('customQueueName');
});

Notice that, since we're not using the default 'fx' queue, we also have to pass our queue's name to the 'dequeue' method, in order to allow jQuery to continue with our custom queue.

Read more about 'queue', 'dequeue' and 'jQuery.queue'.

7. Event Namespacing

jQuery provides a way for you to namespace events, which can be very useful when authoring plugins and third-party components. If needed, the user of your plugin can effectively disable your plugin by unbinding all event handlers that it's registered.

To add a namespace when registering an event handler, simply suffix the event name with a period and then your unique namespace (e.g. '.fooPlugin'):

jQuery.fn.foo = function() {

    this.bind('click.fooPlugin', function() {
        // do stuff
    });

    this.bind('mouseover.fooPlugin', function() {
        // do stuff
    });

    return this;
};

// Use the plugin:
jQuery('a').foo();

// Destroy its event handlers:
jQuery('a').unbind('.fooPlugin');

Passing just the namespace to 'unbind' will unbind all event handlers with that namespace.

Conclusion

So which ones did I miss? Any helpful features that you feel jQuery doesn’t document well enough? Let’s discuss in the comments!

[Austria] Platogo, the social games platform, has today released its Platogo Wrapper that enables casual games developers to easily integrate their games with Facebook by inserting a few lines of code.

Essentially, it lets any casual game take advantages of the basic social features offered through Facebook, such as the ability for a user to invite and play with friends in their social graph and see how their scores compare, challenge each other, and display their gaming achievements on their Facebook wall.

The idea was to offer a solution that “automatically transforms any casual game into a social gaming experience.” says Florian Landerl, Product Manager at Platogo. That ’social gaming experience’ on Facebook, of course, also means a casual game has the basis to go viral.

Also important from a developer’s point of view, the actual Facebook app created is owned by them and not Platogo. And so is the relationship with users who can become fans so that developers can keep them updated using Facebook’s built-in communication channels.

Platogo says that its solution also removes the headache of keeping up with Facebook’s endless policy changes. If the social network changes its app rules, Platogo will adapt its wrapper leaving developers to concentrate on making games.

As well as a comprehensive API so that, should they wish, develops can add further Platogo-enabled social features, the company offers its own virtual currency for use within games. Called ‘Platogo Coins’ it enables developers to earn money by selling in-game virtual goods and is, presumably, how Platogo will make money too along with a share of ad-revenue.

In a response to my article here, DeWitt Clinton of Google defined what he deemed the definition of “open” to be.  According to DeWitt, “the first is licensing of the protocols themselves, with respect to who can legally implement them and/or who can legally fork them.”  I argue if this were the case, then why didn’t Google clone and standardize what Facebook is doing, where many, many more developers are already integrating and writing code for?  Facebook itself is part of the Open Web Foundation, and applies the same principles as Google to allowing others to clone the APIs they provide to developers.

DeWitt’s second definition of “open” revolves around, according to DeWitt, “the license by which the data itself is made available. (The Terms and Conditions, so to speak.) The formal definitions are less well established here (thus far!), but it ultimately has to do with who owns the data and what proprietary rights over it are asserted.”  Even Facebook makes clear in its terms that you own your data, and they’re even working to build protocols to enable website owners to host and access this data on their own sites.  Why did Google have to write their own Social Graph API or access lesser-used protocols (such as FOAF or OpenID) when they could, in reality, be standardizing what millions (or more?) of other developers are already utilizing with Facebook Connect and the Facebook APIs to access friend data?  Google could easily duplicate the APIs Facebook has authored (even using the open source libraries Facebook provides for it), and have a full-fledged, “open” social network built from these APIs many developers are already building upon.  I would argue there are/were many more developers writing for Facebook than were developing under the open protocols and standards Google chose to adapt.  I’d like to see some stats if that is not the case.  Granted, even Facebook is giving way to Google to adopt some of these other “open” standards so developers have choice in this matter, even if they were one of the few adopting the other standards.

I still think Google is adopting these standards because it benefits Google, not the user or developer.  If Google wanted to benefit the majority of the audience of developers they would have cloned the already “open” Facebook APIs rather than adopt the much lesser-adopted other protocols they have chosen to go by.  This is a matter of competition, being the “hero”, and a brilliant marketing strategy.  Is Google evil for doing this?  Of course not.  Do I hate Google for this?  Only for the reason that I have to now adapt all the apps I write in Facebook to new “open” APIs Google is choosing to adopt.

IMO, if Google wanted to truly benefit the developer they would have chosen to clone the existing “open” APIs developers were already writing for.  This is a marketing play, plain and simple.  It may have started with geeks not wanting to get into the Facebook worlds, but management agreed because in the end, it benefits Google, not their competitors.  If you don’t think so, you should ask Dave Winer why Google is not implementing RSS or rssCloud instead of Atom and PSHB (I’m completely baffled by that one, too).

Image courtesy http://northerndoctor.com/2009/04/17/re-inventing-the-wheel/

Here’s our rundown of the week’s business and tech news. First, the most popular stories VentureBeat published in the last seven days:

In favor of software patents — Patents are getting a lot of criticism these days, but Fair Software’s Alain Reynaud argues that they are worth preserving, just a little flawed.

The first Web service that Amazon put up, years ago, was the ECommerce API that allowed API access to Amazon's product information. That API has gone through several name changes and is now called the Product Advertising API. Thousands of people have used this API to add data about products--and the opportunity to buy them--to their Web sites.

That's the problem, of course. You can use it on your Web site, but you can't conveniently use them in a browser extension to build client-side community apps because your Amazon developer keys would be exposed to the world. The most recent build of KRL changes that by making the Amazon Product Advertising API (PAA) available as a library. That means that it's possible to use Kynetx to build client-side applications that use the PAA without exposing your developer tokens. That opens up a whole host of possible uses for Amazon product information that were difficult to achieve before.

Here's a video that shows this at work:

Of course, to create client-side applications that people will install and use requires more than just pumping more product at them. The KRL integration of PAA includes the ability to access all the user-generated reviews, product information, photos, and other product data that would allow a developer to create a first-rate experience that adds real value for people who download and use their apps.

KRL makes using PAA easy. To get started, you simple put your Amazon developer secrets and associate ID in the meta block of your application:

meta {
  key amazon {
    "token"        : "absjj99a9ad9ad8799",
    "secret_key"   : "absjj99a9ad9ad87799absjj99a9ad9ad8799",
    "associate_id" :  "windleyofente-20"
  }
}

These are stored securely in the cloud and not divulged to users of the application.

The KRL Amazon library has two primary methods: ItemSearch and ItemLookup. With ItemSearch the search index is a parameter and additional parameters depend on the particular index. ItemLookup takes an Amazon product ID (ASIN) as it's primary parameter. Here's an example:

amazon:item_lookup({"ItemId" : "B00008OE6I",
                "response_group" : "ItemIds" })

The response is returned as JSON so that you can use JSONPath to pick it apart and use it. Here's a piece of the response to the previous query:

"Item" : {
            "OfferSummary" : {
               "LowestUsedPrice" : {
                  "Amount" : "3999",
                  "CurrencyCode" : "USD",
                  "FormattedPrice" : "$39.99"
               },
               "TotalRefurbished" : {},
               "TotalUsed" : "8",
               "TotalCollectible" : {},
               "TotalNew" : {}
            },
            "ASIN" : "B00008OE6I"
         }

Here's a video showing a little more about how this is done and giving a working example.

You can install the example that we used for the first video or just view the source code using the app detail page in the Apps Directory.
Here's the documentation for the Amazon library.

The Amazon integration with KRL allows Amazon developers to build client-side application that use Amazon product data without exposing the Amazon developer credentials--something that's been hard in the past. KRL is designed to make using online data like Amazon or Twitter easy and quick. We'll be annnouncing some other major data and service integrations over the next few weeks as we gear up for Kynetx Impact in April. Come join us.

It’s a SuperTweet, SuperTweet…: new API will allow third-party apps to beef up tweets with contextual data http://bit.ly/bUVfkm

Microsoft’s (rumored) tablet: just over 1 lb., and around 5″x7″x1″ when closed (it folds). Also comes with…a stylus. http://bit.ly/aO4DqS

What will be the fate of books in a post-print age? http://bit.ly/97dtH7 (via @niemanstory)

Using eye-tracking metrics, a survey concludes that the majority of users are “indifferent” to real-time search results http://bit.ly/cWLmJa

Location-as-platform, cont’d: Google Chrome now supports geotargeting http://bit.ly/9bp8pz

People love their mobile phones because they can stay in touch wherever they are. That means not just talking, but e-mailing, texting, microblogging, and so on. So, in addition to search by voice and voice shortcuts like "Navigate to", we included a voice-enabled keyboard in Android 2.1, which makes it even easier to stay connected. Now you can dictate your message instead of typing it. Just tap the new microphone button on the keyboard, and you can speak just about anywhere you would normally type.

We believe speech can fundamentally change the mobile experience. We would like to invite every Android application developer to consider integrating speech input capabilities via the Android SDK. One of my favorite apps in the Market that integrates speech input is Handcent SMS, because you can dictate a reply to any SMS with a quick tap on the SMS popup window.

Speech input integrated into Handcent SMS

The Android SDK makes it easy to integrate speech input directly into your own application—just copy and paste from this sample application to get started. Android is an open platform, so your application can potentially make use of any speech recognition service on the device that's registered to receive a RecognizerIntent. Google's Voice Search application, which is pre-installed on many Android devices, responds to a RecognizerIntent by displaying the "Speak now" dialog and streaming audio to Google's servers—the same servers used when a user taps the microphone button on the search widget or the voice-enabled keyboard. (You can check if Voice Search is installed in Settings ➝ Applications ➝ Manage applications.)

One important tip: for speech input to be as accurate as possible, it's helpful to have an idea of what words are likely to be spoken. While a message like "Mom, I'm writing you this message with my voice!" might be appropriate for an email or SMS message, you're probably more likely to say something like "weather in Mountain View" if you're using Google Search. You can make sure your users have the best experience possible by requesting the appropriate language model: "free_form" for dictation, or "web_search" for shorter, search-like phrases. We developed the "free form" model to improve dictation accuracy for the voice keyboard on the Nexus One, while the "web search" model is used when users want to search by voice.

Google's servers currently support English, Mandarin Chinese, and Japanese. The web search model is available in all three languages, while free-form has primarily been optimized for English. As we work hard to support more models in more languages, and to improve the accuracy of the speech recognition technology we use in our products, Android developers who integrate speech capabilities directly into their applications can reap the benefits as well.

I work for a very large company and at some point or another someone started a Yammer account based on our email domain. Starting on whatever day that was, Yammer commenced its viral expansion and its spread has really been quite impressive and rapid. Last time I looked we were approaching 3000 users.

The usage demonstrates all the free-scaling behaviors you'd expect though, so not everyone is yammering away. Still both the growth and the impact have been impressive. We are developing a nice network of the kind of weak connections that tend to "small world" a big enterprise like ours. It's always difficult to quantify the benefits of "soft" collaboration but I'm really happy with what I see and I've personally enjoyed the interactions and my expanded network.

I think Yammer has done so well because it's a really good product with well thought out features that make Twitter seem kinda retro. It has a nice slick interface, threaded conversations, and no pesky 140 char limit (which is countered by a "return key = submit" that inhibits multi-paragraph posts). They are also working to create the kinds of features that enterprises need to feel comfy: an api that includes directory integration, an Outlook module and etc.

However, despite all that, I'm bummed to say I don't think they are going to make it.

The question of data privacy and ownership comes up over and over in our Yammer discussions. The last time it came up the thread ran for nearly 100 responses. Even though the typical post is something like "Who is using Grails?" or "Is the X application slow for everyone today or just for me?" data privacy is simply one of the biggest concerns going for a lot of companies these days. The mere suggestion that our data isn't under our control is a big deal.

This point was demonstrated to me in a personal and compelling way during my first week on Yammer. I mentioned a client meeting so that I could share a few tidbits with colleagues. Hours later I was surprised and dismayed when a Google search revealed that my comments had been re-posted to the friendfeed of someone I didn't even know. Someone on our network had written a quick and dirty app to follow his Yammer RSS feed and re-post everything to friendfeed. Then for good measure he followed everyone in our network. When I "politely suggested" he take it down he equally politely explained to me that I just didn't get Web 2.0.

Despite that kind of hiccup, I don't think data privacy is the death knell. After all, no one has told us to stop using it yet. The real problem is that Yammer thinks viral works the same way in the enterprise that it works on the web. It doesn't.

Yammer, by being free and viral, is demonstrating in that soft benefit kind of way to lots of enterprises like ours that networks of weak connections and "ambient collaboration" are useful. Usage is creating a pool of users and even executives that "get it." But they are playing their cards too early and are probably going end up as little more than a contribution to someone else's cost of sales.

Recently a thread started with "does anyone know how to remove people from Yammer that left the company?" Well, it turns out that's an admin function and only available to paying customers.

While we have grown rapidly and virally, the "admin issue" is coming to a head with only about 1% of the company holding an account and probably more like .1% actively posting. There is no way this is going to be a level of usage that an enterprise like ours sees as lock-in. And it won't for anyone else's either.

If the average company has an attrition rate of 10% it means that EVERY company that adopts Yammer virally is going to start to have this conversation well before adoption has locked them in. Every company will face the problem of removing ex-employees by the time they reach relatively low penetration rates. If it's a 25 person shop it may be easier to just pay the $3/employee per month than worry about it, but for any reasonably sized enterprise this is going to force an off-budget-cycle decision that involves real dollars before adoption has locked them in.

The other problem with viral adoption as a strategy is this: I may love using Yammer, but I'm not Yammer's customer, our IT department is. And they already have SharePoint. What Yammer doesn't understand, and what Microsoft has known for years, is that IT makes these decisions, not the users.

While Yammer is going viral with users out at the edge, Microsoft perfected its S1P1 virus to attack the very core of the IT enterprise. So, when it comes to enterprise microblogging, The Microsoft Office SharePoint Server (MOSS) and its various add ons may be mediocrity in code form, but it's already there. And being there counts.

The latest developer release of Google Chrome 5 that was released a few hours ago introduces a geolocation feature to the web browser. Google Chrome 5 version 5.0.342.1 and later now include an early version of the geolocation api which can be enabled by starting the web browser with the –enable-geolocation startup parameter.

Geolocation has been added to make use of the user’s location when providing services to the user. This feature can be integrated into websites and extensions.

The user’s privacy is guaranteed since a confirmation prompt is displayed whenever a service tries to access the geolocation feature to detect the user’s location.

The geolocation feature is for instance used in Google Maps to locate the user on the world map and it is likely that new applications will eventually be released that make use of this feature.

Internet users who want to test the new geolocation feature need to download the latest version of the Google Chrome dev release to do so and start the browser with the parameter mentioned above.

It should also be noted that permissions are not persistent and that wifi based location is currently only supported on Windows and Mac (but not OSX 10.6).

Omoby can essentially be summed up in four words: Google Goggles for iPhone. The visual search app allows you to snap a pic of any object and get back a list of convenient search results, retailer pricing, and information about that product.

The technology behind the app is visual object search, so it doesn’t require a barcode to be scanned, and can tolerate a fair amount of object rotation and general object obscurity in making an identification. In our tests oMoby fared better on some things than others: boxed media like video games or DVDs were easily identified while the Nexus One was rendered simply as “Google Android phone.”

Still, it’s a nice quick and dirty way to pull up information or do comparative shopping for a wide range of objects. The app saves a history of your visual searches too so you can reference them later. Hooking in your Twitter or Facebook allows you to share results with your friends; sharing via email is an option as well. The app is powered by IQ Engines visual search technology, which also offers an API for developers who want to incorporate image intelligence into their own apps.

So if you’re an iPhone user who has been jealous of your Android counterparts’ access to visual search, oMoby is definitely worth a look at the low, low price of free in the App Store [iTunes link]. We’ve embedded a demo video below of the app in action; if you get a chance to watch the video or try out the app, let us know what you think in the comments.

Tags: google goggles, iphone, iphone apps, IQ engines, Mobile 2.0, object search, omoby, product search, Search, visual search

What happens when you combine the social networking power of Twitter with the usefulness of Google Maps? The result can be some pretty cool and intriguing applications.

The idea of a mashup in Web development is to simply take the data and functionality of different sources and combine them together to make a new service. With Twitter and Google Maps mashups here, it’s all about taking advantage of both the Google Maps and Twitter API to create a mashup that’s unique, practical, and fun.

Let’s get right to it and find out what all the fuss is about. Here’s 3 cool Twitter and Google Maps mashups you should check out.

Trendsmap

Trendsmap is a tool to visualize the top Twitter trends throughout the world. Simply put, it’s about what people are talking about right now and where they are. Just browse the globe for all the current hot discussions in any region of the world.

If you come across a topic that you’d like to explore further, just click on it for more information. Two small graphs of both the local and global history of that particular trend are displayed on top, along with details about why the topic is a big news story. Below that are links to any videos and news articles, followed by the most recent tweets about the topic continuously updated in real-time.

Feel free to explore the current Twitter trends in your region or city as well. Just zoom in on the map or type in your location for more of a local level perspective.

GeoChirp

Ever wonder what people in your neighborhood are tweeting about? GeoChirp allows you to easily find out with its mashup. Start by selecting a search radius anywhere on the Google map by simply clicking an area.

The latest tweets from that region will be displayed at the bottom of the map. You can then use the site’s filter to specify a keyword, the number of tweets displayed, and the search radius (between 1 and 50 miles).

Keep in mind that the search results aren’t updated automatically, so be sure to hit the refresh button for the latest tweets.

Twittervision

Twittervision is an interesting way to view tweets from all across the world. Once on the website, you don’t have to do anything but watch aimlessly as you sweep across the globe for real-time Twitter updates.

It pauses to display a popup of the actual tweet from where it was sent, along with the Twitter user and location. After that, it just moves on to the next tweet. There’s not much in terms of customization, but it’s still a lot of fun.

If you get bored with that, give the website’s 3D mode a whirl. It’s the same concept, but this time it uses a three-dimensional globe from Poly9, not Google Maps. Twittervision is also available as an iPhone app.

Can’t get enough of these? Be sure to check out 9 Awesome & Useful Google Maps Mashups for more.

Do you have any favorite Twitter and Google Maps mashups? Let us know in the comments.

em>Got Tech Questions? Ask Them on MakeUseOf Answers!

• (13)View Your Firefox & Twitter Histories on A Timeline With Voyage
• (2)Two Geeky Methods To Do Some Quick Tweeting [Mac]
• (11)Twitter On Your Windows Mobile Phone With Twikini
• (24)Twitter Clients – Web Apps or Desktops Apps? Which is Better?
• (17)Twitip.com – Solid Twitter Tips To Help You Get Started

Originally posted at The Download Blog

Shared by Bamboozled
Woohoo! Many more features too.

I'm honored to be the one who gets to announce the release of StatusNet 0.9.0. This is the latest version of our software, and represents almost 8 months of hard work by the StatusNet developer community. It's available for immediate download from the status.net site.
This release includes the following new features:
 

• Support for the new distributed status update standard OStatus, based on PubSubHubbub, Salmon, Webfinger, and Activity Streams.
• Support for location using the Geolocation API. Notices are (optionally) marked with lat-long information with geo microformats, and can be shown on a map.

Google just launched the latest developer version of Chrome, which now includes preliminary support for Google's geolocation API. Google's Geolocation API allows developers to pinpoint your computer's location by looking at the WiFi networks around you, similar to SkyHook's technology that is part of Apple's OSX and iPhone OS. For now, this new feature is still hidden behind a command line toggle and only available in the developer builds for Windows and OSX Leopard (it doesn't work on Snow Leopard yet).

Sponsor

To enable these built-in geolocation features, you have to run the browser with "--enable-geolocation." It's typical for Google to first hide these features behind a command line toggle before exposing them to a wider group of testers. The Chrome team also notes that the geolocation UI is still incomplete and that Chrome will forget the permissions you set.

Preparing for Chrome OS?

It makes sense for Google to enable geolocation for Chrome, especially given the impending release of the Chrome OS, which will also benefit from these new features. Mozilla already offers a built-in location API for Firefox and with Geosense for Windows, Windows 7 developers can now also make use of Google's Geolocation API in their native apps.

Location for Every Browser

Thanks to the current efforts by most browser developers, location APIs will soon become ubiquitous and hopefully more developers will make use of them. While a number of mobile apps for the iPhone, for example, now make use of the location feature in the mobile version of Safari, only a small number of browser-based apps are currently aware of your location. While using WiFi location isn't quite as precise as using a GPS, the precision is usually much better than relying on a user's IP address.

Cult of Mac reports that Apple has begun removing apps from the iTunes App Store that scan for Wi-Fi access points. It looks like these apps are being removed due to their use of private APIs, which is prohibited by the iPhone SDK agreement. This would make it similar to the recent removal of apps that misused the iPhone camera DCIM folder to store and exchange documents.

There’s been some suggestion, however, that list reflects a policy change from Apple closer to the recent removal of sex-based apps.

Our speculation is that Apple has either added the Wi-Fi private APIs to their static analysis tool, or has just finally gotten around to checking for them. That would make it appear like a new policy when it’s actually the originally agreement finally being enforced.

Some developers believe long term lack of action by Apple equals tacit approval for private API use. Those beliefs likely have to start changing. When Apple makes an API public, they’re guaranteeing that developers can use them and have faith Apple won’t break them (and the apps built on them) in a future update. Private APIs are the opposite — Apple can and will change them at any point, breaking apps that try to use them when they shouldn’t. In some cases Apple is working on public versions of private APIs and will release them in future versions of the iPhone OS. In other cases they aren’t — sometimes for security, other times just for proprietary reasons.

In either case, this isn’t the first and likely won’t be last set of rejections. While we feel for developers, we feel more for users who may have come to depend on the functionality of these apps.

If you’re a developer who’s dealing with this and have a better take on the situation, please let us know!

[Thanks to everyone who sent this in!]

Apple Removing Wi-Fi Scanning Apps from App Store is a story by TiPb. This feed is sponsored by The iPhone Blog Store.

TiPb - The #1 iPhone, iPad, and iPod touch Blog

Once the mouthpiece and aggregator of the blogosphere, Technorati lost its luster long ago. And now it’s lost its API, too. The developer page promises a new API but also makes one thing clear: the old one is gone.

Developers like Yancy Lent want Technorati to know they’re waiting:

This is pretty amazing. The services has been down for just over 4 months with no new API to take its place. It’s almost as if it was abandon. This is a real shame, not even an update.

Bloggers used to dutifully add Technorati tags to posts. When your rank changed, it was worth a blog post, even to say you didn’t care. Thousands of bloggers included a widget in their sidebar that used Technorati’s API to say how much the blog was worth.

Technorati founder David Sifry left in 2007. Now his personal blog features a Technorati widget that returns a 404:

With its future unclear (or, perhaps, painfully clear), we’ve marked our Technorati API profile as ‘deadpool’.