dreautall / waterfly-iii

Unofficial Android App for Firefly III, a free and open source personal finance manager.
MIT License
315 stars 22 forks source link

Any plan to include the app on Fdroid repo? #2

Open much-doge opened 1 year ago

much-doge commented 1 year ago

I would say this is a Firefly III android client which I like the most in terms of UI and ease of access, it would be nice for it to be included on Fdroid repository and I'm sure that way more people would know about it.

dreautall commented 1 year ago

Hi, thanks for the kind words! I'll have a look at how to publish on F-Droid once I'm ready to release the first non-alpha version.

Right now, I'm still unhappy with the notification reader feature which needs a more fine-grained settings menu to not be annoying. Once that's done (I hope in 1-2 weeks), a public version should be available, and I'll check how to publish to F-Droid!

dreautall commented 1 year ago

Current PR ongoing with the fdroid repo to include it: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12959

much-doge commented 1 year ago

awesome πŸ‘

natrius commented 10 months ago

I have it.through the izzysoft repo, but it seems.to be stuck at 0.1.7-beta ?

dreautall commented 10 months ago

I'm honestly not sure how Izzysoft determines if there is an app update. For the official fdroid repo I created https://github.com/dreautall/waterfly-iii/blob/master/fastlane/metadata/android/version.txt, and just confirmed again that this works for the fdroid process (although due to issues with the reproducible builds, it is unfortunately still not "officially" part of the fdroid repo).

Not sure if @IzzySoft directly can help out here or if I'd need to create an issue at this GitLab.

IzzySoft commented 10 months ago

I'm honestly not sure how Izzysoft determines if there is an app update.

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags

So my updater looks at the tags if there's a tag name indicating a higher version. Just triggered it manually now and it fetched v0.1.12-beta. Looking at the tag: That APK should have been fetched yesterday (and the other ones before that) – I have no idea why it didn't (the auto-update doesn't do anything different than the manually triggered one, just that the latter only considers the specified app). The logs show no errors either. Hope this was just a one-time hick-up; should it happen again, please give me a ping.

kaanelloed commented 7 months ago

@IzzySoft The app is still stuck at 0.1.7-beta , even with the manual update.

IzzySoft commented 7 months ago

@kaanelloed nothing I can do about that. 0.1.7-beta has versionCode 2096, so to Android that is newer than the 1993 from the current latest release:

package: name='com.dreautall.waterflyiii' versionCode='1993' versionName='0.3.0-beta'

versionCode must never be decreased, or things like this happen. Even if I'd pull this latest one to my repo and remove the 0.1.7, it wouldn't be offered to you as update – and if you tried to update manually, Android would refuse telling you that downgrades are not allowed. So you'll have to wait until the "base versionCode" (aka variant.versionCode) reaches 210 (which then results in 2103 for arm64) before updates will show up in my repo.

If you wonder how this might have happened, I have a good guess. Most likely, initially Flutter's own versionCode generation was used. Flutter takes the "base versionCode" and adds ABI * 1000 to it, with 2 for arm64. So with 0.1.7, the base versionCode probably was 96, which +2000 resulted in 2096. This calculation is a bit problematic, as it would count an older arm64 as newer than a recent armeabi. So the project decided to switch to a proper versioning, using the calculation variant.versionCode *10 + ABI. By that calculation, 0.1.7 would have had 963 (as arm64 was re-defined to 3 and 0.1.7 had 96 as base versionCode).

Maybe @dreautall wants to initialize the "jump" to variant.versionCode = 210 to fix this gap?

dreautall commented 7 months ago

Thanks for letting me know - I'll make sure versionCode is at least 210 for the next release (as I rely on automatic github builds it actually uses the github build number, which is at 203 right now, so getting it to 210 isn't too "hard" πŸ˜„)

IzzySoft commented 7 months ago

Yeah, thought the jump wouldn't be "too far" and thus acceptable :stuck_out_tongue_winking_eye: Of course I could have simply replaced the APK here, but that would leave those at 0.1.7 and below stranded for another while. So going directly to 210 with the next release would solve it for all.

Thanks a lot, @dreautall!

dreautall commented 7 months ago

Should work now with v0.3.1-beta I hope (build number 213)

IzzySoft commented 7 months ago

Yupp, that worked out fine! Just the per-release changelog was not pulled as it could not be matched. So let me guess… I pick the arm64 one. According to your build.gradle that's a 3. At the very same it says versionCode x 10 + abiCode. I don't see where the base is established, but that would mean my 2133 must be 213.txt – and I can calculate that by (versionCode - 3) / 10. OK, I've set that, next release will show if it works (added the current changelog manually for now).

Let me check some more while we're at Fastlane. My notes say I don't pick shortdesc because it's too long (limit is 80 chars). That seems to be mostly fixed, except for

Could you please fix that?

fulldesc is also skipped due to formatting issues: it's close to Markdown, but would only render as Github flavored Markdown, which my renderer does not support. Could you make sure it renders as "standard Markdown"? That means, paragraphs separated by empty lines, and bullet-point lists too.

dreautall commented 7 months ago

Hey. Unfortunately I implemented the length limit too late in Crowdin for short description, but I had to modify it for Google anyways and will update the files.

The text itself is not supposed to be any markdown as I just copy it into the Play Store description. Can I/you somehow mark it as plain text?

IzzySoft commented 7 months ago

will update the files

Please let me know when it's done, so I can enable those here.

Can I/you somehow mark it as plain text?

I can, but it won't look as good then (e.g. the longer lines in the bullet-point list would wrap on phone screens, thus destroying the formatting). All that would be needed to make it render as proper Markdown are two empty lines inserted: one before the bullet-point list, and one before the last line (after "Contribution:") – though the latter would not matter too much if you're fine with the two lines combined to a single paragraph.

dreautall commented 6 months ago

@IzzySoft: Should be all done, thank you for the feedback!