I understand didFinishLaunchingWithOptions returns UIApplicationLaunchOptionsURLKey when launching my app from another application.
I also understand that openURL:sourceApplication returns a URL passed when calling my app from another application, doing so in both cases of launching the app and returning from background.
Since openURL:sourceApplication seems to always be called, it seems most logical to place all logic there - It seems strange that didFinishLaunchingWithOptions would contain the UIApplicationLaunchOptionsURLKey at all to begin with?
My question is: In which method should I place the functionality of handling the URL?
What is the best practice?
The documentation says you should add the functionality of handling to application:willFinishLaunchingWithOptions: or application:didFinishLaunchingWithOptions:.
Related
The pprof package documentation says
The package is typically only imported for the side effect of registering its HTTP handlers. The handled paths all begin with /debug/pprof/."
The documentation says if you already have an http server running you don't need to start another one but if you are not using DefaultServeMux, you will have to register handlers with the mux you are using.
Shouldn't I always use a separate port for pprof? Is it okay to use the same port that I am using for prometheus metrics?
net/http/pprof is a convenience package. It always registers handlers on DefaultServeMux, because DefaultServeMux is a global variable that it can actually do that with.
If you want to serve pprof results on some other ServeMux there's really nothing to it; all it takes is calling runtime/pprof.StartCPUProfile(w) with an http.ResponseWriter and then sleeping, or calling p.WriteTo(w, debug) on a runtime/pprof.Profile object. You can look at the source of net/http/pprof to see how it does it.
In a slightly better universe, net/http/pprof would have a RegisterHandlers(*http.ServeMux) function that could be used anywhere, you would be able to import it without anything being registered implicitly, and there would be another package (say net/http/pprof/sugar) that did nothing except call pprof.RegisterHandlers(http.DefaultServeMux) in its init. However, we don't live in that universe.
I am getting the value for WL.Client.Push as undefined when launching the application. Hence, the below is coming as false.
if(WL.Client.Push)
And that's the reason my push is not getting registered.
Please advise how can I define WL.Client.Push.
This normally happens when you try to use WL.Client.* APIs before the SDK initialization has been completed.
The right point to start using the WL.Client APIs is after the flow has entered the wlCommonInit() method.
Do note that IBM MobileFoundation 7.x is out of support, and you should move to MobileFoundation 8.0.
You can use MFPPush object to invoke Push APIs.
Documentation here.
A working sample can be found here.
Facing a very strange issue.
Following this guide https://azure.microsoft.com/en-in/documentation/articles/app-service-mobile-xamarin-forms-blob-storage/ to implement File Sync in Xamarin Forms app.
The Get method in my service (GetUser, default get method in App service controller) is being called thrice & on the 3rd iteration it gives me a 404 resource not found error. First 2 iterations work fine.
This is the client call
await userTable.PullAsync(
null,
userTable.Where(x => x.Email == userEmail), false, new System.Threading.CancellationToken(), null);
If I remove the following line,
// Initialize file sync
this.client.InitializeFileSyncContext(new TodoItemFileSyncHandler(this), store);
then the code works just fine, without any errors.
I will need some time doing a sample project, meanwhile if anyone can shed some light, it will be of help.
Thanks
This won't be an answer, because there isn't enough information to go on. When you get a 404, it's because the backend returned a 404. The ideal situation is:
Turn on Diagnostic Logging in the Azure Portal for your backend
Use Fiddler to monitor the requests
When the request causes a 404, look at what is actually happening
If you are using an ASP.NET backend (and I'm assuming you are because all the File tutorials use ASP.NET), then you can set a breakpoint on the appropriate method in the backend and follow it through. You will need to deploy a debug version of your code.
this is sorted now, eventually I had to give it what it was asking for. I had to create a storage controller for User too, although I don't need one as I don't need to save any files in storage against the users.
I am testing the app further now to see if this sorts my problem completely or I need a storage controller for every entity I use in my app.
In which case it will be really odd as I don't intend to use the storage for all my entities.
All our Microsoft Datazen servers are seeing an infine loop of client side javascript exceptions:
Uncaught TypeError: n.Telemetry.PageViewPerformance.checkPageLoad is not a function
since this script comes from http://az416426.vo.msecnd.net/scripts/a/ai.0.js the issue may be the App Insights cloud service.
As anyone experienced this?
Interesting - there was a refactoring recently where 'checkPageLoad' was split to 2 other functions (https://github.com/Microsoft/ApplicationInsights-JS/commit/da50064bfc6537fe7efe78ef1f5b048636f85070#diff-e25ffb54668c8e8794fb7224dbfadafbL112) However I don't see any issues with that - all usages of checkPageLoad were corrected accordingly.
Was it an intermittent issue or is it still reproducing? Do you have any custom code calling into AppInsights script, or it's just a snippet that you injected into your page?
When a user registers on my system, I create the user internally, and then allow the user to register with Firebase using the firebase client lib. This generates a session token for the user. Later, when a user starts the app again, the app automatically logs the user in like this:
ref.authWithCustomToken(sessionToken, function(error, authData) {...
debugger
I have verified that the sessionToken is available when the function is executed, but debugger is never reached, and no error is ever emitted.
Any help is appreciated!
I know it's a bit late, but I experienced a similar problem and it had me scratching my head for a while, so just in case it helps somebody else, here's what I found.
If I run authWithCustomToken with a token generated with one uid (uid1) and then run it again on the same ref with a different uid (uid2), the callback doesn't get fired the second time around.
In my case, I had declared the same ref in different modules that were used in the same node process and was trying to authenticate them with different uids. Although I had declared the ref twice, Firebase still saw it as the same ref because it was in the same process and referred to the same Firebase location. By declaring and authorising the ref in a parent module, I was then able to use onAuth in the child modules and the onAuth callbacks all fired as expected.
I had a similar problem with iOS, authWithCustomToken callback was never called right after install.
All consecutive launches worked fine.
My findings might be related so I thought I share them.
Problem was I called
func applicationWillResignActive(application: UIApplication) {
Firebase.goOffline()
}
func applicationWillEnterForeground(application: UIApplication) {
Firebase.goOnline()
}
in AppDelegate. Turns out if you call Firebase.goOnline() without logging in first it messes up the callback. Once I removed those two lines everything worked fine.