Xamarin Forms Support about parse-sdk-dotnet

[cecilphillip]

With .NET Standard coming out, that might be a better target than PCLs for Xamarin

[montymxb]

This might be something worth working towards when we start updating this sdk.

[hallucinogen]

Definitely! The feature has been in the queue for a while, but we currently are not actively working on it. We can bump the priority if there're more people looking forward to it.

[cecilphillip]

I think more people (myself included) are building on and starting with Xamarin Forms. One of the reasons I even considered using Parse was the fact that I was it advertised Xamarin support. Supporting Xamarin Forma would open your service up to the grounding community of cross platform mobile devs

[bbartlett]

HUGE +1 on this! I'm using Parse in a Xamarin.Forms PCL project (and plan to use it on several more), and while it works to do the whole "platform-specific, linked file" approach for the code that directly touches Parse, it's kludgy and it adds complexity (DI, adapters, etc.) to my other code that lives in the PCL portion of the app but that also needs to get to Parse data.

As a short term solution (or possibly even the long term solution?), you might be able to just use "The Bait and Switch PCL Trick" ( http://log.paulbetts.org/the-bait-and-switch-pcl-trick/ ) to provide the PCL "implementation" while keeping the actual code in the platform-specific libraries. This would allow us to reference the real Parse classes in our common PCL code without actually needing to have a "real" PCL Parse library.

[gusennan]

+1

[gusennan]

@bbartlett I needed to do the bait-and-switch approach for our forms project, and can send a PR with the changes if Parse is interested.

@ParsePlatform, in order to be able to do this on all the platforms you support, each of the projects in your solution must implement the complete interface of the Parse.csproj. I know this is already the case with Android and iOS (for which I've implemented this method fur our App). I could work with you on this, if you'd like.

[richardjrossiii]

@gusennan Unfortunately, I think it's a bit more subtle than simply implementing all of the interface.

For example, ParsePush's interface is actually different right now between iOS and Android (due to different Push notification handling APIs).

We also need to figure out the minimal possible subset of the Parse APIs that we can implement, as with a PCL app there's no way to do any sort of LocalStorage in a portable way (that's why right now we abstract that into PlatformHooks.cs).

There certainly would be no way to do Installation or Push in a portable way, and perhaps even the User API would have to change for a PCL-compatible version of the SDK.

Eventually, we'll get there, and we would love community feedback and help. We just need a little more time to solidify the roadmap first, I think. I'lll have a more in-depth conversation with @hallucinogen offline at some point this week to see if we can create a high level list of tasks that need to be done to get there.

[gusennan]

@richardjrossiii thanks for sharing that. I think there is a way it's possible to do Local Storage in a portable way, via the bait-and-switch approach. The push, probably not. At a minimum, all of the classes that are shared between the different projects (which, as I was working through Android and iOS Parse implementations, realized are the majority), could be made cross plat via bait and switch. At least, that's what I've done to access the ParseUser object from our Xamarin Forms project, which works.

[bbartlett]

@richardjrossiii Any update from your conversation on tasks towards a possible PCL implementation? I'm just about to start on a new project that uses Parse as its backend, and I'd LOVE to avoid the hoops that we currently need to jump through on a cross-platform app for getting to even the basic classes like ParseUser from our other PCL code.

I agree with @gusennan -- it does seem like most of the classes that are shared between the projects could be handled via bait and switch, but even making the core 80% (or even 50%) available would be a huge success. Remember that with the bait-and-switch approach, none of the real code is done in the PCL itself -- the PCL contains only interfaces and dummy implementations of the real code. The real code remains in the platform-specific libraries, so nobody needs to actually deal with problems like doing Local Storage in a portable way. The "interface" (the dummy implementation) is done in a portable way, but the actual implementation can remain exactly where it is right now.

I haven't used push notifications just yet but I've heard that that changes hugely between platforms. However, if that falls into the 20% that we still have to implement via DI or adapters, having the rest of the API available in the PCL is still a huge productivity win for us.

[richardjrossiii]

@bbartlett We've talked about it, and, if we could come up with a solid solution for our Push and Analytics APIs being different on different platforms, we definitely be on board with having basic PCL support.

Because of how assemblies work in .NET, and the fact that you cannot have a Partial class in another assembly, I'm not 100% sure how to go about this ATM. If C# had static extension methods, we'd be golden. Sadly, this is not the case.

[gusennan]

@richardjrossiii we're using a (private) version of your library, forked off of 1.6.1 as a bait-and-switch PCL for our company's xamarin-forms app. I think the reason it's worked for us is because, to use what xamarin called "advanced-PCL" techniques (bait-and-switch), the assembly names must be the same. I'd be happy to share a version with our corporate code pulled out.

[cecilphillip]

@gusennan that would be good pony of reference for the rest of us

[gusennan]

Here's a pony of reference:

@cecilphillip

https://github.com/gusennan/Parse-SDK-dotNET/tree/public

The public branch is forked off of 1.6.1. To create version 1.0.0 of bait-and-switch nuget package, run in the root:
sh build-pack-parse-rebuy.sh 1.0.0

We've adopted the library a bit more for our personal needs, which you won't see in this branch, but this at least gives you a PCL-compatable version that will be suitable for the 80% of the cases mentioned above. If you compare this with the 1.6.1 release of parse, you'll see that there aren't so many differences.

[richardjrossiii]

@gusennan Thanks for the reference. We're actually currently in the process of a project restructure (see #108), which should hopefully make it significantly easier to play around with ideas like this.

Also, if you're forking this internally, feel free to suggest any changes publicly that might benefit others, even if you can't directly share them with us! We're always looking for ways to improve.

[gusennan]

@richardjrossiii I'll try to share the good and avoid the half-baked ideas, because I have a lot of those too.

One idea that I'm exploring is saving the keys in the ApplicationSettings (as defined in PlatformHooks.Mono.cs for the Android and iOS platforms). On Android, because of the order that the application is loaded (or rather, not loaded, see #37) on receiving a push notification, having these keys defined in a place accessible by the SDK without the app running is necessary. Setting them in code on the first application launch and then saving them in the ApplicationSettings seems like a decent approach.

[richardjrossiii]

Hey guys. Just wanted to give an update - we've recently switched to a fully modular design for the SDK, and this feature should be rolling out in the 1.8.0 release, along with several new awesome features.

[thewizster]

Great news...Thanks for all the hard work you guys have been putting in to keep Parse alive...Most appreciated!

[cecilphillip]

@gusennan, @thewizster : Question, I thought parse was shutting down?

[thewizster]

The hosted service is shutting down. I was referring to the parse-server open source project. @cecilphillip

[richardjrossiii]

@cecilphillip The client SDKs are not dying either! We will work hard to bring you the best possible features, including some that weren't possible to bring while parse.com was still a thing.

Parse is dead, long live Parse!

[jaganjan]

+1

[gusennan]

@richardjrossiii that's great to hear.

[fotiDim]

Any updates?

[tofutim]

Any updates? Has this been abandoned? Last minor edit July.

[hl4hck]

Any updates?

[Binnette]

Hi, since PCL is almost dead, I filled a bug here #274 in order to know if ParseSDK is working on .Net Standard. If anyone have the answer, fell free to answer there. 😊

[cedriclange]

Parse.NeTStandard2 sdk is already out, but i'm still trying tpo figure out how does it work because i seems like i can't connect to my backend, Im using xamarin.forms based on netstandard2 and prism.

Help please

[andyfmking]

Any update on this?

Would be great if I can use Parse on Xamarin Forms

[TobiasPott]

Did anyone how you tried the current state of the Parse SDK with an Xamarin application?
I did not yet as Xamarin.Forms is not my focus and it will take some time until I have the opportunity to do so, but I don't see why the current state should have problems to run in Xamarin.Forms.

Or, of course, I'm missing any explicit error which occurs?!