CODEWITHSUNDEEP
androiddesign-patternsservice
AADProgramming
AADProgramming

Reputation: 6345

Design Pattern in Bound Service?

I am exploring the Bound services in Android. I came across below line in Android developer documentation about the Bound service.

Multiple clients can connect to the service at once. However, the system calls your service's onBind() method to retrieve the IBinder only when the first client binds. The system then delivers the same IBinder to any additional clients that bind, without calling onBind() again.

As mentioned here, it seems Android system is using an already existing IBinder to return to additional clients.

Is this implementation is loosely based on concept of Flyweight Design pattern? As we know, Flyweight pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance.

Update:

I checked the source code of Android where this code is handled. It is as below:

if (!data.rebind) {
                        IBinder binder = s.onBind(data.intent);
                        ActivityManagerNative.getDefault().publishService(
                                data.token, data.intent, binder);
                    } else {
                        s.onRebind(data.intent);
                        ActivityManagerNative.getDefault().serviceDoneExecuting(
                                data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
                    }

And data.rebind is just a boolean, declared inside a static class as below, and data is an object this BindServiceData class.

static final class BindServiceData {
        IBinder token;
        Intent intent;
        boolean rebind;
        public String toString() {
            return "BindServiceData{token=" + token + " intent=" + intent + "}";
        }
    }

Hence, perhaps it is not directly related to Flyweight pattern.

Upvotes: 2

Views: 349

Answers (1)

mawalker
mawalker

Reputation: 2070

I don't believe this is technically use of the flyweight pattern. There are some similarities, but there is some nuance that separates the two.

from the WIKI page

A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory.

then

A classic example usage of the flyweight pattern is the data structures for graphical representation of characters in a word processor. It might be desirable to have, for each character in a document, a glyph object containing its font outline, font metrics, and other formatting data, but this would amount to hundreds or thousands of bytes for each character. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character (in the document and/or the page) would need to be stored internally.

This describes a scenario where you have a large number of objects which if they each stored their 'full data' in each object would requires a massive amount of memory. The Flyweight pattern is uses to de-duplicate memory usage when the large number of objects (such as characters in a text editor) often have the same sets of values (such as font size, font type, color, background color, etc.) which they just share a single 'flyweight' object among them all to store that data. (reducing the memory impact from multiple variables per object down to just a pointer)

The Android bound service creates a new ibinder when the service is started and returns that same ibinder instance to new client(s) if they 'also happen' to bind to the service while it started. However, unlike the flyweight pattern, the reason that is done in Android, is because there is only 1 instance of a bound service that is ever started. So there is no reason to return a new ibinder. Android Services do not have any concurrency-safety built into them. So they need to be designed in state-less manner unless you design your service from the ground up to have concurrency and handle multiple clients. This is how they are able to create a single instance of the bound service, by putting the concurrency issues onto the developer, not the platform.

Just giving out single instance of the ibinder out to multiple clients doesn't make this the Flyweight pattern. If anything I would think of it closer to the Singleton pattern. But that is still a stretch since different instances of the bound service CAN be different objects, in violation of the singleton pattern.

Upvotes: 1

Related Questions