Fdroid version

[theuser18]

It would be great if this app was also on Fdroid!

[Poussinou]

Hi @alialbaali

Are you ok with the inclusion of this app ? We could take care of the rest.

[alialbaali]

I'm fine with publishing the app to F-Droid. However, In the next couple of releases, Noto will hopefully support internet data backup, and I'm not sure yet how it's going to be done. I'm looking for BaaS platforms such as Firebase and Appwrite and I still haven't decided yet (still researching). Note that, I probably won't go with Firebase since I want Noto to be degoogled.

If you have any platforms you recommend, I'll be really glad to hear about them, as it would help a lot.

From my knowledge, apps that use Google Services (such as Firebase) are not allowed in F-Droid. So, I want to finish implementing data backup first, then I will definitely publish to F-Droid if possible.

[Poussinou]

There is no closed-source/non-free library allowed in apps that pretend to be on F-Droid, sorry :/

I never heard about a BaaS (Banking-as-a-Service) which is free and open-source, but maybe @IzzySoft heard about something like that?

[IzzySoft]

No. The only banking app we have at F-Droid is provided by a bank, but it's just the 2FA (not the banking itself).

But sure you've interpreted BaaS correctly, @Poussinou? @alialbaali compares it to Firebase. And if it's a replacement for Firebase, I'd indeed have something to link to: Supabase. Or, if it's just Cloud Notifications you're after, there's @UnifiedPush (with existing F-Droid support already, see my list on Push Clients/Manager. UP gives a lot of flexibility, with the users being able to choose their preferred "cloud service".

[alialbaali]

By BaaS, I meant Backend-as-a-Service

[Poussinou]

Sorry I misunderstood...

[IzzySoft]

So my irritation was warranted 🤣 – and what's more important, the two hints given fully apply. Take a look at Supabase then – "backend" sounds like you need more than just notifications.

PS: I love Bakery-as-a-Service. Especially when they deliver fresh-and-hot directly to the breakfast table. And if they can't make it in time, there's always Brewery-as-a-Service for the evening… 🙈

PPS: Unfortunately, more than those I daily see a lot of Bullshit-as-a-Service 🙊 💨

[alialbaali]

It's fine, I was trying to correct @Poussinou for considering the term as (Backend-as-a-Service), no biggie.

I'm looking for something like Firebase but degoogled, since I want users to be able to backup their data to the cloud. You're suggesting Supabase, and there's also Appwrite, what do you think of both of them? Are there any other alternatives that worth to look at?

Note that, the app business model might change depending on the implementation, If the implementation would be something like Firebase, then it would offer 3 options:

1. Unlimited content (libraries, notes, etc.) with only local backup. (Totally free, like its current state)
2. Limited content with cloud backup (Totally free)
3. Unlimited content with cloud backup (Monthly/Yearly premium subscription, to cover the costs of hosting)

Otherwise, you have mentioned in the previous comment that there's an option to let users choose their preferred cloud service. Could you elaborate more on this, please? And is UP the only platform that supports that?

Let me know also if any of that would interfere with publishing to F-Droid.

[IzzySoft]

It's fine, I was trying to correct @Poussinou for considering the term as (Backend-as-a-Service), no biggie.

Sure, I got that – I was just joking (couldn't help myself). @Poussinou knows me long enough to also know this was not making fun of him (at least I hope so).

since I want users to be able to backup their data to the cloud

I always tend to leave each task to its own app. If I want to backup stuff off-device, I have an app doing that (e.g. syncing the backup folder to my Nextcloud or other computer). Why should each app include the same functionality redundantly? Though I have to admit that currently, at least to my knowledge, no FOSS sync app for WebDAV/rsync exists. So should you think about a separate app for that, count me in: I'd definitely give that a try and might even "sign up" as tester!

there's also Appwrite

Oh, didn't know about that – thanks for the pointer, added to my snippet right away! As for what I'm thinking about the two: good to have them 😄 I didn't take a deep look, haven't heard much from developers/users on them, and have no experiences with them myself.

The options sound totally fine! Average Jane & Joe can have their care-free free variant – and who needs more can have it as well. Plus, you can cover your costs. A clear win for all.

an option to let users choose their preferred cloud service

I was talking about UnifiedPush, which is just for cloud notifications. There are several providers available for that, details behind the link I gave (which goes to my website). But with things like WebDAV, that would be true s well (at least for "cloud storage"), as there are many different services offering access via WebDAV. Nextcloud/ownCloud are just some of them.

Let me know also if any of that would interfere with publishing to F-Droid.

Firebase would. I see no reason why Supabase or Appwrite would – but then, we didn't yet have an app using those, so I cannot yet tell about possible dependencies being dragged in. A quick look at Appwrite's build.gradle doesn't show any.

[alialbaali]

Hi @IzzySoft

I'm wondering if there's any way where I could upload the latest information/data to the app in this repo?

Currently, it's showing outdated screenshots, and information.

[IzzySoft]

May I recommend you my Fastlane Cheat Sheet and ask you to establish the described structure – then let me know when it's there? Then, once I've enabled that on my end, all future changes would be pulled along with their respective release 😉

[alialbaali]

Got it! Thank you so much :)

[IzzySoft]

Great! Then I'm waiting for your next ping when Fastlane is there, so I do my part of the job on my end 😃

[alialbaali]

Hey @IzzySoft,

So, I decided to publish Noto to the main F-Droid repository. In the past few days, I managed to set up the metadata file, along with the fastlane structure. However, I have few questions, and I'd appreciate any answers before opening an MR on GitLab.

1. I tag every release in Noto, even non-stable ones (Beta & RC). I couldn't find a way to distinguish these releases/builds in the metadata file. If I include the latest Beta/RC release, the checkupdates job fails, due to an error saying something like latest build receipt is newer than version code 54, and then the job updates the CurrentVersion & CurrentVersionCode to the Beta/RC version, which I don't believe is the right solution. Since I would like the Beta/Release builds to be optional, and not the default. Is there a proper solution for this?

Sample of the metadata file:

...
Builds:
  - versionName: 2.2.3
    versionCode: 54
    commit: v2.2.3
    subdir: app
    sudo:
      - apt-get update
      - apt-get install -y openjdk-17-jdk-headless
      - update-alternatives --auto java
    gradle:
      - yes

  - versionName: 2.3.0-RC
    versionCode: 58
    commit: v2.3.0-RC
    subdir: app
    sudo:
      - apt-get update
      - apt-get install -y openjdk-17-jdk-headless
      - update-alternatives --auto java
    gradle:
      - yes

AutoUpdateMode: Version
UpdateCheckMode: Tags ^v[\d.]+$
UpdateCheckData: buildSrc/src/main/java/Dependencies.kt|VersionCode\s=\s(\d+)|.|VersionName\s=\s"(.+)"
CurrentVersion: 2.2.3
CurrentVersionCode: 54

2. What's the flow of publishing a new version after everything is set up, meaning in which order should things go? Do I update the metadata file every release, or do I just add changelog files, is there any automation for getting translated changelog strings into their respective version files (54.txt, 55.txt, etc...), or should this be done manually? All I see from fastlane, is that it manages publishing binaries, and capturing screenshots, is there other tools/actions I should be aware about?

3. In your Cheat-Sheet, one of the notes says:

if you have fastlane structures on multiple matching locations, F-Droid will merge them. This is especially helpful if you use fastlane supply to deploy to Google Play, which does not support ISO-639 language codes (like en or de) but insists on localized ones (en-US, en-UK, de-DE, de-AT etc): keep the ones to be used with fastlane supply in one location, and have the "simple ones" in another.

In this case, do I create two locations, and copy everything manually or is there a specific tool to be used to separate the structures between Play Store and F-Droid?

4. Last question is, when I implement cloud functionality using Supabase/Appwrite, do I need to have a different flavor for F-Droid? AFAIK, Supabase & Appwrite are open-source. However, I'm not sure about the underlying backend (AWS) being fully open-source or not.

Thank you, and sorry for bothering you with my questions 🙂

[IzzySoft]

1. you should only include the latest release. When first listing an app on F-Droid, there's no sense in adding old ones. If you want to have some builds skipped (e.g. not publish beta releases), use different prefixes for your tag names for them not matching what you defined with UCM.
2. do everything but tagging, and only create a new tag once everything is ready.
3. I've never played with that, it's just what I've been told. But if you use build flavors, e.g. gplay for the PlayStore build and fdroid for the F-Droid build, you can have separate Fastlane trees, one per flavor.
4. if the backend is bound to a non-free server, you'll at worst get the NonFreeNet anti-feature.

[alialbaali]

Thank you for the answers, really appreciate it!

[alialbaali]

Great! Then I'm waiting for your next ping when Fastlane is there, so I do my part of the job on my end 😃

@IzzySoft, the repository now has the desired fastlane structure. 😃

[IzzySoft]

Thanks! Integrating it here. Notes:

full_description.txt: paragraphs should be separated with empty lines to render properly as Markdown. Currently, e.g. lines 1+2 would form a single paragraph. You could also use "simple HTML" (e.g. wrapping paragraphs in <p></p>) if you wish. I'd suggest to start with a full paragraph (like the current listing in my repo has it), then make your list a, well, list (<ul>).

<b>Noto</b> is a simple note-taking app that lets you organize your notes into libraries with different colors and icons. You can create and manage your notes easily, Auto Save, Archive Notes and more.

* <b>Ad-free:</b> We all hate ads. Well, Noto doesn't have any, and it never will. Enjoy the full experience without any ads and free of cost.
* <b>Open source:</b> Noto is an open-source application. You can view its source code on GitHub at anytime using this <a href="https://www.github.com/alialbaali/Noto">link</a>
* …

and so on (though it's quite stating the obvious for an app in a repository with only open source apps to state it's open source – but I guess you'll use the same for PlayStore, and that's why it's there?)

All else is now enabled and will be pulled along with each new release from now on. For the full description, I wanted to wait for your decision on formatting.

[alialbaali]

Are you suggesting I do it like this?

<big><b>Ad-free</b></big>
<p>We all hate ads. Well, Noto doesn't have any, and it never will. Enjoy the full experience without any ads and free of cost.</p>

though it's quite stating the obvious for an app in a repository with only open source apps to state it's open source – but I guess you'll use the same for PlayStore, and that's why it's there?

Correct. I have it there since I'm using it in the Play Store too.

All else is now enabled and will be pulled along with each new release from now on. For the full description, I wanted to wait for your decision on formatting.

Thank you!

[IzzySoft]

Are you suggesting I do it like this?

If you want to use HTML directly?

<ul><li><b>Ad-free:</b> We all hate ads. Well, Noto doesn't have any, and it never will. Enjoy the full experience without any ads and free of cost.</li></ul>

For F-Droid.org, ideally the entire description is in one line then, as there each \n would otherwise be replaced by a <br>. For my repo, my updater takes care for it – and the above Markdown would be fine as well.

[smaragdus]

@alialbaali

Why aren't the new versions appearing on F-Droid? The latest version there is still 2.2.3 (54).

[IzzySoft]

UpdateCheckData: buildSrc/src/main/java/Dependencies.kt|VersionCode\s=\s(\d+)|.|VersionName\s=\s"(.+)"

That file no longer exists, so the new versions cannot be found. Probably should be changed to

UpdateCheckData: buildSrc/src/main/java/App.kt|VersionCode\s=\s(\d+)|.|VersionName\s=\s"(.+)"

Done that here now. CI shows CheckUpdates now finds the latest release, so I've added that as well to speed up things (i.e. so we don't have to wait for the next CheckUpdates run as well). But now the build fails for the latest version.

@alialbaali is that someone you can fix on your end? I'm no Android dev, so I'm lost with that:

:jar: No valid plugin descriptors were found in META-INF/gradle-plugins
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project 'Noto'.
> Could not resolve all files for configuration ':classpath'.
   > Could not resolve androidx.navigation:navigation-safe-args-gradle-plugin:2.7.0.
     Required by:
         project :
      > No matching variant of androidx.navigation:navigation-safe-args-gradle-plugin:2.7.0 was found. The consumer was configured to find a library for use during runtime, compatible with Java 11, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.3' but:
          - Variant 'apiElements' capability androidx.navigation:navigation-safe-args-gradle-plugin:2.7.0 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component for use during compile-time, compatible with Java 17 and the consumer needed a component for use during runtime, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'runtimeElements' capability androidx.navigation:navigation-safe-args-gradle-plugin:2.7.0 declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 11
              - Other compatible attribute:
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')
          - Variant 'sourcesElements' capability androidx.navigation:navigation-safe-args-gradle-plugin:2.7.0 declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 11)
                  - Doesn't say anything about its elements (required them packaged as a jar)
                  - Doesn't say anything about org.gradle.plugin.api-version (required '8.3')

