Bangle.js build flavor

gfwilliams commented

2022-03-23 14:08:47 +00:00

Member

This PR adds build flavors to build.gradle. The default is called main, but we also add banglejs which allows the building of an app called Bangle.js Gadgetbridge.

This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit.

Eventually the plan is to put this on the Google Play store, and to have additions in it which are good for Bangle.js users but would otherwise negatively impact normal Gadgetbridge users (a build flavor is used so we can keep the same codebase and not fork).

About naming - I'd mentioned Gadgetbridge for Bangle to @ashimokawa but thinking about how it would appear in the app store and Android apps list, it probably makes sense to call it Bangle.js Gadgetbridge so it's listed under B.... Happy to change or use something else if you have strong opinions though.

Note: adding build flavors seems to add the flavor name to existing builds. As a result, all other builds will now have main in the name. Unfortunately I didn't see another way around this, but hopefully it won't break anything.

This PR adds build flavors to `build.gradle`. The default is called `main`, but we also add `banglejs` which allows the building of an app called `Bangle.js Gadgetbridge`. This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit. Eventually the plan is to put this on the Google Play store, and to have additions in it which are good for Bangle.js users but would otherwise negatively impact normal Gadgetbridge users (a build flavor is used so we can keep the same codebase and not fork). About naming - I'd mentioned `Gadgetbridge for Bangle` to @ashimokawa but thinking about how it would appear in the app store and Android apps list, it probably makes sense to call it `Bangle.js Gadgetbridge` so it's listed under `B...`. Happy to change or use something else if you have strong opinions though. **Note:** adding build flavors seems to add the flavor name to existing builds. As a result, *all other builds will now have `main` in the name*. Unfortunately I didn't see another way around this, but hopefully it won't break anything.

gfwilliams added 6 commits 2022-03-23 14:08:48 +00:00

eddbde313b Bangle.js restrict icon size even if it's already a bitmap

2a53219a14 Bangle.js build flavor

c597adf27f Adding internet connectivity with 'http' Gadgetbridge event

FIXME - still needs a setting to enable that is off by default

cc9d9a16e2 rename application ID to com.espruino.gadgetbridge.banglejs

f43316fcd7 Merge branch 'master' of codeberg.org:Freeyourgadget/Gadgetbridge

ci/woodpecker/pr/can_master_build Pipeline is pending Details

f26f3b0a15 readme link tweaks

gfwilliams commented

2022-03-23 15:05:59 +00:00

Author

Member

Just two notes:

on my computer, builds of the banglejs build flavor are still called Gadgetbridge on the Android device regardless of what I do. Another developer tells me it works fine for them though and as far as I can see I've done everything right here.
As far as I can see, android studio sorts the build flavors alphabetically and chooses the first one as the default, so all developers would end up on 'banglejs'. Maybe it's worth renaming the flavor such that the default is always the main Gadgetbridge

Just two notes: * on my computer, builds of the banglejs build flavor are still called `Gadgetbridge` on the Android device regardless of what I do. Another developer tells me it works fine for them though and as far as I can see I've done everything right here. * As far as I can see, android studio sorts the build flavors alphabetically and chooses the first one as the default, so all developers would end up on 'banglejs'. Maybe it's worth renaming the flavor such that the default is always the main Gadgetbridge

gfwilliams commented

2022-03-24 14:00:58 +00:00

Author

Member

Someone does seem to have already used that I'm afraid (https://m.apkpure.com/banglebridge/de.bangle_bridge.bangle_bridge / https://banglejs.com/apps/?id=banglebridge) although I don't think their app is in the app store...

vanous commented

2022-03-24 17:52:44 +00:00

Owner

on my computer, builds of the banglejs build flavor are still called Gadgetbridge on the Android device regardless of what I do. Another developer tells me it works fine for them though and as far as I can see I've done everything right here.

hi @gfwilliams , thank you for the work and effort on the watch and now also on Java code :) !

Look here for the overwrite of the name:

https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/nopebble/res/values/strings.xml

As far as I can see, android studio sorts the build flavors alphabetically and chooses the first one as the default, so all developers would end up on 'banglejs'. Maybe it's worth renaming the flavor such that the default is always the main Gadgetbridge

This could maybe work? https://proandroiddev.com/android-set-a-default-build-type-flavor-a1cdcd1c15fa

> * on my computer, builds of the banglejs build flavor are still called `Gadgetbridge` on the Android device regardless of what I do. Another developer tells me it works fine for them though and as far as I can see I've done everything right here. hi @gfwilliams , thank you for the work and effort on the watch and now also on Java code :) ! Look here for the overwrite of the name: https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/nopebble/res/values/strings.xml > * As far as I can see, android studio sorts the build flavors alphabetically and chooses the first one as the default, so all developers would end up on 'banglejs'. Maybe it's worth renaming the flavor such that the default is always the main Gadgetbridge > This could maybe work? https://proandroiddev.com/android-set-a-default-build-type-flavor-a1cdcd1c15fa

vanous commented

2022-03-24 18:09:15 +00:00

Owner

This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit.

You need to think if you want this to be installable with regular Gadgetbridge in parallel. If yes, you will need to disable the Pebble provider by renaming it, like the "nopebble" build type does.

This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit> This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit

👍

Eventually the plan is to put this on the Google Play store, and to have additions in it which are good for Bangle.js users but would otherwise negatively impact normal Gadgetbridge users (a build flavor is used so we can keep the same codebase and not fork).

Yes, agreed.

About naming - I'd mentioned Gadgetbridge for Bangle to @ashimokawa but thinking about how it would appear in the app store and Android apps list, it probably makes sense to call it Bangle.js Gadgetbridge so it's listed under B.... Happy to change or use something else if you have strong opinions though.

I like the "Bangle.js Gadgetbridge" name. It keeps both project names intact and gives them full visibility and credits, leaves no confusion, points the users to correct search results and so on. Of course, in Android launcher, the name will be somewhat trimmed "Bangle.js Gadget..." i presume, so it should be tried. I mean... i probably like "Gadgetbridge for Bangle.js" more, but i know that this will create confusion in Android launcher because only "Gadgetbridge" part of the name will be visible and only the icon will actually differentiate the apps. I do not know if it makes sense to even add the "Network(ed)" into the name, for clarity of the users, but this does look a bit odd. So maybe it will be important to add to the description that ...this version has networking enabled to provide connectivity... The reason i say this to make sure we do not make the users think that Gadgetbridge has networking enabled by default... Maybe i am too worried too early :)

Note: adding build flavors seems to add the flavor name to existing builds. As a result, all other builds will now have main in the name. Unfortunately I didn't see another way around this, but hopefully it won't break anything.

I have to try it to see what this means.

>This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit. You need to think if you want this to be installable with regular Gadgetbridge in parallel. If yes, you will need to disable the Pebble provider by renaming it, like the "nopebble" build type does. > This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit> This will have internet connectivity, allowing Bangle.js watches to request data directly from the internet - and it's named so as hopefully not to be confused with the normal offline Gadgetbridge, while still giving credit 👍 > Eventually the plan is to put this on the Google Play store, and to have additions in it which are good for Bangle.js users but would otherwise negatively impact normal Gadgetbridge users (a build flavor is used so we can keep the same codebase and not fork). Yes, agreed. > About naming - I'd mentioned `Gadgetbridge for Bangle` to @ashimokawa but thinking about how it would appear in the app store and Android apps list, it probably makes sense to call it `Bangle.js Gadgetbridge` so it's listed under `B...`. Happy to change or use something else if you have strong opinions though. I like the "Bangle.js Gadgetbridge" name. It keeps both project names intact and gives them full visibility and credits, leaves no confusion, points the users to correct search results and so on. Of course, in Android launcher, the name will be somewhat trimmed "Bangle.js Gadget..." i presume, so it should be tried. I mean... i probably like "Gadgetbridge for Bangle.js" more, but i know that this will create confusion in Android launcher because only "Gadgetbridge" part of the name will be visible and only the icon will actually differentiate the apps. I do not know if it makes sense to even add the "Network(ed)" into the name, for clarity of the users, but this does look a bit odd. So maybe it will be important to add to the description that ...this version has networking enabled to provide connectivity... The reason i say this to make sure we do not make the users think that Gadgetbridge has networking enabled by default... Maybe i am too worried too early :) > **Note:** adding build flavors seems to add the flavor name to existing builds. As a result, *all other builds will now have `main` in the name*. Unfortunately I didn't see another way around this, but hopefully it won't break anything. I have to try it to see what this means.

