Release section for new builds

[rancidfrog]

Looking forward to see how this project develops.
Please include APKs in release section in the future:
A great example for releases is fairemail.

Also, it has automatic new release check mechanism, which can be disabled in settings, that links you to github releases to download latest build, (Newpipe also has update link notification).

As for donations, FairEmail has a great scheme for users without playstore services, https://email.faircode.eu/donate/

I believe you need to be careful not linking between builds, goggles can be annoying and tricky to deal with.

As for fdroid, I am not a fan. Because, they have issues regarding building mechanism and queue order. Most builds are late which creates problems if and when fixes are pushed.
But, you should contact @IzzySoft as he maintains his own repo which might be better on updates.

[appml]

Thanks for reaching out to me. Would you please fork the repo again? I messed up while dealing with Fdroid issues and squashed some commits. Thanks for advice about izzysoft. I will definitely look into it as I don't have the right platform resources to run certain Fdroid requirements at the moment. Anyone who can give me a hand would be appreciated.

…

On Mon, Apr 12, 2021, 09:13 rancidfrog ***@***.***> wrote: Looking forward to see how this project develops. Please include APKs in release section in the future: A great example for releases is fairemail <http://github.com/M66B/FairEmail/releases>. Also, it has automatic new release check mechanism, which can be disabled in settings, that links you to github releases to download latest build, ( Newpipe <https://github.com/TeamNewPipe/NewPipe/> also has update link notification). As for donations, FairEmail has a great scheme for users without playstore services, https://email.faircode.eu/donate/ I believe you need to be careful not linking between builds, goggles can be annoying and tricky to deal with. As for fdroid, I am not a fan. Because, they have issues regarding building mechanism and queue order. Most builds are late which creates problems if and when fixes are pushed. But, you should contact @IzzySoft <https://github.com/IzzySoft> as he maintains his own repo which might be better on updates. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZICZMLFGYCJN7G75IO4KLTILWVXANCNFSM42ZISMMQ> .

[IzzySoft]

@appml

A good starting point would be tagging your releases and then attaching the corresponding .apk files, starting with the current version. That would enable me to list your app with my repo – and some of the scanning F-Droid does on review would already run (so you can "track progress" towards inclusion there). Going by your AndroidManifest.xml, a good name for the first tag would be v3.6.9 (i.e. the versionName prefixed by a v).

