Add new sync intervals

[baldurmen]

I use the app without Google Play installed, and since replacing GCM with something else is complicated, I'd like it if you could add some new sync intervals options.

At the moment, the most frequent sync interval is each day. Adding intervals at:

• 2 mins
• 5 mins
• 10 mins
• 30 mins
• 1h
• 12h

would actually make the app usable without Google Play (issue #36). You could thus publish it on F-Droid (issue #37).

The only downfall is that this will shorten battery life. I do think it's worth it though: I use K9 with a sync interval of 10 mins and my old phone supports it well enough.

If you worry about cluttering the interface (too many options), you could add a "Use without Google Play" button and activate those new intervals only when this option is enabled.

[jkms]

+1.

I would also love to see this feature.

[dkisselev]

@baldurmen, @jkms,

#52 is a quick pass at adding more intervals.

I opted to only include intervals at 30min+ because I personally feel that offering lower options is irresponsible (users will choose them, not realizing that when the interval is that low it significantly affects battery life), but I'm open to discussion and ultimately it's @michaelkourlas's call, I'm happy to amend the PR with any other intervals.

Perhaps a hybrid option might be possible, where the app will refresh every minute or two when it's actually open/running or if a message has been sent/received recently (ie, an exponential backoff based on the last message time and target sync interval), but that's a much more complex change, so this one would get you half way.

[baldurmen]

Thanks for the work on this, it's great.

I have to disagree on the 30min thing though. I think it's a bit too long to use the app like a normal SMS messenger.

IMHO people should be able to set shorter intervals. It indeed affects battery life, but that's a price I'm ready to pay. Ultimately, if people choose shorter intervals and dislike it, they'll just change it later on.

[jkms]

I came up with my own work-around for this. I configured voip.ms to forward my SMS messages to a separate email address, which I've configured my K-9 email client to check every five minutes.

I would still like to be able to configure this behavior in voipms-sms-client, but until that time, this will work.

[michaelkourlas]

I'll add more sync intervals in the 0.4.2 release. I'll probably use the work already done in #52.

[Cylinder]

First, thanks to Michael for this software. This makes my transition to voip nearly complete.
It seems very silly that to get an SMS notification we have to bounce a message from VOIP.ms to Michael's server to Google's servers to our portable devices. (Disclaimer: I am attempting to run my Cyanogenmod device while swearing off Google.) Frequent polling as suggested here is an option (which I will probably use), but that is still very kludgey.
If we were to put in a feature request to VOIP.ms (https://voip.ms/m/features.php) for a service that would allow us to get notifications of new messages directly from VOIP.ms, what would that request be? From my ancient network programming experience I am thinking that my portable device would establish some SSL connection to a VOIP.ms server, and just listen for any input. Thoughts?

[dkisselev]

A question for you guys before I start,

How much battery do the current intervals take up on your phones? (Check the Battery tab in Settings at the end of a typical day and let me know what % it's used on which refresh setting)

This got really long so I'll add a tl;dr:
There are a few possible techniques, but they're very resource-intensive to implement for a small dev and might not actually lead to much actual battery-savings.

There isn't really any standardization around doing push notifications without Google, so it would be difficult to "ask" voip.ms for anything. I think the web callback feature that this project already uses (to forward SMS notifications to Google) is already quite good because it does give you real-time notifications, you just need to write a wrapper to handle it. They might be able to do something if they come out with first-party mobile apps, but I don't think they're actively working on anything.

In mobile development there are generally very few battery-conscious ways of doing push notifications. I've tried to look into it in the past and unfortunately there aren't any good alternatives to Google's cloud (GMS) for users that want to get away from it (most of the things I'm about to explain generally apply to Apple/iOS in nearly the same way).

The idea behind GMS is that the device keeps a single connection open to a single server and notifications for all apps flow through that one connection. This means that the device only needs to wake up for a split second to do a single network call (to a server that's generally designed to respond fast) and get information about every application on the device.

This also means that the device doesn't have to keep app processes in memory just to check notifications, apps are only spun up and use battery when they actually have work to do from notifications.

When you eliminate the central service, every app that wants to do notifications needs to keep a service in memory and use CPU cycles to submit a network request and process the results (and a voip.ms API call is probably slower and bigger than a Google push api call so the service needs to stay awake for even longer). This is what this app currently does for polling mode.

Another big roadblock is Google's VERY aggressive battle against anything except their own system. The Doze features in Android 5, 6, and 7 are designed to throttle everything except for GMS.

There's a hidden toggle in the settings that lets users set specific apps as exempt from battery-saving policies, but from what I've gathered it still doesn't give apps the same rights as what GMS has. The Android developers have also specified that they intend on making the "battery saving sledgehammer" even bigger in the future (in their /r/androiddev AMA yesterday).

As a theoretical option, I've seen some apps use MQTT as a push notification subsystem to replace Google (facebook actually uses it). This is definitely something that's a possibility for this app, but would take significant effort to implement and maintain.

Basically user devices connect directly to an MQTT server hosted by Michael and when messages come in, voip.ms will reach out to Michael's server, which will translate and forward the messages on to devices.

The problem is that again, every app using this technique maintains its own service and connection to its own server and would need to be exempted from battery saving modes. Additionally, since devices are now maintaining connections directly to a small server, that server will need to be kept running and scaled for the userbase of this app.

There aren't any good MQTT libraries/pre-built systems available for Android, so basically everything would be need to be done from scratch. I would love to see the community come together to develop a standard protocol for notifcations-over-mqtt with sample server/client library implementations, but unfortunately it's not here today.

Here's an example of someone implementing it from scratch: http://dalelane.co.uk/blog/?p=1599

[Cylinder]

Denis,
I think that your post sounds a bit hopeless. There are many other applications that do instant messaging without having to use GMS or MQTT. I run a couple of apps that do XMPP messaging, no Google. Perhaps that would be an alternative: request that voip.ms set up an XMPP server for the SMS messages.

[baldurmen]

A question for you guys before I start,

How much battery do the current intervals take up on your phones? (Check the Battery tab in Settings at the end of a typical day and let me know what % it's used on which refresh setting)

@dkisselev I can't really answer this since this has not been merged yet and I don't have time to build the app myself. If you provide me with an .apk I'll be more than happy to give you this info.

For the whole battery-saving thing, it is indeed hard. I've looked into it and it's painful all the way. Personally, I don't mind sacrificing battery life to poll the VOIP.ms servers. I don't use a cellphone carrier and disabling the antenna makes a HUUGGEE difference.

[michaelkourlas]

This is now complete; you'll see it in the next release.

2e9753e