Suppose I write
App.Current.Properties.Add("Crap", "123");
await App.Current.SavePropertiesAsync();
Where is my crap saved, on disk?
Properties are saved in Xamarin with
const string PropertyStoreFile = "PropertyStore.forms";
...
var stream = IsolatedStorageFileStream(PropertyStoreFile, FileMode.Create, isoStore)
Xamarin.Forms.Platform.WPF/Deserializer.cs
IsolatedStorage is a way for an application to store data that persists after closing, without having to specify where on disk it is saved. To find where yours is saved, go to C:\Users\$USER$\AppData\Local\IsolatedStorage and search for a files named PropertyStore.forms. It should be one of the results.
In Xamarin form because you project is a cross platform project you cant find one place on your disk for each platform is created by your compiler for example, in windows executable form you can put your Key/Value variable in multi different destination, Registry, App config, … or in android executable form, you can put your Key/Value on service that is provided by android OS and called "Preferences".
finally, where your Key/Value variables are saved depend on which platform you run your code.
if you want more detail, I suggest you watch this link https://github.com/aritchie/settings/tree/master/Acr.Settings/Platforms .
this link provide interface for store Key/Value Pair variable and implement in 4 different kind of OS that you prefer to run you project on it.
I supposed you need to understand how this is happen in UWP, because you tagged it. In this platform you can search for ApplicationDataContainer.
if you want to find out how this happen and where values saved on disk in android OS, you can watch this link that is provided by Microsoft docs
https://learn.microsoft.com/en-us/xamarin/essentials/preferences?tabs=android
Related
I'm trying to create a map viewer for an existing C# WinForms application. I've installed and hooked up the GreatMaps (GMap.net) controls no problem and that's all working fine. The quirk in this is that it needs to work offline (as it's an application that gets used by users who aren't always in locations where there's a mobile signal).
The offline cache mode works fine for GMap but, we've got to build the cache beforehand which we can do but, as we need the whole of the UK, will be a pain (especially as we have to go down to street level).
Does anybody know if there any existing cache files that we can download and use? I've looked at downloading OSM files but haven't got the faintest idea how to use them, convert them (into the gmdb format that GMap seems to use).
Any ideas?
Check out VectorTileRenderer (https://github.com/AliFlux/VectorTileRenderer) which has a demo for Gmap.net. All you need is an MBTiles file which you can download for free at OpenMapTiles.org (https://openmaptiles.com/downloads/europe/british-isles/)
I've read a few threads where this is discussed. Shai's response has always been that files can only be read, but not written into shared locations
Perhaps saving other type of files isn't so simple but shouldn't there be an option for saving pictures in CN1?
I haven't seen the Whatsapp Clone code, but if it truly is a clone shouldn't it have the option to share pictures (and possibly files). Or is it a simple text chat that perhaps shares pictures that can never be saved outside the app?
I also read somewhere (6 months ago) that Shai said that this should be a feature of CameraKit. Does this mean that this feature is in development? If so, that would be great. But having an ETA would also be great to align with our own devs
If it isn't being developed, can I at least know if this is something I can develop natively within CN1?
We expose the full file system so you can write to any place the native App can write to. Native apps don't have write access to the gallery directory and need to explicitly request it to put a file there. This can be accomplished easily in any external cn1lib (e.g. we could do it in camera kit) but haven't done it for camera kit or the whatsapp clone.
AFAIK there's no RFE open on this feature so I can't even tell you if it's assigned to a specific milestone.
Yes, I know. This question have been already replied in Where to store the Core Data file? and in Store coredata file outside of documents directory?.
#Kendall Helmstetter Gelner and #Matthias Bauch provided very good replies. I upvoted for them.
Now my question is quite conceptual and I'll try to explain it.
From Where You Should Put Your App’s Files section in Apple doc, I've read the following:
Handle support files — files your application downloads or generates and
can recreate as needed — in one of two ways:
In iOS 5.0 and earlier, put support files in the /Library/Caches directory to prevent them from being
backed up
In iOS 5.0.1 and later, put support files in the /Library/Application Support directory and apply the
com.apple.MobileBackup extended attribute to them. This attribute
prevents the files from being backed up to iTunes or iCloud. If you
have a large number of support files, you may store them in a custom
subdirectory and apply the extended attribute to just the directory.
Apple says that for handling support files you can follow two different ways based on the installed iOS. In my opinion (but maybe I'm wrong) a Core Data file is a support file and so it falls in these categories.
Said this, does the approach by Matthias and Kendall continue to be valid or not? In particular, if I create a directory, say Private, within the Library folder, does this directory continue to remain hidden both in iOS 5 version (5.0 and 5.0.1) or do I need to follow Apple solution? If the latter is valid, could you provide any sample or link?
Thank you in advance.
I would say that a Core Data file is not really a support file - unless you have some way to replicate the data stored, then you would want it backed up.
The support files are more things like images, or databases that are only caches for a remote web site.
So, you could continue to place your Core Data databases where you like (though it should be under Application Support).
Recent addition as of Jan 2013: Apple has started treating pre-loaded CoreData data stores that you copy from a bundle into a writable area, as if they were a support file - even if you write user data into the same databases also. The solution (from DTS) is to make sure when you copy the databases into place, set the do-not-backup flag, and then un-set that if user data is written into the database.
If your CoreData store is purely a cache of downloaded network data, continue to make sure it goes someplace like Caches or has the Do Not Backup flag set.
In our Silverlight business application, we need to cache very large files (100's MBs) into isolated storage. We distribute the files separately to be downloaded by users and then they can import those files into Isolated Storage through the application.
However, the Isolated Storage API seem to be very slow and it takes an hour to import about 500MB of data.
Given, that we're in a corporate environment where users trust us, I would like users to be able to copy the files directly into the physical location on their file system where Silverlight store files when using the API.
The location varies per OS, but that's ok. The problem however, is that Silverlight seems to store files in a somewhat cryptic way. If I go to my AppData\LocalLow\Microsoft\Silverlight\is, I can see some weirdly named folder that look like long Guid.
My question: is it possible to copy files directly in there, or is it going to upset Silverlight ?
From what I've been testing it will make stuff fail/act weird. We had some stuff we had to clear and even though we did delete the files to test how it worked the usedspace didn't drop. So there is some sort of register of which files are in IS and how big they are.
I think it would be paramount you find out why IS is so slow. Can you confirm its like that on all clients? Test some others. This should be brought up to Microsoft if it is the case. Possibly you can change your serailization schema and save smaller files? I would not advise trying to figure out Microsoft's temporary and volatile IS storage location.
A call to all Win32 developers... I'm developing an application in C using plain Win32. I wanted to ask about Windows development standards regarding these things:
Is there a standard Windows error log api? For example if my client uses my app and it crashes, I would like them to send me the error log and I would prefer this being a standard location so they can maybe access it with a standard Windows log utility.
My app needs to store settings information. I think the registry is the standard utility for this task. Is that right?
My app needs to store and retrieve files that it downloaded from the internet - images, executables etc. Is Application Data/myapp the standard location to store this type of information?
My app needs a very straight-forward database - I'm using CSV for this. I basically need to store and retrieve this type of data so I'm just serializing a .csv file from Application Data/myapp. Is there a better Windows standard way of doing this?
That's all for now :). Thanks!
Is there a standard Windows error log api?
There is the Windows Event Log, but I don't think you want a typical user having to go into it to extract your logged information.
You probably don't want to log by default, unless you're shipping questionable pre-release code. When a user is experiencing problems, then you have them turn logging on. In this case, I recommend placing the file somewhere that typical users have experience with, like My Documents.
By the way, if you're writing a standalone application and want the best possible information in the event of a crash, look into minidumps. Here is a Codeproject sample.
My app needs to store settings information
Yep, registry.
My app needs to store and retrieve files
Yes, App Data. Just be sure to use SHGetFolderPath and CSIDL_APPDATA.
My app needs a very straight-forward database
There's nothing wrong with CSV for simple data. You could store the data in XML and use MSXML to process it, if you prefer. I've used SQlite in the past when I needed fast, lightweight storage of more complicated data.