I have never really looked at LVL. Using a bound service there is annoying.
Anyway, you're going to have to block the IntentService background
thread, which sucks IMHO, but I can't quite see how to avoid it. So,
here's what I'd do:
-- Override onStartCommand() to call bindService() on your
On Sun, Feb 5, 2012 at 10:52 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
Well, the unbind() call that threw the Service not registered was
originally bound to from a WakefulIntentService, not an Activity.
Oh, I'd never bind to a service from any IntentService, regardless of
what Context you
Ok, but how should I handle calling a bindable service from my
IntentService? This is the LVL library, so it's not under my control to
make it synchronous.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
Let me extend this?
How is binding to a service from an Activity differs from an
IntentService? I mean an Activity can be finished() at any time and thus
go away also?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this
Let me expand on this comment:
How is binding to a service from an Activity differs from an
IntentService? I mean an Activity can be finished() at any time and thus
go away also?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post
The big difference between the application context and an activity context
or service context is lifecycle. The activity context is valid until the
activity's onDestroy(); service until the service's onDestroy(); and
Application is never destroyed.
If you have bound to a service, and the context
Ok, thanks, Dianne.
So it's OK (and desired) to bound to a service from an IntentService using
the Application Context, since the bound service is asynchronous and as
Mark pointed out, the Intent Service finishes right away?
--
You received this message because you are subscribed to the
Well, it depends. If you actually need to use the application context,
that means you are allowing your service to get destroyed while still bound
to the other service, and in general I would assume that is a bug in the
app. You probably shouldn't be doing stuff after your service is
destroyed,
Well, here's what I am doing:
I have a Daily Processing alarm, which among many other (synchronous)
things, as the last thing it does is check of the app's license via the LVL
service. For this, I bind to the LVL service and then as far as I am
concerned, I don't really care what happens and
Well, I made my change, but one of the uses for the Context is bind to a
service.
This now fails sometimes on unbind() with a Service not registered
message.
I asuume I still have to use the Application Context to bind to services?
--
You received this message because you are subscribed to
On Sun, Feb 5, 2012 at 5:38 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
Well, I made my change, but one of the uses for the Context is bind to a
service.
This now fails sometimes on unbind() with a Service not registered
message.
I asuume I still have to use the Application Context to bind
Well, the unbind() call that threw the Service not registered was
originally bound to from a WakefulIntentService, not an Activity.
I bound to the service in doWakefulWork() and unbind() in onDestroy()
as well as when I am done with the service.
Basically I have a cleanup() method which looks
On Tue, Jan 24, 2012 at 2:16 AM, Zsolt Vasvari zvasv...@gmail.com wrote:
In a Service... Actually, it's WakefulIntentService, extending your
class.
I only got a single report of this failure (I use ACRA) and it's in a
commonly executed code.
That's pretty bizarre. A fair amount of work
Is there a particular reason why you are calling
getApplicationContext().getResources(), rather than just
getResources()? getResources() is available on Service as well.
I honestly don't know/remember why Let me turn the question
around, why are you using getApplicationContext()?
For
On Tue, Jan 24, 2012 at 7:27 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
I honestly don't know/remember why Let me turn the question
around, why are you using getApplicationContext()?
For example, your sendWakefulWork() looks like this, why?
public static void sendWakefulWork(Context
Ok, thanks. That makes sense. I will try changing my code to not to
use getApplicationContext()
On Jan 25, 8:37 am, Mark Murphy mmur...@commonsware.com wrote:
On Tue, Jan 24, 2012 at 7:27 PM, Zsolt Vasvari zvasv...@gmail.com wrote:
I honestly don't know/remember why Let me turn the
In a Service... Actually, it's WakefulIntentService, extending your
class.
I only got a single report of this failure (I use ACRA) and it's in a
commonly executed code.
On Jan 24, 8:34 am, Mark Murphy mmur...@commonsware.com wrote:
Where are you executing this statement?
On Mon, Jan 23,
To ellaborate, it's inside the doWakefulWork() method.
On Jan 24, 3:16 pm, Zsolt Vasvari zvasv...@gmail.com wrote:
In a Service... Actually, it's WakefulIntentService, extending your
class.
I only got a single report of this failure (I use ACRA) and it's in a
commonly executed code.
On
Why not create a parentcontext and use this context for calling
getApplicationcontext().
like
Context parentcontext;
parentcontext = this; //must be the contrustor, pass the calling context
here.
and try using parentcontext.getApplicationcontext();
--
Warm Regards,
*Mukesh Kumar*,
Android
What's your point?
On Jan 24, 3:23 pm, Mukesh Srivastav mukicha...@gmail.com wrote:
Why not create a parentcontext and use this context for calling
getApplicationcontext().
like
Context parentcontext;
parentcontext = this; //must be the contrustor, pass the calling context
here.
and
As I said, this code works for 20,000 users, but not this one.
If you understood Java object references, you would know that just
because you assing an object, it's still the same object, so
this.getApplicationContext() is the same as
Context parentcontext;
parentcontext = this;
There are APIs to allow you to run code on the main thread to access
its objects. I'm a little confused about what APIs you are talking
about and how they would help solve this problem. Could you clarify?
To me it seems that the test runner should not be calling my tests if
the Application is
The framework runs the instrumentation independently of the app, so it can
do what it wants when it wants. And an activity is not the app.
Activities are created all the time, you can't wait for whatever one to be
created before running the instrumentation.
You are calling this while the app is running, and it hasn't finished
initializing.
Generally you should be very careful about directly touching app objects
like this from tests, since the test is running in a separate thread. There
are APIs to allow you to run code on the main thread to access
24 matches
Mail list logo
