I am trying to make lock screen notification that asks users to release its lock when it is clicked.
Notification using NotificationCompat.builder works fine with lock screen of pins, patterns and password. But when lock screen is set with dragging, tapping notification automatically releases device's lock and do the work right away, not asking users to drag for releasing its lock.
My code looks like below
mNotificationManager = (NotificationManager)context.getSystemService(Context.NOTIFICATION_SERVICE);
mBuilder = new Notification.Builder(mContext).setSmallIcon(R.drawable.indicator_icon);
Notification noti = mBuilder.build();
mNotificationManager.notify(NOTIFICATION_ID, noti);
I tried depreciated API Noficiation() like below
Notification notification = new Notification();
notification.icon = R.drawable.indicator_icon;
mNotificationManager.notify(NOTIFICATION_ID, noti);
This works fine! (It asks dragging for linking to my application even when screen is locked by simple dragging)
So I guess there is a difference between two codes above. I cannot use notification since I need to set remote view.
The thing is the first code also works well on some devices like Galaxy S5, but not on the other devices like Galaxy Note 4. On the Galaxy S5, it does not release its lock by itself, but a little UI difference is made when I tap the notification.(such as not showing clock or other notifications)
Could anyone give me some advice?
I solved it! The problem was setting pending intents on the remote view not builder itself. Both works, but they act differently in the different settings of all kinds of devices. I guess it is safer to set pendingIntents on the builder itself, not the remoteview...
Related
I've integrated opentok ios sdk in my iOS 7 app, it is working fine, except this problem:
During video chat if I don't access iPhone for 5-10 seconds..then my app moves into background, causing viewer at other end to hear only audio. Video is disabled after app goes to background state.
I've observed same thing with their official example
https://github.com/opentok/opentok-ios-sdk/tree/master/samples/OpenTokFullTutorial
How can I avoid my app going to background while video chat is ongoing. Skype is working fine in this case, I want to achieve same thing.
What you want to do is prevent the iPhone from going to sleep. To do this, you cant try this:
[UIApplication sharedApplication].idleTimerDisabled = YES;
Here is iOS documentation on idleTimerDisabled
If you don't want the app going into background at all (like when the user taps on home button), you can opt to kill the app when it's not running instead of having it run in the background. To do that, check out iOS guide on opting out of background execution
If you do not want your app to run in the background at all, you can
explicitly opt out of background by adding the
UIApplicationExitsOnSuspend key (with the value YES) to your app’s
Info.plist file. When an app opts out, it cycles between the
not-running, inactive, and active states and never enters the
background or suspended states. When the user presses the Home button
to quit the app, the applicationWillTerminate: method of the app
delegate is called and the app has approximately 5 seconds to clean up
and exit before it is terminated and moved back to the not-running
state.
Hope that helped!
Before iOS7 came, we noticed an issue:
Music remote-control from earbud or springboard can hijack our audio session even if we set the category to solo-ambient or another exclusive mode.
We thus tried a few things:
We tried to take ownership of the audio session back. But this requires that our audio code knows when to take it back and from whom. We thought we could let the app code become the first responder to remote-control events, do our stuff, and then pass the events on to the music app. However, we found that the events got detained by the first responder and there is no way to push it back to the chain of commands.
We tried to become first-resonder and block remote-control events all together when we are in solo-ambient. This worked fine with iOS6, still works with earbud control in iOS7, but fails with iOS7's control center. The control center seems to bypass the remote-control event handler remoteControlReceivedWithEvent completely, where we put our blocking code.
I read something elsewhere that:
You can't block the music app. your app can become one though (apple
won't like that) and then the control center would control yours.
But I found no documentation whatsoever about control center.
And as said above, control center does not enter the normal remote control hooks even if an app is the first responder.
Another quoteP
Remote Control Event handling is so your app can be controlled by
Control Center, the earbuds, etc... it is not so that your app can eat
said controls, preventing control of other apps from said sources. It
only worked in iOS6 because of a bug in iOS, now fixed in iOS7
Is it that what had were using was due this bug? I find it hard to believe because we got the solution on this list and the Xcode mailing list so I assume that was an accepted solution.
Now we really wonder if we are missing something from the very beginning:
Is solo-ambient really an exclusive mode for audio session or is it that music app is an exception to that exclusivity?
How can our app live in harmony with the remote-control, and control center?
Where can we find up-to-date documentation of remote-control and control center?
The remote control has been mysteriously fixed after clean building everything agains iOS7 SDK. Now app delegate can receive remote-control events from Control Center. However, the play/pause events are UIEventSubtypeRemoteControlPause and UIEventSubtypeRemoteControlPlay instead of the iOS6's UIEventSubtypeRemoteControlTogglePlayPause.
I'm building a Windows Store app and it pops up toast notifications from time to time. I also have an animation that plays to show when something has updated. Both of these happen at the same time.
What I would like is to not show the toast when the app is running.
So, is there a nice easy way to determine this or do I have to manually track the state via the suspending/resuming events?
Edited info:
The solution has a background task project which goes off, gets the data, then decides if anything has changed that the user needs to know about.
If so, it creates a toast, updates the tile badge, and plays an animation to fade in the new data.
The issue is that I don't want to show the toast and update the tile badge if the user has the app full screen. Similarly, playing the animation isn't needed until the app is resumed (that's the easy part though).
I realize I could solve it by having one timer that works when the app is running, and a separate background task for when it's suspended but that seems like overkill in this case.
The simple answer here is that if your app is suspended, your code won't be running.
If you want to pop up toasts when your app is suspended, you'll either need to use the WPNS or a background task to track changes.
I am making an app where I need to know
every button that was ever pushed by the user in the app, and when it was pushed, and
where the iPhone has gone (using gps), but there are no cell towers in the area so I can't use that significant location changes method everyone uses.
It seems to me like the Plist method for data saving won't work because I don't want the app to start where it left off, I want it to start at the beginning every time.
Also, if any of you have any idea how I can make my app wake up at certain specific times, and/or how I can make it impossible to exit, that would be awesome. This is for an experiment with the University of Queensland St. Lucio Psych Department and the Grute Eylandt Aborigines.
You can know everything the user does in your app if you want. You could use your own solution with an SQLite database for example, and dispatch the data to a server every once in a while.
The GPS is also easy, you could just track the user with the Core Location framework.
You can't make the app wake at specific times, the best you can do is implement push notifications but it's up to the user to open the app via the notification or by themselves by tapping the app icon on the iPhone home screen.
Otherwise you could set up a local notification just before exiting the application, this is faster and easier to implement then setting up push notifications.
There is also no way to stop the app being closed, that is until iOS 6 comes along with it's accessibility features, you can disable the home button then. But not now.
The UIApplicationDidBecomeActiveNotification and UIApplicationDidBecomeActiveNotification notifications do not seem to be called when the app is only briefly closed.
Specifically: when the app enters the foreground it should check to see if any settings in the settings app were changed. If you go right to the settings app, change something, and come right back, the notifications are sometimes not sent. After closing and reopening the app again, they are called and everything is ok.
Is there a better way to consistently detect when the app enters the foreground? or could something be causing a conflict and keeping these notifications from being sent?
Rather than trying to catch every foreground transition, just watch for changes in the settings, no matter how they happen, by watching NSUserDefaultsDidChangeNotification. See How to get an update NSUserDefault on iOS 4?