How can I run multiple copies of the same app using Google ARC Welder? - google-chrome-arc

I've installed the ARC Welder extension for Chrome. I opened it and added an apk. When I navigate to my Chrome Apps page, I see an icon of the app, and when I click on it, it launches ARC Welder and starts that app. Beautiful!
When I try to open a second copy of the app, it closes my Chrome Apps tab and sets the focus to the already-running instance of that app.
On the Chrome Apps page, I've tried right-clicking the icon to look for some option, holding control and clicking it, and opening it from a different Chrome window, but each time, it either does nothing or just directs me to the already-running instance of the app.
Is it possible to use Google ARC Welder to run multiple copies of the same app?
Thanks!

ARC Apps only allow one instance at a time. If you click the App icon it only refocuses the window.
It would be problematic if multiple App instances could be running simultaneously; for instance, they would share the same filesystem which was not necessarily designed to be accessed simultaneously like this.
If you want a second app instance at the same time, you would need to package it separately with a second App ID.

after loading it in ARC Welder
this can be done in 4 steps
click download zip instead of test.
After you save the zip file you'll have to extract it to a folder.
Then in chrome go to the extension page and select "developer mode".
finally click "load unpacked extension" and select the folder you just extracted
if you want to run multiple instances of the same app
you can simply make an copy of the folder you extracted en repeat step 4

Docker will allow you to run multiple ARC Welder containers simultaneously. Here is a Youtube clip showing how.

Related

Open Microsoft Edge while running app in Hololens

I want to open Microsoft Edge while running an app with the HoloLens. In my particular case, I'm developing a simple 2D app in Unity, where the idea is to press a button and open a pdf file, image, etc. Currently I've managed to open these files with the WWW class by pressing a button, but everytime I do it the app gets closed...
Is it possible achieve it? what would I need to implement in order to do it?
Thanks in advance!
To open EDGE or the default web browser you can use Application.OpenURL
https://docs.unity3d.com/ScriptReference/Application.OpenURL.html
In any case your app will go to the background, In case you need to show a website inside your app you will need to use any Plugin/Asset like this one https://github.com/gree/unity-webview that sadly doesn't support Windows.

My windows phone application runs when ran though visual studio (onclick of device button) but when I disconnect and run it doesn't?

I have written file picker code in my project. When i run the project in my windows phone by clicking on device button in visual studio, the app runs fine(I mean it opens pictures library and i can select a photo and preview it).
But when I disconnect my usb and then open the app in the phone and when i open pictures library on click of a button , the pictures library opens briefly and then the app crashes immediately(My app closes).
Can anyone please help me with this??
As written in the blog post , the AndContinue method run in a different process and to do so, the current running app goes into the background or even gets closed sometimes, that is what you are experiencing in your app as far i can tell but not sure why different things happening during debug & deploy.
There must be a callback inside app.xaml.cs specifically to handle the condition when calling application(which was sent into background) comes in foreground, read this blog post carefully & you'll understand as what you need to change in your code :
using-the-andcontinue-methods-in-windows-phone
http://blogs.msdn.com/b/wsdevsol/archive/2014/05/08/using-the-andcontinue-methods-in-windows-phone-silverlight-8-1-apps.aspx
I just dealt with this issue and one of the reasons why there are differences between debug and deploy is because of the suspending event.
During debug, the application does not actually get suspended until you manually do it through Lifecycle Events. This means that when you pick a file on debug and the app is put to the background to load the file picker, it is not actually suspended, while when the app is deployed, it actually gets suspended.
Look into your app_resuming method and OnSuspending methods in your app.xaml that may be causing errors not occurring during debug.

Using an enterprise app for Single App Mode with Profile Manager in Mavericks Server (MDM)

