Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Card suggestion based on location #456

Open
TheLastProject opened this issue Oct 5, 2021 · 12 comments
Open

Card suggestion based on location #456

TheLastProject opened this issue Oct 5, 2021 · 12 comments
Labels
common: uncommon Most users are unlikely to come across this or unexpected workflow severity: tolerable Low/no impact on users state: help wanted I looked into this issue but couldn't solve it quickly type: enhancement New feature or request

Comments

@TheLastProject
Copy link
Member

TheLastProject commented Oct 5, 2021

It would be interesting to store a combination of:

  1. Timestamp
  2. GPS coordinates
  3. Card ID

And whenever a card is opened, save a new entry to this.

Then, we could every 5 minutes or so check the current GPS coordinates and suggest a card that matches nearby coordinates.

For example:
You go to the grocery store, and open your grocery store card. Catima stores the GPS location where you opened the card. So, the next time you go to the grocery store, Catima can create an Android notification telling you that it thinks you're at the grocery store and allowing you to open the grocery store card with a single tap.

This is more of an experiment and will need a lot of tweaking to figure out how to make it helpful but not creepy (even though we will of course not send any data online, we don't want to scare any user). And of course this should be fully optional.

@TheLastProject TheLastProject added the type: enhancement New feature or request label Oct 5, 2021
@djechelon
Copy link
Contributor

djechelon commented Oct 6, 2021

Geofence API doesn't require you to check GPS every x minutes. Android does it for you. Nuki app saves battery using this API. No data is sent to any server. When Android detects a location change it automatically (and battery-efficiently) checks if a fence was trespassed and sends a broadcast to the application.

I haven't used this API yet.

Consider that unless you buy at the same shop(s), you may want to add the locations of all shops of the same brand in your region.

Consider that most users consider creepy to allow permanent GPS access, but being an optional feature it's not a problem to refuse.

My experience: I don't have problems with loyalty cards (the cash attendant often asks me if I own a card), but rather with discount coupons. I forgot to show some precious coupons often.

@TheLastProject
Copy link
Member Author

Look at https://developer.android.com/training/location/geofencing... that looks perfect! Definitely the correct way to implement this.

Hmm, your coupon situation makes sense. Maybe it's best if users can add locations and then to each card you could add zero or more locations, like you can currently manage groups. That way the user stays in complete control and there is no magic.

@djechelon
Copy link
Contributor

Related to: #89

If a database of stores is created, their retail points can be mapped even by the use of public scraping. There is a limit on concurrent geofences but that's a later-stage problem

@TheLastProject
Copy link
Member Author

@djechelon
Copy link
Contributor

I don't know if dependency on GMS is totally forbidden for F-Droid apps, or an application can have an optional dependency to Google stack, which means if you don't have it you don't have the feature

@TheLastProject
Copy link
Member Author

Not forbidden, as long as no non-free libraries are added. And there is microG. But I would prefer to avoid any GMS dependency in any way whenever possible. Just something I will need to research deeper to know exactly what decision we'll be making if we use this.

@djechelon
Copy link
Contributor

Not forbidden, as long as no non-free libraries are added

My apologies, but I don't know if depending on that library causes the app to be banned from F-Droid. Please read further, this detail is important.

I don't like microG, if I can avoid it, and here is an explanation.

From the user's standpoint, microG is some kind of duplicate of Google Play libraries that also may require you (Youtube Vanced) to set up another instance of the same Google account.

So I have logged in from the same account and same device... twice. My Google Account control panel looks confusing then.

My best expectation was that Google publishes GMS APIs open source. They are just f***n APIs. And then if the device is shipped with Google Play services, the APIs will find their implementation and work as expected, otherwise the implementor must handle an exception. It turns into the decision of 1) not providing the service or 2) offering an alternate means to provide implementation

