It's important for your app to stay up to date in order
to get the latest social feeds, news, and weather reports
to your users, but in truth, syncing too often
can be the worst idea for the performance
of your application.
My name is Colt McAnlis and there's
one hard and fast rule when it comes to syncing
your data over the network.
Do not over sync.
It's a pretty common situation.
The user has your app active or maybe
it was the last app they used and you want to make sure
that there's plenty of new data available for them
so that they won't close your app
or let their attention wander elsewhere.
So you sync.
You sync a lot.
You ping the server, you ask for new data,
and bring it down as often as you can, but let's face it,
this is a horrible idea.
Firstly, this destroys the user's battery
and as we've said before, networking
is the single biggest battery hog there is.
Not only does it drain battery just to initialize the chip,
but then it keeps it awake for an additional 20 to 60 seconds
after you're done with your request, also drawing power.
In fact, you can fall into a really bad place where
each one of your networking requests
ends waking up the radio and paying this cost.
Not ideal.
Secondly, consider the sheer volume of bits
that your app is now responsible for requesting
on the user's phone.
Now, for users on restricted usage data plans,
this can be a make or break crime.
One app eating of a month's worth of bandwidth
simply because it keeps pinging the server for new data?
Not a good idea and this is also a double whammy
because the slower the connection,
the longer the radio stays on to help transfer data, meaning
that you're not only being taxed for bits on the wire,
but also draining more battery as a result.
So, OK, so syncing too often is bad,
but let's be realistic here.
Your app needs the data in order to provide the user
with the best experience.
We can't just cut syncing out completely, right,
and the truth is you don't have to.
There's a few handy trick that you
can employ which will give the user
the same sense of functionality but require
much fewer requests.
The key to this solution is understanding the difference
between stuff that has to happen right now
and stuff that could be delayed.
For example, if the user takes an action requesting
that the news feed updates right now,
well, then you pretty much have to kick off that request,
but really, the second and third types
are where you can actually start improving performance.
The requests that happen on regular intervals that
keep things up to date but don't need
to happen right this second.
If it's not super important right now,
then you could be smarter about how it's synced.
Case in point.
You should really never poll the server regularly for updates.
You're basically just wasting bandwidth and battery
for the server to tell you that nothing's changed.
Instead, it's better to leverage other services
like Google Cloud Messaging, which
will let the server signal the app when there's new content.
This will reduce the amount of battery
churn the phone is doing and reduce
the overall number of server responses
that you need to worry about.
Now, if there's a situation where you simply have to sync,
then make sure that you're not doing it on regular intervals.
Remember, this wastes resources and most the time,
there won't be new content waiting for you.
Instead, adopt a back-off pattern based on responses.
For instance, if no new data is available, double the length
you wait until you check again and if nothing's available
the next time, double your wait length again.
This will still allow you to sync against the data
but we'll slowly back away from higher activity based
on how frequent the server site information is updating.
And don't forget, you can also adjust seek frequency
based on user activity.
For example, if you can detect that the user is driving
or running or if the phone has entered into sleep mode,
you can make a good assumption that they won't need data
at the same rate.
On the other side, though, if you've
noticed that the phone has been asleep for eight hours
and suddenly starts getting moved around,
then there's a good chance the user has just woken up
and it might be the right time to kick off the sync request.
And, finally don't hesitate to adjust your sync frequency
based on the state of the device.
Waiting for it to plugged in or connected to Wi-Fi
to do syncing helps keep the battery happy
while users are out and about and the good news
is that you can update your app to adopt
these patterns without having to write a massive amount of code.
GCM Network Manager is a Google Play services API
which helps to schedule network-oriented tasks
and handle batching for you.
This greatly simplifies the implementation
of common patterns such as waiting
for network connectivity, network retries,
and exponential back-off.
Basically all the good stuff you need
with one single helpful API.
And if you're ever wondering how your application is using
the network, make sure to check out the network traffic tool
inside of Android Studio.
It will easily show you the frequency of your data
transfers and the amount of data transferred
during each connection.
Of course, that's what it all comes down to, right?
Watch some videos, improve your app, make your users happier,
but you're not done yet.
That's why you need to check out the rest of the Android
Performance Patterns Content and don't forget to join the Google
Community as well.
So keep calm, profile your code, and always remember,
perf matters.
[MUSIC PLAYING]