OpenWells Cross-Platform Application

Capstone Project: CSCI 6838.04

December 10, 2016

Mentors:

David Crawshay Olivier Germain

Halliburton Halliburton
Email: david.crawshay@halliburton.com Email: olivier.germain@halliburton.com

Instructor:
Dr. Pradeep Buddharaju
Assistant Professor in Computer Science
Email: Buddharaju@uhcl.edu

Techno Sharks Team Members:

Rou'a Aldalqamouni (Email: AldaqamouniR1270@UHCL.EDU)

Shreyas Makde (Email: MakdeS3844@UHCL.EDU)
Madhavi Potluri (Email: PotluriM6302@UHCL.EDU)
Daniel Wang (Email: WangD9527@UHCL.EDU)
 Acknowledgements

The Techno Sharks team would like to acknowledge and give thanks to the
individuals who help make this project possible:

Olivier Germain
For providing a great introduction into the oil and gas industry,
Halliburton, and Landmark.

David Crawshay
For explaining the OpenWells iOS application, providing great technical
direction and assistance, and helping to troubleshoot technical issues.

Dr. Pradeep Buddharaju

For assistance with project planning, paper reviews, presentation
reviews, and overall project management.
 Table of Contents
1 Introduction......................................................................................................................................... 1
1.1 Background ................................................................................................................................. 1
1.2 OpenWells iOS Application ........................................................................................................ 1
1.3 Xamarin and Xamarin.Forms ...................................................................................................... 2
2 Requirements ...................................................................................................................................... 2
2.1 Business Requirements ............................................................................................................... 2
2.2 Functional Requirements............................................................................................................. 3
2.3 System Requirements .................................................................................................................. 6
3 System Details .................................................................................................................................... 7
3.1 Design ......................................................................................................................................... 7
3.1.1 Initial Application Design ................................................................................................... 7
3.1.2 Updated Application Design with Conversion .................................................................... 9
3.2 Implementation ......................................................................................................................... 10
3.2.1 Data Model Implementation .............................................................................................. 10
3.2.2 Realm Implementation ...................................................................................................... 10
3.2.3 Web Service Implementation ............................................................................................ 11
3.2.4 Entry Form Implementation .............................................................................................. 12
3.3 Testing and Verification ............................................................................................................ 13
4 Project Management ......................................................................................................................... 13
4.1 Project Timeline ........................................................................................................................ 14
4.2 Task Division ............................................................................................................................ 16
5 Conclusion ........................................................................................................................................ 17
5.1 Project Summary ....................................................................................................................... 17
5.2 Lessons Learned ........................................................................................................................ 18
5.3 Roadblocks................................................................................................................................ 18
5.4 Future Work .............................................................................................................................. 19
6 References......................................................................................................................................... 20
6.1 Paper References ....................................................................................................................... 20
6.2 Coding References .................................................................................................................... 20
6.3 API/NuGet Packages Used........................................................................................................ 20
7 Appendix .......................................................................................................................................... 21
7.1 System Manual.......................................................................................................................... 21
7.2 User Manual .............................................................................................................................. 22
1 Introduction
1.1 Background
Oil and gas are obtained from all around the world, ranging from Venezuela in the far west to New
Zealand in the far east [1][2]. Subsequently, with many workers employed on and off the oil and gas
fields, a way to monitor the large number of oil and gas wells is needed. These workers need to
coordinate with management and make sure that all of the machines function smoothly and perform
efficiently. These workover operations need to be logged daily, and the logged data is required to get
weekly, monthly, and yearly reports. Many of the workers in the oil and gas fields may not have
internet access to log these workover records. The network access near the oil fields may also be
unavailable due to safety regulations. Due to these reasons, logging mechanisms are needed to work in
both connected and disconnected environments. Moreover, a proper synchronization mechanism is
needed to coordinate between these two environments, especially when workers move from
disconnected to connected environments.

With so many oil and gas wells across the world, many companies operate in the oil and gas services.
One of the leading companies is Halliburton, which operates in countries all over the world [3]. As a
leading company in the oil and gas industry, comprehensive and efficient technologies are needed.
This is what Landmark provides. “Landmark, a Halliburton business line, is the leading technology
solutions provider” [4]. One software which helps with recording data from oil and gas fields from
Landmark is the OpenWells application.

1.2 OpenWells iOS Application

