An app downloaded from Google Play may not modify, replace or update its own APK binary code using any method other than Google Play’s update mechanism.

Surely this new policy won’t affect any major apps, right? Actually, Facebook introduced a self-updating mechanism in its Android app recently that bypasses Google Play entirely. With this new policy, Facebook will now have to go back to manual updates via Google Play.

Of course, this isn’t a case of Google picking on Facebook. Google says that its Play store is “trusted source for Android application downloads” and that it is “committed to providing a secure and consistent experience.” Allowing apps to update themselves could possibly lead to some less-than-secure scenarios as the initial download from Google Play would be safe while the in-app updater installs malware.

It should be noted that these new policies only affect apps available on Google Play. Former Google Play apps, like Adblock Plus, are completely free to use in-app updates.

[h/t: Gizmodo]

Comments

Other tips include staying out of the user’s way (it will be interesting to see if Facebook Home makes its way to Glass) and “avoiding the unexpected”.

He shares something they’ve been working on with the New York Times, which shows headlines over top of photos (actually not unlike status updates on Facebook Home), and lets you click to have the article read aloud.

He also shares an email exchange and a look at Evernote and Skitch.

Give it a watch:

Comments

Simplified the request looked something like this:


$.ajax({
url: "/invoices/" + invoiceid + "/pay",
type: "GET"
})


However Rails was returning a ’406 Not Acceptable’ error, suggesting the request I was sending was not something it was instructed to handle.

In my noobness I tried passing


dataType: "json",


I also tried


contentType: "json"


but always got this error:

In the end the fix was quite simple but had evaded me for a while:


beforeSend: setHeader


followed by


function setHeader(xhr) {
xhr.setRequestHeader("Accept", "application/json");
}


The complete function looked (simplified) like this:


$.ajax({
url: "/invoices/" + invoiceid + "/pay",
type: "GET",
beforeSend: setHeader
}).done(function() {
...
});

function setHeader(xhr) {
xhr.setRequestHeader("Accept", "application/json");
}


Once implemented the GET request succeeded (notice the Accept Request Header).

Hopefully this saves someone some grief. Loading JSON from Rails seems well documented, and so ar 406 errors, but I had trouble finding the fix in this case because I wasn’t 100% sure the issue was on the jQuery side…

Comments

Focusing in on domain name and URL structure, there are several key areas that any business owner will be wise to pay attention to while having a new website developed.

Choosing Your Domain Name

If you’re just starting a new business, before you even select your new business name, you first want to make sure the domain name is available. Unfortunately, this may mean having a few (or perhaps hundreds of) backup name options in case the URL for the name you want isn’t available.

There are things to pay attention to when you are choosing the URL for your website.

• Don’t use hyphens in your domain name
• Don’t build a site on another platform that controls the domain name (get your own)
• Don’t make your domain name too long or wordy
• Use a key word in the domain name if possible
• Be descriptive and compelling
• Be memorable

Purchasing Alternate Domain Names

Once you’ve secured your domain name it’s a good idea to secure some alternate versions. This is akin to protecting your brand. The last thing you want is some other company purchasing a domain name similar to yours as a means to capitalize off the brand equity you’ve been building over the years.

Here are some alternate domain options to consider:

• Abbreviated versions: Think of ways to abbreviate your domain name and secure those domain names. Shorten words into a few letters, use the domain name initials, or a combo of both. (i.e. BFM.com, BisB.com, etc.).
• Hyphenated versions: For ultimate brand protection, you can buy domain names with a hyphen between the words. Many businesses have similar (or the same) name and if the hyphenated version is available, they’ll buy it. This created direct competition to your brand.
• Alternate & Misspellings:An interesting thing about my company is that no matter how many times we tell people, they still get the name wrong. We’re called Pole Marketing, Pole Positioning, and even Pole Positioning Marketing. And that doesn’t even touch the alternate ways to spell “pole” (pull, pul, pool). Grabbing alternate name spellings and even misspellings can help you hold on to your brand name, but also capture traffic from those who type your domain name incorrectly. Which happens a lot.
• Brand Names: If you sell a product with brand names, it can be wise to buy up product/brand domain names. This is especially true if you’re building your own product brand name. As these become household names, you want to be sure to capture traffic from people looking for that.
• Alternate TLD: There are a lot of TLDs available (top level domain; i.e. .com, .net, .org, etc.). Buying them all up for your domain can be cumbersome and expensive. But there are some cases where you might want to secure these, especially if you do business in other countries. Buying up these TLDs before someone else does can ensure you own your brand in that country.

