Variant cleanup, debug version and working towards store publishing

[eddyizm]

I noticed the 3 variants of which 2 seem identical,

• tempo <- this and play are the same?
• play <- guessing this was for when it was in the play store which it no longer is.
• notquitemy <- this does not appear to have the google play features/libraries, which perhaps was for fdroid or another the izzy store. This is the only one that has a different colored icon that makes it easy to have it installed side by side and visually see it is another app even though it is the same name.

I want to get some feedback and ideas from people that are contributing or want to contribute. Users as well since how they get the app and how we can get debug/test versions out is also important.

My thoughts are to just have one variant, tempo, create a debug variant with a different icon (possibly using notquitemy blue icon) with a 32bit and 64bit builds.

The concern is does removing the non-google variant, which is not being maintained, keep users away from using it?

I want to make some of these changes in the near future in part to get ready to change the app name/icon so it can get published again (hopefully) in google play along with the other places, like izzy droid/ fdroid.

---

EDIT: just published a release for notquitemy which is the degoogled version. So it seems like keeping that one is essential since the play services fail when used on graphene os for example.

[eddyizm]

potential new icon I found and like

[SinTan1729]

I like this one, but not sure how it'd look in a square version.

[zc-devs]

and circle

[eddyizm]

ok, used this tool that generates via the svg for different versions.

[eddyizm]

ok, here's another one that i had first suggested for LMS but it won't be used, perhaps we can use it here.

Although I can't recall where i found this one where as the one above I had found on a open source svg page.

[zc-devs]

I like current wave icon with capitalized T. The wave symbolizes the tempo, and the T is the first letter of Tempo / Tempus.
I would like to see a similar icon. However, the wave style could be reworked.

[eddyizm]

I like the current icon too but we would need something that would not confuse folks. Started a discussion with the dev from izzySoft CappielloAntonio/tempo#339
I could definitely use some graphic help because at this point I would just use whatever I could create easily.

[zc-devs]

I've seen it. That is why I said

the wave style could be reworked

---

I could definitely use some graphic help because at this point I would just use whatever I could create easily.

Understandable. I'm not a designer, unfortunately. Perhaps, AI helps...

[zc-devs]

have one variant
get published in google play and fdroid

Contradiction I can see here :)

The concern is does removing the non-google variant, which is not being maintained, keep users away from using it?

Personally, I use F-Droid variant currently and would like so in the future.

---

If I wanted to publish opensource application, I would start from deGoogled variant and would publish it on IzzyOnDroid, then F-Droid. Afterwards, I would consider to make Play variant and publish on there.

It is not like messenger, which is useless without push service (Google, Apple). We do not use (?) pushes here. And functionality tied with Google is optional.
Which one, BTW? Android Auto? Chromecast (isn't it RIP)? What else?

[eddyizm]

Contradiction I can see here :)

totally lol - I am still learning and understanding the codebase. I will add an edit because I think now that we should have 2 versions, a google version and a degoogled version. The 3rd variant was confusing me for sure. also the notquitemy name did not make anything clear to me so I will probably rename it when I do swap over.

Android Auto/Chromecast - Auto is getting more requests from what I can see and chromecast is very light. I could see myself dropping chromecast altogether as the app is really designed to listen to music away from your desk, rather than just using it as a remote control for your local collection at home.

[g3kk3r]

Chromecast support has been useful in my use case. My CDs stay safely in shelving units with rips stored on my Navidrome server. Some of the locations where I listen to my collection have Chromecasts. If it is a little used feature, I do understand Chromecast support being dropped.

[eddyizm]

Chromecast support has been useful in my use case. My CDs stay safely in shelving units with rips stored on my Navidrome server. Some of the locations where I listen to my collection have Chromecasts. If it is a little used feature, I do understand Chromecast support being dropped.

Yup, it's nice to have. I just don't know how many people use it need. With better understanding of the codebase, it does seem like we just need 2 variants, google/degoogled. I am hoping after a full rebrand, I can focus on getting it into the app store.

With chromecast, I at least have a device here at home to test with. The last update I was only able to dev and test successfully (even though it still has bugs) with it. Without it, it would have been impossible.

That is where Auto is, I have no way to test so I can't really make any changes yet. Spent a morning trying to read up and get a android auto emulator working without success and moved on.

I don't think I would drop it out right at this point, especially if I can get a version into google play.

