Add a logging to your Droid1 project. Within the onCreate() callback method, add an informational logging message, using the Log.i() method. Run the application and view the log results.
[For example, where would I type "onCreate()"? In the manifest? and under what
Implement some of the Activity callback methods in addition to onCreate(), such as onStart(), onRestart(), onResume(), onPause(), onStop(), and onDestroy(). Add a log message to each callback method and then run the application normally. View the log result to trace the application life cycle. Next, try some other scenarios, such as pausing or suspending the application and then resuming. Simulate an incoming call. Watch the application log to see how the activity responds to such events.
[ I understand how to simulate calls through the DDMS and etc., but other than that, I am clueless on where to type and of that code, and what variables if any to include.
I am running the latest Android SDK and using Eclipse.
EDIT: No this is not homework, this is from the Sam's Teach Yourself Book
EDIT(Revised): Once I get this..
public void onCreate(Bundle savedInstance) {
... code ...
}
where do I post this, in the Manifest.xml? under activity such as < activity >?
Android SDK uses Java as programming language. If you're familiar with Java you should start reading this:
Android Dev Guide
An activity in android SDK its (copy and paste) "[...]a single, focused thing that the user can do[...]". Here it is the whole explanation:
Activity guide
Good luck with your exercise :)
When you create a new Android project you will start out with a template activity, usually called MainActivity.java.
Inside this file you will see:
public void onCreate(Bundle savedInstance) {
... code ...
}
This is the onCreate() method. You can change the ... code ... part and try to use code from your book instead.
After you've played around with that a bit you can move on to more complicated code examples, such as the Samples section of the sdk.
Related
I am just starting my experience with Android development (I am watching tutorials right now). I looked at the activity lifecycle on the Android developers page, and I realized that the activity always goes through the onResume() method before it's visible to the user. Assuming I will be using no fragments in the activity, does that mean that most of the code logic should be within the onResume() method, and I should just inflate the layout once inside the onCreate() at the beginning?
Please Refer the site for the better understanding of the activity lifecycle
https://developer.android.com/guide/components/activities/activity-lifecycle
and also this for brief understanding
https://www.javatpoint.com/android-life-cycle-of-activity
Now answering your question onCreate() is not just for inflating the layout.
The main part of the core logic is written here and onResume() is called when you minimize the or open the app once again it is called again and again but onCreate() is called once untill and unless the control is not forwarded to another activity
Like in Java the start running from
public static void main(String[] args){
}
In Android(Activity) the first line will be executed will be from onCreate() and not from the onResume()
if you will practice the same and will habitual of this process again and again then you better understand what i m trying to tell nothing can be more useful than you practice and your understanding try to print the toast or Log on each and every state of the activity lifecycle and you better understand this without the help of anyone
Cheers Happy Coding!
In the sample app fetch method is called in onCreate(). Is it really a good place to do this? The application can be used (moves from foreground to background and vice-versa, opens new activities and going back to main activity) for weeks and onCreate() from the main Activity won't be called again. I don't think it is good solution where my app won't update my configs for such a long time.
Update:
It is very bad idea to fetch config values only in onCreate() method, some kind of check should be done in onStart(). Here is also some useful information: https://firebase.googleblog.com/2017/01/firebase-remote-config-loading.html
The link you shared shows example for demo purpose. Ideally you should do initialization in onCreate() and call for data in onStart() when onResume() gets called, the activity is visible and user can interact with your app.
As said by #Doug Stevenson in comment that there is no obligation, but you should follow what is given in docs for best practice.
I am preparing new version of one of my apps, and I made such huge changes in my app, that I need to do some data conversion exactly after update of app as absolutely first thing (before doing anything else). I figured out, that best place to do it would be in my class (which extends Application) in onCreate() method. I tested it few times, and it seems to work ok, but then I read documentation:
Base class for those who need to maintain global application state.
You can provide your own implementation by specifying its name in
your AndroidManifest.xml's tag, [b]which will cause
that class to be instantiated for you when the process for your
application/package is created[/b].
It looks like I am right, but I am not quite sure. Can you confirm/disprove it?
The Application constructor will be called first. Then the Application::onCreate() method will be called. The only exception I know of is if the Application contains a ContentProvider, it can receive calls before the Application does.
This is from here: http://developer.android.com/reference/android/app/Application.html#onCreate()
public void onCreate ()
Added in API level 1 Called when the application is starting, before
any activity, service, or receiver objects (excluding content
providers) have been created. Implementations should be as quick as
possible (for example using lazy initialization of state) since the
time spent in this function directly impacts the performance of
starting the first activity, service, or receiver in a process. If you
override this method, be sure to call super.onCreate().
Yes, that is right. You should do all your initial app configuration in the onCreate() method of the Application.
Besides if you use sqllite you can make migration in onUpgrade method of the SQLiteOpenHelper.
http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html
I have not tested it, and maybe there are some more relevant options out there, but for the upgrade the following looks promising: SQLiteOpenHelper.onUpgrade( SQLiteDatabase db, int oldVersion, int newVersion ).
So you can hang your update routines on that. The method you override should fire only when the database upgrade is needed.
Yes. The application onCreate method is the first method that is called when the process is started. you can put your code there without any problems.
here the documentation http://developer.android.com/reference/android/app/Application.html#onCreate()
Called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created. Implementations should be as quick as possible since the time spent in this function directly impacts the performance of starting the first activity...
be careful to make all the changes very quickly and be sure that you call the "upgrade" method only once.
Consider also the possibility to put this method in an AsyncTask, if its possible.
No it dosent..say you have activity A(launcher activity) and B...when you launch your app ...A loads starting from onCreate()...and say u started activity B, then it launches B and its onCreate method is executed..but now if you navigate back to A..it will call th onResume activity and not the onCreate..
I will start with the simple programme of android :
public class MyClass extends Activity
{
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main)
}
}
My question is why don't we use static with public void onCreate(Bundle savedInstanceState) like in Java also why there is no main function in it?
main is a Java convention for a desktop application which is built around the historical concept of an application that starts at point A (the first line of main) and goes to point B (the return from main) then stops.
An Android application is running in a very different environment. It is very much event driven. Rather than having main, what it has is a Looper (the android version of an event loop) The code you write is responding to events as they happen rather than turning command line parameters and files into output.
I’m not an expert, but here goes with a longish answer. Or answers.
Answer 1: Probably, Android uses an instance method because Java is designed for instance methods and fields. I find things work better with instances than statics.
So, why does a traditional-computer program have a static “main()”?
Answer 2: Probably because when a JVM is fired up, there a no instances of anything, so the designers thought the initially invoked method should be static.
Which brings us to the distinction you were probably hunting for: why is mobile-program different to traditional-program?
Answer 3: The lifecycle of a traditional program is much simpler than a mobile app. A traditional program starts up, runs, and exits. In Java, the JVM starts and dies with it. An Android app has a much more complicated lifecycle. A JVM can survive the user entering and exiting the app many times. And an activity is very lightweight – rotate your device from landscape to portrait, and the activity is killed and a new one started. For more on the activity lifecycle, see http://developer.android.com/training/basics/activity-lifecycle/index.html.
Consider a webserver. It is a long running process, which invokes application-layer code with an instance method for each request. I’d say an Android app is about half way between the two lifecycle models: traditional program and web application request.
(I’ve made some sweeping statements here. Being accurate about details would have made an even longer post.)
I have a couple of simple tests, like assertNotNull(mActivity); (I'm reading M.D.Torres "Android Application Testing Guide"). The activity under test runs okay. Every single test runs okay as well. But if I run several tests at once on the second test getActivity() never returns. No errors in logcat (last line "Starting Intent ..."), no nothing. Debugging doesn't help much either, if I step into getActivity() it complains that there is no source code available.
Another test project - ActivityTesting from Google runs okay even with several tests, so Eclipse is configured right.
Did anybody ever encounter something like that?
I recreated test project once more (like "clean room") and it worked. Then I compared two projects and found the culprit. It was empty teardown:
protected void tearDown() throws Exception {
}
If I remove it, all tests run green. If I paste it back, second test hangs. Now I would like to read the explanation and ready to mark it as answer.
Edit: I should be calling super.tearDown() at the end of the tearDown method.
Sorry for bothering everybody.
I used ActivityInstrumentationTestCase2 to test an Activity using ExoPlayer and correct resource clean up as well. As the clean up and final checks are the same for all the tests, I thought that tearDown() is a good place to implement them. All the tests run separately without any problem, but when I run multiple tests, sometimes getActivity() did not return. My tearDown() implemented various things:
check state of activity (various assert() calls)
check state of player (various assert() calls)
clean up player resources manually (calling close() and release())
setActivity(null) (this caused the trouble)
super.tearDown()
I tried all the suggested workarounds like overriding getActivity() and using the other methods of instrumentation to create and clean up the activity. These methods did not help.
And lots of debugging showed, that with above scenario the onDestory() of the activity of the previous test can overlap with the onCreate() of the activity of the next test. So the logs showed the life cycle events in this order:
test1.getActivity();
test1.tearDown() called;
test1.tearDown() over;
test2.getActivity()
test2.onCreate();
test1.onStop(); --> why is this late?
test1.onDestroy(); --> why is this late?
test2.tearDown() called;
test2.tearDown() over;
test3.getActiviy() --> this should call test3.onCreate, but did not and never returned.
This happens even when the test cases are implemented in separate ActivityInstrumentationTestCase2 classes/files. And the fist time this overlap does not cause trouble yet, so 2 tests are always OK, but running 3 tests in any order that result in this overlap causes the 3rd call to getActivity() to never return.
I tried everything like calling onPause() + onStop() + onDestroy() manually using the instrumentation, introducing really long sleep periods between tests, force clearing the activity of the instrumentationTestCase, reordering checks of my tearDown, but nothing helped. Finally, I accidentally removed setActivity( null) before my checks, and the life cycle events got correctly ordered:
test1.tearDown() called;
test1.onStop();
test1.onDestroy();
test1.tearDown() over;
test2.getActivity()
test2.onCreate();
...
So what really made the difference in my case: do not call ActivityTestCase.setActivity(). This causes the super.tearDown() not to call the life cycle events of the activity directly, clean up will happen later and cause trouble.