The OpenWells iOS application was created for managing Halliburton’s workover operations. It
allows an oil and gas field worker to manage and record every workover data on a daily, weekly, and
monthly basis. The data can be entered in a connected or disconnected environment. Currently, the
OpenWells iOS application by Landmark works only on iPads and other similar iOS devices. This
means that workers with Android or Windows devices are unable to use this application. Because of
this, the Techno Sharks team was asked to create a similar application which is capable of running on
any of the three major platforms (iOS, Android, and Windows). In order to reduce confusion in this
report, the original application (by Landmark) will be referred to as the OpenWells iOS application and
the project created by the Techno Sharks will be referred to as the OpenWells Cross-Platform

1
application. To be able to work on multiple platforms, Microsoft’s Xamarin provides a mature
development environment to create cross-platform applications.

1.3 Xamarin and Xamarin.Forms

Xamarin is a cross-platform mobile application development tool based upon shared C# codebase [5].
It can be used as an extended feature to Microsoft Visual Studio or it can be used on a Mac OS via
Xamarin Studio [5]. Xamarin.Forms is a cross-platform User Interface (UI) toolkit provided by
Xamarin [6]. There are two ways to write code in Xamarin.Forms. First, it supports Extensible
Application Markup Language (XAML), which is used for the UI design, and C# as the code behind
XAML [6]. Second, it also supports a codebase using simple C# code to automatically generate the UI
[6]. The Techno Sharks team will be using the codebase method in Xamarin.Forms for this project.

2 Requirements
Before the coding can begin for a project, an in-depth Requirements analysis should be performed to
determine the Business, Functional, and System requirements. The Business requirements should
identify the high-level expectations for the project. The Functional requirements are the lower level
requirements that identify how each Business requirement is accomplished. And the System
requirements specify the hardware and software necessary to complete the project.

2.1 Business Requirements

First, this project should create an Android application that can manage well workover tasks and
functions using cross-platform technology. An iOS application already exists, but it cannot be used for
Android and Windows platforms.

Second, the application should allow the well workers (the user for this application) to enter well
workover information on a daily basis. The input of daily information from the well worker collects
the data necessary for efficient management of the well workover data.

Third, the application should function in both a connected or a disconnected environment. Well
workers perform their tasks out in the field, and they need to be able to input their data even if there is
no connection to a network.

2
Next, the application should sync with the Engineers Data Model (EDM) Database, which is the
Halliburton/Landmark corporate database. The EDM Database is the corporate database that should
house all of the well data collected by the application. Furthermore, the EDM Database should also
supply well information to the application.

The application should also allow the well workers to view well workover data. This would include
any data entered by the well worker in the past as well as any well data retrieved from the EDM
Database. This way, the well worker is also able to view and review well workover data.

Finally, information about a well worker should be tied to the data input into the application. This
allows for better management and organization of the well workover data.

The full Business Requirements are shown in Table 2-1.

BR1 Develop an application that can manage oil well workover tasks and functions
similarly to the Landmark OpenWells iOS application for the Android platform.
BR2 User should be able to input daily oil well workover task information.
BR3 User should be able to enter data in a connected or disconnected environment.
BR4 Application should sync with the EDM Database.
BR5 User should be able to view data entered in the past or obtained from EDM
Database.
BR6 User information should be tied to the submitted data.

Table 2-1: Business Requirements

2.2 Functional Requirements

In order to satisfy the cross-platform business requirement, Xamarin should be used. The
Xamarin.Forms library allows for development on the iOS, Android, and Windows platform, and using
C#. This would allow for the development of an Android application with the capability of being
cross-platform for iOS and Windows. These requirements are shown in Table 2-2.

BR1 Develop an application that can manage oil well workover tasks and functions
similarly to the Landmark OpenWells iOS application for the Android platform.
FR1.1 Application should be developed in Xamarin with cross platform
capabilities for both iOS and Android using the Xamarin.Forms library.

Table 2-2: Business Requirement 1 and Associated Functional Requirements

3
Since the application should allow well workers to enter data on a daily basis, the application should
allow for numerical data with value limits, textual data for both data and comment fields, and data
entry using graphical interfaces, like radio buttons and switches. Additionally, the application should
allow for uploading of attachments for media files or documents. And finally, the user should also be
able to delete any data that was entered to be able to correct any mistakes. The described requirements
are shown in Table 2-3.

