I want to create an app to consume real time data from an API. This API give me information about different temperatures. When a certain temperature is exceeded my app need to notify the event to the user.
This app need to run in Android and a web browser. So, my problem is the architecture... My app need to be a websocket or a REST API?
Any help is appreciated!!
You need a notification service, and google has something like that for us...
how does this works??
Take a look at the image below,
you need to register your android app in the google service, and your web interface will need an id, so everytime you want to push something to the android, your web interface instead will push it to the google server with the Id of the app, then google (no matter how) will localize your app, and even if its not running, they will get the notification,
behind the scenes there is a couple of thing that you must do, bu nothing like launching rockets from the NASA.
I will suggest to take a look to some tutorials
in order to start with the registration of your app, get the api key etc etc..
In addition to what #Xoce showed, Amazon has the SNS service which will push notifications to you. Or, if you application is a web based application inside of a native (i.e. Cordova), I've used PubNub for JavaScript based events.
A word of caution though - you'll need to define "real time" for your application. There will be a slight latency between the event and what your application sees no matter what stack you choose. When I think real time I think in terms of microseconds of delay. You may have seconds of delay. If this is a "hey, your house temperature is above a threshold" type of application then that is fine. If this is "hey, your nuclear reactor temperature is above a threshold" then this may not be the way to go.
Related
TL;DR: My app is hogging the user's microphone. Can I turn it off automatically whenever another app needs to use the mic?
I have an Android app that has some really cool microphone functionality, similar to Amazon Alexa, that stays on all the time in a background service. The problem is, my app hogs the users' microphone, making it unusable:
However, this is terrible application behavior on my behalf, and I want to do my best to avoid it. Is it possible to be notified when another application requests to use the microphone, so that I can automatically stop my service?
PS: I am using the Pocketsphinx library for continuous background voice recognition.
This is tricky, as I'm not a ware of any API for this. This surely will require system-level APIs to work like an "Ok Google" type of thing.
A viable option would be (from https://stackoverflow.com/a/43623308/603270) to run a Job at regular intervals, checking for foreground apps using android.permission.PACKAGE_USAGE_STATS.
This might suffice. But you could also add things regarding phone calls (how to detect phone call broadcast receiver in android) using android.intent.action.PHONE_STATE or media playback (via Receiver or maybe even MediaPlayer directly).
If you're really wanting to get this thing working, an alternative would be to get an array list of all installed apps on the system and which ones require permission to use the mic or not, then use an accessibility service to monitor the users screen if an app the user just opened requires the mic (which you'll know from the array you just grabbed). From there, disable the mic in your app if their app needs the mic. The background service can then check in intervals of, say, two minutes, to see if the app that required the mic is still open. This is really inefficient. But if you don't care, then this might be a good option.
There is no standard way to inform another app that you want access to the microphone (so that they release the resources and let you access it). You could however send a broadcast to all other apps ("requesting the microphone"), but the other apps would have to implement this feature (and very few or zero developers will do this).
I would recommend you to simply inform the user that the microphone is currently not available, because you can't do anything else.
I've worked with Android in the past, but haven't done anything super-advanced or what I'm about to describe so need some guidelines as to what the best approach/method is to do this before I proceed.
I'm not entirely sure how to google this, so it's best to explain.
I want to build an Android library project preferably with the source undisclosed. I read this can be done as follows: Create another jar that the Android library project references. However, not sure if all of the source code can be private. If anyone can point me somewhere, that would be great.
Asides from that, the library needs to expose an API for any Android app to use, and some sort of event mechanism to broadcast an event when certain events happen (e.g when the app is in foreground etc).
A scenario would be:
1) User loads the app which has the library embedded
2) The embedded library detects that the app has loaded and 'sends an event' to the app
3) The app captures the event and does some stuff specific to the app + an API call to the library
I guess what I'm interested mostly is figuring out what the best ways are to capture the callbacks by the app, once the library has sent some event to the app and to reduce the burden on the developer having to spend too much time implementing what needs to be done when certain events are captured.
Hope this makes sense.
i've a question for a feature, i want to implement.
I know some applications, like whatsapp, gmail or others, which run in background and notify the user, if something is received...
i'd like to do the same with my application. i've a http-network-connection and want to notify the user, even if he hasn't the application started. is something like this possible?
Is it possible, that a PopUp-Window, like receiving a sms, appears?
(if not, the notify-way in a titlebar is enough)
i've no idea, what i should google or where i can find help
Thank you a lot!
Edit: I found another very cool framework which deals with notifications. Have a loot at: https://www.parse.com/tutorials/android-push-notifications
You should take a look into Services. You can have the http connection listening in it. For the notification I'd use the NotificationManager class. A notification is much more less intrusive than a pop-up.
Hope that helps
Google Cloud Messaging will definitely help you.
If your server can instantiate this 'action' or 'event', by all means don't try to pull data periodically, coz that brings extra complexity to your app and also battery drain to your users.
But if you really, truly, badly need this behavior, you can instantiate a Service from your app's process. This can be done from many places, like your main activity or some other user action, or even from a broadcast listener. For example, our app has some parallel work to do, so we pass this to a service and that service is initiated by a broadcast listener listening for phone events like a phone call or sms.
On the other hand, just like the main activity of your app, your background service can be killed arbitrarily by the operating system any time. So you shouldn't depend on it running forever. You should have ways to check if that is still working in the background. Check alarm events or any other relevant broadcast listeners.
We want to implement a back end server [Java EE] for mobile application that sends notification to mobile on some events, I'm asking about the best/simplest approach whether Pushing or Pulling notifications, here you are my ideas/questions
1- The requirement is to send instantly the notifications to the mobile as long as the application is running no need to send if it's not running
2- I read that to push notifications to IOS or Android, I will need to connect to apple/google notifications servers, I felt that this is complicated especially that it requires low level socket programming, but based on number 1 and the project has limited time and budget, do we really need pushing ? and is it really complex
3- I read that pulling date may drain battery and consume data, but what if implementing a simple job on the mobile that runs only 3 or 4 times a day, invoking a simple web service on back end server asking for the notifications
P.S will be much appreciated if you can provide some tutorials for similar cases :)
1) If you're application is already running, is it connecting to the same location anyways? If so you might as well pull for the notifications at that point. However, if the app isn't actively connecting, i would attempt to avoid pulling.
2) Interacting with Notification servers on google and apple site directly, can indeed be a cumbersome task. However there are companies that have made this much easier for you. The advantage of using companies like urbanairship, xtify and mblox will get you started with sending push messages in minutes. (for an example take a look at http://developer.mblox.com/docs/ in the tutorial section).
3) depending on the data you try to present, end users now a days are used to instant data. I can't imagine a service whereby pulling 3 to 4 times a day is sufficient, however if your use case is truly limited to 4 times a day, and there is no other activity going on in the background process you create for this, you might as well have the background process running. But do think this through carefully... If at any point in time you want to increase the number of times a day you read, you might soon get to the point where a rewrite is needed to ensure end user satisfaction.
All I’m really looking for here is a little guidance. I’m trying to create my first official android app. I’m new to java/droid but not programming. Over the past month I’ve created quite a number of little experimental activities, services, threads and whatnot and they all function as planned. So now I’m trying to tie is all together but not having much luck.
In a new project I’ve compiled the guts into 'my.main.package' which runs a service that is constantly crunching data that other clients/apps can use… Well that’s my plan. For example, in this service is a custom thread/loop timer that is constantly counting. What would be the best way for any other apps to get a constant feed of this timer and other data as a listener could within its own sandbox and in the least taxing way possible?
I’m assuming one must implement aidl for IPC but I’m not sure if its needed and/or necessary as data from my.main.package is only outgoing, i.e. other apps only need receive/listen. I understand there needs to be some form of message handling or parcelable marshalling going on and possible permissions with aidl but I got to thinking that encoding/decoding a parcel or sending a message every millisecond would be very taxing. Is aidl the only way to go or is there a way to broadcast data as you can intent?
Any help would be greatly appreciated!
In a new project I’ve compiled the guts into 'my.main.package' which runs a service that is constantly crunching data that other clients/apps can use
A service should only be running when it is actively delivering value to the user. Users think that developers who create services that run all of the time are idiots and attack their apps with task killers, force-stops from the Settings app, etc.
Perhaps your description is just depicting your app in a poor light, but "a service that is constantly crunching data" is an anti-pattern. These are phones and tablets, not servers.
What would be the best way for any other apps to get a constant feed of this timer and other data as a listener could within its own sandbox and in the least taxing way possible?
The best way is for them not to be separate apps in the first place.
For example, in this service is a custom thread/loop timer that is constantly counting.
This is not adding value to the user.
I’m assuming one must implement aidl for IPC but I’m not sure if its needed and/or necessary as data from my.main.package is only outgoing, i.e. other apps only need receive/listen.
A remote service using AIDL is one way of doing IPC. It is not the only way. It is not even the most common way. You can also:
send a broadcast Intent
have the client send a Messenger to the service, and the service sends messages to the client via that Messenger
have the service update a ContentProvider, and have clients register a ContentObserver on the ContentProvider
I understand there needs to be some form of message handling or parcelable marshalling going on and possible permissions with aidl but I got to thinking that encoding/decoding a parcel or sending a message every millisecond would be very taxing.
IPC is "very taxing" in general. Hence, IPC should be avoided wherever possible.
In fact, IPC with AIDL is the only & the most effective way to do your requirements, I think. If you need one demo, you can take a look here. It's a simple example I wrote to learn AIDL & Binder on Android. Hope it could give you some brief for starting.