Pool Math........The App

[redth]

Back button now exits the app, but it does not close the app, it just puts it into the background.

This is how it's supposed to work, and how Google intends all apps to behave on Android. The app gets suspended when it's in the background, it's no longer doing anything or using battery, just sitting in memory until the operating system reclaims it if it needs it for some other app. Most apps work like this

 

[Regnar]

I like the new look.


Sent from my iPhone using Tapatalk

 

[roppy]

I like the new look as well

Sent from my Nexus 6P using Tapatalk

 

[pabeader]

It remembered my info when I updated.

 

[bigjess007]

Hey folks, developer here, just wanting to chime in on a couple things.

1. First of all thanks for all of the solid and constructive feedback you've given so far. We've already identified a number of issues and fixed them here. A new beta version is due to be released today or tomorrow with many of the fixes It's really helpful to receive detailed and accurate accounts of how to reproduce any issues you come across. Thanks for that!

2. There's a bit of discussion about the social login. These days, most users will have one of the 4 options provided. One of the main reasons we didn't elect to do a user name and password is simply because it's actually less secure to do that. It would mean we would have to store your username and a one way hash of your password on our servers.

Considering how many people use the same password for multiple services, there's an added liability on us if we store your passwords that I'd rather avoid. I won't get into details about how OAUTH2 works exactly, but basically now if your social 'token' gets exposed from our servers (which are hosted securely in Azure by the way), the worst someone could do with it is see your name and email address. We don't collect any personal information other than storing your email address locally on your device so that we can display it in the top left corner of the slide out menu in the app. That's it.

Implementing social authentication was actually MUCH more effort from a development perspective for me than implementing a simple username and password. I would rather have avoided that effort, but I don't think that would have been the right decision.

Eventually we may add the ability to login with your TFP forum account, but there's quite a bit of effort involved in making the app talk with the forum securely to do so. Also, that would mean anyone who wants to use the app would require a TFP account, which not everyone will (many users will download the app from the store without having heard of TFP - until they try it out and find out how great a resource it is!).

We require authentication in the app so that your pool data can be sync'd and saved to the cloud. We decided the workflow was too messy and would create a poor user experience if we wanted to allow local device storage only until a user logged in after that.

Hope that clears up the decision to use social auth!

Again thanks for all the feedback and keep it coming!

First, I want to say thanks for the development, never an easy task. I would however like to discuss the storage. I may possibly be in the minority when I say this, but why only cloud based? (It appears to be so you can access anywhere/anytime). If so, ok, but really how many folks are truly going to access this on multiple devices? I can't see that many. More and more folks don't want to use "the cloud" and would prefer local storage. I don't understand your statement that 'workflow was too messy and would create a poor user experience if we wanted to allow local device storage only until a user logged in after that'. Are you writing data local and then syncing a db to the cloud, or are you sending it all individually to a cloud db? And if the latter, are these individual db's or a massive db segmented by user? I'm not full on 'tin hat' but there continues to be an interweaving of connections that isn't always necessary. There are also plenty of times when even cell service isn't available and if the data is only available 'in the cloud' and you have no connectivity, bam, the app can't be used.

Users of any app/program should always be given the choice of where their data is stored.

 

[jagger2005]

I must have read developers comments differently. I thought it was stored locally and synced to cloud.

I like the new look!




Sent from my iPhone using Tapatalk

 

[jagger2005]

I put my phone in airplane mode and it allows me to add/edit without issue


Sent from my iPhone using Tapatalk

 

[bigjess007]

I put my phone in airplane mode and it allows me to add/edit without issue


Sent from my iPhone using Tapatalk

He specifically states:

We require authentication in the app so that your pool data can be sync'd and saved to the cloud. We decided the workflow was too messy and would create a poor user experience if we wanted to allow local device storage only until a user logged in after that.


It requires a login to work. If totally local was an option then it shouldn't require the login. Need some clarification on data handling.

 

[sennico]

Just downloaded the app and it looks like you guys are off to a great start! Have you look at using something like github to log issues and track feature requests? It might be an easier way to manage this project. Just my .02, keep up the great work!

 