From that we can go forwards. I'd e.g. be curious why your app seems to contain Firebase – it's not listed as explicit dependency in your build.gradle as far as I can see. You could run gradle :app:dependencies to find out. Just mentioning it as this is a show-stopper for F-Droid.org (and will raise AntiFeatures with mine: at least NonFreeDep as it's proprietary).

@rancidfrog

Most builds are late which creates problems if and when fixes are pushed.

That's being worked on and improved a lot recently. We found what prevented several builds from being published (yes, those updates were built but not published) and fixed that, then had a few "extended build times" to get the backlog down. There are always cases when builds fail, which can't be helped; our "backend team" tries its best to fix those in a timely manner. It would of course help if there were more volunteers "adopting" specific apps, taking care for their maintenance. Be welcome to step up 😉

his own repo which might be better on updates.

Indeed updates in my repo are more "timely" (usually happen within max 24h after the corresponding APK was made available). But measured at "when the APK becomes available", F-Droid has the same speed – the difference is that F-Droid has to build the APK while I just fetch the developers' builds. So the pro of my repo is updates are closer to the apps' release date – while with F-Droid you can be sure the APK you get corresponds to the code, and was scrutinized even more than those in my repo (yes, I "scrutinize" them too, but for my repo cannot go as deep as F-Droid does).

[appml]

@IzzySoft Thanks IzzySoft for the heads up. I will look into that when I get a chance.

[IzzySoft]

Just give me a "ping" when the APK is available, I'll pick up then.

[appml]

@IzzySoft APK added

[IzzySoft]

Thanks, picking up! First check: Looks good:

Libraries detected:
-------------------
* Android Support v4 (/android/support/v4): Development Framework
* AppCompat (/androidx/appcompat): Utility
* Constraint Layout Library (/androidx/constraintlayout): Utility
* Androidx Core (/androidx/core): Utility
* Lifecycle (/androidx/lifecycle): Utility
* Media (/androidx/media): Utility
* Room (/androidx/room): Utility
* Transition (/androidx/transition): UI Component
* WorkManager (/androidx/work): Utility
* AppIntro (/com/github/paolorotolo/appintro): Development Aid
* Google Material Design (/com/google/android/material): Utility
* Google Core Libraries for Java 6+ (/com/google/common): Utility
* J2ObjC (/com/google/j2objc): Utility
* ZXing Android Embedded (/com/journeyapps/barcodescanner): Utility
* RecyclerView-FastScroll (/com/simplecityapps/recyclerview_fastscroll): UI Component
* prettytime (/org/ocpsoft/prettytime): Utility

No offending libs found.

No show-stoppers – so that "Firebase" reported by Appbrain is not (or no longer) true, cool!

Step 2: something's wrong with your launcher icon: drawable-xxxhdpi-v4/ic_launcher.png PNG 1x1 – that's definitely the wrong size. Same issue for mipmap-xxxhdpi-v4/ic_launcher_round.png – which unfortunately is what the user will see in the launcher (and what will be used in app listings).

Nevertheless: with the next regular sync tomorrow around 5:45pm UTC, your app will become available here – so be welcome to add this badge next to the Playstore one in your Readme, linking it there 😃

Step 3: after a quick walk through your source tree I'd say your app looks ready for listing at F-Droid.org if you wish to have it there. I gladly keep it in my repo if that's what you want.

Further, it's recommended to establish Fastlane structures in your app's repo, so you can maintain description, screenshots etc. and repos like mine or F-Droid's pick up your changes automatically. I gladly prepare a "starter package" for you with the "initial structures" – just let me know if you're interested.

[appml]

@IzzySoft Thanks a lot, I ran into problem getting Ruby on my aging machine so your Fastlane structures really helps. I've also added the badge to my Readme. It might take me a while to get all the graphic stuff fixed.

[IzzySoft]

Gladly done – and hey, looks fine already! As a personal opinion: I'd refrain from framing and "huge image sizes". Keep in mind most people browse using their mobile phones, so screen estate is quite limited. A large frame makes it hard to see the important details. For my repo, I usually cut off the frames and resize images to 350px on the small side. But YMMV, and it's totally up to you.

Structure looks fine with the images. So as soon as there's a new tag with Fastlane inside, your MR can be proceeded with.

[appml]

@IzzySoft Thanks for the suggestion! Let me look into that, probably it would take me a while to work through GIMP.

[IzzySoft]

If you want me to, I can send a PR with those screenshots I already have "gimped": where it was possible, I have them de-framed and resized. But that would of course only fit if you want to use the very same approach I outlined (de-framing and resizing to 350px).

[appml]

If you want me to, I can send a PR with those screenshots I already have "gimped": where it was possible, I have them de-framed and resized. But that would of course only fit if you want to use the very same approach I outlined (de-framing and resizing to 350px).

@IzzySoft Thanks for your help. That would be great.

[IzzySoft]

Sure, will do! You'd then just need to decide about the first screenshot. Maybe replacing it with a "frontal view"?

[appml]

@IzzySoft Replaced with a more "frontal view."

[IzzySoft]

Uh? Removed you mean: it were 6 screenshots (1-6) before, now it's 1-5 with the formerly 1st one gone and the others "renumbered". The initially first one is missing. Or am I looking in the wrong place?

[appml]

@IzzySoft sorry too much multitasking. Image is back.

[IzzySoft]

Ah! Yes. But didn't you want to replace it, quote, with a more "frontal view"? Shall that be done via GIMP – or do you still have the original, or want to create a new one?

[IzzySoft]

OK, deframed using GIMP (see #4).

[appml]

@CypherpunkSamurai Feel free to fork and try out different ideas / create your own version. Hope you enjoy working on it as much as I do.

All notes are stored as files, so should be pretty straightforward to add AES, etc.

[appml]

@IzzySoft Question: I saw the link https://f-droid.org/packages/com.appmindlab.nano in F-droid app, but got a 404 when entering the link in web browser.

[IzzySoft]

That's a statement, not a question 😄 Link works fine for me. Website is updated asynchronously, so maybe you checked too early.

[appml]

@IzzySoft Thank a lot!

[IzzySoft]

Gladly! As it's now on "F-Droid proper", I'd usually remove it from my repo after ~10d overlap. That OK with you – or do you have special needs so I shall keep it?

[appml]

Gladly! As it's now on "F-Droid proper", I'd usually remove it from my repo after ~10d overlap. That OK with you – or do you have special needs so I shall keep it?

@IzzySoft Please go ahead and take it off your repo. Many thanks for your help!

[appml]

@IzzySoft Sorry, another question is that based on this page, in order to issue app update to Fdroid, all I need is to create a new tag in this repo (I've set UpdateCheckMode: Tags already), is that the correct way? In other words, no need to create another merge request to fdroiddata?

Thanks in advance.

[IzzySoft]

Please go ahead and take it off your repo. Many thanks for your help!

Will do so towards the end of the month (to give users a chance to have their indexes updated). And gladly done!

all I need is to create a new tag in this repo (I've set UpdateCheckMode: Tags already), is that the correct way?

Usual routine: increase versionCode, adjust versionName => create a tag matching the defined pattern => Done. CheckUpdates should pick it then.

In other words, no need to create another merge request to fdroiddata?

Usually not, just if things fail (say, the "build recipe" changed, you moved the repo, or things like that). If you made a new release, and it didn't show up with the next 2 indexes, then it's worth checking. Find some useful URLs in my snippet here.

[appml]

Please go ahead and take it off your repo. Many thanks for your help!

Will do so towards the end of the month (to give users a chance to have their indexes updated). And gladly done!

all I need is to create a new tag in this repo (I've set UpdateCheckMode: Tags already), is that the correct way?

Usual routine: increase versionCode, adjust versionName => create a tag matching the defined pattern => Done. CheckUpdates should pick it then.

In other words, no need to create another merge request to fdroiddata?

Usually not, just if things fail (say, the "build recipe" changed, you moved the repo, or things like that). If you made a new release, and it didn't show up with the next 2 indexes, then it's worth checking. Find some useful URLs in my snippet here.

@IzzySoft Got it. Thanks.

[rancidfrog]

Releases are available.
Thank you