5 ms·

now more devs need to start releasing APK's of their apps directly on their websites.

kevincox 6y ago
We also need an alternative to Google Push notifications. I think it would be cool to implement a similar system on top of the Web Push API. This overs e2e encrypted push with existing clients. We would just need to define the Java client API.
- eulenteufel 6y ago
  There is https://bubu1.eu/openpush/ https://bubu1.eu/openpush/ but I am not sure what the current status is.
  - kevincox 6y ago
    I've seen it but it seems to be mostly idle. And they are defining a new server-to-server API instead of using Web Push which seems like unnecessary duplicated work and requires new server-side client libraries and server implementations. Furthermore they don't support e2e encryption yet.
    - Hitton 6y ago
      Aren't web push notifications ineffective (especially battery-wise) compared to google's?
      - kevincox 6y ago
        No. Web Push Notifications are basically a protocol. They define three main things 1. A JavaScript API for retrieving a notification endpoint and configuration 2. A JavaScript API for receiving notifications 3. An HTTP API for sending notifications. Notably absent is a method for connecting that HTTP API to the JavaScript receiver. This is independent of the Web Push protocol and how it is implemented will affect the performance. For example Chrome on Android will use Google's regular push infrastructure (or at least a wrapper around it) and will have the same performance. You could implement this part via polling but the performance will be terrible. So to make a replacement for Google's push system on Android you would need to rewrite 1 and 2 (possibly just translating the JavaScript browser API to Java) and you would need a push server implementation as well as a client to run on the phone. This client is where you take care. But as long as you run one client per device it should perform similarly to Google's solution. The main problem would be if every app ran their own client, but that isn't what is expected. The phone should provide the push server information to the app (which hands it over to the server) so that all apps on the device use the same server. Sure, you are still implementing a lot, but the thing is that websites and services already have ways to store these push endpoints in the DB as well as encrypting the messages and sending them. It would be a lot less work to get them to do a little client-side work so that they app uses the same codepath as their webapp than making changes to their whole stack to support a new protocol.
        Hitton 6y ago
        Thanks for detailed explanation. It's much clearer to me now.
postsantum 6y ago
That's a bannable offense according to Google's policies
- Mediterraneo10 6y ago
  Could you cite that, please? Signal provides both a Google Play install and an APK directly downloadable from its website. And of course loads of apps are on both Google Play and F-Droid. So, I’m assuming that Google’s policies forbid providing directly download of APKs that are inextricably based on Google Play Services, but it would be nice to see the actual text.
  - postsantum 6y ago
    Mostly from personal experience, also saw a few similar cases on Reddit. The banned app had a link to the app's website which, in turn, had a link to xda forum where the very same apk was hosted. Here is the rule quoted in the suspension email: "Apps or third party code (e.g., SDKs) that download executable code, such as dex files or native code, from a source other than Google Play." If someone thinks it's an overreach, read about cases when apps were banned due to a link to another Google Play app from the same developer [1] [1] https://www.reddit.com/r/androiddev/comments/atsju7/linking_to_your_own_apps_leads_to_suspension_and/ https://www.reddit.com/r/androiddev/comments/atsju7/linking_...
    - Mediterraneo10 6y ago
      Yes, so this is apparently banning linking to third-party sources of executable code from within apps, not simply making an APK available from multiple sources.
      - postsantum 6y ago
        Sure, if you frame it like this. But it's not what a developer would think of when linking to online tutorials from within the app
    - 6y ago
solarkraft 6y ago
While this is certainly a welcome option, third party app stores like F-Droid work just fine. The main repository contains only free software compiled by the F-Droid team, but other user-addable repositories can contain anything. Additionally it is already possible to download APKs as they are hosted on Google Play from sites like apkmirror.com and you can even install the Play Store if you have microG and are so inclined. There's no lack of app distribution :-)

We also need an alternative to Google Push notifications. I think it would be cool to implement a similar system on top of the Web Push API. This overs e2e encrypted push with existing clients. We would just need to define the Java client API.

eulenteufel 6y ago
There is https://bubu1.eu/openpush/ https://bubu1.eu/openpush/ but I am not sure what the current status is.
- kevincox 6y ago
  I've seen it but it seems to be mostly idle. And they are defining a new server-to-server API instead of using Web Push which seems like unnecessary duplicated work and requires new server-side client libraries and server implementations. Furthermore they don't support e2e encryption yet.
  - Hitton 6y ago
    Aren't web push notifications ineffective (especially battery-wise) compared to google's?
    - kevincox 6y ago
      No. Web Push Notifications are basically a protocol. They define three main things 1. A JavaScript API for retrieving a notification endpoint and configuration 2. A JavaScript API for receiving notifications 3. An HTTP API for sending notifications. Notably absent is a method for connecting that HTTP API to the JavaScript receiver. This is independent of the Web Push protocol and how it is implemented will affect the performance. For example Chrome on Android will use Google's regular push infrastructure (or at least a wrapper around it) and will have the same performance. You could implement this part via polling but the performance will be terrible. So to make a replacement for Google's push system on Android you would need to rewrite 1 and 2 (possibly just translating the JavaScript browser API to Java) and you would need a push server implementation as well as a client to run on the phone. This client is where you take care. But as long as you run one client per device it should perform similarly to Google's solution. The main problem would be if every app ran their own client, but that isn't what is expected. The phone should provide the push server information to the app (which hands it over to the server) so that all apps on the device use the same server. Sure, you are still implementing a lot, but the thing is that websites and services already have ways to store these push endpoints in the DB as well as encrypting the messages and sending them. It would be a lot less work to get them to do a little client-side work so that they app uses the same codepath as their webapp than making changes to their whole stack to support a new protocol.
      - Hitton 6y ago
        Thanks for detailed explanation. It's much clearer to me now.

postsantum 6y ago

That's a bannable offense according to Google's policies

Mediterraneo10 6y ago
Could you cite that, please? Signal provides both a Google Play install and an APK directly downloadable from its website. And of course loads of apps are on both Google Play and F-Droid. So, I’m assuming that Google’s policies forbid providing directly download of APKs that are inextricably based on Google Play Services, but it would be nice to see the actual text.
- postsantum 6y ago
  Mostly from personal experience, also saw a few similar cases on Reddit. The banned app had a link to the app's website which, in turn, had a link to xda forum where the very same apk was hosted. Here is the rule quoted in the suspension email: "Apps or third party code (e.g., SDKs) that download executable code, such as dex files or native code, from a source other than Google Play." If someone thinks it's an overreach, read about cases when apps were banned due to a link to another Google Play app from the same developer [1] [1] https://www.reddit.com/r/androiddev/comments/atsju7/linking_to_your_own_apps_leads_to_suspension_and/ https://www.reddit.com/r/androiddev/comments/atsju7/linking_...
  - Mediterraneo10 6y ago
    Yes, so this is apparently banning linking to third-party sources of executable code from within apps, not simply making an APK available from multiple sources.
    - postsantum 6y ago
      Sure, if you frame it like this. But it's not what a developer would think of when linking to online tutorials from within the app
  - 6y ago

solarkraft 6y ago

While this is certainly a welcome option, third party app stores like F-Droid work just fine. The main repository contains only free software compiled by the F-Droid team, but other user-addable repositories can contain anything. Additionally it is already possible to download APKs as they are hosted on Google Play from sites like apkmirror.com and you can even install the Play Store if you have microG and are so inclined. There's no lack of app distribution :-)