Fixed inactive buttons after paste/share

Aga-C commented 3 years ago

Hi,

I've fixed the issue with delete and copy buttons being inactive after pasting clipboard contents or after sharing from another app (it was working only if app was in a background; wasn't working if app wasn't turned on).

It wasn't working, because you were editing text directly in a controller without wrapping it in a proper setState. I provided setState as an argument to getSharedText and PasteClipboardButton to make it work. Also, I've removed an empty setState invocation - it's not needed now.

ManeraKai commented 3 years ago

I did fix it with this commit: https://github.com/ManeraKai/simplytranslate-flutter-client/commit/5cbdbe0441fe5f7c60e83ab6fe8173a044708334

Aga-C commented 3 years ago

I did fix it with this commit: 5cbdbe0

It was working only in one case as I wrote in the first sentence: "it was working only if app was in a background"

ManeraKai commented 3 years ago

https://user-images.githubusercontent.com/40805353/133821216-e421730d-12c1-4795-a00a-283aee6624ee.mp4

Aga-C commented 3 years ago

I've fetched the latest main branch (you're doing a lot of changes on it, hard to track it 😅 ) and sharing in fact is working now, sorry. But the case with pasting still wasn't working as you can see on a video:

https://user-images.githubusercontent.com/85929121/133823676-d66c5458-be1b-400c-b844-f8e53e388375.mp4

And about the change with share - I think that providing setState is a cleaner solution than invoking empty setState. Invoking empty setState sounds like a hack that can cause some bugs later.

btw. it would be easier for contributors, if you'd treat main branch as a stable branch and rather do partial changes on feature branches 😉

ManeraKai commented 3 years ago

Yeah I noticed that.
You're right. Your approach is cleaner.
I'll read about that.

Aga-C commented 3 years ago

Here, you can read a bit about how you can approach committing code to Git: https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

I recommend GitHub Flow, it's most common in open-source projects.

ManeraKai commented 3 years ago

I've read them. Your right about GitHub Flow. The chosen one. However, I commit about 10 times per day. Having every one of them as a separate branch is hard and time consuming. There is no Full-Time Coder other than me at the moment. Separate branches and pull-requests should be for contributes that don't commit daily. The main branch is stable in my opinion. The app is simple and bugs are minor in effect. Not a critical security thing either as it's just a client-side app. Nothing will be hacked if a bug is found.

What I'm talking about: https://trunkbaseddevelopment.com

I think it should be that I can commit directly to the main branch. Testing everything before committing on my local machine of course, and any non-daily contributor should open a branch and a pull request for it.

Btw I've made a mistake that I didn't write a comment after that commit to inform you.

What do you think?

Aga-C commented 3 years ago

Trunk based development is also ok, but still there should be a bit less commits. It will be beneficial for all:

When the project will be bigger, it will be easier to track changes and contribute.
You have GitHub Actions in a project - there is a limit of 2000 minutes per month for free accounts. You may run out of build minutes too quickly with too many commits.

What I think you can do:

If you'd like to go with branches, it's easy - you can do as many commits you want on a branch and later merge them into main (even you can do squash-merge to keep the tree cleaner).
If you prefer trunk based development, you can either:
- Do more changes in one commit. For features, it's not recommended, but for bug fixes it's ok.
- Do commits as you're doing it now, but not push them every time. If you send at once, like 5 commits, it will trigger GitHub Actions only once. Also, you may want to squash commits before pushing, but that's up to you, how you like it.

Besides, what I think would be good is to commit bug fixes directly to main, but do features on the separate branch. This way, you won't need to add partial changes to main. When you finish a new feature, e.g. settings menu, you may then merge the branch into the master. Thanks to this, main will always contain a working version, and you can experiment how much you want on the branches (and also switch locally between them easily).

Btw I've made a mistake that I didn't write a comment after that commit to inform you.

Don't worry, that wasn't a problem. Still, I fixed also another issue here, so no time wasted 😉

ManeraKai commented 3 years ago

You have GitHub Actions in a project - there is a limit of 2000 minutes per month for free accounts. You may run out of build minutes too quickly with too many commits.

GitHub Actions will no longer be triggered by pushing commits. They're now scheduled to run once per day. I can trigger them manually if someone needed an .apk at that moment though.

Do more changes in one commit. For features, it's not recommended, but for bug fixes it's ok.

👍

Thanks to this, main will always contain a working version

In the releases page, you can view the source-code of that release. Either by tag or source-code zip file. btw: A new release will be coming soon.

bug fixes directly to main, but do features on the separate branch. This way, you won't need to add partial changes to main.

Feature branches are allowed with trunk, but are short lived: https://trunkbaseddevelopment.com/short-lived-feature-branches/

ManeraKai / simplytranslate_mobile

Fixed inactive buttons after paste/share #37