There are methods and attributes I would like to share across activities. E.g.
public class BaseActivity extends Activity
would be the parent for another activity
public class MainActivity extends BaseActivity
BUT if the child activity is a e.g. ListActivity this is not possible, right? Do I need a base class for ListActivity, too? This would be redundant code.
I could transform the ListActivity to an Activity, but this would be more code then necessary.
Any suggestions?
Yes, you're right. As java does not support multiple inheritance, a class can only have one base class.
But you can work via delegation instead of inheritance: Put your methods into a separate class (which does NOT inherit Activity) and use instances of it in your activities. Then you can reduce the redundant code (creating and holding the instance) to a minimum.
See also:
http://sourcemaking.com/refactoring/replace-inheritance-with-delegation
How do I implement multiple inheritence in Java
For the ListActivity case I would create a BaseListActivity that extends from BaseActivity. The BaseListActivity would contain a getListView() that returns the ListView if you really-really need it, a protected method setAdapter() that receives an Adapter/ListAdapter. You could also create some protected methods for enabling to show the empty view, to enable this behavior and to return the ids for your empty view and ListView. By default these should point to android.R.id.list/android.R.id.empty. But you can override that in your child activity.
In the end it's a matter of OOP and not that much of Android specific. If you check the implementation of ListActivity you'll see how simple it is to make your own BaseListActivity implementation. In the end it's more important to have a consistent and robust class hierarchy.
I am using my Activities this way, and I'm really happy I'm doing it. Of course you have to make some changes (like the ListActivity you mentioned in your question), but it has more advantages then disadvantages in my opinion.
In my app I don't have to worry about sending Analytics data every time I create a new Activity, and I also don't have to worry about setting up BroadcastReceivers I need in every class, I just made my BaseActivity abstract and have an abstract function what I call every time my BaseActivity gets a broadcast.
if you want to share some methods the best way it to impelement an interface or make an abstract class for baseactivty.
As others have pointed out, you need to use composition, since multiple inheritance is not possible in Java. This answer to a related question explains how to do this in the case of Android Activities.
Related
Total beginner here.
As I understand, fragments should communicate with each other through their hosting activities as a way to stay independent and reusable in other situations.
I’ve read that should be done by declaring interfaces in the fragment and implementing them in the activity.
Is that the best way to go about it “just” because you can make sure the activity is ready for that communication (it really has that method to deal with the communication)?
As I’m having a hard time wrapping my head around interfaces (and lots of others things in java/android, for that matter), could this be done without the interface? Could I get a reference to the hosting activity in the fragment and just call the activity’s method?
(fragment class)
Activity activity = getActivity();
activity.doThatThingToOtherFrag(String myString);
(activity class)
Fragment otherFragment = getSupportFragmentManager().findFragmentById(R.id.myOtherFrag);
public void doThatThingToOtherFrag(String string) {
//do something to myOtherFrag
}
Or is there something else about implementing an interface in this case that I’m not getting?
* EDIT *
Let’s say I reuse that fragment in another activity. As long as that activity also has a doThatThingToOtherFrag(String myString) method, I can get a reference to it through getActivity() and still call activity.doThatThingToOtherFrag(String myString) from my fragment, right? I wouldn’t have to change anything in my fragment code -- or am I’m missing something here?
I guess my question should be: is the interface there only to MAKE SURE the/any hosting activity implements a doThatThingToOtherFrag method? Or is there something else I don’t know about interfaces in this situation? Thanks for the help!
"Program to the interface." is a common maxim of object oriented programming. You can certainly just communicate with the activity directly without using the interface. However, this create a tight coupling between the fragment and the activity.
Consider a situation where you want to reuse the same fragment in two different activities. Using interface allows the flexibility to do this.
Answer to edit:
As long as that activity also has a doThatThingToOtherFrag(String myString) method, I can get a reference to it through getActivity() and still call activity.doThatThingToOtherFrag(String myString) from my fragment, right?
I assume you mean something like this:
Activity activity = getActivity();
activity.doThatThingToOtherFrag(String myString);
This won't compile because Activity doesn't have a method named doThatThingToOtherFrag(). However, if you do
FragmentCommunicationInterface activity = (FragmentCommunicationInterface) getActivity();
activity.doThatThingToOtherFrag(String myString);
now it will compile. This has yet another problem: what if the fragment where this is called was added to an Activity which doesn't implement FragmentCommunicationInterface. Now you will get a run-time error when you do the case.
One possible solution to this is to take a FragmentCommunicationInterface as an argument to the fragment's constructor:
public class MyFragment extends Fragment {
private FragmentCommunicationInterface communication;
public MyFragment(FragmentCommunicationInterface communication) {
this.communication = communication;
}
}
Now you create a fragment with
MyFragment frag = new MyFragment(this);
Another advantage to using an interface is that the interface can be implemented by any class not just classes which extend Activity. This allows even more flexibility than I hinted above. It allows you to organize the code to communicate with the activity or other fragments in any way you want.
It's not really necessary, but it may be desirable.
In general, interfaces help code not depend on the class whose code you call. You don't really care which Fragment class you're invoking, what you really care is that whatever you're invoking, it needs to have the ability to doThisOrThat() -- so that's what you put in your interface.
This decoupling is actually about helping to use polymorphism. Say your code may use two Fragment classes where you now use one, and both ca n doThisOrThat(). In that case using an interface will help you write cleaner code, because you won't need to write duplicate code to invoke the same method, except for changing what you cast it to.
Anyway, in order to really decouple you classes, you might want to learn about EventBus (doesn't matter which implementation).
This way you can make your fragment work with any activity that implements the interface. This completely adds to the independence and reusability you pointed out in your question.
If you would use the activity class's method to 'communicate' you would not be able to make it work (interface with) other activities because they are of a different class.
One good reason not to do the way you implemented as above is loose coupling. It is a program design pattern to create well-designed software. I am not gonna create a new discussion of it here since a lot of other discussions are available in StackOverflow.
What is "loose coupling?" Please provide examples
Please take time to understand this concept as this will save you a lot of time as a programmer.
Cheers!
Interfaces are best for communicating two fragments, 2 activities or communicate with any class, because interface triggered at same time when other want to communicate.
I have two activities: AddContact and EditContact. They both share a lot of common instance variables and methods that act on that data.
What would be the best way to refactor this code so that there wouldn't be any duplicate code?
Can you recommend any specific design patterns to use? The most obvious of course would be inheritance, but since every activity in android already extends Activity, this is out of the question.
I already thought of making another class that extends Activity, then putting common variables and methods inside this class, and then initializing this class in both AddContact and EditContact. However, if this really is the best way to go, should I make all the methods and instance variables in this shared class static?
Thank you very much for your time.
How is Inheritance out of the question? You could have a base class that extends Activity, then have your two other classes extend that to inherit the shared functionality for example:
public class MainActivity extends Activity {
//Common functionality and instance methods
}
public class AddContact extends MainActivity {
//Has all of Main Activity's non private methods/variables
}
public class EditContact extends MainActivity {
//Has all of MainActivity's non private methods/variables.
}
Also, if you don't want your MainActivity to be used directly, you could just make it abstract to ensure that the subclasses are used instead. This gives you the perk of reducing redundancy by sharing methods/variables, and also allows you to extend this functionality to make it specific to each subclass, if needed.
The other option is to just use a Singleton to encapsulate common functionality.
It depends on that exactly you want to share between two activities. But in my opinion, the best way would be to move common functionality into a Fragment and use it in both activities. If this functionality has visual elements, then it can be visible Fragment with layout. Otherwise it can be invisible fragment with pure logic in it.
I wouldn't recommend inheritance, creating a single class common code is really good for reusability however, take on count that each class extending from your base class will be allocating duplicated memory for things with the same purpose, google do not recommend it unless really necessary and the advantages you are getting out of it are really clear, you should take a look at the Singleton design patterns, this seems like a good example of when to implement it, basically you will have 1 single instance that does the job among different components without having to allocate new objects every time, just reusing the one already created.
Hope it helps!
Regards!
public class Contact
{
String name
//implement the rest of contact's functionality
}
public class AddContact extends Activity
{
// Create a new instance of Contact
}
public class EditContact extends Activity
{
// Create a new instance of Contact
}
Only create static methods if it makes sense calling the method if an object has not been created
public class MainActivity extends fragment
public class MainActivity extends Activity
The issue I have is that I need to extend Fragment to be able to use the 'pager_title_strip' but to use a list view that can read json, it also needs to be extended.
How can I extend both within the same class?
You can't, a class can only extend one other class.
It can however implement multiple interfaces, maybe that can help you in your design.
Abstractly spoken, multiple inheritance is not the only answer to such design problems, and in Java it was excluded by designers of Java (Gosling et.al.) because they saw it as inherently unsafe. Still in Java 8 multiple inheritance is only allowed for behaviour (see interface inheritance and new "default" methods), but not in state.
Alternatively, you can also think about composition or delegate patterns. From Joshua Bloch we know his recommendation "Favor composition for inheritance". I think this should be possible in your case.
There is FragmentActivity or ActionBarActivity class which may solve your problem!
http://developer.android.com/reference/android/support/v4/app/FragmentActivity.html
The issue I have is that I need to extend Fragment to be able to use the 'pager_title_strip'
There is no requirement to use fragments at all with a ViewPager, let alone with a PagerTitleStrip or PagerTabStrip.
so saying that does this mean you aren't able to use a listview box that reads json and the pager title strip at the same time?
It is perfectly possible to "use a listview box that reads json and the pager title strip at the same time". However, you will need to create more than one Java class, in all likelihood, such as an Activity and a Fragment.
The question doesn't really make sense, but this should help explain it better.
I'm currently using the IOIO, and it works like this:
public class MainActivity extends CustomIOIOActivity {}
From there I can call classes I've made in CustomIOIOActivity, which extends Activity.
The problem I'm running into now is that I have to inherit classes different from just Activity. For example, FragmentActivity.
Is there a way for me to create a custom IOIO activity which I can use for when I extend Activity and FragmentActivity? I don't want to have to make two essentially identical classes, which is what I am doing right now--seems silly. I'm not very familiar with Java, perhaps this is easy to do.
In Java you can't inherit class from more than one superclass. In order to achive your purpose, I would advise you to move all common logic to another class(IOIOHolder, for example), which would take an Activity parameter in constructor. Later you can create two different classes extending Activity and FragmentActivity, each containing an exemplar of IOIOHolder and using it for it's own tasks. By using this approach you can write IOIO code once and use it in any activity you want.
I wish to have a single class which all of my Activity classes extend. I have ListActivities, Activities, MapActivities, TabActivities, etc in my App.
I have many of these different activities in my app, ~12 activities. I want each of them to have the methods which are in the parent class.
Right now, i have created 4 parent activity classes which are extended from a certain activity depending on their type(ListActivity, Activity, MapActivity, TabActivity)
I am creating a lot of redundant code - each of the 4 parent activities has almost identical code, in exception for what class activity it extends.
Here is an example that may clarify what my problem is:
I have an Activity: MenuScreen which extends BaseListActivity
BaseListActivity extends ListActivity
BaseListActivity contains methods and fields which i want all my activities to have access to
I have another Activity: HomeScreen which extends BaseActivity
BaseActivity extends Activity
BaseActivity contains the same methods and fields which are in my other Base[<type>]Activity classes(such as BaseListActivity)
these methods/fields are copy-pasted to all my Base[<type>]Activity, and seems awfully redundant to me.
Can i create a master activity class which all types of Activity classes can use as its parent? if not, am i stuck with copy and pasting this code and feeling gross/dirty about it?
Can i create a master activity class which all types of Activity classes can use as its parent?
No, sorry.
if not, am i stuck with copy and pasting this code and feeling gross/dirty about it?
First, you do not need ListActivity or TabActivity. You do not need ListActivity for a ListView; you do not need TabActivity for a TabHost. That knocks things down to two base classes: Activity and MapActivity. Unfortunately, you do need to extend MapActivity to use MapView.
For that, you can use composition to minimize redundancy. Rather than your "methods and fields which i want all my activities to have access to" being implemented on the activity, implement them on some other object, and have BaseActivity and BaseMapActivity hold onto an instance of that object. You will still need some amount of duplicate code (e.g., for lifecycle methods like onStop()), but more stuff can be located in a single class.
Yes, you can make a master class, that has all the redundant code. Although the problem is, that you use ListActivities, TabActivites and so on, which are only convenience classes (they extends the Activity class and do some chores for you, but not that much).
I'd just ditch them, make a class named BaseActivity that extends the Activity class, and has all the redundant code parts. Then, all your activites should extends BaseActivity.