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.
Related
I have an Android app that has a service that handle Firebase messages. So far it's working for me and I receive messages properly even when app is in background. What I need is somehow update app content when a message is received. That mean use network to contact backend and download fairly long JSON data and put them in database.
I have model in repository which I use in Activity. Now I am considering whenever I have to somehow call activity and refresh data but I think activity is somewhat dead when app is in background? So I don't know if it is even possible.
I can download data inside the service but my understanding of service is that it shall be lightweight and all the model and network calls seems to be a bit overkill for the service. Am I wrong?
What is ideal solution considering standard android architectural approach? Thank you.
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.
So, I want to learn this synchronization strategy instead of just using the simpler MessageAPI, but am really struggling with how to successfully implement this.
My project is like this: I make queries to download a small amount of text from an API, via my phone. I will make these queries every so often, haven't really decided on how often just yet. The data will update the watch, which should hold onto the last data received. After that first download occurs, I send data using a DataMap, to the Android Watch. I only send that once, because I believe that sets up a channel to continually send updates when ready. If that is wrong, please correct me.
My main question is this: what if the Android phone's app closes? Then the data object goes to null, and gets sent to the Watch as null? Or, should I send an object from a long-running service or shared preferences on the Android phone, so that the object is never null?
Think of the Data Layer as more of an event system, i.e., you update your data and you're notified on the other side when the data is updated (created, changed, or deleted). You don't have to worry about if the Activity is killed after that. Even if the data was 'deleted', you would be notified it was deleted.
On the Wear device, you would listen for the changes via a Service or Activity and update UI, DB, etc. accordingly.
It probably make sense to read through this Android training guide. (It isn't too long.) The Handling Data Layer Events section is probably the most useful.
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.