Borrow: An Android Appjmgphd.com/wp-content/uploads/2019/06/borrow_report.pdf · CS701 Final Project Report Borrow: An Android App Claudia Lu Middlebury College Middlebury, VT [email protected]

CS701 Final Project Report

Borrow: An Android App

Claudia LuMiddlebury College

Middlebury, [email protected]

ABSTRACTAmericans owed billions of dollars to their friends and fam-ilies [2]; however, there wasn’t an easy way for lenders toensure that the borrowers would pay back their debts bythe date they promised to repay by. Borrow aimed to pro-vide a platform where friends could borrow and lend moneyamong each other with ease and peace of mind.

The objective of this project was to create an app wherea user could post a borrow request that included the reasonof his request, the amount he was requesting, the date hepromised to pay back by, the installment option he wouldlike to use, and the interest rate (if any) he would like tooffer to his lenders. His post would then become publicon his friends’ feeds for them to contribute towards. If hesuccessfully raised money from his friends, he could cash outimmediately, and he would receive periodic reminders in theform of phone notifications through his borrowing period,reminding him of the amount that he currently owed and hispromised repayment date. If he did not pay back his debtby the midnight of his repayment date, then the app wouldautomatically withdraw the money from his associated bankaccount.

The final result of this project was an Android app, whereusers could register, login, set up display names and pro-file pictures, post borrow requests, comment on borrow re-quests, and lend toward borrow requests. Whenever theuser lent towards a borrow request, funds will be taken outof his credit or debit card and sent to the borrower’s creditor debit card. At the midnight of the borrower’s originalpromised repayment date, if he had not paid back his debtyet, his debt (including the interest rate he promised) wouldthen be automatically taken out of his credit or debit card.The functionalities of this app were made possible throughAndroid Studio, NodeJS, Firebase, and Stripe.

KeywordsAndroid; Firebase; NodeJS; Stripe; P2P-lending; Fintech;

1. INTRODUCTIONAsking your friends and families for money was awkward,

but Americans would do it anyway. As of now, Americansowed an estimate of $184 billion to their friends and fami-lies [2]. To put that number into scale, the entire music in-dustry in the US generated a revenue of 17.2 billion dollarsin 2016 [4]. These peer-to-peer lending activities were es-pecially common among millennials, especially the youngerones–survey showed that millineials in their 20s were more

willing than any other age group to lend money to theirfriends and families [3]. But if you have ever lent yourfriends anything, not even just money, you know the hard-est part about this process is having to, after a week, ora month, or however long you and your borrower initiallyagreed upon, go up to him and ask for that item back.

So by now, we knew people, especially young people, werelending and borrowing money to and from each other, andwe knew it was a pain to have to go up to your friend and“remind” him on the day that he originally promised to payyou back by. Therefore, we wanted to build an app thatalleviated this pain. Borrow would send the borrower no-tifications throughout his borrowing period, but especiallyduring the last of couple of days before his money was due,and if he continued to not pay back his debt, the app wouldautomatically draw the correct amount of money from hisbank account on his original promised repayment date anduse the repayment to pay out his lenders.

In this paper, we will explain why we believed Borrow tobe something that its target audience–Americans who werein their 20s–wanted, by laying out the pain that it aimedto alleviate. We will look at existing platforms and systemsthat led us to believe that Borrow was a fintech that waswanted by its target audience. We will then walk throughthe methods and technologies we have used to bring Bor-row into life–Firebase, Stripe, NodeJS, and Android Studio.After that, we will demonstrate our end result through aseries screenshots of the app. Finally, we will discuss ourtakeaways from this project and our plans for the future.

2. PROBLEM STATEMENTThe problem we were attempting to solve through this

project was the pain that our target users faced when theylent money to or borrowed money from their friends. Fromthe Graph 1 shown below, we could see that 20-somethings,our target users, were more comfortable with lending moneyto and borrowing money from their friends than any otherage group. With this knowledge in mind, we added theassumption that even though 20-somethings were more will-ing than any other age group to lend to and borrow fromfriends, the pain and awkwardness that come with talkingabout money with one’s friends still existed for them. Withthese knowledge and assumption in mind, we decided thata mobile app that would make their borrowing and lendingexperience less awkward was needed.

