I'm fairly new to Android development so I was wondering how I should design/structure a new program I want to develop. I'm not sure if it should be started as a service or a broadcast receiver or an activity even (all I have ever done).
What I want to do is receive when certain events happen on the phone such as when the following are turned on blue-tooth, wifi, gps and camera. And when that happens send a message to a network manager (using SNMP).
Now I want this to continually run in the background waiting for these events to happen. Do I create a service and create receivers to create receivers and when the action happens create a service/tread to act on it/generate the SNMP message?
When that Is answered I was also struggling with how the manifest file would be structured fro when running receivers and services within the same set of code. But I guess that depends on how you design it to run?
All you need is a broadcast receiver which gets notified about the listed events and start a server who asynchronously send some messages.
Related
Hi I'm want to collect user health data. In iOS we have HKObserverQuery to observe.So when ever there is a change in health data for example, change in step count it will wake our app. Is there any thing similar in android for live updates. So I can setup monitoring for any changes.
I been scratching my head for few days. Thank you.
Broadcasts
Android apps can send or receive broadcast messages from the Android system and other Android apps, similar to the publish-subscribe design pattern. These broadcasts are sent when an event of interest occurs. For example, the Android system sends broadcasts when various system events occur, such as when the system boots up or the device starts charging. Apps can also send custom broadcasts, for example, to notify other apps of something that they might be interested in (for example, some new data has been downloaded).
You Could Use LocalBroadcastManager for your App when data changed it will called from your code
Then Register Reciever in manifest
send Broadcast locally fron your app to Broadcast Reciever when data changed in store Like HKObserverQuery
https://developer.android.com/guide/components/broadcasts.html
Yes, there is a CompletableFuture class in java to do so. You can read about it in Java's documentation
I'm new in android development, and need some help and guidance in triggering my notification in my application. I manage to read some documentation about BroadcastReceiver where in it broadcast an announcement and another app can receive that announcement and trigger something to happen(like popping out a notification). I tried doing it, wherein I have 2 (two) application in 1 (one) android device and it worked. But when I try separate the 2 (two) application and install it separately into 2 (two) android device and try to send the broadcast, the receiver didn't manage to receive the broadcast. Then I tried to do more research and saw that BroadcastReceiver is a "System-Wide" broadcast, means (correct me if I'm wrong) it will only work inside 1 (one) android device. So my question is now, is there anyway to make the BroadcastReceiver send the broadcast in the network so that if an android device with a receiver can receive the sent broadcast? if it's not possible, is there another way to trigger notification in 1 device using another device w/o using the FCM/GCM?
PS:
The reason why I don't want to use FCM/GCM is that I'm trying to do this in an adhoc network, wherein internet connection is not present. And I'm not sure how FCM/GCM will behave w/o the internet connection. I appreciate any help. Thanks you.
You can setup a server in a background service on one of the devices and send data to if from the other device, and then have that service create a notification when it gets data.
If you want the devices to automatically be able to discover each other try using the network discovery service. https://developer.android.com/training/connect-devices-wirelessly/nsd.html
I hope that we cannot receive any messages ,when we force stop the default messenger app in our android device.I force stop default messenger app and sent message to that android device. I get message to that device.why this device receive message?
On Android 3.1+, a BroadcastReceiver will only work after its app was force-stopped if an explicit Intent is used to send it a broadcast. Here, by "explicit Intent", I mean one that contains the ComponentName of the receiver, in addition to possibly other data like an action string.
It is unclear what you mean by "the default messenger app" and "messages". If you mean SMS, I would expect that on Android 4.4+, if the user's default SMS client is force-stopped, it would still get SMS messages, as Android probably uses an explicit Intent to talk to it. However, on Android 4.3 and below, I would not expect a force-stopped SMS client to receive messages, as SMS_RECEIVED was just an ordinary ordered broadcast then.
This happens often because there is a service that is listening. The app uses the service to connect with Google Cloud Messaging and receive the messages. You'll need to disable the service. You can view Settings -> Apps, then swipe left to view All or Running and view the services.
Extending a bit further Steve's answer, this is probably an exemplary case that describes why programmers must control any Services in their applications. Many people just declare and run them, and then they forget about them. Services run in a different component than the foreground app, so if you 'close' your app but you don't stop the Service, it will be still running and that's probably what you're experiencing. However, many people tend to misunderstand this concept. This is a different component, but not a different thread nor a different process.
As per the official Android Developer Guide:
A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. [...]
You don't specify what kind of message system uses your app, but if it is GCM (Google Cloud Messaging) or some alike system, it indeed uses a background Service to receive notifications from the central server and you're getting them because your foreground app is closed but your Service is still running.
To stop a Service, you'll need to call Context's stopService() method, as defined in the documentation prior to stopping your foreground application.
I am going to implement Download Queue for my application. One of its feature will be when Network get connected or disconnected. I want to notify my QueueManger(Service) to update items status and stop.
I know use of Broadcast Receiver and how to use it. My question is if my application is stooped (finished) will broadcast receiver will work? Will it notify application or not?
If not is there any way to achieve this functionality even when application is stooped.
If you register your receiver in the XML instead of programmatically, then it should be able to catch these even when the program is not running.
See question, same solution applies Intent action for network events in android sdk
If you have defined your broadcast receiver as <receiver> in AndroidManifest.xml and listening for android's default action strings, then Yes, it will work.
Otherwise, I would recommend you to make use of Service. It can run silently in the background and do all the logic you want. Your service can even be provoked automatically when the phone is restarted (if you code correctly).
I want to know the difference between services and broadcast receivers, can anyone point out an example that can be observed on android mobile devices.
Thanks
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method.
Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Here is good article : Service and BroadcastReceiver
Service is used when you want to do something in background, any long running process can be done using Service in Background. For example, you want to play music when your application gets close. In that case service will be running in background with music.
Example of Service
BroadcastReceiver is used when you want to fire some stuff or code during some event. For example, event can be on Boot of Device. If you want to perform something when device Boots, date and time changed etc...
Example of BroadcastReceiver
I think of it possibly a different way. A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
(The reason I say a Service is a bit like an Activity is that: You wouldn't broadcast a message saying "start Activity MyActivity" across all apps installed on the device. It is only for your specific app.)
Of course, as others mentioned, a Service can continue running in the background, whereas a Broadcast Receiver should finish quickly (e.g. if it is running for more than 5 seconds it may be killed by the OS). The Broadcast Receiver can still run in the background (when app is closed) under certain circumstances. For this, it's worth mentioning that there are actually two types of Broadcast Receivers - Manifest-declared, and Context-registered. They have different lifespans and restrictions - the former can receive broadcasts in the background with certain restrictions, while the latter cannot receive broadcasts in the background (app must be running and active) but has no restrictions on the types of intents that can be received.
Both services and broadcast receivers must be specifically invoked (via an intent), but for services this is usually a specific call (e.g. when your app is started or when the user clicks some button) whereas for broadcast receivers they don't need to be explicitly started as they will start anyway when a relevant broadcast is made.
Here's how I would think of it:
Type
Displays UI?
Can continue running for a long time when app is closed?
Can receive intents when app is closed?
Intents must specifically target your app?
Restricted list of intents that can be specified?
Activity
Yes
No
Yes
Yes
No
Service
No
Yes
Yes
Yes
No
Manifest-declared Broadcast Receiver
No
No
Yes
No
Yes1
Context-registered Broadcast Receiver
No
No
No
No
No
1: Only if you target Android 8.0 or above. The restrictions are not applied if the intent specifically targets your app. The restricted list of intents can be found here.