locked
How to check if a string is URI or a local file?

    Question

  • I tested that the file->Path returned from StorageFile is not a valide URI.

    So I have to deal with URI and Local File separately. 

    The question is how can I know any string is a valid URI or not.

    I cannot figure out the answer from URI class. Any help?

     

    Charlie Chang L

    Wednesday, September 19, 2012 7:07 PM

Answers

  • Using a StorageFile is the only way to achieve what you are asking for.

    StorageFiles represent more than just the file system and can read parts of the filesystem which a Windows Store app cannot access by path. Even if you get a path from StorageFile->Path that path may not be useful to you later since your app likely won't have permission to read from the path. The StorageFile will allow brokered access to areas that the app cannot read itself. This happens if the user granted permission through declared capabilities, pickers, etc.

    If you want to persist a StorageFile for later loading then use the Windows::Storage::AccessCache functions as demonstrated in the File access sample .

    --Rob

    Sunday, September 23, 2012 3:45 AM
    Owner

All replies

  • What are you trying to do with this? In general you would use the StorageFile directly rather than converting it to a Path.

    There is no guarantee that a StorageFile is backed up by a file system object and has a path or if it does that the app has access to read or write to the path's location.

    --Rob

    Wednesday, September 19, 2012 9:28 PM
    Owner
  • A special case is for 

    GetFileFromUriApplicationAsync() and GetFileFromPathAsync(). 

    One requires Uri and another requires Path. I can apply other ways to distinguish both. But a universal checking is better. Metro API may need to provide a universal processing based on URI for local or remote file processing. Unfortunately current API is fragment in this. 


    Charlie Chang L

    Thursday, September 20, 2012 12:14 AM
  • Hi Charlie,

    That doesn't make sense to me. You already have a StorageFile. Why do you want to use a lossy round-trip to get back to it?

    Can you please explain the overall scenario here?

    --Rob

    Thursday, September 20, 2012 12:43 AM
    Owner
  • I do not want to use StorageFile but was forced to use it because of FilePicker and Contracts. StorageFile is lack of some functions like persistence storage. It is not a database. I have to do convert between StorageFile and my SQL database. To store file name as URI is convenient and portable. But current ms-appx/appdata scheme solution is only a half solution. There are no ms-music, ms-documents .etc. And I can not define my own scheme. 


    Charlie Chang L

    Friday, September 21, 2012 3:52 PM
  • Using a StorageFile is the only way to achieve what you are asking for.

    StorageFiles represent more than just the file system and can read parts of the filesystem which a Windows Store app cannot access by path. Even if you get a path from StorageFile->Path that path may not be useful to you later since your app likely won't have permission to read from the path. The StorageFile will allow brokered access to areas that the app cannot read itself. This happens if the user granted permission through declared capabilities, pickers, etc.

    If you want to persist a StorageFile for later loading then use the Windows::Storage::AccessCache functions as demonstrated in the File access sample .

    --Rob

    Sunday, September 23, 2012 3:45 AM
    Owner
  • Nice. Get it work. But there are several restricts: 

    1. The maximum items are 1000 in Future list. I expect 1 million items.

    2. I can not share the database on other Win8 devices: all items are local storage file up onto my app. 


    Charlie Chang L

    Monday, September 24, 2012 11:03 PM