I've created a Windows Phone 8 application that reads and handles a LaunchApp NFC tag when it is presented to the phone.
By default, when a LaunchApp NFC tag is presented to the phone, the WP8 OS automatically handles the tag read and displays a dialog asking whether the user wants to launch the application or ignore it.
The problem is: In-addition to my application receiving and handling the tag read when a LaunchApp NFC tag is presented, the WP8 OS also displays a dialog prompting the user to launch the application.
Is there any way that I can prevent this dialog from showing and strictly let my application handle the LaunchApp NFC tag?
Thanks in Advance.
By design the OS will always intercept the LaunchApp Windows NFC type; especially as its the OS's responsibility to launch the application. It has little use to subscribe to the type within your app. I would suggest looking at alternate NDEF types to use which aren't handled by the OS (so avoid MIME types such as URL, and images).
Related
I am building an application that uses the Microsoft.Toolkit.Uwp.Notifications dependency to display a desktop notification on Windows.
However, since my application is presented in Fullscreen by using AppWindowPresenterKind.FullScreen the notification shows below the application and is not seen by the user when it pops up.
What can I do to see the notification even my application is in full screen? Is there any alternative NuGet I can use to do this?
When writing a Worklight app it is verboten to change the URL of the DOM in which the application is running. This makes sense as a hypertext move to another URL will obliterate the state of the app.
On occasion however, in my app I receive a URL for a news article and the user wishes to read it. Displaying the new content in an iFrame would start to address the requirement, but then I need navigation controls, etc. and it starts to feel like I am reinventing a wheel.
Does Worklight, or one of the mobile JS frameworks provide a "browser in browser" experience that I need here?
Worklight utilizes Cordova. Cordova makes it possible to display just what you wanted, a "browser in a browser" - InAppBrowser.
The InAppBrowser is a web browser view that displays when calling
window.open(), or when opening a link formed as <a target="_blank">.
Try that.
No setup is required as the InAppBrowser plug-in is already part of the Worklight project (this may differ depending on your Worklight version; If you are using 6.x you're OK).
All you need to do is to call up the URL. For example, in yourProject\apps\yourApp\common\main.js:
function wlCommonInit() {
window.open('http://apache.org', '_blank', 'location=yes');
}
Once the app initializes it will open the InAppBrowser:
And once tapping the Done button, you're back in the app.
You can of course not specify the location attribute so the navigation bar won't display. In that case, in order to go back to the app the user will need to tap the Back button:
Context
Many native apps have the user authenticate with Facebook, rather than with their own authentication system. This has been problematic for me to write iOS UIAutomation testcases with the Javascript bindings. Our scenario, from the user's perspective, typically looks like this.
Scenario
The user clicks "Connect to Facebook".
The (target) applications moves to the background, and a Safari browser moves into the foreground, so the user can authenticate with oAuth.
The user enters their authentication data and submits.
The Safari browser window moves into the background, and the target application moves back into the foreground.
Problem
Before running tests, Instruments has the user set the "target app" in the top menu bar.
Using the Automation within Instruments proves problematic when the target app moves into the background and the Safari app moves into the foreground (Step #2). At this point, Instruments reports
The target application appears to have died
I thought this would be as simple as merely polling/testing for changes in UIATarget.localTarget().frontMostApp() (or something similar), but does not seem to be the case -- the test run stops executing.
How can I use Instruments to successfully test this scenario? Is this a testable scenario with UIAutomation's Javascript bindings?
Alas, this is not possible. Instruments loses it's connection with the app since the app freezes in the background and does not continue. Also, it's not possible to send touch events to Safari because UI Automation doesn't work with apps that you didn't build yourself.
If you're using a pre-built SDK, you're pretty much out of luck. But if you are rolling your own Oauth connection to them, you could present a modal view controller with a webview going to Facebook's Oauth authentication page instead of kicking the user all the way out to mobile Safari.
That way, the application never exits. You can then figure out the events to send to the webview and try testing this from there.
I am very new to the Mac platform and Objective-C in general and in my application I would like to know how to determine that a user is logging out and perform some actions prior to this. Any info or pointers for this?
The official way to put the hook at logging in / logging out is described in these Apple documents Customizing Login and Logout and Tech Note 2228. But I'm afraid that the log-out hook was no longer directly supported.
So, the second best way is to run a headless Cocoa app, and receive a notification from the system using NSWorkspace, see the document and the list of available notifications.
To make a headless Cocoa app, you need to set an entry in its Info.plist called LSUIElement, see here. By setting LSUIElement to be yes, the app don't appear in the dock, but perform various operation in the background.
Take a look at Receiving Workspace Notifications in this Workspace Services document.
NSWorkspaceWillPowerOffNotification
Posted when the user has requested a
logout or that the machine be powered
off.
I have a question mainly related to the Iphone web browser but I am hoping the same solution would work on other browsers that are webkit based.
I have a application (Iphone + Android) that registers a handler for custom URI (appuri://) on the Phone. I am able to launch the application by making a link to "appuri://act/launch" from my web pages. This works only if my application is installed on the device. If the device does not have the app installed then a message comes up "Safari was not able to open ....".
What I want to do is detect if the URI Scheme is supported from the browser and then prompt my own message saying "please download the app ..blah blah blah" if the handler for the URI scheme is not found.
Is there a way I can detect or find the list of URL Scheme handlers on the Phone from the Web Browser ?
Protocol handlers are implemented below the browser, and giving foreign code direct access to operating system internals would be a pretty horrible idea, so, not without a plugin.
And since you can't run plugins in Mobile Safari, the answer's probably going to be "no."