[android-developers] Re: Threads in Android (NetworkOnMainThreadException with Javamail) acting very strange
I solved this using AsyncTask, thanks both for replying
On Nov 13, 2:20 pm, Stelios wrote:
> I am a beginner in Android platform and i have encountering a serious
> problem. I want to fetch emails from gmail and therefore i have
> created a class that does that. However when i run my class in android
> NetworkOnMainThreadException. So i have created new Thread with a new
> Runnable as below :
>
> public void onClick(View v) {
> new Thread(new Runnable() {
> public void run() {
> FetchEmails e = new FetchEmails();
> }
> }).start();
>
> }
>
> It worked fine but then i can't seem to have access to e.getMessage in
> order to get the actual email. Having this on mind i have implement
> Runnable to my FetchEMails class and done all the fetch code in run()
> which i have overidden. The last piece of code in run() is setting a
> variable to 'true'. Then in my Activity class i have instantiate the
> class and i have done this : new Thread(e).start();. Below i have a
> while loop to check wether the class has finished to the end of run()
> method (by checking if the variable is true). So now i have created my
> new theard which does not intefere with the UI and when the code is
> finished i want to get the message. But it seems that i still get the
> NetworkOnMainThreadException error. Any help with that is apprecieted.
> Thanks.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads in Android (NetworkOnMainThreadException with Javamail) acting very strange
I was exactly aware of the AsyncTask but in the end i solve it doing
it that way. Thanks
On Nov 14, 5:08 am, GMLチェックツール wrote:
> Why not to use AsyncTask class.
> For me, it is the best approach for your case.
>
>
>
> (2011/11/14 9:56), BCS wrote:
> > move FetchEmails e outside of the curly braces and declare in the
> > scope where you need to use it
>
> > On Nov 13, 8:20 am, Stelios wrote:
> >> I am a beginner in Android platform and i have encountering a serious
> >> problem. I want to fetch emails from gmail and therefore i have
> >> created a class that does that. However when i run my class in android
> >> NetworkOnMainThreadException. So i have created new Thread with a new
> >> Runnable as below :
>
> >> public void onClick(View v) {
> >>new Thread(new Runnable() {
> >> public void run() {
> >>FetchEmails e = new FetchEmails();
> >> }
> >>}).start();
>
> >> }
>
> >> It worked fine but then i can't seem to have access to e.getMessage in
> >> order to get the actual email. Having this on mind i have implement
> >> Runnable to my FetchEMails class and done all the fetch code in run()
> >> which i have overidden. The last piece of code in run() is setting a
> >> variable to 'true'. Then in my Activity class i have instantiate the
> >> class and i have done this : new Thread(e).start();. Below i have a
> >> while loop to check wether the class has finished to the end of run()
> >> method (by checking if the variable is true). So now i have created my
> >> new theard which does not intefere with the UI and when the code is
> >> finished i want to get the message. But it seems that i still get the
> >> NetworkOnMainThreadException error. Any help with that is apprecieted.
> >> Thanks.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Threads in Android (NetworkOnMainThreadException with Javamail) acting very strange
Why not to use AsyncTask class.
For me, it is the best approach for your case.
(2011/11/14 9:56), BCS wrote:
move FetchEmails e outside of the curly braces and declare in the
scope where you need to use it
On Nov 13, 8:20 am, Stelios wrote:
I am a beginner in Android platform and i have encountering a serious
problem. I want to fetch emails from gmail and therefore i have
created a class that does that. However when i run my class in android
NetworkOnMainThreadException. So i have created new Thread with a new
Runnable as below :
public void onClick(View v) {
new Thread(new Runnable() {
public void run() {
FetchEmails e = new FetchEmails();
}
}).start();
}
It worked fine but then i can't seem to have access to e.getMessage in
order to get the actual email. Having this on mind i have implement
Runnable to my FetchEMails class and done all the fetch code in run()
which i have overidden. The last piece of code in run() is setting a
variable to 'true'. Then in my Activity class i have instantiate the
class and i have done this : new Thread(e).start();. Below i have a
while loop to check wether the class has finished to the end of run()
method (by checking if the variable is true). So now i have created my
new theard which does not intefere with the UI and when the code is
finished i want to get the message. But it seems that i still get the
NetworkOnMainThreadException error. Any help with that is apprecieted.
Thanks.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads in Android (NetworkOnMainThreadException with Javamail) acting very strange
move FetchEmails e outside of the curly braces and declare in the
scope where you need to use it
On Nov 13, 8:20 am, Stelios wrote:
> I am a beginner in Android platform and i have encountering a serious
> problem. I want to fetch emails from gmail and therefore i have
> created a class that does that. However when i run my class in android
> NetworkOnMainThreadException. So i have created new Thread with a new
> Runnable as below :
>
> public void onClick(View v) {
> new Thread(new Runnable() {
> public void run() {
> FetchEmails e = new FetchEmails();
> }
> }).start();
>
> }
>
> It worked fine but then i can't seem to have access to e.getMessage in
> order to get the actual email. Having this on mind i have implement
> Runnable to my FetchEMails class and done all the fetch code in run()
> which i have overidden. The last piece of code in run() is setting a
> variable to 'true'. Then in my Activity class i have instantiate the
> class and i have done this : new Thread(e).start();. Below i have a
> while loop to check wether the class has finished to the end of run()
> method (by checking if the variable is true). So now i have created my
> new theard which does not intefere with the UI and when the code is
> finished i want to get the message. But it seems that i still get the
> NetworkOnMainThreadException error. Any help with that is apprecieted.
> Thanks.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads
Steven, There is absolutely no restriction against starting new threads from other new threads. If you are willing to share some code, I might be able to say something more useful... -blake Programming Android, FTW! http://oreilly.com/catalog/0636920010364 On Sep 2, 5:28 am, Steven Bruce wrote: > I have thee threads in my bluetooth program. Both my AcceptThread and > ConnectThread create a newConnectThread from within their Thread class > but my program seems to crash at this point. Are you not allowed to > start a new thread from within a thread class? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Threads
Doesn't make sense to me in the context of Bluetooth. If you can, attach a debugger to one of the devices (when I used to debug Bluetooth programs, I used to connect to 3+ devices :-) and step through your code until you hit a problematic point. You're not doing anything nasty in those threads right? Like updating the UI or something. Kris On Fri, Sep 2, 2011 at 8:47 AM, Steven Bruce wrote: > I think I recall seeing 'KeyChar' generation errors or something in > the debug window > > On Sep 2, 1:43 pm, Kristopher Micinski wrote: >> On top of this I'd say you might read about threading in java in >> general. And yes, it is certainly possible to create new threads in a >> thread :-). There are plenty of reasons your program could crash: a >> security violation, perhaps? >> >> What's your motivation for multiple threads in your program? >> Synchronous IO? You can do a lot of possible combinations to get the >> IO effect you want, try posing a log dump of where your code crashed, >> and your code itself. >> >> Kris >> >> >> >> >> >> >> >> On Fri, Sep 2, 2011 at 8:40 AM, Appaholics wrote: >> > I am not sure but if you have both of them start the same thread in a >> > single >> > run wouldn't you be starting the same thread twice? This may raise an >> > exception. >> > Thanks >> >> > On Fri, Sep 2, 2011 at 6:07 PM, Steven Bruce >> > wrote: >> >> >> I mean they both start a new thread called 'ConectedThread'. Is this >> >> ok or should I not be doing this? >> >> >> On Sep 2, 1:28 pm, Steven Bruce wrote: >> >> > I have thee threads in my bluetooth program. Both my AcceptThread and >> >> > ConnectThread create a newConnectThread from within their Thread class >> >> > but my program seems to crash at this point. Are you not allowed to >> >> > start a new thread from within a thread class? >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups "Android Developers" group. >> >> To post to this group, send email to android-developers@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> android-developers+unsubscr...@googlegroups.com >> >> For more options, visit this group at >> >>http://groups.google.com/group/android-developers?hl=en >> >> > -- >> > -- >> > Raghav Sood >> > CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles >> > required to have complete control) >> >http://www.raghavsood.com/ >> >https://market.android.com/developer?pub=Appaholics >> >http://www.appaholics.in/ >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Android Developers" group. >> > To post to this group, send email to android-developers@googlegroups.com >> > To unsubscribe from this group, send email to >> > android-developers+unsubscr...@googlegroups.com >> > For more options, visit this group at >> >http://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads
I think I recall seeing 'KeyChar' generation errors or something in the debug window On Sep 2, 1:43 pm, Kristopher Micinski wrote: > On top of this I'd say you might read about threading in java in > general. And yes, it is certainly possible to create new threads in a > thread :-). There are plenty of reasons your program could crash: a > security violation, perhaps? > > What's your motivation for multiple threads in your program? > Synchronous IO? You can do a lot of possible combinations to get the > IO effect you want, try posing a log dump of where your code crashed, > and your code itself. > > Kris > > > > > > > > On Fri, Sep 2, 2011 at 8:40 AM, Appaholics wrote: > > I am not sure but if you have both of them start the same thread in a single > > run wouldn't you be starting the same thread twice? This may raise an > > exception. > > Thanks > > > On Fri, Sep 2, 2011 at 6:07 PM, Steven Bruce wrote: > > >> I mean they both start a new thread called 'ConectedThread'. Is this > >> ok or should I not be doing this? > > >> On Sep 2, 1:28 pm, Steven Bruce wrote: > >> > I have thee threads in my bluetooth program. Both my AcceptThread and > >> > ConnectThread create a newConnectThread from within their Thread class > >> > but my program seems to crash at this point. Are you not allowed to > >> > start a new thread from within a thread class? > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Android Developers" group. > >> To post to this group, send email to android-developers@googlegroups.com > >> To unsubscribe from this group, send email to > >> android-developers+unsubscr...@googlegroups.com > >> For more options, visit this group at > >>http://groups.google.com/group/android-developers?hl=en > > > -- > > -- > > Raghav Sood > > CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles > > required to have complete control) > >http://www.raghavsood.com/ > >https://market.android.com/developer?pub=Appaholics > >http://www.appaholics.in/ > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads
No they are designed to be run on two different devices. one device runs one thread and the other one runs the other thread but they both need to run a connected thread. On Sep 2, 1:40 pm, Appaholics wrote: > I am not sure but if you have both of them start the same thread in a single > run wouldn't you be starting the same thread twice? This may raise an > exception. > > Thanks > > > > > > > > > > On Fri, Sep 2, 2011 at 6:07 PM, Steven Bruce wrote: > > I mean they both start a new thread called 'ConectedThread'. Is this > > ok or should I not be doing this? > > > On Sep 2, 1:28 pm, Steven Bruce wrote: > > > I have thee threads in my bluetooth program. Both my AcceptThread and > > > ConnectThread create a newConnectThread from within their Thread class > > > but my program seems to crash at this point. Are you not allowed to > > > start a new thread from within a thread class? > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > -- > Raghav Sood > CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles > required to have complete > control)http://www.raghavsood.com/https://market.android.com/developer?pub=Appaholicshttp://www.appaholics.in/ -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Threads
On top of this I'd say you might read about threading in java in general. And yes, it is certainly possible to create new threads in a thread :-). There are plenty of reasons your program could crash: a security violation, perhaps? What's your motivation for multiple threads in your program? Synchronous IO? You can do a lot of possible combinations to get the IO effect you want, try posing a log dump of where your code crashed, and your code itself. Kris On Fri, Sep 2, 2011 at 8:40 AM, Appaholics wrote: > I am not sure but if you have both of them start the same thread in a single > run wouldn't you be starting the same thread twice? This may raise an > exception. > Thanks > > On Fri, Sep 2, 2011 at 6:07 PM, Steven Bruce wrote: >> >> I mean they both start a new thread called 'ConectedThread'. Is this >> ok or should I not be doing this? >> >> On Sep 2, 1:28 pm, Steven Bruce wrote: >> > I have thee threads in my bluetooth program. Both my AcceptThread and >> > ConnectThread create a newConnectThread from within their Thread class >> > but my program seems to crash at this point. Are you not allowed to >> > start a new thread from within a thread class? >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to android-developers@googlegroups.com >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en > > > -- > -- > Raghav Sood > CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles > required to have complete control) > http://www.raghavsood.com/ > https://market.android.com/developer?pub=Appaholics > http://www.appaholics.in/ > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Threads
I am not sure but if you have both of them start the same thread in a single run wouldn't you be starting the same thread twice? This may raise an exception. Thanks On Fri, Sep 2, 2011 at 6:07 PM, Steven Bruce wrote: > I mean they both start a new thread called 'ConectedThread'. Is this > ok or should I not be doing this? > > On Sep 2, 1:28 pm, Steven Bruce wrote: > > I have thee threads in my bluetooth program. Both my AcceptThread and > > ConnectThread create a newConnectThread from within their Thread class > > but my program seems to crash at this point. Are you not allowed to > > start a new thread from within a thread class? > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- -- Raghav Sood CEO/Founder/Owner/Dictator/Tyrant at Appaholics (Basically all titles required to have complete control) http://www.raghavsood.com/ https://market.android.com/developer?pub=Appaholics http://www.appaholics.in/ -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Threads
I mean they both start a new thread called 'ConectedThread'. Is this ok or should I not be doing this? On Sep 2, 1:28 pm, Steven Bruce wrote: > I have thee threads in my bluetooth program. Both my AcceptThread and > ConnectThread create a newConnectThread from within their Thread class > but my program seems to crash at this point. Are you not allowed to > start a new thread from within a thread class? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Threads or ASyncTask?
> On Apr 14, 3:20 am, MobDev wrote: >> I am just making a wild guess here, and I hope more experience people >> will support or deny it (Mark, are you awake yet ? ;) ) but this >> might be a good scenario for a Service ? Nope, I'm not awake. Streets Of Boston wrote: > Depends. > > But since the OP mentioned Notifications, i guess the search results > should be presented even when the user left the application. If so, > yes, then a Service would be best. > > Still, i would use an AsyncTask (inside the Service) to do the actual > work. This way you'll be sure that the client's call to the Service > will never be blocking. Agreed. A service is a container for logic; a service needs asynchronous operations as much as an activity does. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Development Wiki: http://wiki.andmob.org -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Threads or ASyncTask?
Depends. But since the OP mentioned Notifications, i guess the search results should be presented even when the user left the application. If so, yes, then a Service would be best. Still, i would use an AsyncTask (inside the Service) to do the actual work. This way you'll be sure that the client's call to the Service will never be blocking. On Apr 14, 3:20 am, MobDev wrote: > I am just making a wild guess here, and I hope more experience people > will support or deny it (Mark, are you awake yet ? ;) ) but this might > be a good scenario for a Service ? > > On 6 apr, 16:21, jfbaro wrote: > > > > > Hi, > > > I am working on a simple application (studying purposes) which list > > all the files from a selected folder. On top of that I would like to > > have a search feature where the user can search for files (the code > > for that is already in place). > > > Now, I was thinking about having the search running in the background > > somehow, whilst the user can still navigate, create folders, copy, > > sort and do other stuffs normally. When the search finishes the user > > would get a notification and then could click on it and go to that > > activity (It ideally should be the same ListView I already use for > > browsing the files, I would just need to update the Adapter there with > > the latest processed data after clicking in the notification). > > > What's the best answer for that? Threading or AsyncTask? > > > Could anyone help me? > > > Cheers- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Threads or ASyncTask?
I am just making a wild guess here, and I hope more experience people will support or deny it (Mark, are you awake yet ? ;) ) but this might be a good scenario for a Service ? On 6 apr, 16:21, jfbaro wrote: > Hi, > > I am working on a simple application (studying purposes) which list > all the files from a selected folder. On top of that I would like to > have a search feature where the user can search for files (the code > for that is already in place). > > Now, I was thinking about having the search running in the background > somehow, whilst the user can still navigate, create folders, copy, > sort and do other stuffs normally. When the search finishes the user > would get a notification and then could click on it and go to that > activity (It ideally should be the same ListView I already use for > browsing the files, I would just need to update the Adapter there with > the latest processed data after clicking in the notification). > > What's the best answer for that? Threading or AsyncTask? > > Could anyone help me? > > Cheers -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
[android-developers] Re: Threads and Screen Orientation Change
oops. forgot to override handleMessage ( ) in the pseudo code above. Let us
assume, that in the handleMessage ( ), we decide which processxyz to call,
depending on the message received !
sorry..
On Wed, Sep 9, 2009 at 3:01 PM, Android Development wrote:
> Hello,
> From the conversation above, i understand that having a static reference to
> the activity can be used by background threads (that we may spawn), to send
> callbacks to the activity (which can then render stuff on the UI).
>
> However, It would be helpful, if someone can also provide an example of
> using Handlers.
>
> For my understanding so far, I am posting some pseudo code below. Please
> feel free to correct me/enhance the code, so that i may understand this
> concept better.
>
> I can create a static handler reference in my activity class like this:
>
> private static MyHandler handler = new MyHandler();
>
> My handler class may have the following structure (assuming that MyHandler
> is an inner class of my Activity class):
>
> public class MyHandler extends Handler
> {
>public void processCallConnectedEvent ( Message m)
> {
>// do stuff here..show a dialog that displays "Call Connected" on
> the Activity's UI
> //sleep here for sometime, say 2 seconds..
> // dismiss the dialog.
> }
>
>public void processCallDisconectedEvent (Message m)
> {
>// Do the needful here, pop a dialog that displays "Call
> Disconnected"
> }
>
>public void processCallTimedOutEvent (Message m)
> {
>// Do the needful here, pop a dialog that displays "Call Attempt
> timed out"
> }
>
> }
>
> On Tue, Sep 1, 2009 at 10:27 PM, Streets Of Boston <
> flyingdutc...@gmail.com> wrote:
>
>>
>> You're welcome :-)
>>
>> And you can make your show/dismissDialogSmart 'static'. Then you never
>> need a reference to an Activity at all. Just call
>> OrientationAwareActivity.showDialogSmart(id)
>>
>>
>> On Aug 31, 5:44 pm, CraigsRace wrote:
>> > > I deal with these situations by just keeping a public static reference
>> > > around to the currently active activity. E.g.
>> >
>> > Brilliant idea!!! That's the solution!
>> >
>> > And you could abstract it out into a sub class like this (I wish
>> > showDialog/dismissDialog weren't marked as final!):
>> >
>> > public class OrientationAwareActivity extends Activity {
>> > private static OrientationAwareActivity ACTIVE_INSTANCE;
>> >
>> > @Override
>> > protected void onCreate(Bundle savedInstanceState) {
>> > super.onCreate(savedInstanceState);
>> >
>> > ACTIVE_INSTANCE = this;
>> > }
>> >
>> > @Override
>> > protected void onDestroy() {
>> > super.onDestroy();
>> >
>> > ACTIVE_INSTANCE = null;
>> > }
>> >
>> > public void showDialogSmart(int id) {
>> > if (ACTIVE_INSTANCE != null) {
>> > ACTIVE_INSTANCE.showDialog(id);
>> > }
>> > }
>> >
>> > public void dismissDialogSmart(int id) {
>> > if (ACTIVE_INSTANCE != null) {
>> > ACTIVE_INSTANCE.dismissDialog(id);
>> > }
>> > }
>> >
>> >
>> >
>> > }- Hide quoted text -
>> >
>> > - Show quoted text -
>> >>
>>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Hello,
>From the conversation above, i understand that having a static reference to
the activity can be used by background threads (that we may spawn), to send
callbacks to the activity (which can then render stuff on the UI).
However, It would be helpful, if someone can also provide an example of
using Handlers.
For my understanding so far, I am posting some pseudo code below. Please
feel free to correct me/enhance the code, so that i may understand this
concept better.
I can create a static handler reference in my activity class like this:
private static MyHandler handler = new MyHandler();
My handler class may have the following structure (assuming that MyHandler
is an inner class of my Activity class):
public class MyHandler extends Handler
{
public void processCallConnectedEvent ( Message m)
{
// do stuff here..show a dialog that displays "Call Connected" on the
Activity's UI
//sleep here for sometime, say 2 seconds..
// dismiss the dialog.
}
public void processCallDisconectedEvent (Message m)
{
// Do the needful here, pop a dialog that displays "Call
Disconnected"
}
public void processCallTimedOutEvent (Message m)
{
// Do the needful here, pop a dialog that displays "Call Attempt
timed out"
}
}
On Tue, Sep 1, 2009 at 10:27 PM, Streets Of Boston
wrote:
>
> You're welcome :-)
>
> And you can make your show/dismissDialogSmart 'static'. Then you never
> need a reference to an Activity at all. Just call
> OrientationAwareActivity.showDialogSmart(id)
>
>
> On Aug 31, 5:44 pm, CraigsRace wrote:
> > > I deal with these situations by just keeping a public static reference
> > > around to the currently active activity. E.g.
> >
> > Brilliant idea!!! That's the solution!
> >
> > And you could abstract it out into a sub class like this (I wish
> > showDialog/dismissDialog weren't marked as final!):
> >
> > public class OrientationAwareActivity extends Activity {
> > private static OrientationAwareActivity ACTIVE_INSTANCE;
> >
> > @Override
> > protected void onCreate(Bundle savedInstanceState) {
> > super.onCreate(savedInstanceState);
> >
> > ACTIVE_INSTANCE = this;
> > }
> >
> > @Override
> > protected void onDestroy() {
> > super.onDestroy();
> >
> > ACTIVE_INSTANCE = null;
> > }
> >
> > public void showDialogSmart(int id) {
> > if (ACTIVE_INSTANCE != null) {
> > ACTIVE_INSTANCE.showDialog(id);
> > }
> > }
> >
> > public void dismissDialogSmart(int id) {
> > if (ACTIVE_INSTANCE != null) {
> > ACTIVE_INSTANCE.dismissDialog(id);
> > }
> > }
> >
> >
> >
> > }- Hide quoted text -
> >
> > - Show quoted text -
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
You're welcome :-)
And you can make your show/dismissDialogSmart 'static'. Then you never
need a reference to an Activity at all. Just call
OrientationAwareActivity.showDialogSmart(id)
On Aug 31, 5:44 pm, CraigsRace wrote:
> > I deal with these situations by just keeping a public static reference
> > around to the currently active activity. E.g.
>
> Brilliant idea!!! That's the solution!
>
> And you could abstract it out into a sub class like this (I wish
> showDialog/dismissDialog weren't marked as final!):
>
> public class OrientationAwareActivity extends Activity {
> private static OrientationAwareActivity ACTIVE_INSTANCE;
>
> @Override
> protected void onCreate(Bundle savedInstanceState) {
> super.onCreate(savedInstanceState);
>
> ACTIVE_INSTANCE = this;
> }
>
> @Override
> protected void onDestroy() {
> super.onDestroy();
>
> ACTIVE_INSTANCE = null;
> }
>
> public void showDialogSmart(int id) {
> if (ACTIVE_INSTANCE != null) {
> ACTIVE_INSTANCE.showDialog(id);
> }
> }
>
> public void dismissDialogSmart(int id) {
> if (ACTIVE_INSTANCE != null) {
> ACTIVE_INSTANCE.dismissDialog(id);
> }
> }
>
>
>
> }- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
> I deal with these situations by just keeping a public static reference
> around to the currently active activity. E.g.
Brilliant idea!!! That's the solution!
And you could abstract it out into a sub class like this (I wish
showDialog/dismissDialog weren't marked as final!):
public class OrientationAwareActivity extends Activity {
private static OrientationAwareActivity ACTIVE_INSTANCE;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ACTIVE_INSTANCE = this;
}
@Override
protected void onDestroy() {
super.onDestroy();
ACTIVE_INSTANCE = null;
}
public void showDialogSmart(int id) {
if (ACTIVE_INSTANCE != null) {
ACTIVE_INSTANCE.showDialog(id);
}
}
public void dismissDialogSmart(int id) {
if (ACTIVE_INSTANCE != null) {
ACTIVE_INSTANCE.dismissDialog(id);
}
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
junker37 wrote: > Can you explain how to stop the android framework from destroying and > re-creating the activity on a layout change? http://wiki.andmob.org/samplecode has links to: http://www.androidguys.com/2008/11/11/rotational-forces-part-three/ http://www.androidguys.com/2008/11/24/rotational-forces-part-four/ which cover this topic. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Development Wiki: http://wiki.andmob.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Can you explain how to stop the android framework from destroying and re-creating the activity on a layout change? On Aug 31, 11:24 am, Marco Nelissen wrote: > On Mon, Aug 31, 2009 at 6:06 AM, ReubenH wrote: > > > Having used Android for 4 months, and now having a game doing well in > > the market, I am still wondering why a rotation change results in > > Activity creation / destruction in the first place? It has never made > > sense... why not an onLayoutChanged() type of event instead? > > You can have this too, if that's what you want. You can specify in > your manifest which configuration changes your activity can handle > itself, and you will see your Activity.onConfigurationChanged() called > when such a configuration change happens. > Note however that in that case your activity is responsible for > handling the configuration change, e.g. loading a new layout and > resources if needed, updating all the references your app has to > buttons, lists and other widgets, etc. > > > > > It seems wasteful and counterintuitive to create new activities when > > the activity hasn't actually changed... > > > I'd love to know the reason for it, am sure I am probably missing > > something obvious. > > > Thanks, > > > -- Reuben > > > On Aug 31, 2:39 am, CraigsRace wrote: > >> Dianne: Yes, using a static Handler is a solution. Although, IMO, > >> it's not the most eloquent solution. But it will work, so I should be > >> happy. :) > > >> On Aug 31, 11:19 am, Dianne Hackborn wrote: > > >> > And you shouldn't be doing this. You could have a static pointing to the > >> > currently running activity instance (which very well may be null, which > >> > is a > >> > valid state, and something your thread needs to deal with anyway). Often > >> > you do this by giving the thread just a Handler to communicate back with > >> > the > >> > main thread, which the activity implements as a static along with a > >> > static > >> > of the current activity instance. So your thread posts a message to > >> > display > >> > a dialog, and then on the main thread you get that message and handle it > >> > on > >> > whichever activity instance is the current one. > > >> > On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: > > >> > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > >> > > decided to just go ahead and write a solution myself (see previous > >> > > post). > > >> > > As for starting multiple threads, yes, they will hold on to the old > >> > > Activities. However, that's what happens right now, no? In fact, > >> > > that's the whole problem, when the threads try to do UI, they are > >> > > referring to the old activities. > > >> > > On Aug 31, 8:26 am, Mark Murphy wrote: > >> > > > CraigsRace wrote: > >> > > > > I'm obviously missing something, as I thought the Thread would be > >> > > > > the > >> > > > > only thing holding onto the old Activity (as it is now). When the > >> > > > > Thread dies, the old activity would be garbage collected (as it > >> > > > > does > >> > > > > now). All forwarding would be done via the Activity class. > > >> > > > Correct, but what Ms. Hackborn wrote was: > > >> > > > >> And that still means it needs to keep the old activity around so > >> > > > >> the > >> > > > thread > >> > > > >> can use it. > > >> > > > So, given that, imagine this scenario: > > >> > > > -- Activity instance A starts > >> > > > -- You fork a background thread, holding onto A, that will run for 30 > >> > > > seconds, as a result of a button click > >> > > > -- At 0:02 into the thread, the user rotates the screen > >> > > > -- Android creates a new activity instance (B), and has A point to B > >> > > > for > >> > > > the purposes of your call forwarding stuff > >> > > > -- At 0:05 into the first thread, you fork another thread, holding > >> > > > onto > >> > > > B, that will run for 30 seconds, as a result of a button click > >> > > > -- At 0:07 into the thread, the user rotates the screen again (bear > >> > > > in > >> > > > mind that for non-QWERTY devices, it doesn't take much to cause the > >> > > > screen to rotate) > >> > > > -- Android creates a new activity instance (C), and has B point to C > >> > > > for > >> > > > the purposes of your call forwarding stuff > > >> > > > At this point, we have three total instances of the activity running > >> > > > (A, > >> > > > B, C), and we still have 23 seconds of the original 30 to work with. > >> > > > Factor in the possibility of developers having threads that run for > >> > > > 30 > >> > > > days instead of 30 seconds. > > >> > > > In your specific example, coded properly, the forwarding mechanism > >> > > > may > >> > > > work fine, if your thread is very short lived (a couple of seconds), > >> > > > won't get started again, and your activities are not terribly > >> > > > complex. > >> > > > It's when you start to violate those assumptions (coded improperly, > >> > > > lotsa threads, long threads, complex activities) that me
[android-developers] Re: Threads and Screen Orientation Change
On Mon, Aug 31, 2009 at 6:06 AM, ReubenH wrote: > > Having used Android for 4 months, and now having a game doing well in > the market, I am still wondering why a rotation change results in > Activity creation / destruction in the first place? It has never made > sense... why not an onLayoutChanged() type of event instead? You can have this too, if that's what you want. You can specify in your manifest which configuration changes your activity can handle itself, and you will see your Activity.onConfigurationChanged() called when such a configuration change happens. Note however that in that case your activity is responsible for handling the configuration change, e.g. loading a new layout and resources if needed, updating all the references your app has to buttons, lists and other widgets, etc. > It seems wasteful and counterintuitive to create new activities when > the activity hasn't actually changed... > > I'd love to know the reason for it, am sure I am probably missing > something obvious. > > Thanks, > > > -- Reuben > > On Aug 31, 2:39 am, CraigsRace wrote: >> Dianne: Yes, using a static Handler is a solution. Although, IMO, >> it's not the most eloquent solution. But it will work, so I should be >> happy. :) >> >> On Aug 31, 11:19 am, Dianne Hackborn wrote: >> >> >> >> > And you shouldn't be doing this. You could have a static pointing to the >> > currently running activity instance (which very well may be null, which is >> > a >> > valid state, and something your thread needs to deal with anyway). Often >> > you do this by giving the thread just a Handler to communicate back with >> > the >> > main thread, which the activity implements as a static along with a static >> > of the current activity instance. So your thread posts a message to >> > display >> > a dialog, and then on the main thread you get that message and handle it on >> > whichever activity instance is the current one. >> >> > On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: >> >> > > Mark: Sorry, I deleted my original post (very rude, I know!), as I >> > > decided to just go ahead and write a solution myself (see previous >> > > post). >> >> > > As for starting multiple threads, yes, they will hold on to the old >> > > Activities. However, that's what happens right now, no? In fact, >> > > that's the whole problem, when the threads try to do UI, they are >> > > referring to the old activities. >> >> > > On Aug 31, 8:26 am, Mark Murphy wrote: >> > > > CraigsRace wrote: >> > > > > I'm obviously missing something, as I thought the Thread would be the >> > > > > only thing holding onto the old Activity (as it is now). When the >> > > > > Thread dies, the old activity would be garbage collected (as it does >> > > > > now). All forwarding would be done via the Activity class. >> >> > > > Correct, but what Ms. Hackborn wrote was: >> >> > > > >> And that still means it needs to keep the old activity around so the >> > > > thread >> > > > >> can use it. >> >> > > > So, given that, imagine this scenario: >> >> > > > -- Activity instance A starts >> > > > -- You fork a background thread, holding onto A, that will run for 30 >> > > > seconds, as a result of a button click >> > > > -- At 0:02 into the thread, the user rotates the screen >> > > > -- Android creates a new activity instance (B), and has A point to B >> > > > for >> > > > the purposes of your call forwarding stuff >> > > > -- At 0:05 into the first thread, you fork another thread, holding onto >> > > > B, that will run for 30 seconds, as a result of a button click >> > > > -- At 0:07 into the thread, the user rotates the screen again (bear in >> > > > mind that for non-QWERTY devices, it doesn't take much to cause the >> > > > screen to rotate) >> > > > -- Android creates a new activity instance (C), and has B point to C >> > > > for >> > > > the purposes of your call forwarding stuff >> >> > > > At this point, we have three total instances of the activity running >> > > > (A, >> > > > B, C), and we still have 23 seconds of the original 30 to work with. >> > > > Factor in the possibility of developers having threads that run for 30 >> > > > days instead of 30 seconds. >> >> > > > In your specific example, coded properly, the forwarding mechanism may >> > > > work fine, if your thread is very short lived (a couple of seconds), >> > > > won't get started again, and your activities are not terribly complex. >> > > > It's when you start to violate those assumptions (coded improperly, >> > > > lotsa threads, long threads, complex activities) that memory issues >> > > > become more painful. >> >> > > > -- >> > > > Mark Murphy (a Commons Guy)http://commonsware.com| >> > >http://twitter.com/commonsguy >> >> > > > Warescription: Three Android Books, Plus Updates, $35/Year >> >> > -- >> > Dianne Hackborn >> > Android framework engineer >> > hack...@android.com >> >> > Note: please don't send private questions to me, as I don't have time to >> > provide private support,
[android-developers] Re: Threads and Screen Orientation Change
I deal with these situations by just keeping a public static reference
around to the currently active activity. E.g.
public MyActivity extends Activity {
public static MyActivity ACTIVE_INSTANCE = null;
protected void onCreate() {
ACTIVE_INSTANCE = this;
...
}
protected void onDestroy {
...
ACTIVE_INSTANCE = null; // clean up. important to do this.
}
...
}
And within my background threads, i just use the
MyActivity.ACTIVE_INSTANCE to access any part of MyActivity's gui
elements (getting a handler to post back a message to its gui-thread
and then during the handling of that message, i use
MyActivity.ACTIVE_INSTANCE again to update the GUI, e.g. dismissing
waiting dialogs, updating progess dialogs).
And I check for MyActivity.ACTIVE_INSTANCE being null... just in
case :-)
This assumes that there is at most one instance of an activity around
at any given time.
On Aug 30, 9:23 pm, CraigsRace wrote:
> Romain: Agreed, my solution is bad.
>
> I still feel like there should be a solution. I would think a lot of
> developers would want to do UI from a thread (closing a progress
> dialog, etc). And making them track if the activity has been
> destroyed and recreated seems like something that the framework should
> be able to handle (or at least have some sort of helper class for).
>
> Also, the "Example ProgressDialog with a second thread"
> inhttp://developer.android.com/guide/topics/ui/dialogs.html#ProgressDialog
> is bad example, as it starts a new thread on every screen rotate, so,
> devs (like me) will move the creation of the thread into the button
> click, and then fall into the issue discussed here where they need to
> track Activity creation/deletion (which there is no example for).
>
> On Aug 31, 10:36 am, Romain Guy wrote:
>
>
>
> > No, this is not a good solution. There is no guarantee on how long the
> > thread will run, which means there is no guarantee on how long the
> > Activity (and everything tied to it) will survive.
>
> > On Sun, Aug 30, 2009 at 4:00 PM, CraigsRace wrote:
>
> > > The thread is holding onto the old activity, nothing else references
> > > it. When the thread dies, so does the old activity.
>
> > > I went ahead and wrote a solution myself by extending the Activity
> > > class.
>
> > > What I wanted to do was:
> > > 1. onSaveInstanceState put a reference to itself (the activity) in the
> > > Bundle.
> > > 2. onCreate retrieve the reference to the activity in the bundle (if
> > > it exists), then call the activity telling it about itself. Ie: It
> > > tell the old activity about itself (the new activity).
> > > 3. Make showDialog and dismissDialog call out to the new activity (if
> > > it exists).
>
> > > There were 2 problems with this:
> > > 1. showDialog and dismissDialog are marked as final
> > > 2. Bundle doesn't allow Objects to be added to it.
>
> > > I worked around this by:
> > > 1. Creating showDialog2 and dismissDialog2 methods.
> > > 2. Not using the Bundle, rather a static variable (this is not a good
> > > solution, as it is assumes there will only be 1 activity).
>
> > > These workarounds mean that it is not a proper solution for all devs
> > > to use.
>
> > > However, the Android framework could easily be enhanced to do this.
>
> > > Cheers.
>
> > > PS: I was going to attach my code as reference, however, I can't see
> > > anywhere that I can do this.
>
> > > On Aug 31, 1:44 am, Dianne Hackborn wrote:
> > >> And that still means it needs to keep the old activity around so the
> > >> thread
> > >> can use it.
>
> > >> On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote:
>
> > >> > It would only be a forward reference (from the destroyed activity to
> > >> > the new activity), not a back reference.
>
> > >> > On Aug 30, 2:34 pm, Romain Guy wrote:
> > >> > > > However, couldn't the Android framework just forward any requests
> > >> > > > from
> > >> > > > a destroyed activity, to the newly created Activity, saving us
> > >> > > > developers the pain of handling it ourselves?
>
> > >> > > To do this, the framework would have to keep around references to all
> > >> > > previous Activities pretty much forever. Which would be a large waste
> > >> > > of resources.
>
> > >> > > --
> > >> > > Romain Guy
> > >> > > Android framework engineer
> > >> > > romain...@android.com
>
> > >> > > Note: please don't send private questions to me, as I don't have time
> > >> > > to provide private support. All such questions should be posted on
> > >> > > public forums, where I and others can see and answer them
>
> > >> --
> > >> Dianne Hackborn
> > >> Android framework engineer
> > >> hack...@android.com
>
> > >> 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.
>
> > --
> > Romain Guy
> > Android framework engineer
> > romain...@and
[android-developers] Re: Threads and Screen Orientation Change
> > Having used Android for 4 months, and now having a game doing well in > the market, I am still wondering why a rotation change results in > Activity creation / destruction in the first place? It has never made > sense... why not an onLayoutChanged() type of event instead? > > It seems wasteful and counterintuitive to create new activities when > the activity hasn't actually changed... > > I'd love to know the reason for it, am sure I am probably missing > something obvious. For applications using the widget framework (most non-games), Android will map in fresh resources, as these may differ based upon screen orientation. So, for example, you get fresh XML layout files, if you have different ones for landscape versus portrait. There are ways to tell Android to not destroy and recreate the activity, if that is not what you want. -- Mark Murphy (a Commons Guy) http://commonsware.com Android App Developer Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Having used Android for 4 months, and now having a game doing well in the market, I am still wondering why a rotation change results in Activity creation / destruction in the first place? It has never made sense... why not an onLayoutChanged() type of event instead? It seems wasteful and counterintuitive to create new activities when the activity hasn't actually changed... I'd love to know the reason for it, am sure I am probably missing something obvious. Thanks, -- Reuben On Aug 31, 2:39 am, CraigsRace wrote: > Dianne: Yes, using a static Handler is a solution. Although, IMO, > it's not the most eloquent solution. But it will work, so I should be > happy. :) > > On Aug 31, 11:19 am, Dianne Hackborn wrote: > > > > > And you shouldn't be doing this. You could have a static pointing to the > > currently running activity instance (which very well may be null, which is a > > valid state, and something your thread needs to deal with anyway). Often > > you do this by giving the thread just a Handler to communicate back with the > > main thread, which the activity implements as a static along with a static > > of the current activity instance. So your thread posts a message to display > > a dialog, and then on the main thread you get that message and handle it on > > whichever activity instance is the current one. > > > On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: > > > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > > > decided to just go ahead and write a solution myself (see previous > > > post). > > > > As for starting multiple threads, yes, they will hold on to the old > > > Activities. However, that's what happens right now, no? In fact, > > > that's the whole problem, when the threads try to do UI, they are > > > referring to the old activities. > > > > On Aug 31, 8:26 am, Mark Murphy wrote: > > > > CraigsRace wrote: > > > > > I'm obviously missing something, as I thought the Thread would be the > > > > > only thing holding onto the old Activity (as it is now). When the > > > > > Thread dies, the old activity would be garbage collected (as it does > > > > > now). All forwarding would be done via the Activity class. > > > > > Correct, but what Ms. Hackborn wrote was: > > > > > >> And that still means it needs to keep the old activity around so the > > > > thread > > > > >> can use it. > > > > > So, given that, imagine this scenario: > > > > > -- Activity instance A starts > > > > -- You fork a background thread, holding onto A, that will run for 30 > > > > seconds, as a result of a button click > > > > -- At 0:02 into the thread, the user rotates the screen > > > > -- Android creates a new activity instance (B), and has A point to B for > > > > the purposes of your call forwarding stuff > > > > -- At 0:05 into the first thread, you fork another thread, holding onto > > > > B, that will run for 30 seconds, as a result of a button click > > > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > > > mind that for non-QWERTY devices, it doesn't take much to cause the > > > > screen to rotate) > > > > -- Android creates a new activity instance (C), and has B point to C for > > > > the purposes of your call forwarding stuff > > > > > At this point, we have three total instances of the activity running (A, > > > > B, C), and we still have 23 seconds of the original 30 to work with. > > > > Factor in the possibility of developers having threads that run for 30 > > > > days instead of 30 seconds. > > > > > In your specific example, coded properly, the forwarding mechanism may > > > > work fine, if your thread is very short lived (a couple of seconds), > > > > won't get started again, and your activities are not terribly complex. > > > > It's when you start to violate those assumptions (coded improperly, > > > > lotsa threads, long threads, complex activities) that memory issues > > > > become more painful. > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > > >http://twitter.com/commonsguy > > > > > Warescription: Three Android Books, Plus Updates, $35/Year > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Dianne: Yes, using a static Handler is a solution. Although, IMO, it's not the most eloquent solution. But it will work, so I should be happy. :) On Aug 31, 11:19 am, Dianne Hackborn wrote: > And you shouldn't be doing this. You could have a static pointing to the > currently running activity instance (which very well may be null, which is a > valid state, and something your thread needs to deal with anyway). Often > you do this by giving the thread just a Handler to communicate back with the > main thread, which the activity implements as a static along with a static > of the current activity instance. So your thread posts a message to display > a dialog, and then on the main thread you get that message and handle it on > whichever activity instance is the current one. > > > > On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: > > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > > decided to just go ahead and write a solution myself (see previous > > post). > > > As for starting multiple threads, yes, they will hold on to the old > > Activities. However, that's what happens right now, no? In fact, > > that's the whole problem, when the threads try to do UI, they are > > referring to the old activities. > > > On Aug 31, 8:26 am, Mark Murphy wrote: > > > CraigsRace wrote: > > > > I'm obviously missing something, as I thought the Thread would be the > > > > only thing holding onto the old Activity (as it is now). When the > > > > Thread dies, the old activity would be garbage collected (as it does > > > > now). All forwarding would be done via the Activity class. > > > > Correct, but what Ms. Hackborn wrote was: > > > > >> And that still means it needs to keep the old activity around so the > > > thread > > > >> can use it. > > > > So, given that, imagine this scenario: > > > > -- Activity instance A starts > > > -- You fork a background thread, holding onto A, that will run for 30 > > > seconds, as a result of a button click > > > -- At 0:02 into the thread, the user rotates the screen > > > -- Android creates a new activity instance (B), and has A point to B for > > > the purposes of your call forwarding stuff > > > -- At 0:05 into the first thread, you fork another thread, holding onto > > > B, that will run for 30 seconds, as a result of a button click > > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > > mind that for non-QWERTY devices, it doesn't take much to cause the > > > screen to rotate) > > > -- Android creates a new activity instance (C), and has B point to C for > > > the purposes of your call forwarding stuff > > > > At this point, we have three total instances of the activity running (A, > > > B, C), and we still have 23 seconds of the original 30 to work with. > > > Factor in the possibility of developers having threads that run for 30 > > > days instead of 30 seconds. > > > > In your specific example, coded properly, the forwarding mechanism may > > > work fine, if your thread is very short lived (a couple of seconds), > > > won't get started again, and your activities are not terribly complex. > > > It's when you start to violate those assumptions (coded improperly, > > > lotsa threads, long threads, complex activities) that memory issues > > > become more painful. > > > > -- > > > Mark Murphy (a Commons Guy)http://commonsware.com| > >http://twitter.com/commonsguy > > > > Warescription: Three Android Books, Plus Updates, $35/Year > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Why not just tell your thread about the new activity? Having the old activity keep a reference to the new activity for the sole purpose of being able to pretend that the old activity is still valid, even after its onDestroy has already been called, goes completely against the Android activity model. Also note that your old activity might simply go away, instead of being replaced by a new activity. What does your thread do in that case? On Sun, Aug 30, 2009 at 4:00 PM, CraigsRace wrote: > > The thread is holding onto the old activity, nothing else references > it. When the thread dies, so does the old activity. > > I went ahead and wrote a solution myself by extending the Activity > class. > > What I wanted to do was: > 1. onSaveInstanceState put a reference to itself (the activity) in the > Bundle. > 2. onCreate retrieve the reference to the activity in the bundle (if > it exists), then call the activity telling it about itself. Ie: It > tell the old activity about itself (the new activity). > 3. Make showDialog and dismissDialog call out to the new activity (if > it exists). > > There were 2 problems with this: > 1. showDialog and dismissDialog are marked as final > 2. Bundle doesn't allow Objects to be added to it. > > I worked around this by: > 1. Creating showDialog2 and dismissDialog2 methods. > 2. Not using the Bundle, rather a static variable (this is not a good > solution, as it is assumes there will only be 1 activity). > > These workarounds mean that it is not a proper solution for all devs > to use. > > However, the Android framework could easily be enhanced to do this. > > Cheers. > > PS: I was going to attach my code as reference, however, I can't see > anywhere that I can do this. > > > On Aug 31, 1:44 am, Dianne Hackborn wrote: >> And that still means it needs to keep the old activity around so the thread >> can use it. >> >> >> >> On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: >> >> > It would only be a forward reference (from the destroyed activity to >> > the new activity), not a back reference. >> >> > On Aug 30, 2:34 pm, Romain Guy wrote: >> > > > However, couldn't the Android framework just forward any requests from >> > > > a destroyed activity, to the newly created Activity, saving us >> > > > developers the pain of handling it ourselves? >> >> > > To do this, the framework would have to keep around references to all >> > > previous Activities pretty much forever. Which would be a large waste >> > > of resources. >> >> > > -- >> > > Romain Guy >> > > Android framework engineer >> > > romain...@android.com >> >> > > Note: please don't send private questions to me, as I don't have time >> > > to provide private support. All such questions should be posted on >> > > public forums, where I and others can see and answer them >> >> -- >> Dianne Hackborn >> Android framework engineer >> hack...@android.com >> >> 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
And you shouldn't be doing this. You could have a static pointing to the currently running activity instance (which very well may be null, which is a valid state, and something your thread needs to deal with anyway). Often you do this by giving the thread just a Handler to communicate back with the main thread, which the activity implements as a static along with a static of the current activity instance. So your thread posts a message to display a dialog, and then on the main thread you get that message and handle it on whichever activity instance is the current one. On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > decided to just go ahead and write a solution myself (see previous > post). > > As for starting multiple threads, yes, they will hold on to the old > Activities. However, that's what happens right now, no? In fact, > that's the whole problem, when the threads try to do UI, they are > referring to the old activities. > > > On Aug 31, 8:26 am, Mark Murphy wrote: > > CraigsRace wrote: > > > I'm obviously missing something, as I thought the Thread would be the > > > only thing holding onto the old Activity (as it is now). When the > > > Thread dies, the old activity would be garbage collected (as it does > > > now). All forwarding would be done via the Activity class. > > > > Correct, but what Ms. Hackborn wrote was: > > > > > > > > >> And that still means it needs to keep the old activity around so the > > thread > > >> can use it. > > > > So, given that, imagine this scenario: > > > > -- Activity instance A starts > > -- You fork a background thread, holding onto A, that will run for 30 > > seconds, as a result of a button click > > -- At 0:02 into the thread, the user rotates the screen > > -- Android creates a new activity instance (B), and has A point to B for > > the purposes of your call forwarding stuff > > -- At 0:05 into the first thread, you fork another thread, holding onto > > B, that will run for 30 seconds, as a result of a button click > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > mind that for non-QWERTY devices, it doesn't take much to cause the > > screen to rotate) > > -- Android creates a new activity instance (C), and has B point to C for > > the purposes of your call forwarding stuff > > > > At this point, we have three total instances of the activity running (A, > > B, C), and we still have 23 seconds of the original 30 to work with. > > Factor in the possibility of developers having threads that run for 30 > > days instead of 30 seconds. > > > > In your specific example, coded properly, the forwarding mechanism may > > work fine, if your thread is very short lived (a couple of seconds), > > won't get started again, and your activities are not terribly complex. > > It's when you start to violate those assumptions (coded improperly, > > lotsa threads, long threads, complex activities) that memory issues > > become more painful. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://twitter.com/commonsguy > > > > Warescription: Three Android Books, Plus Updates, $35/Year > > > -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Dianne: Yes, using a static Handler is a solution. Although, IMO, it's not the more eloquent solution. On Aug 31, 11:19 am, Dianne Hackborn wrote: > And you shouldn't be doing this. You could have a static pointing to the > currently running activity instance (which very well may be null, which is a > valid state, and something your thread needs to deal with anyway). Often > you do this by giving the thread just a Handler to communicate back with the > main thread, which the activity implements as a static along with a static > of the current activity instance. So your thread posts a message to display > a dialog, and then on the main thread you get that message and handle it on > whichever activity instance is the current one. > > > > On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace wrote: > > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > > decided to just go ahead and write a solution myself (see previous > > post). > > > As for starting multiple threads, yes, they will hold on to the old > > Activities. However, that's what happens right now, no? In fact, > > that's the whole problem, when the threads try to do UI, they are > > referring to the old activities. > > > On Aug 31, 8:26 am, Mark Murphy wrote: > > > CraigsRace wrote: > > > > I'm obviously missing something, as I thought the Thread would be the > > > > only thing holding onto the old Activity (as it is now). When the > > > > Thread dies, the old activity would be garbage collected (as it does > > > > now). All forwarding would be done via the Activity class. > > > > Correct, but what Ms. Hackborn wrote was: > > > > >> And that still means it needs to keep the old activity around so the > > > thread > > > >> can use it. > > > > So, given that, imagine this scenario: > > > > -- Activity instance A starts > > > -- You fork a background thread, holding onto A, that will run for 30 > > > seconds, as a result of a button click > > > -- At 0:02 into the thread, the user rotates the screen > > > -- Android creates a new activity instance (B), and has A point to B for > > > the purposes of your call forwarding stuff > > > -- At 0:05 into the first thread, you fork another thread, holding onto > > > B, that will run for 30 seconds, as a result of a button click > > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > > mind that for non-QWERTY devices, it doesn't take much to cause the > > > screen to rotate) > > > -- Android creates a new activity instance (C), and has B point to C for > > > the purposes of your call forwarding stuff > > > > At this point, we have three total instances of the activity running (A, > > > B, C), and we still have 23 seconds of the original 30 to work with. > > > Factor in the possibility of developers having threads that run for 30 > > > days instead of 30 seconds. > > > > In your specific example, coded properly, the forwarding mechanism may > > > work fine, if your thread is very short lived (a couple of seconds), > > > won't get started again, and your activities are not terribly complex. > > > It's when you start to violate those assumptions (coded improperly, > > > lotsa threads, long threads, complex activities) that memory issues > > > become more painful. > > > > -- > > > Mark Murphy (a Commons Guy)http://commonsware.com| > >http://twitter.com/commonsguy > > > > Warescription: Three Android Books, Plus Updates, $35/Year > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
CraigsRace wrote: > The thread is holding onto the old activity, nothing else references > it. When the thread dies, so does the old activity. And if the thread does not die? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Romain: Agreed, my solution is bad. I still feel like there should be a solution. I would think a lot of developers would want to do UI from a thread (closing a progress dialog, etc). And making them track if the activity has been destroyed and recreated seems like something that the framework should be able to handle (or at least have some sort of helper class for). Also, the "Example ProgressDialog with a second thread" in http://developer.android.com/guide/topics/ui/dialogs.html#ProgressDialog is bad example, as it starts a new thread on every screen rotate, so, devs (like me) will move the creation of the thread into the button click, and then fall into the issue discussed here where they need to track Activity creation/deletion (which there is no example for). On Aug 31, 10:36 am, Romain Guy wrote: > No, this is not a good solution. There is no guarantee on how long the > thread will run, which means there is no guarantee on how long the > Activity (and everything tied to it) will survive. > > > > On Sun, Aug 30, 2009 at 4:00 PM, CraigsRace wrote: > > > The thread is holding onto the old activity, nothing else references > > it. When the thread dies, so does the old activity. > > > I went ahead and wrote a solution myself by extending the Activity > > class. > > > What I wanted to do was: > > 1. onSaveInstanceState put a reference to itself (the activity) in the > > Bundle. > > 2. onCreate retrieve the reference to the activity in the bundle (if > > it exists), then call the activity telling it about itself. Ie: It > > tell the old activity about itself (the new activity). > > 3. Make showDialog and dismissDialog call out to the new activity (if > > it exists). > > > There were 2 problems with this: > > 1. showDialog and dismissDialog are marked as final > > 2. Bundle doesn't allow Objects to be added to it. > > > I worked around this by: > > 1. Creating showDialog2 and dismissDialog2 methods. > > 2. Not using the Bundle, rather a static variable (this is not a good > > solution, as it is assumes there will only be 1 activity). > > > These workarounds mean that it is not a proper solution for all devs > > to use. > > > However, the Android framework could easily be enhanced to do this. > > > Cheers. > > > PS: I was going to attach my code as reference, however, I can't see > > anywhere that I can do this. > > > On Aug 31, 1:44 am, Dianne Hackborn wrote: > >> And that still means it needs to keep the old activity around so the thread > >> can use it. > > >> On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: > > >> > It would only be a forward reference (from the destroyed activity to > >> > the new activity), not a back reference. > > >> > On Aug 30, 2:34 pm, Romain Guy wrote: > >> > > > However, couldn't the Android framework just forward any requests > >> > > > from > >> > > > a destroyed activity, to the newly created Activity, saving us > >> > > > developers the pain of handling it ourselves? > > >> > > To do this, the framework would have to keep around references to all > >> > > previous Activities pretty much forever. Which would be a large waste > >> > > of resources. > > >> > > -- > >> > > Romain Guy > >> > > Android framework engineer > >> > > romain...@android.com > > >> > > Note: please don't send private questions to me, as I don't have time > >> > > to provide private support. All such questions should be posted on > >> > > public forums, where I and others can see and answer them > > >> -- > >> Dianne Hackborn > >> Android framework engineer > >> hack...@android.com > > >> 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. > > -- > Romain Guy > Android framework engineer > romain...@android.com > > Note: please don't send private questions to me, as I don't have time > to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Mark,Dianna: Sorry, light bulb just went on. I think this is what you're saying: - Currently, the Thread will hold onto just 1 old Activity. - With my solution, the Thread will hold onto 1 old Activity, then that Activity will then holds onto the next old activity, and the next, ... So if a thread starts, then the user decided to flip the screen 20 times, then that's 20 activities all held. Yes, that would be a bit of a problem. On Aug 31, 9:10 am, CraigsRace wrote: > Mark: Sorry, I deleted my original post (very rude, I know!), as I > decided to just go ahead and write a solution myself (see previous > post). > > As for starting multiple threads, yes, they will hold on to the old > Activities. However, that's what happens right now, no? In fact, > that's the whole problem, when the threads try to do UI, they are > referring to the old activities. > > On Aug 31, 8:26 am, Mark Murphy wrote: > > > CraigsRace wrote: > > > I'm obviously missing something, as I thought the Thread would be the > > > only thing holding onto the old Activity (as it is now). When the > > > Thread dies, the old activity would be garbage collected (as it does > > > now). All forwarding would be done via the Activity class. > > > Correct, but what Ms. Hackborn wrote was: > > > >> And that still means it needs to keep the old activity around so the > > thread > > >> can use it. > > > So, given that, imagine this scenario: > > > -- Activity instance A starts > > -- You fork a background thread, holding onto A, that will run for 30 > > seconds, as a result of a button click > > -- At 0:02 into the thread, the user rotates the screen > > -- Android creates a new activity instance (B), and has A point to B for > > the purposes of your call forwarding stuff > > -- At 0:05 into the first thread, you fork another thread, holding onto > > B, that will run for 30 seconds, as a result of a button click > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > mind that for non-QWERTY devices, it doesn't take much to cause the > > screen to rotate) > > -- Android creates a new activity instance (C), and has B point to C for > > the purposes of your call forwarding stuff > > > At this point, we have three total instances of the activity running (A, > > B, C), and we still have 23 seconds of the original 30 to work with. > > Factor in the possibility of developers having threads that run for 30 > > days instead of 30 seconds. > > > In your specific example, coded properly, the forwarding mechanism may > > work fine, if your thread is very short lived (a couple of seconds), > > won't get started again, and your activities are not terribly complex. > > It's when you start to violate those assumptions (coded improperly, > > lotsa threads, long threads, complex activities) that memory issues > > become more painful. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://twitter.com/commonsguy > > > Warescription: Three Android Books, Plus Updates, $35/Year > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
Mark: Sorry, I deleted my original post (very rude, I know!), as I decided to just go ahead and write a solution myself (see previous post). As for starting multiple threads, yes, they will hold on to the old Activities. However, that's what happens right now, no? In fact, that's the whole problem, when the threads try to do UI, they are referring to the old activities. On Aug 31, 8:26 am, Mark Murphy wrote: > CraigsRace wrote: > > I'm obviously missing something, as I thought the Thread would be the > > only thing holding onto the old Activity (as it is now). When the > > Thread dies, the old activity would be garbage collected (as it does > > now). All forwarding would be done via the Activity class. > > Correct, but what Ms. Hackborn wrote was: > > > > >> And that still means it needs to keep the old activity around so the > thread > >> can use it. > > So, given that, imagine this scenario: > > -- Activity instance A starts > -- You fork a background thread, holding onto A, that will run for 30 > seconds, as a result of a button click > -- At 0:02 into the thread, the user rotates the screen > -- Android creates a new activity instance (B), and has A point to B for > the purposes of your call forwarding stuff > -- At 0:05 into the first thread, you fork another thread, holding onto > B, that will run for 30 seconds, as a result of a button click > -- At 0:07 into the thread, the user rotates the screen again (bear in > mind that for non-QWERTY devices, it doesn't take much to cause the > screen to rotate) > -- Android creates a new activity instance (C), and has B point to C for > the purposes of your call forwarding stuff > > At this point, we have three total instances of the activity running (A, > B, C), and we still have 23 seconds of the original 30 to work with. > Factor in the possibility of developers having threads that run for 30 > days instead of 30 seconds. > > In your specific example, coded properly, the forwarding mechanism may > work fine, if your thread is very short lived (a couple of seconds), > won't get started again, and your activities are not terribly complex. > It's when you start to violate those assumptions (coded improperly, > lotsa threads, long threads, complex activities) that memory issues > become more painful. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Warescription: Three Android Books, Plus Updates, $35/Year --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
No, this is not a good solution. There is no guarantee on how long the thread will run, which means there is no guarantee on how long the Activity (and everything tied to it) will survive. On Sun, Aug 30, 2009 at 4:00 PM, CraigsRace wrote: > > The thread is holding onto the old activity, nothing else references > it. When the thread dies, so does the old activity. > > I went ahead and wrote a solution myself by extending the Activity > class. > > What I wanted to do was: > 1. onSaveInstanceState put a reference to itself (the activity) in the > Bundle. > 2. onCreate retrieve the reference to the activity in the bundle (if > it exists), then call the activity telling it about itself. Ie: It > tell the old activity about itself (the new activity). > 3. Make showDialog and dismissDialog call out to the new activity (if > it exists). > > There were 2 problems with this: > 1. showDialog and dismissDialog are marked as final > 2. Bundle doesn't allow Objects to be added to it. > > I worked around this by: > 1. Creating showDialog2 and dismissDialog2 methods. > 2. Not using the Bundle, rather a static variable (this is not a good > solution, as it is assumes there will only be 1 activity). > > These workarounds mean that it is not a proper solution for all devs > to use. > > However, the Android framework could easily be enhanced to do this. > > Cheers. > > PS: I was going to attach my code as reference, however, I can't see > anywhere that I can do this. > > > On Aug 31, 1:44 am, Dianne Hackborn wrote: >> And that still means it needs to keep the old activity around so the thread >> can use it. >> >> >> >> On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: >> >> > It would only be a forward reference (from the destroyed activity to >> > the new activity), not a back reference. >> >> > On Aug 30, 2:34 pm, Romain Guy wrote: >> > > > However, couldn't the Android framework just forward any requests from >> > > > a destroyed activity, to the newly created Activity, saving us >> > > > developers the pain of handling it ourselves? >> >> > > To do this, the framework would have to keep around references to all >> > > previous Activities pretty much forever. Which would be a large waste >> > > of resources. >> >> > > -- >> > > Romain Guy >> > > Android framework engineer >> > > romain...@android.com >> >> > > Note: please don't send private questions to me, as I don't have time >> > > to provide private support. All such questions should be posted on >> > > public forums, where I and others can see and answer them >> >> -- >> Dianne Hackborn >> Android framework engineer >> hack...@android.com >> >> 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. > > > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
The thread is holding onto the old activity, nothing else references it. When the thread dies, so does the old activity. I went ahead and wrote a solution myself by extending the Activity class. What I wanted to do was: 1. onSaveInstanceState put a reference to itself (the activity) in the Bundle. 2. onCreate retrieve the reference to the activity in the bundle (if it exists), then call the activity telling it about itself. Ie: It tell the old activity about itself (the new activity). 3. Make showDialog and dismissDialog call out to the new activity (if it exists). There were 2 problems with this: 1. showDialog and dismissDialog are marked as final 2. Bundle doesn't allow Objects to be added to it. I worked around this by: 1. Creating showDialog2 and dismissDialog2 methods. 2. Not using the Bundle, rather a static variable (this is not a good solution, as it is assumes there will only be 1 activity). These workarounds mean that it is not a proper solution for all devs to use. However, the Android framework could easily be enhanced to do this. Cheers. PS: I was going to attach my code as reference, however, I can't see anywhere that I can do this. On Aug 31, 1:44 am, Dianne Hackborn wrote: > And that still means it needs to keep the old activity around so the thread > can use it. > > > > On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: > > > It would only be a forward reference (from the destroyed activity to > > the new activity), not a back reference. > > > On Aug 30, 2:34 pm, Romain Guy wrote: > > > > However, couldn't the Android framework just forward any requests from > > > > a destroyed activity, to the newly created Activity, saving us > > > > developers the pain of handling it ourselves? > > > > To do this, the framework would have to keep around references to all > > > previous Activities pretty much forever. Which would be a large waste > > > of resources. > > > > -- > > > Romain Guy > > > Android framework engineer > > > romain...@android.com > > > > Note: please don't send private questions to me, as I don't have time > > > to provide private support. All such questions should be posted on > > > public forums, where I and others can see and answer them > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
CraigsRace wrote: > I'm obviously missing something, as I thought the Thread would be the > only thing holding onto the old Activity (as it is now). When the > Thread dies, the old activity would be garbage collected (as it does > now). All forwarding would be done via the Activity class. Correct, but what Ms. Hackborn wrote was: >> And that still means it needs to keep the old activity around so the thread >> can use it. So, given that, imagine this scenario: -- Activity instance A starts -- You fork a background thread, holding onto A, that will run for 30 seconds, as a result of a button click -- At 0:02 into the thread, the user rotates the screen -- Android creates a new activity instance (B), and has A point to B for the purposes of your call forwarding stuff -- At 0:05 into the first thread, you fork another thread, holding onto B, that will run for 30 seconds, as a result of a button click -- At 0:07 into the thread, the user rotates the screen again (bear in mind that for non-QWERTY devices, it doesn't take much to cause the screen to rotate) -- Android creates a new activity instance (C), and has B point to C for the purposes of your call forwarding stuff At this point, we have three total instances of the activity running (A, B, C), and we still have 23 seconds of the original 30 to work with. Factor in the possibility of developers having threads that run for 30 days instead of 30 seconds. In your specific example, coded properly, the forwarding mechanism may work fine, if your thread is very short lived (a couple of seconds), won't get started again, and your activities are not terribly complex. It's when you start to violate those assumptions (coded improperly, lotsa threads, long threads, complex activities) that memory issues become more painful. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, $35/Year --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
I'm obviously missing something, as I thought the Thread would be the only thing holding onto the old Activity (as it is now). When the Thread dies, the old activity would be garbage collected (as it does now). All forwarding would be done via the Activity class. I tried to extend Activity to write it myself, however, methods like showDialog and dismissDialog are marked as final, and I couldn't pass the old Activity into the Bundle on the onSaveInstanceState as Bundle doesn't allow attaching of objects. On Aug 31, 1:44 am, Dianne Hackborn wrote: > And that still means it needs to keep the old activity around so the thread > can use it. > > > > On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: > > > It would only be a forward reference (from the destroyed activity to > > the new activity), not a back reference. > > > On Aug 30, 2:34 pm, Romain Guy wrote: > > > > However, couldn't the Android framework just forward any requests from > > > > a destroyed activity, to the newly created Activity, saving us > > > > developers the pain of handling it ourselves? > > > > To do this, the framework would have to keep around references to all > > > previous Activities pretty much forever. Which would be a large waste > > > of resources. > > > > -- > > > Romain Guy > > > Android framework engineer > > > romain...@android.com > > > > Note: please don't send private questions to me, as I don't have time > > > to provide private support. All such questions should be posted on > > > public forums, where I and others can see and answer them > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
And that still means it needs to keep the old activity around so the thread can use it. On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace wrote: > > It would only be a forward reference (from the destroyed activity to > the new activity), not a back reference. > > On Aug 30, 2:34 pm, Romain Guy wrote: > > > However, couldn't the Android framework just forward any requests from > > > a destroyed activity, to the newly created Activity, saving us > > > developers the pain of handling it ourselves? > > > > To do this, the framework would have to keep around references to all > > previous Activities pretty much forever. Which would be a large waste > > of resources. > > > > -- > > Romain Guy > > Android framework engineer > > romain...@android.com > > > > Note: please don't send private questions to me, as I don't have time > > to provide private support. All such questions should be posted on > > public forums, where I and others can see and answer them > > > -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
It would only be a forward reference (from the destroyed activity to the new activity), not a back reference. On Aug 30, 2:34 pm, Romain Guy wrote: > > However, couldn't the Android framework just forward any requests from > > a destroyed activity, to the newly created Activity, saving us > > developers the pain of handling it ourselves? > > To do this, the framework would have to keep around references to all > previous Activities pretty much forever. Which would be a large waste > of resources. > > -- > Romain Guy > Android framework engineer > romain...@android.com > > Note: please don't send private questions to me, as I don't have time > to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads and Screen Orientation Change
> However, couldn't the Android framework just forward any requests from > a destroyed activity, to the newly created Activity, saving us > developers the pain of handling it ourselves? To do this, the framework would have to keep around references to all previous Activities pretty much forever. Which would be a large waste of resources. -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads for networking and DatagramSocket
Um... it looks like the people there already answered your question: only the receive() call is synchronized, so you can freely send data while your reader thread is blocked waiting for new data to arrive. I don't understand at all why you are suggesting doing networking on the main thread, since that will just make your problem worse, as now you somehow need to keep the reading from blocking so you can make the UI responsive. There is nothing magical about the main thread that lets it do networking in a way that can't be done in another thread. On Thu, Jul 30, 2009 at 6:46 AM, Lex wrote: > > Thank You for your advice, Roman. There's a detailed post about my > issue on the Java Sun Forum: > http://forums.sun.com/thread.jspa?messageID=10779608� > > Lex > > On Jul 29, 5:06 pm, Roman wrote: > > I recommend to keep your data communication separate from the UI. The > > UI should be responsive as possible and you don't want to have any > > blocking on this level. In general data connectivity is not > > predictable and in worse case you are waiting for a response from the > > network and blocking your whole UI. For example how would you > > interrupt your data communication from UI perspective when you handle > > data communication within the UI and your UI is blocked? > > > > -- > > Roman Baumgaertner > > Sr. SW Engineer-OSDC > > ·T· · ·Mobile· stick together > > The views, opinions and statements in this email are those of the > > author solely in their individual capacity, and do not necessarily > > represent those of T-Mobile USA, Inc. > > > > On Jul 29, 3:42 am,Lex wrote: > > > > > My Android app is exchanging traffic messages viaUDPwith a server - > > > binary messages of up to 60 Bytes. The server I'm using (external, > > > don't have access to code nor can I convince the developer to change > > > stuff :( ) is identifying the clients solely through sockets (no other > > > type of client ID whatsoever), so I need to use the same socket for > > > receiving and sending. My initial plan was to use separate Threads for > > > receiving and sending data. The network load depends on the traffic > > > situation - sometimes there might be a lot of messages coming in, > > > sometimes only a few. The client also needs to send periodic keep- > > > alive messages, which are simple, 10 character strings. Now the > > > problem is that Java's DatagramSocket.receive method() is synchronized > > > and also blocking as long as there is data to receive, so my sending > > > thread cannot use the socket for sending anything, which results in > > > the server kicking off the client because there's no response coming. > > > > > My question is, how bad (or not bad) do you think will rejecting the > > > threads and doing all the networking as described above in the UI > > > thread be? Of course, if you also have suggestions on how to overcome > > > the issue, it will be greatly appreciated! > > > > > Cordialement > > > > >Lex > > > -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads for networking and DatagramSocket
Thank You for your advice, Roman. There's a detailed post about my issue on the Java Sun Forum: http://forums.sun.com/thread.jspa?messageID=10779608� Lex On Jul 29, 5:06 pm, Roman wrote: > I recommend to keep your data communication separate from the UI. The > UI should be responsive as possible and you don't want to have any > blocking on this level. In general data connectivity is not > predictable and in worse case you are waiting for a response from the > network and blocking your whole UI. For example how would you > interrupt your data communication from UI perspective when you handle > data communication within the UI and your UI is blocked? > > -- > Roman Baumgaertner > Sr. SW Engineer-OSDC > ·T· · ·Mobile· stick together > The views, opinions and statements in this email are those of the > author solely in their individual capacity, and do not necessarily > represent those of T-Mobile USA, Inc. > > On Jul 29, 3:42 am,Lex wrote: > > > My Android app is exchanging traffic messages viaUDPwith a server - > > binary messages of up to 60 Bytes. The server I'm using (external, > > don't have access to code nor can I convince the developer to change > > stuff :( ) is identifying the clients solely through sockets (no other > > type of client ID whatsoever), so I need to use the same socket for > > receiving and sending. My initial plan was to use separate Threads for > > receiving and sending data. The network load depends on the traffic > > situation - sometimes there might be a lot of messages coming in, > > sometimes only a few. The client also needs to send periodic keep- > > alive messages, which are simple, 10 character strings. Now the > > problem is that Java's DatagramSocket.receive method() is synchronized > > and also blocking as long as there is data to receive, so my sending > > thread cannot use the socket for sending anything, which results in > > the server kicking off the client because there's no response coming. > > > My question is, how bad (or not bad) do you think will rejecting the > > threads and doing all the networking as described above in the UI > > thread be? Of course, if you also have suggestions on how to overcome > > the issue, it will be greatly appreciated! > > > Cordialement > > >Lex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads for networking and DatagramSocket
I recommend to keep your data communication separate from the UI. The UI should be responsive as possible and you don't want to have any blocking on this level. In general data connectivity is not predictable and in worse case you are waiting for a response from the network and blocking your whole UI. For example how would you interrupt your data communication from UI perspective when you handle data communication within the UI and your UI is blocked? -- Roman Baumgaertner Sr. SW Engineer-OSDC ·T· · ·Mobile· stick together The views, opinions and statements in this email are those of the author solely in their individual capacity, and do not necessarily represent those of T-Mobile USA, Inc. On Jul 29, 3:42 am, Lex wrote: > My Android app is exchanging traffic messages via UDP with a server - > binary messages of up to 60 Bytes. The server I'm using (external, > don't have access to code nor can I convince the developer to change > stuff :( ) is identifying the clients solely through sockets (no other > type of client ID whatsoever), so I need to use the same socket for > receiving and sending. My initial plan was to use separate Threads for > receiving and sending data. The network load depends on the traffic > situation - sometimes there might be a lot of messages coming in, > sometimes only a few. The client also needs to send periodic keep- > alive messages, which are simple, 10 character strings. Now the > problem is that Java's DatagramSocket.receive method() is synchronized > and also blocking as long as there is data to receive, so my sending > thread cannot use the socket for sending anything, which results in > the server kicking off the client because there's no response coming. > > My question is, how bad (or not bad) do you think will rejecting the > threads and doing all the networking as described above in the UI > thread be? Of course, if you also have suggestions on how to overcome > the issue, it will be greatly appreciated! > > Cordialement > > Lex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
oops sorry I forgot to post code so it can help people...
this updates and then notifies a list adapter which has an observer.
/**
* Background task to verify the create user action. When the
action comes back
* it could inform the client to sync all data if the username and
passwird match
* or that there was a validation error like the user already
exists, or that
* this is a new user and that it successfuly created it
*
*/
private class PostActionTask extends UserTask {
public ActionResult doInBackground(Object... params) {
ActionResult result =
new ActionResult();
result.setActionStatus("FAILED");
Action actionToRun = (Action)params[0];
try {
result =
RpcActionClient.executeAction(
actionToRun,
MomentaryNowApp.getString("app_momentary_now_server"),
MomentaryNowApp.getInteger("app_momentary_now_server_port"),
MomentaryNowApp.getString("app_momentary_action_endpoint"),
null) ;
} catch (IOException e) {
Log.e(TAG, "IOException:"+e.getMessage());
} catch (HttpException e) {
Log.e(TAG, "HttpException:"+e.getMessage());
} catch (URISyntaxException e) {
Log.e(TAG, "URISyntaxException:"+e.getMessage());
}
return result;
}
@Override
public void onPostExecute(ActionResult result) {
Log.d(TAG, "result:"+result.getActionStatus());
if(result.getActionStatus().equals("SUCCESS"))
{
SharedPreferences sharedPreferences =
PreferenceManager.getDefaultSharedPreferences(
getApplicationContext());
SharedPreferences.Editor editor =
sharedPreferences.edit();
editor.putBoolean("isValidPrincipal", true);
editor.putInt("contactVisibility", 0);
editor.putFloat("visibilityRadius", 0.0f);
editor.commit();
UserInfoListItem item =
mListManager.get(LIST_ITEM_SYNC);
item.setStatus("complete");
item.setProgressVisible(false);
mListManager.refresh();
} else if(result.getActionStatus().equals("VALIDATION ERROR")) {
Log.d(TAG, result.getActionStatus());
UserInfoListItem item =
mListManager.get(LIST_ITEM_SYNC);
item.setStatus("error");
item.setProgressVisible(false);
mListManager.refresh();
} else if(result.getActionStatus().equals("SYNC")) {
Log.d(TAG, result.getActionStatus());
finish();
}
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
>or activity, you can use runOnUiThread(Runnable). ooh thats easy too. UpdateTask won out. It was sick easy to wire up and use and now I can do all this backgrounded threaded stuff that can update the UI. I am kindof surprised that the Handler message dispatch doesn't just behave the same way. If it did it would be so easy to just use handlers and bundles for this stuff. But thanks to all you guys (and gals hackbod, etc.) for what you do, you are enabling an entire new industry, its hard to put a value on that I know but I can tell you that it would be very difficult to figure this stuff out without you. My recommendation is to continue to write killer apps that illustrate these things and reference them like you did for this example. Respectfully, Clay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
Or if you do need to use a thread and it is an inner class of the view or activity, you can use runOnUiThread(Runnable). On Nov 26, 11:04 pm, Clay <[EMAIL PROTECTED]> wrote: > wow. > > UpdateTask is killer. I will probably use hackbod's simpler approach, > but I am seriously thinking of jacking that in somehow. sweet. > > nice photos. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
wow. UpdateTask is killer. I will probably use hackbod's simpler approach, but I am seriously thinking of jacking that in somehow. sweet. nice photos. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
Also, if you just want to dismiss the window after a timeout, you
don't need to use a thread at all, just create a Handler in the
current (main thread) and post a delayed message or runnable to it.
See the use of sendMessageDelayed() here for an example:
http://code.google.com/android/samples/ApiDemos/src/com/example/android/apis/app/RemoteService.html
On Oct 6, 8:33 am, "Romain Guy" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> You can use threads but all the views, and all the views related APIs,
> must be invoked from the main thread (also called UI thread.) To do
> this from a background thread, you need to use a Handler. A Handler is
> an object that will post messages back to the UI thread for you. You
> can also use the various post() method from the View class as they
> will use a Handler automatically. In your case, you could do something
> like this:
>
> private Handler mHandler;
>
> protected void onCreate(Bundle saved) {
> mHandler = new Handler();
>
> }
>
> // In your Thread
> public void run() {
> // ...
> mHandler.post(new Runnable() {
> public void run() { popup.dismiss(); }
> });
>
> }
>
> You can also look at the class called UserTask from the
> apps-for-android
> project:http://code.google.com/p/apps-for-android/source/browse/trunk/Photost...
>
> It makes threading/UI interactions even easier.
>
>
>
> On Mon, Oct 6, 2008 at 8:25 AM, Falko Richter <[EMAIL PROTECTED]> wrote:
> > Hello everyone,
>
> > I first have a general question if threaded programming is possible with the
> > Android Platform?
>
> > Secondly I have a specific problem. I have an application that gives the
> > user feedback with a "PopupWindow". By standart the Popup disappears then
> > the user clicks somewhere on the screen. I want to make the popup
> > automatically after X millisecond, so I programmed myself a little thread:
>
> > package com.fon;
> > import android.util.Log;
>
> > public class PopupThread extends Thread {
> > fonPopupWindow popup;
> > long millis;
>
> > public PopupThread(fonPopupWindow popup) {
> > this.popup = popup;
> > }
>
> > public void run() {
> > try {
> > sleep(millis);
> > popup.dismiss();
> > }
> > catch(InterruptedException e) {
> > }
> > }
> > }
>
> > but everytime the thread tries to dismiss my popup, I get the following
> > exception:
>
> > android.view.ViewRoot$CalledFromWrongThreadException: Only the original
> > thread that created a view hierarchy can touch its views.
>
> > From what I understand, this tells me that I cannot access something outside
> > the new created Thread, and therefore my plan is immpossible to solve on
> > Android.
>
> > Thx for suggestions
>
> > Falko
>
> --
> Romain Guywww.curious-creature.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
[android-developers] Re: Threads in Android
Hi,
You can use threads but all the views, and all the views related APIs,
must be invoked from the main thread (also called UI thread.) To do
this from a background thread, you need to use a Handler. A Handler is
an object that will post messages back to the UI thread for you. You
can also use the various post() method from the View class as they
will use a Handler automatically. In your case, you could do something
like this:
private Handler mHandler;
protected void onCreate(Bundle saved) {
mHandler = new Handler();
}
// In your Thread
public void run() {
// ...
mHandler.post(new Runnable() {
public void run() { popup.dismiss(); }
});
}
You can also look at the class called UserTask from the
apps-for-android project:
http://code.google.com/p/apps-for-android/source/browse/trunk/Photostream/src/com/google/android/photostream/UserTask.java
It makes threading/UI interactions even easier.
On Mon, Oct 6, 2008 at 8:25 AM, Falko Richter <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I first have a general question if threaded programming is possible with the
> Android Platform?
>
> Secondly I have a specific problem. I have an application that gives the
> user feedback with a "PopupWindow". By standart the Popup disappears then
> the user clicks somewhere on the screen. I want to make the popup
> automatically after X millisecond, so I programmed myself a little thread:
>
> package com.fon;
> import android.util.Log;
>
> public class PopupThread extends Thread {
> fonPopupWindow popup;
> long millis;
>
> public PopupThread(fonPopupWindow popup) {
> this.popup = popup;
> }
>
> public void run() {
> try {
> sleep(millis);
> popup.dismiss();
> }
> catch(InterruptedException e) {
> }
> }
> }
>
> but everytime the thread tries to dismiss my popup, I get the following
> exception:
>
> android.view.ViewRoot$CalledFromWrongThreadException: Only the original
> thread that created a view hierarchy can touch its views.
>
> From what I understand, this tells me that I cannot access something outside
> the new created Thread, and therefore my plan is immpossible to solve on
> Android.
>
> Thx for suggestions
>
> Falko
>
> >
>
--
Romain Guy
www.curious-creature.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
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
-~--~~~~--~~--~--~---
