Parse on Dart VM

[rizalkotlin]

Since there is no dependency for specific Flutter feature, why this library use Flutter SDK?
It can be more useful when this parse SDK can be used on dart vm or console app as well

[phillwiggins]

The specific dependencies current are shared_preferences. Until we can think of a better solution to local persistence, it will be Flutter based. I'm fairly new to Flutter & Dart, so if you have any ideas or solutions, please let me know as a pure Dart based library would be so much better. Thanks

…

On Sat, Feb 9, 2019, 06:07 rizalkotlin ***@***.*** wrote: Since there is no dependency for specific Flutter feature, why this library use Flutter SDK? It can be more useful when this parse SDK can be used on dart vm or console app as well — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#78>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgn3qOz2W1xiLIurC81rAJdhGZJHnCeks5vLmWbgaJpZM4ayZvn> .

[putraxor]

@rizalkotlin I have my own implementation for shared_preference and path_provider
https://github.com/putraxor/flutter_parse_sdk
but I haven't tested it on Flutter Mobile

take a look at shared_preferences.dart and path_provider.dart

[chrbayer]

The storage is not an integral part of the communication to the parse server, I think the best way would be to remove the dependency to any kind of storage and just provide some "BaseStorage" class which simply defines the interface and does not store and retrieve anything. For some applications this is good enough. If needed, for Flatter or for a command line application this class can be extended to handle the actual storage.

This would solve #73, this should be a communication library and should not worry about secure or insecure storage places for session ids...

What do you think?

[hyperrecursive]

It would be so nice to have Parse-SDK-Flutter to be based on Parse-SDK-Dart so that we can use the latter on all platforms supported by Dart... Is this planned? Or should I forfeit all hope and start thinking about workarounds? How costly would such change be?

[fischerscode]

I found this issue today.
I think the ideas of @chrbayer and @hyperrecursive sound like a good solution.
Some days ago, I have tried to remove all flutter dependencies, and we would have to do something like @chrbayer's idea for quite a amount of used packages.

@phillwiggins
I am considering doing this as soon as I find some time. Would this be merged? Then everyone could just fork this repo and delete everything that is flutter related in order to create a dart package.

[phillwiggins]

I'm more than happy to have this a pure Dart library. As long as we find the best solution for storage etc that plays nicely on all platforms, then it would completely make sense.

I will release 1.0.27 today and make a new branch called release/1.0.28. If you create a PR for that branch, I will merge it and test it fully heavily.

Sounds like a great idea.

[fischerscode]

I am closing this, as parse_server_sdk can now be used in dart projects.