Once you have all these domain names secured, you’ll want to implement a 301 redirect for each. This redirect will take your visitors from the alternate domain to your main site. Getting this redirect right is important. Other methods of redirecting, such as domain parking, 302 redirect, etc. can be lead to some potentially serious problems later.

Fix Canonical Issues

Every website comes pre-built with duplicate content. I addressed these issues in detail in The Complete Guide to Mastering Duplicate Content Issues. Without getting into too much duplication here (yes, that pun was intended), I’ll briefly discuss one of the universal duplicate content issues.

Every website home page can be accessed by six different URLs:

• www.site.com
• site.com
• www.site.com/
• site.com/
• www.site.com/index.html (or .php, .asp, etc.)
• site.com/index.html (or .php, .asp, etc.)

While each of these URL will get the visitor to the same information, each URL can be indexed separately causing duplicate content in the search index. Eventually the search engines get around to figuring out that these are not duplicate pages, but until then you’re basically working against yourself. And even once they do, there is no guarantee that you’ll get 100% of all link value associated with any of these versions.

Using server side redirects is the best solution to ensure that whenever any of these URLs are entered they all lead back to the one you choose. Talk to your web host to find the best server side solution for these redirects. The next best solution is to add a canonical tag to your home page code. It looks like this:

<link rel="canonical" href="http://www.site.com"/>

This tag tells the search engines that www.site.com is the correct version for their index and link metrics.

Keeping Your Home Page at the Root Level

Many times websites are built with the home page somewhere other than at the root level. An example of this was a site I had been to years ago called YourMusic.com. When you typed in www.yourmusic.com you were redirected to www.yourmusic.com/home/.

Having this improper URL structure they were setting themselves up for disaster, if not failure, if and when they ever changed the URL for the home page. While the redirect from yourmusic.com was redirecting properly, any change would have forced an additional redirect from yourmusic.com/home to it’s new location. This can cause a host of issues, not the least of which are lost rankings and loss of link value through any new redirect.

Be sure to keep your home page accessible at the root level, and redirect all visitors to that URL. Always.

Building Search Engine Friendly URLs

With your URL and domain names secure, it’s time to focus on the URLs of pages other than your home page. Many systems use long and complicated URL structures that you couldn’t type correctly if it was being dictated to you letter for letter. This isn’t what you want. The best URLs use a combination of keywords, good structure, and brevity.

URLs should be structured similarly to how visitors navigate your site. If your site is divided into several categories and sub-categories, these should be used as URL folders and sub-folders. For example:

www.site.com/category/sub-category/page-name.html

Using categories in your URL structure helps you utilize keywords in your URL, which can prove somewhat valuable to your search optimization efforts. It also gives the visitor context to what they page might be about before they even visit.

www.site.com/perfume/chanel/alure.html

In the example above you know that “Alure” refers to the name of a perfume by Chanel. Clearly this page is all about the Chanel perfume Allure. These are great visual cues to web searchers when they are scrolling through search results looking for a page that is most relevant to their search query.

Hyphens, Not Underscores in URLs

When creating URLs with multiple words, it’s best to use hyphens rather than underscores. For the most part, search engines treat them the same, however there have been some issues with them in the past. But from a usability perspective, in some situations underscores can be hard to differentiate from spaces.

If a URL is presented as a link, you want the viewer to know exactly how to type that URL into the browser bar. Any miscommunication here can lead the visitor to someplace other than where you intended.

Establish a Proper URL Hierarchy

Over all, you want to have a strong URL hierarchy that isn’t too shallow or too deep. Like Goldilocks, you want it to be “just right.”

Flat URL Hierarchy

If your hierarchy is too flat you run the risk of having all pages being deemed as equal. We often set up our navigation to draw our visitors through categories and sub-categories, and we should set up our URLs in much the same fashion. When “every” page of your site is essentially on the same level the search engines have difficulty telling which pages should be grouped together topically, and how to give proper weight to pages that are higher up navigationally.

Deep URL Hierarchy

