One of my hobby projects, Beem, is a pretty successful DI.FM streaming application in the Windows Phone Marketplace. What I did in this application is basically read the existing Winamp/Windows Media playlist files and extract the MP3 feed, so that I can stream the music directly to the phone. It works out really nice, considering that the default stream format is encoded in a way that Windows Phone can recognize. The problem lies elsewhere - I am not using the documented API or anything like that. Instead, I rely on endpoints I managed to detect with Wireshark.
What's the danger of such a solution, you might ask? Changes come unannounced. Whenever Digitally Imported decides to modify the URL to the stream or to one of their track list service pages, the application is bound to become unusable. Or is it? Considering this aspect, I decided against hardcoding a list of endpoints in the application itself. Since the application requires an Internet connection anyway, why not download the list of used endpoints on application launch? Ultimately, I get this list:
Every single part of this list is downloaded from an XML file I stored remotely (no need for a separate service fetching it for now). That being said, I recently opened my inbox to get this email:
All I had to do to expand the list of stations in my app was adding three extra entries in the fetched XML file, and I was ready to go - with minimum effort I made sure that a couple of thousands of users get the updated station list instead of waiting for a Marketplace update that might take days to propagate.
If the XML file with the endpoints would be hard-coded in the package, I would have to submit a Marketplace update.
Conclusion: keep your application flexible and ready for changes with minimal effort. You still have to account for situations where you might need a local cache, since there is not always a connection available, but make sure that if an extreme situation arises - you can change the app workflow as fast as necessary.