Project Plan

[djbrown]

Establish CI/CD

• Create CI-Build with GitHub Actions #6
• Create Nightly Build with GitHub Actions #7
• merge nightly-build into ci-build #15

Upgrade project setup to Android API Level 33

• Upgrade project setup to Android API Level 33 #17

Fix instrumentation tests

• Timeout waiting for App to become idle in OwnCloudExportTest #16
• Failing Instrumentation Test: PieChartReportTest.testSelectingValue #13
• Failing Instrumentation Test: TransactionsActivityTest#testAddMultiCurrencyTransaction #26

Migrate models to Kotlin

• codinguser@5dacb7d
• Converting models to Kotlin. #28
• Convert models to kotlin part2 #29

Changes from @JeanGarf #5

• #876 Major contribution to gnucash-android codinguser/gnucash-android#882
• #110 searchable spinner arrayadapter codinguser/gnucash-android#895
• ...

Changes from @XilinJia (Diff)

• ...

migrate translations

• Migration crowdin to weblate #3

Rename Project and Support Channels

• Update README links and references #1
• future support channel: GitHub issues
• also consider mailing lists, UserVoice ...

Rename Technical Name/ID in Source Packages etc.

• Migration to gnucash-pocket #2

[djbrown]

@JeanGarf @XilinJia do you agree to this plan, or do you think we should reorder based on some arguments?

[XilinJia]

I checked on @JeanGarf 's branch briefly. There is basically no change in models. And actually when migrating to Kotlin, preserving the models was quite some work.

Perhaps we can start merging @JeanGarf 's branch with this commit of mine (models code converted to Kotlin): codinguser@5dacb7d

This commit includes updates onto Androidx and only models codes converted to kotlin with the rest still in Java. The java codes include changes only related to calling getters and setters in the models (aside from any changes required for Androidx).

[djbrown]

Nice :) thanks for your feedback. Then we should switch the order entirely or just prepone this specific commit?
latter one would mean:

• merge codinguser@5dacb7d into master
• merge JeanGarf into master
• merge rest of XilinJia into master

what do you think about CI (using GitHub Actions), do you agree that we should establish that first?
Here is an example/tutorial: https://www.youtube.com/watch?v=4nVRJ9ulKJQ
We should modify that for all setup changes of course, but I think a successful central build is essential before doing code work.

I am very familiar with GitHub Actions, Gradle and Java, but not so much with Android and Kotlin.
So I think I'm able to create a first rudimentary pipeline. You could then create PRs which would be tested etc. before merging into master, so we can be sure not to break existing things centrally and transparently.

[XilinJia]

That order sounds good to me.
I think it would be good to set up CI first so to ensure each merge step problem free.

[JeanGarf]

I agree with your proposal.

Great !

[JeanGarf]

I checked on @JeanGarf 's branch briefly. There is basically no change in models. And actually when migrating to Kotlin, preserving the models was quite some work.

Perhaps we can start merging @JeanGarf 's branch with this commit of mine (models code converted to Kotlin): codinguser@5dacb7d

This commit includes updates onto Androidx and only models codes converted to kotlin with the rest still in Java. The java codes include changes only related to calling getters and setters in the models (aside from any changes required for Androidx).

I confirm, I didn't change the model. I just enhanced UI experience and corrected some calculus.

[arozaqf]

@djbrown can you please change the color for the tags, black on red is not easily readable. thanks

[djbrown]

@djbrown can you please change the color for the tags, black on red is not easily readable. thanks

@arozaqf do you mean the color of priority/now and priority/high? which theme are you using?
for me it looks like this:

