I have been coding an Android app that has a lot of code dedicated to it. As you can imagine, there's lots of case-driven code in there. Because most of Android callback functionality is based on integers and ItemIDs and requestCodes, there is a lot of functionality built into switch statements or if-then-else constructs.
What are the best practices for organizing/refactoring this code in a better way? What have you found that works to reduce the amount of code and clarifies it at the same time? Is a huge amount of small classes going to hurt Android performance?
Thanks in advance.
A large number of classes is not going to affect the performance of the application. Some good practices in Android, however, include placing values like integers, item IDs, and request codes into a Resources xml file.
You will also see a lot of Callback classes as inner interfaces of the Object they relate to:
public class MyObject
{
private Callback callback;
private Object returnObject;
public void setCallback(Callback callback)
{
this.callback = callback;
}
public void doSomething()
{
//do something - could be an anync task or other that assigns returnObject
callback.invoke(returnObject);
}
public interface Callback
{
public void invoke(Object obj);
}
}
Then you can use this as follows:
MyObject obj = new MyObject();
obj.setCallback(new MyObject.Callback() {
#Override
public void invoke(Object obj) {
Log.i("Callback", obj.toString());
}
});
obj.doSomething();
Related
I am using the visitor pattern to abstract payment processing away from the UI code in android. I have some doubts on what i should pass into the visitor constructor inorder for the view to get a call back once its done processing the payment.
Let me show you what i have so far:
i am dealing with 2 payment systems, thus two payment strategies (brainTree and Stripe):
public class BrainTreePaymentStrategy implements IVisitable {
#Override
public void makePayment() {
}
#Override
public void accept(Visitor v) {
}
}
public class StripePaymentStrategy implements IVisitable {
#Override
public void makePayment() {
}
#Override
public void accept(IVisitor v) {
}
}
public interface IVisitable {
void makePayment();
void accept(IVisitor v);
}
public interface IVisitor {
//list out all the classes the visitor can visit now
void visit(StripePaymentStrategy stripePaymentStrategy);
void visit(BrainTreePaymentStrategy brainTreePaymentStrategy);
}
//now critical, lets create a real concrete visitor that can actually do the work:
public class PaymentStrategyVistor implements IVisitor {
#Override
public void visit(StripePaymentStrategy stripePaymentStrategy) {
//process the braintree payment here, but how to give call back to UI ?
}
#Override
public void visit(BrainTreePaymentStrategy brainTreePaymentStrategy) {
//process the braintree payment here, but how to give call back to UI ?
}
}
i am using uncle bob's clean architecuture so my network calls are through usecases and also im using mvp for my presentation layer so i have access to presenter and usecase if needed.
So again my question is regarding PaymentStrategyVistor class, what do you think if i passed in the presenter as a constructor parameter. i for example , could then call presenter.doBrainTreePayment("someToken"); i could do that in the visitors visit(BrainTreePaymentStrategy brainTreePaymentStrategy) method. is this how you all would do it ?
Your suggestion (passing the presenter to the constructor of each visitor) seems to be totally fine.
Looking from clean architecture perspective this all is fine as long as u do not violate the dependency rule. so if ur strategy and visitors live in the "interface adapter layer" u can easily pass the presenter. on the other hand if ur strategy/visitor belong to the "use cases layer" than passing the presenter would violate the dependency rule and u should not do it.
For a more detailed discussion on presenters in clean architecture see my blog post: https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/
I struggled with some issues about design complex tasks with fragments
use. Fragments and asynchronous approach are quite new for me, so I think it will be better to describe my app.
Application
App works with GitHub API and has two screens: list of repositories and details about selected one. For retrieving data from json I use Retrofit and store it in SQLite. Little remark As I understood Retrofit can be used asynchronously but in case of additional work with DB it is better to use asynchronous approach for operations under DB also. In my case I'm checking internet connection: in case of absence I load data from DB. Otherwise I upgrade DB and then use it. Now I want to add fragments for different screen density support( usual master - detail workflow).
And my questions are
Where is the better place to run async tasks? Is it a right solution to make it in activity and then pass result to fragments?
What is the better solution for asynchronous processing? As I understood from my search about that, AsyncTask is deprecated but the easiest solution.
AsyncTask is a pain in the rear. Many beginners still seem to use it, but imho it's not worth learning it. Sooner or later you'll be bugged out by it because AsyncTask is error prone, has lots of caveats and tons of boilerplate code.
Retrofit does make it's calls asynchronously automatically, so you've got that covered already. Retrofit also plays very nice with RxJava which is I guess considered the way of doing asynchronous things on Android these days.
RxJava has a steeper learning curve initially than other patterns, but it's worth learning. If you got your database stuff working already, it won't be much work making ti asynchronous with Rx.
As for
Is it a right solution to make it in activity and then pass result to
fragments?
If you don't follow an MVP design approach, which is okay, in my opinion it's absolutely okay to do 'business logic' stuff in the Fragment and not let the Fragment call the Activity, then let the Activity get back to the Fragment. Whichever is easier for you and suits your app.
You can place your background thread anywhere, but make sure it is cancelled if the class is garbage collected, and don't keep references (Context, callbacks) in your thread.
public class MyActivity extends Activity {
private static interface OnDownloadThreadCompleteListener {
public void onDone(String data);
}
private static class DownloaderThread extends AsyncTask<Void, Void, String> {
private OnDownloadThreadCompleteListener mListener;
public DownloaderThread(OnDownloadThreadCompleteListener listener) {
mListener = listener;
}
#Override
protected String doInbackground(Void... args) {
// Do your network request here
return result;
}
#Override
public void onPostExecute(String data) {
if (mListener != null && !isCancelled()) {
mListener.onDone(data);
}
mListener = null;
}
#Override
public void onCancelled() {
mListener = null;
}
}
private DownloaderThread mThread;
private OnDownloadThreadCompleteListener mListener;
#Override
public void onCreate(Bundle bundle) {
super.onCreate(bundle);
mListener = new OnDownloadThreadCompleteListener() {
#Override
public void onDone(String data) {
Fragment fragment = getFragmentManager().findFragmentByTag("fragment_git");
fragment.show(data);
}
}
mThread = new DownloaderThread(mListener);
findViewById(R.id.btn_download).setOnClickListener(new View.OnClickListener() {
#Override
public void onClick(View v) {
mThread.execute(null, null, null);
}
}
}
#Override
public void onPause() {
super.onPause();
if (mThread != null) {
mThread.cancel(true);
}
mThread = null;
mListener = null
}
}
I've already developed many Android apps that make web service requests, always with the following approach:
In every activity that need to make a web service request, I define an inner AsyncTask that shows a ProgressDialog in onPreExecute(), makes the web service call in doInBackground, and dismisses the progressDialog and updates the results in the UI from onPostExecute().
My concern is: Is there a better (shorter) way to do it? Does it make sense to repeat all that code in every activity? I've been googling a lot, but I've found nothing.
My question is: Couldn't I define a Callback interface? for example this one:
public interface RequestCallback {
public void onSuccess(Whatever whatever);
public void onError(ErrorCode errorCode, String message);
}
... and then define an external class, for example AsyncRequest, that wraps the AsyncTask definition and the ProgressDialog show() and dismiss() statements. So, all activities would just need to instantiate that class, and pass in the following parameters:
1) The method of the web service to run
2) A Bundle with all the parameters of that method of the web service
3) A RequestCallback instance (that could be an anonymous inline instance, where I could update the UI from onSuccess())
4) The context of the Activity (necessary to show the ProgressDialog(), so I would still need a way to prevent configuration change exceptions and so...),
Do you find this a good design? It could save hundreds of lines of code...
Your approach is what I did on my project. And it saved a lot of code as you said, I don't have any complaint about it. But here is some issues that I want to tell you:
You should create new instance of AsyncTask every time you do a background thread to avoid to pile callback.
For the progress dialog, I use it as Singleton, because you don't show many dialogs at the same time. The dialog will be showed when you call the background job, and will be dismiss in the callback. Here is what I did:
private void showProgressDialog(String strMess){
if(null == progressDialog){
progressDialog = new ProgressDialog(MainActivity.this);
}
if(!progressDialog.isShowing()){
progressDialog.setMessage(strMess);
progressDialog.show();
}
}
private void hideProgressDialog(){
if(null != progressDialog && progressDialog.isShowing()){
progressDialog.dismiss();
}
}
void someMethod(){
showProgressDialog("Loading...");
doBackgroundJob(param, new RequestCallBack() {
public void onRequestCompleted(String message, boolean isSuccess) {
hideProgressDialog();
if(isSuccess){
}else{
//do something on error
}
}
});
}
It is an optional, I defined an interface to notify instead of specific class, for each response I use one class, so in base class, I don't care what the response is. Here is it:
public interface OnRequestCompleted<TResponse> {
void requestCompleted(TResponse response);
}
public abstract class BaseRequest<TResponse> implements IRequest{
protected OnRequestCompleted<TResponse> delegate;
protected Class<TResponse> responseClass;
#Override
public void send() {
new HttpTask().execute();
}
private class HttpTask extends AsyncTask<Void, Void, String> {
//...
#Override
protected void onPostExecute(String result) {
if (null != response && null != delegate) {
delegate.requestCompleted(response);
}
}
}
// the response example
public class GroupResponse {
public static class Clip {
public int clipId;
public String detail;
}
public static class Movie {
public int movieId;
public String detail;
}
}
In the subclass of BaseRequest, I will tell it exactly what the response class is (Movie, Clip...)
Hope this help.
If you use it already and it works for you, then yes it makes sense to make it generic and save the time (and bugs) of reimplementing the same thing dozens of times. If you ever find yourself copy-pasting large sections of code with few to no differences you should turn it into a library function or class of some sort. Otherwise if you find a problem later you'll have to fix it in a dozen places. It doesn't even matter if you think of a better way to do things later- its still easier to change it in one place than a dozen.
The only real issue I'd have with your solution is I wouldn't add the progress bar to it- I'd handle it in the calling code and the onSuccess/onError implementations. That way you could also reuse it for a background call that doesn't need to put up a UI. I try to keep my UI decisions as far away from data grabbing code as possible, MVC patterns are good.
public void consumeResponse(OmwListResponse<T> response) {
synchronized (response.getResultList()) { // XXX this isn't synchronized safely
for (T t : response.getResultList()) {
if (!cacheList.contains(t)) {
cacheList.add(t);
}
}
}
}
The the situation is I don't want anyone to chance response.getResultList() or cacheList until this method is done. How do I properly do this?
Create a lock object:
private static final void LOCK = new Object();
and synchronize on that.
Synchronizing cacheList is easy. Just wrap any code your code that uses it in:
synchronized(cacheList) {
// Make changes to cacheList here
}
If cacheList is a public member and you're afraid external classes will change it, make it a private member and synchronize the getter and setter. This is the only way since you have no control over what other classes do and it is your responsibility to synchronize your members.
As for response, that is trickier because I don't what an OmwListResponse is. Do you own that class? If so, use the same method as above. If not, you may be out of luck.
In Android application development, I frequently go through the word CallBack in many places. I want to know what it means to tell us technically - and how I can manage to use the callback in applications. I need a guide to understand it and use it.
i want to know what it means, tell
us technically
http://en.wikipedia.org/wiki/Callback_%28computer_science%29
"In object-oriented programming languages without function-valued arguments, such as Java, [callbacks] can be simulated by passing an abstract class or interface, of which the receiver will call one or more methods, while the calling end provides a concrete implementation. Such objects are effectively a bundle of callbacks, plus the data they need to manipulate. They are useful in implementing various design patterns such as Visitor, Observer, and Strategy."
how i can manage the callback of the
applications
I have no idea what this means.
Hmm. How about an example. You write a quicksort algorithm in C. The user who wants to use your algorithm must supply a compare method appropriate for what the user is sorting with your algorithm. The user must pass a function pointer to the user's compare method to your quicksort code. The quicksort code uses this address, the function pointer, to CALL BACK to the user's compare function. You provide a function prototype, no implementation, since you cannot possibly know how to determine the ordinality of what is being sorted. The user supplies the implementation of compare that makes sense for what the user is sorting. This implementation must match the function prototype. The function pointer is used by the quicksort alogorithm to reach back and touch the user's code.
This is actually about polymorphism.
In java, you can use an interface to do this. So for sorting, see the interface IComparer and IComparable.
A Callable interface can be used to run a piece of code as Runnable does. However, Callable can return the result and can throw checked an exception.
For more detail.
http://developer.android.com/reference/java/util/concurrent/Callable.html
By using Callable interfaces you can pass an argument as function I added a simple code snippet for understanding.
public class MainActivity<V> extends Activity {
Callable<String> doLogin=null;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
doLogin=new Callable<String>() { //created but not called now.
#Override
public String call() throws Exception {
//make some piece of code
return "something"; //or false
}
};
CheckSession checkSession=new CheckSession("sessionName");
String sessionKey="";
try { //we are sending callable to the DAO or any class we want
sessionKey=checkSession.getSessionKey(doLogin);
} catch (Exception e) {
e.printStackTrace();
}
}
}
public class CheckSession{
String sessionName="";
Callable<String> func=null;
public CheckSession(String sessionName) {
super();
this.sessionName = sessionName;
}
public String getSessionKey(Callable<String> doLogin) throws Exception{
func=doLogin;
return (String) func.call();
}
}