0

I have two ListActivity classes that I want to pass into into a third class as below. The reason being that I'm using the deprecated android.text.ClipboardManager in one activity for old Android versions, and the newer android.content.ClipboardManager for the other one. These are used in different ways and need to be separated.

Activity1

import android.content.ClipboardManager;

public class Activity1 extends ListActivity {
    ThirdClass tc = new ThirdClass(this);
}

Activity2

import android.text.ClipboardManager; <--- different

public class Activity2 extends ListActivity {
    ThirdClass tc = new ThirdClass(this);
}

ThirdClass

public class ThirdClass {

    public ThirdClass (ListActivity la){
        //do stuff
    }

    //other methods
}

In this third class I want there to be shared code that are used for both ListActivity classes. However, the third class needs to be able to tell whether it's working with Activity1 or Activity2 so that it can use the specific variables and methods that are defined within these classes. This can be done by casting the class name like this:

((Activity1) la).whatever

My question is, what's the easiest way to retrieve the class name Activity1 or Activity2 with code from the ListActivity variable "la" that has been passed down to ThirdClass?

The only way I've been able to figure out myself is by using getClass() and getName() and then using if statements as below.

String activity = la.getClass().getName();

if (activity == com.stuff.Activity1) {
    //do stuff
}

But there has to be a better way so that I can directly cast the class name to anything using the "la" variable?

UPDATE

Using instanceof would result in a lot of duplicate code since I would have to write it up once for each instance as below. I'm hoping to avoid this.

if (la instanceof Activity1) {
    ((Activity1) la).whatever
}

if (la instanceof Activity2) {
    ((Activity2) la).whatever
}

Using an interface that contains the needed methods like Stefan suggested may be a good idea? I actually don't know much about interfaces so haven't considered this. I'll look into it.

mattboy
  • 2,870
  • 5
  • 26
  • 40

4 Answers4

1

Do it with instance of:

if (la instanceof Activity1)

This is the java way to check if something is instance of specific class.

EDIT And once more the question turns out to be completely different from the initial statement. You are faced with classic form of the Strategy design pattern - many sources on the net, I have linked to Wikipedia. Basically this is a design pattern that allows you to choose the algorithm to use based on the circumstances. Exactly your case. In the article I link, there is a very simple example.

As for learning basics of design patterns I will definitely recommend the book of Gang of Four. Everybody knows it.

Boris Strandjev
  • 46,145
  • 15
  • 108
  • 135
  • Thanks. This makes things very different and I would need to rethink my entire code so far, but I do think is the right answer. I'll probably stick to having a lot of duplicate code for now though. – mattboy Mar 24 '12 at 18:05
1

using instanceOf should work if you know the listactivity classes at compile time Also see: What is the difference between instanceof and Class.isAssignableFrom(...)?

Community
  • 1
  • 1
Vijay Agrawal
  • 3,751
  • 2
  • 23
  • 25
1

At the momement you are required to call from a ListActivity. For that no need is given.

And you bind your code extremely strong to the names of the caller. This is rather bad.

I would propose to define an interface with all methods you need to work on. This is much more flexible and probably you dont need to know the concrete name of the caller

stefan bachert
  • 9,413
  • 4
  • 33
  • 40
1

Requiring to use instanceof is almost always a code smell, that is a sign of a bad design. If you can't interchange Activity1 by Actitivity2 (that is, substitute them), they should probably not extend the same class.

helpermethod
  • 59,493
  • 71
  • 188
  • 276
  • It wouldn't surprise me if there's a better way to do this since I'm a total noob, but the reason why it's done is because one class is for older versions of Android and uses (and has to use) old, deprecated code whereas the other is for newer versions and uses up to date code. Then I hope to gather the common code into one separate place like this. – mattboy Mar 24 '12 at 16:16