I am developing a simple library project which have a broadcast for Battery stats.
I implemented this simple library project in 3 of the my projects. As the result of this, suppose at 30% battery I need to send something to the server, I received the broadcast and send data to server. What is happening is as I have implemented the same broadcast in 3 of my applications, I receives 3 same files at the server.
I need to restrict this, such that only one time the file will be send to the server, that means if from 3 projects if any one received the broadcast other two will not receive it or don't perform the broadcast.
As there are 3 separate broadcast senders so i think the only way to stop this behaviour is make a shared object that the first sender (or receiver) will create with some sort of timestamp and the other will check and if the object is present - stop sending anything to server.
That can be achieved with:
world readable/writable preference (i think it marked as deprecated since api 17..)
or
some sort of file on sdcard
Related
What is maximum acceptable frequency from your point of view or experience of sending broadcasts in Android to be received by BroadcastReceivers without performance impact?
Let's say we send only basic data in a Bundle without need for long deserialization.
I am going to send broadcasts only inside my app with LocalBroadcastManager.
In other words this question is about when you should stop using broadcasters and write you own implementation for faster usage and when you should not do it.
First of all, if you send data inside one app, I would advise you, instead of BroadcastReceiver use LocalBroadcastManager or even not use any type of broadcast receivers at all - just Observer Pattern (here good article on this topic).
What would be good approach to establish communication between different APKs? One app can send request to other apps and wait for response.
I can think of:
1. using BroadCast receivers: send "request" broadcast and receive returned broadcasts (results). This seems nice clean solution, no security problems, but how to get all results back as "one" - usually I will want to send out broadcast to collect app identifications, and get result like array.
2. use sharedUserId between all these apps and gather or execute whatever I need directly on the apps. But here are have couple of more loose ends:
- how do I get list of apps (through list of installed packages?)
- is with sharedUserId and same signature possible to access other app internals? like register/unregister component, etc.?
Thanks!
EDIT:
Have been reading more about ordered broadcasts and so far this seems good way to go. Using order broadcast each of other apps will fill in its own data part and result will be returned back to supplied "final" receiver.
I am using ordered broadcasts. When broadcast is send out, each receiver adds its information and last receiver calls resultReceiver.
I would like to develop an application. It could be a game or whatever. I would have the same application in two or more devices. When one of them finish his tasks the other "client" must receive an notify that he has task to do and his datas should be updated automatically with the last changes. I guess that I would need a server in the middle where I'd save the model with the datas and send to them where the smartphones are communicating through it. It could be like a cardgame or kind of.
So,,,,
1. Two or more clients with the same application.
2. When one of them finish his task or turn, the other client should get a notify with his dates updates.
I have been looking at GCM, but I don't know if I could send complex datas through it or not,, and maybe there is a better way to make these kind of things.
Could someone give a clue where I can start??
Thank you!.
In your architecture, you must separate out the control and data aspects of the app.
You don't need the cloud to initiate a push of the entire data. If your app on any particular device gets a notification that an update is pending, then it can initiate the download at its convenience. Just use the GCM to push a notification that some task is pending for the app.
I'm using pubnub as a publish/subscribe channel between an android app and a server.
Currently I'm thinking of how I will implement this.
I'm using the provided library for android (https://github.com/pubnub/pubnub-api/tree/master/android) but I think there will be some problems with the application lifecycle if I use it like it is now. (Correct me if i'm wrong)
I was thinking of implementing it as a service
What I want
The service has to keep on running until an hour (negotiable) after the last app usage. That's because we want to have notifications when a message comes in, but the app is not the currently used app.
How do i stop the service after one hour of non-activity of the app? Probably Android will kill it, but I want some control.
The Service must be able to trigger the app to change it's interface when specific messages come in (I was thinking of sending intents from the service when we receive a pubnub message?), pubnub will send data to the service, so I need a way to pass this data to the application (probably save it in a Bundle in the intent?)
I need to listen to multiple pubnub channels (max 2 at the same time), I think I will have to do this in multiple instances of this service?
I think I will do it like this:
Create a service that's started when the app starts
Let the service listen to a pubnub channel
When a message comes in, send an intent and use the intent filters
implement broadcasthandlers to listen to these internal intents
Is this the right way to do this? any hints?
You have an excellent set of questions an detailed points that I will talk about in this answer. You are using Android and you are interested in the conventions and best practices for PubNub Publish/Subscribe scenarios.
Your use case is very common and the best ways to build apps always vary dependent on application needs. However you definitely have the right idea and have asked all the right questions. You just needed some sample code and a direction to get started on implementing the specifics of your application needs. To define your needs in a list:
Connect/Disconnect Ability.
Always-on Background Service that can Send/Receive data and notify other apps via Android Intents.
Connecting to Multiple PubNub Channels at the Same Time.
So to get started I will provide you direct links to some examples and methods:
Create a Service that is Started when when Android Boots: https://github.com/pubnub/pubnub-api/blob/0dfd8028b803332f5641adc909b1a26f87bd7ff1/android/PubnubAndroid/src/com/aimx/androidpubnub/BootReceiver.java
UnSubscribe/Disconnect Example Code when you want to stop listening on a PubNub Channel: https://github.com/pubnub/pubnub-api/blob/0dfd8028b803332f5641adc909b1a26f87bd7ff1/android/PubnubAndroid/src/com/aimx/androidpubnub/MainActivity.java - Listening to multiple channels is easy by placing the blocking pubnub.Subscribe() method inside a Thread.
Regarding your thoughts - This IS the right way to do it:
Create a service that's started when the app starts
Let the Service listen to a PubNub Channel.
When a message comes in, send an intent and use the intent filters.
Implement BroadcastHandlers to listen to these internal intents.
I'm creating an Android application that will register an Observer and listen for events, I will probably use one of the suggestions by Mark in this previous question.
However, my question is, how can I create a "stub" on Android that I can use to fire events at my applications observer? For the purpose of this example, we'll assume that my app is listening for a wifi signal strength, I need to create something that will run on the emulator (or device) that will mock up data to "pretend" it has a strong/weak signal, and to relay that to my app.
Any suggestions?
I am no Android expert but here is my catch.
If you are implementing an observable, I believe you need to create a Service by inheriting from ServiceBase.
Also create a content provider and allow other applications to insert data. The whole notification is built into the framework so if you have a cursor, you will get notifications of change in the data.
So here are the steps:
You run the service and register for notifications
Application is getting an instance of your service and registers to get back a token
They use your content provider to insert event along with the token they got
They call the notification
You will be notified whenever anything changes.
I know that there are notification services built into the framework but I have never had a chance to look into it.