I am using the 'location' UIBackgroundMode to receive GPS background updates when the user presses the Home button. As a result, if the app is left in background mode overnight, the battery is consistently dead the next morning. I have told the locationManager to stopUpdatingLocation, but to no effect.
I understand Apple doesn't want developers to use exit - in fact it seems to have little effect on the app other than to take it to the background - but I can't afford to have the battery die if the user doesn't end the app.
Any suggestions?
Maybe you could register for a local notification that informs the user they should open the app to stop location tracking? It's not very elegant of course, it seems Apple should allow the developer to register for location updates for a specified length of time, maybe you could submit a feature request for that. I think Loopt monitors for 24 hours and then quits, maybe you could research into how they made it stop after 24 hours. I wish I could help more but I haven't messed with the location framework at all.
You could use a timer and/or background task, which would run after a set amount of idle time, and try to turn off the GPS then. So you can still have location tracking in the background of your app, but after 10-20 minutes, it turns off.
Related
I wanted to know how to make a service like WhatsApp, the service won't die after 1 minute, it will display a notification that is updated every 12 hours or every 1 minute (the user chooses it in the app).
How can I make the service where the message can be rejected, and the service will not die but will display another notification after a while?
I tried to use foreground. Is it the right way? I'm not sure, because according to the developers site, the foreground must display notifications all the time. I don't want that.
What should I do? Thank you for any help
I am creating an app that shows bus schedules from my nearest bus stop. However if I am traveling between many busstops it seemes like the app stops to transfer data to my watch extension.
I think this is a issue because of the limited background time watch applications has. A better solution may be to check if the device is moving when the CLLocation manager launches the location delegate function, and if the device is not moving then update the complication because the user has moved to a new permanent location for a while.
Is there anyone that know if my assumption is correct? Or do someone else have a better idea?
I am starting to get familiar with Azure Media Services and I wanted to see if anyone had some thoughts on live events and start times.
We offer a paid live event, so via our web application, users can join the "presentation" up to 30 minutes before it starts.
In azure, we typically start the channel 1hr beforehand to get everything set up, and start the "Live Event" at the exact start time. What is the best practice for showing a "this presentation will begin shortly" message and auto-starting the feed when the event starts?
Is it best to start the "Live event" 30 min early, and use a slate, or can the Azure Media player basically sit and wait for the event to start? Does this happen automatically, or would I need javascript to keep trying when OnError happens? Basically, I don't want users to have to refresh the page or anything when the even starts. It should just start playing right at the start time.
I'll take a stab at this one Chris.
For most live events that are produced by our customers (including Microsoft Studios here on campus), we typically start the channel about 20-30 minutes prior to the event time with a slate and music. Usually that slate is coming from the encoder rather than from a slate on the live channel in Azure Media Services. Reason for that is there is a lot more control locally in the production pipeline for animated slates, music, fading and switching, etc. You can achieve this with low cost options like Telestream Wirecast, or a NewTek Tricaster setup.
n azure, we typically start the channel 1hr beforehand to get everything set up, and start the "Live Event" at the exact start time. What is the best practice for showing a "this presentation will begin shortly" message and auto-starting the feed when the event starts?
We then monitor the Preview feed URL from the Live Channel in Azure just to make sure everything is operational and running correctly. When it is close to showtime (5-10 minutes or so ahead), we will start the recording (Start a new Program). This is not automatic, but you could certainly use multiple methods to automate the calling of the API to create, start, and stop the Program via our REST API or client SDKs.
To your point, the new Program creation will generate a new Program URL for playback. Your users or web page code would need to refresh. If you have a requirement that the users are going to arrive really early, you could either start the Program recording a lot early and publish that URL - but you would then want to use our Dynamic Filters or Subclipping feature after the event to remove the long slate at the head of the event.
Another trick could be that if you automate the start of the live Program recording, you could also use SignalR or some other out-of-band notification to signal the player in the page to reload the src URL and begin playback. I've seen that trick used before as well.
Hope that helps. Bottom line, there are a lot of creative options, but nothing "built-in" and automatic at this time.
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us an example?
I'm getting a lot of reports about a problem with delayed notifications from people using my timer app on windows phone 8.
http://www.windowsphone.com/en-us/store/app/timer/38ac6043-0d3e-471a-9527-a20d1ef8521b
There was always the problem that Alarms added to the ScheduledActionService aren't very accurate. I fixed the problem when the app is running by adding and removing a dummy alarm shortly after the real alarm counted to 0. This "woke up" the ScheduledActionService, it checked for expired alarms and showed the notification. This behaviour changed with WP8.
My little hack doesn't work any more and a lot of people seems to be quiet frustrated about it. I also got feedback that sometimes the alarms don't work under the lockscreen at all. Sadly I can only reproduce the first problem on the emulator. Has anyone experienced similar behaviour?
Is there any other possibility to tell the ScheduledActionService to check it's alarms?
Is it possible to hide my app in the store on WP8 devices up to the time when I corrected this behaviour?
regards,
Christian
I ran into a similar problem. I created a basic voice enabled timer app. The problem I had was if someone sets the alarm to go off in 20 seconds and I create that scheduled action well its not going to work for one minute.
"Alarms and Reminders are accurate only within a range of one minute. In other words, the notification can be launched up to one minute after it was scheduled." -msdn
I know you know this but I thought I would include it for others reading. I ended up initially creating all alarms via a timer in code and if the user exits the app only then do I create a scheduled action. If the user tries to close the app and there is less than one minute remaining I show a message box I don't remember the exact warning but its along the lines of the phone cannot show the alarm for one minute after exiting the application.
Maybe you could split the options up for the user?
an accurate timer that only works when the app is open and you can control in code down to the second, and a more generic timer that works outside of the app that would only allow one minute increments.