Graph 1: Percentage breakdown of people who have bor-rowed money from friends and families before [3]

3. RELATED WORKThis project was inspired by various existing platforms.

The popularity of money-transaction platforms such as Venmoand Cash App demonstrated to us our target users’ desireand need to send and receive money with ease and speed;the existence of micro-loaning systems such as the rotatingsavings and credit association proved to us the ubiquity ofpeer-to-peer lending activities; the success of crowdfundingplatforms such as Kickstarter and GoFundMe proved thatour target users were willing to ask for help as much as theywere willing to give help; the popularity of public platformssuch as Instagram and Facebook proved to us that our tar-get users enjoyed the ability to “like” and be “liked,” evenfrom people across the internet. Inspired by the successes ofthese existing platforms, we believed that an app that madethe lending and borrowing process as easy and painless as itwas to “like” someone’s Instagram photo or “venmo” some-one money was needed by our target users.

Money-transaction platforms such as Venmo and CashApp have made sending money across the internet as easyas it was to send a text message. Because of the existenceof these platforms, we barely remembered a time–not thatlong ago, when funds took multiple days to transfer be-tween different bank accounts when they were under thesame bank and even longer when they were controlled bydifferent banks. Now that money could be transferred withease and speed, it was time to build an app that would allowmicro-loans to be transferred with the same amount of easeand speed.

Because of the popularity of systems such as the rotat-ing savings and credit associations (ROSCA), we knew thatpeer-to-peer lending activities were popular, especially amongtight-knit communities with little savings. A rotating sav-ings and credit association was a group of individuals whoagreed to meet for a defined period in order to save andborrow together; it was a form of combined peer-to-peerlending. Meetings could be regular or tied to seasonal cashflow cycles. Each member contributed the same amount ateach meeting, and one member took the whole sum once.As a result, each member was able to access a larger sum ofmoney during the life of the ROSCA, and use it for what-ever purpose he wished. Rotating savings and credit asso-ciations could be found in the US as well as countries andregions all over the world, including Latin America, Swahili-speaking East Africa, West Indies, Mexico, Somalia, SouthAfrica, China, and many more [11]. Even though the target

audience for Borrow was 20-something Americans–an au-dience who was not necessarily engaged with the ROSCAsystem right now–the existence and popularity of ROSCAproved that peer-to-peer lending was extremely commonamong tight-knit communities with little savings, and webelieved that 20-something Americans, often with little sav-ings and existing in tight-knit communities, desired an es-tablished platform where they could engage in peer-to-peerlending as well. We wanted Borrow to be that platform.

We wanted to argue that the 20-something Americans’ de-sire to engage in peer-to-peer lending activities can alreadybe seen in the successes of crowdfunding platforms such asKickstarter and GoFundMe. Over $601 million were raisedon Kickstarer in 2017 [8]; over $140 million were raised onGoFundMe every month [6]. The popularity of Kickstarterproved young Americans’ increasing desire to borrow moneyfrom their peers instead of from the bank. The popularity ofGoFundMe proved that Americans were equally as willingto ask their peers for financial help as they were willing togive their peers financial help.

Some scholars have even proposed that one of the reasonswhy Kickstarter and GoFundMe have become so popularwas the neurobiological reward that our brain received when-ever we gave help or received help [1]. This neurobiologicalreward also explained our addiction to social media plat-forms such as Instagram and Facebook–studies have shownthat we got a dopamine drip whenever we received a “like”on Instagram [7]. If our target users could be incentivizedto use Instagram for the digital “likes,” we believed they canalso be incentivized to use Borrow for the actual money theywould be able to raise.

Because of these existing platforms, we concluded thatBorrow was needed. We believed that, now that transferringmoney could be made painless and instant through Venmoand Cash App, and that funds could be raised through Kick-starter and GoFundMe, it was time to make peer-to-peerlending just as easy and painless.

4. METHODS

4.1 FirebaseIn building this project, we used Firebase Authentication

to handle user sign up and sign in, Firebase Database tostore user information (first name, last name, location, andurl of the user’s current profile picture), and Firebase Stor-age to store the user’s current profile picture.