BR2 User should be able to input daily oil well workover task information.
FR2.1 Application should allow numerical data entry with value limits.
FR2.2 Application should allow textual data entry for both data and comment
fields.
FR2.3 Application should allow user to input information via radio buttons and
switches.
FR2.4 Application should allow user to delete entered data.
FR2.5 Application should allow user to attach a media file or document.

Table 2-3: Business Requirement 2 and Associated Functional Requirements

For the application to function in a connected or disconnected environment, the application should be
able to detect the type of environment (connected or disconnected). Since the environment for a well
worker can change, the application should be able to save and store data locally on the device
regardless of the environment. These requirements are shown in Table 2-4.

BR3 User should be able to enter data in a connected or disconnected environment.

FR3.1 Application should be able to detect if it is in a connected or disconnected
environment.
FR3.2 Application should save and store data locally on device in both connected
and disconnected environments.

Table 2-4: Business Requirement 3 and Associated Functional Requirements

When in a connected environment, the application should be able to sync with the EDM Database. The
application should be able to send saved and stored data to the EDM Database, as well as pull data
from the EDM Database for display in the application. Additionally, the application should allow for a
manual syncing with the EDM Database whenever the user would like, if in a connected environment.
The described requirements are shown in Table 2-5.

4
 BR4 Application should sync with the EDM Database.
FR4.1 Application should send stored data to EDM Database if it is in a connected
environment.
FR4.2 Application should receive data from the EDM Database if it is in a
connected environment.
FR4.3 Application should allow manual syncing of data to the EDM Database with
a “Sync” button.

Table 2-5: Business Requirement 4 and Associated Functional Requirements

Since the application should also display data, the user should be able to generate PDF reports and
view the data in different views, filtered by day, month, or year. Additionally, the application should
be able to display diagrams and maps, like Well Bore schematics or a map of the current area using the
GPS of the device. These requirements are shown in Table 2-6.

BR5 User should be able to view data entered in the past or obtained from EDM
Database.
FR5.1 User should be able to generate a PDF report with details of daily tasks.
FR5.2 User should be able to view past data within the application.
FR5.3 Application should display views of the data filtered by “All”, “Year”,
“Month”, and “Day”.
FR5.4 Application should display Well Bore schematic data obtained from the
EDM Database.
FR5.5 Application should display a map of the current area via device GPS.

Table 2-6: Business Requirement 5 and Associated Functional Requirements

In order to tie the user information to the data entered, the application should identify the user
whenever the application is installed on a device. The user information should also be available via the
device settings, in case a change in the user information is needed. The described requirements are
shown in Table 2-7.

BR6 User information should be tied to the submitted data.

FR6.1 User information should be tied to the device settings.
FR6.2 Application should identify the user for a specific device the first time a
well is downloaded.

Table 2-7: Business Requirement 6 and Associated Functional Requirements

5
 2.3 System Requirements
For the System Requirements, there are both software and hardware components. For the software,
Xamarin Open Source and Visual Studios is needed for the software development. The XCode
Integrated Development Environment (IDE) is needed in case the source code for the OpenWells iOS
application is needed to assist with the software development. Microsoft Office products, Notepad++,
and Adobe Acrobat are also needed to assist with documentation, presentation, and code reviews.
These requirements are show in Table 2-8.

SR1 Xamarin Open Source

SR2 XCode IDE
SR3 Visual Studios (compatible with Xamarin Open Source)
SR4 MS Office
SR5 Notepad++
SR6 Adobe Acrobat

Table 2-8: Software Requirements

For the Hardware components, a computer capable of running the Xamarin Open Source software
installed is needed. Additionally, both an Android and iOS tablet with GPS will be needed for testing
purposes. Finally, an Apple computer capable running XCode IDE is needed. The described
requirements are shown in Table 2-9.

HR1 Windows computer with Xamarin Open Source installed.

HR2 Android device with GPS.
HR3 Apple computer capable of viewing OpenWells application source code.
HR4 iPad tablet with GPS capable of running the Landmark OpenWells application.

Table 2-9: Software Requirements

6
3 System Details
3.1 Design
3.1.1 Initial Application Design
The OpenWells Cross-Platform application was supposed to be similar to the OpenWells iOS
application, so the system architecture was very similar. As shown in Figure 3-1, there were three
major components to the design, the Mobile Application, the Web Service, and the EDM Database.

