First Finder


1. Overview:

At present, the FIRST® bus network is the most widely used bus service in the West Yorkshire and especially in Bradford. The FIRST ® buses run according to a pre-defined schedule. The vast number of bus stops all around Bradford makes it harder to update bus schedules. Apart from the updating problem, most of the bus stops do not have any bus schedule at all, hence making it very difficult for someone to find bus information. These problems increase the need of a system where people can check the required bus service to go to their destinations anywhere and anytime. Although this information is available on some of the bus stops but it is still insufficient to get the required information about routes when you have to switch buses.

This project addresses these issues and provides up-to-date information to its users anywhere, anytime in any conditions. The basic purpose of this project is to find bus route between two different locations within a city. The end user enters the source and destination locations and the service returns all possible bus routes between the paths. The user can use this information to get to the destination or he/she can find more information about the bus, such as bus stop names and bus timings at each of these bus stops.

1.1 System Flow:

This section looks at the overall system flow. The diagram below demonstrates how the information is flowed between the different components of the system.

Figure 1: System Flow

First, any user who wants to use the service enters the URL to access the front page of the WAP site. The front page (or the default page) asks for two key pieces of data, the source and the destination locations. When the user enters this information into appropriate fields and presses the find button, the mobile device submits the values to the server.

The server accepts the source and the destination locations and creates a query for the database. The WAP site running on the Mobile Application Server then submits the query to the database server. The Database server, running any DBMS, executes the query and returns the results back to the Mobile Application Server. This server then formats the information according to the client device and sends it back to the user. The query only shows the possible routes from the source and destination locations.

Now, it is possible for the user to exit the system as he/she can use this information to get to the destination. But, if the user requires further information such as Bus Stops where a particular bus stops and timings on which it stops at each location, then the user can select the desired piece of the information and submits it back to the Mobile Application Server. The whole process explained above is repeated again to generate and return the results to the client.

1.3 Requirements/Technologies Used:

The following technologies and tools are used to build this project:

• Microsoft .NET Framework
• Microsoft ASP.NET Mobile Controls
• Microsoft IIS 5.0
• Microsoft SQL Server 2000
• Nokia Simulators for 7210 , 7110 and 6210
• Microsoft Simulator for Mobile devices
• Microsoft Visual Studio 2003
• Microsoft Visual C#

The reason that I choose these technologies is to get advantage of the power provided by the Microsoft .NET Framework and especially the ASP.NET Mobile Controls. While using Microsoft ASP.NET Mobile Controls the developer does not need to worry about the type of content that he needs to generate. The ASP.NET Framework automatically detects the type of device used by identifying its user agent and formats the content according to the device’s specification. Similarly other Microsoft tools are used to provide a unified development platform and developer’s experience.


2. Application Flow:

2.1 Logical Page Flow:

The logical page flow is described in the system flow section above. The physical flow or the page diagram for such flow is as follows:



Figure 2: Logical Page Flow


2.2 Demo:
This project is tested on three Nokia Emulators and the screen shots captured are shown below.

Nokia 7210


Figure 3: Nokia 7210

Nokia 7110:


Figure 4: Nokia 7110


Nokia 6210:


Figure 5: Nokia 6210


3 . Integration with Mobile Operators:

Apart from the service provided by this project, there are also interfaces for any interested third party. There is an XML Web Service included in the project to expose the specific functionality to any one wanted to use our service. So instead of using WAP, the clients can use any medium to use the contents provided by our application. For example, to implement the same system on SMS or MMS, it won’t take complete re-implementation of the application. Rather, the client uses any Web Service supported language to access our Mobile Web Service.

Figure 6: Integration with Mobile Operators


4. Cost:

The following table shows the cost of the service when it is utilized once.

Page 1: 591 bytes
Page 2:
2698 bytes
Page 3: 1783 bytes
Page 4:
776 bytes
Total 5848 bytes ˜ 10,000 bytes

Calculating Cost:
1 MB = £ 1
Then 10,000 bytes ˜ 10 KB ˜ 1 p

All these prices are depends of the market. It may be possible that in the future, there are changes in the GPRS cost, hence changing these values.


If you like this then you might like my other Projects

No Comments