4.1.1 Firebase AuthFirebase Auth was a service that could authenticate users

using only client-side code. It supported a user manage-ment system whereby developers could enable user authen-tication with email and password login stored with Fire-base [5]. Whenever a user tried to register a new accountfrom the Android app’s user registration page, a requestwas sent to Firebase Auth, registering the email address andpassword provided as a new account on Borrow’s FirebaseAuth project.

4.1.2 Firebase DatabaseFirebase provided a realtime database and backend as

a service. The service provided application developers anAPI that allowed application data to be synchronized acrossclients and stored on Firebase’s cloud. The company pro-

vided client libraries that enabled integration with Android,iOS, JavaScript, Java, Objective-C, swift and Node.js ap-plications [5]. For Borrow, we integrated calls to FirebaseDatabase directly inside our Android app. Whenever a userset or updated his user information (first name, last name,location, or url of his current profile picture) from the user’ssettings page in the Android app, a request was sent to Fire-base Database, setting or updating the user’s informationstored in Borrow’s Firebase Database project.

4.1.3 Firebase StorageFirebase Storage provided secure file uploads and down-

loads for Firebase apps, regardless of network quality. Thedeveloper could use it to store images, audio, video, or otheruser-generated content. Firebase Storage was backed byGoogle Cloud Storage [5]. Whenever a user tried to set orupdate his profile picture through the user’s settings pagein the Android app, a request was sent to Firebase Stor-age, uploading the new photo to Firebase Storage. Then, arequest was sent to Firebase Database, changing the user’sprofile picture url to the url of the profile picture that wasjust uploaded.

4.2 NodeJS–Making CallsBorrow used a NodeJS backend, which was an open-source,

cross-platform JavaScript run-time environment that exe-cuted JavaScript code server-side [10]. Using the NodeJSbackend, Borrow was able to store all the borrow requestsand associated comments and lends into a database andmake calls to Stripe, which handled all the money trans-actions.

4.2.1 Stripe–Saving CardsStripe was a technology company that provided software

that allowed individuals and businesses to receive paymentsover the Internet. Stripe provided the technical, fraud pre-vention, and banking infrastructure required to operate on-line payment systems [12]. In order to allow Borrow to makecalls to Stripe, we had to register for a Stripe platform.Stripe assigned each registered platform a publishable keyand a secret key, which allowed us to store our users’ cardinformation in Stripe’s PCI compliant server and receive aStripe Token in return. However, even though Stripe Pay-ment could charge a card with just the Stripe Token, a Stripetoken could only be used once [13]. Therefore, we had tocreate a Stripe Customer object out of the Stripe Tokenreturned, because we intended to use the user’s card infor-mation more than once–we needed his card information onfile so we could pay him out or retrieve funds from him in thefuture when we needed to. Therefore, we stored the StripeCustomer object’s id into our database.

4.2.2 neDB–StorageBorrow used an neDB database to store all the borrow re-

quests, comments, and lends that have been posted throughthe Android app. NeDB was an embedded and lightweightNoSQL database that mimiced MongoDB. It left a smallamount of overall footprint on the system because it storedits data either in memory or in a plain text file [9]. Everytime a user tried to post a borrow request through the An-droid app’s Post page, a POST request was being made toNodeJS, resulting in a new borrow request being created inthe neDB. Each borrow request was made up of a userId

(the id given by Firebase to the user when he registered),a userName (the user’s first name, followed by a space, fol-lowed by his last name), a userProfileUrl (the url that led tothe user’s current profile picutre), an amount (the amountof money the borrow request was requesting for), an amoun-tRaised (the amount of money the user had already raised,which was 0 when the borrow request was created), a re-paymentDate (the date that the borrower promised to re-pay his loan by), a repaymentDateMidnight (the midnightof the borrower’s promised repayment date–the exact timewhen NodeJS would charge his bank account, in the for-mat of epoch timestamp), a paymentPlan (either “None”or “Installment,” but since we have yet to implement anyinstallment options, this field was always “None”), an inter-estRate (the percentage of interest lenders of this borrowrequest would receive), a requestType (always “Public” fornow because we have yet to implement private requests),a requestReason (which was the reason that the borrowerneeded this loan for), a StripeCustomerId (which was the idof the Stripe Customer Object we have created in associa-tion with the credit or debit card the user has inputted), arequestId (the id that we’ve assigned to this borrow request;this id was unique to each borrow request), a createdAt (thetime when the borrow request was posed), and an update-dAt (the time when the borrow request was last updated,the same as createdAt unless someone has lent towards orcommented on this borrow request, then it was the last timesomeone has lent towards or commented on this borrow re-quest).

When a comment was posted in response to a borrowrequest, NodeJS would find the borrow request item in itsdatabase, then attach the new comment onto that borrowrequest. Each comment item had a requestId (the id of theborrow request that it was commenting on), a commenterId(the user id of the commenter), a commenterName (the firstname of the commenter, followed by a space, followed by hislast name), and a commentContent (which was the contentof his comment).

When someone lent toward a borrow request, NodeJSwould find the borrow request item in its database, thenattach the new lend item onto that borrow request. Eachlend object had a requestId (the id of the borrow requestthat it was commenting on), a lenderId (the user id of thelender), a lenderName (the first name of the lender, followedby a space, followed by his last name), a lendAmount (theamount he was lending towards the borrow request, cannotbe larger than the amount the borrow request was tryingto borrow), and a StripeCustomerId (the Stripe CustomerObject’s id that was associated with the credit or debit cardthat the lender had inputted).

4.2.3 Stripe–Collecting Funds and Paying OutWhen a user posed a borrow request, he was required to

input his card information, which got stored in the databasein the format of a StripeCustomerId. However, if nobodylent towards his borrow request, his card information wouldnot be used.

When a user lent towards a borrow request, he was re-quired to input his card information as well, which got storedin the database in the format of a StripeCustomerId as well.The app would then charge the lender through Stripe. Ifthat charge was successful, the borrower’s Stripe Customerobject would receive the loan, and an invoice would then

be created. This invoice would charge the borrower’s StripeCustomer object the amount that the lender had just lentto him, plus any interest rate, on the date of his promisedrepayment date.

If the borrower paid back before the midnight of his promisedrepayment date, his repayment would immediately be paidout to his lenders. If he still has not paid back his debt bythe midnight of his promised repayment date, the invoiceswe have created would charge him, and if these charges weresuccessful, we would then pay out to his lenders.

4.3 Android StudioWe used Android Studio to create the frontend of Borrow.

To generate each page, or “Activity,” of the app, Androidrequired a java file and an XML file. The XML file was usedto layout the components on the page while the java file wasused to determine how each component would react whenthe user engaged with it.

For example, there is a button on the Main Activity pageof the app. It was generated by an ImageButton item in theXML file:

<ImageButton

android:id="@+id/action_write"

style="?attr/actionButtonStyle"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_alignParentLeft="true"

android:layout_alignParentStart="true"

android:layout_alignTop="@+id/my_toolbar"

android:layout_alignBottom="@+id/my_toolbar"

android:src="@drawable/ic_action_edit" />

In the corresponding java file of that activity page, wewould tell the app that, if the user clicked this button, theapp should open up a new page that would allow the userto post a new borrow request:

ImageView postButton = findViewById(R.id.action_write);

postButton.setOnClickListener(

new View.OnClickListener() {

@Override

public void onClick(View v) {

Intent myIntent = new Intent(MainActivity.this,

PostActivity.class);

startActivity(myIntent);

}

});

Once the Post Activity page has been opened, the userwould now be able to input information about his borrowrequest such as his request reason:

<EditText

android:id="@+id/RequestReason"

android:layout_width="300dp"

android:layout_height="wrap_content"

android:layout_marginLeft="8dp"

android:hint="Type Borrow Request Here"

android:textSize="20sp"

android:minLines="4"

app:layout_constraintLeft_toRightOf="@+id/profile_image"

app:layout_constraintTop_toBottomOf="@+id/greyPadding" />

There is also a button on the Post Activity page that, onclick, would post the borrow request to the NodeJS server:

<Button

android:id="@+id/postButton"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="Post"

