Just make a Handler, have your thread post messages to it, and update the UI when receiving the message. Don't run your thread/service in another process, that adds a whole lot more complexity for nothing you need.
On Sun, Sep 6, 2009 at 9:20 PM, pink 444 <[email protected]> wrote: > > > First of all thanks for ur explanation.I have one more doubt. > > I have to run a thread in background till my forcing to stop it.the > thread running in background needs to update my main activity's UI > elements. > > How can i implement this . Do i need to use Services component .If it > all that is the case , one more process is created and added to my > application .Further i need to establish IPC between Main activity and > the Services component to update main activity UI element data , i > need to save Activity UI element's data . I think ,this is a clumsy > solution.Because simple application has lot of overhead. > > > Thanks, > -Siva. > > > > On Sep 2, 9:49 pm, Dianne Hackborn <[email protected]> wrote: > > On Wed, Sep 2, 2009 at 5:16 AM, pink 444 <[email protected]> wrote: > > > I got one way to solve my problem and it resembels your solution.What > > > i did is i made my EditText as static.Whenever oncreate() is called i > > > check EditText for previous version of instance,if at all previous > > > EditText was there i am getting it's data using EditText's standard > > > way EditText.getText().toString().It is working up to the mark in all > > > three situations ,when orientation is changed, "Home" button pressed > > > and "BACK" button is pressed. > > > > That is really broken, in many ways: > > > > - It leaks the whole activity and everything it owns (which the EditText > is > > part of). > > - It fails if the system needs to kill your process after the user > leaves. > > - There are no guarantees about the state of a widget after its host > window > > has been destroyed and view hierarchy torn down. > > > > At the very very least, extract the data out and store only that in a > > static. But that still has the problem that this will not work > > consistently, since you will lose the data whenever the system kills your > > process (which if the user has many background things running may be > > immediately). You should really use something like the solution I > > previously proposed. > > > > But the thing i think , i am not using properly is onSaveInstanceData > > > > > (),onRestoreInstanceData().Because those methods are standard > > > ones.Moreover there should be some reason why they are there. > > > > They are standard ones, there for the standard flow: the user leaves the > > activity to go somewhere else WITHOUT closing it (by pressing home, using > > the notification panel, simply pressing a button in your activity that > > causes it to start another), and while your activity is in the background > > the system needs to kill its process. Then when the user next returns to > > it, onCreate() will be called with the previously saved instance state so > > that they return to it in the same state as they left it (since from > their > > perspective, they didn't close it). > > > > The standard behavior of back is "close activity." If you want to do > > something different, you will need to do something non-standard. > > > > > My question is , Am i doing correct?? > > > > No. > > > > > Is there any standard way to retain EditText data when "BACK" button > > > is pressed.Why onSaveInstanceData() call back is not called when > > > "BACK" pressed.I have seen "google" home web page on android has on > > > "EditText" to accept data and it is retaining data in all the three > > > senarios. > > > > onSaveInstanceState() is not relevant because you are trying to do > something > > different than the standard UI flow it supports. The browser also does a > > lot of special things for its navigation (pressing back all occurs in the > > same activity for example), so it is not a good example of what the > > -standard- behavior is. > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
