I have an 8.1 app in the Windows Store and it is currently being bought and used by customers. I have made some changes to the app that I want to deploy out to my testers. From what I've read, I should update the app and set it's distribute and visibility to Hide and Prevent Acquisition so that only my testers can download it.
If I change the visibility in the update, does that mean that no one can download the previously deployed version anymore? The goal here is to involve testers in an automated fashion via the store without affecting the app in production until it's been tested and approved.
As far as I know, you can't do that.. if you, this will effect the whole submission (even the public)..
What I suggest to do (and all the beta apps providers are doing including me) is to create another app -submission- marked as preview and thought this you can submit any beta versions, and when a release is ready.. you can push the last beta to the public app :) .
Related
I'm developing a line of business app for Windows 8.1, that is, I am not deploying through the Windows Store and will be able to control all of the features of both the OS and hardware this app is being deployed on.
Because this app is working as the UI in a real-time situation I would prefer if I could ignore the life-cycle events and not have the app suspend or terminate at the whim of Windows 8. Does anyone know of a way to do this?
I have seen some older answers, such as this one and this other one indicating otherwise, but I haven't yet found anything more recently and specifically dealing with the case of a line of business app. I have found the Embedded Lockdown Manager which would prevent the app losing focus and addresses some of the needs I have, but I still would like a way to simple disable Lifecycle events.
Have you tried Assigned Access Mode? Basically use PC Settings -> Accounts to lock an account to a single app. You have to reboot the device and log-in again in order to run anything else.
I'm working on modern Windows 8 app and wanted to figure out if Windows.Storage.ApplicationData.current.localSettings (msdn doc is here) get cleaned up when the app gets updated by the store.
Those settings are preserved across app updates, as are the roamingSettings and the contents of localFolder, roamingFolder, and tempFolder. In other words, performing an app update does not affect any of the appdata state, which makes perfect sense when you consider that many updates are minor bug fixes and should not in the least way require resetting or migrating existing state.
Do note that uninstalling an app and then reinstalling it will clean out localSettings, localFolder, and tempFolder. roamingSettings and roamingFolder will be restored provided that the user has had the app installed on another device within some reasonable period of time (unspecified, but something like 30 days).
It's also good to know that app state has its own versioning scheme through ApplicationData.setVersionAsync, and that an app update can choose, if it wants to migrate appdata from one version to another. Examples can be found in the Application Data sample.
No, your local settings will persist between app updates.
In Windows Phone Store for Windows Phone 8.1 OS are applications with or without the with Live Tile sign under logo in app overview.
Which criteria must the application meet to be detected by Store as it supports Live Tile?
I know that the answer should be obvious – it must support Live Tile, but it is not as simple as it looks like. My app is not detected as it supports Live Tile.
It calls PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync, uploads the PushNotificationChannel.Uri to the server and the server sends tile updates via WNS. The tile is regularly updated.
It contains all scales of all visual assets.
Contacted MSFT Support:
There is no explicit check. The flag is set during manual instigation
of the app in the publishing process.
As the app submission has been changed to publish your app immediately, this flag will only come up once your app is manually checked. That usually only happens some days after your app is published and only in rare cases for updates (or when somebody complains about your app).
Also: The tester has to notice that there is a live tile. If it comes through push or there is no data at the moment of testing or it requires a specific setup, that will just not be visible.
I recommend hinting your live tile in the certification notes field (under describe your package) to make sure the tester is informed that you have a live tile option.
Most probably the Store show the with Live Tile tag for Silverlight (XAP) apps but not for Store (Runtime) apps.
I need help with publishing an app me and my team developed. It currently is in beta phase and we need testers. We thought of publishing it in the store as an open free beta app and ask for people to download it and report their bugs. After all the testing bugs are fixed the app will go public as v1.0 but not as free. We do however want the people who originally downloaded it to get all the updates for free as a reward for their help of testing our help and never have to pay for the app. How can that be done?
As you probably know Beta App is different than 'Normal' App - so after finished test you need to publish new application (you can't change beta to normal).
What you are asking is called targeted distribution - you can hide App (you will need to submit one more App for that purpose) from users browsing the store, and send a link to those who you choose (Beta testers). But you cannot prevent such a situation when a beta tester send this link to other person. So you have to cosider it.
EDIT
You cannot do such a thing like in beta version - create a list of user that will be able to use it.
The other solution that comes to my mind - you can create 'Beta' App that is the same as Normal App and alow specific user to use it. The disadventage of this method is that Beta expires after 90 days.
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.