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
Related
I would like to know if global declarations of too many variables bad in android activity class or fragment class.
Would it affect performance?
I would like to know if global declarations of too many variables bad in android activity class or fragment class
No, it the same case as with any other java class. Usually the less the better, for the sake of code maintenance, testability and simply readability. Too many global members may simply indicate that your code is messy and not isolated properly.
And how many is too many? If you got 10, even 20 - that'd be rather ok. But if you count 100, then I'd say there is definitely something wrong with the code.
Would it affect performance
Last thing to worry about here.
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.
This is a stylistic question more than an actual "how can this be done," but the basic situation is this: I have an Activity MyActivity which contains a MapFragment, as well as a List of Renderers which are my own class that takes care of displaying some data. The Renderers also have ViewPagers which get their content views from yet another class, let's call it ViewPagerTab. Sometimes, something happens in some of these ViewPagerTabs that necessitates the update of the map in the top level Activity. There are, as I see it, a few approaches:
1) Both my Renderers and my ViewPagerTabs contain a reference to the context. If I cast the context as MyActivity I can access its map parameter.
2) By using the reference to the context, I can call getSupportFragmentManager().findFragmentById(R.id.map)).getMap() on it and get the map that way.
3) I can pass the map down from the Activity to the Renderers to the ViewPagerTabs as they are created so the map is accessible in each as a class variable.
4) Use a BroadcastReceiver in my Activity and send a message to it when the map needs updating from my ViewPagerTab.
Have I missed anything? What's the best/cleanest way of doing this?
This lesson may give you some ideas:
Communicating with other Fragments
Basically, the idea is to define an interface in a subunit such as a Fragment, then implement it in the parent Activity. Then, actually call the methods in the interface in the Fragment.
Another alternative is to create a class that extends Application. There, you can "share and declare" a number of non-context specific variables (like a glorified container, but where you don't have to create multiple instances of, or do look ups).
Requires some setup in your manifest but then all your activities can call MyApp app = (MyApp) this.getApplication(); (or in fragments, via the onAttach activity's .getApplication() )
The standard way is to define a listener interface, but I've found this to be cumbersome. Otto is a really nice alternative that you should at least look into before making your decision.
I think this is a bit over my head but what about parcel.I think it wouldn't work because of the dynamic nature of your data however it is one way to communicate between activities.
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.
And which way is better?
Let me know if the question needs clarification.
For reusing passing the context is easier as you then can simply copy it to another project. Otherwise you have to change all the MyActivity.this to OtherProjectActivity.this.
But most of all it doesn't matter what you use
I have chosen to answer my own question, not because any of the answers are bad, but because while they are equally good, none provide a complete answer.
It seems that one of the main factors to take into consideration is reusability:
Using MyActivity.this to refer to the context means that you will have to modify your code if you ever decide to use the class in another project/class/context.
Passing the context in the constructor and referencing it as a private variable, allows you to reuse the class wherever you want without modifications.
Another factor that will influence your choice is whether your inner class is public or it is private. It doesn't make sense to make an inner class public and then reference the context with MyActivity.this. The application would force close the moment you use the class from another activity. I would argue though, that a public class belongs in its own file, but that is up to the individual developer.
Lastly there is the matter of simplicity, as it is simpler to write MyActivity.this than to implement a constructor etc. This seeming simplicity can come back and bite you, as you can see above, if you decide you need to use the class somewhere else.
I will continue to use MyActivity.this out of simplicity for all inline eventhandlers, but for any other situation it seems that passing the context to the constructor is best practice.
This is more of a design issue as having a reference either way will have the same result. Consider the complexity, the access level and other design elements related to the inner class.