Apps-android-commons: Discussion: New strategies until grant renewal starts

[neslihanturan]

Hi everyone,
After #829 , it might be very important to be organized again, to not lose our team motivation. We already have our ideas on proposal here: https://meta.wikimedia.org/wiki/Grants:Project/Improve_%27Upload_to_Commons%27_Android_App/Renewal , but I think there is a lot to that is not included to our proposal. It can be a good time to

• Re-factor our legacy codes
• Optimise our network calls
• Write our test codes, maybe this is the most important one
• Of course some bug fixes
• Removing structural problems and inconsistencies in the code

Actually I think this delay is a good thing on another point of view (Polyanna was here:)) because we have several new features planned for an unstable application yet. So, it is a good time to stabilise our application without adding new features. If you are also good with it we can discuss more well described things to do under this discussion, instead of discussing under separate issues. Then we can work to create our new issues, and organize existing ones accordingly, maybe this weekend.

What do you think about for a stabilising camp for 3-4 months?

[misaochan]

Hi Pollyanna. ;)

@neslihanturan In all seriousness, all the suggestions that you mentioned sound great. I mean, I don't really agree that new features should be delayed just because bugs/crashes still exist - bugs/crashes will always exist (especially with the plethora of Android devices out there and new Android versions coming out so often), so I personally think that it would be unrealistic to delay new features because they exist. I think both new features and bugfixes can and possibly should be worked on at the same time. But the timeline is really out of our hands at this stage, so moving on from that...

I agree with your proposed stability additions. Refactoring ShareActivity.java would be AWESOME. :) It is worth noting that we need people to test, review and merge every PR though, otherwise contributors might lose motivation. Would you like to take on the mantle to lead these proposed changes for the time being? Also, I can try harder to ask WMF to allow you read-only access to the developer console so you can see the crash reports (I tried asking them about a month ago but they didn't follow it up).

[neslihanturan]

Yes, I can follow this process. I need to declare that I am in two more project simultaneously, but I will do my best anyway.

Regarding tests, I am sometimes having hard situations because as you know wikipedia access is blocked in my home. Despite my wasted long hours to solve the issue, I am still not able to set a consistent VPN connection from my main computer (I even tried to refresh my OS installation). Thus, I am not able to use emulator, my test environment is limited with my android devices. This may be a little problematic for me to test. Thus, any other help for testing is appreciated.

Other than Refactoring ShareActivity.java, do you have any other advises?

[whym]

I agree. If there is going to be a lack of releases for an extended period, it sounds like a good idea to use the time to cleanup/stabilize internal things.

[misaochan]

Thanks for volunteering to oversee this @neslihanturan ! No worries, just put in however much time you can afford to put in. This is all currently volunteer work anyway. :)

Advice off the top of my head:

• Look into the high priority issues
• Have a clean-up of our current issues, a lot of them should have been closed or need tags. It's easier to start with a clean slate.
• Have a clean-up of the existing PRs
• Work with @psh and @akaita to get the RxJava2 implementation up and functional so we can overhaul how threads are handled (this needs testing unfortunately, I was testing halfway through the last PR #818 but haven't been able to follow up. Hopefully your real device can do it or someone else can chip in).
• As you said, tests, bugfixes and refactors would be great too

[akaita]

Please let me chip-in, at least in regards to the status codebase.
It is very obvious that tons of people with very varying knowledge-levels have contributed code into it. Good practices and bad practices are mixed in equal parts, as well as very different coding styles and patterns.

The absolute highlight of the codebase if though the handling of threading. It is quite bad (excuse my sincerity) and will cause issues and errors which magically appear/disappear. Other issues in the codebase are not such a biggies and could be lived with, but the threading does need fixing or it will keep bitting us.
The best strategy in regards to this is to progressively merge PRs migrating to RxJava2. I highly discourage any Big-Bang style strategy, as it will make the task overly daunting (doing it, keeping up-to-date with conflicts, testing, merging,...).

[misaochan]

Testing would be needed even if RxJava2 PRs are progressively merged into master. But yes, conflicts could be minimized that way. I am good with progressive PRs and merging assuming there are no issues with core functionality when tested.

As for the varying knowledge levels - yes, that is the beauty of a community-maintained open source app IMO. ;) We all have to start somewhere, after all.

[psh]

Three problems of deprecation should be addressed:

• Several of the API calls return warnings that they are deprecated on the server side. For instance, we should be requesting a _csrf_ token and not an _edit_ token.

• Worse than simple API calls being deprecated is that the Wikimedia API data formats page lists XML as a deprecated format, and the standard is to use JSON for all API calls. This affects _every_ API call we make.

• The Apache HTTP library that the API calls utilize has not only been deprecated but removed in newer API levels of Android. The only thing saving us is the useLibrary 'org.apache.http.legacy' in build.gradle

I've started the work and happy to push it through to completion but it will need some testing love from folks. Its out of the realm of _refactor_ and well into _rewrite_ but I'm confident that the app will be better for it! When all is said and done we'll also be able to drop a few libraries from the build.

[sivaraam]

Is this still relevant? Or shall we close this? 🤔