> Are you trying to tell me that it's totally safe to throw stuff in
> static fields?
You have to be careful you don't accidentally pin things into memory,
eg, putting a View or a Drawable or anything that inherits from
Context into a static field would be a bad idea. Otherwise it's not a
problem
Check out this link - http://www.paxmodept.com/telesto/blogitem.htm?id=766
This works great without calling a service.
On 30-May-09, at 2:03 AM, Mark Murphy wrote:
>
> Robert Green wrote:
>> Are you trying to tell me that it's totally safe to throw stuff in
>> static fields?
>
> I wouldn't go
Robert Green wrote:
> Are you trying to tell me that it's totally safe to throw stuff in
> static fields?
I wouldn't go with "totally safe", but it's an unfortunate requirement
in some Android cases (e.g., sharing a WakeLock between a
BroadcastReceiver triggered by AlarmManager and a Service doi
Are you trying to tell me that it's totally safe to throw stuff in
static fields? I've always avoided it because of years of shared
space in a JVM in web apps. I know Android uses separate processes
for each application but is it safe to say that it will kill all of
your static allocations even
> I DO need it to run in the background, that is, while orientation is
> changing.
That's not "in the background" - the activity manager will keep your
process alive during configuration changes anyway, regardless of
whether you have a service or not. The only reason to use a service is
if you ne
Mike:
I DO need it to run in the background, that is, while orientation is
changing. The service is also really nice because I can do things
like submit a score in the background while the user is going from the
game back to the game menu. I don't like the static handler idea
because it can't h
On May 28, 4:40 pm, Streets Of Boston wrote:
> Is it safe to cache a Handler (in a static variable)?
It should be OK, from my reading of the code. It keeps a reference to
the current threads looper, but that should exist for as long as the
process does anyway.
I *think* you'd code it up like th
> Done! Man I'm happy to have that working. I've been retrofitting all
> the netcode with this service for the past 20 hours of coding and I
> can't wait to not be working on this anymore!
Well, I did show you a simpler way to do it. I'm not sure you should
write a tutorial on this - like I sa
This code seems to rely on the fact that your background thread does
not die immediately. If your service is rebound within 30 * 1000
milliseconds, then it all works well.
- This is an unlikely scenario, but what if the re-bind happens more
than 30 seconds later?
- What if the service is stopped
"So, how do I keep the service alive between orientations but shut it
down when the user has totally exited the app?"
I use this 'trick' to figure out if an onDestroy is really a destroy
or just a configuration change by the user (e.g. closing keyboard):
Use onRetainNonConfigurationInstance() an
I used the example in APIDemos for the bindable service.
I created AIDL interfaces for it, then I did what I said in my last
post.
It's a ton of code and a lot of overhead for interfaces but once you
get it right, it works really well. I'll probably write a tutorial on
how I did it at some poin
Hi Robert
Can you please post how you're using the service. I had the same
problem and asked this question on 22 May but didn't get a reply.
Using managed dialogs gives out errors too on orientation change.
Thanks.
On 29-May-09, at 9:23 AM, Robert Green wrote:
>
> I just tested using onl
I just tested using only bindService and now it's not doing what I
need it to do. The requirement is to have the service stay running
between orientation changes. Now it stops when the first activity
unbinds and starts new when the new activity binds, losing the current
work (which is a form sub
I'm just worried about using bindService alone because I need the
service to stay alive between orientation changes of the activity.
There will be a period when the activity unbinds and the new activity
binds but the service can not be stopped then or it will defeat the
whole purpose of using it.
> I'm wondering if I just leave it running, if the OS will eventually
> kill it because nothing is bound to it and it is inactive. Can I
> count on that?
No. If you start a service with startService() it is supposed to quit
itself, otherwise it will never die. It's best to pick one of bind or
st
I dunno, I wrote a really awesome service that can do things a more
simple solution can not - such as, if it is processing something and
the registered callback unregisters, then it finishes processing, I
have it queuing the result. The next callback that registers will get
that result fired imme
Hi Mike,
Is it safe to cache a Handler (in a static variable)? Some objects,
such as Activities or Drawables, are not safe to cache statically and
share amongst multiple activity-instances due to possible memory leaks
(memory referencing to destroyed activities that doesn't get cleaned
up in a ti
You don't need a Service, that's way too complicated for what you
need. Especially if you use the RPC stuff (optional but the docs don't
tell you that!)
If you create the progress dialog using the onCreateDialog() method
then it'll be automatically reconstructed after an orientation
change.
To r
Yup, I found it.
RemoteService.java
IRemoteService.aidl
IRemoteServiceCallback.aidl
Is that what you're talking about?
I'm looking at those now and am going to try to code this up in the
next few hours.
On May 27, 4:08 pm, Streets Of Boston wrote:
> Your steps below are basically correct, but
Your steps below are basically correct, but take a look at the API
Demoes source code.
There is one for demoeing how to write a Service, using AIDL.
It also shows how to write a callback method (service calling back
into activities bound to that service).
I use it for monitoring image-upload prog
I'm searching all of the documentation I can find but I'm not seeing
any mechanism to register for callbacks from a service or to callback
to whatever handler is registered as the service.
I see the AIDL binding stuff, and so far I think maybe this sort of
thing might work?
Activity
-- Starts Se
I agree you should use a service.
But for optimization, i would use this method.
You should have a call to the service to query if the service is still
busy. If so, show a progress dialog and start listening to the service
to know when it no longer is busy (callback from the service into your
app
I just looked at it.
1) They state that it is only an optimization and that you are not to
rely on the method being called.
2) My design is a little too complex to use that elegantly. I do
network calls from multiple activities and some dialogs on those
activities, which need to chain to othe
Take a look at the method onRetainNonConfigurationInstance() of the
Activity class. :-)
http://developer.android.com/reference/android/app/Activity.html#onRetainNonConfigurationInstance()
On May 27, 2:01 pm, Robert Green wrote:
> I have an app that communicates with a server. While it is
> com
24 matches
Mail list logo