The Mobile Application component contained the User Interface (UI) pages that a user interacts with
on a mobile device. The Well Selection Page allowed the user to select from different wells. The Data
Entry Pages allowed the user to enter pertinent workover data for a specific well. The Data Display
Pages displayed information, either entered by the user or obtained from the database. Additional
pages allowed for different views, allowing for easier navigation in the application.

The Web Service component connected the application UI with a centralized database. The Web
Service required an existing internet connection from the mobile device, and allowed for pushing and
pulling data from a database.

The EDM Database was the centralized database to which all instances of the application connect. This
database already existed, and did not need to be created. This particular database was the
Halliburton/Landmark corporate database, which contained all of the well workover data. All data
entered via the application UI will be stored in this database. Additionally, other well data would be
available in the database, which could be displayed in the application.

7
 Mobile Application (Xamarin/Android)

Well Selection Page Data Display Pages

Report Map Wellbore

Application Background Generatio Location Schematic
n Display Display

Data Entry Pages

View Pages
Daily Ops Info Test Info

Casing Info Failures Info Daily View Year View

Cementing Info Logging Info Monthly All View

View
Perforation Info Material
Transfer Info Description Pages
Pipe Tally Info

Stimulation Info
Drill Stem Event Well Bore Well
Wellbore Eq. Test Info Descriptio Descriptio Descriptio
Info n n n

Web Service EDM

Database

Figure 3-1: Application System Architecture

8
 3.1.2 Updated Application Design with Conversion
Due to the similarities between the OpenWells Cross-Platform application and the OpenWells iOS
application, it was determined after the design phase that a conversion of the OpenWells iOS
application would be more efficient. Thus, the design and architecture changed slightly, as can be seen
in Figure 3-2. The EDM Database component stayed the same, and the Sync Engine component is
synonymous with the Web Service component. The differences were the Entry Forms conversion, the
Data Model conversion, and the Realm Xamarin Database.

Figure 3-2: Application Conversion Architecture

The Entry Forms, otherwise known as the application UI pages, already existed in the OpenWells iOS
application. So, instead of re-creating the pages, the data was exported from the iOS application into an
XML file. Thus, instead of creating new UI pages, a parsing and conversion of the Entry Form XML
file could be used to create the UI pages.

Similarly, a Data Model already existed with the OpenWells iOS application. The Data Model was
then exported from the iOS application into a different XML file. This Data Model XML file could
also be parsed and converted into the Data Model classes used in cross-platform version of the
application.

9
Finally, a local database residing on the mobile device would need to be created in order to hold the
data locally. It was determined that a Realm Database could be used in a cross-platform setting. The
local Realm Database would store data entered by the user before syncing with the EDM Database.

3.2 Implementation
As discussed above, there were five components to the updated application design. The EDM Database
already existed, and did not need to be implemented. Thus, the four components that needed to be
implemented were the Entry Forms, the Data Model, the Realm Database, and the Web Service. With
the full implementation, the OpenWells Cross-Platform UI pages could push/pull data to/from the local
Realm Database, and then push/pull data to/from the EDM Database. This covered the primary
functionality of the OpenWells Cross-Platform application that the Techno Sharks set out to
accomplish.

Due to time constraints, the Techno Sharks team decided to only implement one main branch in the
OpenWells Cross-Platform application, the “Daily Operations” branch. It was more efficient to focus
on a single branch, and once the single branch was successful, the other branches could then also easily
be implemented.

3.2.1 Data Model Implementation

The Data Model implementation started with the Data Model XML file that was exported from the
OpenWells iOS application. Then, this XML file would be read, parsed, and converted to C# classes
which could be used by the Xamarin.Forms application.

A standalone C# application was created, which would read and parse the Data Model XML file using
the C# System.XML and System.IO libraries. This C# application would then export out a C# file with
all of the necessary Data Model classes needed in the Xamarin.Forms project. In order to do the
conversion correctly, each Data Model class and property had a variety of meta-data. In order to
accurately and correctly capture the meta-data, data annotations had to be used. Once implemented, the
data annotation information can be accessed using reflection functions.

3.2.2 Realm Implementation

The next step was to implement the local Realm Database. The first step was to use the Realms library
by importing the Realm NuGet package. Once imported, then the Data Model classes could all be sub-

10
classed to the RealmObject class. This allowed the mobile device to create a local Realm Database,
based upon the application data model.

The next steps were to create functions that could push data from the UI pages to the Realm Database
and also pull data from the Realm Database to display on the UI pages. A OpenWells_RealmLayer
class was created for the Xamarin.Forms project, and this included the necessary Realm functions,
pushToRealm(…) and pushToUI(). Dictionary objects were used to make the transfer of data to/from
the Realm Database easier. The pushToRealm(…) function used the Realm Write() function to push
data from the UI to the Realm Database. And the pushToUI() function used the Realm All() function to
read data from the Realm Database.

3.2.3 Web Service Implementation

The final component to implement was the Web Service component, which connected the OpenWells
Cross-Platform application to the EDM Database. In order to make the connection, the WebClient
class in the System.Net library was used. The EDM Database URL, username, and password were all
provided by the Techno Shark team mentor.

The EDM Database stored data as JavaScript Object Notation (JSON) objects with a specific format. It
was determined that the JSON object had three sections, the UpperJSON, LowerJSON, and
MiddleJSON. The UpperJSON and LowerJSON did not change for a specific data object instance, and
so that information was hard-coded in the OpenWells_EDMLayer class of the Xamarin.Forms project.
Only the MiddleJSON section needed to be manipulated to obtain (Get) and submit (Put) data to the
EDM Database. Thus, the giveMiddleJsonToEDM(…) and getMiddleJsonFromEDM(…) functions
were also created in the OpenWells_EDMLayer class.

The next step of the WebService was to connect the local Realm Database with the EDM Database
using the giveMiddleJsonToEDM(…) and getMiddleJsonFromEDM(…) functions. Back in the
OpenWells_RealmLayer class, the realmToEDM() and pullFromEDM() functions were created. The
realmToEDM() function was able to convert a Realm object to JSON, and then push to the EDM using
the OpenWells_EDMLayer functions. The pullFromEDM() function was able to use functions in the
OpenWells_EDMLayer class to obtain a JSON object, and then convert it to a Realm object.

The last step was to include a way to determine if a viable internet connection was available. The
Connectivity Plugin for Xamarin and Windows NuGet package was found which could test for internet
connectivity. Since the OpenWells Cross-Platform application needed to successfully operate in both a
11
connected and disconnected environment, the connectivity check was implemented. If connectivity
was detected, then the functions would connect the Entry Form UI to the Realm Database to the EDM
Database. If no connectivity was detected, then the functions would only connect the Entry Form UI to
the Realm Database.

3.2.4 Entry Form Implementation

The Entry Forms implementation was similar to the Data Model implementation. First, the Entry Form
XML file was exported from the OpenWells iOS application. Since all the necessary information was
included in the XML, Xamarin.Forms content pages could be created to display all of the UI pages.

First, the XML file was read and parsed using C# System.XML and System.IO libraries. Once this
information was parsed, it could be used to create Xamarin.Forms content pages that could display the
Entry Forms as cross-platform UI pages. The TableView UI class for was used to display the pages. A
C# standalone application was created which successfully create a Xamarin.Forms content page using
TableView for each UI page for the application. Then the Xamarin.Forms content pages were able to
be displayed in the cross-platform application.

Even though the implementation of the UI pages was successful using the Xamarin.Forms TableView
class, it was discovered that the TableView class did not easily implement data binding. Since the
application serves mainly as a data entry application, data binding was deemed important as changes to
the data should be easily reflected. Thus, the team decided to re-implement the Entry Forms using the
Xamarin.Forms ListView class instead, which included built-in data binding. The XML reading and
parsing was not changed. However, with the ListView class, Section Headers, Cell Templates, and
Cell Template Selectors had to be implemented. Further implementation work resulted in
Xamarin.Forms content pages that displayed the application UI pages using ListView.

One more issue with the Entry Forms was discovered. The Xamarin.Forms content pages were all
generated by the C# application, and then each content page was then manually added to the
Xamarin.Forms project. This meant that if there was a change to the XML file, then a new converted
content page would have to be generated, and then added to the project. After discussions with the
mentor, it was decided that an easier method would be to dynamically generate the content pages from
within the Xamarin.Forms project. The C# application would no longer be needed, as the XML file
could be embedded within the Xamarin.Forms project. The final step was then creating a generic
Xamarin.Forms content page that pulled information from the XML file, depending what was needed.

12
 3.3 Testing and Verification
