iOS - Letting users subscribe to a topic?

Hi Scott,

There are a lot of different ways to do it. Up front I would recommend avoiding iCloud + Core Data. There's a great discussion on the Debug Podcast about the pitfalls of that approach.

I recommend thinking through if you want to use iCloud or if you want to just avoid it. It's definitely easier to avoid it, but as of Xcode 5, iCloud integration got a whole lot easier. (Check out Apple's 2013 WWDC videos on how to do that, if you have a developer license.)

I also recommend against using NSUserDefaults for storing your data. Save that sort of thing for keeping track of whether you've asked the user to rate the app or not—if they decline to rate the app, save that as a NSUserDefaults object. (Which is really just a key-value or NSDictionary pair.)

The simplest thing to do would be to save a NSMutableArray filled with strings of those hash tags. (You might want to avoid saving the hash tag itself in the string and just add it at display time, to make searching functions easier.) NSArray, and therefore their subclass NSMutableArray, have a nice writeToFile method that turns your array into an XML object and saves it to file. To be honest, I'm not sure what the best place to save a file, but it would seem like the Documents are of the app's Sandbox would make the most sense. You can probably take this approach and integrate it with iCloud via their Key-Value Data in iCloud, which is one of three types of iCloud data management. (Again, it's recommended you avoid iCloud + Core Data, but by all means look into it if you're interested.)

A far more difficult approach would be to have the user's subscription (array) stored on a server somewhere. You'd have to worry about security and creating/managing user accounts, aside from the complexity of making a website. It's far easier to keep things completely native, but that prohibits you from allowing users to share their subscriptions with others—for that you need a database and servers and web development costs and resources.

I'd be interested to know what you go with and how it turns out! Full disclosure, I've never fully implemented any of these myself, I've only read, heard, and thought a lot about them. If you find a more professional opinion, go with that.

Edit: I almost missed a crucial part of your question. You'll probably need to pull requests from Twitter or whatever service you're using—it doesn't really do much if all the user has is a list of hash tags that don't actively pull in content. If it's Twitter, you'll have to check out their API. The biggest thing I can recommend is that whatever data you pull in, you do it asynchronously so it doesn't lock up the app. For that you'll need to know a little about delegates, maybe about NSURLConnection and so on—but it depends greatly upon how Twitter or whatever you're using runs their API. If they return a JSON object, go with NSURLConnection to handle the asynchronous downloading of that JSON file, and then use NSJSONSerialization to parse it. NSJSONSerialization might be a bit confusing at first, but it's pretty simple once you know what it's asking. (Simple as in it only takes a few lines of code to parse a JSON file; way easier than using the XML parser, especially for just grabbing an NSArray that only contains NSStrings.)

Hi Mike,

Thanks so much for such a detailed response, I really do appreciate it.

At the moment, the solution that seems to make the most sense to me is storing the user's subscription array on a server somewhere. I am already creating and managing user accounts. To give you a bit more colour, I'm creating a feature around users being able to follow #hashtags (topics) where they can post content to that hashtag and receive content from specific hashtags. E.g. handbags, they'd have a feed of the latest handbag submissions.

Now that you have a little more colour on what I'm trying to achieve, any other words of wisdom?

Thanks. Happy to take this offline if you want, maybe chat via Skype or something.

Best, Scott

I was working with a startup that was doing something very similar. At the time we looked into this last year, Twitter had a limit of 100,000 server requests per day or something like that. But we decided to get into a completely different niche anyway, so we never had to worry about the implementation. Are you using Twitter? If you can avoid pulling tons of data from their servers, I think you'll save yourself a lot of trouble. For example, rather than pulling a list of all hash tags from Twitter every day, have your master list of hash tags live on your server, so you never have to pull something from their server except whatever data they return for a given hash tag.

From a design perspective (and to help you get approved by Apple), I would recommend not requiring the user to sign up to use all features of the app. If you can allow a user to make a temporary account without signing up for anything (i.e., come up with some user-id that gets paired with their device and stored in an NSUserDefaults object), and then allow them to easily transfer that information into a sign-up account, that would be money. (An American term for awesome.)

Since you're building your own implementation on a server, probably go with serving up JSON data to the user's device and do the asynchronous loading with NSURLConnection, and avoid iCloud entirely. I'm not sure what the best way to save a user's login information—obviously something encrypted.

Another thing to think about—suppose multiple users look up "handbags." You'd want to figure out if you cache that feed on your server (say if the results are from Twitter), or if their device requests the list from Twitter itself and circumvents your site entirely. Because maybe there's some tradeoff in terms of staying within the allowed number of server requests from whoever hosts the overall feed (i.e. Twitter). It's really hard to say without knowing the rules of the service you're pulling from. (And maybe they have more relevant FAQ on their site.)

You also have to wonder whether you need to create a level of security in the data you return to the user. i.e., do you need to encrypt the array of hashtags when they go to view the hashtags they're subscribed to? Is that even necessary? Obviously protect their user-name and password via encryption, but I'm not sure if it makes sense or not to encrypt any other information.

One more thing to consider: it's my guess that if your users are pushing content to Twitter, they wouldn't care as much about that 100,000 requests limit. The way I see it, if your users are increasing the content richness on Twitter (rather than your app dragging away Twitter users), Twitter will be happy. That's speculation though.

Hi Mike, I was hoping that we wouldn't need to interact with Twitter at all. I wanted users to either create their own list of hashtags (topics) or I would seed them with say a list of 500 common ones, then others could add when and if required. Would this simplify the whole ordeal or make it more complicated?

As always thank you so much for your detailed answers - I definitely owe you a beer or two!

Glad I can help! I find these sort of things very interesting.

So if you're not interacting with Twitter, where is the content coming from? What I mean is, the way Twitter works is people have Twitter accounts, they post 144 characters of awesomeness with a hashtag at the end. But the hashtags only make sense because of whatever content is in the other 144 characters. For instance, I follow programming on Twitter, and someone recently used #OSX. The hash tag is useful in that people look for content about #OSX, right? But if you don't interact with Twitter at all, what is the meaningful content? (If that's a secret element of your app, I don't want to you to expose that if you don't want to.) I'm just trying to understand where your information is coming from in order to help answer your question.

It would sound like your idea of seeding users a list of 500 common hashtags would make a lot of sense. It definitely simplifies things if your site holds all available hash tags used in your app; if you had to pull that list of hashtags from Twitter, you would probably reach your limit fairly quickly and run the risk of having your server's IP blocked (if they do that sort of thing). The more content you can generate and maintain on your server the better, in my opinion, because then you can choose how to access it and you don't have to worry about policies other than whatever Apple requires of you.