Seperate the dart and the flutter parts of this sdk #434
Conversation
|
@phillwiggins |
|
I genuinely believe that this is the best approach. If we can slowly figure out a way to create a pure Dart library, and a Flutter library that sits on top, it will surely help a lot of people. Great idea and great work. |
Not so happy with the fact that `CoreStoreSembastImp implements sdk.CoreStoreSembastImp` in `parse_server_sdk.dart` but I didn't find a better solution.
|
I have pushed a new commit that removes |
|
I think there are now all flutter parts separated from the core of the SDK. |
|
I think I have separated everything. Currently I have done very little tests. Testing is highly appreciated. |
fischerscode
changed the title
|
Is it worth splitting documentation correctly into 2 sections? It's a little confusing at the moment. We either split the library and have one depend on the other, or keep the libraries in the same repository and tidy docs etc? I've not had a chance to test any web stuff as of yet in all honesty. I've been tied up alot in other projects recently. I'm happy to take your advice. |
|
@phillwiggins Regarding the future, I think the cleanest option would be:
But this would also be the biggest change! The question is more like this: In addition to this, I think it would be a good idea to use the master branch as the working branch (like currently the release/1.0.28 branch), freeze it's current state regularly in a branch to prepare the next release (like a release candidate) and release the release candidate after changes in the version number, changlog, readme and small fixes, as this is pretty much the norm in git and it shouldn't be more work. |
|
I think the same repository is fine. We can publish both libraries from the
same repository, just ensure documentation is very clear. Let me know if
you're happy with that solution and we can amend the repository details
accordingly. I.e. update the main Parse repository to label this as a
Dart/Flutter repository.
In terms of branching solutions, we ideally need to work from a develop
branch as the Pub Dev points to the master branch of the repository by
default. I'm happy to have a develop branch, create release branches from
that when ready and merge back to master when released.
What's your thoughts?
…On Fri, 4 Sep 2020, 11:49 Maximilian Fischer, ***@***.***> wrote:
@phillwiggins <https://github.com/phillwiggins>
I think the documentation is currently fine, as this is currently a
flutter package.
In order to use it as a dart package you have to remove everything marked
with # only used in the flutter part from the pubspec.yaml and remove
parse_server_sdk.dart and parse_live_list_flutter.dart.
Regarding the future, I think the cleanest option would be:
- to completely split this project in two repositories (one for dart
(quite similar to this
<https://github.com/AdvancedProjects/Parse-SDK-Dart/tree/release/1.0.28>)
and one for flutter)
- publish a parse_dart_sdk_dart to pub.dev (or even better use
parse_server_sdk for the dart SDK and eq. parse_server_sdk_flutter for
the flutter SDK)
- let the flutter SDK depend on the dart SDK.
But this would also be the biggest change!
The question is more like this:
Should we do a small change or is doing a huge change but have a clean
setup for the future?
In addition to this, I think it would be a good idea to use the master
branch as the working branch (like currently the release/1.0.28 branch),
freeze it's current state regularly in a branch to prepare the next release
(like a release candidate) and release the release candidate after changes
in the version number, changlog, readme and small fixes, as this is pretty
much the norm in git and it shouldn't be more work.
Doing this release candidate-thing would make sens, as it prevents bugs in
a release, that got fixed 2 days later like one livelist related bug in
1.0.26.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#434 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4CPXVVVO2YPD43W75IILDSEDA2DANCNFSM4QRSHP4Q>
.
|
|
I have not published anything in pub.dev, so I didn't knew you can have one repo for two packages. (How does it work with the pubspect.yaml? Are there two directories? One with the dart, one with the flutter package?) With that extra information, using a single repo is a good idea.
So you want the Edit: I just had a look at the bloc repo I think a structure like this might be a good idea. |
|
I think 2 packages sounds about right. Looking at the Flutter libraries
offered by Google (i.e. SharedPrefs), they use the same repository, but
different packages.
Have the Flutter dependency depend on the Dart library but include the
Flutter extras?
Does this sound logical to you?
…On Fri, 4 Sep 2020 at 17:28, Maximilian Fischer ***@***.***> wrote:
I have not published anything in pub.dev, so I didn't knew you can have
one repo for two packages. (How does it work with the pubspect.yaml? Are
there two directories? One with the dart, one with the flutter package?)
Neither did I know, pub.dev points to the master branch.
With that extra information, using a single repo is a good idea.
I.e. update the main Parse repository to label this as a
Dart/Flutter repository.
So you want the parse_server_sdk be available for dart and flutter and
not contain e.g. ParseLiveListWidget (Widgets are only available on
flutter)? An then create a second package e.g. parse_server_sdk_flutter
that contains parse_server_sdk and all the flutter related things?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#434 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4CPXS64KQVITL6UIV4Q53SEEISFANCNFSM4QRSHP4Q>
.
--
Kind Regards
Phill Wiggins
[email protected]
|
|
I have started separating in this branch. TODOS:
|
|
Those names sound great to me. Go for it!
…On Fri, 4 Sep 2020, 19:31 Maximilian Fischer, ***@***.***> wrote:
I have started separating in this branch
<https://github.com/maaeps/Parse-SDK-Flutter/tree/refactor_structure>.
It works like a charm.
Should I create a PR?
Do you think the dart directory should be named parse_server_sdk and the
flutter directory parse_server_sdk_flutter
TODOS:
- Docs
- dart example
- migration instructions
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#434 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4CPXTIQX6JWMRLC6QWYRTSEEW7BANCNFSM4QRSHP4Q>
.
|
Change log: ## 1.0.28 - Added full web support - split this package in a dart and a flutter one - [flutter package](https://pub.dev/packages/parse_server_sdk_flutter) - [dart package](https://pub.dev/packages/parse_server_sdk) - Moved ParseHTTPClient to Dio [#459](#459) - Bug fixes - general improvements Commits: * Release 1.0.28 - Create new release branch - Update references to 1.0.28 * Replace devicelocale by Platform.localeName call (#430) * Replace devicelocale by Platform.localeName call * Use flutter_test to meet new requirements * Livequery: combine both implementations (#433) * make livequeries web implementation more similar to the mobile implementation * combining both livequery implementations * make livequery "part of flutter_parse_sdk" * smal fix * Seperate the dart and the flutter parts of this sdk (#434) * Set TODO's Set TODO's, needed for #78 (comment) * First step of seperating the flutter and the dart parts * added one todo * remove connectivity from the dart part * Removed path_provider from the dart part Not so happy with the fact that `CoreStoreSembastImp implements sdk.CoreStoreSembastImp` in `parse_server_sdk.dart` but I didn't find a better solution. * Removed shared_preferences from the dart part * Update pubspec.yaml * Update parse_server_sdk_dart.dart * removed dart:ui from dart part * removed flutter from dart part * fixed tests * Add WEB-support for CoreStoreSembastImp (#436) * Add websupport for CoreStoreSembastImp * Add debug warning when using sembast on web ParseCoreData().debug should be null at that time * fixed issues * fix getInstance of CoreStoreSembastImp (#438) * Reset _isConnected var If state is equal to ConnectivityResult.none, then there is no connection with LiveQuery server (for example when internet is disconnected). _setReconnect function will now retry connection. * Fixed bad type ConnectivityResult to ParseConnectivityResult * Preparing the repository for seperated dart and flutter package (#439) * split code into package directories * removed unused dependencies * Updated READMEs * Small changes and improvements (#441) * docs changes * remove flutter_test * CoreStore was implemented twice * implemented CoreStoreMemoryImp (default corestore for dart) * fix tests * Update .travis.yml * Fix links (#443) * fix flutter logo * fixed flutter link * Fix infinite connecting on web * delete old example folder * fixing travis tests (#447) Should work again. * Fixed throw in live list stream (#448) * ParseUser: store password in field (#446) * store password in field Potential fix for #444 * remove password from clone * fix for issue #456 (#457) Added @BaranMichal25 fix for #456. #456 (comment) * LiveList: preloadedColumns (#458) * LiveList: added preloadedColumns * LiveList: fixed bug with lazyloading=false * formatting * Add README section for flutter * creat migration guide for version 1.0.28 (#445) * Create migrate-1-0-28.md * Update migrate-1-0-28.md * Update migrate-1-0-28.md * Update migrate-1-0-28.md * Merge from upstream/release/1.0.28 * fix typos * added "changed network library" to migration guide * Move ParseHTTPClient to Dio (#459) * Merged manually from branch dio * fixing nullpointer * Fix batch operations Maybe dio changes the toString behaviour. * use mine * keep content-type * fix file upload issue * fixed file uppload on web * performance improvement in parse_file_web * fix for issue #456 (#457) Added @BaranMichal25 fix for #456. #456 (comment) * fix flutter test * fix crash when debug=true * fix dart test * add ProgressCallback in README * added progressCallback example * improve readme (#468) * Update CHANGELOG.md (#462) * allow signup without email (#469) * Update migrate-1-0-28.md (#471) Added section for tests at migration guide. Fix: #385 (comment) * SignUp encoding data to JSON (#470) * signup - use toJson Co-Authored-By: itmesh <[email protected]> * fix password update * Add disclaimer to not use Masterkey on client side (#474) * Add disclaimer to not use Masterkey on client side * LiveList: fix setState after dispose (#475) * Querybuilder: whereMatchesKeyInQuery bugfix (#476) Fix bug where whereMatchesKeyInQuery cant be used when using different object classes. * fixed liveListRetryIntervals in flutter Not sure how this line got lost. * Rel 1.0.28: Add license to sub-projects * Rel 1.0.28: Add dependencies required for rel * 1.0.28/fix publish warnings (#472) * added licenses I've just copied the LICENSE file. * change dependencies at dart/pubspec.yaml * change dependencies at flutter/pubspec.yaml * flutter: added dio to pubspec.yaml It's contained in the pub.spec archive, so I add it here. Thanks to: Co-authored-by: Phill <[email protected]> Co-authored-by: Nils Strelow <[email protected]> Co-authored-by: FNPCMDs <[email protected]> Co-Authored-By: itmesh <[email protected]>
work in progress
This PR aims to separate the Flutter parts from the SDK itself, in order to create a base for possibly a parse sdk for pure dart projects.
Issues for parse on dart are #78 and #408.
This comment is heavily related to this PR.