I have a bunch of iPads that are all supervised, and that are enrolled into a MDM server (Mavericks Server). I've added the app to the specific device group, but when I go to the profile settings and Single App Mode the only apps I can select are the builtin ones.
Is there no way to use a third party (enterprise) app as the app for Single App Mode?
EDIT: If you use Apple Configurator and add the app there you can set Single App Mode to use that app, I would imagine that would be possible when doing the same in Apple's Profile Manager, but it doesn't seem to be working here.
EDIT2: Looking at Apple's documentation it does indeed seem to be possible to select a third party app for single app mode using their Profile Manager, so why isn't the app showing in the list for me?
http://images.apple.com/education/docs/assessment_with_ipad_mar2013_v2.pdf
Go to the Device Group, after installing the app (that you want to show in Single App Mode dropdown and lock it to) do "Update Info" (small icon in bottom-middle-left of screen) on all the devices in that group. Wait a bit, then go to Single App Mode screen again, the app should start appearing.Works for me. The "Update Info" thing also works for Single Device as well and you can lock to any new app installed from Profile Manger, doesn't matter if the app was installed while supervising through Configurator or not.
So interestingly enough in the new update for Server (3.1.1) this seems to be working. The Enterprise app is now listed in the dropdown box.
However there also is about 10 empty items in the box with no text description. So it's clearly still a bit buggy.

How to make 2 applications shared the same dock tile

I have a launcher application in a bundle in /Applications that chooses a binary and fork/execs it. What I would like is for them to share a dock tile. I have tried a few approaches and none of them are satisfactory.
1. Keep the binary bundled with the app
If the binary is contained within the app bundle, this seems to work. However, it's generally considered bad practice for a bundle to modify itself, and I can't guarantee that a user has write access to /Applications. I tried putting a symlink to e.g. ~/Library/Application Support/MyBinaries/mybinary but this gives a separate dock tile.
2. Keep the binary outside the app bundle
If the binary is outside the app bundle, I get a separate dock tile. Why don't I set one of the processes to be an agent s.t. one of the tiles does not appear? This would have to be the launcher as the user should not be able to skip the launcher's logic as to which binary to run. Unfortunately this means that quit doesn't work properly, and you can't click the dock to restore the binary's window. It may be possible to get this to work by passing messages between the applications properly.
3. Massively hacky solution
There's a rather hacky way of doing this by adding an extra level of indirection, where the app at /Applications/MyLauncher.app launches another app in ~/Library/Application Support/Launcher2.app, which contains the binaries in its bundle. Only the second launcher has a dock icon.
This seems rather hacky, so I thought I would open this up to SO to see if anyone has a better solution?
EDIT
In option 2, I was keeping the binaries in bundles of their own. Don't do this. When I kept them in a regular folder everything worked correctly.
Answering my own question.
If you find yourself in this situation, go with option 2. Put the application at /Applications/MyApplication.app and keep the binaries in a folder named something like ~/Library/Application Support/MyApplication/Binaries/ and happily fork/exec them. Definitely do not put them in app bundles, as this was the source of my confusion. This solved all of my criteria:
Don't need root access to modify the binaries
Launcher and binaries share one dock tile
Pressing quit on the dock tile quits the binary.
App appears in Launchpad
Launching via Dock goes through the launcher app

Can I store a screensaver inside my App bundle?

I have a Mac app that can double as a screensaver (a minor functionality, but which I enjoy!). I don't want to have to distribute the app itself (a fractal viewer) and the screensaver separately, so I want to put the screensaver bundle inside the app bundle.
Questions: can I do that, and expect it to work? Do I have to "register" the screensaver somehow (using which API?), or will it be picked up automagically by the system?
I don't think the OSX screen saver host will acknowledge your .saver bundle unless it's in one of the Library/Screen Savers directories. So you can't just distribute the app and expect the saver to run with no further intervention.
You can still distribute them as a single bundle, of course, but you'll need to have some way of copying or symlinking the .saver into the right place from wherever it lives inside your app. For example, you could offer the user that option the first time they run your app, or you could add an "Install Screen Saver" menu item, or whatever.
I doubt you can do it without any user intervention at all -- as well as being rude, that would probably represent a bit of security hole...
You can do this without user intervention. At startup of your app, you can copy the .saver out of your bundle and into the "~/Library/Screen Savers" directory. The next time you run System Preferences and go to the screen saver settings, you should see your screensaver listed with the built in screensavers.
Beware that if the user doesn't expect that you are installing a screensaver, they might get irritated.
So, apparently no way around this.

Resources