Open BartoszWilkusz opened 7 years ago
Busy indicator: https://developer.apple.com/ios/human-interface-guidelines/ui-controls/progress-indicators/ Possible strategies:
Permission to access user location: You don’t have to check it all the time but maybe after login and in App delegate when the app will be active again
Remove weight from user: 6 / 30 told their actual weight. You can discuss if you want to keep it.
Async and Singleton: Pass on to @horsson :)
Credentials: I'm sending an email in 20 seconds
Hello! My opinion about 3 . Remove weight from user. The users don't tell their actual weight -> they don't like it We added the parameter for calculation of losing calories. The result of each user directly depends on his weight. I met different ways to calculate the number, but everywhere you need to know weight (example of formula http://fitnowtraining.com/2012/01/formula-for-calories-burned/), if you want to provide right data about the calories. Maybe the feature should be only for entertainment and work with average meaning, but in this case we have to inform users in advance.
Thank you Marc, I will have a look at it. @inf2381 You should change the password, because if you browse the history of the project, you can find the user and password. Furthermore, you should use a technical user for the connection to Hana with restricted permissions. If someone gets (whatever) the login data, he/she gets access to the database and can delete eveything. I tried it and can login with the user.
Hello, Today I had a meeting with @BartoszWilkusz. Regarding the Busy Indicator, I'll go for the easy solution. Because firstly it can unified the logic, secondly if the loading time is less than 2 seconds, the show and hide busy indicator doesn't impact the user experience, if the loading is very fast, for example, 0.1 the user doesn't know it happens.
Another question to refactoring. We have the attributes "wheel rotation", "burgers burned", "distance", and "co2 saved" for every user. Should we store this values in the database and attach them to the singleton user class, or only store it in the KeyChain because of legal stuff? (Personal information etc.) thanks.
We discussed it offline :)
Right. All attributes are stored in the user class and user table in database.
Now only the user permission for user location left to do.
I have some questions to the remaining refactoring items from trello:
1 . Add busy indicators (e.g. when loading data from the backend) How should the activity indicator look like?
Option A: We have a spinning wheel in the middle of the screen during activity like in this tutorial. In this version, the user can touch all buttons etc. The screen is not "locked".
Option B: We "lock" the screen for the user during activity (e.g. loading data from backend). But in this case, the user can't do anything while the background task is running.
2 . Permission to acccess user location I'm not familiar with iOS, so is it possible for a auser to cancel the permission for the app to use the users location? If so, we have to check the permission every time we access the user location, right? Is this a good approach, how we should implement it? I don't now whats the common way to check the permission.
3 . Remove weight from user. The users don't tell their actual weight -> they don't like it I'm not sure about this.
4 . User as singleton Hao said, this isn't a good idea. Maybe i get it wrong, but he could write 2-3 sentences to this topic?
5 . The whole async issue I implemented a prototype async process in the dev branch for request the reports. I notified Hao to make a feedback, so i can implement all other requests the same way.
6 . Credentials.json file Should the credentials file have any information like login data for the backend? Because since the thing with the credential file was added, building the project will fail.
Thanks.