Once all components described above were implemented, the OpenWells Cross-Platform application
needed to be tested and verified.

For testing, an Android Virtual Device and an Android Asus K010 tablet were both used. First, the
dynamic generation of the Xamarin.Forms content pages were tested by navigation of all the pages.
Then, the Data Model component was added, and the content pages were able to be bound to the Data
Model. This was tested by having the content page display texts come from the Data Model. Next, both
the Realm and Web Service components were added. These components were tested by implementing
the Push and Pull button functionality. The Push button sent user input data from the application UI to
the Realm Database, and if connectivity existed, then sent the data from the Realm Database to the
EDM Database. The Pull button tried to pull data from the EDM Database to the Realm Database to
the UI if connectivity existed. If not, the Pull button would only pull data from the Realm Database to
the UI. The behavior of Push and Pull buttons were tested by pushing and pull data with the WiFi
enabled and disabled.

For verification, the Techno Sharks team needed to see that data from the OpenWells Cross-Platform
application sent to the EDM Database could be access by another application, including the OpenWells
iOS application. The verification was performed with the OpenWells Cross-Platform application on
the Android tablet and the OpenWells iOS application on an iPad. Again, the behavior of Push and
Pull buttons were tested by pushing and pulling data with the WiFi enabled and disabled.
Successful testing and verification were performed by the Techno Sharks team during a demonstration
during the Final Techno Sharks Presentation.

4 Project Management
The Techno Sharks team was made of four team members. The main role of each team member was
split as follow:
 Project manager: Rou’a Aldalqamouni
 Technical lead: Daniel Wang
 Presentation and Website lead: Shreyas Makde
 Documentation lead: Madhavi Potluri
13
All team members contributed to the overall development process, with each person taking care of
his/her responsibilities based on their associated role. The OpenWells Cross-Platform application was
implemented using Agile and scrum software methodology. The project was divided into small,
complete pieces/functionalities to be implemented.

4.1 Project Timeline

As shown in Figure 4-1, the project duration was ~15 weeks, starting from August 24, 2016 and ending
on December 10, 2016. The time given to each task was based of the complexity of implementing the
specific task.

Figure 4-1: Project Timeline, Page1

14
 Figure 4-2: Project Timeline, Page 2

There were five main stages of OpenWells Cross-Platform application development process:
 Requirements analysis (Figure 4-1): This task took 13 days to complete and the output was the
Initial Technical Report. This task included three subtasks:
o Research and analyze the project requirements (Functional/Non-Functional).
o Determine the resources needed for the development process.
o Establish the Business requirements of this application.
 Design (Figure 4-1): This task took 25 days to complete and consisted of two main parts:
o Perform analysis of the Data Model architecture.
o Perform analysis of the Entry Forms.

15
  Implementation (Figure 4-1 and Figure 4-2): This stage took 33 days to complete and consisted
of two main parts:
o Develop C# code for project. This included conversion of the Data Model from XML to
C# classes, implementation of the Realm Database, and implementation of the Web
Service.
o Develop Xamarin.Forms code for Entry Form pages. This included development using
TableView and ListView, and dynamically creating Entry Form pages from the XML
file.
 Integration (Figure 4-2): This stage took 5 days. This took all components from the
implementation stage and integrated them into a single application.
 Testing (Figure 4-2): This stage took 3 days. The OpenWells Cross-Platform application
targeted functionality on the Android platform. iOS and Windows testing would be
implemented if time was available.
Project timeline also consisted of some tasks that were needed for the development process, such as
familiarization with Xamarin and Xamarin.Forms as a development tool for the application.
Additionally, the project timeline included some tasks outside of code development such as,
presentation and paper preparations.

4.2 Task Division

Tasks were divided among the team members as leads, but every member contributed to each task.
This was done to make sure that all team members learned about the new technologies and were
knowledgeable of all the functionality in OpenWells Cross-Platform application
The task leaders were divided as follow:
 XML Data Model Conversion: This task was to convert the XML Data Model file generated
from the OpenWells iOS application into C# classes. All team members worked on this task
with Shreyas Makde as the lead.
 Realm Database Implementation: This task was to research and learn about Realm
Databases. Then, this task was to implement the Realm Database with the OpenWells Cross-
Platform Data Model. All team members worked on this task with Rou’a Aldalqamouni as the
lead.

16
  Web Service Implementation: This task was to determine how to connect the OpenWells
