How do I avoid reloading the activity with asynctask class in activity when the user changes orientation, in android? Can anybody give an example?
Please turn off config changes as a last resort. Your app must work correctly when this happens. If you turn off the orientation config change because it breaks, your app will still break in other and some times more subtle way. Allowing the activity to be restarted due to an orientation config change is a very good way to easily test these important code paths of your app that are otherwise much less often exercised but still will result in failures in your users' hands.
To transfer active objects across Activity instances, use the new fragment static library which allows you to make a fragment that is retained for you across instances.
Chirag have already correctly pointed out the solution.
I just want to add that, restart of Activity has nothing to do with the AsyncTask in it. By default, when there are any config changes,the activity is restarted UNLESS the config change is explicitly handled by the Activity. This is done by making an entry in manifest file.
Go through this link developer guide : android:configChanges
NOTE: Check the code on a device not on emulator. Because I had faced similar problem earlier. The same code didn't worked on emulator but it worked on device perfectly. So add the entry for android:configChanges in manifest and check the application on a android device instead of emulator.
And I second #hackbod. Do it only if necessary!
Related
Currently working on an issue in our application where a dependency is reading the state of night mode from the Activity (i.e. activity.getResources().getConfiguration().uiMode & Configuration.UI_MODE_NIGHT_MASK). The Activity in question is configured with android:configChanges="uiMode" and I am seeing that the state of night mode never changes from light when reading from the Activity.
However the value is correct when reading from the Application (i.e. activity.getApplicationContext().getResources().getConfiguration().uiMode) and it is also correct in the Configuration object passed to onConfigurationChanged.
Unfortunately since its a dependency that is using the night mode value fixing my issue by simply using either of the objects that give the expected value isn't the simplest solution, so I would prefer to fix the root cause. Kind of at a loss for what is going wrong and I haven't been able to find why these values are differing.
there are a lot of questions around this, however I was not able to solve.
My app shouldnt restart when the device is put into a specific car cradle. I just want to ignore it
I tried changing manifest
+
What do I need to code if I would like to handle the Configuration Change by myself?
How would my onConfigurationChanged method look like to just ignore the uiMode change and not restarting the app?
Thanks
I had the same problem.
Here's the fix:
Modify your AndroidManifest.xml to include uiMode in the android:configChanges element.
After that your app will handle uiMode-changes all by itself and doesn't restart anymore.
Greeting,
Chris
I'm new to android development.
I download a toy project and want to figure out the flow of this project.
Can I use debugging to figure out it and how?
Let me explain it more detail. Every android project starts from an "main" activity. I guess I find the "main" activity for the project and set a breakpoint at the onCreate method of this "main" activity. I expect to run this project from that breakpoint one step by step to figure out the flow. However it doesn't work since the debugging stop after finishing the onCreate method.
Start with AndroidManifest.xml file. Open it and look for an Activity with LAUNCHER category. Then open that Activity and go to onCreate(...) method. This is where your app starts. Inside the method, there is a call to setContentView(R.layout.some_layout). some_layout.xml in res/layout folder is UI for this Activity.
Each window you see in Android app is an Activity and each Activity has a layout file.
The "flow" of an android application is more like an asynchronous model than a sequential flow of action. There is a main application loop that processes external events (such as clicks on button) and callbacks related to the activity lifecycle (such as your onCreate method), and lot of other stuff.
Every event is put into the queue and processed asynchronously, so it's not easy to follow it. It's better to think about actions and reactions. In any case you can dig into the android source code and see what's running behind the scenes. Some hints about the model of android apps can be found here but any google search for "android ui thread queue" would lead to relevant info.
If you want to learn the flow of a typical android application, I would recommend you download the samples if you haven't already and add your own log statements. You could use the debugger too. Then start making small changes here and there to force different 'flows' of control, as you make guesses about what should happen and observe your logging statements and the app behavior to see what's going on.
The sample projects can be downloaded from the adt plugin in eclipse and come as ready-made projects. They are also a good way to learn because they are generally the 'best-practice' way of doing things.
Hope that helps! Good luck :)
My app started to get really slow between activities and I started to investigate
from the time I run StartActivty until onCreate in that activity start, can take up to 1000ms
Can anyone tell me what this could be
I tried to remove everything in oncreate and it's not it.. it's simply the 800ms to 1000ms before it even runs onCreate
The reason could be hidden in your xml layout files. Xml parsing itself is resource consuming. So check them out.
If you are running the application in 4.x device. Please the Setting -> Developer Option-> Don't Keep Activites enabled or not.
If it's enabled your application might be slow.
Please check out the option.
I completely revamped an app. Tested it for a while on my device and emulator. The app worked fine. However when I updated the app through the Android market, my users experienced crashes.
Since there is no way to properly debug this procedure I asume the crash is caused by old data which is not being removed from the device (probably from the onsavedstate bundle?!).
Is there a way to do a "clean/total" reinstall without having the user to do it manually?
Best Regards
Johe
When the variable that's giving you trouble is overwritten with the proper type on the next OnPause, the class cast problem should be gone. You could reserve one variable to hold a version number and if the one you retrieve from OnResume is older you skip the other saved values and use the defaults.