android:textColor="@color/white"

android:background="@color/darkBorrowGreen"

android:layout_marginRight="3dp"

app:layout_constraintBottom_toBottomOf="parent"

app:layout_constraintRight_toRightOf="parent"/>

The corresponding java file would tell the app what todo with the information that the user has input into theseEditText boxes:

private EditText requestReason;

requestReason = findViewById(R.id.RequestReason);

The java file would also tell the app that, if the user clickedthe post button, the app should try to post the borrow re-quest he has just input to the NodeJS server:

postButton.setOnClickListener(

new View.OnClickListener() {

@Override

public void onClick(View v) {

postRequest();

}

});

5. RESULTSThe results of this project was an Android app with the

following screens.

The activity page on the left would allow the user to signin.

The activity page on the right would allow the user to setup his user information.

The activity page on the left is the main landing page of theapp; it shows all the borrow requests that have already beenposted by the users.

The activity page on the right is the post activity page.It is the page that would open up if the user clicked on thepen icon on the upper left hand corner of the main activitypage.

The activity page shown on the left is the page that wouldopen up if the user clicked on the lend icon that appears onthe lower left hand corner of each borrow request.

This activity page shown on the right is the page thatwould open up if the user clicked on a specific borrow requestin the main activity page. It is the detail activity page ofthat specific borrow request. It shows all the comments andlends that are posted in response to that borrow request.

6. DISCUSSIONThrough building this app, we have created an Android

app, a nodejs server, a firebase project, and a Stripe plat-form. We then established connections among them so theycould make calls to each other and make the necessary func-tionalities of the app happen. The Android app was the

frontend, the part where the user interacted with; the An-droid app made GET and POST calls to the Firebase back-end, which contained the users’ information, and the NodeJSbackend, which in turn made calls to the neDB and Stripe.

Through building this app, we learned the importance ofoutlining our code before we started–six weeks in, in orderfor the Android app to be able to retrieve these data andstore them into a HashMap instead of a much less efficientlist, we had to completely revamp the structure of the userobject, the borrow request object, as well as the way theseobjects were stored in the neDB. The main takeaway mes-sage of the work was that there was no end to the amount ofimprovements and extensions we could potentially add, es-pecially when the project was a mobile application like Bor-row was. Therefore, it was very important to focus on ourpriority instead of getting distracted by minor functionali-ties. With that being said, we felt extremely positive aboutthe final structure of the user object, the borrow request ob-ject, as well as the way these objects ended up being storedin the database. We have structured these data in a waythat was very efficient. On the other hand, something thatwe were not especially content with was the lack of error-handling when making calls to Stripe. There simply weretoo many errors that could occur during a Stripe call, andbecause of the lack of error-handling, the resulting app, froma security point of view, was not ready to be released to thegeneral public.

Besides error-handling for Stripe, there were still manymore extensions we would like to add–such as installmentoptions (so the borrowers would not need to pay back infull at once), private requests between friends (so the bor-row requests would not appear on anyone else’s feed butthe lender’s and the borrower’s), online wallet (so we canminimize the amount of time the app would need to accessthe users’ bank accounts), and email and phone verifications(so we could increase security and decrease the risk of userfraud).

7. ACKNOWLEDGMENTSWe wanted to thank everyone in our CS701 class for all the

feedbacks and encouragements we have received throughoutthe semester.

We also wanted to thank MiddChallenge for the summergrant–we will be using the grant money to explore and de-velop this project further.

8. REFERENCES[1] 3 specific ways that helping others benefits your brain.

2016.

[2] Americans owe an estimated 184 billion to friends andfamily annually. 2017.

[3] An inside look at borrowing money from family andfriends. 2017.

[4] U.s. music industry - statistics facts. 2017.

[5] Firebase by platform. 2018.

[6] Gofundme. 2018.

[7] Instagram cto says they do not withhold “likes” tokeep users coming back for more. 2018.

[8] Kickstarter in 2017 year in review. 2018.

[9] nedb github. 2018.

[10] Node.js. 2018.

[11] Rotating savings and credit association. 2018.

[12] stripe docs. 2018.

[13] Stripe: Saving cards. 2018.