How can more than five touch inputs be handled simultaneously on Windows Store Apps using C# and XAML?
Different approaches have been tried, including this from MS: http://msdn.microsoft.com/en-us/library/windows/apps/xaml/jj150606.aspx
Does any one know an approach to handle more than five?
The five touch limit is most likely a hardware limitation. A touch screen has a dedicated processor to process the large amount of capacitance data. This processing results in a list of touches, and their respective locations, which is sent along to the operating system for handling.
In Apple-land, small iOS devices (iPhone, iPod) have a 5-touch limit, while large iOS devices (iPad) have a 10-touch limit.
Related
I have developed a voice recording app using WasApi for Windows Phone 8. But users are facing battery problem a lot and also the screen is not getting timeout while the recording is on.
And if users press the lock button on background recording is getting paused. Can anyone tell me how to solve these issues?
I am unaware of a way to turn off the screen while recording, or of a way to record while the application is in the background. That does not mean it's not possible, only that I don't know how. It may not be possible now, but become possible in the future. Other answers may explain how to do this.
So I'll list ways to reduce battery consumption while your application is running in the foreground and the screen is on:
Black display. Bright images require a lot more power than dark ones. Depending on the display technology, black pixels require a lot less power than dark pixels. Look at the Lumia Glance feature which can be always on and still requires days to drain the battery.
No animations. Depending on the display technology, redrawing the screen may require more power. In any case, calculating the animation to be drawn on the screen prevents the CPU from sleeping. Having an animation that only updates every second instead of every 15 milliseconds should already be a big improvement.
No wait loops/busy wait. If the CPU needs to wait for something don't use this pattern:
while (true)
{
if (arewethereyet())
break;
}
Cluster work into batches. The CPU needs to be able to sleep and ideally it needs to be able to sleep for long continuous periods of time. Use a long buffer duration for the microphone and don't fetch the buffer too aggressively.
While attached to debugger it runs just fine. The Periodic Task is invoked and runs over and over, but when I deploy it to my device It seems to run 1-2 times and then stops.
What It does is setting the live tile background image from isolated storage. The images are created in the application and then saved to isolated storage. As mentioned it works well while attached to the debugger.
The only constraint I could think that could break it would be the memory cap. The application creates and saves 40 images of ~25kB each, and that isn't 1 MB! The application is maybe <4 MB, so that is 5 MB... a lot less than the 11 MB minimal requirement.
So it can't be the memory cap kicking in. Two consecutive unhandled crashes should also break the task, but I've thrown all the code in the task's OnInvoke() in a try/catch.
Now I'm out of ideas what stopping my periodic task when running without being connected to visual studio running in debugger. Any clues?
Firstly are you using Windows 8.1 phone by any chance? Since there is an issue with Periodic tasks do not run on windows phone 8.1 devices as you can see on this forum
Background agent can’t use more than 6MB of memory. You can get the current memory usage using the following snippet :
var memory = DeviceStatus.ApplicationMemoryUsageLimit
- DeviceStatus.ApplicationCurrentMemoryUsage;
automatically executed by the OS each 30 minutes
the operation can’t exceed 25 seconds per run
if the phone switch to battery saver mode the background agent may not be executed
on some devices only 6 background agents may be planned simultaneously
agents can’t use more that 6MB of memory
agents have to be re-planned each 2 weeks
an agent that crashes two times is automatically disabled by the system
Periodic tasks are unscheduled after two consecutive crashes. You need to make sure that this doesn't happen (check internet connectivity if required, set a timeout on web requests, etc.).
You should place your code in a try/catch block and log exceptions in the Isolated Storage to see what happened afterwards.
Here is the list of constraints that apply on scheduled agents (MSDN): Constraints for all Scheduled Task Types
Here is also a series of blog posts that could help you: Windows Phone: Background Agents Pitfalls
Have you actually measured and logged the memory that's being used? What you're saying isn't very correct:
When the background agent starts it has already taken 5-6MB to load what it needs from the .NET framework.
If you mean that the compressed files are 25KB each, you should know that the images in the memory are not compressed (at least not that much).
There are two things you can try:
Use this property and check the peak memory usage: DeviceStatus.ApplicationPeakMemoryUsage. Write it to some file (maybe every 5 images or so) and check if it's okay. Paste the results, please.
Note: When testing the memory usage, it's best to build the app in "Release" and run it without debugging on a device. That's most accurate. There are some minor variations, so you should run the agent several times to be sure it's working within the limits. You can force start it from the app using ScheduledActionService.LaunchForTest.
Also, I'd suggest you subscribe to the Application.Current.UnhandledException event and mark all exceptions as handled (and log them, so that you can fix them). That's for extra safety.
P.S. When the background agent stops executing, is it "blocked" in the list of background tasks on the device?
I have an issue with background agent execution in Windows Phone 8.
After a successful agent registration it wasn't executed by OS.
I waited 5-10 days - no effect.
The issue is reproduced ONLY on two test devices (lumia 920 and htc x8).
All other devices shows normal agent execution log (about 5 other devices).
You can find the sample by the following link:
https://dl.dropboxusercontent.com/u/19503836/2013-12-19%20TestApp_Release_AnyCPU_v1.2.xap
XAP:
https://dl.dropboxusercontent.com/u/19503836/SimpleAgentApp.zip
App registers clean agent and tracks agent launches
App user interface displays that log
no extra logic
no time/memory consumable operations, it is almost clean project
device battery level is over 50% all the time
battery saver mode is disabled
device has Cellular and Wifi access all the time
device is used frequently
it seems that other background agents are also not executed by OS
What could be wrong with background execution in system?
How can I diagnose the issue?
I'm trying to find the issue for several months without any luck.
It turned out that those devices had some OS issues.
One test device was fixed by a hard reset and another one by a firmware update.
What is the application memory usage limit of windows phone 8 application, I need memory limit for the three different devices available (like 720p, WXVGA etc)
The zen of WP8 memory caps has three aspects: default baseline (150MB+), extended memory (180MB+) and low-memory device opt-out (300MB+).
Baseline:
By default all apps (D3D, XAML and XNA) on WP8 have at least 150MB which is up from 90MB on WP7. The increase from 90MB to 150MB is done to accommodate the extra memory needed for more detailed visuals on HD displays.
Extended Memory Caps
Apps can also ask for additional memory by specifying ID_FUNCCAP_EXTEND_MEM. When asking for additional memory you're guaranteed at least 180MB on all devices. When asking for additional memory your app may actually get all the way up to 380MB memory on high-memory devices.
Low memory device opt-out
Apps can also opt-out of low-memory devices (512MB RAM) by specifying ID_REQ_MEMORY_300. That guaranteed your app will only run on high-memory devices (more then 1GB of RAM) and with at least 300MB of memory.
The way you should think about "high memory devices" is that it's just like having an optional sensor (Gyroscope, Compass, etc) or any other optional hardware (NFC, etc). Don't assume users have this extra memory unless you want to limit the distribution of your app considerably. Public statistics show that low-memory devices sell pretty well and you shouldn't disqualify your app from those devices unless it's an absolute must.
App memory limits for Windows Phone 8 (MSDN)
Is it possible, say, using a programming language like C or C++, to write a program that directly interacts with the power inverter or controller in a modern LCD monitor?
I'm told that it used to be possible to forcefully overclock the oscillator in a CRT to make it catch on fire. I'm curious as to whether the same principle can be applied to a modern monitor.
Being able to inflict real damage on a modern external monitor is highly unlikely.
Connections like VGA, DVI and HDMI don't provide sufficiently direct access to the screen's hardware.
The hardware design of a consumer product can be considered flawed if it allows a killer poke, i.e. destruction of a hardware component by issuing
software instructions.
In modern PC hardware, laptops have a tightly integrated display. It may be possible to write a program that has harmful effects on a laptop's backlight,
e.g. by flicking it on and off rapidly by calling the ACPI interface.
From http://ibm-acpi.sourceforge.net/README:
Whatever you do, do NOT ever call thinkpad-acpi backlight-level change
interface and the ACPI-based backlight level change interface
(available on newer BIOSes, and driven by the Linux ACPI video driver)
at the same time. The two will interact in bad ways, do funny things,
and maybe reduce the life of the backlight lamps by needlessly kicking
its level up and down at every change.
Since inputs are digital or at least inputs with D/A converters it is unlikely. That might work with really old VGA monitors without any digital logic. VGA in general does not even have clock, just hsync and vsync which tells timing for returning electron beam and was direct controller for controlling beam. Most modern CRT monitors had automatic detection of improper inputs, so no it is impossible to kill LCD this way.
http://www.epanorama.net/documents/pc/vga_timing.html