<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId in Dropbox API Support &amp; Feedback</title>
    <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145578#M4697</link>
    <description>&lt;P&gt;Not really a critical issue, but for our project it brought some inconveniences.&lt;BR /&gt;So, currently DropboxAccessToken stores user id from API v1, while Users.Account.accountId stores API v2 account id.&lt;/P&gt;
&lt;P&gt;Our app has it's own account system and it supports usage of multiple accounts at the same time. Every account can link multiple dropbox accounts and every user can go to a screen where he can add another dropbox account or remove linked dropbox account.&lt;/P&gt;
&lt;P&gt;In order for user to understand which dropbox account he unlinks, we use and display&amp;nbsp;e-mails. To get account's email, we make a call to DropboxClient.users.getCurrentAccount(). So far so good.&lt;/P&gt;
&lt;P&gt;But making requests takes time. Plus we have our own file browser which supports switching between accounts, and we use e-mails there too. So it makes sense to cache Users.FullAccount in order to have fast access to e-mails.&lt;/P&gt;
&lt;P&gt;With API v1 we had a small "database" with DBAccountInfo, where we could make a request "give us a cached account for userId". With API v2 "database" implementation gets harder:&lt;/P&gt;
&lt;P&gt;1) Create a subclass of Users.FullAccount, which will have a property "APIv1userId", and create a subclass of FullAccountSerializer&amp;nbsp;&lt;/P&gt;
&lt;P&gt;1) get access token, get userId&lt;/P&gt;
&lt;P&gt;2) create client with userId, call getCurrentAccount()&lt;/P&gt;
&lt;P&gt;3) Create an instance of FullAccount subclass, and use APIv1userId property.&lt;/P&gt;
&lt;P&gt;Too much work for something simple as caching and differentiating which account info belongs to which account.&lt;/P&gt;
&lt;P&gt;For the same reason I would like to ask you to make functions because we in order to cache&amp;nbsp;FullAccount, we serialize it first.&lt;BR /&gt;prepareJSONForSerialization()&lt;BR /&gt;objectToJSON()&lt;/P&gt;
&lt;P&gt;So, is there a possibility to SwiftyDropbox will use v2 account id in access tokens? This would simplify things a lot and remove one very unclear moment: DropboxAccessToken.userId and FullAccount.accountId are different things. Intuitively, people think that they are the same.&lt;/P&gt;
&lt;P&gt;And, of course, if you have a better solution for our "cache database", I will be glad to hear it.&lt;/P&gt;
&lt;P&gt;Thanks in advance, Gregory!&lt;/P&gt;</description>
    <pubDate>Wed, 29 May 2019 09:35:27 GMT</pubDate>
    <dc:creator>Aibek D.</dc:creator>
    <dc:date>2019-05-29T09:35:27Z</dc:date>
    <item>
      <title>[SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145578#M4697</link>
      <description>&lt;P&gt;Not really a critical issue, but for our project it brought some inconveniences.&lt;BR /&gt;So, currently DropboxAccessToken stores user id from API v1, while Users.Account.accountId stores API v2 account id.&lt;/P&gt;
&lt;P&gt;Our app has it's own account system and it supports usage of multiple accounts at the same time. Every account can link multiple dropbox accounts and every user can go to a screen where he can add another dropbox account or remove linked dropbox account.&lt;/P&gt;
&lt;P&gt;In order for user to understand which dropbox account he unlinks, we use and display&amp;nbsp;e-mails. To get account's email, we make a call to DropboxClient.users.getCurrentAccount(). So far so good.&lt;/P&gt;
&lt;P&gt;But making requests takes time. Plus we have our own file browser which supports switching between accounts, and we use e-mails there too. So it makes sense to cache Users.FullAccount in order to have fast access to e-mails.&lt;/P&gt;
&lt;P&gt;With API v1 we had a small "database" with DBAccountInfo, where we could make a request "give us a cached account for userId". With API v2 "database" implementation gets harder:&lt;/P&gt;
&lt;P&gt;1) Create a subclass of Users.FullAccount, which will have a property "APIv1userId", and create a subclass of FullAccountSerializer&amp;nbsp;&lt;/P&gt;
&lt;P&gt;1) get access token, get userId&lt;/P&gt;
&lt;P&gt;2) create client with userId, call getCurrentAccount()&lt;/P&gt;
&lt;P&gt;3) Create an instance of FullAccount subclass, and use APIv1userId property.&lt;/P&gt;
&lt;P&gt;Too much work for something simple as caching and differentiating which account info belongs to which account.&lt;/P&gt;
&lt;P&gt;For the same reason I would like to ask you to make functions because we in order to cache&amp;nbsp;FullAccount, we serialize it first.&lt;BR /&gt;prepareJSONForSerialization()&lt;BR /&gt;objectToJSON()&lt;/P&gt;
&lt;P&gt;So, is there a possibility to SwiftyDropbox will use v2 account id in access tokens? This would simplify things a lot and remove one very unclear moment: DropboxAccessToken.userId and FullAccount.accountId are different things. Intuitively, people think that they are the same.&lt;/P&gt;
&lt;P&gt;And, of course, if you have a better solution for our "cache database", I will be glad to hear it.&lt;/P&gt;
&lt;P&gt;Thanks in advance, Gregory!&lt;/P&gt;</description>
      <pubDate>Wed, 29 May 2019 09:35:27 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145578#M4697</guid>
      <dc:creator>Aibek D.</dc:creator>
      <dc:date>2019-05-29T09:35:27Z</dc:date>
    </item>
    <item>
      <title>Re: [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145579#M4698</link>
      <description>&lt;P&gt;Okay, now that I actually implemented "database" that supports API v2, I think that the SwiftyDropbox improvement would be to:&lt;/P&gt;
&lt;P&gt;1) Add "v1APIuserId" (or something like this) property to Users.FullAccount, which will contain userId from v1 API.&lt;/P&gt;
&lt;P&gt;2) make&amp;nbsp;prepareJSONForSerialization(),&amp;nbsp;objectToJSON() functions public, in order to simplify serialization, caching and storing FullAccount for client code.&lt;/P&gt;
&lt;P&gt;Right now, they're private and to implement storing, I ended up with simply copy-pasting those functions.&lt;/P&gt;
&lt;P&gt;3) Add explicit initializers&amp;nbsp;for&amp;nbsp;StringSerializer and some other serializers in order to simplify subclassing.&lt;/P&gt;
&lt;P&gt;Although&amp;nbsp;StringSerializer is a public class, there's no way client code can use it, because there's no accessible initializers. Ditto for a bunch of other serializers. I also had to copy-paste StringSerializer in order to implement caching.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;And, of course, these are just my thoughts, I hope you will consider these thoughts sane and good.&lt;/P&gt;</description>
      <pubDate>Sat, 20 Feb 2016 22:25:07 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145579#M4698</guid>
      <dc:creator>Aibek D.</dc:creator>
      <dc:date>2016-02-20T22:25:07Z</dc:date>
    </item>
    <item>
      <title>Re: [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145580#M4699</link>
      <description>&lt;P&gt;Thanks for the writeup&amp;nbsp;Aibek! I'm sending these along as feature requests, though I can't make any promises about if or when they'd be implemented.&lt;/P&gt;
&lt;P&gt;One note, it doesn't sounds like you necessarily are, but just to be sure/for anyone else reading, you definitely shouldn't rely on email address as an account identifier in your app, as it can change on Dropbox's side. Either of the other account IDs (user ID or account ID) are better suited for that. Email is fine for display purposes though.&lt;/P&gt;</description>
      <pubDate>Tue, 23 Feb 2016 06:05:25 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145580#M4699</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-02-23T06:05:25Z</dc:date>
    </item>
    <item>
      <title>Re: [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145581#M4700</link>
      <description>&lt;P&gt;The&amp;nbsp;serialization methods are now public in &lt;A href="https://github.com/dropbox/SwiftyDropbox/releases/tag/3.1.0" target="_blank" rel="nofollow noreferrer"&gt;version 3.1.0&lt;/A&gt;.&lt;/P&gt;</description>
      <pubDate>Wed, 03 Aug 2016 04:25:20 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/145581#M4700</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2016-08-03T04:25:20Z</dc:date>
    </item>
    <item>
      <title>Re: [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/240253#M13372</link>
      <description>&lt;P&gt;Hi Greg,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Are you saying that userID is sufficient to distinguish a unique Dropbox account? As our product were storing this information(userID) since V1, it is difficult for us to switch to another value(accountID) now unless we drop all our exisitng connected Dropbox accounts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you for the help.&lt;/P&gt;&lt;P&gt;Chao&lt;/P&gt;</description>
      <pubDate>Wed, 06 Sep 2017 06:06:36 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/240253#M13372</guid>
      <dc:creator>fengzhazha</dc:creator>
      <dc:date>2017-09-06T06:06:36Z</dc:date>
    </item>
    <item>
      <title>Re: [SwiftyDropbox] Storing v2 accountId in DropboxAccessToken instead of v1 userId</title>
      <link>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/240317#M13380</link>
      <description>&lt;P&gt;Yes, both user ID and account ID uniquely identify Dropbox accounts.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;By the way, you can call &lt;A href="https://dropbox.github.io/SwiftyDropbox/api-docs/latest/Classes/UsersRoutes.html#/s:FC13SwiftyDropbox11UsersRoutes17getCurrentAccountFT_GCS_10RpcRequestCCS_5Users21FullAccountSerializerCS_14VoidSerializer_" target="_self"&gt;getCurrentAccount&lt;/A&gt;&amp;nbsp;(or the equivalent method/endpoint in your platform)&amp;nbsp;for each stored account to map from user ID to account ID.&lt;/P&gt;</description>
      <pubDate>Wed, 06 Sep 2017 14:15:05 GMT</pubDate>
      <guid>https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/SwiftyDropbox-Storing-v2-accountId-in-DropboxAccessToken-instead/m-p/240317#M13380</guid>
      <dc:creator>Greg-DB</dc:creator>
      <dc:date>2017-09-06T14:15:05Z</dc:date>
    </item>
  </channel>
</rss>

