Ok, this is what I know so far about the Windows Phone 7.1 application life-cyle, but I still have a few questions.
Application Launching
- Called on application start-up, then proceeds to initializes App and then MainPage.
Applicaiton Deactivated
- Called when app becomes dormant (running but user is not using it). This calls the OnNavigatedFrom method of the current page before moving to the ApplicationDeactivated method in the App class. Once the application is Dormant it might become Tombstoned if the operating system needs more memory.
Application Activated
- Called when app comes out of Dormant or Tombstoned state, you can call IsApplicationInstancePreserved to figure out which (true means Dormant, therefore the state was preserved). Once this is called it moves to OnNavigatedTo.
Applicaiton Closing
- Called when user navigates backwards past the first page and the app exits. The OnNavigatedFrom method (on the first page) would be called as well.
So my questions mostly pertain to what is being initialized when the ApplicationActivated method is called.
-If the application was NOT Tombstoned is there anything you need to do to initialize the application or does the operating system restore everything back to the way is was? Is the constructor even called for the page that it is navigating to or was everything just frozen?
-If the application WAS Tombstoned do the page constructors get called? (I'm assuming so since nothing was saved). If the page constructors are called is there a difference between navigating to this page for the first time and coming back from a Tombstoned state?
These are all things that you can test yourself. Under the properties of an the application project you can enable tombstoning when you navigate away from the application. This setting is under the Debug tab.
Correct me if I'm wrong but here are the answers to the questions I posed.
-When the application gets activated and it hasn't been tombstoned then only the OnNavigatingTo method of the last page gets called (no page constructors). I don't believe there is anything you need to do in this case since the application state has been saved.
-When the application gets tombstoned you need to save any page data that you might need to reload since everything on the page is lost and when it becomes activated again the page constructor IS called before the OnNavigatedTo method.
Hope this helps anyone in the future with similar questions....
Related
In my app when the app is resumed from a sleep, I'd like to
reload the page - or ideally, just update specific UI elements.
How can this be done?
Preferably in a platform independent way.
You want to hook into the onResume method in the application module which exposes the event when an app resumes from the background.
https://docs.nativescript.org/api-reference/modules/application.html#onresume
So in your app.js (the entry point of your application), import the module and add the onResume event handler and it can run everytime the app resumes. Now reloading a page will require a little more work. You'd have to use the frame module and find out the current page and do your work, but I'm guessing it can be done with a little effort using the approach mentioned.
UPDATE: based off your comment, you need the reloadPage() method from the ui/frame module. https://docs.nativescript.org/api-reference/modules/_ui_frame_.html#reloadpage
The correct method is reloadPage() in the Frame module (as contributed by #Brad) but the problem is that it's NOT an exposed api.
No problem - just copy/paste it and it works.
The problem is that it basically does a navigateTo() to the currentPage and that effects the navigation history. You have 2 choices - setting clearHistory to true and you lose all history (don't want that) or set clearHistory to false which creates a a duplicate of the current-page (don't want that either). There's also a backstackVisible option but that doesn't help in this scenario.
#Brad tells me that there's api that allows access to the navigation stack - haven't looked into it.
For my app - the user will be at the root page most of the time, so I decided to reload the page only if on the root page and then set clearHistory to true and that works for me.
I'm making a app with using XF PCL.
I started to doubt that XF's timer is not good enough for UI routine.
for example, in iOS native app, If View is not showing some reason (new page's pushed or something), scheduler is stopped automatically. Because it's for UI.
But Xamarin's doesn't seem like that.
It's still doing his job.
I hope at least within "Device.BeginInvokeOnMainThread(() =>" will be skipped when it's disappeared.
Am I right?
Should I put extra logic for that?
(like stop and restart timer?)
(or declare variable to skip in it?)
Thanks.
In Andriod usually when you are in Page1 and then you navigated to Page2, although Page1 is hidden it is not killed therefore the worker threads would still working (in that case it is the timer)
My suggestion is to override the OnDisappearing method in the code behind of Page1 and place the code that would make the timer stop or being ignored.
If it is for me , I would also place a boolean flag and called _isPageShown so when you override OnDisappearing and OnAppearing you just put the value of _isPageShown to false or true accordingly. Then in the callback of the timer you check the flag if it is true or false and act accordingly.
I'm writing a Cocoa app, and I need to indicate to the user that a view is invalid and can't respond until a background job is completed.
Longer version:
A view in my app contains some data fetched from a server. When the app determines that the data is invalid, it fetches fresh information and displays it. Usually the update happens too quickly to see, but if server or network problems cause the background job to take more than a second or two, I need to make sure the user
Cannot interact with the view until the job is finished;
Can tell that the view is awaiting an update; and
Can continue to interact with other parts of the application until the job is finished.
1) is important because any operation initiated with the stale data will fail, and if the network or the server is slow, I don't want the user to waste his time with futile attempts to interact with that part of the application. (It's fine if the user can still see the data. That could conceivably be helpful, actually, but it isn't crucial.)
What is the standard way to do this in Cocoa? For what it's worth, in the Eclipse framework I think I used the showBusy method on ViewPart.
If there isn't a standard way, does anyone have any suggestions for tackling it? I haven't been using OS X very long, so I'm not even sure how an app is supposed to look and behave in this situtaion. (The screenshots on this page looking promising, but it's iOS, not OS X: http://cocoawithlove.com/2009/04/showing-message-over-iphone-keyboard.html)
Right now I'm working on replacing the whole view with an NSProgressIndicator and restoring the view after the task finishes, but removing the view means my app could end up in a funky state if something goes wrong. Also, I'd like to be able to factor this functionality out into its own class or category(?) since I will have this issue with several different view classes in my application. Ideally I'd like to end up with something as simple as Eclipse's view.showBusy(true)/view.showBusy(false).
Any and all help would be appreciated.
Thanks!
Why not just draw another view on top of the busy view? You could either have it display an image that means busy, or draw it as semitransparent, so it shades out the before-update version of the busy view.
is there any way to handle the Windows button keypress within the *.Xaml.cs especially when the app is busy getting a request processed using an Asynchronous BeginGetResponse. is there a override handler like OnBackKeyPress?
What's the appropriate way to handle this use case? i'm already handling Application_Activated and deactivated in the App.Xaml.cs file for tombstoning.
You can't stop this from happening. When this happens the current page will get its OnNavigatedFrom override called so you could clean up your page and save state from this method.
Bear in mind that it won't be possible to tell whether this is due to the hardware Start key or if the user just navigated away by say pressing the Back key or tapping a button.
Update:
If you're trying to avoid a crash due to Fast App Switching interrupting your networking call you should rather handle this when you return to the application. Your WebRequest will be cancelled and you should handle this case as shown in this MSDN blog post.
I have a Mac OS X application that is also a protocol handler (just as, for example, Safari is a protocol handler for the HTTP and HTTPS protocols). So when a user clicks a link of the form myscheme://some-kind-of-info in any application at all, my application launches to handle the link.
Now I need to be able to determine if the application was launched by such a link click, or if it was launched by any other method. In other words, it was launched by any method besides a link click. (In those cases, I want the app to stay open, but if it was launched by a link it should quit and ignore the link. This way it only operates when already running.)
Is there some way within the app at startup to introspect and find out that it was launched by a standard method rather than by an AppleScript GetURL event? I'd like to find out through a documented method, rather than - for example - just have my app only open these links after it's been running for a half a second.
You can register a handler for each of the possible Apple Events you'll get on launch, and make note of which one you receive first.
If the application is launched without documents, you'll get kAEOpenApplication.
If it's launched with documents, you'll get kAEOpenDocuments (or
kAEPrintDocuments).
If it's launched with a URL, then (obviously) you'll get kAEGetURL.
There's also kAEOpenContents, but I wasn't able to trigger it easily in my test app; it's probably worth supporting no matter what.
How Cocoa Applications Handle Apple Events documents all of this stuff.
There is one error in there, though; it says that AppleScript's "launch" will send kAEOpenApplication. It won't, it'll send ascr/noop (kASAppleScriptSuite/kASLaunchEvent, defined in ASRegistry.h). I couldn't get the usual Cocoa event handler mechanism to trap this event, so you may need to do some more digging there.
One way you can check if the event is sent at launch is to register the event handlers in your application delegate's applicationWillFinishLaunching: method; they should deliver by the time applicationDidFinishLaunching: is invoked. With that method, you could potentially only check for kAEGetURL.