Scribd
Upload
4 views

Push vs Poll when large delay

The document discusses the trade-offs between push and polling methods for mobile applications, emphasizing that polling is acceptable when real-time updates are not necessary. It suggests that polling can lead to resource inefficiency and server performance issues, especially with many concurrent users, and proposes using design patterns like Observer and Proxy to improve application efficiency. Additionally, it outlines various proxy usage scenarios, including remote, virtual, and protection proxies, along with a code example demonstrating the Proxy design pattern.

Uploaded by

Anoop Kumar
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
4 views

Push vs Poll when large delay

The document discusses the trade-offs between push and polling methods for mobile applications, emphasizing that polling is acceptable when real-time updates are not necessary. It suggests that polling can lead to resource inefficiency and server performance issues, especially with many concurrent users, and proposes using design patterns like Observer and Proxy to improve application efficiency. Additionally, it outlines various proxy usage scenarios, including remote, virtual, and protection proxies, along with a code example demonstrating the Proxy design pattern.

Uploaded by

Anoop Kumar
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Push vs Poll when large delay (hours) is

acceptable
Ask Question

It seems commonsense nowadays that polling is a bad practice and pushing is


the way to go when developing mobile applications that require to constantly
receive data from a remote server.

All major mobile shops provide their version of a push notification service:

 Apple Push Notification Service


 Google Cloud Messaging for Android
 Microsoft Push Notification Service
However I'm wondering to what extent this assumption is valid. I mean, if I have
an application that polls a remote server only a couple of times a day, and to
which "notifications" don't need to be delivered instantly (a large delay is
acceptable), then would it be a good decision to poll for data instead of pushing
it?

Thanks in advance!

Answer:

Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself
is why would you use one instead of the other?

The purpose of a push service is a couple things; it can be considerably less traffic for you
to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this
allows you to send one message and have thousands receive it. But as you note, the
biggest boon of a push service is the realtime nature that allows for immediate updates to
reach your consumers. However when doing pushes you really don't ever want to be
pushing large data sets if you're broadcasting, and you're also at the mercy of the third party
push service you utilize (if you utilize one).

The purpose of a poll is to check for data differences periodically, where the update period
can have an acceptable SLA(service-level agreement ) of inaccuracy up to a certain time
period. A poll will require all your clients to request the data periodically which will mean a
connection being requested for every running client, and the necessity of a live service able
to monitor that data accurately to serve it up to the pollers. Having accurate data to serve up
means some data persistence which will take up disk and maintenance time.

So from this we can see that if you have concerns about network traffic or the maintenance
of a service (which means possibly authenticating/authorizing requests, logging them which
takes up disk space, all the normal requirements of maintaining a service) then you don't
want to force clients to poll. However if the use case requires transmitting a particularly
large data set or you can't be tethered to a third party's API which may change in time as
well as their SLA or charges, then a home grown polling system may be applicable, though
the maintenance overhead may be significantly more. Alternatively you may already be
running service and have the data persisted such that the polling is a light addition to
already in-place infrastructure, which makes polling more desirable.

Though to the central point you make you are correct; if real-time is necessary, polling will
not do. If it is not, then you just have to do the math on how periodic the data can be
checked multiplied by your client base multiplied by your data set size to decide if the
network cost is going to be worth it, or if a push service would be better where you can
always just push a change event that let's them request the large data set in a secondary
step (though atomicity of these steps may be something you need to be careful of
depending on the criticality of the data).

Problem Statemenmt
Currently the application using the polling method (i.e, to retrieve new data
from server in a fixed amount of seconds).

This is quite taxing and does not retrieve latest result immediately. Assuming
the server is using webservice and if possible, without a major overhaul, how
can I better improve on the application efficiency?

By taxing , I mean the server would have to pull up different SQL tables and associated
data and stuff, meaning complex data processing which if there is alot of concurrent users
I'm afraid there might be possible issues with the server performance in the future.

Answer:
The problem with polling is that the observer controls when the call happens yet doesn't
know when state changes so it makes many needless calls. This eats resources especially
when there are many observers. The key to dealing with polling is: as soon as possible, get
the direction of calls going from the point of state change(Suject) to the observer. Then calls
happen when they're needed. Not when they aren't.

Make the server follow the observer pattern. Allow clients to register as observers.
Proxy Pattern:
The proxy could interface to anything: a network connection, a large object in
memory, a file, or some other resource that is expensive or impossible to
duplicate.

In short, a proxy is a wrapper or agent object that is being called by the client to
access the real serving object behind the scenes.

Example Of Bank Loan and Loan Executive


Say You want to process Home Loan from Bank and guess what..you meet first
person(Loan Executive) to your doorstep who on behalf of bank first first verifies
your eligibility and if you fit in criteria of bank’s loan guidelines.

So you can understand that Bank Manager who Approves Bank Loan is real
Object and Executive is Proxy Object which does the validation work before it
promices your loan can be approved by Bank Manager.

What problems can the Proxy design pattern solve?


 The access to an object should be controlled .
 Additional functionality should be provided when accessing an object.

To act as substitute for a subject, a proxy must implement the Subject interface.
Clients can't tell whether they work with a subject or its proxy.
See also the UML class and sequence diagram below.
 Structure
 UML class and sequence diagram

Possible Usage Scenarios


Remote Proxy
In distributed object communication, a local object represents a remote object (one that belongs
to a different address space). The local object is a proxy for the remote object, and method
invocation on the local object results in remote method invocation on the remote object. An
example would be an ATMimplementation, where the ATM might hold proxy objects for bank
information that exists in the remote server.

Virtual Proxy
In place of a complex or heavy object, a skeleton representation may be advantageous in some
cases. When an underlying image is huge in size, it may be represented using a virtual proxy
object, loading the real object on demand.

Protection Proxy
A protection proxy might be used to control access to a resource based on access rights.

class ICar {
public:
virtual void DriveCar = 0;
};

class Car : public ICar {


void DriveCar override {
std::cout << "Car has been driven!" << std::endl;
}
};

class ProxyCar : public ICar {


private:
ICar* realCar;
int _driver_age;

public:
ProxyCar (int driver_age) : realCar(new Car), _driver_age(driver_age) {}
~ProxyCar {
delete realCar;
}

void DriveCar {
if (_driver_age > 16)
realCar->DriveCar;
else
std::cout << "Sorry, the driver is too young to drive." << std::endl;
}
};

// How to use above Proxy class?


int main
{
ICar* car = new ProxyCar(16);
car->DriveCar;
delete car;

car = new ProxyCar(25);


car->DriveCar;
delete car;
}

Output

Sorry, the driver is too young to drive.


Car has been driven!

Mediator Design Pattern:


Say over facebook there is a Group named JavaGroup and there are 7 members in group. Here Facebook
Group is abstract Entity prviding mechnisam to communicate to each group member through its
concrete implementation which is “Java Group”
Composite Design Pattern:

You might also like