1. 07 May, 2020 1 commit
  2. 06 May, 2020 1 commit
  3. 05 May, 2020 5 commits
  4. 04 May, 2020 5 commits
  5. 02 May, 2020 1 commit
  6. 30 Apr, 2020 2 commits
  7. 29 Apr, 2020 4 commits
    • Jonathan Almeida's avatar
      Closes #6171: Simplify push error handling; reduce non-fatal reporting · cb03ee89
      Jonathan Almeida authored
      Based on the our crash reporting there are only a hand few of exceptions
      that are non-fatal. For the rest, we can simply notify the crash
      reporter.
      
       - Simplified state requirements for native invocation by replacing the
       `DeliveryManager.with` to an extension `PushConnection.ifInitialized`.
       - The new `CoroutineExceptionHandler` now notifies the crash reporter
       of fatal or unknown exceptions.
       - Moved extension functions to their equivalent files in an `.ext`
       package.
       - Added more tests to increase coverage. 🎉
      cb03ee89
    • Michael Comella's avatar
      Issue #5680: Deprecate URLStringUtils.isURLLikeStrict. · a95b8f64
      Michael Comella authored
      I want to remove this method and the expensive regex it relies on
      because:
      
      1. unused code should generally be removed because it's more likely to
      break
      2. if the APIs exist and fulfill someone's needs, they'll use them.
      However, if they had to write their own, they may be able to come up
      with a simpler, alternative implementation that would better fit their
      needs and, in this case, be much more performant.
      3. On a mobile device with limited battery, we shouldn't be
      unnecessarily compiling a regex for a second or more if it's not
      necessary, especially if a simpler implementation is viable
      4. This hard-coded list of TLDs (from 2015) is already out-of-date and
      liable to cause problems: more TLDs are getting all the time so, if
      keeping a hard-coded list of TLDs is actually a need, we should find an
      alternative implementation that lends itself to getting frequent updates
      like our public suffix list
      a95b8f64
    • Gabriel Luong's avatar
    • MickeyMoz's avatar
      Update docs (20200429-120938) · bc865861
      MickeyMoz authored
      bc865861
  8. 28 Apr, 2020 4 commits
  9. 27 Apr, 2020 6 commits
  10. 26 Apr, 2020 1 commit
  11. 24 Apr, 2020 2 commits
  12. 23 Apr, 2020 2 commits
  13. 22 Apr, 2020 3 commits
    • Jeff Boek's avatar
      897e50e1
    • MickeyMoz's avatar
      Update docs (20200422-120704) · 91ae6d07
      MickeyMoz authored
      91ae6d07
    • Grisha Kruglov's avatar
      Closes #6233: Git-based autopublish workflow · eb626793
      Grisha Kruglov authored
      Adds a python script which is responsible for checking if there are any local changes,
      and publishing to mavenLocal if there are.
      
      Before, consuming projects were responsible for this logic; now, they can simply call this command.
      
      This also behaves differently from what fenix did.
      Before, to determine if there are changes we'd run the build, and see if any tasks were
      actually performed (meaning, there were code changes that triggered a rebuild).
      This way had its pros - it wouldn't consider changes to .gitignore, for example, as something that would
      affect the build.
      However, for the most common case, when there are no changes, this approach would still run through the build.
      Doing so comes with a significant overhead of running through all of gradle's build phases, even if there isn't
      actually anything to re-compile.
      
      New approach optimizes for the common case. When there are no changes, we can now determine that almost instantly
      by looking at an aggregate of git hash values for our project. And, by allowing consuming projects to call the python
      script directly, we're skipping the gradle overhead as well.
      
      The end result is a zero-cost auto-publication workflow.
      eb626793
  14. 21 Apr, 2020 2 commits
  15. 17 Apr, 2020 1 commit