There is nothing great about the code. Just thought it would be a nice thing to share.

-(NSString*) HebrewStringForInt:(int) number{
    if (number ==15) {
        return @"טו";
    }
    if (number==16) {
        return @"טז";
    }

    NSMutableString* toReturn=[NSMutableString string];
    while (number > 400) {
        number-=400;
        [toReturn appendString:@"ת"];
    }

    if (number >= 300) {
        [toReturn appendString:@"ש"];
        number-=300;
    }else if (number >= 200) {
        [toReturn appendString:@"ר"];
        number-=200;
    }else if (number >= 100) {
        [toReturn appendString:@"ק"];
        number-=100;
    }

    if (number >= 90) {
        [toReturn appendString:@"צ"];
    }else if (number >= 80) {
        [toReturn appendString:@"פ"];
    }else if (number >= 70) {
        [toReturn appendString:@"ע"];
    }else if (number >= 60) {
        [toReturn appendString:@"ס"];
    }else if (number >= 50) {
        [toReturn appendString:@"נ"];
    }else if (number >= 40) {
        [toReturn appendString:@"מ"];
    }else if (number >= 30) {
        [toReturn appendString:@"ל"];
    }else if (number >= 20) {
        [toReturn appendString:@"כ"];
    }else if (number >= 10) {
        [toReturn appendString:@"י"];
    }

    if (number %10 ==9) {
        [toReturn appendString:@"ט"];
    }else if (number %10 ==8) {
        [toReturn appendString:@"ח"];
    }else if (number %10 ==7) {
        [toReturn appendString:@"ז"];
    }else if (number %10 ==6) {
        [toReturn appendString:@"ו"];
    }else if (number %10 ==5) {
        [toReturn appendString:@"ה"];
    }else if (number %10 ==4) {
        [toReturn appendString:@"ד"];
    }else if (number %10 ==3) {
        [toReturn appendString:@"ג"];
    }else if (number %10 ==2) {
        [toReturn appendString:@"ב"];
    }else if (number %10 ==1) {
        [toReturn appendString:@"א"];
    }

    return toReturn;
}

If you are using this for Hebrew Years keep in mind that the millennium is usually omitted and that some years have special rules which rearrange the the letters. For example the year 742 should be ‫תשמ״ד‬ but that would spell a word that means "you will be destroyed", so instead the custom is to mix around the letters and write ‫תשד״מ‬.

Also keep in mind that the Hebrew numeral number system starts to look weird after 800 (with two ת's at the beginning of the number), and is completely worthless for large numbers.

Something that bothered me is that Apple did not mark the bugs as resolved and did not update the change logs to indicate that there were any changes. So you are just going to have to take my word for it that these mistakes where there.
Spelling mistake in SKRequestDelegate documentation
In the SKRequestDelegate documentation the header for the section 'Handling Errors' read 'Handling Errrors', with the extra 'r'. It was a bit ironic.

Mistaking an enumerated type for a BOOL
UITableView has a bunch of functions for modifying the tableview, such as adding, removing and reloading cell. For all of these there is an enumerated type of what kind of animation you want to you (fade, push from left, push form top etc). In the UITableview documentation for - (void)deleteSections:(NSIndexSet *)sections withRowAnimation:(UITableViewRowAnimation)animation
it did state that the row animation was a BOOL not an enumerated type. This was already pointed out on stackoverflow (here) in June 2011, but it wasn't fit until Feb 2012 after I submitted the bug report.

iOS documentation confuses a path for a URL
I know that I am being really pedantic, but this one bothered me a little. I (like most iOS developers) has some trouble at first with the difference between a path (a kind of NSString) and a url (and kind of NSURL). So when the documentation confuses them it can be really tough for a new programmer. In NSFileManager there are two very similar functions:
- (BOOL)removeItemAtPath:(NSString *)path error:(NSError **)error
and
- (BOOL)removeItemAtURL:(NSURL *)URL error:(NSError **)error
for the path one it used to state:
"Return value: YES if the item was removed successfully or if URL was nil." - which is confusing since there is no URL there is only a path. Seems like it was a copy-paste mistake. Thankfully they fixed it, and they even added italics to the words 'URL' and 'path'.

Misnamed variable in Programming Guide
In the a href="https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_pdf_scan/dq_pdf_scan.html">programing guid to PDF there is some sample code called "Open the PDF Document". This is the code that Apple posted

CGPDFDocumentRef myDocument;
myDocument = CGPDFDocumentCreateWithURL(url);// 1
if (myDocument == NULL) {// 2
        error ("can't open `%s'.", filename);
        CFRelease (url);
        return EXIT_FAILURE;
}
CFRelease (url);
if (CGPDFDocumentIsEncrypted (myDocument)) {// 3
    if (!CGPDFDocumentUnlockWithPassword (myDocument, "")) {
        printf ("Enter password: ");
        fflush (stdout);
        password = fgets(buffer, sizeof(buffer), stdin);
        if (password != NULL) {
            buffer[strlen(buffer) - 1] = '';
            if (!CGPDFDocumentUnlockWithPassword (myDocument, password))
                error("invalid password.");
        }
    }
}
if (!CGPDFDocumentIsUnlocked (myDocument)) {// 4
        error("can't unlock `%s'.", filename);
        CGPDFDocumentRelease(myDocument);
        return EXIT_FAILURE;
    }
}
 if (CGPDFDocumentGetNumberOfPages(document) == 0) {// 5
        CGPDFDocumentRelease(document);
        return EXIT_FAILURE;
}

