Re: [mono-android] Async and the UI

[JLee]

Hi Nosh,

i had a similar problem few days ago, look here:
http://mono-for-android.1047100.n5.nabble.com/Can-t-create-handler-inside-thread-sync-problem-why-td5710999.html

In Android you have to use RunOnUiThread() Method to sync code to the ui.
Your code have to lool like somthing like this:

RunOnUiThread(delegate { Toast.MakeText(this, "ServerReturned " +
ex.Message, ToastLength.Long).Show(); });

Hope this helpes.



--
View this message in context: 
http://mono-for-android.1047100.n5.nabble.com/Async-and-the-UI-tp5711015p5711022.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
Monodroid@lists.ximian.com

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

Re: [mono-android] Deploying to multiple devices

[andyjohnson0]

Thanks for replying.

I understand how to get an apk onto the devices. My problem was that I
didn't see how to build the apk without being forced to deploy it to a local
device or emulator.

Anyway, realised that I have to use Build->Package for Android. I really
don't know why I failed to notice that menu option before. To used to
build/deploy I guess.

Cheers, Andy




--
View this message in context: 
http://mono-for-android.1047100.n5.nabble.com/Deploying-to-multiple-devices-tp5711017p5711023.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
Monodroid@lists.ximian.com

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

Re: [mono-android] Automatic crash reporting

[grupatnt]

Hi Paul

Had the same problem sometime while ago.

Gave up on trying to convince ACRA to work and reimplemented most of the
functionality in C#.

Error value collection is mostly one on one map with a couple of exceptions
re reflection and such.

If you are only interested in submitting data to Google Docs you can use the
following snippet.

public static bool SubmitToGoogleDoc(string formKey,
IEnumerable> values)
{
using (var wc = new WebClient())
{
var keyval = new NameValueCollection
{{"pageNumber", "0"}, {"backupCache", ""},
{"submit", "Envoyer"}};
foreach (var kvp in values)
keyval.Add(string.Format("entry.{0}.single", kvp.Item1),
kvp.Item2);

wc.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
wc.Headers.Add("Origin", "https://spreadsheets0.google.com";);
wc.Headers.Add("User-Agent", "Android");
wc.Headers.Add("Accept",
"text/html,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5");

var uri =
string.Format("https://spreadsheets0.google.com/formResponse?formkey={0}&ifq";,
formKey);

var result = wc.UploadValues(new Uri(uri), "POST", keyval);
var str = Encoding.UTF8.GetString(result);
return str.Contains("Your response has been recorded.");
}
}

Hope it helps.

Cheers,
Greg



--
View this message in context: 
http://mono-for-android.1047100.n5.nabble.com/Automatic-crash-reporting-tp5710823p5711024.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
Monodroid@lists.ximian.com

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

[mono-android] dynamic listview item expansion using ViewStub - selectively not working

[Stephan Steiner]

I have a listview that I'm populating at runtime - and I want a listview item
to expand upon click (using a ViewStub).

And I have this strange thing happening - if I enter the Activity showing
the ListView, click on any item in the ListView except the last one, it
expands as desired, but the last item in the list disappears.

If however, you click on the last item on the list while it is visible, it
does not expand.

I've written a small sample that allows to reproduce this issue - it starts
with an activity that adds a new ListView item and changes to the ListView.
Inside the ListView you have the expansion mechanism, plus the ability to
remove an item (End Call). I realize the action bar isn't perfect (at times
it happens that it doesn't show my context options) but that's okay, I'm
only interested in the disappearing last item and why I cannot expand the
last item (even though in code everything works.. it just never shows up).

I've uploaded the fully working sample here:
https://skydrive.live.com/?cid=EAF6A98542EF6194&id=EAF6A98542EF6194!132
(latest zip file).



--
View this message in context: 
http://mono-for-android.1047100.n5.nabble.com/dynamic-listview-item-expansion-using-ViewStub-selectively-not-working-tp5711026.html
Sent from the Mono for Android mailing list archive at Nabble.com.
___
Monodroid mailing list
Monodroid@lists.ximian.com

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

