Thanks Stoyan,
Is it a case of declaring the activity with android:configChanges in
the AndroidManifest.xml, and then implementing what to reload in the
onConfigurationChanged(Configuration) of that particular activity?
On Mar 11, 11:23 am, Stoyan Damov stoyan.da...@gmail.com wrote:
It's not
For some reason that seems not to work in my case. I've declared the
activity as android:configChanges=orientation in the
AndroidManifest.xml, which I assume will call onConfigurationChanged
(Configuration). So for testing purposes I've simply implemented it as
follows:
@Override
public void
keyboardHidden|orientation
On Wed, Mar 11, 2009 at 2:34 PM, mobilekid mobilek...@googlemail.com wrote:
For some reason that seems not to work in my case. I've declared the
activity as android:configChanges=orientation in the
AndroidManifest.xml, which I assume will call
That will solve the problem when opening/closing the keyboard, but
won't solve it when e.g. starting the app and then immediately hitting
the back button to exit it.
On Wed, Mar 11, 2009 at 5:37 AM, Stoyan Damov stoyan.da...@gmail.com wrote:
keyboardHidden|orientation
On Wed, Mar 11, 2009
Sweet! Thank you!
On Mar 11, 12:37 pm, Stoyan Damov stoyan.da...@gmail.com wrote:
keyboardHidden|orientation
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
unless he traps the back button in onKeyDown
On Wed, Mar 11, 2009 at 2:51 PM, Marco Nelissen marc...@android.com wrote:
That will solve the problem when opening/closing the keyboard, but
won't solve it when e.g. starting the app and then immediately hitting
the back button to exit it.
On
I've been dealing with the same issues and i tried all these. And
nothing seems to work well.
First of all, having a thread that's part of your activity running
after your activity's onDestroy has been called is tricky. It can lead
to memory-leaks, etc.
I finally decided to create a Service for
Sure, but then what if right as the activity is starting, something
else happens that causes it to be destroyed? (incoming phone call,
camera app is started, it could be anything, really)
My point was: instead of putting in all these hacks to try and prevent
your activity from being stopped and
Yes, a Service is what you want to use if you want to continue doing work
after the user has exiting your app.
The original poster I think is dealing with thread that are just supposed to
be running while the app is being used, in which case I would avoid using a
Service, since that is likely to
Dianne... instead of making a Handler subclass, would it be just as
effective to have the Handler be a field of a custom Thread class
which is reset by a dying activity instance in
onRetainNonConfigurationInstance() and set by the new activity
instance in onCreate()?
Instead of retaining the
Answering my own question, I think the answer is that Dianne's way is
better than mine.
With Dianne's way, if the thread completes while the Activity is being
destroyed/created, there's still a Handler around to post a message
to. When the new Activity is created, it'll get the message that was
Yep, it's easier to take advantage of Handler to deal with a lot of the
threading grunginess for you.
On Wed, Mar 11, 2009 at 4:13 PM, Timo Bruck timot...@gmail.com wrote:
Answering my own question, I think the answer is that Dianne's way is
better than mine.
With Dianne's way, if the
12 matches
Mail list logo
