I’m using the onPause() method in my app so that users become ‘offline’ in my chat when the app is on pause. I found it very useful.
But the thing is that each time a user navigates between activities, the method is called for like a millisecond. This way, users are ‘online’ in activity A, ‘online’ in B, but ‘offline’ in between.
Because I use a green dot to described online users, it is very annoying since it changes to grey and then green again each time.
Is there a way to prevent this?
onPause is part of the Activity lifecycle, which relates to the different states an Activity goes through - it's not about whether your app as a whole is in the background. Here's what the docs say about it
The system calls this method as the first indication that the user
is leaving your activity (though it does not always mean the activity is being destroyed); it indicates that the activity is no longer in the foreground (though it may still be visible if the user is in multi-window mode).
There are a few ways you could handle it - the simplest would be to have a navigating flag you set when you're switching to activity B. Then the onPause can check that flag, and skip setting you to offline if there's a navigation even going on.
I'm assuming you mean the dot is flashing for other users (since you wouldn't be looking at the same View if you're the one switching between activities) - it might actually be a good idea to have the app send out an "I'm online" ping every so often anyway.
That way they can set a user to offline if they don't get a message after a certain amount of time - it just means that if a user gets a crash, their network drops or whatever, they don't look online the whole time just because they didn't send an "I'm offline now" message through onPause
Related
When we deactivate a WP app, it can be tombstoned and terminated later by the OS. I need to save some unsaved app data to a persistent storage when the process is terminated, but not before this. Obviously, the Deactivated event cannot be used for this purpose as it is raised immediately when an app is moved to the background; the Close event is also not the event we need as it si not raised when the app process is terminated by the OS. Is there a special Windows Phone app event for that, something like Application_Terminated?
The problem is that the operating system only tombstones your app when it is under severe resource pressure. At the time it is not practical to wake up the app and run app code because it might risk whatever is currently in the foreground. This limitation exists on all modern mobile operating systems (Android, IOS included). This is just the cost of operating in a battery/resource friendly environment.
Having said that, it sounds like your backing store does not disambiguate between data the user "saved" and data that is just being cached until the user can finish the transaction. It would be useful to build the idea in. Think of it the way some of the smarter web sites on the internet now work. You can navigate away while you were in the middle of entering data and when you come back the site presents you with the partially filled form. The site understands that you weren't "done" but it respects the fact that you had provided some of the information you'd need to get "done".
What I'm saying here is that the problem is easily fixed by understanding and accommodating the way your users are likely to use the app. Thinking of your app like a web site (at least in this context) helps out things into perspective. Sorry about the longish answer. I hope it helps :)
There is no such event. You should save your state on Deactivated so that if the application is removed from memory (tombstoned) you can set yourself up again upon reactivation. If your problem is figuring out whether or not you need to restore state on Activated, check out the ActivatedEventArgs.IsApplicationInstancePreserved flag (http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.shell.activatedeventargs.isapplicationinstancepreserved(v=vs.105).aspx). This flag tells you whether your app was tombstoned. If it wasn't, you can throw away the old state or overwrite it the next time you are deactivated.
Subject sounds mutually exclusive, and this is probably a terrible hack, but I'll ask anyway.
I have an single-threaded VB.NET application which is setting status bar label to "Loading..." and then synchronously loading data from database which in some cases can take up to 1-2 minutes. Is there any way to show user an AJAX-type animation while data is being loaded? Of course, the correct way is to use separate thread/BackgroundWorker for data access and manage UI separately, but I can't currently change data access model and have been asked for a "temporary fix".
Here are some of my ideas at the moment:
Update label (and only that single label) from another thread, force it's redraw, somehow circumventing windows forms message pump (probably not possible)
Keep another process in background and send "show" message to it from main application. It shows up in front of application, shows animation until "hide" message from main application is received. (problems with user switching away from main application but "animation" form still visible)
I'll probably get down voted for suggesting it (and quite frankly I don't blame people) but this sounds like a job for DoEvents.
I wouldn't normally suggest it, but you are looking for a hack.
According to J. Likness on page 166 of "Building Windows 8 Apps with C# and XAML," in speaking of the OnResuming event: "The main reason [for this event ] is for applications that provide timely data to refresh their information."
I have one page in my app that has such data; so, if the user has resumed the app, and he explicitly
returns or is implicitly/automatically returned to that page (assuming he was on that page when the app was suspended), I want to refresh the data. But how do I know that my app was suspended/resumed?
My idea is to set a bool that the data-rich page can interrogate in its OnNavigatedTo() event; if it is true, I will refresh the data. Is there a better way to do this, and perhaps more importantly: is the OnNavigatedTo() event fired if the user was on that page, the app was suspended, and then resumed? Or does the app view the page as never having been left, and thus it is not being navigated back to? Perhaps another page-level event would be more appropriate?
I'd say you need to determine what the threshold is for when the page of interest needs to be refreshed; I don't think it's as simple as a Boolean. A user could suspend and pretty much immediately resume (say within 15 seconds) and that may not merit a refresh, but that same user could also linger on secondary page, never suspend, and come back to a page 30 minutes later, in which case the page data could be quite stale. Your Boolean may need to be more of a timestamp.
That said, the Resuming event does not fire OnNavigatedTo. If you need to know what page you're coming back to, you'd need to save that info when you suspend, perhaps in LocalSettings. But now consider that if you're using SuspensionManager in C#/XAML, that is already happening on your behalf, and if you think about it, the behavior you want is not too different (if at all) from what should occur when the application comes back from a terminated state.
So in a similar fashion, you could add a call
await SuspensionManager.RestoreAsync()
as your implementation of the Resuming event. That would, in turn, cause an OnNavigatedTo and you'd run through the normal logic of bringing up that page.
It's technically not resuming anymore, you're just using the resuming event to trigger the reload of the entire page. That could be overkill depending on the nature of the page (e.g., maybe there's a lot of semi-static data and only a tiny bit of volatile data - resuming doesn't need to restore the static data). You may want to dial back how much is refreshed on a 'resume' versus a 'terminate,' but since SuspensionManager is code you can see and change, so you can control that level of granularity. And maybe it's here that you introduce you're idea of the Boolean to differentiate what needs to be done in LoadStateAsync when it's invoked by Resuming versus by other means.
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
I've got a JMS messaging system implemented with two queues. One is used as a standard queue second is an error queue.
This system was implemented to handle database concurrency in my application. Basically, there are users and users have assets. One user can interact with another user and as a result of this interaction their assets can change. One user can interact with single user at once, so they cannot start another interaction before the first one finishes. However, one user can be in interaction with other users multiple times [as long as they started the interaction].
What I did was: crated an "interaction registry" in redis, where I store the ID of users who begin an interaction. During interaction I gather all changes that should be made to the second user's assets, and after interaction is finished I send those changes to the queue [user who has started the interaction is saved within the original transaction]. After the interaction is finished I clear the ID from registry in redis.
Listener of my queue will receive a message with information about changes to the user that need to be done. Listener will get all objects which require a change from the database and update it. Listener will check before each update if there is an interaction started by the user being updated. If there is - listener will rollback the transaction and put the message back on the queue. However, if there's something else wrong, message will be put on to the error queue and will be retried several times before it is logged and marked as failed. Phew.
Now I'm at the point where I need to create a proper integration test, so that I make sure no future changes will screw this up.
Positive testing is easy, unfortunately I have to test scenarios, where during updates there's an OptimisticLockFailureException, my own UserInteractingException & some other exceptions [catch (Exception e) that is].
I can simulate my UserInteractingException by creating a payload with hundreds of objects to be updated by the listener and changing one of it in the test. Same thing with OptimisticLockFailureException. But I have no idea how to simulate something else [I can't even think of what could it be].
Also, this testing scenario based on a fluke [well, chance that presented scenario will not trigger an error is very low] is not something I like. I would like to have something more concrete.
Is there any other, good, way to test this scenarios?
Thanks
I did as I described in the original question and it seems to work fine.
Any delays I can test with camel.