I'm wanting to extend both a MapActivity and a FragmentActivity. I know Java doesn't allow multiple inheritance, so how do I do this? I've read something about a 'composite' type, but I've never implemented one so I don't know how to go about doing that.
Someone else HAS to have run into this before, how did you solve it?
EDIT: The reason I want this is because I have 3 activities in tabs; a map, an image gallery, and a settings list view. The code for all three of these "acitivities" is inside one big MapActivity called "Main". Yes I know this is ugly, and not good programming practice, and I don't remember why I wrote it this way. I think it was because I was reading most people recommended NOT having separate activities for separate tabs... which if I decided to split them into separate activities, I wouldn't have this problem anymore.
I have no idea why you would want such a thing, but I suppose the easiest solution is something like ActivityGroup, something similar to how TabbedActivity works.
I ended up solving this by going in and modifying the source of the Android support package and deploying my app with that. Outlined here, all I did was make FragmentActivity (android.support.v4.app) extend MapActivity. I don't think the reverse works... though maybe, and it would require you having the source of the mapping library you're using (in the case of Google Maps - no go)
Related
I would want to make two similar activities in android. If i change something in one, the changes appear simultaneously in the other. So it's as if they were a constant copy of each other. Is it possible to do that in Android ? Thank you to everyone !
Take a look at abstract classes http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html. Essentially, you make one class that does all the commonly shared logic, and have each child class extend that. That way you make your code changes once. Hopefully I understood your question correctly. Please comment if not.
My doubt here is how to achieve a clean and easy code to maintain over time in an Android app?, I'm trying to apply Uncle bob - clean code rules but as I keep going with development sometimes some rules must be broken, and I end with an Activity of 700 lines (I'm not using Fragment, and 700 lines seems to be a Class that "does too much things") so I want to know if someone has try an Android app with proper use of Fragment and could answer these questions:
1- does it really impact on Activity lines length (at least less than 300-500 [not strictly this numbers but a "reasonable" Class length] lines)?
2- does code keep clean and easy over the time?, not necessary with Uncle bob rules but considering best practice in OO while coding.
3- does it have a considerable impact in terms of "Performance"?
4- does Fragment help to support in a more simple way a wide fan of Screens?"
5- ignoring developer skills, what "should" be the way to go non-Fragment activities or activities with rich Fragment use?
Note: this is not an attemp of Duplication to Android - Activity vs FragmentActivity? since the topic here is not about tab format but best practice for android development.
sorry for my english ;).
You are conflating the use of fragments with the use of FragmentActivity.
FragmentActivity is a subclass of Activity designed for use with the backport of fragments from the Android Support package. You usually only use FragmentActivity if you are using the backport. If you are using fragments, but your android:minSdkVersion is set to 11 or higher, you can usually skip FragmentActivity.
With that in mind:
does it really impact on Activity lines length (at least less than 300 lines)?
That is impossible to say. It is equivalent to asking whether a Restaurant that subclasses Business will be longer or shorter than a Restaurant that subclasses FoodSupplier. It all depends on your code.
That being said, it is certainly possible that the use of fragments will reduce the lines of code in the activity. IMHO, that's not a good reason to use fragments.
does code keep clean and easy over the time?, not necessary with Uncle bob rules but considering best practice in OO while coding.
That is impossible to say. It is equivalent to asking whether a Restaurant that subclasses Business will be "clean and easy" compared to a Restaurant that subclasses FoodSupplier. It all depends on your code.
does it have a considerable impact in terms of "Performance"?
Not usually.
does Fragment help to support in a more simple way a wide fan of Screens?"
If by "wide fan of screens", you mean "a wide range of screen sizes", then yes, fragments can help with that. In fact, that's the #1 reason for using fragments, IMHO. However, fragments alone do not magically help with screen sizes, any more than having capital letters in method names magically helps with screen sizes.
ignoring developer skills, what "should" be the way to go FragmentActivity or Activity?
As stated previously, you usually only use FragmentActivity if you are using the backport of fragments. If you are using fragments, but your android:minSdkVersion is set to 11 or higher, you can usually skip FragmentActivity.
If your question really is "should I be using fragments in my app?", the answer is "probably, but it depends upon the app".
Yes, fragments are the way to go. They help spread your code around in a logical way so you don't have a 700 line activity, they keep your code easy because each fragment will have its own class usually, and they do, to answer your 4th question, make it easy to have "A wide fan of Screens".
I recommend this video to help get you started. For any beginners, this video is a great explanation of how to use fragments ( I know because I had a hard time figuring out how to use them until I watched this video). It is called "Programming Android with Fragments" by Andrew Ruffolo:
http://www.youtube.com/watch?v=KyXvq_kwfzg
This video demonstrates the power of fragments. You still need a main activity of some kind, but this main activity acts kind of like a container for the fragments, and most of the functionality of your app is handled by the fragments and their corresponding classes.
I have never used activities because I started app development after fragments were added to android, but it seems like fragments help break down your app in the same way that methods and inner classes help break down your classes, and the same way that classes help break down a project or program. I am not sure if this was possible or as simple using only activities before fragments were added.
I've been working on a app for the past month which basically consists of a TabControlActivity with a few ActivityGroups within this Tab.
I decided on using ActivityGroups basically because my knowledge as far as Android programming goes is very limited and at the time I had no clue that you're "supposed" to use Fragments for these things(Making sure that the tabwidget persists even if a new activity is started)
Now, Using ActivityGroups has forced me into doing things I really didn't think was needed. These are the methods I feel like ive been forced to implement in each ActivityGroup to make the application act the way I wanted it to.
I hope I've been able to pain a pretty good picture of my project. What I want to know is how much "effort" and recoding it would take to switch into using fragments instead of ActivityGroups.
Your question is not narrowed down enough. But from whatever I understood, this link might help. It says move the code from activity's callback methods to corresponding Fragment's callback methods. Thats a good way to start.
Good luck.
I was wondering if instead of having to create a new class for each activity is it possible to create mulitiple activities within one class?
So define various layout xml for various activities within one class, instead of having to create new classes for each activity.
Thanks
No, you should put each activity in seperate class. Take a look at this question. Someone is wondering just the same thing as you.
Ricky,
Yes, you may have multiple "Activities" defined inside a single class. But there are a lot of obstacles and issues with doing so. Before I answer this question, two things must be understood:
What you are asking goes against the Android guidelines for development, and those guidelines are enforced in as many ways as they can be during the compilation process, so nothing I say here is insured to work across any or all API versions of the Android SDK.
Different development environments do their own checks and compile in slightly different ways. I will be speaking from the Eclipse side of development.
Techniques listed here are for education, but introduce a lot of issues. For self education and theory, it is a wonderful practice to explore. However, the goal of this answer is to educate you as to why the guideline should be followed rather than sidestepped.
Requirements for an Activity
The first thing to understand is that Android has specific points that must be met for an Activity to be run. It must: a) be declared in the manifest; b) have an intent-filter describing how it is to be used; c) be a public class; d) be a top-level class.
Multiple Activities, Same Parent Class
This means that you may create an Activity inside of another class (an inner Activity, so to speak), but it must be declared static and public. This limits your Activity in a huge number of ways. Calls to methods or members that are instance-related (not static) to the parent class are not possible. So you lose a lot of time and code hacking around this.
Second, it affects your Android XML declaration for your Activity. This is where the real trouble comes in, because while it can be done, it is very specific and there is not any supporting documentation to make that happen. But that's okay, you wanted to know if you could make ONE class for your Activities.
Multiple Activities, Same Class
Well, Android determines which Activity to run based on its Intent. You could declare the same class multiple times, but with different Names and Intent-filters. If this is the case, then you would have to determine what to do based on the Intent and the extras included. This would be done in your onCreate() method.
Doing things in this manner would mean that you would have to code for two Activities in every place that you would normally deal with one. This would make it much harder to track down bugs to support your product. It would also make every routine operation take longer as you would have to decide which method to perform. For instance, if you overrode onDraw(), you would have to know which Activity you were drawing. Its ultimately just a big schmorgasborg (sp? does anyone know how to spell that word?) of "what do I do?!"
The Real Question
Why would you want to do this anyway?
1. If the answer is to save yourself time navigating your own project, believe me... That won't really happen. Your code will be harder to read, interpret and debug.
If the answer is that you want to save file space, I would reconsider your project's priorities.
If the answer is that you want to share functionality, consider extending Activity and then extending your new sub class. How do you think they made the ListActivity or TabActivity to begin with?
If you want to save state, you can place state in SharedPreferences or your Application object (if you have extended it).
As you can see, no matter your needs, there are many other ways to go about it in a way that doesn't cause you or anyone else a hassle.
Hope this helps,
FuzzicalLogic
I'm working on an Android app having an always visible tabbar.
However, each tab potentially contains many nested "screens".
Of course the back-button needs to handle this correctly.
I've now spent most of the day finding out what's the best architecture to achieve this.
There are also several similar questions on stackoverflow, but I couldn't really find an answer working for me. Two proposals I found and tried out:
switch view, see here
work with ActivityGroup, see here
Another approach I thought about is just implement all "screens" as normal activities and have them all have their own tabbar (but looking the same, so for the user it doesn't change).
I've seen that should be possible without too much redundant code by using include statement in layout xml and maybe create a common base class "CustomActivity" which configures the tabbar.
However since I'm not yet experienced with Android, I wanted to ask here before spending more time with try and error style.
Is this an approach which makes sense? If not, what would be a better solution?
Btw: The proposals mentioned above didn't work for me mainly because with neither the back button worked for me.
Thanks for every input!
Use Fragments API, ActivityGroup seems to be deprecated.