gfwilliams commented

2022-03-24 19:56:15 +00:00

Author

Member

Hi @vanous, thanks!

Look here for the overwrite of the name:

Is that not what I do with app/src/banglejs/res/values/strings.xml? I checked by writing some garbage in there and the file is definitely parsed as part of the build, so I don't know why it's not having an effect for me :(

Good point about the Pebble provider and default build. I'll get those added.

I hadn't considered the name clipping in launcher, thanks! I think that definitely makes using Gadgetbridge something more of a problem. On one phone I'm using here even Gadgetbridge becomes Gadgetbri.... So I think for now Bangle.js Gadgetbridge seems sensible and I'll make sure networking is mentioned clearly in the docs.

I finally got the App Loader working inside Gadgetbridge too (not in this PR yet) so it should make a really big improvement to the usability of Bangle.js.

Hi @vanous, thanks! > Look here for the overwrite of the name: Is that not what I do with `app/src/banglejs/res/values/strings.xml`? I checked by writing some garbage in there and the file is definitely parsed as part of the build, so I don't know why it's not having an effect for me :( Good point about the Pebble provider and default build. I'll get those added. I hadn't considered the name clipping in launcher, thanks! I think that definitely makes using `Gadgetbridge something` more of a problem. On one phone I'm using here even `Gadgetbridge` becomes `Gadgetbri...`. So I think for now `Bangle.js Gadgetbridge` seems sensible and I'll make sure networking is mentioned clearly in the docs. I finally got the App Loader working inside Gadgetbridge too (not in this PR yet) so it should make a really big improvement to the usability of Bangle.js.

gfwilliams added 1 commit 2022-03-25 08:35:34 +00:00

ci/woodpecker/pr/can_master_build Pipeline is pending Details

fd69f85daa Disable pebble provider to allow Bangle.js Gagdetbridge to coexist with normal one. Make normal gadgetbridge the default project

gfwilliams added 1 commit 2022-03-25 08:44:58 +00:00

ci/woodpecker/pr/can_master_build Pipeline was successful Details

69aabf6d18 mention network access in about

gfwilliams commented

2022-03-25 09:10:57 +00:00

Author

Member

Ok, just added those tweaks.

However: I just tried building and uploading the Nightly/Nopebble releases from normal Gadgetbridge (without my changes) and I see the same thing - the app icon changes, but all apps are called 'Gadgetbridge' - strings.xml seems to be ignored.

Is it just me? I've tried on two separate PCs now each with fresh android-studio installs and I see the same thing!

Ok, just added those tweaks. However: I just tried building and uploading the Nightly/Nopebble releases from normal Gadgetbridge (without my changes) and I see the same thing - the app icon changes, but all apps are called 'Gadgetbridge' - strings.xml seems to be ignored. Is it just me? I've tried on two separate PCs now each with fresh android-studio installs and I see the same thing!

vanous commented

2022-03-25 13:59:04 +00:00

Owner

Ok, just added those tweaks.

However: I just tried building and uploading the Nightly/Nopebble releases from normal Gadgetbridge (without my changes) and I see the same thing - the app icon changes, but all apps are called 'Gadgetbridge' - strings.xml seems to be ignored.

Is it just me? I've tried on two separate PCs now each with fresh android-studio installs and I see the same thing!

I think i know what you mean. Do you mean the main activity (see below):

Look:

F-droid (i did not update icon in F-droid for the nightly):

Install (name and icon):

App name:

Main activity name:

You need to provide another string for the main activity. I do not do this particular one for the Nightly.

Launcher icons:

App info:

> Ok, just added those tweaks. > > However: I just tried building and uploading the Nightly/Nopebble releases from normal Gadgetbridge (without my changes) and I see the same thing - the app icon changes, but all apps are called 'Gadgetbridge' - strings.xml seems to be ignored. > > Is it just me? I've tried on two separate PCs now each with fresh android-studio installs and I see the same thing! I think i know what you mean. Do you mean the main activity (see below): Look: F-droid (i did not update icon in F-droid for the nightly): ![image](/attachments/f6f8eddd-eb58-4067-9747-6844abec0243) Install (name and icon): ![image](/attachments/965d21b0-d9a9-4d04-ac8e-84eff6d8b781) App name: ![image](/attachments/e8a7e2c1-3adf-4b2e-92a8-543436829c03) App name: ![image](/attachments/2c238a10-0637-4577-944a-f03d45183764) Main activity name: ![image](/attachments/4f3150e1-c577-4be5-bf9b-bc028ade7ad1) **You need to provide another string for the main activity. I do not do this particular one for the Nightly.** Launcher icons: ![image](/attachments/5a80e5be-82f6-4e8c-8790-d1b57b8d804a) ![image](/attachments/37200428-3d3c-4277-a493-05aff7ae4153) App info: ![image](/attachments/d8e8d92c-135e-4e6a-bfc0-6a17312ed5ea)

image.png

115 KiB

image.png

93 KiB

image.png

60 KiB

image.png

66 KiB

image.png

35 KiB

image.png

17 KiB

image.png

20 KiB

image.png

48 KiB

gfwilliams commented

2022-03-28 12:20:18 +00:00

Author

Member

Thanks! Actually that's not what I see - in the launcher, task manager, and permissions list, it just shows 'Gadgetbridge' for me for all apps (including Nightly).

Glad it's just me though, so this code should work fine for you. I'll dig deeper at my end - while I used different PCs I did rsync the folder, so maybe there's something else kicking around that is causing a problem.

Thanks! Actually that's not what I see - in the launcher, task manager, and permissions list, it just shows 'Gadgetbridge' for me for all apps (including Nightly). Glad it's just me though, so this code should work fine for you. I'll dig deeper at my end - while I used different PCs I did rsync the folder, so maybe there's something else kicking around that is causing a problem.

gfwilliams commented

2022-03-29 13:09:33 +00:00

Author

Member

Ok, so I found the problem with the app name - and it's not specifically related to my build system or this PR. It's translations.

It seems the order of priority for strings.xml is:

1st app/src/main/res/values-LANG/strings.xml
2nd app/src/BUILD_TARGET/res/values/strings.xml
3rd app/src/main/res/values/strings.xml

So I guess if you're in the USA you're fine, because there's no specific strings.xml language for you.

However outside of the USA, Nightly, Nopebble and now Bangle.js builds are all still just called 'Gadgetbridge' because pretty much every app/src/main/res/values-LANG/strings.xml has an app_name=Gadgetbridge line in it.

So I don't know what your thoughts are here. We could:

Delete app_name=Gadgetbridge from every translation file where there was no language-specific translation, so then the name of the other builds will appear correctly (apart from ml/ja/ko/fa where there do seem to be language-specific versions).
Come up with app/src/BUILD_TARGET/res/values-LANG/strings.xml files for every language that just override app_name with the right name

Personally I feel like the first option might be more sensible?

Ok, so I found the problem with the app name - and it's not specifically related to my build system or this PR. It's translations. It seems the order of priority for `strings.xml` is: * 1st `app/src/main/res/values-LANG/strings.xml` * 2nd `app/src/BUILD_TARGET/res/values/strings.xml` * 3rd `app/src/main/res/values/strings.xml` So I guess if you're in the USA you're fine, because there's no specific strings.xml language for you. However outside of the USA, Nightly, Nopebble and now Bangle.js builds **are all still just called 'Gadgetbridge'** because pretty much every `app/src/main/res/values-LANG/strings.xml` has an `app_name=Gadgetbridge` line in it. So I don't know what your thoughts are here. We could: * Delete `app_name=Gadgetbridge` from every translation file where there was no language-specific translation, so then the name of the other builds will appear correctly (apart from ml/ja/ko/fa where there do seem to be language-specific versions). * Come up with `app/src/BUILD_TARGET/res/values-LANG/strings.xml` files for every language that just override `app_name` with the right name Personally I feel like the first option might be more sensible?

vanous commented

2022-03-29 13:21:32 +00:00

Owner

First option seems ok, but let me add... i am in EU but my locale is not CZ as per my country, but rather US :)

$: locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Or perhaps this has to do with the phone lang? I need to try this, interesting...

First option seems ok, but let me add... i am in EU but my locale is not CZ as per my country, but rather US :) ``` $: locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= ``` Or perhaps this has to do with the phone lang? I need to try this, interesting...

