Wp8 is incapable of background tasks

[AngryNil]

Are you looking for Background file transfers for Windows Phone?

FlashVideo TubeMusic can download things in the background, metweets sends a tweet when I directly change to another app.

Looks like I was completely wrong. Thanks a bunch for these pointers, I have no idea how I missed them. I'm not sure how well known this is, but a tonne of apps could benefit from it. This is good knowledge for my own purposes, too.

MeTweets seems to have a rather imperfect implementation, when I resumed the app it sent the tweet again.

 

[Arjun KR]

you can run maximum of 15 apps at background with true multitasking capabilities(on my 620) so no problem with twitter here,I'm on Tata Docomo 2g,it just works fine,but you may find delay in live tiles updates because WP8 has interval of 30mins before each live tiles updates,this is done inorder to save battery

 

[link68759]

This is a minor issue though. While there is an API in place for background downloading, you are mistaken if you think this is intended for what OP posted. The amount of misunderstanding here is extraordinary...

Apps that appear to always be online don't have or need background support. They register with the system to receive "push" notifications which is entirely handed by the system and the system gives you a shortcut back to the app when you get one. When you start the app again, it reconnects and resumes your session. It IS NOT "running in the background". This is fine for chat programs and other, but OP is correct in saying that you must wait for network operations to complete before multi tasking. And no, it's not somehow the dev's fault that he/she didn't add another 30 lines of code to circumvent this, which a number of you are insinuating. Sorry, that's just stupid. Moreover as I said, the background API isn't intended for this and I'm not confident that devs have the power to resolve this issue.

Even in internet explorer, if you save a picture you MUST wait for it to finish downloading, you have to sit there and watch it download before "backing" out of it, which is quite annoying to me.
Sent from my RM-824_nam_att_101 using Board Express

 

[AngryNil]

This is a minor issue though. While there is an API in place for background downloading, you are mistaken if you think this is intended for what OP posted. The amount of misunderstanding here is extraordinary...

I believe you are conflating the standard issue background agents (which are likely familiar to many) and background file transfers (per manicottiK). I personally can't believe I've never seen anything on this until today, considering it apparently has been supported since Mango! An app can initiate an upload or download transfer when it is active which will run separate from the app and as such, not be frozen when you switch away from it. This should work to send tweets, download podcasts and similar.

 

[Robert Carpenter]

There are reasons that this is by design.

In all of these scenarios that were provided (twitter, downloading picture in IE), there are implications with these expectations. If any of these scenarios encountered some sort of error during the process, you would NEVER know. You go to send a tweet and immediately exit the app because you expect it to finish in the background. You form a natural expectation of this over time, and then eventually there will be one time where there is a network error and you will never know what happened. In these situations, consistency is more important. With the current design, it will function and behave the same way EVERY time and you will never be left guessing.

If you want the functionality you are all describing, you need to have a way to inform the user of errors that might be encountered. Therefore, you will need a full background agent to achieve this, which is currently available for developers to use. If you want to introduce advanced features like this in your app, you need to make sure you are covering EVERY scenario and requirement.

However, an app developer can STILL achieve the functionality you want using a BackgroundWorker thread. A BackgroundWorker thread is stopped when an app is tombstoned, not deactivated.

 

[AngryNil]

If you want the functionality you are all describing, you need to have a way to inform the user of errors that might be encountered. Therefore, you will need a full background agent to achieve this, which is currently available for developers to use. If you want to introduce advanced features like this in your app, you need to make sure you are covering EVERY scenario and requirement.

The two current background agents do a poor job of filling this hole. The periodic agent is obviously not what is desired, and the intensive one is simply too constrained.

As far as I can tell from MSDN documentation, you can catch errors in background transfers and act on it. Obviously this increases complexity and is likely unnecessary in a Twitter app, but it is arguably vital for applications which rely on potentially lengthy downloads and preloading. Personally, I think the existence of these transfers should be made more obvious to the user ? something a notification centre would handle very well.

 

[Andre o Botelho]

There are so few developers interested in WP8 and a lot of things have to be done by hand because the system does not support it, even it you register a background task it simply can not work and if you went off the app it cant do anyting about it. Happens everytime I try to make something and switch app( or hit the search button accidentally) or change current app page,it cancels the operation and does nothing. Lets ask to MS to help, not put the guilt on the developers.

 

[link68759]

I believe you are conflating the standard issue background agents (which are likely familiar to many) and background file transfers (per manicottiK). I personally can't believe I've never seen anything on this until today, considering it apparently has been supported since Mango! An app can initiate an upload or download transfer when it is active which will run separate from the app and as such, not be frozen when you switch away from it. This should work to send tweets, download podcasts and similar.

I'm not confusing or combining the two, I merely didn't mention daemons. I mentioned the background transfer API and push. As far as I can tell it is for large data operations and it might simply not be applicable to simple tasks like sending a tweet.
Sent from my RM-824_nam_att_101 using Board Express

 

[AngryNil]

There are so few developers interested in WP8 and a lot of things have to be done by hand because the system does not support it, even it you register a background task it simply can not work and if you went off the app it cant do anyting about it. Happens everytime I try to make something and switch app( or hit the search button accidentally) or change current app page,it cancels the operation and does nothing. Lets ask to MS to help, not put the guilt on the developers.

It would help if you provided specific examples for what you're looking to do, making blanket statements after there has been a page of discussion isn't beneficial to anyone.

There are specified scenarios for background processing provided by Microsoft. I remain of the opinion that this is the right approach, but it needs to be fleshed out further. Would you rather let developers do whatever they want in their apps? That will lead to lag, freezes, crashes, security vulnerabilities, lost data and such, whether from malicious intent, honest mistakes or laziness.

I'm not confusing or combining the two, I merely didn't mention daemons. I mentioned the background transfer API and push. As far as I can tell it is for large data operations and it might simply not be applicable to simple tasks like sending a tweet.

Whether background workers or background transfer is the applicable method, it remains that there is at least one Twitter app on the store that sends tweets when you switch away from the app, which is exactly what the OP wanted. You said that "OP is correct in saying that you must wait for network operations to complete before multi tasking". That doesn't seem to hold in the light of the aforementioned APIs.

Saying that it is unfair to make developers implement extra code is really quite silly. If you want background processes, you will have to implement them in a specific way. If you don't want to spend the time doing so, that's your choice to make and your product may suffer for it. I don't see how this scenario is different from the thousands of other constraints that developers invariably run into.