Restore Xamarin Studio, as well as the Android and iOS platforms

[jamesottaway]

#5099 (and later #5118) removed these three Casks because it was believed they couldn't be updated.

@Fapper: I originally created the XamarinPlatform cask because XamarinStudio is stuck at version 4.2.4, and seemingly will never be able to be updated past that because Xamarin have started to use this new installer that my cask uses, installing Xamarin Studio version 5 and above (I assume).

This isn't the case, so this PR restores the three individual Casks to allow direct installing of Xamarin Studio along with Xamarin.Android and Xamarin.iOS.

For the record, I use Charles (a web debugging proxy) to retrieve the direct download URLs for these three packages out of the general installer which Xamarin offer.

If any of this is unclear I'd be happy to clarify why I believe these Casks are the correct approach rather than the Xamarin one added in that other PR.

[jamesottaway]

@Fapper Feel free to chime in on this PR.

[martinbjeldbak]

I like your solution much better than mine. Didn't know that was possible... smart!

@vitorgalvao, filing to have my two pull requests reverted in favor of this pull request. Thanks for helping me make the casks, I learned a ton and will hopefully be able to use this knowledge for future casks.

[vitorgalvao]

Since you’re both in agreement, and you both use this (I don’t), I’m inclined to trust your judgement. However, I’m not sure this approach is the best one. You’re getting the apps in a manner that is not the one intended by the vendor. I feel that if we have to resort to sniffing traffic to find the url (and we can’t use one that always tracks the latest version), these will likely linger in comparison to Xamarin, which seems like a good argument to leave them in caskroom-versions (either way, they are still to remain, in one repo or another). Caskroom-versions is for alternate versions as much as older (and even newer/beta) versions, so it seems like these might fit.

I don’t feel strongly about it, however, and could certainly be convinced otherwise. This also bears some small resemblance to the recent Sketchup pull request, where @rolandwalker expressed a desire to break from our old pattern (where including all these would make sense), but we haven’t yet discussed specifics, so I’m requesting his input on this.

Either way, @jamesottaway, for these to be included back, I simply ask they be added as they were last, regarding stanza order.

[rolandwalker]

@jamesottaway and @Fapper, thanks!

@vitorgalvao I had not intended to create new policy in #5090, will have to review it. I don't worry too much over what goes into the versions repo, because one day those Casks can come back: if we implement a variants block, the alternate versions could be inlined.

The Casks in this PR don't install different versions of /Applications/Xamarin Studio.app. For example, xamarin-android.rb installs a framework to /Library/Frameworks/Xamarin.Android.framework/. So there is no reason to shift them out of the main repo.

As to sniffing the URL for the pkg file, not only do I not have a problem with that, I applaud it! Xamarin's meta-installer/downloader thing is just getting in the way of people who want to install from the CLI. There are probably also appcast URLs we can sniff to help track updates.

[vitorgalvao]

My concern with different versions of the same app was mainly tied to Xamarin and Xamarin Studio.

To be clear, I also have no problem with sniffing the traffic, and also found it an ingenious solution. My sole concern was with future updates, as we don’t want to chain @jamesottaway with the task of updating these indefinitely. Checking the urls again, however, they seem simple enough to update through deduction alone.

It’s settled, then. @jamesottaway would you mind restoring the stanza order, as mentioned, so we can merge this?

[jamesottaway]

Thanks for the feedback everyone.

@vitorgalvao: My sole concern was with future updates

Is it worth leaving a comment in the cask with information on to how to update it? It's a valid concern to be able to keep them up-to-date if or when I no longer can.

@vitorgalvao: My concern with different versions of the same app was mainly tied to Xamarin and Xamarin Studio.

Since these casks replace the Xamarin one that @Fapper created, I'll add a commit to this PR to remove it.

@vitorgalvao: would you mind restoring the stanza order, as mentioned, so we can merge this?

Done.

[vitorgalvao]

I think Xamarin shouldn’t be removed. After all, it is still a separate app, and there might be users who prefer to get these packaged the official way.

When I said “concern” I should’ve been clearer. I didn’t mean in the sense of conflicts — it’s pretty clear now that users won’t download both apps, they’ll get either one or the other — but was instead referring to one app being considered a version of the other. To clarify, in my latest comment I was referring to the concern I had in the comment prior to it, which is a concern I no longer have after @rolandwalker’s input. Does that make sense?

In sum, all four casks should remain, and yes, a comment would likely help. Something small like “The download url was discovered by sniffing Xamarin’s traffic”, it doesn’t need to be a full-fledged set of instructions.

[jamesottaway]

OK, I'll remove the commit to remove the Xamarin cask, and add a comment in the other three.

[jamesottaway]

I just realised that including the manifest URL would be ideal, so the comment now includes the URL which can be parsed to determine the download links.

[vitorgalvao]

Even better. That was exactly what @rolandwalker was referring to. Those can be added as appcasts.

Instead of

# http://xamarin.com/installer_assets/v3/Mac/Universal/InstallationManifest.xml
url 'http://download.xamarin.com/MonoforAndroid/Mac/mono-android-4.12.5-2.pkg'
homepage 'http://xamarin.com/android'

we can have

url 'http://download.xamarin.com/MonoforAndroid/Mac/mono-android-4.12.5-2.pkg'
# non-Sparkle appcast
appcast 'http://xamarin.com/installer_assets/v3/Mac/Universal/InstallationManifest.xml'
homepage 'http://xamarin.com/android'

appcast doesn’t do anything yet, but it will. The # non-Sparkle appcast is so it can be found later. The order in this example is already the preferred one. Would you mind this one last change?

[jamesottaway]

#4847 has been merged, so should I append :format => :unknown to the appcast stanza now?

Also, should I remove the "Discovered by sniffing the web traffic of the official Xamarin installer" comment above the URL now that it will live in the appcast stanza?

[vitorgalvao]

Yes, I believe you’re right on both accounts. The comment can go, and :format => :unknown can be used, instead of the comment.

[rolandwalker]

#4847 has been merged but not released, so most users don't have the code to support it. A comment is the best way, for the moment.

@jamesottaway, it is generous of you to work out all these details. Greatly appreciated here.

[jamesottaway]

Ah, of course. I'll put the # non-Sparkle appcast comment in there for now.

Should be good to go now!

[vitorgalvao]

Thank you for all your work on this. And thank you as well, @Fapper.

Merged.