gfwilliams commented

2022-03-29 13:33:04 +00:00

Author

Member

... It felt like translatable:false might be an option, but that doesn't seem to work (it might just be a lint thing?). I'm happy to do a PR with all the app_name=Gadgetbridge lines removed...

... It felt like `translatable:false` might be an option, but that doesn't seem to work (it might just be a lint thing?). I'm happy to do a PR with all the `app_name=Gadgetbridge` lines removed...

gfwilliams commented

2022-03-29 13:34:52 +00:00

Author

Member

Sorry - missed you last post @vanous.

Pretty sure it's phone language. Some translations don't have app_name defined (ar/lv/ta/hi) so if you happened to have one of them you'd be fine. The vast majority do though.

Sorry - missed you last post @vanous. Pretty sure it's phone language. Some translations *don't* have app_name defined (ar/lv/ta/hi) so if you happened to have one of them you'd be fine. The vast majority do though.

vanous commented

2022-03-29 16:32:20 +00:00

Owner

Confirmed here as well - when using non EN language on the phone, the app_name is Gadgetbridge. Two (other) options:

remove the translations
add a new string app_name_build_variant and set the app_name via code from this variant - thus allowing the name to be localized

Confirmed here as well - when using non EN language on the phone, the app_name is `Gadgetbridge`. Two (other) options: - remove the translations - add a new string `app_name_build_variant` and set the `app_name` via code from this variant - thus allowing the name to be localized

gfwilliams commented

2022-03-30 11:01:04 +00:00

Author

Member

Ok, great! Glad to hear it's not just me :)

So personally I'd say this was all good to merge if you're ok with it @ashimokawa?

App name issue:

I assume some people must use the translations?

You all know much more about Gadgetbridge/Android than me so I don't really know what the best route is, but I have a branch here with 'app_name' removed from translations (where it is not translated) and I can do a PR with that if needed.

Ok, great! Glad to hear it's not just me :) So personally I'd say this was all good to merge if you're ok with it @ashimokawa? App name issue: I assume some people must use the translations? You all know much more about Gadgetbridge/Android than me so I don't really know what the best route is, but I have a branch here with 'app_name' removed from translations (where it is not translated) and I can do a PR with that if needed.

ashimokawa commented

2022-03-30 19:30:49 +00:00

Owner

@gfwilliams

I think it is best to have multiple app names and all should be translatable.

Anyway I think I can merge this for now.

@gfwilliams I think it is best to have multiple app names and all should be translatable. Anyway I think I can merge this for now.

ashimokawa commented

2022-03-30 19:32:59 +00:00

Owner

@gfwilliams
Would you mind if I squash this into one commit?

@gfwilliams Would you mind if I squash this into one commit?

gfwilliams commented

2022-03-31 08:04:05 +00:00

Author

Member

Great!

Would you mind if I squash this into one commit?

No, not at all! Would you like me to squash subsequent PRs as well?

I think it is best to have multiple app names and all should be translatable.

Definitely. I'm not quite sure I understand how we'd handle that, but I'll start a new issue for it so as not to drag this one too off-topic.

Great! > Would you mind if I squash this into one commit? No, not at all! Would you like me to squash subsequent PRs as well? > I think it is best to have multiple app names and all should be translatable. Definitely. I'm not quite sure I understand how we'd handle that, but I'll start a new issue for it so as not to drag this one too off-topic.

gfwilliams referenced this pull request

2022-03-31 08:20:00 +00:00

Gadgetbridge app name for Nightly/Nopebble builds only changes for default US locale #2627

ashimokawa commented

2022-03-31 09:36:12 +00:00

Owner

@gfwilliams
No you do not need to pre-squash PRs, I have a button for that ;)

@gfwilliams No you do not need to pre-squash PRs, I have a button for that ;)