I have an application which accepts some data from the user and stores it in a DB.
I need to monitor this data (whether the application is running or not) and create notifications based on this. The data may change without user interaction, so I need this monitoring system to run even when the application is not running.
I have read up on AsyncTask, Services and Handlers, but I am confused as to what I should use for this. Can someone give me some direction?
My current idea is to use a background service, that is IntentService.
Yes, you need to use a Service:
A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.
You need this to host the app outside of a user interface. The application by definition must be running to monitor the data, however the UI (and associated activities) do not. A Service is how you accomplish this.
Related
I'm newbie in Android services and I need some help. I'm trying to understand the google's guide, but it really lacks lot's of information and i hate the fact that google automaticly translates to my language and doesn't allow me to DENY it, so i cant quote it here.
https://developer.android.com/guide/components/services
I've an app that perform long tasks on background, so I do understand that i need a service to achieve that since activities and related thread or resources might be killed by android when the app goes background.
My service monitore some stuff from user social media so i do need to use social media Apis to contact with their server. To make things easier i wrap the social media apis into one facade and my service deals only with that facade. this facade is a singleton
the user logs in-> the service starts to run in background -> at certain point the user leaves the app now starts the problem...
after the user left the app, my background service keeps running: OK
all its fields still aren't collected by GC: OK
but the inner fields of the facade singleton get released by GC and at certain point my service call singleton (not null) which calls some field that now is null: PROBLEM
how can i deal with that? how can i force android to keep those fields (aren't many) alive because they are being used by my service
PLEASE- do not ask me to make them parceable or something like this... it is a third party api i cant change
I have a case in my Android application in which I need to perform a long running task. At the end of that task I will use that info. I have multiple activities that need to access that info and I do not need to recalculate it each time.
The simple answer is create a 'static' class that can store the info. If the info is not yet there, it can start an AsyncTask to get the info. If the info has already been obtained/calculated it can just give back the info.
However I am wondering if a service is a better pattern/idea in this case. Can I use a service in Android, have that service obtain the data and allow other activities to ask that service for the data?
However I am wondering if a service is a better pattern/idea in this case
If the task will take longer than a second or so, I recommend the use of IntentService. That way, if your app moves to the background while the work is going on (e.g., incoming phone call), Android is less likely to terminate your process, allowing you to complete your work.
If the task will take longer than 10-15 seconds, I recommend the use of a WakeLock as well, perhaps in the form of my WakefulIntentService. Otherwise, the device may fall asleep while the work is being done.
and allow other activities to ask that service for the data?
You only want a service around while it is actively delivering value to the user. Sitting around waiting for activities to ask it questions is not actively delivering value to the user. IntentService automatically destroys itself when the work is complete.
When the data is ready, use an in-process event bus (e.g., greenrobot's EventBus, Square's Otto, LocalBroadcastManager) to tell interested parties that the data is ready. If you also need to hold onto the results past that point, use an appropriate feature of the bus (e.g., sticky events with greenrobot's EventBus, the #Producer pattern with Otto), or have a separate singleton cache.
If the information is needed at different points of the Application life cycle then, then I would suggest storing it using shared preference. That would give you the option of accessing the information next time you would start the App.
However, if you would need to notify an activity of the availability of the information I would use some bus in the application. Incase you wanted to use Otto be mindful that it has been discontinued in faver of Rx. a link to Otto's github page
I need a shared list of computers made available to all my app's activities. The list of computers needs to be upated by two background tasks of some kind, one that blocks on a socket waiting to receive data, and another task that periodically purges computers from the list. What is the proper Android way of doing this to avoid running into activity lifecycle problems? Specifically,
Can/should I use a singleton to maintain and expose the list to the activities and background tasks? (I'm familiar with thread synchronization issues and am prepared to deal with that.)
Can/should I use the IntentService class (two separate instances for the work I need to carry out) or is there a better way? Do I need to use a BroadcastReceiver in that case or could I still store the list in some common place, like a singleton?
How do I avoid keeping my services running when my application is put in the background?
Updated answer for updated question
You can use a Singleton if you don't have a problem with losing your data when your app get's killed (e.g. when you can rebuild the data on restart). In this case you should check that all your components run in the same process (which is default).
You should not use IntentService for intra-app-communication, however bound Services might be an option here
If you bind services from an Activity and unbind them in onPause, they get automatically stopped (if there are no other bound contexts and they weren't started with startService)
If you think your tasks are too complex to accomplish in the same Service, I would recommend two Services bound by an Activity and backed by a ContentProvider which e.g. can be backed by a database.
Old answer
The issues you expierenced might be a problem of Thread-safety (or the lack of it)
Two Intent Services just to share data within an application is definetly way over the target
A broadcast is the right way to notify components of a change
You might want to take a look at Content Providers
Another solution might be a service, which can be bound by all your other components
You can use Database to maintain the UDP packets with timestamp.
Also periodically check the last sync time from Database to check whether UDP packet is coming or not. Hope you know how to use Database.
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'm building a program which interfaces with a device which runs its own internal web server. I communicate with the device via a web API.
Basically what happens is that a GUI is presented to the user, where the user can make certain modifications to the device. These changes are communicated to the device, and results are returned through XML. The device needs to converse with the program in the background more or less continually (say every 15s or so) to update certain values to the user.
My structure that I'm envisioning is something like this:
UI - Main - Networking - XML Parser.
I'm looking for advice on how to manage these. I understand the UI thread should be separate to provide a smooth experience to users. I also understand that the networking should be at least an asynchronous task. I'm not so sure about how to handle their interaction, and make sure things are happening smoothly and effectively.
My idea is that Main will handle passing data around, telling the networker to send specific messages or changes, passing the returned XML to the parser, and then passing the parsed values to UI for handling.
I'm curious though for advice beyond that.
Have a look at creating a service that is created with your Activity. Without knowing the details of your plan, a Service looks like the optimal solution to perform all the heavy work.
UPDATE:
You could have the calls to web API run in a Service and, when needed, update the UI through an interface. You would have to instruct the Service to run on its own thread, so thread safety is an issue, but less trouble in the long run than using an AsyncTask.
Have a thought about using Google C2DM.
In your case,
Pros -> Less battery use, coordinated network traffic, Don't have to run a continues service and doesn't have the potential of being killed when the device runs out of resources.
Cons -> You have to post the results manually back to your internal server, and server should know which request the device is replying to. Communication is disconnected and may not be real-time. Requires a google account on the device and Google market.