Another new feature for
GTViewer for iOS version 3 is the
Web App Framework.
It allows GTViewer on the iOS platform to
communicate with a Web Server and perform various tasks remotely, then display and save the results locally.
GTViewer for iOS is designed to work
without a network connection once the dataset has been downloaded. There may be times, though, when additional
information or processing is needed beyond getting a refresh of the GIS dataset.
When a user is connected, they can now run a
Web App to download information
such as Outages, Jobs, Crew Locations, etc.
This information can be tabular and/or graphic and can be saved for
offline use. Other applications of this
framework include resource intensive tasks like network tracing or other types
of analysis.
If we compare GTViewer for iOS's
Web
App Framework to its
Data Collection Framework, there are both similarities and differences. They both extend functionality, they both use customizable HTML forms for their user input, and
they both use a server component in some way.
The Data Collection Framework's biggest difference is that it is geared specifically for the collection
of data for features or points on the map.
It also has built-in functionality to handle all of the record
synchronization with a
GTShare server and Lifecycle management. The only thing you have to provide is your
Data Collection Form. A Web App, on
the other hand, is an open sandbox that will let you implement whatever you
want. There is not a specified task that
it is meant to solve, and it has a great deal of flexibility available. It also requires you to implement the server
portion of the Web App. In some cases,
this may be something you already have or something that is not difficult to
create, but it could be a significant piece of development depending on your
requirements.
In GTViewer for iOS,
Web Apps are launched by selecting a feature and viewing the Attribute
Information. If a Web App is associated
with a feature, a section will appear at the top of the Attribute Info containing
a link to start the Web App. A Web App
Form must be provided with the dataset.
It is very similar to a Data Collection Form in that it is created in
HTML and JavaScript and has access to the selected feature’s tabular attribute
values. However, instead of collecting information to
save in a Data Collection Record, it is just an interface to the App you will be
communicating with on a Server. It can
be simple or sophisticated depending on what options you need to send to the
App on the server and how you want to represent the results that are returned. In its simplest
form, it is just a Button to start the app and someplace to display the results
(if there are any).
Example
It is probably easiest to understand
Web Apps if we look at an example.
A common request for GTViewer for iOS is support for Network Tracing
(Gas Valve Isolation, Upstream/Downstream Traces, Fiber OTDR, etc.). These types of apps could be coded into the
GTViewer for iOS base product, but would probably only be applicable to the
users they were created for. Unlike
GTViewer for Windows, it is not so easy to create your own external apps on the
iOS platform. There is no VB or C# or
built-in extensibility like we are used to in the Windows world. The
Web App Framework attempts to narrow
this gap.
Let’s look at a common Electric Trace that finds all
Downstream Customers from a selected Primary Conductor. This is a fairly simple network trace, but
it does have some complicated aspects.
We first need a Server App to perform the trace. For this example, an ASP.NET app using the
GTViewer Objects and
GTTrace.
The GTViewer Objects are low-level .NET components for reading and using
GTViewer data without running GTViewer or GTVx (no display is required). With a GTViewer dataset, these objects can
perform queries, do spatial searches, lookup feature attributes, create .GTG
files, and much more. The GTTrace objects abstract all of the commonly used network tracing functionality making it easier to create network tracing apps. By using these components wrapped
up in a simple ASP.NET application, a web page is created that will accept a
Feature’s connectivity Node Ids as a starting point, then it will separately
trace in all directions from the starting feature to find a Breaker (to
determine the Upstream direction). The downstream
direction is then searched to gather a list of downstream customers. The results send back to the user includes a list of customer’s, their location, and
pertinent attribute information is returned as the Web Apps result's along with a list
of highlighted features to identify the upstream and downstream portions of the
circuit, the location of the downstream customers, and the breaker.
GTViewer for iOS will take the results from
the Web App and let the user browse the list of Downstream Customers (and optionally locate on them in the map), and graphically show the highlighted trace results.
In the example shown below, you select a Primary Conductor in the map. The Attribute Info is shown. Since the Primary Conductor feature is associated with a Web App, there is a a Web Apps section at the top with a Link to the Downstream Customer Trace app:
If you click the Link to the Web App, it will display the Web App Form for the Downstream Customer Trace App. For this example, the interface to the app is very simple. There is a Start Trace button and a Results box to display the trace's tabular results:
When you press the Start Trace button, the Web App on the Server is sent a request to perform the network trace using the selected feature's information as the starting point. When the Server finishes processing, it will send back the trace results and the list of Downstream Customers is shown in the Results box.
You can scroll through the Results and can select the Locate on each record to Locate that Customer in the map. You can also press the Highlight button to draw the highlighted trace results on the map.
The Save button in the Trace Results will let you save the results so they can be recalled later. Saved results do not require a network connection to recall, and both the tabular and graphic data are saved.
This example of a Web App is very specific but any scenario that involves selecting a feature, specifying some options, and displaying tabular and/or graphical results will work. The capabilities of the Web App interface will expand too in future versions.