[clambert1273]

Almost everything requires logins so I am not sure what the issue is... as to the above, I would use this across different devices & platforms (phone, tablet, etc...) and since I configure software, I know that my own we have social media integrations for login purposes only which cuts down on the "I need to reset my password" emails. I just used my google when first testing the app and it works fine.


Sent from my iPhone using Tapatalk

 

[dlance]

1. This should be addressed in the next update.
2. This error still exists until I can update PoolMath on the website later this weekend
3. This should be fixed on next update
4. This error still exists. We've been able to now recreate but but can't tell why it's doing it. We didn't want to hold up the update while we searched for this.
5. This should be fixed in next update. At least the best he could. He mentioned some changes however I wasn't able to fully follow as I'm unsure just how Android works to exit Apps. Regardless, it's improved.
6. This should be fixed in next update

Lee,

Regarding #2 about the salt level and CSI, should we go with the website CSI number or the app number? The statement about updating PoolMath on the site is confusing me.

I haven't found anything new yet.

 

[jagger2005]

Yeah, I guess I am sorry I tried to answer whether there is any local storage or not.

Just entered my testing for the day. So much easier than entering the info into pool math at the TFP website to get CSI and logging the info into Google sheets. You could store my pool logs on a Russian server...and I'd still be happy with the app.


Sent from my iPhone using Tapatalk

 

[jagger2005]

Diance, Leebo plans on changing the CSI calculation on the website to match the app. The difference in the 2 is website defaults salt to zero and app to 1000 - which is more realistic for a non-SWG pool. At least that is what I gathered from earlier posts.


Sent from my iPhone using Tapatalk

 

[Leebo]

Let me share a very common item.....

Almost weekly I get an email from a user, "Help, I've lost my password!" Ya know, I get this. Most users could care less about their pools over the winter. It's very common for users to never login from Sept until May. Could I remember a password for that off-season?????? Doubt it. Whenever I get this email I always send a password reset form to the Users email address they have on file and let them manage their own information. I email the user what I did and invite them to email me back if you still have issues.

I cannot tell you how many times a year I receive a bounced email due to the email address on file being wrong. I cannot tell you how many times I get a reply from the user saying "I never got an email because I no longer have access to that address!!" Now what am I to do?? I could manually edit their email address, but how do I know who I'm dealing with? Do I simply say deal with it? Social Login shifts that responsibility from TFP to Google, Facebook, or whatever.

So why save data in the cloud and not locally??
How many users have only one device? Likely less than you'd think. We want the user to log their data on their iPad at the table then use their phone to calculate how much bleach to add by the pool. We want you to use a huge screen to view your data. All this is really only possible by saving the data outside of your device.

 

[clambert1273]

Let me share a very common item.....

Almost weekly I get an email from a user, "Help, I've lost my password!" Ya know, I get this. Most users could care less about their pools over the winter. It's very common for users to never login from Sept until May. Could I remember a password for that off-season?????? Doubt it. Whenever I get this email I always send a password reset form to the Users email address they have on file and let them manage their own information. I email the user what I did and invite them to email me back if you still have issues.

I cannot tell you how many times a year I receive a bounced email due to the email address on file being wrong. I cannot tell you how many times I get a reply from the user saying "I never got an email because I no longer have access to that address!!" Now what am I to do?? I could manually edit their email address, but how do I know who I'm dealing with? Do I simply say deal with it? Social Login shifts that responsibility from TFP to Google, Facebook, or whatever.

So why save data in the cloud and not locally??
How many users have only one device? Likely less than you'd think. We want the user to log their data on their iPad at the table then use their phone to calculate how much bleach to add by the pool. We want you to use a huge screen to view your data. All this is really only possible by saving the data outside of your device.

I love you [emoji8][emoji8][emoji8][emoji8]


Sent from my iPhone using Tapatalk

 

[dlance]

Yeah I knew about the 1000 thing I just didn't know about the planned change. So "salt" is more in essence TDS now? If so I guess it is time to brush off my TDS meter lol.

 

[Leebo]

