search

e-mission / e-mission-docs

Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.
https://e-mission.readthedocs.io/en/latest
BSD 3-Clause "New" or "Revised" License
15 stars 34 forks source link

Maintenance updates to the app platforms #465

Open shankari opened 4 years ago

shankari commented 4 years ago

This issue tracks changes required to support recent requirements from apple and google. The requirements are:

Apple also requires all apps to be upgraded to 64-bit, but that appears to be an OSX-only requirement. https://support.apple.com/en-us/HT208436 At least, I haven't received any warnings about any of the iOS apps in the stores

I will try to make these changes without changing the min supported version (#438) and then upgrade those separately so that you can choose the migration path. But if this is too hard to do, I will upgrade but give you sufficient warning here.

Note that I don't plan to deploy the updated apps to the stores (e.g. e-mission and emTripLog) until December at the earliest, to allow existing studies to complete without interruption. But if you are building your own app, you can pull the changes and update/deploy your own apps.

Please let me know if you can help with testing the changes. Having multiple testers will make the changes more robust, and reduce individual testing/validation.

PatGendre commented 4 years ago

Hi @shankari , we have received a security warning on android related to angular.js, I've created an issue https://github.com/e-mission/e-mission-docs/issues/464 , if this relevant you can add it in this update list?

shankari commented 4 years ago

Based on #483, it seems like there is an urgent need for app maintenance to support new iOS versions and new app store requirements. The last major update was in the Spring of this year, and took roughly one month of my time. Alas, I am graduating now, and I don't have time to spend a month on a maintenance update.

I anticipate having even less time in the future, so I would like to start transitioning the maintenance to a developer or developers who can periodically go through and make the changes necessary. Since it took me, the super skilled maintainer, a month for the last update, I would like to budget 2 person-months for a developer who is going to have a learning curve.

2 person months @ 40 hrs/wk, ~ $40/hr will come to around USD 13000.

Let's see if the community can come together to fund this. I know that @stephhuerre, @asiripanich, @st-patrick, @jf87, @xubowenhaoren are planning to deploy native versions soon.

13k/5 ~ USD 2500. Let's count me as a person since I care about the project. 13k/6 ~ USD 2100

Would you be willing to contribute USD 2100 each to upgrade the plugins to support the latest store requirements?

@xubowenhaoren you can contribute time instead of money if you like 😄

Since we are going to touch the plugins anyway, we can also fix the build issues and ensure that the most recent version of xcode works. We can also fix issues with the onboarding - e.g. add a screen that tells people that they need to select "Always Allow", explain why we need certain permissions, etc., add better error handling, etc.

Please let me know what you think. Email is fine if you are shy 😄 but the general trend for open source projects is complete transparency. e.g. check out https://www.bountysource.com/

shankari commented 4 years ago

If people would prefer a bountysource approach, I can split the update into multiple smaller issues of 2k - 3k each. But really, all the components need to happen for the update to work, so I think that a bounty approach doesn't really work for maintenance as much as for new features.

shankari commented 4 years ago

I spoke to SDSU today and they want to build a custom app too. So if we include them, this comes down to 13k/7 = approx $1860 per group. If you can round up to $2k, I won't complain 😄

shankari commented 4 years ago

In #480, @stephhuerre said that they would handle the upgrade to API 28. Woo!

If only somebody else would handle the support for Apple Sign in (@xubowenhaoren?) then both updates will happen organically from the community, which would be great....

shankari commented 4 years ago

@stephhuerre @asiripanich as part of the upgrade to API 28, android will also have options for "when in use" and "always" (https://support.google.com/googleplay/android-developer/answer/113469#targetsdk). It seems like this would be a good opportunity to introduce a screen in the onboarding that explains to the users what popup they are going to get and how to answer it.

We have had issues with end-users picking "when in use" instead of "always" on iOS before, and it would be good to fix this before we have the same issues on android as well.

Further, since the app knows what the OS version is, it can give the correct instructions - e.g. for iOS12, say "pick always" and for iOS13, say "pick when in use" just to avoid confusion. Since there are no native code changes for the location permissions on iOS, @asiripanich could even implement it in time for their January launch.

Let me know if either of your teams wants to take this on, and I can write out a high level design or create a draft PR as a starting point for the changes.

asiripanich commented 4 years ago

@atton16 I think we will need that feature for our up coming deployment. Please follow up with @shankari about the details.

shankari commented 4 years ago

@atton16, you want to look at calls to markConsented, which is the call that initializes the location fsm after the user says "I accept".

If you have more specific questions I can respond after a few days