This is where patterns like MVVM come in. You model, view and
viewmodel don't change (or change very little). But your view (which
sits above the viewmodel) changes a lot.
It's not an easy thing to design, but it's better than c# + java + obj-c
On Wed, Aug 10, 2011 at 13:39, kbudris wrote:
> I
ges some things like GETDATE() to datetime('localtime', 'now) or
something like that. (well, I'm panning to change db to sqlite on windows
mobile to be things more easy).
Karl
From: Robert Jordan
Date: Wed, 10 Aug 2011 14:56:24 +0200
To: "monotouch@lists.ximian.com&qu
On 10.08.2011 14:39, kbudris wrote:
> I've only worked with MonoTouch so far... haven't yet needed to work on
> Microsoft or Android devices. Just how portable is a MonoTouch app to
> Android? I can see where I might be able to reuse the data model, but the
> entire presentation layer seems so Appl
I've only worked with MonoTouch so far... haven't yet needed to work on
Microsoft or Android devices. Just how portable is a MonoTouch app to
Android? I can see where I might be able to reuse the data model, but the
entire presentation layer seems so Apple-specific. Wouldn't the entire UI
need to b
On 10.08.2011 12:48, Jon Hopkins wrote:
> The bottom line is we have no real benchmarks. 1:1 code mapping can prove
> some things, but
> Its not a given that there is no performance difference, yet.
> I would like to see some hard figures that do show this, to convince clients
> that there is no
The only way to do that is to write something non trivial in both, and
look at the perf results.
Be sure to tell them it took you 5x or more longer to write in Obj-C,
with no possibility to port to other platforms without a full rewrite,
with the potential for nasty memory-related crashes
O
The bottom line is we have no real benchmarks. 1:1 code mapping can prove some
things, but
Its not a given that there is no performance difference, yet.
I would like to see some hard figures that do show this, to convince clients
that there is no
Reason to use objective c over monotouch.
___
y solution is to look at the
> difference, and when bigger than 1 page, to manually add the missing view,
>
>
>
> Thanks,
>
> Jon
>
>
>
> Von: Jeff Stedfast [mailto:j...@xamarin.com]
> Gesendet: 09 August 2011 20:32
> An: Jon Hopkins
> Cc: monotouch@lists.ximi
view,
Thanks,
Jon
Von: Jeff Stedfast [mailto:j...@xamarin.com]
Gesendet: 09 August 2011 20:32
An: Jon Hopkins
Cc: monotouch@lists.ximian.com
Betreff: Re: [MonoTouch] Performance cost of MonoTouch vs. Objective-C
My *guess* would be that perhaps the GC thread is getting in the way
here, t
issues.
Karl
From: Jeff Stedfast
Date: Tue, 9 Aug 2011 14:31:42 -0400
To: Jon Hopkins
Cc: "monotouch@lists.ximian.com"
Subject: Re: [MonoTouch] Performance cost of MonoTouch vs. Objective-C
My *guess* would be that perhaps the GC thread is getting in the way here,
trying ha
My *guess* would be that perhaps the GC thread is getting in the way here,
trying hard to clean up all the removed objects.
A common trick to work around this problem is to try and re-use your heavier
objects used in this scenario to try and limit the amount of work the GC has
to do. How hard this
: [MonoTouch] Performance cost of MonoTouch vs. Objective-C
you may need to drop to doing this
http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/
http://mikebluestein.wordpress.com/2009/11/08/fast-scrolling-a-uitableview-in-monotouch/
On Tue, Aug 9, 2011 at 08:43, Jon
m
> Betreff: Re: [MonoTouch] Performance cost of MonoTouch vs. Objective-C
>
> Hrmmm:
>
> Simulator: 2.5ghz quad core.
> iPad: 1ghz (or less?) single core.
>
> should explain most of that.
>
> On Tue, Aug 9, 2011 at 08:03, Jon Hopkins wrote:
>> My Magazine App runs fine
Betreff: Re: [MonoTouch] Performance cost of MonoTouch vs. Objective-C
Hrmmm:
Simulator: 2.5ghz quad core.
iPad: 1ghz (or less?) single core.
should explain most of that.
On Tue, Aug 9, 2011 at 08:03, Jon Hopkins wrote:
> My Magazine App runs fine in the simulator, and ok in normal use on the
>
Hrmmm:
Simulator: 2.5ghz quad core.
iPad: 1ghz (or less?) single core.
should explain most of that.
On Tue, Aug 9, 2011 at 08:03, Jon Hopkins wrote:
> My Magazine App runs fine in the simulator, and ok in normal use on the
> Ipad, but when you scroll too
>
> Fast, it leaves blank pages which al
My Magazine App runs fine in the simulator, and ok in normal use on the
Ipad, but when you scroll too
Fast, it leaves blank pages which all my optimisations cannot seem to
fix. The code seems to work fine,
But just not performant. It uses dynamic adding and removing of views on
a UIScrollView.
> Since image processing is largely CPU intensive (and normally done using
> SIMD - which, sadly, MonoTouch does not support (maybe a feature for a
> future version?)), this might be a task best suited for a native library or
> something. Then again, maybe Apple's CoreImage does what you need, in w
As with anything, "it depends".
File I/O should be as fast as buffered native I/O (I did a fair bit of
testing of this for Mono a few years ago).
Most of what apps do is spent idling waiting for user events and idle time
is idle time and using the MonoTouch APIs is (for the most part) just a thin
How about once the app is launched? Does using MonoTouch impose a performance
overhead at runtime? Will things like file I/O or image processing be slower
in MonoTouch than in Objective-C?
--
View this message in context:
http://monotouch.2284126.n4.nabble.com/Performance-cost-of-MonoTouch-vs-Obj
Just to add, MonoTouch 4.1 should improve things a fair bit. The size of
apps should be considerably smaller (the linker is a bit smarter and will
remove more unused API) and startup time is greatly reduced (depending on
what you do in your FinishedLaunching() override.
Jeff
On Mon, Aug 8, 2011 a
Not official, but:
http://www.shrinkrays.net/code-snippets/csharp/monotouch-tips-and-snippets.aspx
"Masking the startup time of Monotouch
When you build a Monotouch application with a provisioning license
(whether for the appstore or not), the startup time is generally
around 1-2 seconds. The Mo
Does Xamarin have an official statement on this in the kind of concise yet
technical format that would satisfy a skeptical CTO?
--
View this message in context:
http://monotouch.2284126.n4.nabble.com/Performance-cost-of-MonoTouch-vs-Objective-C-tp3715348p3726872.html
Sent from the MonoTouch maili
I've not done any actual work, however in the past, it's been very
little. It can't be zero, 'cos monotouch is "extra", but it's as close
to zero as you can get.
Geoff commented in the past that load time depends more on what you do
during load, than the framework - an MT app can spin up quicker t
Has anyone done benchmarking of an app implemented in MonoTouch vs.
Objective-C to determine what, if any, performance cost we pay for the
convenience of MonoTouch? Do we take any hit on launching and/or running a
MonoTouch app?
--
View this message in context:
http://monotouch.2284126.n4.nabble.
24 matches
Mail list logo
