-
Mathematica code:
Animate[
Graphics[
Table[
Circle[{0, i}, t + (16 - n) (1 + Sign[16 - n])/2],
{n, 0, 100, 1}, {i, -5, 5,1}],
PlotRange -> 6],
{t, 0, 1, .01}] -
Twitter Integration
With more than 3000 apps integrated with Twitter, is not really a big surprose to learn that iOS 5 adds APIs to make things even easier.
If all we need to to allow users to push tweets from our apps, then it is really easy. All we need to do is to link the ´Twitter.framework´ and then import
Twitter/TWTweetComposeViewController.hwhere we need it.TWTweetComposeViewControlleris basically a modal view that supports user interactions to compose a tweet. One important method is the class methodcanSendTweetthat returns eitherYESorNOdepending on whether the device can send a tweet. The rest is really simply,allocandinitand instance ofTWTweetComposeViewControllerset a completion handler, and if appropriate, add some initial content like a URL, some text or images.Here some code to play around.
-
Werror or GTFO
There are a few useful warnings that should be set in any Xcode project. Here them, and why you should care:
- Mismatched Return Type Warns if a function does not declare a return type, or if the return type is not
void, but areturnstatement is found without a return value. - Sign Comparison You have a signed and and unsigned comparision. This warn will let you know if the result is incorrect after the signed get’s convertd to unsigned.
- Undeclared Selector Checks if the
@selectorconstruct makes reference to an undeclared selector. Let’s say you are handling a notification with a method you are referring to the@selectorexpression. Later on, you change the signature of the method. Unless you set this alarm, the code will be unaware of this change until runtime, when is already too late, and the app crash. - Treat Warning as Errors aka:
WerrorIn many other platforms, warnings are not that important. That’s not the case with Cocoa. Here a warning should be treated as an error, because most of the times, is just an error waiting to happens. - Run Static Analyzer The clang static analyzer is the best thing that happens to humanity ever. Well, ok, perhaps there is a little hyperbole here. But in any case, is always an excellent idea to run early, to run often this tool.
- Mismatched Return Type Warns if a function does not declare a return type, or if the return type is not
-
Famous Physicists
By Heidi Sandhorst
Famous Physicists 2010 Trading Card Set for sale. 20 4″ x 6″ glossy cards with rounded corners featuring handmade artwork and information about each physicist on the back as well as an inspirational quote from each physicist. Each set comes in a black box with hand drawn label and gold rubber band to hold it shut. $20 plus s+h (if applicable).
Email me at heidisandhorst@gmail.com if you are interested in purchasing a set.
(Source: ecr206)
-
Not always faster
A few weeks ago, I was asked how to sort an array, and I was prompt to answer “using GCD”. Bilal LoLo (@anabillo) ask again “why not
NSSortDescriptor”, and I was “because GCD is faster”. Is it? Well, there is an obvious way to know. Truth be told, I was using sort descriptors before GCD was introduced to the phone. And when it was introduced, I automatically assumed that because GCD is terrible fast, then anything is faster in GCD. Well, it turns out that the old fashion and well known sort descriptor beats GCD here. And not by a marging, but by an order of magnitude. Moral of a fable? It worth checking asumptions with real code.And talking about code, here’s the meat.
-
History of the iPhone
-
Instagram Engineering: Sharding & IDs at Instagram →
With more than 25 photos & 90 likes every second, we store a lot of data here at Instagram. To make sure all of our important data fits into memory and is available quickly for our users, we’ve begun to shard our data—in other words, place the data in many smaller buckets, each holding a part of…
-
When the deal goes down
I’m pretty sure that your code, as mine, never has bugs. It just develops random features. But you know, sometimes sheet happens, or at least that’s what I’ve been told.
In Cocoa there two mechanism to deal with, let’s say, random features. Exceptions, and error reporting. Apple strongly recommends not to use exception like in other platforms. In Cocoa, exceptions are meant to be use mostly in development, or in libraries. The recommended way to report when the app is not behaving is through
NSError.In many Cocoa APIs we will find an error parameter. They usually takes the address of an
NSErrorvariable (not the reference). Takes, for instance,- (NSArray *)executeFetchRequest:(NSFetchRequest *)request error:(NSError **)error. First you declare aNSErrorand then, you pass it to the API, if this particular call, returnsnil, then you know something went wrong (it should returns an array. An empty array if nothing found, but an array). If that’s the case, the error will bring the details of what’s wrong.NSError *error = nil; NSArray *fetched = [context executeFetchRequest:fetchRequest error:&error]; if ( fetched == nil ) { NSLog(@"error: %@", error); }The return value of the error pointer is undefined if the method succeeded. Therefore, you should never use the value (
nilor non-nil) of anNSErrorpointer to decide if an error happened.NSErrorare composed with a domain and a code. The domain is there for historic reasons. It is sometimes useful to know the subsystem that has produced the error. The domain is string, most of the times with an inverse domain name (likenet.volonbolon.subsystem). The error codes, on the other hand, are numbers. The different numbers indicate a different problem in a given subsystem. You can check the Foundation Kit error codes here.But not everything is a code,
NSErroroffers more information via a set of different APIs. The content returned by these APIs is composed with the content of theuserInfodictionary of theNSError. But sinceuserInfois not mandatory, there is only one API that is guaranteed to return a string:localizedDescription.localizedDescriptionis either the string stored with theNSLocalizedDescriptionKeyin theuserInfodictionary, or an string constructed from the domain and the code.localizedRecoveryOptionsreturns an array the localized titles of buttons appropriate to display to the user to fix the issue. By default this method returns the object in the user info dictionary for the keyNSLocalizedRecoveryOptionsErrorKey.localizedRecoverySuggestionreturns a string containing the localized recovery suggestion for the error. This is the string stored in theuserInfodictionary with the keyNSLocalizedRecoverySuggestionErrorKey.localizedRecoverySuggestionalso returns a string, this time with a localized recovery suggestion for the error. This is stored inuserInfowithNSLocalizedRecoverySuggestionErrorKey. The last API islocalizedFailureReasonthat contains a localized explanation of the reason for the error. By default this method returns the object in the user info dictionary for the keyNSLocalizedFailureReasonErrorKey.Sometimes, for instance, if you are validating a Core Data Managed Object to insert in the context, you may need to append to and error produced by some native API some more information to let the use knows what’s wrong with the managed object. Here’s a snippet that do just that:
- (NSError *)errorFromOriginalError:(NSError *)originalError error:(NSError *)secondError { NSMutableDictionary *userInfo = [NSMutableDictionary dictionary]; NSMutableArray *errors = [NSMutableArray array]; if ( [originalError code] == NSValidationMultipleErrorsError ) { [userInfo addEntriesFromDictionary:[originalError userInfo]]; [errors addObjectsFromArray:[userInfo objectForKey:NSDetailedErrorsKey]]; } else { [errors addObject:originalError]; } [userInfo setObject:errors forKey:NSDetailedErrorsKey]; return [NSError errorWithDomain:NSCocoaErrorDomain code:NSValidationMultipleErrorsError userInfo:userInfo]; }Exceptions
In Objective-C an exception should not be used as in Java. In Objective-C an exception should be used only in development, and only to catch errors in the code, never to handle expected errors, like a
nilresponse. Exceptions are instances ofNSException. They contain a name, a reason and an optionaluserInfodictionary. Exceptions can be thrown with the@throwndirective, or sending theraisemessage to any instance ofNSException.Uncaught exceptions terminate the application, and this is perfectly fine. You can also catch them, but just to gather more information, and terminate the program yourself. Remember, in Objective-C exceptions are not about trying to keep the app running, but to discover what’s wrong. For those with experience with Java, or Python, the blocks are pretty standard:
@try { // Trying to avoid dragons? Perform the dangerous trick here } @catch { // You found the dragons. Try to get the as much information as possible, and kill the app. } @finally { // This is going to be executed, whether if the exception is thrown or not. }(the title is borrowed from a wonderful song from Bob Dylan)