StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This is a very interesting question and I ran into the same problem. In my opinion both mechanisms can be used altogether and the right approach to use depends on your use case. Here are some points to be taken into account before deciding.</p> <p>Using the callback-mechanism has some benefits, but there are also limitations:</p> <p>PRO</p> <ul> <li>It is simple and straight forward to implement.</li> <li>You get type-safety between the components that interact with each other.</li> <li>You can return arbitrary objects.</li> <li>It simplifies testing as you only have to inject a mock-callback (e.g. generated through mockito or something similar) in unit tests.</li> </ul> <p>CONTRA</p> <ul> <li>You have to switch to the main thread in order to do UI manipulations.</li> <li>You can only have a 1-to-1 relationship. A 1-to-n relationship (observer pattern) is not realizable without further work. In this case I would prefer Android's <code>Observer</code> / <code>Observable</code> mechanism.</li> <li>As you already said, you always have to check for <code>null</code> before invoking callback functions if the callback may be optional.</li> <li>If your component should offer a kind of service API with different service functions and you do not want to have a callback interface with only a few generic callback functions, you have to decide whether you provide a special callback interface for each service function or whether you provide a single callback interface with a lot of callback functions. In the later case all callback clients used for service calls to your API have to implement the complete callback interface although the majority of the method bodies will be empty. You can work around this by implementing a stub with empty bodies and make your callback client inherit from that stub, but this is not possible if already inheriting from another base class. Maybe you can use some kind of dynamic proxy callback (see <a href="http://developer.android.com/reference/java/lang/reflect/Proxy.html" rel="nofollow noreferrer">http://developer.android.com/reference/java/lang/reflect/Proxy.html</a>), but then it gets really complex and I would think of using another mechanism.</li> <li>The client for the callback calls has to be propagated through various methods/components if it is not directly accessible by the caller of the service.</li> </ul> <p>Some points regarding the <code>BroadcastReceiver</code>-approach:</p> <p>PRO</p> <ul> <li>You achieve a loose coupling between your components.</li> <li>You can have a 1-to-n relationship (including 1-to-0).</li> <li>The <code>onReceive()</code> method is always executed on the main thread.</li> <li>You can notify components in your entire application, so the communicating components do not have to "see" eachother.</li> </ul> <p>CONTRA</p> <ul> <li>This is a very generic approach, so marshalling and unmarshalling of data transported by the <code>Intent</code> is an additional error source.</li> <li>You have to make your <code>Intent</code>'s actions unique (e.g. by prepending the package name) if you want to eliminate correlations with other apps, as their original purpose is to do broadcasts between applications.</li> <li>You have to manage the <code>BroadcastReceiver</code>-registration and unregistration. If you want to do this in a more comfortable way, you can implement a custom annotation to annotate your Activity with the actions that should be registered and implement a base <code>Activity</code>class that does registration and unregistration with <code>IntentFilter</code>s in its <code>onResume()</code> resp. <code>onPause()</code>methods.</li> <li>As you already said, the data that is sent with the <code>Intent</code> has to implement the <code>Parcelable</code> interface, but furthermore there is a strict size limitation and it will cause performance issues if you transport a large amount of data with your <code>Intent</code>. See <a href="http://code.google.com/p/android/issues/detail?id=5878" rel="nofollow noreferrer">http://code.google.com/p/android/issues/detail?id=5878</a> for a discussion on that. So if you want to send images for example you have to store them temporary in a repository and send a corresponding ID or URL to access the image from the receiver of your <code>Intent</code> that deletes it from the repository after usage. This leads to further problems if there are several receivers (when should the image be removed from the repository and who should do that?).</li> <li>If you overuse this kind of notification mechanism the control flow of your application may get hidden and when debugging you end up drawing graphs with sequences of <code>Intent</code>s to understand what has triggered a specific error or why this notification chain is broken at some point.</li> </ul> <p>In my opinion, even a mobile app should have an architecture base on at least 2 layers: the UI-layer and the core layer (with business logic, etc.). In general, long running tasks are executed in an own thread (maybe via <code>AsyncTask</code> or <code>HandlerThread</code> if using <code>MessageQueue</code>s) inside the core layer and the UI should be updated once this task has been finished. In general with callbacks you achieve a tight coupling between your components, so I would prefer using this approach only within a layer and not for communication across layer boundaries. For message broadcasting between UI- and core-layer I would use the <code>BroadcastReceiver</code>-approach that lets you decouple your UI layer from the logic layer.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload