nathanwchan / shinigami Goto Github PK

If user A logs in to Tweetsee on a device and visits Bill Gates' profile, a TWTRList entry for BillG is created in the DB for user A. If user A logs out, then user B logs in, the BillG list's owner will be overwritten from user A to user B. If user A logs back in on this same device, they won't see BillG in their suggestions.

Obviously this isn't a huge deal, but highlights the implementation of TWTRList local storage, and might uncover some other issues in the future.

The lists/ownerships.json API has limit of 1000, so the app will be potentially creating duplicate lists if the user has more than 1000 lists. Most people don't create their own lists, or create very few of them, so it'll be a looooong time before a Tweetsee user hits this because of Tweetsee-generated lists.

If you manually go into your Twitter account and delete a Tweetsee_X list, you will never be able to load the profile again. That's because the list still exists in the Realm DB, pointing to that deleted list ID in Twitter. It tries to load it, and simply fails. Doesn't currently try to handle creating a new one. An easy fix would be to just delete it from the Realm DB is this error is detected.

DId a quick scan, and noticed that I'm filtering/sorting (using comparative operators) on non-indexed properties TWTRList.[ownerID, createdAt] and TWTRUserCustom.screenName. Might be worth indexing.

This one needs more thought. The idea if the user is on the Favorites tab, they might naturally be thinking about people they'd want to favorite. Today, they'd have to go to the Search tab, search for the user, enter the user's profile page, then hit the heart button. Maybe we should provide an easier way to add favorites directly from the Favorites tab. Again, more thought on UX needed.

This is the current suggested-for-you list ordering logic: https://github.com/nathanwchan/shinigami/blob/master/shinigami/SearchViewController.swift#L231

Lists that the user has already visited is ordered by createdAt: https://github.com/nathanwchan/shinigami/blob/master/shinigami/SearchViewController.swift#L39

Maybe the DB should have an updatedAt column so that suggestion ordering applies to profile re-visits instead of just new visits.

Open to other suggestions of how to improve this list's ordering.

The biggest problem with Tweetsee is that we're dealing with Twitter's defined rate limits. This is fairly deterministic (docs say 15 requests per 15 minutes per user for certain endpoints), so we could be smart about helping the user understand that the app has limitations. The inCommon Twitter app internally keeps track of API requests made, and presents a notification option for when the API limits have been lifted. See attached pictures.

The Tweetsee app creates private Twitter lists on behalf of the user, but sometimes API calls fail (specifically the add-members-to-list call). This leaves 0 member lists in the user's account, which is gross. I already attempt delete-list calls to clean this up when that particular add-members-to-list call fails (see https://github.com/nathanwchan/shinigami/blob/master/shinigami/ProfileViewController.swift#L58), but sometimes THOSE fail. Maybe on app startup or termination, or somewhere else that makes sense, I can attempt to do this list cleanup.

On initial search page load, the app always checks for public Tweetsee lists, and creates an entry or tries to overwrite it in the DB, if possible. If the list is for a Twitter profile that is currently a user favorite, this overwrite is skipped. This means that this scenario can happen:

1. A user views Mark Cuban's profile in Tweetsee, which creates a new private list with only 100 users in the user's Twitter account
2. The user favorites Mark Cuban
3. We add a new public Mark Cuban list with all 1,400 users he is following
4. The next time the user loads the app, they will continue to be using the private Mark Cuban list with only 100 users, instead of the new public one with 1,400.

Related to Issue #2

Shows nothing in the TableView when the user has no favorites. Maybe use something like this to encourage adding favorites: https://github.com/dzenbot/DZNEmptyDataSet

Currently the UserTableViewCell is duplicated in the Favorites, Search and Profile view controllers. This is gross. Should use xib/nibs to reuse this component.

Intermittently seeing the following: Click on a tweet's author's profile picture to open that user in the profile view controller. This makes a call to retrieve the user's data from Twitter (if it doesn't already exist) to load the profile cell, in addition to all the regular API calls to create a list and add members. I'm occasionally seeing that the spinner loads forever. Pretty sure this was introduced in the fix for #15.

This was a request from @d3ming. Idea is to have a new view showing collated Tweetsee feeds of all your favorites. I personally don't feel the urge for this, but maybe others do.

Technically not super hard, but could eat into Twitter API rate limits depending on number of users the favorites are following. Couple ways to do this:

1. Re-use existing favorites' Tweetsee lists, call list/statuses API for each, and collate tweets in-memory. Problem with this is guaranteeing chronological ordering without missing tweets. If for example it is now 4pm. Favorite A has 50 tweets (current tweet count retrieval from statuses API) from 3-4pm AND 50 more tweets from 2-3pm, but Favorite B has 50 tweets only from 1-2pm; retrieving the last 50 tweets from each favorite and collating them would not correctly reflect tweets in chronological order- Favorite A's 2-3pm tweets would be missing. Not impossible to solve this, just not trivial.
2. Create and keep up-to-date a "Favorites" Tweetsee list for the user of all following users of each Favorite. This way, we can rely on Twitter to do the collation by simply calling the list/statuses API on this new Twitter list. This is the cleanest approach, but will eat into rate limits, especially on initial creation and population of the list.

Already being done in Trump Goggles app, mostly a copy-paste job nathanwchan/trumpgoggles@b1127cc

Currently, in an attempt to prevent Twitter rate limit errors, whenever a non-public profile is loaded for the first time, I limit the number of members to add to 100 so that only one API call is made (100 members is the limit - https://dev.twitter.com/rest/reference/post/lists/members/create_all).

This obviously sucks. If Mark Cuban is following 1,400 users and you load his profile, you're only seeing the tweets from 100 of those following users. But I really don't want to call that API 14 times to load up all 1,400 users because Twitter enforces a 15 requests per 15 minutes per authed user for the members/create_all API. So my stop-guard solution is just to add 100.
But maybe if the app user comes back to Mark Cuban again, and we notice that the list already existings with 100 users, we should try loading more? More to think about here.

The "suggestions for you" list of users in the search page is front-and-center, and currently partly reflects your search history, existing visits, and users you're following. Sometimes you accidentally click on a profile that you didn't care about, which means that that profile will get bumped/inserted to the top of the list on next app-startup. I personally would like the ability to remove those users from the list, just so I don't have to see them again. Not sure if others feel the same.

Technical details: I think we could keep the list intact in Twitter, and just delete the Realm entry in the DB

The code is gross in that there are multi-nested async calls being made to Twitter. One call is made, and in the success callback, another call is made, and in that success callback, another call is made, and so on. Using Promises looks promising (get it?!) to cleanup all this code.