We want to intercept the user action of actually following the link our button generates (it would load the Twitter website and ask users to log in) – so let’s place an invisible UIButton over the web view and action that instead:
Opening the Twitter App is pretty much the same as opening the Facebook App discussed earlier, just the URL scheme is different.
This is how we open Twitter so people can follow the user (me in this case, versluis). If the call is unsuccessful, we’ll try to open the Twitter page in Safari. And if that doesn’t work, we’ll display a log message:
If the app is not installed nothing happens – which may mean that the app is not installed. As a fallback we’re opening the same page with Safari. If that also doesn’t work, a log message is displayed.
Note that to pass your page into the Facebook App you need your Page or Profile ID. There are several ways to find those:
The caveat is that it’s a UIWebView, and as such if users click on the Like Button, the “real” Facebook action happens inside your tiny web view (i.e. Facebook.com loads and prompts the user to login or sign up). Not really what we want.
Let’s fix it by simply placing a transparent UIButton on top of your web view, and hook the button up to an action:
Now you can react however you see fit: open a URL in Safari, open the Facebook App, etc.
Another thing of note: since the button will be pulled in from Facebook.com, it will not be displayed when a user is not online. Check via UIWebViewDelegate and if the URL can’t be loaded present an image from your bundle instead.
The NSDictionary class doesn’t have a length property that can tell us how much memory is being used for storing the whole lot. Usually we don’t really care how big our variables grow – but if you’re storing that dictionary somewhere with potentially limited space (such as iCloud Key/Value storage), it may well be of interest.
You can however turn the dictionary into data and test its size like this:
Here we setup a loop that generates a dictionary and adds 1001 entries with an NSNumber literal of 47. This will give us the following information:
Size in bytes: 12954 – Entries: 1001
Note that the above only works if your dictionary has “serialisable” data such as NSNumber, NSDate, NSArray, NSDictionary, NSString or NSData (anything that can be written to a .plist file basically) – but it will not work with custom objects.
Note that I’m also setting the title property of each view controller. This is displayed as the tab bar text and is left blank if not specified. To override this behaviour and/or specify graphics, set the UITabBarItem of each individual view controller.
The method that creates the view controllers is very straightforward: in this example I have a single ViewController in my storyboard (with a Storyboard ID of “PlainViewController”). All we do here is specify a funky background colour to tell them apart:
You can switch out the NSPersistentStore file in your running Core Data app by first adding your new store file, then removing the previous one. Once done you must execute your fetch request again so that the new data is available.
Hot-swapping stores assumes both NSPersistentStore files are based on the same model. It’s like replacing a USB stick.
First let’s pass a reference of the Persistent Store Coordinator into the class you’d like to make the switch in. Based on the Xcode Utility Project, that’s MainViewController. The Core Data stack is already setup in the App Delegate, so we’ll pass a reference here:
NSLog(@"Couldnot remove first store.Error was:%@",error);
Test this by fetching your data before and after the swap. You don’t have to remove the second store, you can leave it in place if you’d like to fetch data from both stores. I’m not sure though what will happen if you add data – it may end up in both stores.
To check if your store file has changed, you can subscribe to this notification: