Hi Jon,
-Original Message-
From: monodroid-boun...@lists.ximian.com
[mailto:monodroid-boun...@lists.ximian.com] On Behalf Of Jonathan Pryor
Sent: dimecres, 30 / novembre / 2011 15:40
To: Discussions related to Mono for Android
Subject: Re: [mono-android] Trouble with Android.Graphics
>
>It
On Dec 1, 2011, at 5:13 AM, Narcís Calvet wrote:
> Thanks! Actually I tried that before but this method is giving memory
> consumption problems as well. I try compressing images to save memory but
> objects used in this method consume more memory than what it's freed so I
> compression code is work
Hi Jon,
-Original Message-
From: monodroid-boun...@lists.ximian.com
[mailto:monodroid-boun...@lists.ximian.com] On Behalf Of Jonathan Pryor
Sent: dijous, 1 / desembre / 2011 12:57
To: Discussions related to Mono for Android
Subject: Re: [mono-android] Trouble with Android.Graphics
>
>Toss
I noticed in the limitations of Mono for Android it lists 3rd party JAR
files.. Is there any way to wrap third party JARs for reuse? For instance if I
need to write some custom code in Java (say for an API that wasn't wrapped for
some reason).. or I wanted to reuse a component like ChartDroid.
On Dec 1, 2011, at 10:32 AM, Josh Handel wrote:
> Is there any way to wrap third party JARs for reuse?
In a future release we'll be providing better tooling for 3rd party .jar files.
Unfortunately it couldn't be stabilized in time for the next release.
(Timeframe _should_ be early next year, but
Hi Josh
You'll have to write JNI wrapper and drop them in as Java Source files. There
are a few examples floating around, and it is a little fiddly. As a heads-up
I'd recommend using JAVAP (with the -s option IIRC) to extract the method info
if you are having trouble getting the parameter str
Thanks guys for the feedback.. Really where I am right now in my evaluation, i
just need to know if it can be done or not.. Sounds like the answer is yes...
:-P.. I'll do some digging for examples but its not important to my POC right
now.. The absence of the capability would be an issue, but if
I believe that this will be fixed in the next release. I apologize for the
delay.
- Jon
On Nov 2, 2011, at 2:17 AM, Nirban Dutta wrote:
> Hi Jon,
>
> Yesterday I have attached the demo project to the bug as required by you.
>
> http://bugzilla.xamarin.com/show_bug.cgi?id=1741
>
>
> Cou
I think ultimately what could help you the most is android x86 (this is not
supported yet i beileve, but is probably more useful than many realise for
people that don't own an android device). Android ARM is very slow in
emulating (where as iphone has an awesome emulator).
I would also recommend d
FYI : I roll with SSDs in all my laptops (mac and windows) so its not a drive
issue.. :-P
Josh Handel
Senior Lead Consultant
512.328.8181 | Main
512.328.0584 | Fax
512.577-6568 | Cell
www.catapultsystems.com
CATAPULT SYSTEMS INC.
THE MICROSOFT CONSULTING COMPANY
Thanks, your comments below are pretty much what I have come to accept as the
reality of Android development.. Though Eclipse/Emulator isn't that bad,
Mono/Emulator is impossibly slow. Ximian needs to come up with a way to let
us test drive on a device.. Because I promise they are loosing sale
Thanks Jon. Yeah, I had figured this stuff out. I'm not quite sure what was
happening that day. The next morning I came in and boom, it was all there
working. Made me feel foolish, but its not the first time.
Wally
On Nov 30, 2011, at 7:11 PM, Jonathan Pryor wrote:
> You may have figured t
Not sure if this workaround is known, but I've solved the slowness of the
simulator the next way:
I use ubuntu as a host system for running android emulator,
M4A is running in VirtualBox. Emulator connection is done via port
forwarding (with putty or similar).
This way I get near real time debugg
13 matches
Mail list logo
