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.
25 matches
Mail list logo
