I'm am writing a WinJS app that deals with data on the clipboard. I see you can use
Windows.ApplicationModel.DataTransfer.Clipboard.addEventListener("contentchanged", function (event) {
to listen for changes to clipboard. But if your app is not currently in focus, you get the error message
WinRT information: The clipboard could not be accessed because the application is not in the foreground.
How do you detect if the app is currently in focus? Also, is there an event or method to detect when it comes back into focus? For instance, say I set an internal variable that the clipboard changed when the app lost focus, and should check the content on return?
The window.onblur event will tell you when the app loses focus; window.onfocus will tell you when it has the focus again. (There also the visibilitychange event on window/document and their visibilityState property that you can use to know if the app is visible but without the focus, as when sharing the screen.)
Scenario 4 of the Clipboard app sample in the Windows SDK shows how to use blur and focus events to manage calling the clipboard's getContent method at appropriate times.
Note also that because the contentchanged event comes from a WinRT object, be sure to removeEventListener if you're not going to be listening to the event for the entire lifetime of the app. That is, if you might possibly call addEventListener for this event more than once, neglecting to remove the listener will cause a memory leak.
Related
I have a group email app where customers create emails in a standard iOS compose window. If they write a long email, then switch apps to do a memory intensive task, iOS may close the compose window, losing the contents of their email.
Is there a way to prevent the window being closed? or a way to ensure iOS saves the email to drafts before closing it?
I am wondering if I am not retaining a link that I should be, perhaps?
Can anyone else confirm whether they see the same problem?
The best way to do this is to understand the App Life Cycle on iOS.
When the App is running in background, the method applicationWillTerminate will be called, this is one of your options to save the content of the email. But this method is not called every time, it is only called when your app isn't suspended or when the user reboots his device.
One solution is to save this data inside the method applicationDidEnterBackground, it is called as soon as your app starts to run in background. And reload the data inside application:didFinishLaunchingWithOptions, this allows you to perform any final initialization before your app is displayed to the user.
Is there a way to prevent the window being closed? or a way to ensure iOS saves the email to drafts before closing it?
There's nothing you can do to prevent the window from being closed, because iOS is killing the app. What you can do is to save the email at some point before that happens. Since the user obviously can't modify the email while the app is in the background, saving the message when the app goes into the background would be a good choice. That way, you'll have the data saved if iOS does end up killing the app, and you can check to see if there's a saved message that needs to be restored when the app launches.
If you take that approach, though, you'll also have to figure out a way to help the user get back to their saved message, which means that you also need to keep track of how they got there in the first place so you can recreate that state. If it's just a simple message, maybe all you need to do is to open a message editor view and set it up with the saved message. In general, though, this can be a thorny problem. Luckily, Apple has provided a nice solution...
The View Controller Programming Guide for iOS has a section called Preserving and Restoring State, which explains how you can set your app up to automatically save and restore its state. With a relatively small amount of work, you can set your app up so that the user will never even notice that the app has restarted -- if they launch it after iOS has killed it, the app will recreate the view controllers so that it looks like the app was running the whole time, even if the device was shut down in the interim.
I'm making a simple app with a Today Widget extension that logs events.
The user can tap a button in the app or the related Today Widget to log an event. These events are saved with Core Data any time the button is pressed either place.
Whenever a new event is logged in the app, I run a function called updateLocalNotificationsFromCoreData(). It handles the setup of UILocalNotifications based on the most recent event in Core Data after clearing the appropriate existing notifications.
However, when a new event is logged from the Today Widget, I can't use this function because I need to register the Local Notification with UIApplication.sharedApplication().scheduleLocalNotification(), and UIApplication is not available in the Today Widget extension.
I realize I'll probably need do something unconventional or hacky to get this working, so I'm trying to evaluate possible approaches and come up with a relatively robust solution.
Basically, I want to find a way I can call my
updateLocalNotificationsFromCoreData() function right away any time a new event is logged.
If I can't do it every time an event is logged, an alternative would be to trigger the updateLocalNotificationsFromCoreData() function periodically (somewhat frequently) another way. Here are some solutions I was thinking about using, but I don't like any of them:
Do it in AppDelegate when the app is launched (or another state change)
One approach I'm thinking about is running my updateLocalNotificationsFromCoreData()function in AppDelegate somewhere, like didFinishLaunchingWithOptions.
The downside is that it would require the user to open the app periodically. If the user didn't open it much the notification behavior would be inconsistent. I'd prefer a solution where a user could interact with only the Today Widget and reliably get Local Notifications without ever opening the app.
Sync the events to a server and use Push Notifications
I've thought about syncing the data in Core Data to a server, then setting up Push Notifications to the user's phone based on that.
I don't like this, because I want the user to still be able to get notifications without an Internet connection. It also introduces a lot of extra overhead of syncing the data with a server.
Ping a server, and send a content-available Push Notification
When someone logs an event with the widget, I could ping a server. That server could send back a silent content-available push notification to trigger the app to run updateLocalNotificationsFromCoreData() in the background.
I found a similar question (Scheduling local notification from within a Today extension) where one answer proposes a similar solution. Unlike the previous solution, an Internet connection is not needed to receive the notifications, but an Internet connection would be required to make sure the notifications are up to date when a new event is logged.
Background fetch
I thought about using Background Fetch to fetch something arbitrary from a server, then run the updateLocalNotificationsFromCoreData(). This would be a way to trigger the update in the background, although it seems silly to fetch data if that data isn't being used, and seems like something for which an app could be rejected. There also seems to be a risk of the system not calling the background update regularly if the user doesn't open the app much and mostly uses the Today Widget.
Use background location updates
This seems like the dumbest approach, but I thought I would mention it anyway since I thought about it. I could use one of the low accuracy background location update modes to trigger updateLocalNotificationsFromCoreData().
It would require the user to allow location in the background, which would be hard to explain. And, it would require the user to at least move around a few blocks to trigger the function, which could provide an inconsistent user experience. Also, it would increase power consumption of the app for a silly reason.
I'd really appreciate fresh ideas about how I might be able to reliably schedule local notifications when Core Data changes on a device that doesn't have an Internet connection!
Or, if that doesn't seem possible, I'd appreciated feedback on which approach seems to make the most sense.
EDIT: I came up with a new solution. It's not ideal, but I think it's better than these other approaches I was considering. When someone taps the button to log the event, I launch the full app. It's annoying because I have all the data I need at that point to give the user feedback and log the event within the Today Widget without launching the app, but by launching the app I have the opportunity to check and schedule local notifications.
Also, in iOS 9 the annoyance on the user is slightly minimized because the system-wide "back" button will appear and let the user go back to the previous app easily once my app has launched from the Today Widget.
In the future I may try a solution where one of the server-based approaches above is used when an Internet connection is available, and I would then fall back to this system of opening the app only when the network connection is not available and I need to schedule the local notifications within the app.
i have database in my app and i want to delete all information from database when user force quit from app. I looked this question Which Event When i close app in iOS? , but when the user click home button, app has force quit in applicationWillTerminate.I don't want to close my app. I just want to catch close event in my app.
Sorry for my bad english.
Thanks for advice and interest.
the OBJC runtime will shut down without any final notification
BUT
you can write a posix signal handler to get the signal. but note that since the runtime is already shutting down it is unsafe to do much work here.
see e.g.:
http://chaosinmotion.com/blog/?p=423
You can't. The last notification you get that you can be sure of is a didEnterBackground when you get switched to the background. After that, you will likely be killed silently, either from memory pressure or from the user force-quitting you.
I want to trigger a remote control event such as UIEventSubtypeRemoteControlTogglePlayPause programatically. The application that I have in mind is a voice remote control application (even if it already exists) which receives the command "Play" and it simply generates the event UIEventSubtypeRemoteControlTogglePlayPause. Any app registered as the first responder for this event will get it. I.e. my app simply translates voice to remote control commands.
Ideas?
It's not possible to generate UIEvents programmatically.
You can do it by using private API (google synthesize UIEvent). Some testing frameworks do that. Also, for testing, you can inject Apple's UI Automation framework into the application and use its method to generate events (mostly touch events, headers available on github).
However, synthesizing events is something you can't do in an Appstore application. If you need to do that, it's a bad design.
From Apple's Push Notification Guide:
If the target application isn’t running when the notification arrives, the alert message, sound, or badge value is played or shown. If the application is running, iOS delivers it to the application delegate as an NSDictionary object. The dictionary contains the corresponding Cocoa property-list objects (plus NSNull).
I have implemented this in my app and everything works fine. If the app is in focus, the app gets the message directly. If not active, an alert is shown, the app launches when the user clicks the alert, and finally the app gets hold of the message.
Would it be possible, however, in the case of a message arriving when the app is not active, to get iOS to activate the app and pass the message on without showing any message or requiring any user interaction?
I would like this behavior because the push message from my server only might be of interest to the user, depending on her current position. The app works like this: When it starts, it registers for push and tells my server: I am at this position and would like to be notified when something interesting happens near me. At a later point the server sends a message, but since the user might have moved from the area, I would like the app to check the user's position again, and not bother the user if she now is too far from the original position.
I suppose it would be possible to have a background service that notifies the server about the current position every n minutes, but I fear that this will drain the battery.
Any thoughts on this?
Unfortunately, you can't — in iOS — directly open your app when a notification is received. The user must choose himself to open it via the alert displayed by the system.
However, using the background location is not that battery-unfriendly. It depends on the location accuracy you set for your CLLocationManager object.
All the informations about location accuracy can be found here : Location Awareness Programming Guide
In your case, you may want to use the significant location changes methods or the kCLLocationAccuracyKilometer accuracy for example.
Here is a good tutorial to get started : iOS Multitasking: Background Location
Hope this will help.