I am creating an Android Class library that makes calls to an internal REST API and also utilizes Android's Geocoder class (specifically getFromLocation()) which requires Context. I was planning on making the library an IntentService to allow for it to be run asynchronously, but I can't figure out how to handle Context (the GeoLoc call is in a separate class that is part of the library that the IntentService calls).
My question is, how do I obtain context necessary to instantiate android.location.Geocoder from within an IntentService?
Every Service is a Context. You can use this or getApplicationContext().
IntentService Inherits Service, and Service Inherits Context.
You are free to use "this" as Context whenever you needs it inside your IntentService.
Related
I'm developing an Android app, and I need a ThreadPool for background operation (insert/retrieve from database, calculating distances between latent points, etc) in repositories and in a foreground service.
The official Android documentation says that it's correct to put ThreadPoolExecutor in a class that extends Application ( https://developer.android.com/guide/background/threading ) but they and other sources also says that's correct write a singleton class holding the ThreadPoolExecutor . I don't need to access context or other android framework related stuff in my ThreadPoolExecutor class, so now I'm confused: should I extend the application or do a singleton class? My doubt is that my foreground service is running even if app is killed, so it may be better use the separate singleton?
Thank in advance!
I am using Kotlin to build an Android app. I have a Service that is also a singleton. When I call startService() in an Activity, I get the following exception: java.lang.IllegalAccessException: void com.mydomain.socket.SocketService.<init>() is not accessible from java.lang.Class<android.app.AppComponentFactory>
Does anyone know what is causing this and how to work with a singleton service? The reason I implemented this as a singleton is because I wanted to be able to get a reference from that service easily anywhere in my app. To implement the singleton, I simply declared my Service as object instead of class.
I ran into this same problem and I found that I have declared a default constructor for the service class but did not specify it as public.
Since it is private, the AppComponentFactory class from another namespace is not able to create an instance of the service.
Add "public" to the constructor.
I have a service bound to an activity. I defined an interface that is implemented by the activity. In the service I have an object of the interface that implements the activity, i give memory to this object when I call the method that returns the binder.
The service implements socket.io when I receive a message from the server, I call the interface method to update data in the activity.
My question is, am I using bad practices? Should I implement a LocalBroadcastReceiver to communicate with the activity instead of using the interface?
what do you suggest me?
Short answer is yes it is really a bad practice.
Long answer, even though you reference your activity over an interface it's still the same object in the memory. So let's say you have long running operation on your service then when the activity is recreated after a rotation or any kind of configuration change your old reference will be kept in the Service and it will be leaked.
So since your question is too generic I can just list the alternative methods, you can look through all of them and apply whichever fits on your style.
EventBus (Publish/Subscribe pattern, the easiest solution)
Dependency Injection (Use Dagger or similar to inject your model on
both Activity and Service
BroadcastReceiver
Messenger
I've got a quick question on the best way to handle Android contexts. A lot of things (e.g. Service) require that you pass a context as a parameter. At the present time, I have a public static variable that is set to point to getApplication() and I just refer to this throughout my application where a context is required.
Is this ok to do? Or is there a better method to handle this? A lot of my classes don't extend Activity or service and as such, don't have access to this.getApplication().
Everything seems to work ok when I just pass in my static variable.
Is this ok to do?
The Application object, in some cases, will fail to work. For example, it sucks for UI-related stuff.
Dianne Hackborn, a leading Android engineer, has stated her regret at Application existing in the first place.
My general advice is to use Application only when you know specifically why it is superior to using your Activity, Service, etc. There are cases when it is the better answer (e.g., binding to services).
A lot of my classes don't extend Activity or service and as such, dont have access to this.getApplication().
Pass a suitable Context as a parameter, as the Android SDK does.
At the present time, I have a public static variable that is set to
point to getApplication() and I just refer to this throughout my
application where a context is required.
Is this ok to do?
No.
A context applies to the context in which it was obtained. That is, an activity has context for that activity, a service has context for the service, and so on. Now, a lot of folks do what you are doing, and as you observe, it seems to work. That doesn't mean it will continue to work or that it's good design. If that was the proper pattern, Android would have been designed with Context.INSTANCE that is available statically.
An activity, service, and application are contexts (isA). Receivers are passed a context to their onHandlerIntent() method. For all other classes you write, just get used to constructing them with a context. Out of habit, whenever I create a new class, I automatically add a constructor that accepts a context and add a private field to hold it.
When you need a context in a static method, you should pass it in directly as a parameter.
I would like to bind and connect a service but not within an android activity. Is there a class witch could be extended to have a context necessary for binding?
What i am trying to do is to provid a simple java library using an android service. My library does not use a UI. I only need to bind and connect my service inside a class witch necessary have application context necessary to the binding
Thanks
You can get the context from your application class. Derive your own class from Application, and give it a static getApplication method. You can use that for creating services.
Note that without an Activity, binding to a service may be a little hard - if, for example, you're in a BroadcastReceiver, it's not going to be alive long enough for you to receive the callback after the service has been bound.
Simply create an application without default activity. Then extend base Service class. And do not forget to describe it in the manifest file.
Service has its own context.