Cross-Platform application to the EDM Database. All team members worked on this task with
Madhavi Potluri as the lead.
 XML Entry Forms Conversion: This task was to convert the XML Entry Form file generated
from the OpenWells iOS application into Xamarin.Forms content pages. All team members
worked on this task with Daniel Wang as the lead.
 Integration: This task was to take all implementation components and integrate into a single
application. All team members worked on this task with Shreyas Makde and Madhavi Potluri
as the leads.
 Testing: This task was to determine a way to test and verify all functionality. All team
members worked on this task with Rou’a Aldalqamouni and Daniel Wang as the leads.

5 Conclusion
5.1 Project Summary
The Techno Sharks team successfully implemented the one branch of the OpenWells Cross-Platform
application as planned. In order to create a working product, the team decided to focus on function
over form, meaning that most of the project resources were focused on making the application function
as detailed in the Requirements.

The team was able to learn and use the new technologies of Xamarin, Xamarin.Forms, Realm
Database, and Web Service to a corporate database using JSON objects. Each of these new
technologies had to be researched, learned, and implemented in a short amount of time. Additionally,
the Techno Sharks team also learned about all the components necessary for a successful project,
including research, requirements analysis, design, planning, presentations, demonstrations, and
technical papers.

The major goal for the Techno Sharks team was to implement a cross-platform application. This was
accomplished using Xamarin, and the resulting application was able to be run on both Android and
iOS platforms.

17
 5.2 Lessons Learned
At the end of the project, there were two major lessons learned, one involved with project planning and
the other involved with time management.

When the Techno Sharks first investigated the project, it was determined that a new application had to
be created. The Design and Project Planning phases were all created assuming that a new application
would need to be created from scratch. Later, it was discovered that since another application (the
OpenWells iOS application) was so similar, much of the information could be re-used. This caused the
Design and Project Planning phases to be updated to reflect a new paths which incorporated
conversions from the iOS application. Even though changes were often unavoidable, the Techno
Sharks team learned that doing more research at the beginning of a project could save more time later.

The other major lesson learned by the Techno Shark team was with regards to time management. As
with many projects, the initial time estimation did not match up with the actual time needed. The
Techno Sharks team initially thought that the entire OpenWells Cross-Platform application could be
completed within a semester. However, the team soon realized that it was not possible, and the team
had to choose specific parts of the project to focus on. In the end, the Techno Sharks team decided to
focus only on one branch of the project (the Daily Operations branch), and to implement as much
functionality as possible for that single branch. This ended up being the right decision, as the Techno
Sharks were able to deliver an application that saw almost full functionality of the Daily Operations
branch.

5.3 Roadblocks
Although the Techno Sharks team were successful, there were many roadblocks along the way. Three
major roadblocks identified were with Xamarin software installation, cross-platform library
implementation, and interactions with a corporate database.

The Xamarin software installation took much longer than expected. Due to a variety of compatibility
issues, much troubleshooting was necessary. The installation was attempted on multiple computers in
multiple environments. In the end, it was only successfully installed on three computers. The extra
time spent troubleshooting and installing Xamarin delayed other parts of the project.

With regards to cross-platform library implementations, there were two options: Portable Class Library
(PCL) and Shared Library. The PCL implementation is a way to share code between different

18
platforms, and is more efficient since a single set of code can work for multiple platforms. Shared
Library implementation allows for more customization at the cost of more code using compiler
directives, which tells the compiler which code to use for a specific platform. This means that there can
be three different sections of code for three different platforms. Maintenance of code using Shared
Libraries can become complicated due to the additional code. Thus, PCL is the recommended
implementation. However, not all libraries have full compatibility with PCL, and it was determined
that the Realm library was easier to implement with Shared Library. So, the OpenWells Cross-Platform
application was implemented with Shared Library.

The interactions with the EDM corporate database also caused some roadblocks. The EDM Database
stored data as JSON objects, but there was difficulty in determining what parts of the JSON object
were allowed to be modified. It required extensive testing and assistance from the Techno Sharks team
mentor in order to successfully determine how to manipulate the JSON objects in the EDM Database.

5.4 Future Work

As stated before, the OpenWells Cross-Platform application is not complete. The Techno Sharks team
successfully implemented one branch, along with the full Push and Pull functionality. This means that
there is much future work.

