Hi Guys

I totally agree with the no dependencies route.

The reason for the request was principly for enterprie base
deployments. For example for our app, we know what api level we are
working on, we know the hardware , we know the user wont be updating
the device. So a Shared Release runtime that is installed directly
(not via the market) seems like a sensible solution. App updates then
shrink from a few meg to a few hundred kb, which when downloading from
cloud storage over 3G is a big saving.


the bundled app for the market is correct and I think having a shared
runtime on the market would be a nightmare.

Regards

Dean

On 17 February 2012 16:59, Roy Goode <r...@roygoode.com> wrote:
> Thanks Jon for taking the time to respond, it's a great answer!
>
> I really just threw the question out there - I actually really appreciate
> the no-dependencies approach of embedding the runtime in the app. It makes
> updates a whole lot easier. e.g. on Windows Mobile, rolling out .NET Compact
> Framework patches / updates across the organisation was always a nightmare.
>
> On 14 February 2012 13:34, Jonathan Pryor <j...@xamarin.com> wrote:
>>
>> On Feb 9, 2012, at 7:39 PM, Roy Goode wrote:
>> > I wonder if it's possible to make the official Shared Runtime as an app
>> > released on the Android Market as an alternative to the bundled runtime?
>>
>> <Insert maniacal laughter here>
>>
>> In theory, there's nothing [0] preventing this. In practice, we haven't
>> gone two releases without having some form of API/ABI break. We are working
>> on improving that (hopefully 4.2 will be the last release which breaks API
>> in an incompatible manner), but I don't hold out much hope for things being
>> "stable" long enough for a shared runtime package to be plausible on the
>> Android Market, not anytime soon.
>>
>> This isn't to say that these things aren't insurmountable. I just wouldn't
>> expect it anytime soon. :-)
>>
>>  - Jon
>>
>> [0] except for gigantic app sizes and user complexity [1]... The
>> Mono.Android.DebugRuntime-debug.apk package, containing BCL + ARMv5, ARMv7,
>> and x86 runtimes is "only" 25MB in size. We already have requests for MIPS
>> support, which will make that larger still, and then there's the per-API
>> level Mono.Android.Platform.apk, which is another 12-16MB. Assuming the end
>> user only downloads apps which require a single API level, you're still
>> requiring that they download 37+MB just to run your app, as opposed to the
>> ~2+MB size that is currently required.
>>
>> [1] Then there's the user complexity side. We'd either need to have a
>> "bootstrap installer" embedded into apps to direct the user to the Android
>> Market to download the packages, or you'd need to document that they
>> download _three_ packages -- Runtime, Platform, and App.
>>
>> _______________________________________________
>> Monodroid mailing list
>> Monodroid@lists.ximian.com
>>
>> UNSUBSCRIBE INFORMATION:
>> http://lists.ximian.com/mailman/listinfo/monodroid
>
>
>
> _______________________________________________
> Monodroid mailing list
> Monodroid@lists.ximian.com
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
_______________________________________________
Monodroid mailing list
Monodroid@lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid

Reply via email to