Did you maybe switch to Java17? Oh, indeed:

const val JdkVersion = 17

OK, let me give that a try then (oops, my team mate just did that now 🙈 Which means I was on the right track). Builds now – but is no longer reproducible:

==== detail begin ====
verification of APK with copied signature failed
Comparing reference APK to APK with copied signature...
Unexpected diff output:
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/3n.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/3n.png differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/At.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/At.png differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/CO.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/CO.png differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/Ed.xml and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/Ed.xml differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/FM.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/FM.png differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/Qx.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/Qx.png differ
Binary files /tmp/tmpz0poyg69/tmp_binaries_com.noto_61.binary/content/res/y0.png and /tmp/tmpz0poyg69/_tmp_tmpz0poyg69_sigcp_com.noto_61/content/res/y0.png differ
==== detail end ====

For consultation: HOWTO: diff & fix APKs for Reproducible Builds. Relevant details:

PNG optimisation/generation is often not reproducible.

Links:

• PNG Crush/Crunch;
• PNGs generated from vector drawables.

Can you please take care for that, @alialbaali? Once the PNGs are fixed, I guess the XML will be fixed automatically (guessing at checksums being stored there).

[obfusk]

I guess the XML will be fixed automatically (guessing at checksums being stored there).

The XML is different b/c upstream's APK has one more locale than the one from CI:

 <locale-config xmlns:android="http://schemas.android.com/apk/res/android">
   <locale android:name="en-US" />
   <locale android:name="ar" />
@@ -6,7 +6,6 @@
   <locale android:name="de" />
   <locale android:name="es" />
   <locale android:name="fr" />
-  <locale android:name="id" />
   <locale android:name="in" />
   <locale android:name="it" />
   <locale android:name="ko" />

[alialbaali]

Why aren't the new versions appearing on F-Droid? The latest version there is still 2.2.3 (54).

I'm still waiting for some feedback regarding this issue.