I have a menu that I want to implement on multiple activities. If I change the menu I don't want to have to update these everytime in every place
onCreateOptionsMenu()
or
onOptionsItemSelected()
Is there a way to include these sections in an activity and link it to a single file to edit the menu?
Option #1: Create your own subclass of Activity, implement those methods there, then extend your custom subclass for your actual activities.
Option #2: Create static methods someplace that implement the logic contained in those methods. Have each of your activities delegate to the static methods. This is a bit more work, but it still consolidates the real business logic, and you don't have to worry about any inheritance issues.
Related
I'm trying to learn more about proper architecture so I'm going to try to refactor some of my working code. I have an android app that swaps in a few different Fragments for the main view. Right now, the different fragments exist as properties in MainActivity. When the user picks a menu item I have to check what kind of Fragment is currently being shown (via instanceof) and perform some different tasks depending on what kind of fragment it is. It's pretty ugly and I feel like it should be better abstracted. In the future, the case statement will grow even more and need to be maintained. Also, most of the code is duplicated since I only really need to do something special for one fragment in particular. How can I abstract away these details out of MainActivity? I tried to make a base class for all my fragments but it didn't quite work out because some of the fragments extend MapFragment and some just extend Fragment. So I'm guessing an interface is the way to go but I'm not quite sure how to do it. Do I need to create an abstract factory to get these objects in MainActivity? What is the proper way to do this? After reading up a little bit on architecture, it seems to me that my MainActivity should only know about some abstractions for my Fragments and not the concrete classes themselves, is that correct? Thanks for any help you can provide.
I would like to add separate files for each fragment I want to add to my tabbed Android application. Each tab view should reference code contained in one of those separate files.
Is this possible?
Is it safe to split the logic completely out of the MainActivity class?
Should I simply call their onCreate events within onCreate in MainActivity or is there a better way?
Any input is appreciated as this diverges significantly from what I've read and seems like it could cause a lot of unforeseen problems. Albeit it would be great to have this for readability.
Not only is this possible, it's good practice. Typically, you create separate files for each of your classes. I understand your confusion, though, since the default "Tabbed Activity" project template puts the fragment logic in MainActivity. This isn't required.
It is completely safe to separate the Fragment-specific logic into its own file.
You shouldn't call onCreate yourself. The system does this for you.
I modified the "Tabbed Activity" template to use separate files for each tabbed fragment. Check it out here, and let me know if you have any other questions.
Hope this helps!
I'm creating an Android application. I need to override the draw method on a number of UI classes to create a custom appearance. These classes all subclass View. I'm wondering what the best way to do this is. I'd like to be able to reuse code as much as possible, so I'm looking for help in organizing things. As I see it right now, I have 2 options:
Option 1 - Subclass Everything
If I want to use LinearLayout, I create CustomLinearLayout. If I want to use ImageView, I create CustomImageView. On each of these custom classes, I override draw exactly the same way. This doesn't seem efficient because I'm repeating code and extending a number of classes which do almost nothing.
Option 2 - Subclass a Super Class
My original thought was to extend View and create CustomView, because it's already a superclass of all the classes I want to use. This, however, doesn't work because all the existing subclasses I want to use are still extending View, not CustomView.
Is there a better way to do this? Am I missing something?
One possible solution would be to extract your draw logic into a separate class DrawingCode. This could contain a static method or you could even use instances of DrawingCode to customize your drawing code with other parameters. Of course you'll still have to overwrite the draw() method, but only write one line of code to call DrawingCode.draw(param1, param2). This way you get to store your drawing code in one central place and don't repeat yourself.
This is a bit of a general question, but I will give a specific example for you.
I have a bunch of activities in an App. In all of the activities, there is a Facebook button. When you click the button it takes you to a specific Facebook page. I wish for the button to behave exactly the same way on every page.
Right now, in every single Activity, I create an onClickListener() for the Facebook button and make the intent and start the activity. It's the same code in every single Activity.
What is the best way to write this code once and include it in multiple activities? Is there anyway to include other .java files?
One solution that I know would work, is to make a base CustomActivity class that extends Activity and then have all activities extend CustomActivity. Then put my onClickListener() code in CustomActivity. I'm new to Java though and I wasn't sure if that was the best approach or not. Some of my Activities already extend other custom activity classes as is, so extending things that extend more things might get kinda messy, I dunno.
UPDATE
Playing the devil's advocate here: Lets say I went with the inheritance route and I create some CustomActivity that I want my Activities to extend. CustomActivity would contain a bunch of general code that I need to use for all Activities, including but not limited to the Facebook button functionality. What happens when there is an Activity that I need to use generic code from the CustomActivity but there is no Facebook button in that specific Activity?
A common base class is perhaps the best approach. (It doesn't work quite so well if some of your activities extend Activity and some extend Activity subclasses (such as ListActivity).
An alternate approach is to create a separate class that implements the logic of your click listener. This doesn't eliminate all duplicate code — each activity still needs to instantiate and register a listener — but the logic for what to do will only need to be written once in the listener class.
In either alternative, you might consider assigning the android:onClick attribute to the button. That way you don't need to register a click listener; you just need to implement the target method in each activity. This is particularly useful with the base class approach.
UPDATE
Suppose you go the inheritance route and you want an activity with no Facebook button. If you are using the android:onClick technique, then you don't have to do anything different in your code — since no button will invoke your onClick method, the method will just sit there doing nothing. If you are installing an OnClickListener in code, then you just need to test that the button exists (i.e., that findViewById() did not return null) before registering the listener.
Generally a common base class is NOT the best approach (although it's certainly valid).
This took me (and every OO programmer who "gets" OO that I know of) a while to really grok, but you should use inheritance as sparingly as you possibly can. Every time you do it you should ask yourself if there is REALLY no other way to do this.
One way to find out is to be very strict with the "is-a" test--if you call your base activity a "Facebook Activity", could you really say that each child "is" a Facebook activity? Probably not. Also if you decided to add in Twitter to some of the pages (but not others), how do you do this?
Not that inheritance is completely out! A great solution might be to extend a control to launch your facebook activity and call it a facebook button--have it encapsulate all the stuff you need to do to connect to facebook. Now you can add this to any page you want by simply dragging it on (I'm pretty sure android tools let you add new components to the pallet). It's not "Free" like extending your activity class, but in the long run it will cost you a lot less stress.
You probably won't believe me now, we all need to learn from our own experience, just keep this in mind and use it to evaluate your code as you evolve it over time.
--edit, comment response--
You can encapsulate any facebook activity you think you will use a lot in it's own class--get it to a bare minimum so you can just add it to any class in a one-liner.
At some point, however, you may decide that it's STILL too much boilerplate, I totally understand. At that point you COULD use an abstract base activity like you suggest, but I wouldn't hard-code it to handle facebook explicitly, instead I'd have it support behaviors such as facebook (and maybe others), and turn-on these behaviors as desired. You could then tell it NOT to add the facebook behavior to a given screen if you like, or add in Twitter to some of them.
You can make this boilerplate minimum, for instance if you want "Standard" functionality, you shouldn't have to do anything special, if you wish to disable facebook you might start your constructor with:
super(DISABLE_FACEBOOK_BEHAVIOR);
and if you want one that also enables Twitter you could use:
super(DISABLE_FACEBOOK_BEHAVIOR, ENABLE_TWITTER_BEHAVIOR);
with a constructor like AbstractAction(BehaviorEnum... behaviors).
This is more flexible and you actually can say that each if your activities IS-A "behavior supporting activity" with a clear conscience.
It is, of course, a perfectly good approach to be less flexible at first and refactor into a pattern like this later when you need to, just be on the look-out for your inheritance model causing problems so you don't let it mess you up for too long before you fix it.
Well, extending things is the principle of OOP, so I don't think this is a problem to have more than one level of subclasses. The solution you thought about is in my opinion the best.
Absolutely. Use inheritance to gain some reusability as you should with OOP. You'll find, as you progress, that there are gonna be more and more things you'd like to reuse in your activities -- things more complex than an onClickListener for a FB button -- so it's a great idea to start building a nice, reusable "super" activity that you can inherit from.
Hi all I am relatively new to OOD and Java hence am not sure how to do this properly.
Currently I need to create an application (console/command prompt based) that involves going through a series of so called "menus" where the application will display your choices and you enter 1/2/3/4 etc. My professor told me to break up my boundary class (the class where all the display of choices is in) because it's too long (400+ lines).
Now comes the problem. If i were to break it up, I would have to keep creating new object classes to call on the different menu in different classes. For example:
Let say I have MainMenu, FoodMenu, DrinkMenu. So my main method will create a MainMenu object to call displayMenu(). From there, if I want to navigate to the food menu, I have to create another FoodMenu object and call displayMenu() under it again. Further along the codes, if i want to navigate back to the main menu, I would then again have to create the MainMenu object again and call displayMenu.
The above method would have so many variables waiting to be garbage collected and a total waste of memory. Is there another solution around this? Thank you very much in advance.
Hamlyn
Make all your menus either extend an abstract class (okay) or implement an interface (better), if you're not already doing that.
As for how to get to the menus, you can just store one of each type of menu in a menu array or some other collection (for example, a Map if you want to be able to look them up using a string or other object). Have that collection be globally accessible (static in some public class) and then you can display the same instance of a menu each time you need it.
First of all, garbage collection problems happen when you have thousands of objects floating around, not... three. So don't even worry about that.
But in general, your thesis that you need to recreate all those objects is flawed. You only need one of each, and they simply need to be able to get access to references to one another. For example, each "displayMenu" method might take a Menu as an argument; that displayMenu() method would set things up so that the "return to previous menu" option invokes the Menu that was passed as an argument.
As discussed in How to Use Actions, the Action class is a convenient way "to separate functionality and state from a component." This example creates a menu of recent files using instances of the RecentFile class. A similar class for each of your MainMenu, FoodMenu, DrinkMenu might be a way to encapsulate related menu items.