PC Pro blog » javascript

Displaying a location marker on a Google Map

Ian Devlin — Thu, 23 Dec 2010 12:54:54 +0000

One of the most popular features on websites today is a marker pinpointing a location on Google Maps. It’s incredibly easy to add such a map to a website and I’m going to show you how.

I said it was easy, and with the recent release of version 3 of the Google Maps JavaScript API, it’s become even easier. With the previous version of this API, you had to register your map to receive an API key, but that’s now no longer necessary.

Naturally Google provide a comprehensive guide to the Maps API, but I will run through the basics here.

Setting up the Map

First of all you need to include the map API in your web page. This is done by adding the following line in the element of your code:

You may notice the sensor parameter, which is set to false. This is a required parameter and should be set to “true” if the application used to determine the user’s location has a sensor device (e.g. a GPS locator). That’s not the case here, so we set it to false as shown.

Naturally, we need to define a map to display, but before we do that we need three things: somewhere on the web page to actually place the map, a default position to use as the map’s centre, and then some options to define the type of map that we require.

Setting up somewhere on the web page to place the map is a simple case of defining a div with a unique id, and some inline styling. So we have:

And that’s all we need.

To define a default position we need a latitude and longitude. There are plenty of websites out there that will convert addresses or places into coordinates for you, and I will centre this particular example on the PC Pro offices at latitude 51.515252 and longitude -0.189852. From these values a Google map position is defined by using the following:

var latlngPos = new google.maps.LatLng(51.515252, -0.189852);

We then set up the map options as follows:

var myOptions = {
   zoom: 10,
   center: latlngPos,
   mapTypeId: google.maps.MapTypeId.ROADMAP
};

Where zoom (naturally) indicates the zoom level of the map (you may want to play about with these to get the value that you want), center is set to the latitude/longitude position that we defined, and mapTypeId is set to the type of map that we wish to display initially. The map types are defined by the Google Maps API and are:

MapTypeId.ROADMAP displays the default road map view
MapTypeId.SATELLITE displays Google Earth satellite images
MapTypeId.HYBRID displays a mixture of normal and satellite views
MapTypeId.TERRAIN displays a physical map based on terrain information

Note: this simply defines the initial map type to display, the user can change it via a dropdown list that appears on the map itself. You can read more about the different map types over at Google should you want to know more.

With these things done, we can now initialise our map as follows:

var map = new google.maps.Map(document.getElementById("map"), myOptions);

This will now cause the map to appear on your web page, contained within the map div (the map itself stays within the boundaries of the div’s dimensions).

Marking the Location

With the map set up, we can now go about defining the marker on the map that we want displayed. Once again we need to define a position for the Google map using latitude and longitude. I’m using the same values as above, as I want to place a marker on the PC Pro offices (it’ll help the staff when they stumble back from their Christmas party).

var markerPos = new google.maps.LatLng(51.515252, -0.189852);

Adding a marker to this location is as simple as:

var marker = new google.maps.Marker({
   position: markerPos,
   map: map,
   title: "PC Pro Offices"
});

(where map is the id of the map div)

As usual I have a simple example so that you can see it in action. (Note: this example also uses some jQuery)

Going further

The Google Map API is very powerful and you can go much further than I have shown here, such as adding pop-up information windows on the map marker.

You can even use the API to convert addresses into latitude/longitude positions and display them on the map. I have included a more advanced example should you want to take a look at it. It’s pretty straightforward and I’ve commented the code in order to make it clearer.

How to store website data with HTML5

Ian Devlin — Mon, 27 Sep 2010 11:02:47 +0000

Throughout your web browsing careers I’m sure you’ve come across the notion of cookies, pieces of text stored by the browser to be retrieved and used at a later date. These vary from simply remembering your name to welcome you personally next time you visit, to more complicated storage of authentication and shopping-cart contents.

Cookies generally work well but can be fiddly to implement, as they are set to be deleted by default once the browser is closed. If a website owner needs the data to be stored for a longer period, a cookie can be given an expiry date. Again this isn’t as clean as it could be: how far into the future do you set the date, for example? And what happens when a user flushes out their cookies?

HTML5 attempts to clean this up with the introduction of web storage.

Web Storage

Web storage comes in two different types, sessionStorage and localStorage. As might be deduced from the names, sessionStorage is for storing data that’s required for a particular session only, and localStorage is for data that’s to remain indefinitely.

Web storage correctly separates session data from long term data

This does away with the need for expiry dates, and instantly makes it clearer which data is for when and for how long. It also makes it incredibly easy to implement.

The API

As both types are so similiar, they share the same API, which contains the following items and functions:

// The number of items being stored
long length;

// To retrieve the item 'key' from storage
getItem(key);

// To set the item 'key' in storage with 'value'
setItem(key, value);

// To remove the item from storage
removeItem(key);

// To clear the entire storage
clear();

It’s all quite simple and straightforward to use.

Saying Hello

Let’s say you wanted to store a user’s name to welcome them back later. Assuming the existence of a simple HTML5 page consisting of one input field called name and a link that calls the function saveName() it would be defined as follows:

function saveName() {
   var name = document.getElementById('name').value;
   localStorage.setItem('username', name);
}

Each time this page loads, call a new function sayHello() which is defined as:

function sayHello() {
   var userName = localStorage.getItem('username');
   if (userName != null) alert("Hello " + userName + " and welcome back!");
}

This will check for the existence of a username in localStorage, and if it’s there, will welcome the user.

Note that localStorage is used here rather than sessionStorage as we want the name to be displayed next time the user visits the page again, during which time they may have closed the browser, which would clear anything in sessionStorage.

You can see this working for yourself in this very simple “say hello” example. Enter a name, click ’save’, and reload the page.

If you enter a different name in the input field and click ’save’, the existing value will be overwritten. We could also remove the item by calling localStorage.removeItem('name'); which would remove that item only. The entire localStorage could be cleared by calling localStorage.clear();

Session storage

sessionStorage works in the exact same way, except that the data will be automatically cleared once the brower is closed.

You can also store multiple data items in web storage attached to the one key, but you will need to use a JavaScript object and something such as JSON which helps to “stringify” the stored data, thus facilitating its storage.

Browser Support

If you’re used to reading about Internet Explorer’s current inability to support any HTML5 feature, you’re in for a surprise here. Web storage is actually supported by IE8 as well as all the major browsers:

Firefox 3.5+
Safari 4.0+
Chrome 4.0+
Opera 10.5+
Internet Explorer 8.0+
iPhone 2.0+
Android 2.0+

So basically, you can start using it now!

Adding your Twitter feed to your website with jQuery

Ian Devlin — Mon, 13 Sep 2010 10:44:11 +0000

If you or your company has a Twitter account, chances are you’d like to promote it and display your latest tweets from your website. Since many websites – both personal and increasingly business – are built on blogging software such as WordPress, this is usually achieved via a plugin, of which there are many out there.

But what if you simply want to add your live Twitter feed to a “normal” web page? Twitter itself provides a number of HTML widgets, but in this article I’ll show you how easy it is to achieve with a little bit of JavaScript, CSS, and jQuery.

In case you haven’t come across it before:

What is jQuery?

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. It’s very powerful and makes life a whole lot easier when writing JavaScript. To include jQuery in your webpage, simply add the following within the tags:

This uses the version that is hosted on Google Code, which saves you having to download the file.

Twitter API

Twitter itself provides a complicated API to allow access to all sorts of things. A lot of this complication arises around authentication, and necessarily so, but thankfully to simply retrieve a stream of tweets, authentication isn’t required (as long as the user in question hasn’t hidden their tweets).

First of all the API provides many different ways to obtain a user’s statuses. I won’t go into any of them other than the one that I favour, and this is the one that I’ll talk about here: user_timeline.

user_timeline

This returns a number of the most recent statuses posted by the user. It can return the data in different formats: XML, JSON, RSS and Atom. I favour JSON, a lightweight data-interchange format, so this is the one that I will talk about.

You can use a number of parameters, and a full list of what they can do can be found on the Twitter API description for user_timeline. For now, I will only use a few relevant ones.

Give me the Tweets!

To retrieve the data for a particular Twitter account (I will use pcpro in this example here) you call the following:

