dazinism: ah wow, this is fantastic information. If I can digest it successfully it'll help me explain to devs why Holochain-on-mobile has a challenging future... and also, apparently, why it's not such a lost cause as I thought?

Looks like the key here is TCP, and I'm guessing that the WiFi and various mobile standards allow for a connection that remains open yet allows the device to enter a low-power state that waits for an incoming packet before it fully wakes up? Is the same also possible with stateless, socketless UDP (e.g., QUIC protocol)?

One thing I'm curious about is, how do these apps that don't use Google's push notification service stay alive in the background? I thought that was expressly forbidden, and indeed made impossible, by the Android SDK. I'm not much of a dev anymore, but perusing the docs all I could find to make an app do stuff in the background was stuff like registering a callback to trigger on events, such as a schedule interval or an incoming push or SMS

dazinism: ah wow, this is fantastic information. If I can digest it successfully it'll help me explain to devs why Holochain-on-mobile has a challenging future... and also, apparently, why it's not such a lost cause as I thought?

Looks like the key here is TCP, and I'm guessing that the WiFi and various mobile standards allow for a connection that remains open yet allows the device to enter a low-power state that waits for an incoming packet before it fully wakes up? Is the same also possible with stateless, socketless UDP (e.g., QUIC protocol)?

One thing I'm curious about is, how do these apps that don't use Google's push notification service stay alive in the background? I thought that was expressly forbidden, and indeed made impossible, by the Android SDK. I'm not much of a dev anymore, but perusing the docs all I could find to make an app do stuff in the background was stuff like registering a callback to trigger on events, such as a schedule interval or an incoming push or SMS

Paul d'Aoust: theres a 'special app access' permission to disable battery optimisation for an app. The app can tell the user why it needs it then get the users permission to not be optimised. That doesnt mean the app will then use loads of power. If the app is designed well it can still minimise power draw. (On older versions of Android things were done differently - been this way for a fair few years now)

Not sure what the deal is with using something other than a TCP port. My knowledge of networking stuff is limited. I couldnt see any reason why the app could do that, unless the way networking on Android or cell networks is implemented would mess things up?

In reply to @DzzzzzzR:matrix.org
With battery opt disabled the app also has to run a foreground service, which requires it to have a notification constantly open telling the user its running (the user can hide that)

In reply to @eseohe:matrix.org
Hi everyone. We are planning the next DWeb Meetup for Thurs, Nov 4 at 5pm PT. Our featured speaker Coraline Ada Ehmke will be discussing trust, respect and equity in the DWeb space based on her blog on the DWeb principle - Mutual Respect. We are also hoping to hear updates from DWeb projects. You can read the article https://blog.archive.org/2021/09/03/the-sacred-geometry-of-respect-trust-and-equity/ and sign up to present a lightning talk at the next meetup https://form.jotform.com/203236908715154 or share with someone who might be interested in speaking