For an augmented reality app, I must record screen and camera simultaneously. I found apps that record the screen while I run my augmented reality app. However, I couldn't find apps that record a video from the camera while letting my augmented reality app work normally as both these apps need to use the camera simultaneously.
Related
This is regarding the functionality of Google Chromecast. Consider a scenario where I'm playing a YouTube video in my Android mobile. I've an old TV to which I've attached the Chromecast dongle. The TV and my mobile phone are in the same WiFi network.
What I understand, when I tap on "Cast" icon in YouTube app of my mobile, it sends a request to YouTube server to stream media to my Chromecast dongle (which is already registered). So, basically, it is not streaming directly from my mobile phone. From my phone I'm instructing YouTube to send media to one of my other registered device. This explains why the video continues to play even if send YouTube app to background.
My question is, if that is the case, then why is it necessary to have Chromecast and my mobile phone to be in the same Wi-Fi network? I can send "Cast" request from my office network and YouTube should start streaming videos to my TV connected to home network. What am I missing here? Thanks for your help!
You are sending some meta information about the video you are watching to the Chromecast and the Chromecast is fetching and playing the video from Youtube. In the most home setups Youtube would have no chance to connect to your Chromecast and send a file to it.
So for your devices to exchange these meta information they need to be in the same WiFi network.
First, there is the discovery task which, based on the methods used, requires being on the same network. More importantly, the model is to cast content to a TV and doing that when you are not in front of a TV doesn't really make much sense, at least in the large majority of the cases (there is no point for me to cast something to my home TV when I am at work). As was shown at Google I/O this year, we will support a case that a "guest" can participate in casting without being on the local network but that would also requires proximity to the cast device.
In WP8, if we set
ApplicationIdleDetectionMode = IdleDetectionMode.Disabled
the app continues to run even when the screen is locked.
If, for instance, we have a WebBrowser in an app (which is actually active only when the app is in the foreground), and the above property is set as disabled:
Will the WebBrowser continue its execution even when the screen is locked (for example, playing an audio file).
Will the WebBrowser continue its execution even when the app is switched to the background.
Thanks.
As for running under lock screen - yes it should run, you can get more information from MSDN.
As I have tested once, WebBrowser is using BackgroundAudio to play (audio element), so it should also play under lock screen and probably in background (thought you should test it).
When the App goes to dormant state - all its processes are stopped MSDN:
When the user navigates forward, away from an app, after the Deactivated event is raised, the operating system will attempt to put the app into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory.
You should also watch out for Certification requirements, when usind AppIdleDetection - point 6.3 – Apps running under a locked screen.
I have to create a Background Task which should run after every 1 minute and should call a Rest service to update the Mobile longitude and Latitude Location. The rest service for this purpose have been written all I have to do is to write a Task in my existing application which should perform this update. Can you guys please tell which is the most easiest way to implement this functionality.
Thanks,
There isn't a concept of a service like exists in Windows Desktop. Applications are running, or not on the phone. One application on the phone, tracking location, can be running in the background while other applications run.
If your application is in the foreground, you will just directly call the web services with updated location.
You can use a scheduled background agent to periodically update location, but it is likely that it won't update frequently enough for your needs.
MSDN has details about how to create an application that actively tracks location in the background, subject to some important limitations, and reasons the application may be deactivated:
The app stops actively tracking location. An app stops tracking location by removing event handlers for the PositionChanged and StatusChanged events of the Geolocator class or by calling the Stop() method of the GeoCoordinateWatcher class.
The app has run in the background for 4 hours without user interaction.
Battery Saver is active.
Device memory is low.
The user disables Location Services on the phone.
Another app begins running in the background.
In addition, there is a complete tutorial available for this scenario.
I'm in the process of developing a WP8 app that makes use of the background location tracking abilities provided by the OS. The idea is to monitor the users position and to notify them when they are near certain types of places.
So far it all seems to work fine and when running the location tracking works as I would expect.
The problem is, it seems that the phone times out background apps after around four hours, stopping the location tracking.
I can understand why Microsoft did it, to preserve battery life etc. But there's not much point having a background location tracking app that has to be manually restarted every four hours! If a user chooses to run this app and is made aware of the potential battery hit, surely it should be able to run indefinitely - to a point of course, if the system runs out of resources or similar then that's fair enough.
Does anyone have any experience with this? There must be hundreds of others apps in the store that have run into this issue I would have thought? And presumably there must be some way of keeping the location tracking running?
I've tried periodically updating the live tile (using a DispatcherTimer) while the tracking is running but this doesn't seem to be enough to keep the app alive either :(
Anyone have any ideas?
Thanks.
There is no way to achieve your desired behavior. The app will be deactivated under anye of following conditions:
The app stops actively tracking location. An app stops tracking location by removing event handlers for the PositionChanged and StatusChanged events of the Geolocator class or by calling the Stop() method of the GeoCoordinateWatcher class.
The app has run in the background for 4 hours without user interaction.
Battery Saver is active.
Device memory is low.
The user disables Location Services on the phone.
Another app begins running in the background.
Source: Running location-tracking apps in the background for Windows Phone 8
What you could do is to show a toast notification before app is deactivated advising the user, and make him navigate back to the app, extending the period for other 4 hours that way.
There is no way to keep it running without any user interaction.
I am developing a game using PhoneGap iOS. I integrated Ads in it using Mobclix as well as iAds. Also I integrated Flurry in the game for analytics.
But after integrating Ads in the game I am facing some performance issues in the game on some devices. They are as follows :-
Ipod touch :- Slow response to touch events, Animations are too slow, Rendering has become slow.
Iphone :- Animations are slow but better than Ipod touch.
It works fine on Ipad.
I have used PhoneGap to port our HTML5 code on the devices.
I checked Removing the Ads and Flurry Code then game runs Fine. I also searched extensively for this problem, but couldn't find a suitable answer. Looking forward to getting some help, here.
I've noticed (from first hand experience) that the Flurry HTML5 SDK can slow your app down, massively. It communicates with the server by inserting SCRIPT tags into the HEAD section of the DOM, which has three drawbacks that I can see:
Some browsers (e.g. mobile Safari on iOS it seems) will wait for HEAD scripts to resolve before running any other scripts
If you make multiple Flurry calls, you'll soon reach the browser's concurrency limit for multiple downloads from the same server, since each call creates a new SCRIPT tag.
The script tags are never removed, so the DOM keeps growing.
One solution is to try the native Flurry SDK for the phone(s) you are targeting, but that's not an option if you are supporting browser WebApps, and increases your development time & download size for native apps.
I find it pretty shocking that the Flurry HTML5 SDK is so inefficient. Back to Google Analytics I guess.