that color (#B60205) is one of the predefined ones in the labels edit menu.
I could switch to a more vibrant red for more contrast (like type/bug). or do you suggest something else?

[djbrown]

also I updated the initial thread post on the top, to reflect the current state and todos

[arozaqf]

@djbrown i'm currently using non dark mode because i'm using old version of firefox. is there no color that can be used visible.for the two themes? thank you for your consideration

[djbrown]

@arozaqf I changed the color of priority/now to bright red ( #FF0000) and it is readable for me on light and dark theme.
is that better for you too? I cannot reproduce your problem with the black font, I get white font on the light red backgrounds.
Can you add a screenshot how it looks on your end? and which other color would you suggest to represent urgency?
appart from that, I cannot do much, since GitHub sets the font color automatically.
maybe you could update your browser?

[djbrown]

as of #15 the apk creation and instrumentation tests now also executed in the ci-build and there is no separate nightly build anymore.

over the last couple weeks I tried to fix and stabilize the instrumentation tests but to no avail.
my different approchaes in my fork didn't make it much better, many tests still aren't even executed or reported properly since they're crashing in class initialization. and I can't even debug it properly since the current API level 27 is too low for Android Studio to handle it properly. I also tried to cherry pick commits from @XilinJia but that didn't really work neither.

I suggest to update the project setup first (with fine, semantic commits), then fix and stabilize the instrumentation tests and then finally merge @JeanGarf improvements. I hope I can merge them keeping Jeans authorship. Else I'll have to recreate them and give credit manually.

[XilinJia]

@djbrown with respect to the merging steps #8 (comment), where are you now?

[djbrown]

@XilinJia I couldn't find a way to merge in specific commit ranges, so sadly no progress for the mergings steps yet. my new suggestion was to upgrade the project to the latest API level (via Android Studio Upgrade Assistant) then hopefully get stable test results and then finally merge in or replicate the proposed changes.

[vinaygopinath]

It's great to see the Android app project being revived! 👏🏾

Creating a Github project to track the project plan in a kanban board might be more readable.

[arozaqf]

this is why the old gnucash android not moving we relied too much to one person

[djbrown]

I finally managed to set up a stable, secure and public CI for the project 🎉
see #18
the pull request is now open for reviews from anyone interested
when it's merged we can automatically verify all future contributions

[djbrown]

@reul managed to fix many tests ❤

There is still one more test failing according to current CI (#26).
Also there seems to be a general problem with missing tests on some configurations (#25).
I would defer the latter one, but in order to have a green pipeline, the former should be resolved soon.
@reul would you (or anyone else) like to look into #26? Else I'll give it a shot.

[reul]

Hey! I'm already looking into #26. I just couldn't fix it yet.

Funny thing is if I run only that test, it passes. If I run all tests, it fails.

Anyway I'm going to keep pushing it and I will send a patch as soon as I have it.

[djbrown]

Now we finally have a stable pipeline.
@XilinJia would you like to propose a Pull Request with models converted to Kotlin?
codinguser@5dacb7d is probably outdated now, since everything is already upgraded to androidx.

[reul]

@djbrown any suggestions on what should I address next?

In my own fork I'm testing retiring the CursorAdapter, but that's going to require a lot of work and testing until it's ready for production.

[djbrown]

@reul I guess Xilin isn't very active anymore, so you can work on converting the models top kotlin.

As for the CursorAdapter: would you migrate to an alternative way for data-view binding, or just fix deprecations?

[reul]

@reul I guess Xilin isn't very active anymore, so you can work on converting the models top kotlin.

As for the CursorAdapter: would you migrate to an alternative way for data-view binding, or just fix deprecations?

Yes! Data-View binding and moving the data loading logic out of the adapter and into a view model for now.

I can work on converting the models to Kotlin first and then go back to the adapters at some point.

[axiopisty]

I just discovered this fork today after sadly discovering that GnuCash Android is no longer in the Google Play Store. I'm happy to see all the collaboration and work that has started to take place on this project. Thank you.

It looks like the last communication I can see on this project was 5 months ago. Has the traction fizzled? I'm happy to help however I can. I have very little Android development experience but I did dabble in it many years ago. I'm looking forward to seeing this project become more active and hopefully contributing in some way.

[djbrown]

hey @axiopisty :) last communication on this project was 3 weeks ago on #10 (comment)
this is also still the current state

I wish this project was more active. I tried to establish a reproducable and open source friendly pipeline with GitHub Actions and Firebase Test Lab, but I'm not an android expert and have been stuck for some time with the failing instrumentation tests (#25).

I have also talked to some android enthusiasts whether they would like to look at the pipeline, but no feedback so far.
I'm not a big fan of manual testing, but if there's no better way...
So I'm thinking about just releasing a first stable version to the play store.
Users would then test, provide crashlytics and report problems.
That would give the project more visibility and traction,
but at the cost of user experience and project reputation.

EDIT: I just found an interesting relevant blog post:
How to Submit Your App to the Google Play Store for Beta Testing

[Kaligula0]

Why don't we just test it at first? 🤔

[Kaligula0]

Wouldn't it be better to release a alpha/beta here on GitHub and spread among us and our trusted volunteers?

[raoulbhatia]

From my side, I'd be happy to help in every possible way as I am missing gnucash on my mobile for a long time.

[djbrown]

The app is built on every run of the CI Build workflow.
Feel free to download, install and test the "application-apk" from the newest workflow runs.
I retriggered a run, since the last one was 6 months ago and the artifacts and logs are only kept for 90 days.

[Kaligula0]

I'm testing the app :) Generally, there are a few flaws but it works with the basic task of entering simple transactions and exporting them in GnuCash format :) I'm filing issues of what I've found.

[Kaligula0]

Who is allowed to approve PRs?

[Kaligula0]

Is anyone going to approve the PRs of the only dev working on this project? 🤔

[axiopisty]

Hello everyone. I have the same thoughts and questions kaligual0 has. We can see pnemonic78 is actively working on the project. But none of the PRs are being approved. Can we here from someone who manages this repository to get some instructions how to enable more contributors to be able to approve the PRs?

Also, I'm curious who here would be interested in broadening the scope of this project. I've recently learned about Flutter and am currently in a role where I have been learning and using Flutter professionally. I'm just curious if there is interest in this community for a possible rewrite of this mobile application in Flutter that would support both Android and iOS platforms.

I'm interested in taking on the challenge to do something like this. But I'm curious what kind of support there would be from the community. Specifically, I'm curious if there is anyone who would be capable and willing to collaborate by creating a Figma design for each of the screens (preferably using Material Design)?

[Kaligula0]

Is it that only the owners (@djbrown and @gutierri) of GnuCash-Pocket can approve PRs? 🤔

[axiopisty]

Only those with write access to the repository...

…

On Sat, Mar 9, 2024, 4:41 PM Kaligula ***@***.***> wrote: Is it that only the owners ***@***.*** <https://github.com/djbrown> and @gutierri <https://github.com/gutierri>) of GnuCash-Pocket can approve PRs? 🤔 — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXOR5QVKDYYQHO42UERVRTYXOM3RAVCNFSM6AAAAAARCX2IACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGAYTCNBZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Kaligula0]

I suppose so, but can't find who is it. I assumed "write access = owners", but I may be wrong.

[djbrown]

Hey guys, sorry I've been away from GitHub for some time.
I got kind of stuck with the flaky test automation -_-
Currently I don't really have the time to actively push this project.
And I'm not really an android developer, so ..
@Kaligula0 you now have maintainer permission for this repo 😉
See also Contributors (Wiki)
I'll try to keep up with the updates here and at the latest when we have a somewhat stable version, I'd like to release a beta version to the app store.

while I'm at it: @gutierri do you want to keep your organization owner role or may I remove/degrade you? if the latter, then I would really like to have a second owner, other than me

[axiopisty]

@djbrown can you make me a maintainer too?

[Kaligula0]

Hi, @djbrown, and thanks for reacting!
1) I looked at the Contributors (Wiki) and wonder what is the difference among owner, maintainer and project manager?
2) I'm not fully acknowledged with GitHub tasks and Android development but I'll do my best to keep the project alive. I also know, that in a month I'm starting a project that will absorb most of my free time :l What do you think of giving more permissions to @pnemonic78, who created most of recent PRs?

[djbrown]

Also, I'm curious who here would be interested in broadening the scope of this project. I've recently learned about Flutter and am currently in a role where I have been learning and using Flutter professionally. I'm just curious if there is interest in this community for a possible rewrite of this mobile application in Flutter that would support both Android and iOS platforms.

@axiopisty I had also thought about rewriting GnuCash or gnucash-android for web and/or cross mobile plattform. I think this could be a future (sub)project, once the app is back to stable. GnuCash (core) is already available for Linux, Windows, macOS.

Another big architectural idea is to integrate more with GnuCash (core). Currently the only "interface" between mobile and core are the data files. GnuCash (core) is very mighty and many features might be relevant for mobile users too. Currently the mobile business logic is quite detached from the core and duplicates it at best. Instead the mobile apps could call the C/C++ API of GnuCash (core), see also mailing list). That could either be done on platform specific architecture (Android NDK, Mixing Swift and C++) or cross platform (dart:ffi). This could also be adopted in web variants of GnuCash (C/C++ API calls depending on backend technology).