The other branches still need to be implemented. The other branches function similarly to the Daily
Operations branch, which was already implemented. The Daily Operations branch implementation can
be expanded to include the other branches.

The relationships between the classes in the Data Model were also not implemented. Additional tweaks
to the Data Model will need to be made, but this should help with making the code operate more
efficiently.

The Entry Form UI look and feel will need to be improved. Additionally, since this application is
cross-platform, the UI will need to be adjusted for each platform to look uniform. Since the focus of
the Techno Sharks team was on functionality, there is a lot of work to be done here.

Other smaller functionalities have not been implemented by the Techno Sharks team, such as map and
GPS, schematics, PDF report generation, attachments, and spreadsheets implementation. Each of these
can be added to the existing project and will add to the usability of the full application.

19
6 References
6.1 Paper References
[1] Tippee, Jessica. 2012. Gas field developments progressing offshore Venezuela. Retrieved
from http://www.offshore-mag.com/articles/print/volume-72/issue-7/latin-america-report0/gas-
field-developments-progressing-offshore-venezuela.htm

[2] Oil & gas jobs. Retrieved from https://www.newzealandnow.govt.nz/work-in-nz/nz-jobs-

industries/oil-gas-jobs

[3] Halliburton. Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Halliburton

[4] Halliburton Landmark. Retrieved from https://www.landmark.solutions/About

[5] Building Cross Platform Applications. Retrieved from

https://developer.xamarin.com/guides/cross-
platform/application_fundamentals/building_cross_platform_applications/

[6] Xamarin.Forms. Retrieved from https://www.xamarin.com/forms

6.2 Coding References

 Hermes, Dan. 2015. Xamarin Mobile Application Development: Cross-platform C# And
Xamarin.Forms Fundamentals. APress.
 Xamarin.Forms. Retrieved from https://developer.xamarin.com/guides/xamarin-forms/

6.3 API/NuGet Packages Used

 Json.NET
 Realm
 Connectivity Plugin for Xamarin and Windows

20
7 Appendix
7.1 System Manual
Installation instructions for Xamarin Studio, which is an IDE designed for Mac OS computers.
Xamarin Studio installation is downloadable from the Xamarin website. The process requires proper
synchronization of Android SDK (Software Development Kit), NDKs (Native Development Kit), and
JDKs (Java Development Kit). Once we install Xamarin we need to make sure that these development
kits are recognized by the IDE. This can be assured by navigating to Xamarin Studio > Preferences >
Projects >SDK Locations > Android

Figure 7-1: Xamarin SDK, JDK, and NDK

If the green checkmark is missing, make sure you download and install these components separately
(as seen in Figure 7-1).
If a virtual device is to be used for testing purposes, then the Android Virtual Device (AVD) manager
must be started and configured. This is launched by selecting Tools > Google Emulator Manager.

21
 7.2 User Manual
For the OpenWells Cross-Platform application, three third-party NuGet packages were installed. These
packages will need to be installed on both Android and iOS subfolders (and Windows as well if you
are working with this platform). Since the project template type is Shared Library, common files are
shared through two separate project files in the solution (three if we include Windows Phone OS).
The three packages that we have to install are
 json.NET
 Realm
 Connectivity for Xamarin and Windows.

Button Functionality:
 Pull – If there is connectivity, this will pull data from EDM to Realm, and then Realm to the
UI. If there is no connectivity, will only pull data from Realm to the UI.
 Push – This will push data from the UI to Realm, and if there is connectivity, will also push
data from Realm to EDM.
 Pull Only From Realm – This will only pull data from Realm to the UI. This is used for testing
purposes.
 Push Only To Realm – This will only push data from the UI to Realm. This is used for testing
purposes.
Navigation:
The content pages are all display as Navigation pages, so there will always be a “Back” arrow
to get to the previous page.
There are 4 types of Display text:
 Section Label: Only displays a label of the section.
 TextCell Field Label: These act as buttons to go to another content page.
 EntryCell Label: These provide a description of the Entry Cell.
 SwitchCell Label: These provide a description of the Switch.

Figures 7-2, 7-3, 7-4, and 7-5 include some additional screenshots of the OpenWells Cross-Platform
application.

22
Figure 7-2: Root Page of OpenWells Cross-Platform Application

Figure 7-3: Main Page of Daily Operations Branch

23
Figure 7-4: Contacts Page of Daily Operations Branch

Figure 7-5: Status Page of Daily Operations Branch

24