$.getJSON("http://twitter.com/statuses/user_timeline.json? screen_name=pc_pro&count=10&callback=?", function(tweetdata) { // do some stuff here });

This will return the last 10 tweets from the pc_pro account in JSON format in the tweetdata variable. By default, retweeted tweets are not included in this feed, but to include them, add the &include_rts=1 parameter above, and they will be returned.

Of course we now have to make sense of this data, parse it and actually do something with it.

On our HTML page, define a

tweet-list

$.getJSON("http://twitter.com/statuses/user_timeline.json?screen_name=pc_pro&count=1O&callback=?", function(tweetdata) { var tl = $("#tweet-list"); $.each(tweetdata, function(i,tweet) { tl.append("

“" + tweet.text + "”– " + tweet.created_at + "

");

   });

});

Some explanations: var tl = $("#tweet-list"); grabs a reference to the

$.each(tweetdata, function(i,tweet) {... is the start of a jQuery loop, in this case iterating through each item in tweetdata and storing it temporarily in tweet. The following line then adds the tweet within an

item. The actual text of the tweet is contained within the text data member, and here we put double quotes around it, and the time it was created is contained within the created_at data member.

This will now display the last 10 tweets in list format on the relevant HTML page.

However, if there are links contained in the tweet, they won’t be clickable, and the created date is a bit long and not like the Twitter standard timelines such as “about a minute ago” or “two hours ago”. We can fix this with the following two functions urlToLink(); which we call on tweet.text:

function urlToLink(text) { var exp = /(\b(https?|ftp|file):\/\/[-A-Z0-9+&@#\/%?=~_|!:,.;]*[-A-Z0-9+&@#\/%=~_|])/ig; return text.replace(exp,"$1"); }

and relTime(); which we call on tweet.created_at:

function relTime(time_value) { time_value = time_value.replace(/(\+[0-9]{4}\s)/ig,""); var parsed_date = Date.parse(time_value); var relative_to = (arguments.length > 1) ? arguments[1] : new Date(); var timeago = parseInt((relative_to.getTime() - parsed_date) / 1000); if (timeago < 60) return 'less than a minute ago'; else if(timeago < 120) return 'about a minute ago'; else if(timeago < (45*60)) return (parseInt(timeago / 60)).toString() + ' minutes ago'; else if(timeago < (90*60)) return 'about an hour ago'; else if(timeago < (24*60*60)) return 'about ' + (parseInt(timeago / 3600)).toString() + ' hours ago'; else if(timeago < (48*60*60)) return '1 day ago'; else return (parseInt(timeago / 86400)).toString() + ' days ago'; }

So we need to change the above line to the following:

tl.append("
“" + urlToLink(tweet.text) + "”– " + relTime(tweet.created_at) + "

");

This will be called when the HTML page is loaded (or you can load it some other time, it’s up to you of course) and this is done using jQuery by inserting the code within:

$(document).ready(function() { // code here });

which basically calls the code when the entire DOM has been loaded.

End Result

I have put together an example using all the code above, so you can see all this together and working for yourself. Plus you can view the code to see how it’s done. It’s all commented too, probably overly so, in case you get stuck.

You can of course also style the list and its contents with CSS, but I’ll leave that as an exercise for the reader.

*Update*

One of the comments below asked about retrieving the latest statuses from a specific account’s list. I’ve created a quick example that retrieves and displays the latest updates from PC Pro’s ’staff’ Twitter list. You can of course view the source code.

The main difference is the URL in included in the &.getJSON() call which should be:

http://api.twitter.com/1/account-name/lists/list-name/statuses.json?callback=?

where account-name is the name of the account, in this case pc_pro, and list-name is the name of the list, in this case staff.

Google App Inventor: is drag and drop a flop?

Darien Graham-Smith — Tue, 07 Sep 2010 16:09:17 +0000

Confession time: I have never learnt to program in Java. Swoon, gasp.

It’s not that I haven’t wanted to. In particular, I’ve always loved the idea of creating my own mobile phone apps; but I’ve never seemed to find the time. So I was excited to discover at the weekend that Google has finally given me access to App Inventor — a visual development environment that lets you create Android applications via a drag-and-drop interface, with no Java skills required.

It certainly does simplify the process. The first sample application – which puts up a picture of a cat that miaows when you prod it – is embarrassingly easy to assemble. In the design stage, you simply drag a button onto your workspace (representing the phone screen), import the cat picture, assign the picture to the button and import the sound. Create a click event that plays the sound, and the job’s done.

So yes, the workflow is similar to Microsoft Visual Studio — not that there’s anything wrong with that. But there’s one big difference: in VB.NET, setting up an event handler for the button involves getting to grips with some daunting syntax, along the lines of: Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

In App Inventor you assemble an event handler by simply snapping colour-coded, jigsaw-piece-shaped “blocks” together. In fact, all “code” is constructed by combining blocks within the Java-based Blocks Editor. As Google freely acknowledges, it’s a system that owes a heavy debt to MIT’s Scratch project, an educational programming system which we’ve already produced a tutorial for in our Free Computing Lessons for Kids feature.

Childishly simple?

Does this indicate that App Inventor is similarly intended for kids? Yes and no. Google has said that App Inventor was designed from “an educational perspective”, and tested in “classrooms across the United States”, which sounds like a pretty clear hint. But then Google’s Mark Friedman has also described it as a broader tool, for “programmers and non-programmers, professionals and students” alike. Certainly it can support constructions as sophisticated as anything you’ll find in more grown-up languages:

So while App Inventor is aimed primarily at kids, it’s not just a classroom tool. In principle, it should be powerful enough to produce any application you can imagine.

Writers’ blocks

Sadly, as soon as I started using App Inventor, I discovered the catch. Dragging blocks about may be a fine first introduction to computing, but if you want to create anything more complex than “Pet the Kitty” it’s a slow and fiddly way to work. It doesn’t help that the blocks you need are split across two tabs of seven or more drawers, and as you build up functions the workspace becomes messier and harder to navigate (see the screenshot at the top of this post). Perhaps in time the Blocks Editor will improve, but right now it’s such a faff I can see it driving people away from programming altogether.

That’s a shame, because some of the functions on offer seem designed to appeal to experienced coders, and support some neat mobile-specific capabilities:

But if you ask me, this representation is actually harder to understand than a function written in plain text — and it was certainly harder to construct.

All of which leaves App Inventor looking like a missed opportunity. Yes, for the kids at whom it’s chiefly aimed, it’s a decent introduction to programming concepts. But it has potential far beyond that, and I fear that will never be usefully harnessed, because anyone with the programming nous to make full use of App Inventor’s abilities will surely prefer a language that doesn’t force you to pedantically assemble every function, procedure and event out of multicoloured blocks.

Rewriting the script

In fairness, it’s optimistic to think that any development environment could ever be perfect for both beginner projects and more complex designs. But, tantalisingly, I think App Inventor could get close with one single addition. What’s needed is a traditional script-based view that operates in parallel with the Blocks Editor. For beginners, this would show automatically-generated code (presumably using simple Java-type syntax) representing their block-based constructions, making App Inventor an even better introduction to programming.

Meanwhile, more advanced users could develop directly within the script editor, while still using App Inventor as a time-saving tool for designing interfaces and packaging completed projects. The blocks view, automatically generated from your code, would become a handy visual aid to debugging and program flow.

But in the absence of a script editor, I doubt I’ll be producing any mobile applications with App Inventor. Google certainly deserves credit for the excellent work it’s done in simplifying Android development, and abstracting it away from the nitty gritty of libraries and dependencies. But if the only way to take advantage of that is via drag-and-drop programming then personally I think I might be better off simply learning Java.

The hard facts: what languages web developers should learn

Kevin Partner — Thu, 06 May 2010 11:43:59 +0000

When I first started learning programming, choices were limited to machine code or a version of BASIC. But then I am ancient.

In many ways, the newcomer to programming who’s aiming at web or mobile development has a much better time of it today. This is because whilst there are many, many languages to choose from, they have much more in common than languages of the past. Learn ActionScript, for example, and you’re half way there with C#, PHP and JavaScript, as their basic constructs are identical.

But the real value you, as a web developer, can bring to a project is specialist skill. Whilst every good PHP developer understands the basics of C#, no web project can be completed without in-depth knowledge, and this takes time and lots and lots of practice to develop. It’s a huge investment so the choice of which language to specialise in is also critical, at least in the short- to medium-term.

If you’re aiming to develop your own web applications, you can choose whichever language flies your kite. I develop in PHP, JavaScript/jQuery and Flex/Flash Builder because I like them. PHP is my absolute favourite, and I tend to use that alongside jQuery unless I need the super-rich application features that only Flex/Flash can deliver. My brother, on the other hand, is a massive fan of C# and either language is perfectly capable of creating sophisticated web applications.

If you want to hire yourself out you need to make a more pragmatic choice about which development tool to specialise in and one way to do this is to look at the demand for each. According to the TIOBE Programming Community Index for April 2010, the venerable trinity of C, Java and C++ are the most widely used and requested programming languages. This is mainly because of the huge quantity of legacy code that needs to be managed within large corporations. PHP is the top web scripting language with C# around half of PHP’s level and Python and Perl next. Objective-C, the language used for creating iPhone applications, still only accounts for a tiny fraction of the programming market but is massively on the rise.

So, for web development, PHP is the most popular language (note, I did not say “best”). That’s all very well but I rather suspect that there are more programmers working in PHP than any other development language, which means the competition is huge. We need to know the ratio between popularity and competition.

I went to freelance recruitment site Guru.com and, for each language, found out the number of projects posted for each of the common web and mobile platform development languages. I then noted how many freelancers/companies offered each language. By dividing one into the other, we end up with a rough idea of how competitive the market for expertise in each language is. For example, when I checked there were 151 PHP projects on Guru and 7,769 providers. This means that there are 51.45 providers for each job.

Here’s the full list:

Tool	Providers/Jobs (low is better)
Android	1.86
iPhone	3.39
Silverlight	14.44
Flex	38
PHP	51.45
ASP/ASPX	52.5
Ruby	83.8
Python	90.3
Flash	90.9

What leaps out immediately is that the competition ratio for mobile development is much lower than for web development, and within that Android development is almost twice as attractive a market as iPhone development.

Looking at the web development languages, it looks as though Flash, Python and Ruby development are markets that are saturated with developers chasing relatively few projects. PHP and ASP (which includes ASP and ASPX) are neck-and-neck but the head and shoulders winners are Flex and Silverlight. Whilst there are relatively few projects, there are also few developers.

So which should you choose? Looking at these ratios, it seems to me that choosing either PHP or ASP development with Visual Studio for creating standard web applications is a good initial approach. PHP has the advantage of being free to install and develop for (there are plenty of free IDEs) whereas skills developed in C#, for example, are also transferrable into desktop development. The other benefit of developing in the Visual Studio environment is that adding Flash-like functionality is simply a matter of extending your existing C# skills so that they use the Silverlight player.

From the purely commercial point of view (and if you assume that Silverlight will, eventually, succeed as a technology in becoming as ubiquitous as Flash Player) the Visual Studio approach has a lot going for it: C# becomes a single language that can be used on the desktop, for creating standard .aspx web applications and for developing Silverlight applications.

For me, however, PHP is unbeatable when it comes to productivity, and Flash Player is way ahead in terms of browser installations so, at least for now, I’ll be sticking to this combination. My advice to a newcomer to programming, however, would probably be to download Visual Studio 2010 Express and try C# for size – it may well, finally, be the future Microsoft always intended it to be.

On the other hand, with the forthcoming release of Adobe Air for Android and the low competition level for Android development, Flex has suddenly become a very credible development environment for that platform. You pays your money…

Google says it can keep Chrome on top

Matthew Sparkes — Tue, 16 Sep 2008 18:07:32 +0000

Chrome may have impressed with its speedy rendering and JavaScript performance, but there’s more where that came from says a Google developer.

Kevin Millikin, one of the team which worked on the V8 JavaScript rendering engine that underpins Chrome, gave a talk at the Google Developers Conference today where he explained that although the code is already pretty unique, there are plenty more avenues they can explore to eke out more performance.

“The internet has changed. Inside of Google we do almost all our work, except engineering, in the browser,” said Millikin, explaining that the public aren’t the only ones waiting on Linux and Mac versions of the browser. “We’re looking for it too. We’ve all got MacBooks.”

The company decided early on that it did not want to create a new web platform, which would upset web developers worldwide. Instead they chose to base Chrome on WebKit and have it act just like Safari, almost to the exact pixel. “We even implemented bugs, as long as they weren’t security bugs,” said the developer proudly.

In a talk which was deeply technical to say the least, Millikin ran through the ways in which V8 manages to overtake its rivals. One important method is hidden classes, which takes the messy and loose way that JavaScript handles objects and tidies it up behind the scenes by trying to lay an object-oriented model over it. Add some just-in-time translation to machine code and you already have a speedier engine.

However, there are more tweaks to come. In order to speed up creating new processes V8 already caches the heap at the appropriate moment, but this could also be done with new pages under the same site, and even refreshes – certain JavaScript elements will remain from page to page, and these don’t necessarily have to be recompiled.

It seems that not only has Google nailed JavaScript rendering already, but that it has some excellent engineers with some decent plans for the future to make sure it stays on top. Perhaps Firefox would be wise to take a look at V8. In fact, it may well be unwise not to do so quickly, with news that it is losing market share to the new, faster kid on the block.

“We’ve now entered a new phase in an arms race on JavaScript performance,” said Millikin, diplomatically not naming names. He explained that Google would be keen to see the open source V8 taken into other browser products. With two years of engineering and research behind the project, I’d say that it was the plan from the very start. “When we started the project the JavaScript landscape was pretty grim,” admits Millikin.