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 and
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 brace
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 encou
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
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 wro
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 ri
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 p
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 would
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?
Sy
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
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 p
> 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
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'
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 fi
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
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
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 refere
> 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 Orie
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/rotati
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 mar
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 onLayoutChange
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 onD
>
> 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 wastefu
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 counteri
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 activit
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 mode
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 t
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, whic
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: htt
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
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 thre
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 prob
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
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
Bund
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.
Corre
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 w
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
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
> > de
> 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.
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
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 possibl
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
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
passwi
>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. I
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 t
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 Develop
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/Api
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 t
48 matches
Mail list logo
