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.
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?
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.
I have a simple app, it logs a bunch of sensor/gps data. The first activity is a mess, and way too long, so i wanted to modularize it. I want to have 3 modules now:
Main Activity
Sensor Data (Gyroscope, accelerometer, etc)
GPS Data (Position, elevation, etc)
What is the best way for me to go about modularizing this? I was trying to move some of the Sensor Data out of the original class, and then I noticed that my class needed to extend some android.content.context (such as an Activity) in order to access the sensor data properly?
Thanks for a nudge in the right direction.
From my comments on the original question...
You don't need to extend Context - you can create helper classes and simply pass the Activity Context into the class constructor or into the various methods using this from the Activity.
As long as you design your helper classes correctly then it is fine and it is something that many people do and, indeed, there are various Android classes which require a Context parameter. Avoid memory leaks and use the right Context.
Sometimes using the application Context might be better as it is persistent for the life-time of all application components. It is, however, only a partial context in that certain things won't work with it (some UI-related tasks, for example). Otherwise using the Activity Context is fine as long as nothing holds a permanent reference to it (which can cause memory leaks if the Activity is destroyed.
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