For Catima, that turns into a choice:

  • What if the user runs an Android device with Play Services and downloads the app from Play Store with a Google Account? Can use GMS
  • What if the user downloaded Catima from F-Droid but still owns the Google Play stack? Can use GMS
  • What if the user is running a debloated (Google-free) device? Will Catima break or provide the service with a different API? Or offer to download microG?

How many Catima users are running a Google-free device? Is that audience worth additional effort? I discussed such a question for a government app, where it is certain that, at the current time, the vast majority of users overwhelm the few that might use a Google-free phone (though we don't have data available to support any of the statements).

In the case of Vanced, since Play Services checks for the calling application to be stock YouTube, the authors were forced to depend on microG.

Personally, since I am not a content creator, I even wonder why I am really using microG APIs in the first place with Vanced. I use it only to watch Incognito ad-free videos. And really, I turn on Incognito every single time.

@TheLastProject
Copy link
Member Author

How many Catima users are running a Google-free device? Is that audience worth additional effort?

I honestly don't know, but I don't like making any part of Catima work only on Google-approved Android installations. It pushes people towards choosing between convenience or control and privacy. Sure, it won't affect 99.9% of users but Catima exists to give people a libre and privacy-friendly alternative to apps like Stocard, depending on anything Google for that just feels wrong.

If it needs GMS or microG, I kinda would only want it if microG also bundles a library you can use (like how covid apps can still work on completely Google-free devices by including a library into the app itself).

@djechelon
Copy link
Contributor

djechelon commented Oct 6, 2021

I get your point and I agree about how bad the requirement is to work only on Google-bloated devices.

But my view was about effort required vs the result (how many people reached by the feature, or using it).

Your point, if I interpret correctly, is that you don't like to offer a feature if that has limitations. All or none. Not even a warning "feature is currently unavailable". That is a good point and the best way to offer privacy.

Then, we could think about getting the best of both worlds if it was ever possible

  1. If user has Google suite, offer to use it
  2. If the user doesn't want geolocation/geofencing, don't require to install extra apps
  3. If the user doesn't have Google suite, offer to install a third party open source app
  4. Don't break existing app functionality

Of course if it was possible to use geofencing with a 3rd party open source library, voilà, we are done 🧙‍♂️

But again, it is important to understand if it is legal to link an application to GMS and distribute it over F-Droid, even when providing an alternate to non-GMS users.

I don't know if you get my view over this.

@TheLastProject
Copy link
Member Author

But again, it is important to understand if it is legal to link an application to GMS and distribute it over F-Droid, even when providing an alternate to non-GMS users.

Well, that is the thing, it depends solely on the app source code. If it is a libre library, it's fine, if it requires a proprietary library to talk to GMS, that's not okay. Using GMS itself is not really something that changes acceptance on F-Droid (but REQUIRING it to work means you get the NonFreeDep antifeature, as GMS is proprietary).

@ycodryn
Copy link

ycodryn commented Oct 26, 2021

Keep it simple and lightweight please. If I want bloatware I will use stocard and many other alternatives. I dont need a location to see what cards Im having.

@famewolf
Copy link

famewolf commented Dec 31, 2021

Keep it simple and lightweight please. If I want bloatware I will use stocard and many other alternatives. I dont need a location to see what cards Im having.

Assuming you have 1 vote, I'll vote the opposite thus making both null and void. While I prefer privacy I'd much rather have an open source app use my location all the time to show cards/coupons etc when I enter a store than proprietary like stocard. I find the feature useful. You have the option to not enable the feature. I also use stocard to hold all my GIFT CARDS and I'm constantly forgetting to use them so I just enabled this exact feature in stocard.

@TheLastProject TheLastProject added common: uncommon Most users are unlikely to come across this or unexpected workflow severity: tolerable Low/no impact on users state: help wanted I looked into this issue but couldn't solve it quickly labels Feb 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
common: uncommon Most users are unlikely to come across this or unexpected workflow severity: tolerable Low/no impact on users state: help wanted I looked into this issue but couldn't solve it quickly type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants