Now that we've talked about what Apple has coming, let's talk about Android's 2011 phones. Tablets are mentioned in the end.
Thinner, Better, Faster
Android phones are already heavy on features. The bulk of the upgrades this year will be evolutionary. Processors will be faster with the release of the dual-core phones, like the Motorola Atrix. RAM will be increased; the Atrix and Samsung Galaxy S II have 1 gigabyte of RAM and it's reasonable to consider that 1GB will be standard by the end of 2011. Screens will hopefully begin to approach the extraordinary resolution of the iPhone 4's Retina Display. But even if they don't approach that excellent resolution, new Super AMOLED Plus screens (like the one in the Samsung Galaxy S II) are thinner, brighter and more efficient than the old SAMOLED screens (http://www.oled-info.com/super-amoled-plus). Some phones will get thinner. The Samsung Galaxy S II will be 8.5mm deep, a bit thinner than the iPhone 4's 9.3mm. Video recording resolution will be bumped up to 1080p, like the LG Optimus 2X. Cameras on the front and back will increase their megapixels.
The New Stuff
Front and Back Cameras: Is this worth mentioning? The Nexus S, a dream phone in most other ways didn't have this, so perhaps it's worth saying that almost all Android phones will have this.
4G: A no-brainer (though also lacking from the Nexus S). Pretty much all Android phones will have 4G (be it LTE, WiMAX, or HSPA+) in 2011.
Gorilla Glass: This ultra-tough glass featured in the Atrix and some other phones will make the screens difficult to break.
NFC: It's hard to say whether NFC will be successful in it's attempt to replace our credit cards as payment devices, but this hardware feature already on the Nexus S and coming to the Galaxy S II will most likely be seen on more Android phones in the future. And even if it isn't used for payments, it could become a handy way to transfer information to and from the phone. For example, you'll be able to pair bluetooth devices just by tapping them together.
DLNA: DLNA is a technology that allows you to stream media to your TV (or other devices) wirelessly, as long as both are on the same network. This means, in short, streaming videos and pictures from your phone to your TV. We're getting to an age where everything including your toaster is hooked up to your wireless router, so it's exciting to see this interconnectivity actually have a point. Several phones have this already (Droid X, Droid 2, HTC Thunderbolt), so the only reason many phones may not get this in 2011 is because of seemingly slow adoption by TV manufacturers.
Cheaper Price: iPhone's have a rigid pricing structure, and unless you take your chances with eBay, you're gonna pay $200 for the cheapest iPhone with a new contract. Not so with Android. Secondhand phone dealers, such as Amazon.com and Radio Shack, have been knocking down prices on Android phones recently. The Motorola Atrix is currently $200 from AT&T, but is $150 when you buy it from Amazon Wireless and $130 at Costco. The availability of brand new, hi-tech, and less expensive Android phones will be the death knell of the iPhone. When the iPhone 5 comes out this summer, every carrier will already have an Android phone that can do everything the new iPhone does, and for less money. The iPhone will start to become a niche phone.
Ice Cream: In late 2011, a new version of Android OS will be released. All signs point to it being a mix of the Gingerbread and Honeycomb versions of the OS. All I can gather from this is that the beauty of Honeycomb's UI will make its way to phones. It also might mean greater interactivity between Android phones and Android tablets. But, if history is any indication, most 2011 Android phones won't receive the update in 2011, if they get it at all.
Hopes
Webtop: The absolute coolest thing about the Motorola Atrix is its "webtop" app that allows you to see your phone on a larger screen (laptop or TV) without simply stretching the screen. Google would do well to build this functionality into its OS. Even if it was a simple screen-stretching video out function, I can think of many uses putting your phone on the big screen. Hopefully, Google will put something like this in Ice Cream, though I won't hold my breath.
Battery: With Android's already short battery life, more powerful processors will necessitate a larger battery. Instead of making the phones thinner, let's make them a bit thicker with larger batteries.
Higher Resolution Screens: SAMOLED looks great and SAMOLED Plus should look even better, but it's hard to top the crisp, clean look of the iPhone 4's 326 pixels-per-inch Retina Display. I want to see high-resolution screens on Android and the new big thing in Android screen technology--SAMOLED Plus--actually has a worse resolution per inch than SAMOLED (check the oled-info.com link above).
Wish List: What I Want
I am determined to get a new phone this year, after I see what the iPhone 5 has to offer. Most likely, I will go with Android. If I can find a 4G Android phone with 16GB internal storage, a pretty screen (SAMOLED Plus or something with a high pixel density), a way to show media on my TV (either DLNA or an HDMI port), and stock Android (or rootable so I can put stock Android on it), then I will buy it. The Atrix almost fits most of this description and it was hard not to go out and buy it. The locked (or rather, signed) bootloader helped me save my cash.
Tablets
Tablets will get these features, slowly. It's hard to say what will happen because the Motorola Xoom (the tablet I'd call the first real Android tablet) is yet to be released. But just like with the iPhone and iPad, new features will appear in the phones first, then trickle down to the tablets.
That's it for Android. If I have time, I'll write about WP7 and the other OSes.
Sunday, February 27, 2011
Monday, February 14, 2011
Speculation: iPad 2 and iPhone 5
It's already February and I haven't listed the specs for all the upcoming gadgets. My bad. I'll start with the Apple products.
The Obvious: Thinner, Better, Faster
As usual, the next iPad and iPhone will likely be faster due to upgraded RAM or an upgraded processor (likely dual-core) or both. The iPad 2 might be thinner, but the iPhone 5 probably won't because Apple already went through a major design change with the iPhone 4 after three phones with the same design. They aren't likely to change it up again (except to fix that pesky antenna problem). The next iPad will come out in April or May and the next iPhone will be released in June or July.
iPad
The next iPad should have a CDMA antenna so it can be available through Verizon. Verizon has already promised a Verizon iPad, although the iPad 2 wasn't specifically mentioned. The iPad will NOT have the rumored SD card slot if for no other reason than it would ruin Apple's tiered pricing for different amounts of storage. Front and back cameras are rumored. I definitely agree with the front-side camera because it would mean Facetime was available on one more device. AppleInsider says it might have a mini DisplayPort. A price drop is somewhat out of character for Apple, but it would help them compete with the cornucopia of Android tablets that will be release this year. A price drop on the more expensive models is more likely than a price change on their cheaper models.
CrunchGear has a good article on what might and might not be in the iPad 2. I agree with them on most of it, especially the thinner body and better speakers. I disagree with the resolution. Putting a retina-display-style screen on such a large screen would be expensive (though not impossible). Upping the resolution slightly is more likely and could be done without "awkward" resizing of elements.
It will run iOS 4.3.
iPhone
The next iPhone will also be available on Verizon, so don't get that iPhone 4 yet. Seriously, just wait 4 months.
The iPhone 5 is rumored to have NFC (near field communication). Apple doesn't add features to their gadgets unless the features are implemented well, so if the phone does have NFC, you can bet that it will be set up to make payments. There is little else you can do with NFC. Apple will have partnered with credit card companies or perhaps worked out a payment system through Verizon and AT&T. It wouldn't make a lot of sense to force users to pay their bills through iTunes.
It might have 4G. There have been rumors that the next iPhone will have both a CDMA (Verizon) and GSM (AT&T) antenna since the Verizon iPhone 4 has a baseband chip that supports both technologies. That chip also supports HSPA+ (AT&T's initial "4G" network), but it doesn't have anything to do with LTE (Verizon's 4G network). If they add in support for LTE, then it would support Verizon's current 4G network and AT&T's future 4G network, while possibly supporting AT&T's current 4G network and both 3G networks. In short, it would be a multi-carrier future-proof phone. That would be great, but a bit out of character for Apple, who only puts the bare minimum of features in their phones, unless those features are shiny and pretty. But by then, most new Android phones will have 4G. Hard to call.
Price will be the same. No reason to change that.
There will be a 64GB model.
Some software updates to catch up with Android features.
iPhone Nano
The blogsphere has been awash with rumors of a smaller, cheaper iPhone ever since the Wall Street Journal posted this rumor. It could be true, but it seems like a mistake. Supposedly, the phone would have less storage, but MobileMe or iTunes would allow users to instead stream music from the Internet, or from their computers through the Internet. Thus, if you're without Internet, you're without music. It would also be "half the size of the iPhone 4", which would make Internet browsing ridiculously bad if this means the screen is half the height. Currently, the iPhone 3GS is $50 on contract (and other Android phones are even cheaper), so I don't see the point of an iPhone Nano unless it is super cheap without a contract. There are Apple fanboys that will buy anything with a fruit logo on it; perhaps Apple will release this just to test their loyalty.
That's it for Apple. I'll post soon (hopefully) with Android and WP7 speculation.
Update: The iPhone Nano didn't sound likely. The New York Times said today (2/17) that Apple is considering a cheaper phone, but not a smaller phone. This won't happen either, at least not this year. Old iPhones are already cheap: the 3GS is $50, and a used 3G will run you ~$150 with no contract on eBay. The only way Apple could compete with their old phones and successfully release a new, cheaper "iPhone Express" would be to make a phone that costs around $200 and somehow isn't worse than a 3G. They can't, so I don't think they will even try.
The Obvious: Thinner, Better, Faster
As usual, the next iPad and iPhone will likely be faster due to upgraded RAM or an upgraded processor (likely dual-core) or both. The iPad 2 might be thinner, but the iPhone 5 probably won't because Apple already went through a major design change with the iPhone 4 after three phones with the same design. They aren't likely to change it up again (except to fix that pesky antenna problem). The next iPad will come out in April or May and the next iPhone will be released in June or July.
iPad
The next iPad should have a CDMA antenna so it can be available through Verizon. Verizon has already promised a Verizon iPad, although the iPad 2 wasn't specifically mentioned. The iPad will NOT have the rumored SD card slot if for no other reason than it would ruin Apple's tiered pricing for different amounts of storage. Front and back cameras are rumored. I definitely agree with the front-side camera because it would mean Facetime was available on one more device. AppleInsider says it might have a mini DisplayPort. A price drop is somewhat out of character for Apple, but it would help them compete with the cornucopia of Android tablets that will be release this year. A price drop on the more expensive models is more likely than a price change on their cheaper models.
CrunchGear has a good article on what might and might not be in the iPad 2. I agree with them on most of it, especially the thinner body and better speakers. I disagree with the resolution. Putting a retina-display-style screen on such a large screen would be expensive (though not impossible). Upping the resolution slightly is more likely and could be done without "awkward" resizing of elements.
It will run iOS 4.3.
iPhone
The next iPhone will also be available on Verizon, so don't get that iPhone 4 yet. Seriously, just wait 4 months.
The iPhone 5 is rumored to have NFC (near field communication). Apple doesn't add features to their gadgets unless the features are implemented well, so if the phone does have NFC, you can bet that it will be set up to make payments. There is little else you can do with NFC. Apple will have partnered with credit card companies or perhaps worked out a payment system through Verizon and AT&T. It wouldn't make a lot of sense to force users to pay their bills through iTunes.
It might have 4G. There have been rumors that the next iPhone will have both a CDMA (Verizon) and GSM (AT&T) antenna since the Verizon iPhone 4 has a baseband chip that supports both technologies. That chip also supports HSPA+ (AT&T's initial "4G" network), but it doesn't have anything to do with LTE (Verizon's 4G network). If they add in support for LTE, then it would support Verizon's current 4G network and AT&T's future 4G network, while possibly supporting AT&T's current 4G network and both 3G networks. In short, it would be a multi-carrier future-proof phone. That would be great, but a bit out of character for Apple, who only puts the bare minimum of features in their phones, unless those features are shiny and pretty. But by then, most new Android phones will have 4G. Hard to call.
Price will be the same. No reason to change that.
There will be a 64GB model.
Some software updates to catch up with Android features.
iPhone Nano
The blogsphere has been awash with rumors of a smaller, cheaper iPhone ever since the Wall Street Journal posted this rumor. It could be true, but it seems like a mistake. Supposedly, the phone would have less storage, but MobileMe or iTunes would allow users to instead stream music from the Internet, or from their computers through the Internet. Thus, if you're without Internet, you're without music. It would also be "half the size of the iPhone 4", which would make Internet browsing ridiculously bad if this means the screen is half the height. Currently, the iPhone 3GS is $50 on contract (and other Android phones are even cheaper), so I don't see the point of an iPhone Nano unless it is super cheap without a contract. There are Apple fanboys that will buy anything with a fruit logo on it; perhaps Apple will release this just to test their loyalty.
That's it for Apple. I'll post soon (hopefully) with Android and WP7 speculation.
Update: The iPhone Nano didn't sound likely. The New York Times said today (2/17) that Apple is considering a cheaper phone, but not a smaller phone. This won't happen either, at least not this year. Old iPhones are already cheap: the 3GS is $50, and a used 3G will run you ~$150 with no contract on eBay. The only way Apple could compete with their old phones and successfully release a new, cheaper "iPhone Express" would be to make a phone that costs around $200 and somehow isn't worse than a 3G. They can't, so I don't think they will even try.
Wednesday, February 9, 2011
Code: Using JavaScript and CSS to Switch to and from a Mobile Site
There are many ways to detect an iPhone or other mobile browser on your website. I chose JavaScript for my professional website because my webhost restricts the use of PHP. (I'm not going to link to my website here because it needs some work.)
There are only a couple ways to set up a mobile version of a website. Using two CSS files is the best method for small sites that don't have a lot of images to resize. Alternatively, you can build a different site just for mobile browsers and redirect mobile users to that site. Right now, I have one website with two CSS files, but eventually I will build a separate mobile site.
This guide is for users that have one version of a website, but two CSS files: one for the full site and one for the mobile site. It shows you how to create dynamic links to the full site from the mobile site and vice versa. I think it's really important for mobile users to have the choice to view a website's full site and the option to go back to the mobile site, but full browser users shouldn't be bothered with a link to the mobile site. Surprisingly few websites do this.
Detecting Mobile Browsers Using JavaScript
This JavaScript code detects mobile browsers by checking the user agent string for the words "iPhone" or "iPod".
// Are we using iPhone or iPod to browse this site?
var mobileDetected = ( (navigator.userAgent.match(/iPhone/i) != null) || (navigator.userAgent.match(/iPod/i) != null) );
Selecting the CSS File
This code writes the code to select either the full site CSS file or the mobile CSS file based on whether or not a mobile browser was detected. It also involves checking cookies, and I'll explain that later.
// If not on mobile or full site was selected, use full site css
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
document.write("<link rel='stylesheet' href='css.css'>");
} else { // else use mobile css
document.write("<link rel='stylesheet' href='iphone.css'>");
}
Allowing Mobile Browsers Access to the Full Website
Now that we can detect mobile browsers and get them to use the mobile CSS file, we need a way to prevent our site from always doing this so that the mobile browser can also access the full site. The way I do this is with cookies. This HTML code displays the link to the full website:
<div class="mobileOnly"><br>
<br>
<a href="index.html" onClick="skipMobileSite()">go to full site</a>
</div>
Notice that this code is wrapped in a class called mobileOnly. I ensure that only mobile browsers can see this text by making mobileOnly invisible in my full site CSS file:
/* Always hide this on normal site */
div.mobileOnly {
display: none;
}
But in my mobile CSS file, mobileOnly is visible:
div.mobileOnly {
display: inline;
font-size: 25pt;
font-style: italic;
margin-bottom: 30px;
}
You'll notice that in the link to the full site, a JavaScript function skipMobileSite is called. This sets the actual cookie:
function skipMobileSite() {
// Skip mobile site with a cookie setting, no expiration date
document.cookie = 'occSkipMobile=true; path=/';
}
Cookies with no expiration date expire when the user closes his browser.
So this link sets a cookie that tells us that the mobile user prefers to view the full website. This means we need to check for this cookie every time this page is loaded. That's what the getCookie function does in the "Selecting the CSS File" section. When a cookie is found that states a user's preference for the full website, the full website CSS file is selected. Here's an implementation of getCookie from quirksmode.org (paraphrased):
function getCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') { c = c.substring(1,c.length); }
if (c.indexOf(nameEQ) == 0) { return c.substring(nameEQ.length,c.length); }
}
return null;
}
Let's look at that line for selecting the full CSS file again:
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
So, if a mobile browser isn't detected, the full CSS file is selected. Or if the full website cookie is set to "true", the full CSS file is selected. Otherwise, we select the mobile CSS file.
Notice that the link to the full site links to "index.html", which is the page all this code is on. It's just an easy way to refresh the page. Alternatively, I could have linked to "#" and written a page refresh in the skipMobileSite function.
Allowing Mobile Browsers Access Back to the Mobile Website
Now we have two versions of one website where mobile users are automatically sent to the mobile version, but they can click a link that only they can see that will take them to the full website from that point on. We just need to link back to the mobile site.
<script language="JavaScript">
<!--
// only write this if we're on a mobile and deliberately selected full site
if(mobileDetected && getCookie("occSkipMobile") == "true") {
document.write("<a href='index.html' class='fullSiteOnly' onClick='allowMobileSite()'>go to mobile site</a>");
}
//-->
</script>
document.write is only called when a mobile browser is detected and the full website cookie is set. Just to be sure, the class is fullSiteOnly, which is invisible in the mobile CSS file:
/* Always hide this on mobile site */
div.fullSiteOnly {
display: none;
}
but is visible in the full website CSS (there's no code in the full site CSS for this). So this link is only visible to mobile browsers that have clicked "go to full site" and it calls a function called allowMobileSite before refreshing the page. What does allowMobileSite do? It simply removes the full website cookie by setting the cookie to an expired date:
function allowMobileSite() {
// Just delete cookie by setting it to past date
document.cookie = 'occSkipMobile=true; expires=Fri, 3 Aug 2001 20:47:11 UTC; path=/';
}
Result (click to enlarge pictures)
This is my website on a regular desktop computer. There are no links to a mobile or full website.
This is my website on an iPhone (two images have been combined to show the entire page). By default, the mobile edition is showing. Mobile-friendly CSS code allows for easy navigation on mobile browsers. It contains a link to the full website at the bottom.
This is my website on an iPhone after clicking "go to full site". It looks just like the website on a desktop computer, except for the link to the mobile site at the bottom. If a user clicks that link, he will go back to the "mobile edition" of the site.
All the Code Together
Let's review the whole thing. First the full website CSS file, css.css:
/* Always hide this on normal site */
div.mobileOnly {
display: none;
}
Then the mobile CSS file, iphone.css:
div.mobileOnly {
display: inline;
font-size: 25pt;
font-style: italic;
margin-bottom: 30px;
}
/* Always hide this on mobile site */
div.fullSiteOnly {
display: none;
}
And finally, the webpage, index.html. First we define the JavaScript functions, then we detect mobile browsers, then we check the cookie and select a CSS file, and finally we dynamically create links to the full site and mobile site:
<script language="JavaScript">
<!--
function getCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') { c = c.substring(1,c.length); }
if (c.indexOf(nameEQ) == 0) { return c.substring(nameEQ.length,c.length); }
}
return null;
}
function skipMobileSite() {
// Skip mobile site with a cookie setting, no expiration date
document.cookie = 'occSkipMobile=true; path=/';
}
function allowMobileSite() {
// Just delete cookie by setting it to past date
document.cookie = 'occSkipMobile=true; expires=Fri, 3 Aug 2001 20:47:11 UTC; path=/';
}
// Are we using iPhone or iPod to browse this site?
var mobileDetected = ( (navigator.userAgent.match(/iPhone/i) != null) || (navigator.userAgent.match(/iPod/i) != null) );
// If not on mobile or full site was selected, use full site css
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
document.write("<link rel='stylesheet' href='css.css'>");
} else { // else use mobile css
document.write("<link rel='stylesheet' href='iphone.css'>");
}
//-->
</script>
<div class="mobileOnly"><br>
<br>
<a href="index.html" onClick="skipMobileSite()">go to full site</a>
</div>
<script language="JavaScript">
<!--
// only write this if we're on a mobile and deliberately selected full site
if(mobileDetected && getCookie("occSkipMobile") == "true") {
document.write("<a href='index.html' class='fullSiteOnly' onClick='allowMobileSite()'>go to mobile site</a>");
}
//-->
</script>
Just embed those code snippets in your respective CSS and HTML files, and mobile users visiting your website will be able to switch back and forth between the mobile and full websites with ease.
Although this article as a whole and the code on my professional website are protected by copyright, feel free to use and tweak any of the code examples written in this article.
There are only a couple ways to set up a mobile version of a website. Using two CSS files is the best method for small sites that don't have a lot of images to resize. Alternatively, you can build a different site just for mobile browsers and redirect mobile users to that site. Right now, I have one website with two CSS files, but eventually I will build a separate mobile site.
This guide is for users that have one version of a website, but two CSS files: one for the full site and one for the mobile site. It shows you how to create dynamic links to the full site from the mobile site and vice versa. I think it's really important for mobile users to have the choice to view a website's full site and the option to go back to the mobile site, but full browser users shouldn't be bothered with a link to the mobile site. Surprisingly few websites do this.
Detecting Mobile Browsers Using JavaScript
This JavaScript code detects mobile browsers by checking the user agent string for the words "iPhone" or "iPod".
// Are we using iPhone or iPod to browse this site?
var mobileDetected = ( (navigator.userAgent.match(/iPhone/i) != null) || (navigator.userAgent.match(/iPod/i) != null) );
Selecting the CSS File
This code writes the code to select either the full site CSS file or the mobile CSS file based on whether or not a mobile browser was detected. It also involves checking cookies, and I'll explain that later.
// If not on mobile or full site was selected, use full site css
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
document.write("<link rel='stylesheet' href='css.css'>");
} else { // else use mobile css
document.write("<link rel='stylesheet' href='iphone.css'>");
}
Allowing Mobile Browsers Access to the Full Website
Now that we can detect mobile browsers and get them to use the mobile CSS file, we need a way to prevent our site from always doing this so that the mobile browser can also access the full site. The way I do this is with cookies. This HTML code displays the link to the full website:
<div class="mobileOnly"><br>
<br>
<a href="index.html" onClick="skipMobileSite()">go to full site</a>
</div>
Notice that this code is wrapped in a class called mobileOnly. I ensure that only mobile browsers can see this text by making mobileOnly invisible in my full site CSS file:
/* Always hide this on normal site */
div.mobileOnly {
display: none;
}
But in my mobile CSS file, mobileOnly is visible:
div.mobileOnly {
display: inline;
font-size: 25pt;
font-style: italic;
margin-bottom: 30px;
}
You'll notice that in the link to the full site, a JavaScript function skipMobileSite is called. This sets the actual cookie:
function skipMobileSite() {
// Skip mobile site with a cookie setting, no expiration date
document.cookie = 'occSkipMobile=true; path=/';
}
Cookies with no expiration date expire when the user closes his browser.
So this link sets a cookie that tells us that the mobile user prefers to view the full website. This means we need to check for this cookie every time this page is loaded. That's what the getCookie function does in the "Selecting the CSS File" section. When a cookie is found that states a user's preference for the full website, the full website CSS file is selected. Here's an implementation of getCookie from quirksmode.org (paraphrased):
function getCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') { c = c.substring(1,c.length); }
if (c.indexOf(nameEQ) == 0) { return c.substring(nameEQ.length,c.length); }
}
return null;
}
Let's look at that line for selecting the full CSS file again:
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
So, if a mobile browser isn't detected, the full CSS file is selected. Or if the full website cookie is set to "true", the full CSS file is selected. Otherwise, we select the mobile CSS file.
Notice that the link to the full site links to "index.html", which is the page all this code is on. It's just an easy way to refresh the page. Alternatively, I could have linked to "#" and written a page refresh in the skipMobileSite function.
Allowing Mobile Browsers Access Back to the Mobile Website
Now we have two versions of one website where mobile users are automatically sent to the mobile version, but they can click a link that only they can see that will take them to the full website from that point on. We just need to link back to the mobile site.
<script language="JavaScript">
<!--
// only write this if we're on a mobile and deliberately selected full site
if(mobileDetected && getCookie("occSkipMobile") == "true") {
document.write("<a href='index.html' class='fullSiteOnly' onClick='allowMobileSite()'>go to mobile site</a>");
}
//-->
</script>
document.write is only called when a mobile browser is detected and the full website cookie is set. Just to be sure, the class is fullSiteOnly, which is invisible in the mobile CSS file:
/* Always hide this on mobile site */
div.fullSiteOnly {
display: none;
}
but is visible in the full website CSS (there's no code in the full site CSS for this). So this link is only visible to mobile browsers that have clicked "go to full site" and it calls a function called allowMobileSite before refreshing the page. What does allowMobileSite do? It simply removes the full website cookie by setting the cookie to an expired date:
function allowMobileSite() {
// Just delete cookie by setting it to past date
document.cookie = 'occSkipMobile=true; expires=Fri, 3 Aug 2001 20:47:11 UTC; path=/';
}
Result (click to enlarge pictures)
This is my website on a regular desktop computer. There are no links to a mobile or full website.
All the Code Together
Let's review the whole thing. First the full website CSS file, css.css:
/* Always hide this on normal site */
div.mobileOnly {
display: none;
}
Then the mobile CSS file, iphone.css:
div.mobileOnly {
display: inline;
font-size: 25pt;
font-style: italic;
margin-bottom: 30px;
}
/* Always hide this on mobile site */
div.fullSiteOnly {
display: none;
}
And finally, the webpage, index.html. First we define the JavaScript functions, then we detect mobile browsers, then we check the cookie and select a CSS file, and finally we dynamically create links to the full site and mobile site:
<script language="JavaScript">
<!--
function getCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0)==' ') { c = c.substring(1,c.length); }
if (c.indexOf(nameEQ) == 0) { return c.substring(nameEQ.length,c.length); }
}
return null;
}
function skipMobileSite() {
// Skip mobile site with a cookie setting, no expiration date
document.cookie = 'occSkipMobile=true; path=/';
}
function allowMobileSite() {
// Just delete cookie by setting it to past date
document.cookie = 'occSkipMobile=true; expires=Fri, 3 Aug 2001 20:47:11 UTC; path=/';
}
// Are we using iPhone or iPod to browse this site?
var mobileDetected = ( (navigator.userAgent.match(/iPhone/i) != null) || (navigator.userAgent.match(/iPod/i) != null) );
// If not on mobile or full site was selected, use full site css
if(!mobileDetected || getCookie("occSkipMobile") == "true") {
document.write("<link rel='stylesheet' href='css.css'>");
} else { // else use mobile css
document.write("<link rel='stylesheet' href='iphone.css'>");
}
//-->
</script>
<div class="mobileOnly"><br>
<br>
<a href="index.html" onClick="skipMobileSite()">go to full site</a>
</div>
<script language="JavaScript">
<!--
// only write this if we're on a mobile and deliberately selected full site
if(mobileDetected && getCookie("occSkipMobile") == "true") {
document.write("<a href='index.html' class='fullSiteOnly' onClick='allowMobileSite()'>go to mobile site</a>");
}
//-->
</script>
Just embed those code snippets in your respective CSS and HTML files, and mobile users visiting your website will be able to switch back and forth between the mobile and full websites with ease.
Although this article as a whole and the code on my professional website are protected by copyright, feel free to use and tweak any of the code examples written in this article.
Subscribe to:
Posts (Atom)