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チェックツール gml.check.t...@gmail.com 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
I solved this using AsyncTask, thanks both for replying
On Nov 13, 2:20 pm, Stelios s.kiay...@gmail.com 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
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 s.kiay...@gmail.com 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
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, Stelioss.kiay...@gmail.com wrote:
I am a beginner in Android
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 stevebruc...@gmail.com wrote:
I have thee threads in my bluetooth program. Both my AcceptThread and
ConnectThread create a newConnectThread from within their
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 stevebruc...@gmail.com wrote:
I mean they both start a new thread called
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?
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 raghavs...@appaholics.in wrote:
I am not sure but if you have both of them start the same thread
I think I recall seeing 'KeyChar' generation errors or something in
the debug window
On Sep 2, 1:43 pm, Kristopher Micinski krismicin...@gmail.com 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
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
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
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 jfb...@gmail.com wrote:
Hi,
I am working on a simple application (studying purposes) which
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
On Apr 14, 3:20 am, MobDev developm...@mobilaria.com 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.
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
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 indodr...@gmail.comwrote:
Hello,
From the
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 craig...@gmail.com wrote:
I deal with these situations by just keeping a
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
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
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
On Mon, Aug 31, 2009 at 6:06 AM, ReubenHreuben.har...@gmail.com 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
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/
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 marc...@android.com wrote:
On Mon, Aug 31, 2009 at 6:06 AM, ReubenHreuben.har...@gmail.com wrote:
Having used Android for 4 months, and now
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
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 craig...@gmail.com 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,
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
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,
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
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, CraigsRacecraig...@gmail.com wrote:
The thread is holding onto the old
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
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
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
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:
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 hack...@android.com wrote:
And you shouldn't be doing this. You could have a static pointing to the
currently running activity instance (which very well
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
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
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 hack...@android.com wrote:
And you shouldn't be doing this. You could have a static pointing to the
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.
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 romain...@google.com wrote:
However, couldn't the Android framework just forward any requests from
a destroyed activity, to the newly created Activity,
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#10779608
Lex
On Jul 29, 5:06 pm, Roman roman.baumgaert...@t-mobile.com wrote:
I recommend to keep your data communication separate from the UI.
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,
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
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
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.
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
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
46 matches
Mail list logo
