Android fragments can be embed in Activity files as public static inner class.
Or define in independent files.
What is the better way?
By common sense, I'd implement them as separate files. I do so, for a better code maintenance.
I only use a class in a class or a class into an activity (or fragment) if it's only used in that place and serves as a helper for that,
I normally separate all classes, activities and fragments and I prefix them with CLS_, ACT_ and FRG_ for a better separation and a quicker access in editing my code.
Related
I was wondering if I have 2 activities that needs to update and access the same object . What would be the best way to do it? Should I use Application class? Or perhaps Static variable.. Etc?
Another option I can think of is putting it in a base class that both activities inherit. I will initialize the object from shared preferences during OnResume
If your object holds some kind of preference value, don't put it into a super-class. Make it static and/or use the singleton pattern and separate it from your application logic. This provides you with a more modular structure that will be easier to work with. The application class is probably overkill; singletons do the job most of the time. (The Android docs simply states: "There is normally no need to subclass Application.")
You can add it to a super-class, if it is a logical part of it though.
Don't forget to synchronize your object if it's going to be accessed by another/several thread(s).
There are different method to perform such requirement. Singleton is one of them. The other one is extending the application class. If you want a reference outlining all of these methods please see:
What's the best way to share data between activities?
Which one is better option for application or activities?
A. BaseActivity class, [OR]
B.Singleton class.
In my application most of activities do same actions like show toasts, maintaining sessions, static variables,show EditText errors, HTTP request/response, etc., For now I'm extends BaseActivity in all my Activities where needed.
You're on the right path, a BaseClass is preferred because most of those thing you mentioned (Manipulating Toasts, EditText functions) require a Context to work with. A Singleton class would need that Context passed to it with every method call - a BaseClass does not (since it is technically a Context itself).
These are two fundermental different design patterns.
BaseActivity --> Inheritance
Use a Singleton in all activities --> Aggregate pattern
You find many posts in the internet about advantage and disadvantage of both patterns.
For your specific problem I would suggest to use inheritance. It is a common way to do and you should avoid to use the singleton pattern if possible.
I have this android application and I am trying to extend two classes at the same time. I have this code:
public class TimelineFragment extends Fragment {
public class TimelineFragment extends Activity {
//all codes here
}
}
On my second TimelineFragment, it has an error that says: The nested type TimelineFragment cannot hide an enclosing type
I have this android application and I am trying to extend two classes at the same time
That is not possible. Java does not support multiple inheritance.
I have this code
Given your class name is TimelineFragment, one presumes that it should extend Fragment. Whatever problem you are trying to solve via multiple inheritance will need to be solved in some other way. For example, if you are trying to perform operations on the activity that hosts your fragment, you can call getActivity() from the fragment.
Multiple inharitance is not possible in Java, and therefore in Android.
multiple inheritance is not possible in java so therefore u cant't use it in android as well.
Well one thing you can do is to create interfaces instead of class and implement any no. of interfaces you want and their methods.
I was wondering if it was considered poor practice to create a single java class or enum that contained all my application's different Intent actions. If not in a class or enum, then maybe one of the XML files? I plan on using LocalBroadcastManager to handle events to decrease coupling.
I do not see anything particularly 'good' but surely it is possible to have a utility class consisting of public static final Strings representing your actions. It should then have a private constructor and you will not want to subclass from that class.
I wouldn't put the constants in an interface though because you will have to implement that interface then but what you want is usage and not the implementation.
There's an advice in 'Effective Java' to avoid purely constant interfaces.
I would say it is Good to have all Intent Action in a single Java Class, or you can have Interface for it.
I can create an intermediate activity class like MyAppActivity, to contain common code used across my activities, but this obviously doesn't work if the app also needs to subclass MapActivity.
What's the solution? Options I see:
Move as many methods as possible to an ActivityUtils class (yuk)
Accept some duplication (yuk)
Subclass MapActivity, and use that class to subclass my actual activities. I'm not sure what the downside to this is. MapActivity doesn't seem to object if there's no MapView present. Ugly, but I suspect rather less ugly than duplicating lots of code which has a direct negative impact on quality and maintenance.
This challenge also applies with PreferenceActivity.
It is not possible to use a common Helper class with static methods?
EDIT: ah maybe that's your first mentioned option