I'd like to come back to those thoughts and chose the next best step once we have a stable software version for android.

[djbrown]

@Kaligula0 I have clarified the collaboration roles in the Contributors (Wiki) with further documentation links to read on.

Thanks for the heads up. I have now also promoted @pnemonic78 as maintainer.

@axiopisty I have invited you as member to the organization and gave you the triage role on the repository. Depending on what you want to contribute, I'll gladly promote you to what is needed. But as I said before, I don't think we should strive for huge technological changes or even a rewrite just yet.

[pnemonic78]

I think that if we are to port the Android-Java version, it should be to Kotlin Multiplatform, because Flutter is too foreign to developers coming from Java/Kotlin worlds.

[djbrown]

Hey @pnemonic78 and @Kaligula0 First of all I wanted to let you know that I'm very grateful for your effort! You guys bring incredible velocity to this Project 🚀

I try to keep up with the Issues and PRs and so far I do comprehend most of whats getting merged 👀

I would feel much more confident though if we got back to a stable pipeline 🔄 and if there we're new tests to assert (functional) fixes 🔩

Currently the instrumentation-test workflow runs after every completed ci-build workflow, which runs after each push or pull request. With the current velocity, this leads to Insufficient testing quota error messages from firebase ❌

To fix this we could switch instrumentation-test to run only on push/merge or even only once a day ⏰ if the former turns out to be still too much. Upgrading to a paid plan doesn't seem feasible to me just yet 💱

There is also a problem with running the instrumentation-tests in older devices via firebase, see #25 ⚠️ Could you take a look at it? I can even add you to the firebase project if that helps. Maybe you already came across this problem when running the tests locally - or If they run just fine, that would also bei good to know.

Thank you for your contributions! 🚀

[Kaligula0]

I, as a perfectionist, also would like to do things step by step, but as I see @pnemonic78 's PRs there is a lot to fix in the app, and he's doing it quick and is the only dev working on it, so I don't want to discourage him. My only concern is that the more PRs the harder will be merging @JeanGarf 's and @XilinJia 's fixes. I don't have so much time to analyse their code and review all PRs.

As for the Firebase error messages I think that, looking at the number of PRs recently (😅), we can set this to a less frequent option.

I don't have so much time (and knowledge, too) to take care of the failing tests, so I really wait for someone to look at them (and frankly speaking I hope that one of pnenomic78's fixes will fix the tests ;) ).

[hades]

Please also share your thoughts on the future of Gnucash-Android in #141. Thank you in advance.