[mono-android] Minimum Android to Target (suggest use term Default)

[Neal Culiner]

I'm implementing features in Android OS 4 but still supporting back to OS
2.2.  I have the  in my
AndroidManifest.xml and all seems fine so far.  However, to get support for
the newer features, as you know, I had to set the Minimum Android to Target
to 4.0.  I then saw that the package that was sent to my device and later an
emulator was a higher package version.  This leads me to believe I should
use the max version in my project to code against and this will also send
the latest package to the device to use.

 

With this being said, I suggest we adopt the same thing MonoTouch adopted
for the SDK version with the term "Default" which uses the latest available
API installed on the machine or you can set it to a lower version as needed.
This would ensure that we're always pushing the latest package and also
ensuring compatibility with the latest OS version.  I noticed I had a few
conflicts with "using" statements when switching to a later API that I
needed to use a fully qualified definition such as with clipboard
integration using Android.Text specifically.  

 

What do you all think?  Should we adopt "Default" for this setting like in
MonoTouch?

 

Neal Culiner

NC Software, Inc.

http://www.nc-software.com  

 

___
Monodroid mailing list
Monodroid@lists.ximian.com

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

Re: [mono-android] Minimum Android to Target (suggest use term Default)

[Darren Abbott]

I posted a similar question to this group recently.

AndroidManifest.xml supports "minSdkVersion" and "targetSdkVersion"
attributes.  The target SDK version being higher than the min SDK is
supposed to mean you can use features from higher SDK level, but have taken
steps to insure you are backwards compatible back to the min SDK level.

My experience is the same as yours -- "Minimum Android to Target" does NOT
set the minSdkVersion attribute.  And to complicate matters even more,
there is a "Target API level" setting under "Android Manifest".

One person who responded to my thread said that "Minimum Android to Target"
did set minSdkVersion for him.

I think both the minSdkVersion and targetSdkVersion should be exposed via
the GUI, on the same page.   I'm not too picky about what to call the
fields.

I filed a bug report on the topic (ID = 6221).  I am not sure I have
figured out the bug reporting system, though, since I have never seen
any acknowledgement that a report has been received.

Darren

On Wed, Jul 25, 2012 at 12:57 PM, Neal Culiner  wrote:

> I’m implementing features in Android OS 4 but still supporting back to OS
> 2.2.  I have the  in my
> AndroidManifest.xml and all seems fine so far.  However, to get support for
> the newer features, as you know, I had to set the Minimum Android to Target
> to 4.0.  I then saw that the package that was sent to my device and later
> an emulator was a higher package version.  This leads me to believe I
> should use the max version in my project to code against and this will also
> send the latest package to the device to use.
>
> ** **
>
> With this being said, I suggest we adopt the same thing MonoTouch adopted
> for the SDK version with the term “Default” which uses the latest available
> API installed on the machine or you can set it to a lower version as
> needed.  This would ensure that we’re always pushing the latest package and
> also ensuring compatibility with the latest OS version.  I noticed I had a
> few conflicts with “using” statements when switching to a later API that I
> needed to use a fully qualified definition such as with clipboard
> integration using Android.Text specifically.  
>
> ** **
>
> What do you all think?  Should we adopt “Default” for this setting like in
> MonoTouch?
>
> ** **
>
> Neal Culiner
>
> NC Software, Inc.
>
> http://www.nc-software.com
>
> 
>
> ** **
>
> ___
> 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

Re: [mono-android] Minimum Android to Target (suggest use term Default)

[Jonathan Pryor]

On Jul 25, 2012, at 1:57 PM, Neal Culiner  wrote:
> However, to get support for the newer features, as you know, I had to set the 
> Minimum Android to Target to 4.0.  I then saw that the package that was sent 
> to my device and later an emulator was a higher package version.

I'm not sure I understand this sentence; _what_ was "a higher package version"?

