I helped marco to finish the Android app for the final presentation, these changes were UI changes, and there are push notifications, that was something more elaborated than I tought, I needed to obtain some keys in our firebase database to let our server comunicate with the gcm service (now it’s called fcm, firebase cloud messaging), then when the user signups or updates their profile, the android device sends a token that fcm generated for the device and we store it in neo4j, then when someone invites that user to a pool or asks them to pay his debt we send a push notification to his phone. Now, to receive push notifications, we needed to register a service in the android app that would listen for the messages, then depending on the messages we would create a different behaviour when the user clicks the notification, or one of its buttons. It was a pain in the ass.
This is the app. https://play.google.com/store/apps/details?id=com.cooper.cooper
I think it does not have the most recent code.
This last week I tested a lot from the users and pools, I found a lot of bugs while I was doing so and fixed them. I managed to solve the travis-ci problem with neo4j (turns out it was trying to connect to another port). So now when someone pushes, the tests are run.
Francisco helped us edit the final video.
This week I plan to finish the test and have at least 70% of the api code covered. We already have all signup, login, profile and delete account functionality tested and passing. I tried to include the tests in the travis-ci build but it seems to have problems with the neo4j service, neo4j is throwing this error:
Uncaught error when processing result: Neo4jError: 140223444313984:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827
And I just don’t know why, should I just remove the https code when the code is being executed in travis? Maybe it’s because it does not find the key and certificate, but I don’t see why that would be the case, I’ll try again anyway.
This week I started helping with the testing. I solved the issues that they were facing with the cookie. Marco is creating the web application and, when he was developing, found some bugs in the api, these are already fixed. Marco (and someone else that I’m not aware of, I guess) integrated the firebase chat to the app. That’s nice, altough it’s kind of ugly, but hey, it works.
We know we may have some security issues, in the chat and some parts of the api, but no can do, we are aware of that and will not fix it, we have to finish the things that we need to present in the demo.
I have some things left to work in the api before helping Marco or Francisco with the mobile app and the tests.
- Pool owners can specify custom amounts for each user, but they cannot make it automatic, I have to put a flag in the pool creation to set if the users will be charged the same amount, and also update everyones debt if a new user joins (This will only be updated if the pool has not started yet, because then users can start paying).
- I need to notify users if they have a debt that have not paid (when the pool end date arrives).
- With cash, owners should confirm the amount the users claim to have paid.
- Store profile pics somewhere.
That’s what I’ll work this week, even if I don’t finish all of this I’ll start working in the Android app with Marco.
This week I worked in the flow logic for cash payments, a user can only pay a pool if it has a debt, but he or she can overpay and then the pool owner has a debt with him. Pool owners can edit the debts and amounts of the users but only if the debt is high enough to surpass the pool’s total. I was working implementing stripe, in fact, we were able to receibe payments from users that registered in stripe (we were missing the frontend that would comunicate with stripe for the registration). Anyway we decided that we don’t have the time to finish this, there are other, more urgent things to do before the final delivery, so we will drop the credit card functionality from the app and focus in making better what we already have.
This week I’ll be working on the payment flow.
When a pool is marked as cash, users should say how much they paid and then the administrator should confirm the amount.
When a pool is marked as credit we will have to request the payment from the users and then send the same amount to the admin (we need to check if this is possible with stripe).
If the admin wants to update the amounts that the users have debt, we need to make sure that everything is kept within the limits of the initial costs (right now you can update a user’s dept to whatever amount). And maybe we should not be able to update the already paid amount (at least for credit), what’s already paid should not change.
Another nice to have would be to find friends on Facebook, instead of searching them by name or email.