New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unified API support for Xamarin.iOS #813

Closed
wants to merge 3 commits into
base: 3.2
from

Conversation

Projects
None yet
4 participants
@lothrop
Member

lothrop commented Oct 23, 2014

Breaking change supporting 32-bit and 64-bit platforms, as required for all iOS projects as of February 1.

See http://developer.xamarin.com/guides/cross-platform/macios/unified/.

See issue #801.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

Thanks :)

As a user... how do you think we should introduce this change? It obviously has to happen, but it's going to break everyone's projects....

Will also ask for input from Twitter :)

Thanks again!

Contributor

slodge commented Oct 24, 2014

Thanks :)

As a user... how do you think we should introduce this change? It obviously has to happen, but it's going to break everyone's projects....

Will also ask for input from Twitter :)

Thanks again!

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Oct 24, 2014

Member

I'm really not sure. How was the reaction to the breaking change introduced in 3.2?

My test of these fixes was not thorough at all. I translated an automatically generated NinjaCoder example to the Unified API and that worked (at least from Xamarin Studio). How do you go about testing changes? I'm also curious to find out how to to test if the code generated by the NuGet package still works.

Member

lothrop commented Oct 24, 2014

I'm really not sure. How was the reaction to the breaking change introduced in 3.2?

My test of these fixes was not thorough at all. I translated an automatically generated NinjaCoder example to the Unified API and that worked (at least from Xamarin Studio). How do you go about testing changes? I'm also curious to find out how to to test if the code generated by the NuGet package still works.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

Changes generally tested by:

  • recompiling ApiExamples and deploying to phone to test
  • recompiling DialogExample and deploying to phone to test
  • recompiling assorted other samples and deploying to phones to test
  • running through TipCalc

For nuget, I believe you'll need to change the targets - I'm not sure yet, but I believe that Xamarin are trying too nuke all MonoTouch naming - to replace it with Xamarin - although the situation is changing a bit (maybe) - see answer on http://stackoverflow.com/questions/26068750/could-not-install-package-mvvmcross-portablesupport-3-2-1-at-visual-studio-2013 (this might mean we could release a package with both old and new assemblies... but doing so might be too much pain to actually build....)

Contributor

slodge commented Oct 24, 2014

Changes generally tested by:

  • recompiling ApiExamples and deploying to phone to test
  • recompiling DialogExample and deploying to phone to test
  • recompiling assorted other samples and deploying to phones to test
  • running through TipCalc

For nuget, I believe you'll need to change the targets - I'm not sure yet, but I believe that Xamarin are trying too nuke all MonoTouch naming - to replace it with Xamarin - although the situation is changing a bit (maybe) - see answer on http://stackoverflow.com/questions/26068750/could-not-install-package-mvvmcross-portablesupport-3-2-1-at-visual-studio-2013 (this might mean we could release a package with both old and new assemblies... but doing so might be too much pain to actually build....)

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

Ooops - when I said "you'll need to" I meant "we'll need to" :)

Contributor

slodge commented Oct 24, 2014

Ooops - when I said "you'll need to" I meant "we'll need to" :)

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Oct 24, 2014

Member

I'm failing miserably with ApiExamples. I see a list but each element leads to an empty page (tested on iPhone 4 and iPhone 6 Plus). I'm guessing this is because of the bug in Xamarin.iOS for Visual Studio. If I switch to iPhoneSimulator instead of iPhone the project doesn't compile at all anymore because of supposedly missing namespaces that should all be in Xamarin.iOS.dll. I can't get it to compile at all in Xamarin Studio because of these missing namespaces, although Xamarin.iOS.dll is correctly referenced.

I'd say it's too early to do the switch to the Unified API.

Member

lothrop commented Oct 24, 2014

I'm failing miserably with ApiExamples. I see a list but each element leads to an empty page (tested on iPhone 4 and iPhone 6 Plus). I'm guessing this is because of the bug in Xamarin.iOS for Visual Studio. If I switch to iPhoneSimulator instead of iPhone the project doesn't compile at all anymore because of supposedly missing namespaces that should all be in Xamarin.iOS.dll. I can't get it to compile at all in Xamarin Studio because of these missing namespaces, although Xamarin.iOS.dll is correctly referenced.

I'd say it's too early to do the switch to the Unified API.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

I wonder if @migueldeicaza can get someone from Xam iOS team to take a look - I'm sure they don't want to hear "I'd say it's too early to do the switch to the Unified API."

Contributor

slodge commented Oct 24, 2014

I wonder if @migueldeicaza can get someone from Xam iOS team to take a look - I'm sure they don't want to hear "I'd say it's too early to do the switch to the Unified API."

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