Appreciate your feedback! (my cd's also stay safely stored on a spindle)

[Offerel]

As long as there is a version, which has Android Auto support, im fine with any version.

[eddyizm]

Well, the degoogled version doesn't have android auto support. So I intend to keep at least 2 versions. A google one and a degoogled one.

[JamesMowery]

Oh in that case (at least for me)... definitely want the Android Auto support! I have Tempo going on GrapheneOS and it works with Android Auto. Only thing that sometimes is finicky is the "Random" play option which I use all the time (honestly wish it was not all the way at the bottom of the play options). It feels like I often hit the "End" of the "Random" playlist, and it forces me to back out and start it up again. I'd just want "Random" to infinitely give me random songs from my library on Android Auto. :)

[eddyizm]

I don't use Graphene (I plan to if/when I get a new device, eg pixel) but from my understanding of the docs and other users, you can enable google play services by installing them but by default it doesn't have those libraries/features.

But yeah< I got to use Android Auto on my last holiday for a couple weeks and it was flipping sweet lol

[JamesMowery]

Feedback: add an explanation either to the repo readme (preferrably) or to the release notes for every release explaining what the difference is between the normal and notquitemy releases (at least until this is sorted). I struggled for so long to understand what it was (and, to be honest, I'm still not 100% sure).

Beyond that, I use Obsidian on Android to pull down the app directly from GitHub. Has been working pretty well (at least until this latest update. For some I can't pull the latest update.

[eddyizm]

I just started to release that variant when I noticed issues opened on graphene os - I guess he was pushing that update in some other way? I have not yet published to fdroid but once I get the changes needed, i will work on that. the notquitemy name really threw me off as well lol. I will add an note in the readme/release soon. I plan on renaming it though to something else eventually.

EDIT : I am just barely getting familiar with obtainium, not familiar with Obsidian, assuming it is a similar tool. Send me a link to docs and what errors you are getting, most of these have similar requirements.

[JamesMowery]

No worries! I'm also using GrapheneOS. Haven't noticed any issues, but maybe I'm just not paying attention enough. So maybe it's good that it exists! :D

I'm not getting an error, per se. It's just I attempt the update in Obtanium (as it is alerting me there is a new version) and the update runs and it installs v3.16.1 and it still says there is a new update available. Maybe the change in repository with adding the new variant broke the auto update functionality. I think Obtanium likes when the repo format stays the same. I'll try deleting and setting it back up again to see if that fixes it.

Update: I just nuked everything and started from scratch. It still installs v3.16.1 but says 3.16.6 is latest. Confirmed in Tempo's settings that the version is v3.16.1 So yeah, very strange.

[eddyizm]

@JamesMowery So it looks like the app is set at 3.16.1 (so the code is correct and you have the latest), - looks like i just F'ed up the tag since I did it in a hurry.

Will fix it later tonight or this weekend as I role in some new updates.

[eddyizm]

I might need some help with screenshots for radio and podcasts. Is anyone open to helping with those?

I started making some documentation updates on #182 that will merge once I get the application updates done. Those have been challenging.

@IzzySoft -> Making the minimal changes to speed up the process, I am hoping I can leave the namespace alone without changing much of the structure
namespace 'com.cappielloantonio.tempo'
while updating the application id
applicationId 'com.eddyizm.tempus'

As far as the fastlane stuff, I updated what was already existing, updated the icon.png and cleared out the change history, starting with a new version that will be initial release. let me know if that works. I also did not see any other graphics besides the screenshots (which I still need to add/update) that are described in the fastlane docs such as featureGraphic and tvBanner so I'm assuming not having those is ok.

[IzzySoft]

Making the minimal changes to speed up the process, I am hoping I can leave the namespace alone without changing much of the structure

That should be possible, yes. IIRC, I've seen a similar approach with several other forks (or other apps) already.

As far as the fastlane stuff, I updated what was already existing

Guess you didn't push those changes yet? Latest changes there are shown as being from last year. But yes, the approach is fine; we mostly care about shortdesc,fulldesc,icon,screenshots – all else is "nice to have". A featureGraphic is in the tree, though (it will be shown in tha Android clients as "header background" in the app details, if it exists).

[eddyizm]

Perfect, that will make it easier to move over. And sorry, I had posted this before your mention but the fastlane changes are in this pr #182 -> not quite done eg still need screenshots and stuff.

Oh, and the other thing I thought about after reading more the docs. I realize, at this point, since I am swapping the application ID. I'm going to bump the version to 4.0 (UI facing) however since it will be a new app in the droid system, I can probably go back and start at versionCode 1 right?

Thanks for your response! I will hopefully have it ready in the very near future.

[IzzySoft]

Yes, as it's a new app, you can start over with versionCode: 1.

All the best for the move – just let me know when you're ready (or when other questions pop up).

[eddyizm]

ok all. I got a post here with a alpha apk version for testing before release if anyone is wanting to check it out and do some light testing. Going to close this discussion.
#185