To get CSI to work some number is required to be entered for Salt. We had to pick some sort of number by default. On the website we used the number 0. This isn't realistic in a chlorine pool as all chlorine adds salt. To help give a more accurate CSI result we defaulted the App to 1000ppm. Now, if a user skips changing that field in both the App and website the result won't match.

To fix this I plan on editing the website version of PoolMath to also use 1000ppm for salt. This will make both versions match IF the user doesn't manually enter some result.

 

[dlance]

Thanks Lee!

 

[bigjess007]

Let me share a very common item.....

Almost weekly I get an email from a user, "Help, I've lost my password!" Ya know, I get this. Most users could care less about their pools over the winter. It's very common for users to never login from Sept until May. Could I remember a password for that off-season?????? Doubt it. Whenever I get this email I always send a password reset form to the Users email address they have on file and let them manage their own information. I email the user what I did and invite them to email me back if you still have issues.

I cannot tell you how many times a year I receive a bounced email due to the email address on file being wrong. I cannot tell you how many times I get a reply from the user saying "I never got an email because I no longer have access to that address!!" Now what am I to do?? I could manually edit their email address, but how do I know who I'm dealing with? Do I simply say deal with it? Social Login shifts that responsibility from TFP to Google, Facebook, or whatever.

So why save data in the cloud and not locally??
How many users have only one device? Likely less than you'd think. We want the user to log their data on their iPad at the table then use their phone to calculate how much bleach to add by the pool. We want you to use a huge screen to view your data. All this is really only possible by saving the data outside of your device.

I knew my post was going to start a storm, and I would be in the minority. I however am not changing my opinion, but I think what you've posted clarifies how you want the users to use the app, and not give them a choice on data storage. And in today's changing world, that just continues to prove to not be a good idea. More and more folks don't want everything to be in the 'cloud' however having a choice of being in or out of the cloud is generally the more important option.

If the developer responds on the data handling so be it, but offline is generally always an option for any app, and always should be an option to the end user. However depending on how this app's underlying framework is built determines on whether this can easily be implemented at this point or not. It certainly is possible as I've been using another app for this for years now in the vacuum of not having an official pool calc/math app by TFP. (And I know someone is going to say well just keep using that if you don't want cloud storage. And I'll save you the post cause yes, you're right, I will, however I would rather much use this new app because it does have alot more great features providing I have control of the data.)

But I'd rather this just be addressed and look at both the security and more importantly the user's choice in it instead of just saying this is how you are going to use it.

 

[redth]

Hi there, I'm going to try and explain our decision on the cloud syncing a bit, and how it works. I definitely can appreciate the concern for data security and control, so I'm happy to be transparent about how this works and what we're using.


First of all, the data is stored locally. You can use the app in airplane mode, the data is always kept on the device, in a local database. If you never connected your device to the internet, your data would always still be there on that device. One of the next features which I've already started working on is the ability to Export and Import your data, as I believe it's important that you ultimately control your data. We aren't trying to own your data, just make it convenient.


We use a technology called Realm (for those interested, Realm: Create reactive mobile apps in a fraction of the time ) to implement the cloud syncing and syncing between devices. Each user login is associated with its own Realm (or database) locally, which gets synchronized to the cloud (hosted in Microsoft Azure), so it's not one big database, it's actually many small databases.


Early on, actually before we settled on using Realm, we decided that the lowest friction way to implement cloud sync would be to automatically provide it for everyone. This minimizes the chance of data conflicts if a user installs the app on multiple devices, and it also reduces the number of first time run paths when we add in some sort of payment/subscription for the app. I think it's fair to say we would consider adding the ability to opt-out of cloud sync in the future. It's certainly possible, it's just not what most users are going to want or expect, and we feel it's not the best use of development effort at this point in time.


I appreciate that you realize you're probably in the minority here, and unfortunately I think that's true. I don't want to sound dismissive of your request, so we'll definitely log this as a feature request for future versions of the app (we have an internal bug/feature tracking board). I'm all for giving users the choice, but like I said, in this case specifically, it's not as high priority as other things such as adding import/export and graphs/charts.


Thanks for your feedback!