1. 12 Jan, 2021 1 commit
  2. 05 Jan, 2021 1 commit
  3. 16 Dec, 2020 1 commit
  4. 04 Dec, 2020 1 commit
  5. 01 Dec, 2020 6 commits
  6. 30 Nov, 2020 1 commit
  7. 22 Nov, 2020 1 commit
    • Jeffrey I. Schiller's avatar
      Add Gallery Readonly Flag · b77b2a5d
      Jeffrey I. Schiller authored
      When set we do not display the “Send to Gallery” Button, only the “Login
      to Gallery” button. The Gallery itself enforces read only status, so if
      the button is enabled but the gallery is in read only (for this
      instance) then the user will receive an error when they attempt to send
      a project to the gallery. But it is better if we can just avoid the
      issue by not providing the button in the first place.
      
      Another implementation here could be to have the server side actually
      check in with the gallery itself to determine read-only status, but for
      now we provide it as a config flag so we do not have to work out the
      details of how and when the server would communicate with the Gallery as
      well as how to handle errors and time-outs etc.
      
      Change-Id: Ib6ca63ab2ca63636d7451762f782050dbffd9b3c
      b77b2a5d
  8. 17 Nov, 2020 1 commit
    • Jeffrey I. Schiller's avatar
      De-bounce the Publish to Gallery button · da2e2cbb
      Jeffrey I. Schiller authored
      Some people were double-clicking this button which results in two copies
      of the project being sent to the Gallery simultaneously. This results in
      two entries for the project appearing in the Gallery. Then when the
      author next goes to update it, the Gallery finds two copies and fails.
      
      We will be adding a uniqueness constraint to the Gallery database which
      will prevent this. However this will result in one of the two
      transactions failing. Depending on the exact timing of things this can
      still result in the end-user receiving an error.
      
      This change “de-bounces” the Publish button so while one button push is
      still being processed, a second is ignored silently.
      
      Change-Id: Idd7506773b5e2a27500250d82a1350602b634a77
      da2e2cbb
  9. 05 Nov, 2020 2 commits
    • Jeffrey I. Schiller's avatar
      The New Gallery · 72e0a501
      Jeffrey I. Schiller authored
      This commit adds the interface support for the new gallery.
      
      The new gallery is a separate system run on its own
      infrastructure (which today consists of a horizontally scale-able
      collection of Linux virtual servers).
      
      It is configured via three system properties (out of
      appengine-web.xml). They are:
      
      gallery.enabled –  Set this to “true” to enable the Gallery
      gallery.id –       This is a string which is used to identify this
                         instance of App Inventor to the gallery. It is
                         also used to identify the shared keys needed
                         to authenticate tokens sent to the Gallery
      gallery.location – The location (URL) of the gallery itself.
      
      Change-Id: I30745a65c976cadd288650f779a9bf546097567a
      72e0a501
    • Jeffrey I. Schiller's avatar
      Remove old Gallery · bafdb08e
      Jeffrey I. Schiller authored
      This change removes the original “integrated” Gallery.
      
      Change-Id: I782834a6c86a379c5f47de7a5da1d24547bcd829
      bafdb08e
  10. 21 Oct, 2020 4 commits
  11. 05 Oct, 2020 1 commit
  12. 21 Sep, 2020 2 commits
  13. 10 Sep, 2020 4 commits
  14. 04 Sep, 2020 2 commits
  15. 02 Sep, 2020 1 commit
  16. 31 Aug, 2020 3 commits
  17. 27 Aug, 2020 1 commit
  18. 26 Aug, 2020 1 commit
  19. 21 Aug, 2020 2 commits
    • Evan W. Patton's avatar
      Make specific drop targets to reduce chances of inadvertent drop capture · 9638c167
      Evan W. Patton authored
      Change-Id: Idd7b231e4c57da44b008ba4c5fbb700cf4342d78
      9638c167
    • Evan W. Patton's avatar
      Implement LegacyMode for File component · 0fc9fd19
      Evan W. Patton authored
      With the nb184 change, apps that previously worked on Android 10 may
      no longer work if the app in question stored files based on the
      external storage root (e.g., /sdcard). While Google isn't enforcing
      read/write access to directories outside of the app-private path just
      yet (this will be true in Android 11), we switched over most file
      operations to use the app-private path anyway starting with Android
      Q. New apps will read/write files without issue, however apps that are
      used to using the old path on Android 10 have no way to read files
      they may have written.
      
      This change adds a LegacyMode property to File, which is False by
      default, that allows a developer to access files relative to the root
      of the external storage on Android 10 and higher. I've included a note
      that the use of this property may cause apps to fail starting with
      Android 11.
      
      Change-Id: I4ab0d26e54d2a74535b4a691cfd63826543d29a4
      0fc9fd19
  20. 12 Aug, 2020 4 commits