I wanted to ask a question you have to see if I can help.
I've started working on a (Android) application that should display a message on the android device. This message should be Push notification type, as would be when we get a whatsapp, with the only difference that this message does not come out, but will be a sort of alarm, since the user will mark what time to leave this notice.
And want to know what kind of message should work, and if it's with Push notifications, if they know of any conditions or any manual tutorial, because I've seen so far the only thing that has made me lose more.
Thank you.
I think you don't need Push Notification but AlarmManger and NotificationManager samples.
http://androidideasblog.blogspot.co.uk/2011/07/alarmmanager-and-notificationmanager.html
Related
I read all the answers but I couldn't find the right answer. All I need Is to generate five notifications when the special dates (which is stored in my Database) come.
I won't paste my code here because it is a lot and it's doesn't work, but this is the tutorial I used. http://blog.blundellapps.co.uk/notification-for-a-user-chosen-time/#comment-17214. The problem is that in this tutorial is shown how to generate only one notification and after the phone is rebooted the notifications don't come.
I will be very thankful if someone helps me :)
I'm developing an app that runs in the background that essentially snaps a front facing photo every time the phone is successfully/unsuccessfully unlocked. This isn't an original idea, but I'm developing it as a final project for my college android programming course, with no intent to sell this app. I have a general idea how I am going to go about this via some research but I keep running across a problem.
I know that it is hard and bad practice to run an app continuously in the background, so the idea is you put the app to sleep and set an alarm. My problem is that if the would be phone-snooper were to get really lucky, they could access the phone in between the alarms, and the owner of the phone would never know. I talked with my professor, and he proposed a couple ideas, but we could not come up with a definite solution, so I'm asking opinions here. Any idea how to subvert this dilemma? Thanks a ton.
Your approach is probably not appropriate for the problem. You can't "time" unpredictable events (like someone attempting to unlock a phone). Or else it's not clear how you are setting the alarm.
You should change the approach to an event-based approach.
Either provide a service for a lock-screen app so that it can use your code to capture a pic by sending login attempt events to it. You write that and provide an SDK/API.
Or else create your own lock screen app with your feature:
https://stackoverflow.com/questions/10864300/create-a-lock-screen-of-my-own
I am developing an Android app that allows sports team coaches to update the attendance for events like training/matches. A feature I would like to add would be to display a notification on the device to remind them that they need to update the attendance for the event when it has started.
I have been reading online a bit and it seems that push is the preferred method for data that is changing. But because i know the start times of the events, would it be better to create a background service using something like the following?
https://stackoverflow.com/a/9933130/2039505
I basically want the user to receive a vibrate notification which when they click on it, it will open the events attendance screen. Hopefully someone will have some insight into which option is best!
Since all you need is a notification on a timer, the AlarmManager would be the best way to go.
If you used Push Notifications(GCM), that would require server side code and a method to store the device id to send the notification to.
Overkill if you ask me.
Here are links to the official documentation and example code:
Official documentation
Vogella's example on services
I'm using Push Notifications in my application and have noticed that if around 50+ notifications arrive the draw stops displaying any new notification that may arrive.
This situation should be rare within my application but its still possible and I'm trying to find out more information about it (since I can't find a mention of a limit anywhere) and the best way to deal with it (so far I'm thinking using SQLlite and storing the overdraw notifications and showing them when the user dismisses a notification).
Please do not show "50+ notifications". Please show one Notification, updated perhaps to reflect 50+ events.
This is covered:
in the design guidelines (see "Stack your notifications")
in the API guide
in the Android Wear documentation (as people with Android Wear devices will get severely pissed at you for flooding their watch or whatever with 50+ notifications)
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.