Metrics Manager configurable synchronize interval

[joseprl89]

I have noticed that the current setup for the Metrics Manager uses hardcoded values for maximum batch count and batch interval between batch synchronizations:

    /**
     * Number of queue items which will trigger synchronization with the persistence layer.
     */
    protected static int mMaxBatchCount = 50;
    /**
     * Maximum time interval in milliseconds after which a synchronize will be triggered, regardless of queue size.
     */
    protected static int mMaxBatchInterval = 15 * 1000;

Having a hardcoded interval means that:

• The CPU will be woken up very regularly.
• The network will also be woken up.
• Can't reduce the interval for testing purposes.

In my opinion, the default behaviour of the SDK should be aligned with the "Optimizing Downloads for Efficient Network Access" article on developer.android.com.

Furthermore, those two properties should be configurable so as to allow the users to tweak it if their use case has different needs (e.g. increase while testing).

[ElektrojungeAtWork]

Hey Josep,

Thanks for getting in touch, I hope it's okay if we use just one issue instead of 3 all over the place ;)
I value your input a lot, so please, let me know your thoughts.

First, let's talk about why there is no API for it. We have been burned by exposing an API in the past with another SDK where people would set crazy values and then blame the SDK on eating up their battery and we don't have any plans to expose an API for this for this exact reason.
Second, you are right that there should be a shorter interval for testing purposes. The iOS SDK actually has such an API where it's lacking on Android and Xamarin. I just created tasks for this, so it get's fixed. Thanks for pointing this out! The values are a batch size of 5 and an interval of 3s for testing.
Third, let's talk about the values. You are right, that the interval is too small for Android. We did some cross-platform testing and the values seemed like a sweet spot between the desire to send logs instantly to get a "live event" behavior, and not draining CPU/Network too much. That said, I value your opinion. What would be your sweet spot?

Best,
Benny

[joseprl89]

Hi Benny,

If we have a testing mode where we get the batches more frequently, I would personally not mind extend the batch interval to several minutes, since I am not fuzzed that much about liveliness of this data.

Furthermore, and based on the Optimizing Downloads for Efficient Network Access docs, 15 seconds means that the network will be constantly switching between low and high battery usage, which means the app will have a high impact on battery. Quoting Google:

An app that pings the server every 20 seconds, just to acknowledge that the app is running and visible to the user, will keep the radio powered on indefinitely, resulting in a significant battery cost for almost no actual data transfer.

However, I feel like this wouldn't properly fit all use cases, so what if the SDKs offer an enum to configure how frequently it flushes the events?

How about:

public enum EventUpdateInterval {
     SHORT, // Current setup
     MEDIUM, // every minute
     LONG, // every 15 minutes
     IMMEDIATE, // max batch size == 1
     NONE // Batches not synced unless the user manually triggers them. More on this later.
}

This would allow consumers of the API to decide if they want immediate upload during testing, or to look for their sweet spot.

On Manually triggered

If a consumer of your SDK wants to make the calls as efficient as possible, an API that allows to flush the analytics batches on demand would allow to perform optimisations such as:

Batch transfers and connections, by firing the analytics events when another network call occurs.

In Minimizing the Effect of Regular Updates, Google recommends to use Network Scheduling Tools. The consumer could be using the AlarmManager, SyncAdapter, or JobScheduler APIs (or any other sort of scheduling API) to manually trigger a batch sync at the time it is more convenient to them.

In Modifying your Download Patterns Based on the Connectivity Type the recommendation is to take advantage of Wi-Fi connections.

[ElektrojungeAtWork]

Hey Josep,

We've discussed both options in the past and I definitely see the value. We'll discuss internally next week and and I'll let you know the outcome over here.

Thanks for all the input from your side. This is very important for us. Keep it coming!

Have a great weekend!
Benny

[ElektrojungeAtWork]

Hey Josep,

I just merged a PR that adds support for "debug" intervals to develop and this will be part of 4.1.5. I can't provide an ETA for you just yet.
We have added a task about the sending interval to our backlog, but I can't promise an ETA for this as we have a lot going on right now with Mobile Center.

Thanks again for your input! It's invaluable!
Benny

[joseprl89]

Cheers Ben!

[ElektrojungeAtWork]

I'm closing this as we've added the debug intervals.

That said, the API to customize the sending interval is still on our backlog.