I have just began researching services in Android. What I'm trying to do is remotely call a method within my application. How I believe it will work is the service will listen for requests from the server in the background, then depending on the request, it will call a certain method within the application. Is this possible to do with a service? or are there better ways to do this?
I'm not asking for implementation of this, just confirmation that it could work and is the best way.
Thanks
Local service can call any functions you want inside your application.
This might not be the best application design, but this certainly will work. Local service is equivalent to any other locally created object. The difference is that service is created by Android System, not by your code.
Related
Currently I have written custom LiveData class, which adds snapshot listener to document reference while being observed, thus providing easy way to update UI. I want to continue listening to the same document after app closes, and show updates in notification.
What would be a good way to do that? I have little experience with services, etc. but if I understand corectly, I should use either WorkManager or foreground service. Is there a solution which would allow to use the same listener for UI and background?
Most answers to similar problems suggest using FCM + Cloud Functions to send updates, but for my purposes I would like to have ongoing notification and also I've experienced delays with cloud functions, so I'd like to avoid going this way.
The way you'd like it to work is simply not possible anymore these days.
When your app is backgrounded on Android, the operating system will reduce its resources usage over time. This means that you can't rely on Firestore's usual mechanism to receive updates from the server, not even in a background service.
The idiomatic way to deliver updates to an app that is not active in the foreground is (as you've found) to send FCM messages to that app from a server or Cloud Functions. If you're having trouble making this work, we'll be better able to help if you post the minimal, complete/standalone code with which we can reproduce where you got stuck.
I'm a beginner in android development and I'm trying to implement an android udp client, which connects to a java server and sends/receives some packets from it.In this process it collects some data (like round-trip delay etc), which is used to measure the QoS of that particular network. I have tried implementing the connection and sending/receiving data using Java Threads, but the application crashes, and hangs if i try to use more than 2 threads. So I'm looking for alternatives. While going through this site as well as some other links I found that in android multiple threads can be implemented using AsyncTask, Handler etc. Also I found that the Service class also helps to run a background service in an app. Please suggest which approach among these would be the best to achieve my purpose.
Thanks in advance.
You can use AasyncTask to do this and as you mentioned service may be useful too, where u can let your application do whatever it wants in background , if user needs to use application by its interface then AsyncTask must be used to avoid Crashing
There is not one right answer that can be applied as a broad stroke to how to do Android multi-threading. There are a few different ways to approach it based on what your specific needs are.
Any long running, blocking call, in Android will result in the application crashing.
The most common solution is to use an AsyncTask though. For example, when I want to make a call out to a web API endpoint for some XML data within an Activity I would in this case use an AsyncTask and kick off the calls from within doInBackground.
This is not an appropriate solution though if the wait time is longer, or possibly an unknown wait time. Or in a situation where there will always be waiting such as a message queuing service. In this type of situation it may be best to write a separate app based on extending the Service class. Then you can send/receive notifications to/from the service from your primary application in a similar manner to how you would communicate with a web service.
I am having trouble grasping the correct way to implement a centralized data access for different resources.
I want to have a single class, call it DataAccess.class that will call from both a SQLiteDatabaseHelper.class and a ServerAccess.class depending on what is appropriate when I call it's methods.
I thought extending DataAccess.class from a Service was the best approach so I can use ASyncTask for the ServerAccess.class. Now I am having doubts. The DataAccess.class needs to be accessible by most of the Activities in my Application, and I want it to stop when the Application does.
According to the google developer resources it sounds like a Service is well used for ongoing operations in the background but I am unsure how to handle the life cycle given the scope that I am trying to incorporate. Can I make the Service call startService() and stopService() internally when I use the DataAccess.class methods? Does it make sense to call it every time I access the Service or should this only happen once at the start and stop of the Application?
Thanks for the help,
I would recommend
1) Use all AsyncTask based solution because Service - Activity Communication is limited. (Unless of course you need to run something in the background) BUT I would love to hear the counterargument to this, why use a service instead.
2) Don't use just one Facade like DataAccess but make it specific to your app functions (ie sort of like System Services in Android).
3) You should use factories just like Android does to get the DataAcccess object you need. This addresses second part of where you get DataAccess object. Follow same model as getting and Android System service.
4) Use Content Providers where indicated and manage as indicated in Android docs.
Update: I think these are sort of the Axioms of a good solution. Not the whole thing. I will update as we consider this in depth.
I need some help in understanding when and why to use Remote Service instead of local service. There are several cases where one can use a local service. For example: playing music in background, downloading files from network without interrupting the user. But i am unable to found a similar use case scenarios where i have to use Remote Service.
I am very curious about the scenarios where one can use Remote Services.
Any help is appreciated. I dont wanna know how to implement it. I know the technical part on how to implement it, do the interprocess communication. All i want to know is when to use this.
Thanks!!
Remote services are used when different applications need to communicate with said service. Having a service that, say, tracks your location, can be accessed from multiple applications using remote services.
I can find several examples of how to build a service, but I'm having a difficult time finding a working example of how to send messages between an Activity and a Service. From what I can find, I think my options are to use Intents, AIDL, or to use the service object itself as per this question.
In my case, my activity is the only activity that will ever access the service, so a local service will do. When the activity is open, I want to see some status messages from the service, which will be coming in at up to 20 Hz. Are there any limitations on how many messages per second those communications methods will support? Basically, which method is going to be best for my situation?
Thanks.
Since your Actvity and Service are a part of the same app, then no need to use AIDL. You may simply use your Service as a local one.
The limitation is only affected by the performance of your device. There is no cap on requests per second.
Usually there is a context switch involved, that uses quite a lot of cpu (compared to other parts of the transmission), but since you use a local service you don't suffer from that. In any case, 20Hz is not a problem.
The best solution for you would be to use AIDL, and set up a callback that the service can call to report its status.
There is good example of how this is done in the APIDemos.