Alternative for Background Transfer Service to run uploads in background - windows-phone-8

I've used background transfer service (BTS) API for Windows Phone in two apps and experienced very bad problems. It became one of the main source of bug in the two apps as for some reasons, download are often refusing to start, whatever I set in the flags (Connected to wifi, not connected, connected to a power outlet, etc.), and it was random from a user to another. This and bad response from the servers.
Is there a more customized way to achieve it? Which threads or loop remains alive in my app when I'm navigating to the external:// world? I should probably check with counters.
My main question remains: appart from the BTS, is there something to allow a 3-4 megs file to upload even if I navigate out from my app to play an mp3 from an external:// app?

Once you exit your app, you are pretty much shut down. You can masquerade as a location tracking background agent to remain in the background when you get deactivated, though you'll suck battery and I believe there can only be one of these active at a time. Generally, highly not recommended (and you'll probably fail certification).
A better way to do this if BTS is not to your liking is to use a ResourceIntensiveTask. This will only be triggered when the user is plugged in and has WiFi but will allow you to run whatever you want for as long as the conditions are met (for example, at night) which should be plenty of time to upload a 3-4 MB file.

Related

WP8 Uploading/Downloading large files

I am fairly new to Windows Phone development. We have a scenario where we allow user to upload or download files but along with authentication (oAuth, NTLM, forms all standard mechanism but not limited to oAuth).
Now so far our RnD suggest that we have following options
1- Resource Intensive Agent
The constraints associated with Resource Intensive (like Minimum battery etc.) have lead us to drop this option
2- Periodic Agent
A relatively better option, however as they run after 30 minutes and the constraint of 10 minutes duration gives us doubt that on mobile if user wants to upload a video of say 1-2 GB, it does not guarantee competition and u can anticipate other problems associated with this approach.
3- Background File Transfer
This is the best option in our scenario however my colleague told me that it does not support basic windows authentication and that we cannot change user-agent etc.
4- On Application
Another option is to perform network operation on application but we cant retain user on application for longer duration and also after sometime lock screen would appear. So...
Can anyone who have experienced similar scenario or from product team can guide here. It's a common scenario, are we missing something here? or is it really API limitation?
Resource Intensive Agents will indeed not work for your use case because they require external power to work. Not to mention that if the user receives a phone call the agent terminates.
Periodic Agent Have a 25 second limited duration, not 10 minutes (10 minutes are in resource intensive agents), so they are really no an option if you need to upload a gigabyte of information.
Background File Transfers have a hard limit of 100 megabytes. (It's even less on cellular internet).
On Application is a very possible option, you can prevent the phone from going to lock screen if that's a problem. The bigger issue here is that the user is pretty much stuck for the duration of the upload. More importantly, this seems to be your only option out of the four you mentioned.

Is Google's Webspeech server request-limiting me, and is there a fix?

I've been writing an extension that allows the user to issue voice commands to control their browser, and things were going great until I hit a catastrophic problem. It goes like this:
The speech recognition object is in continuous mode, and whenever the onerror: 'no-speech' or onend events fire, it restarts. This way, the extension is constantly waiting to accept input and reacts whenever a command is issued, even after 5 minutes of silence.
After a few days of of development, today I reached the point where I was testing it in practical use, and I found that after a little while (and with no change to anything on my part), my onend event started firing constantly. As in, looking at the console, I would see 18,000 requests being made in the space of three seconds, all being instantly denied, thus triggering onend and restarting the request.
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
Are my suspicions correct? Am I getting request limited?
Are my suspicions correct? Am I getting request limited?
Yes
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
To hide the IP source of your request you can use anonymizer networks like Tor, though it will not be fast.
It's naive to assume Google will spend resources to process all audio being recorded on your system. In your application development it is better to rely on API which provides at least some guarantees. It could be either commercial API or open source implementation like CMUSphinx.
With CMUSphinx, you can also properly implement command keyword detection and increase accuracy by specifying the grammar of the commands.
You could also use a Voice Activity Detection (VAD) algorithm to detect when a user is talking. This can be done by either setting a volume threshold or a frequency threshold (Human speech is usually less than 400hz for example). This way, you won't send useless requests to Google unless those conditions are meant. I would not recommend using Tor as this would significantly increase latency. CMUSphinx is probably the best local system option, but if still want to use a web-based service, I would recommend either using a Voice Activity Detection algorithm or finding a different web-based software.

Windows Phone 8 - Keeping background location tracking active beyond four hours

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.

Increasing Google Chrome's max-connections-per-server limit to more than 6

As far as I know, at the current moment, late 2011 the max-connections-per-server limit remains 6. Please correct me if I am wrong. This is bad that we cannot fix this easily as in Firefox. As far as I know this value is hardcoded.
One of the solutions is to download the Chromium's sources and rebuild them. Is there a more easy solution?
Is there any tricky way to hack this without creating a dozen of mirror-domains?
Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The javascript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the javascript app will take days.
Offtopic: do you know any other things that can be tweaked in my concrete situation?
IE is even worse with 2 connection per domain limit. But I wouldn't rely on fixing client browsers. Even if you have control over them, browsers like chrome will auto update and a future release might behave differently than you expect. I'd focus on solving the problem within your system design.
Your choices are to:
Load the images in sequence so that only 1 or 2 XHR calls are active at a time (use the success event from the previous image to check if there are more images to download and start the next request).
Use sub-domains like serverA.myphotoserver.com and serverB.myphotoserver.com. Each sub domain will have its own pool for connection limits. This means you could have 2 requests going to 5 different sub-domains if you wanted to. The downfall is that the photos will be cached according to these sub-domains. BTW, these don't need to be "mirror" domains, you can just make additional DNS pointers to the exact same website/server. This means you don't have the headache of administrating many servers, just one server with many DNS records.
I don't know that you can do it in Chrome outside of Windows -- some Googling shows that Chrome (and therefore possibly Chromium) might respond well to a certain registry hack.
However, if you're just looking for a simple solution without modifying your code base, have you considered Firefox? In the about:config you can search for "network.http.max" and there are a few values in there that are definitely worth looking at.
Also, for a device that will not be moving (i.e. it is mounted in a fixed location) you should consider not using Wi-Fi (even a Home-Plug would be a step up as far as latency / stability / dropped connections go).
BTW, HTTP 1/1 specification (RFC2616) suggests no more than 2 connections per server.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
There doesn't appear to be an external way to hack the behaviour of the executables.
You could modify the Chrome(ium) executables as this information is obviously compiled in. That approach brings a lot of problems with support and automatic upgrades so you probably want to avoid doing that. You also need to understand how to make the changes to the binaries which is not something most people can pick up in a few days.
If you compile your own browser you are creating a support issue for yourself as you are stuck with a specific revision. If you want to get new features and bug fixes you will have to recompile. All of this involves tracking Chrome development for bugs and build breakages - not something that a web developer should have to do.
I'd follow #BenSwayne's advice for now, but it might be worth thinking about doing some of the work outside of the client (the web browser) and putting it in a background process running on the same or different machines. This process can handle many more connections and you are just responsible for getting the data back from it. Since it is local(ish) you'll get results back quickly even with minimal connections.

Shared HTML5 offline cache within a local network?

Ok, so I know that HTML in itself isn't done yet, and I've done my fair share of reading for HTML5's offline modes.
Here's the question:
Can I set up an offline app in such a way that the entire system works offline, and SHARES a cache (or an XML repository, or a SQL-Lite DB or something) with other clients in the SAME network?
For example, my system runs on clients that need to share information with each other within a local network, but its fully web based. In case the local network's router dies, how can these clients continue to communicate with one another?
=== END ===
NOTE: If you're still not clear, I'd recommend you read on. The information below is to further clarify what I want.
In case you're still reading, here's a detailed example:
4 people in a restaurant are using a web based ordering system. They each have an iPod Touch (lol) which is connected to the internet via Wifi. Each member logs in to the system under a shared account, which allows them to share information. The cook is also connected, but uses a mounted iPad (lolz) in the kitchen.
When a waiter records an order, the data is stored in a DB, and AJAX is used to constantly refresh the Cook's screen, so he is notified instantly.
Assume, Zeus struck down the electricity in the restaurant.
Now, there's no internet connection, but all devices in question still function thanks to their inherent battery-oriented nature.
The web app switches to offline mode, and utilizes cached menus and screens.
BUT!
How does the offline system share information between client devices? How does the iPod Touch #3 tell the Cook's iPad - "Hey there, this is order #5352"?
The most obvious thought is a shared cache or something...
Ideas?
That is not possible. WebPages cannot communicate without a server.
The only thing you could do is setting up a local server for the case that the server on the internet is offline or not reachable.