Why using an error prone URI for Windows Phone Navigation Service [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

Every Windows Phone developer might be familiar with the NavigationService and the way a URI is used to navigate to the specified content, i.e.:

 NavigationService.Navigate(new Uri("/Views/DetailsPage.xaml?selectedItem=" + selectedItem.ID, UriKind.Relative));

But is there an explanation for WHY it is this way?

The issues about the safeness when using it are:

• If you rename/move/refactor a class, the URI won't work anymore. Same with properties.
• You have absolutely no validation if the specified Page or the Properties exist
• Even though this is the standard mechanism for page navigation, why doesn't the IDE at least validate relative URIs to check if the classes and properties fit?
• Why doesn't anyone seem to care?

Compared to e.g. Android and iOS, both provide at least more type safety, or am I missing something here?

Answer 1

The explanation is quite simple: Silverlight.

Silverlight implements an URI-based system for obvious reasons: the framework has been designed to be executed inside of a web browser, and therefore it makes deep-linking easier to implement (that is: opening a specific page of the Silverlight application depending on the requested URI in the web browser).

Windows Phone's runtime is based on Silverlight, so the same system simply remained. Note that it isn't a bad thing. Sure, if you stop at the navigation service, it looks like we're losing type-safety for no benefit. But if you consider that your application can be launched from a secondary tile, or since WP8 from a custom URI scheme, it suddenly all makes sense.