... and on Visual Studio iOS support, let's log and complain about the bugs - they may not use VS as much as XS, but they do seem keen to address things like yesterday's CGRect issues and other things like https://bugzilla.xamarin.com/show_bug.cgi?id=15002 which I encountered yesterday

Contributor

slodge commented Oct 24, 2014

... and on Visual Studio iOS support, let's log and complain about the bugs - they may not use VS as much as XS, but they do seem keen to address things like yesterday's CGRect issues and other things like https://bugzilla.xamarin.com/show_bug.cgi?id=15002 which I encountered yesterday

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Oct 24, 2014

Contributor

In fine .Net naming tradition, we'll aim to include this in our 3.5 release - https://github.com/MvvmCross/MvvmCross/tree/3.5 - but obviously we'll need to get stability from Xam before we switch over...

Contributor

slodge commented Oct 24, 2014

In fine .Net naming tradition, we'll aim to include this in our 3.5 release - https://github.com/MvvmCross/MvvmCross/tree/3.5 - but obviously we'll need to get stability from Xam before we switch over...

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Nov 13, 2014

Member

The fix from Xamarin in now in the beta channel. https://bugzilla.xamarin.com/show_bug.cgi?id=23868

Member

lothrop commented Nov 13, 2014

The fix from Xamarin in now in the beta channel. https://bugzilla.xamarin.com/show_bug.cgi?id=23868

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 13, 2014

Contributor

So ... I really want to merge this into 3.5... which means the 3.5 will have the fragment changes and this....

Is there any way we can keep the old Classic API too? Is it case of having to build the assemblies twice and then use different nuget targets? (Not sure I can be bothered with the manual overhead of that...)

What do we have to put into the nuget packages? Anyone know?

Downloading beta updates now...

Contributor

slodge commented Nov 13, 2014

So ... I really want to merge this into 3.5... which means the 3.5 will have the fragment changes and this....

Is there any way we can keep the old Classic API too? Is it case of having to build the assemblies twice and then use different nuget targets? (Not sure I can be bothered with the manual overhead of that...)

What do we have to put into the nuget packages? Anyone know?

Downloading beta updates now...

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Nov 13, 2014

Member

It seems we'll need the newest NuGet version 2.8.3 (https://nuget.codeplex.com/releases/view/133091) and change the platform moniker (http://developer.xamarin.com/guides/cross-platform/macios/unified/#NuGet).

Supporting both in NuGet might be possible through Bait & Switch but I don't think it will be possible with a real PCL. I also don't think it's worth the effort since everyone will have to switch by February 1. Could 3.5 be released as a pre-release NuGet package with corresponding warnings?

Member

lothrop commented Nov 13, 2014

It seems we'll need the newest NuGet version 2.8.3 (https://nuget.codeplex.com/releases/view/133091) and change the platform moniker (http://developer.xamarin.com/guides/cross-platform/macios/unified/#NuGet).

Supporting both in NuGet might be possible through Bait & Switch but I don't think it will be possible with a real PCL. I also don't think it's worth the effort since everyone will have to switch by February 1. Could 3.5 be released as a pre-release NuGet package with corresponding warnings?

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 13, 2014

Contributor

I've merged into the v3.5 branch... I can't get it building here... not sure why (I can build other xam.ios projects) - will keep pushing this tomorrow night :)

Thanks - this is going to rock :)

(but I might go missing when we actually push this live - there'll be a lot of confused people with this 64bit handover :))

Contributor

slodge commented Nov 13, 2014

I've merged into the v3.5 branch... I can't get it building here... not sure why (I can build other xam.ios projects) - will keep pushing this tomorrow night :)

Thanks - this is going to rock :)

(but I might go missing when we actually push this live - there'll be a lot of confused people with this 64bit handover :))

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 13, 2014

Contributor

What I'm seeing in the iOS projects is:

1

and if I look in references then I see:

2

and if I select that Xamarin.iOS reference then I end up with:

3

I'm a bit confused... if I create a new Unified iPhone project and it builds fine... tried creating a new copy of the repo - that works fine.... I'm a big bit confused right now...

Contributor

slodge commented Nov 13, 2014

What I'm seeing in the iOS projects is:

1

and if I look in references then I see:

2

and if I select that Xamarin.iOS reference then I end up with:

3

I'm a bit confused... if I create a new Unified iPhone project and it builds fine... tried creating a new copy of the repo - that works fine.... I'm a big bit confused right now...

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Nov 13, 2014

Member

Can you see any difference in the csproj file between the working version and mine? I remember seeing this problem for one project but it disappeared after I browsed for the right DLL once.

Member

lothrop commented Nov 13, 2014

Can you see any difference in the csproj file between the working version and mine? I remember seeing this problem for one project but it disappeared after I browsed for the right DLL once.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 13, 2014

Contributor

Nothing obvious - https://gist.github.com/slodge/82e23c8c30caed0d92d4

Heading for some zzzzz - sure it will make more sense tomorrow :)

