TLDR:
I have to extend the application class but don't know where to start.
Ok... I know this is a dumb one but I have to ask it.
I need to install LeakCanary and I see in their documentation that it requires me to put code in the Application Class.
I understand how to make a java class that extends the application class, but I have some questions before I do this.
SITUATION:
I have 9 classes in my app already.
The entry point to my app is MainActivity.class (figures, right?)
I have not had to extend the Application Class yet.
App name is "CST-ALERT"
QUESTIONS:
Do I just create a new Java class in my java source folder and name it the same as my overall
package name? What do I name this new class?
Do I need to adjust the manifest now to have this as the entry point
instead of MainActivity? Which I imagine will change things quite a
bit for me.
Do I have to change anything else in the manifest? I assume I will
at least have to declare it in there.
Hopefully my situation and questions will give you an idea of what I am asking.
Do I just create a new Java class in my java source folder
Yes.
and name it the same as my overall package name?
If by "it", you mean the Java package, you already have a directory for your existing Java code. Put your subclass of Application in there, unless you have a clear reason not to.
In this trivial sample app, I put my Application subclass in the same directory as my launcher Activity, which is the directory for my Java package (com.commonsware.android.button).
What do I name this new class?
That is up to you. I called it CanaryApplication. If you think you leak a lot, call it CoalMine. So long as it is a legal Java class name, it doesn't matter.
Do I need to adjust the manifest now to have this as the entry point instead of MainActivity?
Um, well, I wouldn't describe MainActivity as the entry point. Regardless, MainActivity is left alone. You need to add an android:name attribute to the <application> element, identifying your Application subclass.
Do I have to change anything else in the manifest?
No, that should suffice.
Related
I just started playing around with android annotation.
I know that when I do #Eactivity, another ActivityName_ class is generated instead.
Now, in my code, i have ActivityName.this written somewhere. But when i change it into ActivityName_.this, my compiler starts to complain that it is not recognized. My question is how do I import the proper ActivityName_ ?
First of all, you do not have to change all the class names to the generated class name. In this case, writing ActivityName.this will work just fine. Actually you only have to use the generated class names for Activitys in two places:
in the manifest where you declare the Activity
in your intents, where you start an Activity (and you can use the generated Intent builder: ActivityName_.intent(this).start()
The generated classes will be available after you compile (make) the project. So please compile the classes first.
I want to open an activity without declaring it in an manifest file.
I don't know if it is possible or not.
What I actually want is to dynamically open an activity from my program using intents.
Can anyone help me if it is possible.
Not possible. Although I am unsure what you mean "dynamically open an activity".
See: http://developer.android.com/reference/android/app/Activity.html
Under Class Overview it states "To be of use with Context.startActivity(), all activity classes must have a corresponding declaration in their package's AndroidManifest.xml"
You can have an Activity in your package and not define it in the manifest, however you would not be able to start it successfully.
Your 'Dynamic' activity start is actually the normal way of starting an activity (as you have said in a comment to the answer of Matt M). Though you HAVE to add the Activities in manifest as Matt M said. In list view, clicking an activity will call a function that will start respective activity with startActivity() function.
I tried this very long, but since the Instrumentation class uses the IActivityTaskManager, which is a class of the internal API located at com.android.server.wm, that is not in the Activity classloader, I solved this by another method:
Using a subclass
I just made an Gist, with sample code.
GIST
Assuming I have a shared activity class defined in a Library project, which does not change for any application using it and thus does not need to be subclassed, can I get a way with creating applications without subclassing this activity for them?
To better explain my question, say I have a single activity in a Library project:
public class LibActivity extends Activity {
...
}
And now I am creating an application using that Library project. Do I really need to create
public class AppActivity extends LibActivity {
// totally empty!
}
Only so that the application have its own activity to be referenced in its own AndroidManifest.xml?
Can I get a way with a minimalistic approach, in which I subclass the activity only if I need to modify the library's activity core behavior?
Here is the fully qualified answer:
Yes, an activity based application doesn't have to derive an activity from the library's activity. The application simply uses the library's activity verbatim, unmodified.
Yes, I can get a way with a minimalistic approach, in which I subclass the activity only if I need to modify the library's activity core behavior.
I have been able to verify this with an AndroidManifest.xml that is identical in both the library and the application. It would be interesting to see whether some of this redundancy can be eliminated. I will experiment with this and report back.
UPDATE: Sure enough, it is possible to create a perfectly running application in which the only activity is defined in the library and the library's AndroidManifest.xml doesn't have any <application> or <activity>! This is possible if the application's AndroidManifest.xml has them.
You can reference library Activity classes directly from your application AndroidManifest.xml. Just specify the fully qualified name like so android:name="com.example.LibActivity"
I'm new to this and I'm sorry if this is a really dumb question. I'm just trying to clarify things. My book says I can retrieve application context for process by using the getApplicationContext() method. I just really don't know where to type this or what to do with any of it. I can go to the hierarchy but what do I do with all the script there. Also where would I write Activity Callbacks, in the main.xml? An exercise wants me to add a logging tag to my project but I'm not sure how to do this. The exact text says:
"Within the onCreate() callback method, add an informational logging message, using the Log.i() method."
and another exercise says to:
"Implement some of the Activity callback methods in addition to onCreate(), such as onStart(). Add a log message to each callback method and then run the application normally".
As these seem like basic questions, can someone please help me.
I am using the Android SDK, and Eclipse. I have made the Hello World application, but I have no idea what to do with Context or Retrieving resources. Please help!
The first rule I would give you: if you don't know why you need it, you probably don't need it. Use your activity object as the Context when you need a context.
The callbacks you talk about are on the Activity class. The Application Fundamentals describes what an Activity is: http://developer.android.com/guide/topics/fundamentals.html#Components
The only time you want to use getApplicationContext() is when you need a Context that exists outside of the lifecycle of an Activity class (or other component). You'll want to find documentation on specific cases where this is desired, there is a lot floating around. For example this one is part of the Android documentation: http://android-developers.blogspot.de/2009/01/avoiding-memory-leaks.html
For the tasks you're working with here, you'll be using the Java code that defines the behavior of the application, not the XML files that define resources and layouts or the AndroidManifest.xml file that declares basic application properties.
If you're working with Hour 3 of the Sam's Teach Yourself... book, then you need to open the src\com.androidbook.droid1\DroidActivity.java file. In general, you would need src\<package-name>\<class-name>.java. When you open that file, you'll see a class (in this case, DroidActivity) that extends Activity and already has the onCreate() callback method. Anything that you want to happen during onCreate() goes inside that method. Other callback methods can be added inside the activity class. To see an example that has all the lifecycle callbacks (but doesn't do anything in them), look here.
A logging tag is just a string. You can declare it, for example, as a private static final String inside the activity class.
If there's confusion about where methods belong, where and how to define variables or constants, how to call methods, how to use classes, and so forth, then it might be best to go through an introductory Java text before starting with Android. There are plenty of free resources available for that.
I go back and forth about how to name activity classes. Activity seems to imply a verb, like EditContact, for example. But that seems more like what one would call the Intent that triggers EditContact. Should the activity be named ContactEditor instead?
Interesting question. There is no right answer to this.
Personal opinion: Activities represent "places" in my application, so I name them accordingly: UserSettingsEditorActivity, MainScreenActivity, etc..
I've worked with a few projects and there doesn't seem to be a set way of doing it, and generally I follow the golden rule of name something by what it does. In this case, ContactEditor would be better, save your verbs for functions.