The opposite of a flat hierarchy is one that is too deep. Instead of causing pages to appear to be of the same value, a deep architecture causes pages to have a far lesser value than they need in order to perform in search engine rankings. A deep architecture essentially devalues the pages at the bottom to the point of being almost worthless. Or at least, considered worthless to the search engine.

Perfect URL Hierarchy

The perfect URL hierarchy is one that isn’t too shallow nor too deep. It’s “just right.” You want each page on your site to be found within just three or four clicks. There are exceptions to this, depending on the size of the site, but most sites can be structured so any page isn’t too far removed from the home page. This is both in terms of clicks and the directories in the URL itself. Using proper URL directories allows you to get your keywords in place in the URL and keep a relatively shallow URL structure.

Putting all these URL tips into practice will give you an effective search engine friendly architectural structure that also helps your visitors navigate, find or understand your site. You’re serving two masters, but good URL practices serves them both.

Comments

You can check it out in action below:

RTCPeerConnection is currently available on the Chrome 25 beta and the latest build of Firefox Nightly. Once you download one of those, set the media.peerconnection.enabled to true in about:config and you’ll be set.

For the developers out there, Mozilla has a lengthy tutorial on how to bring RTCPeerConnection to your apps at its blog post. Check it out to get all the details.

Comments

Commnets

In addition to providing better localized experiences for your customers, we want to make it easier for you to measure your audience in each country as well as benchmark your brand against other brands you care about. Later this year we will include the country-level fan counts for all Pages (both those using the Global Pages framework as well as Pages that haven’t transitioned to the new framework) publicly in our API. This will enable your internal teams to track how each market is performing, as well as to compare your fan base on a country-by-country level with other Pages on Facebook by accessing the data available via our API.

Now the feature is available in the API, and Facebook has some more information on the feature. For once, the metrics included in this first iteration are like count and PTAT (people talking about this). Facebook will take this information and allow brands to compare it to other brands to see which products are being talked about more on Facebook. To access this new information, just hit up the new ‘global_brand_like_count’ and ‘global_brand_talking_about_count’ fields on the Insights object.

As for the weekly bug report, 288 were reported and 37 were fixed. Facebook has also accepted 72 bugs for further review. You can check out the full list by hitting up the blog post.

Comments

The calendar in its current form splits up API announcements into two categories – recent change and upcoming changes. Both categories list the date the change was or will be deployed, a short description, a link to the original announcement and the APIs that will be affected by the change.

Twitter notes that the Timeline is not a replacement for its official blog or its API Twitter feed. Developers will still want to follow all the official sources for Twitter developer news. The calendar mainly serves as a reminder for the social network’s major announcements.

That being said, the calendar is a major source of transparency and convenience for Twitter developers. It doesn’t change the fact that version 1.1 of Twitter’s API screws over developers, but it’s a decent consolation prize.

Speaking of which, you have until March of next year to make the switch to version 1.1 of the API and all the regulations it brings.

Comments

Jetpack offers a huge range of features, services and functionality that enhances your WordPress experience – both yours as the content publisher and those who interact with your content.

With version 2, Jetpack currently brings nearly two dozen modules that you activate to use in your WordPress site.

Once you install the plugin, it created a dashboard in your WordPress admin through which you manage all aspects of it.

You will need an account at WordPress.com even if you don’t have or plan to have a blog there, as the plugin connects with data and services in the WordPress cloud. Opening an account is free of charge.

You use the Jetpack modules you want, which may not be all of them. I have some activated, not all; the ones I find very useful are these:

• Comments: enables your visitors to use WordPress.com, Twitter, or Facebook accounts when commenting on your site.
• Subscriptions: Allow users to subscribe to your posts and comments to receive a notification via email.
• Contact Form: Easily insert a contact form any where on your site.
• Sharing: The most super duper sharing tool on the interwebs. Share content with Facebook, Twitter, and many more.
• Shortcode Embeds: Easily embed videos and more from sites like YouTube, Vimeo, and SlideShare.
• WP.me Shortlinks: Enable WP.me-powered shortlinks for all of your Posts and Pages for easier sharing.
• Mobile Theme: Automatically optimize your site for mobile devices.
• Enhanced Distribution: Share your public posts and comments to search engines and other services in real-time.
• Custom CSS: Customize the appearance of your site using CSS but without modifying your theme.

I’ve dispensed with other plugins where Jetpack offers similar or better functionality. It’s definitely a core plugin that will give any self-hosted WordPress blog a boost.

Comments