{"action":"created","issue":{"url":"https://api.github.com/repos/opendatakit/briefcase/issues/643","repository_url":"https://api.github.com/repos/opendatakit/briefcase","labels_url":"https://api.github.com/repos/opendatakit/briefcase/issues/643/labels{/name}","comments_url":"https://api.github.com/repos/opendatakit/briefcase/issues/643/comments","events_url":"https://api.github.com/repos/opendatakit/briefcase/issues/643/events","html_url":"https://github.com/opendatakit/briefcase/pull/643","id":359887331,"node_id":"MDExOlB1bGxSZXF1ZXN0MjE1Mjc1OTQ0","number":643,"title":"Issue 595 normalize startup behavior","user":{"login":"ggalmazor","id":205913,"node_id":"MDQ6VXNlcjIwNTkxMw==","avatar_url":"https://avatars0.githubusercontent.com/u/205913?v=4","gravatar_id":"","url":"https://api.github.com/users/ggalmazor","html_url":"https://github.com/ggalmazor","followers_url":"https://api.github.com/users/ggalmazor/followers","following_url":"https://api.github.com/users/ggalmazor/following{/other_user}","gists_url":"https://api.github.com/users/ggalmazor/gists{/gist_id}","starred_url":"https://api.github.com/users/ggalmazor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ggalmazor/subscriptions","organizations_url":"https://api.github.com/users/ggalmazor/orgs","repos_url":"https://api.github.com/users/ggalmazor/repos","events_url":"https://api.github.com/users/ggalmazor/events{/privacy}","received_events_url":"https://api.github.com/users/ggalmazor/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-09-13T13:06:14Z","updated_at":"2018-09-18T09:07:41Z","closed_at":null,"author_association":"MEMBER","pull_request":{"url":"https://api.github.com/repos/opendatakit/briefcase/pulls/643","html_url":"https://github.com/opendatakit/briefcase/pull/643","diff_url":"https://github.com/opendatakit/briefcase/pull/643.diff","patch_url":"https://github.com/opendatakit/briefcase/pull/643.patch"},"body":"Closes #595\r\n\r\n#### What has been done to verify that this works as intended?\r\nI've manually verified each scenario described in the issue:\r\n- When user credentials change between Briefcase launches\r\n- When the server somehow malfunctions or it's missing\r\n\r\n#### Why is this the best possible solution? Were any other approaches considered?\r\nThis continues the work started by @dcbriccetti and @jpknox to avoid failures and provide users with options and feedback when something goes wrong.\r\n\r\n#### How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?\r\n\r\n- Users should expect an error dialog whenever there's an error while reloading (or preloading, if Briefcase is starting) forms from a configured source.\r\n- The underlying errors should appear on the logs\r\n- No sentry events should be sent due to this errors.\r\n\r\n#### Does this change require updates to documentation? If so, please file an issue at https://github.com/opendatakit/docs/issues/new and include the link below.\r\nNo.\r\n"},"comment":{"url":"https://api.github.com/repos/opendatakit/briefcase/issues/comments/422316709","html_url":"https://github.com/opendatakit/briefcase/pull/643#issuecomment-422316709","issue_url":"https://api.github.com/repos/opendatakit/briefcase/issues/643","id":422316709,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMjMxNjcwOQ==","user":{"login":"ggalmazor","id":205913,"node_id":"MDQ6VXNlcjIwNTkxMw==","avatar_url":"https://avatars0.githubusercontent.com/u/205913?v=4","gravatar_id":"","url":"https://api.github.com/users/ggalmazor","html_url":"https://github.com/ggalmazor","followers_url":"https://api.github.com/users/ggalmazor/followers","following_url":"https://api.github.com/users/ggalmazor/following{/other_user}","gists_url":"https://api.github.com/users/ggalmazor/gists{/gist_id}","starred_url":"https://api.github.com/users/ggalmazor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ggalmazor/subscriptions","organizations_url":"https://api.github.com/users/ggalmazor/orgs","repos_url":"https://api.github.com/users/ggalmazor/repos","events_url":"https://api.github.com/users/ggalmazor/events{/privacy}","received_events_url":"https://api.github.com/users/ggalmazor/received_events","type":"User","site_admin":false},"created_at":"2018-09-18T09:07:41Z","updated_at":"2018-09-18T09:07:41Z","author_association":"MEMBER","body":"> Here’s what I recommend. What do you think? dcbriccetti@9d0c5e7?w=1\r\n\r\nIf I understand correctly, a SwingWorker distributes an operation to the correct threads for each thing:\r\n\r\n- Current thread: The execute() method is called on this thread. It schedules SwingWorker for the execution on a worker thread and returns immediately. One can wait for the SwingWorker to complete using the get methods.\r\n- Worker thread: The doInBackground() method is called on this thread. This is where all background activities should happen. To notify PropertyChangeListeners about bound properties changes use the firePropertyChange and getPropertyChangeSupport() methods. By default, there are two bound properties available: state and progress.\r\n- Event Dispatch Thread: All Swing related activities occur on this thread. SwingWorker invokes the process() and done() methods and notifies any PropertyChangeListeners on this thread.\r\n\r\n  (copied from this [post](https://www.codementor.io/isaib.cicourel/swingworker-in-java-du1084lyl))\r\n\r\nSome extra context:\r\n- The only block that will ever run outside the EDT is the PullPanel constructor, and that's why it's important to launch the dialog with `invokeLater()`, which ensures that it will run on the EDT. (same happens with all the other components' constructors)\r\n\r\n- The method `sources.getFormList()` can become a long-running process that could block the UI, and that's why we want to launch it in another thread.\r\n\r\n- We have the same problem with other long-running processes:\r\n  - Exporting forms\r\n  - Pulling forms\r\n  - Pushing forms\r\n  - Maybe even refreshing the forms cache\r\n\r\n- The same problem exists in the context of the CLI\r\n\r\nI'm hesitant to couple ourselves to Swing to solve our concurrency needs. \r\n- We know we wouldn't be able to use it on the CLI, forcing us to solve the same problem twice, using different stacks.\r\n- We know that Swing's threading model is kinda old and wrong: it's not thread-safe \r\n and it feels like everything depends on not forgetting to use SwingWorkers and invokeLaters. It doesn't take complexity away and [threading is hard](https://www.google.es/search?q=threading+is+hard&oq=threading+is+hard&aqs=chrome..69i57j0l5.3382j0j7&sourceid=chrome&ie=UTF-8). I'd prefer a more safer & closed system that \"just works the way we want\" (the UI class is one example of this).\r\n- Briefcase needs a longstanding revamp of its concurrent code to take advantage of modern Java8 features like `CompletableFutures`. Maybe this could be a first run at this.\r\n\r\n"}}
{"actor":{"display_login":"ggalmazor"}}