I need to make a certain setting stay on the device even when the app itself has been uninstalled. For iOS we are using user's keychain to store this information. Is it possible on WP8 somehow?
If you want to keep, let's say user settings after an app is uninstalled, I highly doubt that this is possible on Windows Phone. First of all it would create a lot of orphan files on the phone that you would not be able to get rid of. One of the services on Windows Phone is Package Manager. This manager is in charge of installing/uninstalling apps, keeping track of what is pinned to the start screen and other metadata about an app and any extensibility points like Share..., etc. If you uninstall an app this manager should clean everything related to you app, even your user settings in any file or IsolatedStorage that you create.
iPhone and Android give you an ability to use some sort of file manager to explore your phone. As far as I can remember you could use Putty to connect to your phone to see the folders and stuff. In Windows Phone you cannot go this far. There are some tools like Windows Phone Power Tools that you can use to check the installed apps, but that's about it.
Apps and all their related data are stored in sandboxed folders. When an app is uninstalled this whole folder is deleted. As such this means that all saved data is removed.
There are two, probably non-ideal, workarounds.
You could create an image saved in the users photo library. You could embed the identifier in the image or it's name but the user has control of these images and may delete it. You also can't programmatically delete such files so you may end up with lots on the device. Having lots of "rogue" files on a device is also likely to cause a user to tidy them up (delete them).
You could store a record of the setting, linked to the device on a web server. This has the downside of needing to maintain the server and handling data sync and offline scenarios.
Related
I'm testing my Win32 app converted to UWP, so I'm new to the whole Windows 10 Store concept.
So far I was able to get my app certified & published in the store via a private link. Now I would like to download and test it, but there's an issue.
The first time someone sees the app it has the following options:
but once you get it, all you see is this:
and even if you log in under a different Microsoft account (on the same computer), or previously uninstall the app, you get this:
and "free trial" simply installs it w/o a trial in that case.
So my question is, how do I make Windows Store "forget" that I have this app?
If you have bought the app you can't undo that, but you can always create a new user who has never bought for the testing purpose.
EDIT: Windows Store is for real transactions and not for testing. If you want to test, you should have a custom build that uses CurrentAppSimulator instead of CurrentApp
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've an embedded system which runs firmware and has USB mass storage with size 79kB. So when you plug in the device to any computer(MAC/Windows), it pops as a 79kB flash drive. The firmware creates files which has transaction records. The objective is to display these transactions (tables and simple graphs) to the user. I've narrowed down to a web browser. So the user (with MAC/Windows PC) can plug in the USB device mass storage and open an HTML file in the mass storage drive and view all the transactions in the form of tables and simple bar graphs. The tricky part comes here: the device(firmware) needs to update it's clock, and this time input has to be sourced from the MAC/Windows PC. How can this be achieved?
This is the minimum requirement. Further, through the web browser the user wants to write some configuration parameters for e.g. through a text box and a submit button in the HTML page.
NOTE: Here the device has USB mass storage type and the web browser approach were selected so that there is no prerequisites for the user.
Please suggest an alternative if this can be done using another approach for e.g. a different class of USB or some other application locally available on MAC/Windows desktop/laptop. For e.g. the application should run on both on Mac and Windows i.e. the code should be the same but can be built into separate packages one for Mac and the other (.exe) for Windows. Please suggest a platform for this that has same source but can be built for both mac and windows. Thanks!
As far as I know, there is no way a web browser could write to a file. If such a thing was possible, it would be a huge security issue.
You have to write a piece of native software to do all the tasks you name. That can be done in pretty much any programming language, and if you're developing embedded systems I reckon you must have some experience in programming.
I'm looking at doing something similar and have an idea, though you may be better equipped to run with it than I am. Have the define contain a directory called "SET_DATE" with files "YEAR15" through "YEAR99", "MON01" through "MON12", "DATE01" through "DATE31", "H00" through "H23", "M00" through "M59", "S00" through "S59", and "SET"; each such file should start at a different sector, though none of the sectors in question need to contain any data (they need not physically be stored anywhere). To set the date to July 4, 2020 at 12:34:56pm, read the following files in sequence:
SET_DATE/YEAR20
SET_DATE/MONTH07
SET_DATE/DATE04
SET_DATE/H12
SET_DATE/M34
SET_DATE/S56
SET_DATE/SET
The last access should cause the unit to set its clock. If a user might want to set the clock more than once, that could be accommodated by either having a bunch of essentially-identical directories under SET_DATE (so setting the date the first time would use SET_DATE/00/YEAR20, the second time SET_DATE/01/YEAR20, etc.) and/or having the drive unmount/remount itself if necessary to clear out any caching.
I would think it unwise to have directory fetches trigger actions, since Windows or an anti-virus tool might decide to pre-cache all the directories in a drive when it is mounted. I would not expect Windows or a browser to eagerly load files, however, so I would think one could have read accesses trigger actions.
I would like to change the Packages directory location or add a new one (to be on network drive.)
I can't use the symlink.
I had a look on the plugins, but can't find.
I am on Windows Vista, Windows 8 (soon.)
Thank you for your help.
Christophe
If a moderator could please turn this post into a comment, because it is only a potential workaround to the issue (rather than a complete solution).
Using an OSX operating system, I am automatically backing-up (to Dropbox with a symlink) the entire SublimeText2 folder and subfolders within the application support directory. Inasmuch as Dropbox works on different platforms, perhaps this will give the original poster some ideas to have multiple computers using the same Packages data. I am successfully using this method to automatically synchronize all three (3) of my computers -- i.e., if anything changes on one computer in the Packages directory or subdirectories, then all computers are automatically synchronized.
Of course, back up your data on each computer before trying out this method.
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.