OpenWells Cross-Platform Application

Capstone Project: CSCI 6838.04

December 10, 2016

Mentors:

David Crawshay

Halliburton

Email: david.crawshay@halliburton.com

Olivier Germain

Halliburton

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

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

2

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.

3

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

4

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.

5

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

6

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

7

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.

8

Figure 3-1: Application System Architecture

Web Service EDM

Database

Mobile Application (Xamarin/Android)

Well Selection Page

Application Background

Data Entry Pages

Daily Ops Info

Wellbore Eq.

Info

Test Info

Failures Info Casing Info

Cementing Info Logging Info

Perforation Info Material

Transfer Info Pipe Tally Info

Drill Stem

Test Info

Stimulation Info

Data Display Pages

Report

Generatio

n

Map

Location

Display

Wellbore

Schematic

Display

View Pages

Monthly

View

Year View

All View

Daily View

Description Pages

Event

Descriptio

n

Well Bore

Descriptio

n

Well

Descriptio

n

9

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.

10

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-

11

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

12

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.

13

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

14

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

15

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.

16

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.

17

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.

18

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

19

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.

20

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

21

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.

22

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.

23

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

Figure 7-3: Main Page of Daily Operations Branch

24

Figure 7-4: Contacts Page of Daily Operations Branch

Figure 7-5: Status Page of Daily Operations Branch