Did you catch it?. The last check uses of the variable "document" when the rest of the code used "mydocument". This is the only one of the four which is still now fixed.

The lesson here is that Apple bug reporter works, but don't expect any feedback or a thank you, or even a notice in the change log.

1. Download the Facebook SDK for Android. It can be downloaded easily from the Facebook developers website.
2. Get a hash key from the Android keytool. The command I found around the net is:

   	keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64
   

3. Create an app on Facebook.
4. Add the hash key to your app (you have to choose “native android app” below “select how your app integrates with Facebook").
5. In Your project, add the external Jar file for the facebook SDK. The way to do this is to follow these simple steps:
   1. Right click on the project in eclipse.
   2. Choose “properties” (command+i).
   3. Choose the java build path.
   4. Add external jar.
   5. Choose the Facebook sdk jar from the /%facebook-sdk-folder%/facebook/bin/com_facebook_android.jar.
6. In your code, add an import to the facebook sdk.

   import com.facebook.andriod.Facebook;
   

7. The next thing to do, is to create a new instance of the Facebook object.

   Facebook facebook = new Facebook(“your-app-id”);
   

   this will create an instance of a Facebook object that’s linked to your app.

8. The next thing to do is to sign in with Facebook’s SSO (Single Sign-On). the way to do this, is with the function authorise, you need to call it with the calling activity, the permissions requested and a FacebookDialogListener that has to be implemented.
9. The facebookDialogListener implements 4 functions.
   • onCancel (handles clicking the back button or the x button on the login popup).
   • onError (handles java-side errors and network errors).
   • onFacebookError (handles errors received from the server-side).
   • onComplete

   the overriding of onComplete is what to do when you get back the access token from the server side.
   the way to get the session key is:

   public void onComplete(Bundle values){
   	String token = values.getString(Facebook.TOKEN);
   	//DO SOMETHING
   }
   

   every time you need to interact with the facebook servers you need to send the token with the request.

10. The main problem with SSO is that you are probably already signed in with your facebook app and therefore the authorize function doesn’t return a new token, instead you need to get the token from the existing sign-on.
    to get that value, you’ll need to override the onActivityResult function and call the authorizeCallback function. the code for this is:

    @Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    	super.onActivityResult(requestCode, resultCode, data);
    	facebook.authorizeCallback(requestCode, resultCode, data);
    }
    

    ---

    Now you are all ready to go with using the Facebook Graph API. Here is a code sample for posting on a Facebook wall.

    import java.io.FileNotFoundException;
    import java.io.IOException;
    import java.net.MalformedURLException;
    
    import android.app.Activity;
    import android.content.Intent;
    import android.os.Bundle;
    import android.text.Html;
    import android.text.method.LinkMovementMethod;
    import android.util.Log;
    import android.view.Menu;
    import android.view.MenuInflater;
    import android.view.MenuItem;
    import android.widget.TextView;
    import android.widget.Toast;
    
    import com.facebook.android.DialogError;
    import com.facebook.android.Facebook;
    import com.facebook.android.Facebook.DialogListener;
    import com.facebook.android.FacebookError;
    
    public class Main extends Activity{
    Facebook facebook;
    String permissions[] = {“publish_stream”};
    
    @Override
    public void onCreate(Bundle savedInstanceState){
    	super.onCreate(savedInstanceState);
    	facebook.authorize(Main.this, permissions, new DialogListener(){
    		public void onComplete(Bundle values){
    			updateStatus(values.getString(Facebook.TOKEN));
    		}
    
    		public void onFacebookError(FacebookError e){
    		}
    
    		public void onError(DialogError e){
    		}
    
    		public void onCancel(){
    		}
    	});
    	public void updateStatus(String accessToken){
    		try{
    			Bundle msg = new Bundle();
    			msg.putByteArray(“message”, “this is a sample message”.getBytes());
    			msg.putByteArray(Facebook.TOKEN, accessToken.getBytes());
    			String response = facebook.request(“me/feed”, msg, “POST”);
    		} catch (FileNotFoundException e) {
    			e.printStackTrace();
    		} catch (MalformedURLException e) {
    			e.printStackTrace();
    		} catch (IOException e) {
    			e.printStackTrace();
    		}
    	}
    	@Override
    	protected void onActivityResult(int requestCode, int resultCode, Intent data){
    		super.onActivityResult(requestCode, resultCode, data);
    		facebook.authorizeCallback(requestCode, resultCode, data);
    	}
    }
    

    ]]> http://www.appstudio.co.il/blog/android-developer-tips/ten-steps-to-get-started-with-facebook-on-andriod/feed 0 http://www.appstudio.co.il/blog/ios-developer-tips/nscalendar-week-calculations http://www.appstudio.co.il/blog/ios-developer-tips/nscalendar-week-calculations#comments Tue, 13 Mar 2012 15:05:04 +0000 rose http://www.appstudio.co.il/?p=2642 A former colleague of mine (who we are still on good terms with) recently asked me a NSDate related question:

    I'm struggling with a problem that should be simple.

    The problem is how do I get the NSDate that represents "nearest Sunday at 00:00:00" (for example, in the Gregorian calendar).

    So this is what I had in mind:

    1. Create NSDateComponents from [NSDate date] against the gregorian calendar. Ask only for the year, the serial number of the week and the time.
    2. Change the weekday of this date components to "1" and the time to 00:00:00.
    3. Translate back to NSDate against the same calendar.

    What's my problem:
    What if this sunday is not in the same year? For example, if we are in the first week of the year, and the year started in Monday, what will I get if I'll ask for the "Sunday of week 1"?
    Error? the right date? undefined?

    This is a great question: How do years interact with weeks? While months and days never overlap two different years*, a week can start in on year and end in another! This brings us to the often overlooked NSDateComponent: NSYearForWeekOfYearCalendarUnit.

    The YearForWeekOfYear has the property that it can start (or end) a little before or after the regular year, but will ensure that weeks do not straddle any year. How these "years" are exactly broken up is decided by two properties of NSCalendar: firstWeekday and minimumDaysInFirstWeek.

    Now that were have a year system that guarantees that week will all be in the same year we can easily find the last Sunday:

    -(NSDate*) LastSundayBeforeDate:(NSDate*) date{
        NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar] ;
        NSUInteger unitFlags =NSWeekdayCalendarUnit | NSWeekOfYearCalendarUnit | NSYearForWeekOfYearCalendarUnit;
        NSDateComponents * components =[gregorian components:unitFlags fromDate:date];
        //1 is sunday in a gregorian calendar
        components.weekday=1;
        return [gregorian dateFromComponents: components];
    }
    

    Just like we can represent a date with {year-month-day}, we can also represent a date as {year-week-weekday} - as long as we remember that this is special kind of "year" where weeks are on only in one year. All we are doing is saying that for any date find the {year-week-weekday} then give me the date for {year-week-1}. This would be a very similar process if I wanted to find the date (NSDate) of the first day of a month that another date falls in.

    Now to get next Sunday we would just need to add a week:

    -(NSDate*) weekAfterDate:(NSDate*) date{
        NSDateComponents* oneWeekInterval=[[NSDateComponents alloc] init];
        oneWeekInterval.week=1;
        NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar] ;
        return [gregorian dateByAddingComponents:oneWeekInterval toDate:date options:0];
    }
    

    Finally the function for next Sunday is just a week after last Sunday.

    -(NSDate*) nextSunday:(NSDate*) date{
        return [self weekAfterDate: [self LastSundayBeforeDate:date]];
    }
    

    In the code above I am creating two different NSCalendars without any "real" benefit. Some would argue that the code should be refactored to be a single function. I disagree. Code clarity is more important than efficiency especially with objects that are already very fast.

    In any event if you are calling this function over and over again, cutting the amount of NSCalendars in half is not the right answer. You should create an instance variable for the Gregorian Calendar and reuse it many many times.

    There is one more thing to note. I said above that weeks can change years, unlike months which do not straddle years. This is not completely tree. The Japanese Calendar numbers the years from the start of the emperor’s reign. They normally change on December 31, but can change at any time of the year if the emperor dies.
    ■ 31 December, Showa 63
    ■ 1 January, Showa 64
    ■ …
    ■ 7 January, Showa 64
    ■ 8 January, Heisei 1

    ]]> http://www.appstudio.co.il/blog/ios-developer-tips/nscalendar-week-calculations/feed 0 http://www.appstudio.co.il/blog/ios-developer-tips/uigesturerecognizer-cancelled-state http://www.appstudio.co.il/blog/ios-developer-tips/uigesturerecognizer-cancelled-state#comments Sat, 03 Mar 2012 12:58:14 +0000 rose http://www.appstudio.co.il/?p=2532 UIGestureRecognizers were a great improvement to iOS starting in version 3.2. For those of you who had to deal with the touchesBegan: and touchesMoved: method of UIResponder you need no explanation. For the noobs out there, they provide a common interface for standard touch events and give a simple API to access what it means. For rotations that means that complex trigonometry of rotation calculations are done for you and all you have to do is call

        [rotationRecongizer rotation];
    

    to get the rotation begin performed on the UIView and you can easy append it to the transform.

    Something that may confuse people is the many states that a recognizer can be in:

    typedef enum {
        UIGestureRecognizerStatePossible,   // the recognizer has not yet recognized its gesture, but may be evaluating touch events. this is the default state
    
        UIGestureRecognizerStateBegan,      // the recognizer has received touches recognized as the gesture. the action method will be called at the next turn of the run loop
        UIGestureRecognizerStateChanged,    // the recognizer has received touches recognized as a change to the gesture. the action method will be called at the next turn of the run loop
        UIGestureRecognizerStateEnded,      // the recognizer has received touches recognized as the end of the gesture. the action method will be called at the next turn of the run loop and the recognizer will be reset to UIGestureRecognizerStatePossible
        UIGestureRecognizerStateCancelled,  // the recognizer has received touches resulting in the cancellation of the gesture. the action method will be called at the next turn of the run loop. the recognizer will be reset to UIGestureRecognizerStatePossible
    
        UIGestureRecognizerStateFailed,     // the recognizer has received a touch sequence that can not be recognized as the gesture. the action method will not be called and the recognizer will be reset to UIGestureRecognizerStatePossible
    
        // Discrete Gestures – gesture recognizers that recognize a discrete event but do not report changes (for example, a tap) do not transition through the Began and Changed states and can not fail or be cancelled
        UIGestureRecognizerStateRecognized = UIGestureRecognizerStateEnded // the recognizer has received touches recognized as the gesture. the action method will be called at the next turn of the run loop and the recognizer will be reset to UIGestureRecognizerStatePossible
    } UIGestureRecognizerState;
    

    UIGestureRecognizerStatePossible and UIGestureRecognizerStateFailed are rarely relevant since they do not call the action method. UIGestureRecognizerStateRecognized is also rarely relevant since it is only for discreet touch events, such as a tap.

    In general the action method for the gestureRecognizer will test the recognizer's state and have different code for UIGestureRecognizerStateBegan, UIGestureRecognizerStateChanged and UIGestureRecognizerStateEnded. UIGestureRecognizerStateCancelled is often ignored - it shouldn't be.

    Many people are confused what that cancelled state is, or why it would ever be used. The cancelled state is rarely seen, but if a gesture is cancelled it may leave the UIView in an undesirable state. My rule is to run the same code for the Cancelled State as I do for Ended State.

    Let me give you an example of what I mean. Take a look at the Facebook app - this will work on either the iPhone or the iPad version, but you need iOS 5. The main view of the Facebook app can be panned to the right to reveal a menu below it. Start your finger close the top center of the screen and start dragging right. Now move you finger up to the status and pull down - as if you are trying to pull down the iOS notifications. If you did it right (it takes a little practice) you now have the Facebook sidebar half revealed and half hidden. (You can also start with the menu revealed and start panning left, then move you finger up and pull down).

    When you start moving your finger it trigger the UIPanGestureRecognizer to start moving the UIView. But after you start moving down near the status bar iOS says "oops I was wrong" and cancels the GestureRecognizers using those touches.

    I don't need to see Facebook's code to know that they failed to implement the same code for UIGestureRecognizerStateCancelled as they did for UIGestureRecognizerStateEnded. In truth, Facebook should implement different code for the Cancelled State to return the UIView to where it started regardless of how it has been moved by the gesture, but that is a lot to ask for a case which is so rare. Leaving the view half open and half close though is much worse, especially considering how easy it is to fix.

    So don't make the same mistake as Facebook, go through all your code and replace

    	if (UIGestureRecognizerStateEnded == [recognizer state])
    

    with

    	if (UIGestureRecognizerStateCancelled ==[recognizer state] || UIGestureRecognizerStateEnded == [recognizer state])
    

    ]]> http://www.appstudio.co.il/blog/ios-developer-tips/uigesturerecognizer-cancelled-state/feed 0 http://www.appstudio.co.il/portfolio/apps/hands-on-equations http://www.appstudio.co.il/portfolio/apps/hands-on-equations#comments Thu, 01 Mar 2012 10:49:38 +0000 cnotethegr8 http://www.appstudio.co.il/?p=2427 Hands-On Equations is the ideal first introduction to algebra for elementary and middle school students. Not only will these students have fun and be fascinated with the program, their sense of self-esteem will be dramatically enhanced as they experience success with sophisticated looking algebraic equations.
    ]]> http://www.appstudio.co.il/portfolio/apps/hands-on-equations/feed 0 http://www.appstudio.co.il/blog/ios-developer-tips/translate-a-uiview-without-creating-a-new-xib-file http://www.appstudio.co.il/blog/ios-developer-tips/translate-a-uiview-without-creating-a-new-xib-file#comments Thu, 01 Mar 2012 09:53:43 +0000 rose http://www.appstudio.co.il/?p=2553 When dealing with multiple languages Apple recommends creating a different XIB file for each language, and a strings file for the NSStrings embedded in your code. While creating a new XIB gives you the most flexibility, it is also a big pain. If you have 3 languages it is three times the amount of work when updating a XIB file. And it is also a huge amount of work to add a new language. It also creates two different translations job: one in the strings file which can be done by a professional translator and another in the XIB file which requires a programmer.

    Sometime you have view with very few strings that need to be localized. This can happen if your main view is a UITableView and most of your string are returned programmatically through a UITableViewDataSource. In this case it is easier to make an outlet to the few views that you need localized and localize them programmatically.

        self.myLabelThatNeedsToBeLocalized.text=NSLocalizedString(myLabelThatNeedsToBeLocalized.text, @"translation for myLabelThatNeedsToBeLocalized");
    

    The problem with is method is that it gets real tiresome real fast as you have more and more UIViews to translate. My solution is a UIView category that will translate a UIView and all of its subviews:

    UIView+APPStudioIsraelLocalizeView.h

    #import 
    
    @interface UIView (APPStudioIsraelLocalizeView)
    -(void) Localize;
    @end
    

    UIView+APPStudioIsraelLocalizeView.m:

    
    #import "UIView+APPStudioIsraelLocalizeView.h"
    
    @implementation UIView (APPStudioIsraelLocalizeView)
    -(void) Localize{
        NSMutableSet* SetToTranslate=[NSMutableSet setWithObject:self];
    
        while ([SetToTranslate count] >0) {
            UIView* toTranslate=[SetToTranslate anyObject];
    
            if ([toTranslate isKindOfClass:[UILabel class]]) {
                ((UILabel*) toTranslate).text=NSLocalizedString(((UILabel*) toTranslate).text, nil);
            }else if ([toTranslate isKindOfClass:[UIButton class]]) {
                for (UIControlState state=0; state <16; state++) {
                    [((UIButton*) toTranslate) setTitle:NSLocalizedString([((UIButton*) toTranslate) titleForState:state],nil) forState:state];
                }
            }else if ([toTranslate isKindOfClass:[UISegmentedControl class]]) {
                int numberOfSegments=[((UISegmentedControl*) toTranslate) numberOfSegments];
                for (int segment=0; segment < numberOfSegments; segment++) {
                    [((UISegmentedControl*) toTranslate) setTitle:NSLocalizedString( [((UISegmentedControl*) toTranslate)  titleForSegmentAtIndex:segment], nil) forSegmentAtIndex:segment];
                }
            }else if ([toTranslate isKindOfClass:[UITextField class]]){
                ((UITextField*) toTranslate).placeholder=NSLocalizedString(((UITextField*) toTranslate).placeholder, nil);
            }else if ([toTranslate isKindOfClass:[UITextView class]]){
                ((UITextView*) toTranslate).text=NSLocalizedString(((UITextView*) toTranslate).text, nil);
            }else if([toTranslate isKindOfClass:[UINavigationBar class]]){
                ((UINavigationBar*) toTranslate).topItem.title=NSLocalizedString(((UINavigationBar*) toTranslate).topItem.title,nil);
            }else if([toTranslate isKindOfClass:[UIToolbar class]]){
                for (UIBarButtonItem* item in ((UIToolbar*)toTranslate).items) {
                    item.title=NSLocalizedString(item.title, @"");
                    if  (item.customView){
                        [SetToTranslate addObject:item.customView];
                    }
                }
            }else if ([toTranslate isKindOfClass:[UIDatePicker class]]){
                //don't look at subviews
            }else  if([toTranslate isKindOfClass:[UIPickerView class]]){
                //Don't look at subviews
            }else{  //Otherwise it might have subview worth looking at
                for (UIView* view in toTranslate.subviews) {
                    [SetToTranslate addObject:view];
                }
            }
    
            [SetToTranslate removeObject:toTranslate];
        }
    }
    @end
    

    I use an iterative method instead of a recursive one because I find it easier to read, easier to debug, and less prone to problems. I try to avoid recursion because I think it make programmer try to be more cleaver than they are.

    The advantage of the above method is that it avoids creating a different XIB for each language, and is super easy to implement.

    -(void) viewDidLoad{
        [super viewDidLoad];
        [self.view Localize];
    }
    

    This will not translate view that are not inside the view hierarchy when the view loads - such as view that created programmatically or views that are outside of the main view in the XIB file. You would need to call Localized on those views individually, or when you create then set the text using NSLocalizedString.

    One thing to note is that this doesn't solve size problems. Some languages such as German take up much more space than English. You need to make sure your UILabels are big enough to handle the largest translations you are supporting. If you are dealing with languges with very different sizes, such as German and Chineses you are probally better off creating different XIB files. Otherwise you will have a lot of empty space in the small language and be very cramped in the large one.

    Also you should note that there is no way to automatically find the strings using genstrings. So you need to be meticulous in adding string to the Localizable.strings file every time you add a new string.

    Overall I find that this is a good alternative to multiple xib files especially if you plan the layout of your UI to expect to have different sized strings.

    The code is free to use under the terms of the "Simplified BSD License"

    ]]> http://www.appstudio.co.il/blog/ios-developer-tips/translate-a-uiview-without-creating-a-new-xib-file/feed 0 http://www.appstudio.co.il/blog/ios-developer-tips/the-limits-of-nscalendarcomponents http://www.appstudio.co.il/blog/ios-developer-tips/the-limits-of-nscalendarcomponents#comments Tue, 21 Feb 2012 13:14:45 +0000 rose http://www.appstudio.co.il/?p=2528 I recently stumbled across some code that was so bad I had to comment on it.

    //returns a Hebrew date from a Gregorian date
    - (NSDate*)convertHebrewDateWithDate:(NSDate*)date {
    ...
    

    When I saw this I was shocked! As you may already know an NSDate does not have any calendar information attached to it. It is a point in time. Internally it is a just a fancy wrapper for a count from January 1, 1970 2001 with a double precision floating point. So if you look at just the input and output of the function it makes no sense. You are inputing a NSDate (a point in time) and getting back another point in time.

    Even more, there is no meaning to the words "Hebrew date" or "Gregorian date" all NSDates are calendar independent!

    So what does the function actually do. Well nothing good, but lets take a look:

      NSCalendar* gergorianCalendar = [[[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar] autorelease];
      NSCalendar* hebrewCalendar = [[[NSCalendar alloc] initWithCalendarIdentifier:NSHebrewCalendar] autorelease];
    

    It start off good making calendars which is often a good start when dealing calendar conversions. But then it is all down hill:

    	NSUInteger dateUnits = NSDayCalendarUnit | NSMonthCalendarUnit | NSYearCalendarUnit;
    	NSDateComponents *dateComponents = [hebrewCalendar components:dateUnits fromDate:date];
    

    Then he creates a date Components from the Hebrew calendar. Something important to realize with NSDateComponents is that there is no context for what they mean. It is simply a collection of seconds, minutes, hours, days, weeks, months, and years. It could represent an amount of time - if for example they were created from NSCalendar's components:fromDate:toDate:options. Or they can represent numerical representations of calendar information as it does when it is created from NSCalendar's components:fromDate:. NSDateComponents does not reference the calendar it was created with to know what the information represents - that is up to the programmer. In the code above the components are a representation of a Hebrew Date. If, for example, you gave it a NSDate that was this year's Passover the components would be would be day=15, month=7 and year=5772.

    This next line make me cringe a little:

    	NSDate *hebrewDate = [gergorianCalendar dateFromComponents:dateComponents];
      return hebrewDate;
    }
    

    AHHHHH! You can't use Hebrew date components in a Gregorian calendar! This will create a date of July, 15, 5772 in the distant future (which by the way would be 18 Tammuz, 9532). It is completely meaningless!

    The lessen here is already stated in a big prominent box in the Apple's documentation of NSDateComponents:

    Important An NSDateComponents object is meaningless in itself; you need to know what calendar it is interpreted against, and you need to know whether the values are absolute values of the units, or quantities of the units.

    Frankly I am not sure why NSDateComponents is an object instead of just a struct. If it was a struct it would be a lot clearer that it is not meant to do anything beyond simply storing values, and we wouldn't be seeing mistakes like this.

    UPDATE: I also realized that the reverse conversion will not necessarily return you to the same date! In any Hebrew year where there isn't a leap year the 7th month is interpreted the same as a the 6th. So you could jump form July to Adar and then back to June.

    ]]> http://www.appstudio.co.il/blog/ios-developer-tips/the-limits-of-nscalendarcomponents/feed 0 http://www.appstudio.co.il/portfolio/apps/imegillah http://www.appstudio.co.il/portfolio/apps/imegillah#comments Mon, 20 Feb 2012 08:33:57 +0000 cnotethegr8 http://www.appstudio.co.il/?p=2651 Just tap the electronic scroll to open and let the iMegillah of Purim envelop you. This free app lets you comfortably read and follow along in Megillat Esther, Esther's Scroll. It includes an easy to read font along with vowels, and provides smooth scrolling for a more enjoyable iMegillah experience.
    ]]> http://www.appstudio.co.il/portfolio/apps/imegillah/feed 0