Windows Store: how to test whether specific "metro" app is installed? - windows-8

Well, the title says it all. From my Windows Store (a.k.a. "Metro") application, I need to know whether some other specific application is installed on that machine. Alternatively, I want to know whether there is some application that able to handle URL of specific theme (for me its the same problem) - without launching it.
I tried to use PackageManager from Windows.Management.Deployment namespace, but it not accessible from winrt...
http://msdn.microsoft.com/en-us/library/windows/apps/windows.management.deployment.aspx
Is there any other way to do that?
Thanks!

No, there isn't any way to do it. If you want to invoke another app though - you can use a custom protocol with protocol activation to invoke an app that supports that protocol or have it installed from the store.

Related

Program won't load my custom DLL instead of Windows one

I am trying to proxy WS2_32.dll but no matter what I do it always loads the systems one instead. I used a tool to check and it is loading the systems one:
0x00000000775c0000 0x67000 C:\WINDOWS\SysWOW64\WS2_32.dll
I heard windows blocks this one from being loaded if its in the same directory. Is there anyway to override this?
You're describing a security feature of Windows here. Known Windows DLL's are loaded from trusted locations (and secured against modification there). So no, there's no publicly known method. And if one would become known, you would expect a patch very shortly afterwards.

Override worklight.js

I'm developing an app with IBM MobileFirst Platform and I find an issue with Worklight.js file. Worklight.js is extending Function prototype defining several methods like bind, curry, wrap and so on.
My app is built with aurelia framework an after upgrading the framework to the last version I'm facing a funky issue related to bind extension.
If I comment the bind extension in worklight.js everything seems to work like a charm (don't know why worklight implements its bind version).
Worklight.js file seems to be added to the wlapp package at build time. Is there a way I can override this file so I do not have to modify .wlapp file each time app is built?
Thanks
The direct answer to the specific question you've asked is, no, there is no way provided to override worklight.js. This is the core JavaScript code needed for the MobileFirst Platform client-side to function, and as such the user isn't given any means to modify it - it's injected into your app (i.e., into the WLAPP file) during the build process.
I'm not aware of any specific issues with Aurelia, but have certainly seen cases in the past where an app that uses two different frameworks (e.g., MobileFirst Platform / Worklight, and something else) "fight" with each other because they both want to implement extensions that are not compatible with each other - in which case, one framework or the other usually needs to change to accommodate the other.
If you are a customer with paid support, I'd suggest opening a PMR so we can get our developers to take a look at the issue.
I have the same problem with Angular. Worklight bind makes Angular controller fail to instantiate. The solution is to recover the bind function after worklight is loaded.
var bind = Function.prototype.bind;
window.wlCommonInit = function() {
Function.prototype.bind = bind;
};

IBM Worklight 6.2. Change default behavior for Remote disable in native apps

I'm using worklight application management features from an Android native App.
I want that when in the console the application status is changed to "Access Disabled" the only option for the user will be to quit.
In the Knowledge Center and in Developer works there is documentation about how to do it:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.appadmin.doc/admin/t_denying_access_to_older_app_versions.html?lang=en
https://www.ibm.com/developerworks/community/blogs/worklight/entry/how_to_create_a_customized_remote_disable_behavior?lang=en
It is explained that you must set a specific value for the initOptions object used in the WL.Client.init() method.
But in the Android native API I have not found the way to set the initOptions. The init method is deprecated and it does not accept initOptions.
Also, in case of Remote Disable the ResponseListener used in the WLClient.connect(aResponseListener) is not invoked, success or failure, no method is executed. Is this working as designed? I would expect a failure or success but not nothing.
Is it possible in a native app to force the application to close in case of Remote Disable?
How could I handle this situation manually in the app?
Unfortunately I do not have an example for you, but this is the general idea.
See if you can work with it (if someone can produce an example - please do...):
You need to create your own Remote Disable challenge handler that will extend the default Worklight Remote Disable challenge handler (RemoteDisableChallengeHandler.java).
class MyRemoteDisableChallengeHandler extends WLRemoteDisableChallengeHandler
Then you need to implement your custom logic in MyRemoteDisableChallengeHandler
WLClient.registerChallengeHander(new MyRemoteDisableChallengeHandler())
This will override the original.
You'll need to create your own dialog with a Quit button.
Some additional documentation.
For handling MaM configurations, this is, when you configure the app as Lost, Stolen, etc, in the Worklight Console -> Devices tab you must install the Fix IF201408281937 (Worklight 6.2) or later.
This events are also handled with the ChallengeHandler registered for the realm "wl_remoteDisableRealm"

make an AIR desktop application the default web browser

I would like to make my AIR desktop browser be the default web browser on a system, how can I go about and do this ?
I would also like to know how I can retrieve the link that has been clicked (in an email for example) to interact with the application.
thanks !
As far as I'm aware this is impossible in AIR. You can associate your app with file types using the air-app.xml descriptor or by calling NativeApplication.setAsDefaultApplication() (Read about it here). Opening files after using either of these methods will trigger your application to launch with an InvokeEvent (Read Here). You can read a good tutorial for this here.
However, if I understand correctly, you also want your app to take over any HTTP requests from inside any other app. To do this you have to override the protocol default application, which requires a registry edit and (I believe) that AIR can't do that. You may be able to write an external script in C or Java to do that for you (This might help with that).

need a way to securely communicate between Priviliged Helper Tool (installed using SMJobBless) and the application

I am trying to install a privileged helper tool to perform some elevated work. I am using SMJobBless for the same.
I am able to install the tool fine and also able to communicate with it. I am using Mac OS X 10.8.4 and using NSXPCConnection for the same.
I have added .mach service in the plist which will be installed in /Library/LaunchDaemons. I am using [initWithMachServiceName:options:] in the app as the helper is privileged tool and [– initWithMachServiceName:] in the helper to listen. The communication is working fine.
But the problem is I tried the same communication with another application I created which did not have any codesign at all (the helper tool installer earlier was codesigned). I tried to connect to the mach service of the helper tool and was able to connect easily. This is a problem because anybody can communicate with it then and make it do anything.
I wanted some way to securely communicate between my application and the helper tool.
Thanks a lot.
As you've said that you're not signing the second app, I believe that that is the problem that is allowing a 2nd app from calling the helper application. From the Apple docs and specifically the ReadMe file in SMJobBless, it states: -
The Service Management framework uses code signatures to ensure that the helper tool is the one expected to be run by the main application
This document should be able to assist you in getting the helper app correctly associated with its owner.
Note that it references a python script, which is provided here.
Answering my own question: I had logged a radar bug for the same and Apple said that the behavior was intended:
"It is up to the privileged helper to not expose insecure operations"