In this chapter, you will learn the following:
• How to use geolocation to determine the location of your users/customers/clients
• About reverse geocoding in the Google Maps API to find the address of a given latitude/longitude
• About the asynchronous nature of certain operations in the Google Maps API
• How to send e-mail by using a server-side function
Introduction
The projects for this chapter involve the Google Maps API, geolocation, and PHP. I will describe two applications: the first just to show geolocation, a facility in which the browser determines the user’s location using one of a variety of means. This application lets you find out where the location services think you are and compare it to where you really are. The second application provides a way for the user to generate an e-mail using the geolocation information along with other data and send it to someone.
This makes use of a server-side PHP script to send the e-mail, and HTML5 form validation to confirm the e-mail addresses.
The geolocation specification is under development in parallel with HTML5 and is considered a distinct specification. It also is different from Google Maps, though Google Location Services is one of the main sources of geolocation information. An obvious thing to do with the location data is to display a Google Map, but you can do anything you want with the information.
One important feature of the geolocation specification is that the user—that is, the person on the client computer browsing the web page—must give approval for the location to be determined. This is so-called “opt-in.” The exact look of the screen varies with the different browsers. The terminology varies: a specific address may want to know, to track, or to use. It is all the same thing. Figure 6-1 shows the opening screen using Firefox.
Figure 6-1. Opening screen with request for permission to share location (Firefox)
The drop-down menu offers four options: Share Location, Always Share, Never Share, and Not Now.
If you choose the first option, when you refresh the screen or return to the page, the program will prompt again for a response.
Notice that other material already appears on the screen from my program. The request for permission is triggered when the code is invoked for the geolocation operation. Figure 6-2 shows the analogous screen in the Opera browser.
Figure 6-2. Opening screen with request for permission to share location (Opera)
Notice that Opera gives the option of remembering the choice for this site. Figure 6-3 shows a follow-on screen that requests another confirmation that the user is opting-in.
Figure 6-3. Additional request from Opera
Figure 6-4 shows the corresponding screen in Chrome. At this point, I had uploaded the application to one of my server accounts. The browser uses the domain name of the account in its query.
Figure 6-4. Opening screen with request for permission to share location (Chrome)
Figure 6-5 shows the screen for Safari. I returned again to using a file on my local computer.
Figure 6-5. Request for permission to share location (Safari)
Notice that Safari provides the user a way to give permission for 24 hours—that is, avoid repeated requests each day. Note that Safari on my desktop PC does not work, and unfortunately hangs up—does nothing—rather than trigger the problem handler when the simplest call is made. I will show where it does work when explaining the different ways that geolocation actually is performed and techniques to use so that the problem handler will be triggered. For now, I note that the variant of Safari running on the iPhone does work. Figure 6-6 shows the permission screen for an iPhone. I wanted to test the other program, so I made use of another server account.
Figure 6-6. Request to share location (iPhone)
There are many variables, which will be explained following, but in my recent experiment around my town, the iPhone returned the most accurate results.
The permission is associated with the browser. For example, clicking “Remember my choice for this site” for Opera will not affect what happens when you use Firefox or any other browser. You also can use the general settings in the browser for all sites. For example, in Firefox, using Tools/Page
Info/Permissions, you can choose from among Always Allow, Always Block, and Always Ask, the latter being what is recommended. In Opera, you can right-click (PC) or Ctrl+click (Mac), or choose Edit Site Preferences ➤ Network, to get the same choices. In Chrome, you start by clicking the wrench symbol in the upper right. Then choose Options ➤ Under the Hood ➤ Content Settings, and scroll down to Location. Safari appears to take a different approach. You can click the gear symbol in the upper right and then click Preferences and choose the Security tab. The choices are to allow sites to ask or not give permission at all. The iPhone provides similar options in Settings ➤ General ➤ Location Services.
The geolocation standard is moving its way through the recommendation process in the W3C (see www.w3.org/2008/geolocation/drafts/API/Implementation-Report.html). You need to check and keep checking with each browser to determine what features work and how.
So, moving on, what does my program do after being given permission to determine the location?
The program, geolocationkmgeo.html, uses the returned coordinate values to bring in a Google Map, and uses another service, reverse geocoding, to calculate an address. Figure 6-7 shows the result. The geolocation is termed the base.
Figure 6-7. Location found in the basic program
The reverse geocoding has returned 100-162 E. Main Street, Mt. Kisco, NY 10549, USA for the description of the address with accuracy given as 86 meters. That is fairly accurate for the location of the red x. This screenshot was made while using a laptop at the Borders Café (now closed).That fact is significant because, as will be demonstrated, the geolocation itself was fairly accurate The official W3C specification for geolocation supplies little information on how the accuracy is calculated. This project can be used to make your own analysis of how accurate the geolocation is. The user can use the Google Maps interface to zoom and/or pan and then click the screen. This is what I did. A black dot will appear, along with the reverse-geocode address and the distance from the base of the clicked location. This can serve to check out distances to other locations, or calculate the distance from the geolocation to the actual location. Figure 6-8 shows the result of clicking the screen at where I determined I actually was.
Figure 6-8. Screen showing actual location
The reverse geocoding is good: we were on Green Street. The program calculates and displays the distance from the base (the red x) and where I clicked (the black x). The location was .03 kilometers (equivalent to 30 meters). This is within the 86 meter accuracy returned by the geolocation function.
The second application demonstrates how you can use geolocation, reverse-geocode information, and actions you take yourself to compose an e-mail to send to someone else. Of course, many
companies offer such services to facilitate meet-ups, promote restaurants, and so on. This application, geolocationkme-mail.html, makes use of a small program written in PHP that runs on your server to send e-mail to a person of your choosing. You will need to confirm that this is possible for your server account. This is an extra service that your Internet Service Provider may or may not provide. We’ll will return to PHP in Chapter 10.
After agreeing to allow geolocation, the opening screen of the second application is shown (see Figure 6-9).
Figure 6-9. Opening screen for the e-mail program
Notice that there is a form on display with a place to put From and To e-mail addresses. The subject line has the reverse-geocoding information, and the body of the message refers to the subject line.
Next, I click where I believe I am. This application does require you to be able to find yourself on a map! Figure 6-10 shows the results.
Figure 6-10. After clicking the location, the screen with information in the message body
The clicked location now has the default marker used by Google Maps. This actually was an
oversight on my part, but I decided to stick with it to show you that you can use the default upside-down teardrop icon. Notice that the subject line and the body of the e-mail have been filled. Now is the time to put in the From and To addresses. You can also change what is in the body of the e-mail or the subject line. You then click the SEND button. It is not instant, but the message will be sent to your e-mail account. Figure 6-11 shows the message as it appears in my Gmail account.
Figure 6-11. The received e-mail with location information
assumption to make. To handle this, I declared form validation as a requirement for this application.
Form validation refers to a set of tests that are done to check if the input is valid. With form validation, if the user neglects to put in anything before hitting the SEND button, the program will present something like what is shown in Figure 6-12 (produced using Chrome).
Figure 6-12. Message from Chrome when a required field is empty
If the user puts in something, but that something isn’t a valid e-mail address, to the extent that it can be ascertained in terms of format alone, the application will present something like what is shown in Figure 6-13 (also produced using Chrome).
Figure 6-13. Invalid e-mail address as detected by Chrome
Other browsers also support similar form validation. Figure 6-14 shows the response produced by Firefox for an empty field.
Figure 6-14. Message from Firefox when a required field is empty
Figure 6-15 shows the response produced by Firefox for input that was not the correct format for e-mail.
Figure 6-15. Invalid e-mail address as detected by Firefox
One can argue that it would be better if all the form input fields were validated at once, but that could lead to an overcrowded screen. We hope the user gets the message. If not, the messages will be repeated for the To field. The user may wonder about the meaning of the From e-mail field. It does not mean that this message will show up in the SENT folder in the user’s e-mail account. What it does is make it possible for the receiver to click Reply.
With this introduction to the projects for this chapter, I’ll now provide background on geolocation and other critical requirements for these applications.