fix: Remove flutter version and add `example` and `example_ui`

[mbfakourii]

New Pull Request Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am creating this PR in reference to an issue.

Issue Description

In order to reduce conflicts, it was decided to remove the Flutter version, so the following tasks should be done

• [x] Remove the Flutter version
• [x] Restructuring the repository
• [x] Create an example to test the package
• [x] Create an example called example_ui for graphic widgets
• [x] Transferring the required codes of the Flutter package to the new package
• [x] Transferring the required codes of the Flutter example project to the new example package
• [x] Transferring the required codes of the Flutter example_livelist project to the new example_ui package
• [x] Writing codes related to the example project
• [x] Writing the primary codes related to the example_ui project
• [x] Solve CI problems
• [x] Re-examine README.md

Closes: #850

Approach

n/a

TODOs before merging

• [x] Add tests
• [ ] Add changes to documentation (guides, repository pages, in-code descriptions)
• [ ] A changelog entry

[mbfakourii]

@mtrezza @Nidal-Bakir

I implemented a new method base dynamics that the flutter tasks can only use the following code. what is your opinion ?

import 'package:parse_server_sdk/src/utils/parse_server_sdk_flutter.dart';
import 'dart:ui' as ui;

main() async {
  Parse().initializeFlutter(
      "appId",
      "serverUrl",
      packageInfo: await PackageInfo.fromPlatform(),
      ui: ui,
      connectivity: await Connectivity(),
      pathProvider: pathProvider,
      coreStore:  await CoreStoreSharedPrefsImp.getInstance(
          sharedPreferences: (await SharedPreferences.getInstance())),
  );
}

[mtrezza]

How does this address the concerns that have been voiced?

[mbfakourii]

How does this address the concerns that have been voiced?

In this method, all the initial values that were in the Flutter version are set with this, we actually support the Flutter version in Dart and also use pure Dart codes dynamic variables are actually dynamic, that's why from the point of view of our library, we are using dynamic variables instead of variables created in Flutter.

[mtrezza]

Ok, I think the biggest concern with this PR is the additional code that developers would need to write to adapt a single dart package to their OS specific APIs. What could we do about that?

[mbfakourii]

Ok, I think the biggest concern with this PR is the additional code that developers would need to write to adapt a single dart package to their OS specific APIs. What could we do about that?

I said above that the best way is to explain line by line, I will create a separate document for this topic

[mtrezza]

Could we go back to what the actual pain point is that led to the idea of merging the 2 packages? Is that pain on the developers' side or on the maintainers' side, or both?

[mbfakourii]

Could we go back to what the actual pain point is that led to the idea of merging the 2 packages? Is that pain on the developers' side or on the maintainers' side, or both?

More side maintainers But developers choose a library with more confidence

[mtrezza]

Could you outline what the current difficulties for maintainers are? Apologies if that has been posted already somewhere.

Also, could we look at how others are solving this? If we look at other SDK providers, what do they offer, 2 packages or only dart or only flutter?

Looking at firebase as an example, they seem to offer:

• dart core package
• dart OS-specific packages
• flutter installation via CLI

[mbfakourii]

Could you outline what the current difficulties for maintainers are? Apologies if that has been posted already somewhere.

Also, could we look at how others are solving this? If we look at other SDK providers, what do they offer, 2 packages or only dart or only flutter?

Looking at firebase as an example, they seem to offer:

• dart core package
• dart OS-specific packages
• flutter package

I got it . I think it is better to close this PR

[mtrezza]

Are you sure? You seem to have put a lot of work into the PR. I'm not suggesting either way, I'm just trying to facilitate the conversation to hopefully reach more of a consensus.

[mtrezza]

I think the best way forward is keeping an open mind and trying to find a consensus. With significant changes like these there's always a risk that concerns will come up later on. That's why we encourage to first have a discussion in the GitHub issue, maybe leave it open for some time to get more voices in, before opening a PR. I've offered to reach out to the community during the issue discussion for that reason.

[mbfakourii]

With your examples from other libraries, I also doubted, after the research I did, I think it is better to have a flutter version

[mtrezza]

Alright, so the conclusion is that the status quo is fine, or can we learn anything from the other packages?

[mbfakourii]

Alright, so the conclusion is that the status quo is fine, or can we learn anything from the other packages?

The current situation is good

[mtrezza]

Got it, well thanks for all the work with the PRs, they were surely helpful in realizing the scope of the change and in coming to a conclusion; and thanks to all others for their input into this discussion.