Calling GC.Collect hangs on LG GT-540 with Android 2.1. Works properly on
other devices I have.
Model number: LG GT-540
http://www.lg.com/uk/mobile-phones/all-lg-phones/LG-android-mobile-phone-GT540.jsp
Firmware version: 2.1-update1
Kernel version: 2.6.29
Software version: GT540-V20b-SEP-13-2010
I've been trying to port https://code.google.com/p/android-calendar-view/
I am well on the way, just needs some tweaks to show up calendar
values on the view.
https://github.com/Cheesebaron/MonoDroid.Calendar
Not sure when I get time to port the rest, but feel free to use the
code to finish the
Here's a screenshot of my emulator settings:
http://mono-for-android.1047100.n5.nabble.com/file/n5523239/screenshotuc.png
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Not-enough-storage-space-tp5523204p5523239.html
Sent from the Mono for Android mailing list ar
Hey, I am trying to display rectangle and put texture on it. The problem I
get is white screen, even if OpenGL ES error is all the time 0 (so no
error).
Here is my code:
public class Mesh
{
float[] _Vertices;
short[] _Indices;
byte[] _Colors;
float _xTrans;
Guys ever since I upgraded to 4.0.4 I am now getting a "not enough storage
space on device to deploy package" error.
I am starting the emulator from within Visual Studio.
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Not-enough-storage-space-tp5523204p5523204.htm
Has anyone ever successfully created a Widget with MfA with a configuration
activity?
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Setting-Configuration-activity-for-Widget-tp5506245p5523048.html
Sent from the Mono for Android mailing list archive at Nabble.com.
On Feb 28, 2012, at 12:53 PM, Miroslav Pomšár wrote:
> Sorry to jump in, but what is the reason Mono.Data.Sqlite is not supported on
> Android 2.1?
Because it broke when I tried to use it on the Android 2.1 emulator. ;-)
More specifically, it's because the libsqlite.so that's included with Andro
Hi,
Sorry to jump in, but what is the reason Mono.Data.Sqlite is not supported on
Android 2.1?
Miro Pomsar
-Original Message-
From: monodroid-boun...@lists.ximian.com
[mailto:monodroid-boun...@lists.ximian.com] On Behalf Of Jonathan Pryor
Sent: Tuesday, February 28, 2012 17:24
To: Disc
On Feb 28, 2012, at 2:41 AM, James Briant wrote:
> MT is 4.0. MfA is 3.5.
I don't understand what you mean here. The Base Class Library (BCL) that
MonoTouch and Mono for Android provide are a superset of Silverlight (2.0? 3.0?
not entirely sure anymore), and use assembly version 2.0.5.0. There a
Thanks, my fault.
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Would-you-recommend-Android-Database-Sqlite-or-Mono-Data-Sqlite-tp5519867p5522379.html
Sent from the Mono for Android mailing list archive at Nabble.com.
__
On Feb 28, 2012, at 11:11 AM, tsukrov wrote:
> You wrote above, that we cannot use Mono.Data.Sql on Android 2.1, aren't you?
Correct, you can't use Mono.Data.Sqlite on Android 2.1, but you can use
Android.Database.Sqlite on Android 2.1 and later. You had mentioned that
Android 2.1 holds 7-10% of
Sorry? I didn't understood your reply.
You wrote above, that we cannot use Mono.Data.Sql on Android 2.1, aren't
you?
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Would-you-recommend-Android-Database-Sqlite-or-Mono-Data-Sqlite-tp5519867p5522300.html
Sent from the
On Feb 28, 2012, at 10:45 AM, tsukrov wrote:
> Yup. Android 2.1 is still 7-10% of the market.
Targeting Android 2.1 will allow you to run on anything later than Android 2.1
as well, which is significantly larger than 7-10%. :-)
- Jon
___
Monodroid ma
> Is it 2x slower?
The benchs of the developer.
http://code.google.com/p/csharp-sqlite/wiki/Benchmarks
http://code.google.com/p/csharp-sqlite/wiki/Benchmarks
Not that we need the last CPU tact.
Yup. Android 2.1 is still 7-10% of the market.
So csharp-sqlite is the only portable solution.
Thank
On Feb 28, 2012, at 5:55 AM, tsukrov wrote:
> * Csharp-sqlite (2x slower)
Is it 2x slower? I haven't done any performance testing/comparison, so I have
no idea.
If you need Android 2.1 support, then that is the option: Android.Data.Sqlite
or csharp-sqlite. Use whichever makes your life easier.
On Feb 28, 2012, at 4:52 AM, Danny wrote:
> Am I correct in thinking the supported alternative is
> android.media.mediaplayer ?
Yes, Android.Media.MediaPlayer should work.
- Jon
___
Monodroid mailing list
Monodroid@lists.ximian.com
UNSUBSCRIBE INFOR
Thanks for help:)
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/System-IO-Stream-Length-not-supported-tp5520446p5521422.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
M
Hi!
We need Android 2.1.
So either:
* Not portable Android.Data.Sqlite
or
* Csharp-sqlite (2x slower)
Isn't it?
--
View this message in context:
http://mono-for-android.1047100.n5.nabble.com/Would-you-recommend-Android-Database-Sqlite-or-Mono-Data-Sqlite-tp5519867p5521482.html
Sent from t
So, there's this:
http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981
Portable Library Tools.
On Mon, Feb 27, 2012 at 11:41 PM, James Briant wrote:
> MT is 4.0. MfA is 3.5. You'd think it doesn't make much of a difference
> but if my libs are 3.5 NUnit wont run t
Thanks for cleaning that up, you could always have OpenAL calls throw a not
implmented.
I assumed because the namespace was there that it was working. Am I correct
in thinking the supported alternative is android.media.mediaplayer ?
Thanks :)
--
View this message in context:
http://mono-for-andr
Hi
On 2012.02.28 09:56, James Briant wrote:
On Tue, Feb 28, 2012 at 12:50 AM, Miljenko Cvjetko
mailto:mcvje...@holisticware.net>> wrote:
Why would partial classes be problem?
It is just splitting code into multiple files
Its no different than having #if/#endif, which you agreed w
Hi
On 2012.02.28 09:04, Stuart Lodge wrote:
I like that Norway flights example - wish I'd seen that earlier!
I've personally found that as long as you put as much of your code as
possible into the shared ViewModel and lower classes (Model, Services,
BL, DAL, whatever, ...) inside their own pr
On Tue, Feb 28, 2012 at 12:50 AM, Miljenko Cvjetko <
mcvje...@holisticware.net> wrote:
>
> Why would partial classes be problem?
> It is just splitting code into multiple files
>
Its no different than having #if/#endif, which you agreed was bad in your
earlier email. But instead of the compiler
Hi
Its not something that they can reasonably solve without a complete
model change, and then I suspect that they would still run into the
fundamental problem that Visual Studio itself will not open the same
file twice, in the context of two different projects. That's the
infamous "This file i
Howdy
On 2012.02.28 04:18, Felix Collins wrote:
The different platforms can be in the same solution except for
MonoTouch which can't be compiled on PC. We have out shared app code
in three projects named something like MyApp (for a .net/mono console
version), MyApp.MD (for android) and MyApp.M
Hi
On 2012.02.27 15:26, Stuart Lodge wrote:
I'm with you on some of the refactoring pain thing.
I'm work 95% of the time in VS2010 using your plugin to make R# do
something. I'm currently sharing as much code as I possibly across all
3 platforms by trying to use mvvm with all viewmodels, model
Hi
On 2012.02.27 14:13, Jamie Briant wrote:
Is this as good as it gets? I'm attempting to build an MfA version of
my MT app and its proving extremely frustrating, to the extent that
I'm considering just writing the thing in Java. My reason for using MT
was the awfulness of Objective-C, and whi
I like that Norway flights example - wish I'd seen that earlier!
I've personally found that as long as you put as much of your code as
possible into the shared ViewModel and lower classes (Model, Services, BL,
DAL, whatever, ...) inside their own project, then refactoring isn't too
painful - it's
28 matches
Mail list logo