Contributor

slodge commented Nov 13, 2014

Nothing obvious - https://gist.github.com/slodge/82e23c8c30caed0d92d4

Heading for some zzzzz - sure it will make more sense tomorrow :)

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Nov 13, 2014

Member
<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.MonoTouch.CSharp.targets" />

probably shouldn't be in there (line 39)...

Member

lothrop commented Nov 13, 2014

<Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.MonoTouch.CSharp.targets" />

probably shouldn't be in there (line 39)...

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge
Contributor

slodge commented Nov 14, 2014

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 14, 2014

Contributor

That targets line does indeed seem to be the cause here...

Removing it makes my project build :)

Before I go edit all my touch csproj files (won't take long!), is this in your local copy of the repo too? Or have you already fixed it?

Contributor

slodge commented Nov 14, 2014

That targets line does indeed seem to be the cause here...

Removing it makes my project build :)

Before I go edit all my touch csproj files (won't take long!), is this in your local copy of the repo too? Or have you already fixed it?

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 14, 2014

Contributor

(I've removed them for now - but can easily discard my changes later if I've got out of date csproj files - it's just a "replace in files")

Contributor

slodge commented Nov 14, 2014

(I've removed them for now - but can easily discard my changes later if I've got out of date csproj files - it's just a "replace in files")

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Nov 14, 2014

Member

Thanks! No, I didn't fix it locally. I just saw that the correct line was in there and didn't notice the wrong one wasn't removed. Might explain some of the strange behavior I was seeing...

Member

lothrop commented Nov 14, 2014

Thanks! No, I didn't fix it locally. I just saw that the correct line was in there and didn't notice the wrong one wasn't removed. Might explain some of the strange behavior I was seeing...

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 14, 2014

Contributor

Thanks @lothrop

Got stuff building, made a few small nuspec changes (and a couple of linkerpleaseinclude fixes) and then my first couple of ios sample apps "just worked" TM

Top work :)

Thank you!

Stuart

Contributor

slodge commented Nov 14, 2014

Thanks @lothrop

Got stuff building, made a few small nuspec changes (and a couple of linkerpleaseinclude fixes) and then my first couple of ios sample apps "just worked" TM

Top work :)

Thank you!

Stuart

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Nov 23, 2014

Contributor

Hi @lothrop

I'm closing this now - as 3.5 is "live" on nuget

Thanks again for the work - fabulous stuff :)

I'm also trying to talk with people at the moment about how to open up Mvx to make it easier to contribute - I'm trying to learn how to be a better githubber. Hoping to add a few more people as contributors with write access... If @Cheesebaron is ok with this (I suspect he will be!), I'd love you to be one of them :)

Stuart

Contributor

slodge commented Nov 23, 2014

Hi @lothrop

I'm closing this now - as 3.5 is "live" on nuget

Thanks again for the work - fabulous stuff :)

I'm also trying to talk with people at the moment about how to open up Mvx to make it easier to contribute - I'm trying to learn how to be a better githubber. Hoping to add a few more people as contributors with write access... If @Cheesebaron is ok with this (I suspect he will be!), I'd love you to be one of them :)

Stuart

@slodge slodge closed this Nov 23, 2014

@Cheesebaron

This comment has been minimized.

Show comment
Hide comment
@Cheesebaron

Cheesebaron Nov 24, 2014

Member

No objections from me 👍

Member

Cheesebaron commented Nov 24, 2014

No objections from me 👍

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Dec 1, 2014

Member

I would be honored.

Member

lothrop commented Dec 1, 2014

I would be honored.

@slodge

This comment has been minimized.

Show comment
Hide comment
@slodge

slodge Dec 1, 2014

Contributor

Thanks - moved to #841 :)

Contributor

slodge commented Dec 1, 2014

Thanks - moved to #841 :)

@lothrop

This comment has been minimized.

Show comment
Hide comment
@lothrop

lothrop Dec 11, 2014

Member

I'm going to test this with the Xamarin Alpha channel next week as suggested in http://blog.xamarin.com/unified-api-and-64-bit-support-complete/.

Member

lothrop commented Dec 11, 2014

I'm going to test this with the Xamarin Alpha channel next week as suggested in http://blog.xamarin.com/unified-api-and-64-bit-support-complete/.

@martijn00 martijn00 added this to the 3.5.0 milestone Jan 25, 2015

@lothrop lothrop deleted the lothrop:64bitshizzle branch Jan 3, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment