Bestaurants, the best restaurants in Belize

It has been proven that it's easy to learn a new concept by actually implementing that concept in a real-life project scenario. That is why we created this fictional project. Reading the project statement and requirements will teleport you in to the context of a developer who has to analyze, design, and implement instead of just being a reader. This helps you guess how you will be able to do things instead of being spoon-fed and bombarded by information. We will start small, from concepts you will probably be familiar with, which will give you the confidence to progress through the book. We will slowly develop and plug in the components into the main website until the whole website is completed. At the end of each chapter, I will provide a support file with the last chapter on the website, just in case you decided to skip through a chapter, you can pick up things from the previous chapter.

Note

This project is an example that will be used and it will keep on reappearing in the following chapters. This is not an actual project and not related to the country whatsoever.

The project statement

Belize is thriving in tourism. Lots of tourists go there on holidays to enjoy its beautiful beaches and a wide range of restaurants. The government of Belize is trying to enrich tourists' experience in finding their favorite restaurants in the country more effectively. To accomplish that, a new project titled Bestaurants has been proposed to design a website to feature the best restaurants in Belize. For that, they asked for the website to be able to run on both desktop browsers and mobile devices.

The website will contain a map that shows the city of Belize and the restaurants with key icons based on the restaurant type. For example, a café will be shown as a coffee mug and a restaurant will be displayed as a fork and knife. Tourists should be able to search for restaurants by name, category, or rating. The results should show the ratings, reviews, and pictures of that restaurant if available. The user will only be able to upload photos and write reviews. When the user opens the website from his mobile phone or a tablet, they should get the exact same functionalities that are available in the web version. Finally, the website will identify and show the user location on the map using the Global Positioning System (GPS) receiver on the device. The user can then highlight all restaurants near them by clicking on a button.

Note

GPS: Global Positioning System provides the location and time information using satellites on the earth. Nearly all new smart phones are equipped with GPS receivers that can identify the device location with respect to Earth. You can read more about GPS here:

http://www.gps.gov/

Proposed Interface Design

Before we start the development, we need to get a picture of what the website would look like after it is completed. That is what is called the Interface Design; we can do it on a piece of paper or using sophisticated software such as Microsoft Visio. What is important is to capture what the website should look like.

Note

Interface Design: This is the heart of any web application, which defines how the website will look like and function. The general rule of thumb is to keep the interface simple.

Let's start designing our canvas; we will start with the most important element of the website: the map. I know that there will be a map because the project statement says:

The website will contain a map that shows the city of Belize and the restaurants with key icons based on the restaurant type.

The map will display the restaurants, and the user will be interacting with it. The map should be the biggest object on the site as it will be the focus point for the user. The map will need zoom functionality, so we will add a small slider to the top to help the user zoom in or zoom out. Moreover, the user will require a legend to show the key objects on the map; so we will reserve a space for that as well. Reserving 25 percent of the left side of the website will suffice for the legend. The following figure illustrates what the application page design will look like. Remember that the design can be changed as we progress through the chapters.

The website looks simple and zen, but unfortunately, we cannot keep it this simple. We need to add more elements to the design. Read the following quote from the project statement:

Tourists should be able to search for restaurants by name, category, or rating. The results should show the rating of the restaurant, reviews, and pictures of that restaurant if available.

This quote implies that we should have a search box and probably a drop-down list for the category and rating. The bottom line is that there will be some input controls that the user will interact with; so we need to reserve a space for it. Let's reserve the upper 10 percent of the web page for input controls. We also need some space to display the search result where we can display the restaurant name, rating, reviews, and photos. For this, we can use the left area, below the legend. The new Interface Design is illustrated in the following figure:

As the user searches and interacts with the map, it will be nice to display some status and loading messages for them. Let's save the bottom five percent of the page for status messages.

Of course, this design is not written on stone, so you might want to move things around as you progress through the book. Take a look at our initial Interface Design:

The proposed architecture

Before rushing in to the developing process, it is always good practice to create the architecture of your components. This helps show how the entire solution is tied together. The architecture describes the software, hardware components, the relations between them and assess in viewing the solution as a whole. With the architecture, the developer can see the big picture before diving into the details of implementation, which may save them a lot of time and make them consider exterior elements. You can read more about system architecture at:

http://www.esri.com/library/whitepapers/pdfs/sysdesig.pdf

The first part of the architecture is to make a decision on what programming language is suitable for the web application. This can only be determined by reading the requirements. Let's take a look at the following quote from the project statement:

The Client asked for the site to run on both desktop browsers and mobile devices.

The best option to make a web application able to run on both mobile and desktop is to use a language that will run on both. ArcGIS provides APIs for Silverlight, Flex, and JavaScript. Silverlight and Flex are good and simple programming languages and provide rich interface and logic; however, they both require browser plugins to run, and no smart phone supports it, so they are out of the question. This leaves us with the ArcGIS JavaScript API to develop our web application. The reason we chose JavaScript is that this scripting language is open standard and can run in modern browsers including mobile devices. JavaScript is a client-side scripting language, which means all the code executes on the client. Keep that in mind while we design the architecture. Note that JavaScript API is a volatile SDK and a continually evolving API. Esri continually releases updates for this library at least twice a year, adding new functionally in each update. It is crucial to mind which version you are developing on, use one, stick to it, and upgrade as you see new functionalities that you would like to use. Fortunately, this API can work with services shared and published on ArcGIS Online, which makes it a really good choice.

Note

API: Application Programming Interface is a set of functionalities that are exposed for the developers to extend and customize particular software; in our case, this software is ArcGIS.

Silverlight: Silverlight was created by Microsoft. This is a rich structured language that runs on the client, but requires a special plugin to be translated in the browser.

Flex: Flex was created by Adobe. This is a rich programming language that provides rich content on the web and requires a special plugin to run on a browser.

ArcGIS JavaScript API: This is an application programming interface exposed as a JavaScript library that is used with ArcGIS for Server services. This API can run on modern browsers and mobile devices without a plugin.

Now that we have selected our programming language, there are four main components we can look at in our Bestaurants project. The components are listed as follows:

• The database that contains the restaurant's data.
• The ArcGIS for Server site that connects to the database.
• The web server where our web application will be hosted and where the clients will connect to browse the website.
• The client browser, which will connect to the web server to retrieve the website. Take a look at the following figure for more details:
  

Let's explain this design, from the moment a user opens the web application up until the moment they are served the map, in the following steps:

1. The user opens the browser and types the address of the web server hosting the web application that we will be writing. This will send an HTTP request to the web server.
2. The web server receives the user HTTP request and returns the content of the website back to the user.
3. Since the scripting language is JavaScript, the browser starts executing the code locally on the browser side. The ArcGIS JavaScript code that you will write in Chapter 2, Setting Up the Basic Web Application, will create an HTTP request to the ArcGIS for Server site for the Bestaurants web service.
4. ArcGIS for Server site receives the HTTP request from the client, and converts the HTTP request into a Structured Query Language (SQL) query to be sent to the database.
5. The database executes the query and returns the result to ArcGIS for Server.
6. ArcGIS for Server wraps the results into an HTTP request and returns it back to the client.

Note

SQL: Structured query language, is a language designed to retrieve data from a database. The syntax of this language depends on the type of the database.

In our case, the web server, ArcGIS for Server and the database components are located on a single machine named ARCGISMACHINE. You can choose to put each component in a separate server, which is a good practice for scaling each component independently later.