The TargetFrameworkVersion[0] that your app is built against corresponds to an 
API level, e.g. selecting "Android 2.3 (Gingerbread)" corresponds to API level 
10. When the app is deployed, a Mono.Android.Platform.ApiLevel_X package is 
deployed to the target, where X is the TargetFrameworkVersion's API level.

TargetFrameworkVersion controls which types and members the compiler will 
permit access to.

There is also the AndroidManifest.xml //uses-sdk/@android:minSdkVersion 
attribute (MonoDevleop: Project Options > Build/Mono for Android Application > 
Minimum Android Version). This tells Android what the minimum API level your 
application will target. If not specified, this defaults to 
$(TargetFrameworkVersion).

Finally there is the AndroidManifest.xml //uses-sdk/@android:targetSdkVersion 
attribute [1], which Android uses to enable/disable certain default behaviors, 
in addition to which android.jar your application is built against. If not 
specified, this also defaults to $(TargetFrameworkVersion).

> This leads me to believe I should use the max version in my project to code 
> against and this will also send the latest package to the device to use.

There are two different possible max values, which control different things: 
TargetFrameworkVersion and targetSdkVersion.

TargetFrameworkVersion should be the maximum API level that you wish to target.

targetSdkVersion should be ignored unless you're using something that requires 
it be set to a different value (e.g. Admob, which requires API 13 no matter 
what API level your app actually targets).

> With this being said, I suggest we adopt the same thing MonoTouch adopted for 
> the SDK version with the term “Default” which uses the latest available API 
> installed on the machine or you can set it to a lower version as needed.

I'm not sure this is a good idea. (I'm not sure what we currently do is best 
either, for that matter.)

MonoTouch is not Mono for Android. MonoTouch ships with a single binding 
assembly, and it's up to the developer to (somehow) ensure that they only use 
members that exist on their target devices.

Mono for Android, meanwhile, ships with one binding assembly per API level 
(Mono.Android.dll/etc.). This allows the compiler+IDE to only show the desired 
types and members.

The problem is that our installer installs _lots_ of API levels, including 
API-15, which has 10.7% market share.

http://developer.android.com/about/dashboards/index.html

In the future our installer will likely install API-16, which will have even 
less.

I'm not sure it's a good idea to default to an API level that hardly anyone 
has, unless the developer actually has such a device. Compare to iOS, where iOS 
5.1 got 61% adoption in 15 days; fragmentation is a reality.


http://thenextweb.com/apple/2012/03/23/apples-ota-upgrade-process-and-focused-hardware-lets-ios-5-1-hit-61-adoption-in-15-days/

(Granted, the current solution of "default to API level 8" isn't wonderful 
either...)

 - Jon

[0] TargetFrameworkVersion is set in Visual Studio at Project Properties > 
Application > Minimum Android to target.

TargetFrameworkVersion is set within MonoDevelop at Project Options > 
Build/General > Target framework.

[1] //uses-sdk/@android:targetSdkVersion is set in Visual Studio at Project 
Properties > Android Manifest > Target API level.

//uses-sdk/@android:targetSdkVersion is set in MonoDevelop at Project Options > 
Build/Mono for Android Application > Target Android version.
___
Monodroid mailing list
Monodroid@lists.ximian.com

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

Re: [mono-android] Release version errors

[Jonathan Pryor]

On Jul 24, 2012, at 5:45 AM, Goncalo Oliveira  wrote:
> Let me see if I get this straight. I do have an additional project that is 
> referenced by the application. It's basically the data model classes. I need 
> to add the "[Android.Runtime.Preserve(AllMembers=true)]" attribute to the 
> classes in this assembly in order to avoid the linker to "eat up" its 
> references? Either that or the weird falseflag method?

Generally you should start with "Link SDK Assemblies". Using the "Link All 
Assemblies" option is for the insane.

If Link SDK Assemblies fails, it's generally because the linker isn't smart 
enough to preserve SDK members that you're using. Using [Preserve] won't help 
(no source!), so you'd want to use falsflag or linkskip.

 - Jon

___
Monodroid mailing list
Monodroid@lists.ximian.com

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