I can test my addin in Excel for Windows / Online, but can't test it from a Mac and iPad because I don't have that setup and don't have plans to acquire it.
I'm being rejected because of Mac tests by the team, and I'm unable to fix the errors.
Is there any way to cap Macs from the manifest file and don't make them avaible to Mac users when they browse the store?
Office Web Add-ins are designed to work across the entire Office platform. As such, there isn't a mechanism for enabling the add-in by platform.
In the end, these add-ins are just web apps that run within a browser context. If you're running into a blocker on a single platform, posting those questions on Stack Overflow would be a reasonable next-step. Generally browser specific issues are well known by the community here and can be quickly answered.
There are also several vendors that offer cloud-based Mac access. MacinCloud for example has a $1 per hour option (you pre-pay for 30 hours so it's a $30 investment). I've used this service myself for testing add-ins.
Related
I developed an extension for my team with more than a dozen persons. And we used it internally. But some Windows-base-on colleagues now face a problem. When they update chrome to verson 37 and above, my extension is blocked by chrome, due to its not installing by chrome app store. Is there a cheap way to avoid this?
I had tried some methods. We don't want to change chrome into chromium or change their Windows into MacOS, Linux. And we want to update Automatically, so packaging on local is standby. Publishing in chrome app store is also a standby. Is there any other way?
Alternative deployment is available only if your computers are in a Windows domain. You can then use this documentation to set up distribution via Group Policy.
Other than that, no, you have to publish on the Web Store. It's $5, once, it's not that costly. You can set your item to be Unlisted, so that it's not possible to install it without knowing an explicit link, or you can even restrict it to an explicit list of Google accounts.
As a bonus, if you deploy to Web Store providing your packaging key, I think the extension will be turned back on automatically.
I'm looking to buy a Windows Phone smartphone, and am looking into the possibility for 'deploying' private apps. I currently own an Android system, and it's a simple as building an APK file, and adding it to the filesystem of any phone I want to install it on.
I realize there have been some questions around this subject 1, 2, 3. They seem to say you either need a developers account, or an enterprise edition. These questions are old, and possibly outdated. I've tried to find more information on the topic, but all I could find was related to enterprise, or beta testing.
I have no interests in getting a developer's account, because I don't intend to develop or sell larger applications on the marketplace. It's mostly for private use.
If there is no way to do this by default (without paying any fees), are that alternatives that don't involve losing warranty?
You can register yourself in Windows App Studio and you will get to unlock one phone for development and side load up to 2 apps.
Currently that is the only way to put custom apps in your Windows Phone for free and without losing warranty.
If you, however register for a developer accout (which as you know has costs) you will be able to side load up to 10 apps in 3 different devices.
What versions of chrome are compatible with loadrunner 11.52 on windows?
I saw a post that said version 26 was supported, but Im looking to record using chrome version 13 on windows 7
NB: Browser version is mandated by the project.
NNB: Assume playback is browser agnostic - as the commands generated will send the raw HTTP(S) requests to the target server, without any UI
All versions when using the proxy recording model.
I just recorded again , and quit before I got the site up (so recorded for about 4 minutes with an empty chrome screen and a spinning timer) to see what Loadrunner recorded - I got web_url, web_add_cookie & web_custom_request for google safebrowsing & related api - ...
Unless you work for Google or have their expressed written permission then you do not use automated tools against their site. This is why the sample applications exist. Or, you may download and install onto a server you own, control, manage, ... any of the thousands of open source applications which are available on the market.
Pointing an automated tool at a site you don't own, manage or control is no different than driving down the street and shooting at parked cars, homes and signs just because they are there and you can. Pointing a performance testing tool at the same is akin to pointing a piece of field artillery at someone's home. This is something you do not engage in as a performance test professional.
I'm going through the Windows Phone test suite before submitting my app to the Windows store.
The guidelines have the following section:
Requirement - 5.4.1 - Malicious software screening
Requirement Text - The app must be free of viruses, malware, and any malicious software. -
Test Steps -
Launch your app.
Scan the app for malware.
Verify that there are no viruses, malware or malicious software in the app.
What does "Scan your app for malware" mean? Is there some tool I'm supposed to use to scan the app for malware? The document contains no link to such tool and a google search and MSDN search did not yield much results.
I can't speak on behalf of MS but I imagine that the malware tools used internally aren't available outside. Having said that, you could still run scans using programs like MalwareBytes or Microsoft Security Essentials on your XAP file itself and/or rename XAP to ZIP and unzip it to scan the files individually. Viruses stored within the XAP file could be read in by an app and then spread onto other platforms (even if it doesn't affect the phone itself. The requirements may be discussing that.
If your app isn't doing anything suspicious and doesn't use unsupported APIs, I personally wouldn't worry too much. Whilst there may be some false positives sometimes, I'm not aware of any particular tool that this section of the requirements specifically refers to.
Edit - I was reminded that there is a Store Test Kit but I didn't initially post that as it doesn't specify that it does a malware check. Good idea to run it nevertheless.
[What Store Kit Tells You]
Whether the XAP file meets size requirements and whether the app manifest file is valid.
Whether a Direct3D app that targets Windows Phone 8 uses APIs that are not allowed on the phone.
Whether a background agent app uses APIs that are not allowed with background agents.
What capabilities the app uses (for apps that target Windows Phone OS 7.1 only).
Whether the specified images and screenshots meet certification requirements.
Whether the app icon and background image used in the app meet certification requirements.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.