A few more autolayout tips and tricks

1.  If you add an view to a container without specifying constraints to derive width/height  it will use the object's intrinsicContentSize.   This is nice if you want to maintain the aspect ratio of the view. 

2.  I have wasted many hours of my life that I'll never get back spent gobs of time attempting to mix IB Autolayout with programmatic constraints.  The problem is because IB automatically inserts its own constraints (thanks IB!) which then conflict with the ones that I'm trying to set (See #3 below).

Several StackOverflow posts recommend checking off the "Remove at build time" flag for constraints that should be set or adjusted programmatically.  That will work, but it means I'll always have to programmatically add that constraint - but sometimes the default IB constraint is fine until something else in the layout changes (e.g., a view is added or removed)

In that situation, just set the priority of the constraint in IB to "High" (vs "Required").  That way, if you add a constraint that conflicts with the default IB constraint, you won't get bad layouts or error messages.

3. Programmatically removing all of the IB built-in constraints for a given view seems to be beyond my technical abilities.  In some situations, no matter what I do, I just can't seem to get rid of those @#!$&$! default IB constraints.  See #2.

4. You can add the same constraint numerous times without error.  I'll leave it up to you to decide if that's a good thing

5. And so I don't forget,  here's how to position two views at 25% and 75% of parent width with programmatic constraints:

   [buttonPanel addConstraint:[NSLayoutConstraint constraintWithItem:button1 attribute:NSLayoutAttributeCenterX relatedBy:NSLayoutRelationEqual toItem:buttonPanel attribute:NSLayoutAttributeCenterX multiplier:.5 constant:0]];

   [buttonPanel addConstraint:[NSLayoutConstraint constraintWithItem:button2 attribute:NSLayoutAttributeCenterX relatedBy:NSLayoutRelationEqual toItem:buttonPanel attribute:NSLayoutAttributeCenterX multiplier:1.5 constant:0]];

Venting on the iOS8 iTunesConnect

I've had a few app updates in the queue for about 10 days now.  I put them in before the big itunesconnect UI change.  One of them was finally reviewed but rejected yesterday for crashing after startup.  Naturally, I can't reproduce the error but with the given crash logs I tweaked some code and resubmitted.

Then I went into iTunesConnect and could not find my binary.  Ah, wait - it's here under "Prereleases".  It says that it is "processing".  It's already been validated.  "Processing"?   What can it possibly be doing?  Theories abound:

1. Each byte is meticulously separated and dropped into a "bit bucket" which then tips over and causes a matchbox car to go down a ramp, triggering a fan, which expands a small red balloon, thus delighting the children of Apple employees.
2. The binary is transmitted to CIA for insertion of  top secret code which turns my flashcard app into a Morse code messenger for international spies.
3. It's standing in the TSA line at Denver International Airport.

After some quick Goog research I find out that we have to wait for the "processing" step to finish before we can do anything else.

So, six hours later, the sprinkled unicorn dust finally settles on the build and it is done "processing".    Unfortunately, this occurs at 2AM, and like all good developers, I'm in bed, dreaming of a better world where these fancy, newfangled computer thingies are smart enough to sheperd a binary through the process all by itself.

In the "Prereleases" list, my newly blessed magical "processed" binary shows a little   !  in a box with no explanation.   Clicking/Hovering over it makes no difference.     Is it tired? Unhappy?

I add the binary to the app record, and go to subm -  ah, no.  Requires a "Save" first, then I can resubmit.   Because, you know, I might want to add a build and then get a sandwich before attempting that last, exhausting, tap-the-submit-button step.

I have three other apps "Waiting For Review" that are not even showing up in the app list as that status.   Another one that says it's "Waiting For Review" but it was actually approved before the UI change.    Yay! There are no rules!  Pick your own status!

UIWebView issue with links only being called once.

We use UIWebView's pretty heavily in our apps.  Sometimes we use links in a page to invoke other behaviors, like pushing another UIViewController on to the navigation stack.

We noticed recently that, on an iPad, clicking such a link, popping the navigation stack, then trying to click the link again did not work.

With some investigation, it seems that the delegate method shouldStartLoadWithRequest was only being called the first time.  If another link on that same page was clicked, it would work fine; the problem only occurred when the same link was attempted two or more times consecutively.

It seems the issue is that, even if you return NO from shouldStartLoadWithRequest, UIWebView believes that the requested link is the currently viewed page - thus, clicking the link again takes no action since UIWebView thinks that it's already there.

To fix this, I found the following StackOverflow link - it describes a similar problem.  The workaround to fix the issue is to fool UIWebView into believing that it is somewhere else by using javascript to change its location.

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { 


    NSString *surl = [[request URL] absoluteString]; 

    NSRange r = [surl rangeOfString:@"#MYACTIONLINK"]; 
    if (r.location != NSNotFound){ 

    // do my custom action
        [[NSNotificationCenter defaultCenter] postNotificationName:NotifyHTMLViewerSelectedLink object:nil userInfo:nil]; 

        [webView stringByEvaluatingJavaScriptFromString:@"window.location='#__DUMMY_ANCHOR'"]; 
    
        return NO; 

    } 

    if ([surl hasSuffix:@"_DUMMY_ANCHOR"]) 
        return NO; 

....

Percentage based layouts using (mostly) Xcode IB and Autolayout

The Xcode lnterface Builder (IB) doesn't provide a clear way to handle a percentage based layout - for example, a screen where one view takes up 25% of the width of the screen, and the other view gets the rest.

---------------------------------------------------
|                    |                                              |
|                    |                                              |
|                    |                                              |
|        A         |                       B                     |
|                    |                                              |
|                    |                                              |
|                    |                                              |
---------------------------------------------------

Here's one way to use IB for all but a few lines of code.  (based on ideas from this stackoverflow post.)

For "view B", using Xcode IB, I put constraints on the top, right, bottom, and left
For "view A", using Xcode IB, I put constraints on the top, left, bottom, and then set the width to a fixed size.  I edited the width constraint of "view A", and checked the "placeholder remove at build time" checkbox.

then, in the view controller's viewDidLoad, I added these two lines:


    NSLayoutConstraint *c = [NSLayoutConstraint constraintWithItem:viewA
                           attribute:NSLayoutAttributeWidth
                           relatedBy:NSLayoutRelationEqual
                            toItem:viewA.superview
                            attribute:NSLayoutAttributeWidth
                            multiplier:.25
                            constant:(CGFloat)0];
   

    [viewA.superview addConstraint:c];


This just makes viewA 25% of the size of it's superview.  Since viewB is tied to viewA's width, it also adjusts properly without having to specify extra constraints for it.

iOS 7.1 issues

x. Noticed that the tab bars don't work quite the same way.  I have an .xib that I use for both iPad and iPhone layouts.  With 7.1, the tab bar now appears to be larger on the iPad (56 pixels) but the .xib doesn't auto adjust the 'y' for the former size (which was 49 pixels).  What this does is make the tab bar looked clipped at the bottom on the iPad. 

The fix requires using autolayout to set up the tab bar.  Then it works for 7.1 and prior versions.   An alternative fix is checking the tab bar's y value in the view controller's viewWillLayoutSubviews method to make sure it is equal to viewController.view.frame.size.height - tabBar.frame.size.height;

x. In previous versions, setting the corner radius and border on a layer would implicitly mask that layer to the corner arcs.  This is no longer the case in 7.1.  Now, if you set the background color of a UIView, and then set the corner radius and a border, the border will show the corner arcs, but the background color will extend to the square corners.


x. Not sure if this is a 7.1 only, issue but noted that an application that used to work okay is now getting a weird autolayout error on the iPad when dismissing a modal view.  There's tons of unhelpful error diagnostics and it ends with:
 
Cannot find an outgoing row head for incoming head UILabel:0x1462c580.Width{id: 414}, which should never happen.'

I saw a few mentions of this error on the web but no real help.  I was able to avoid the error by changing the constraints on one of the ViewControllers' UILabels.  Originally the UILabel was constrained to top right left with a fixed height.  It works if set to top width height centered x.     I doubt that this is the "real" solution, but I wasn't able to find anything else that seemed to be the issue.   (Ugh. There's three hours of my life I'll never get back).

Update: Ran into this error again and burned another six or so hours.  It seems related to percentage based views in autolayouts but I haven't been able to narrow it down much further than that.

PERL Matching non-ASCII characters in a converted RTF

I have a data file that was converted from an RTF to a TXT.    When I started trying to parse it using PERL, my regular expressions weren't able to split up lines that looked like they had whitespace delimiters - It would just ignore the whitespace.

After my initial confusion, I figured that the whitespace must be something other than an ASCII space character, tab, etc.   By some experimentation, I noticed that there were several bytes being represented in that "whitespace".

To try and figure out what the bytes/characters were, I created a little PERL code segment that looked like:

while ($filecontents =~ /([^\d\w\s\t\.:;&\,\-\(\)]+)/){
    $f = $1;
    $d = $1;
   
    $f  =~ s/(.)/sprintf("%x ",ord($1))/eg;
    print "f is $f\n";
    $filecontents =~ s/$d/zzz/g;

}

Basically, the code goes thru the file, finds oddball characters and prints them out.  When I ran it, it produced the following:

   f is e2 80 83
   f is e2 80 a8
   f is e2 81 84
   f is c2 b0 
 
Note that each of those looks like a multi-byte character, but what are they?

Well, I do love the internet.  I cut and pasted e2 80 a8  into Google and found that it was an "em space", aka Unicode character \u2003.

Once I was able to get the Unicode character, I could just replace all of the em spaces with a regular space, and the rest of my program worked as designed.  Same idea with the other special characters.  Two of those characters were not whitespace, but were non-ASCII characters as well (fraction slash and degree symbol).

Note that, at least in my case, I had to match using the hex versus the unicode character. In other words

    $filecontents =~ s/\xe2\x80\xa8/ /g;

I'm assuming this is because the Unicode would be a UTF-16 character but I'm dealing with a UTF-8 encoding?   For next time, I should see if I can export the RTF to a UTF-16 text file.  Maybe it would be easier :)

UIWebView, URL history, and redirects

Sometimes it seems the simplest things turn out to be much more complicated than they should be.

In several of our apps, we include help files written in HTML which are loaded locally from the bundle into a UIWebView.  Sometimes those help files contain links to web pages.

The problem is that UIWebView doesn't treat locally loaded webpages as part of the history stack.  Thus if the user clicks a link and visits a web page, there is no simple way for the app to return to the original locally loaded HTML file because [webview canGoBack] returns NO.  Grr.

My first attempt to deal with the issue was to just reload the local file if [webview canGoBack] was NO.  However, if the same locally loaded HTML file contains two web pages, and the user visits each, after the attempt to return from the 2nd webpage,  [webview canGoBack] will return YES and [webview goBack] will display the first webpage, because the first webpage was never removed from the UIWebView's history, and there's apparently no way (that I was able to find) to get rid of it.  Grrr.

The next step was to try and maintain my own count of visited URL's and back out of them as the user clicked the back button.   I implemented this by adding to the count in the UIWebView delegate method shouldStartWithRequest when the navigationType was UIWebViewNavigationTypeLinkClicked and removed them with each click of the back button.  Great!  Except that redirects also load with a navigationType of UIWebViewNavigationTypeLinkClicked so the user would have to click "back" several times for no clear reason because the link count was incremented for each redirect.  Grrrr.

I was able to finally make it work with some insight from this tutorial.  The key I learned was that  the webViewDidFinishLoad delegate method is not called until the redirects have been resolved. (But it may call the method several times as it loads the contents of the page).

Below are the key elements of the code:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
   
    // we use the linkClicked boolean because with redirects, this method is still called multiple times and we only want
    // to increment once.
    if (linkClicked == NO && navigationType == UIWebViewNavigationTypeLinkClicked){
        linkClicked = YES;

        if (linkStack == 0){
            scrollOffset = webView.scrollView.contentOffset;
        }
        linkStack++;
    }
   
    return YES;
}
- (void)webViewDidFinishLoad:(UIWebView *)webView
{
    if (linkStack == 0 && scrollOffset.y > 0){
        // reset the scroll if we are coming back to a page after a clicked link.
        [wv.scrollView setContentOffset:scrollOffset];
        scrollOffset = CGPointMake(0, 0);
    }
   
    NSURLRequest* request = [webView request];
    if ([[request mainDocumentURL] isEqual:lastMainDoc])
        return;
   
    linkClicked = NO;
    [self setLastMainDoc:[request mainDocumentURL]];
   
    NSLog(@"finished loading %@", [[request mainDocumentURL] absoluteString]);
   
}

-(void)doBack:(id)sender
{
   
    if (linkStack > 0){
        if (linkStack == 1 || [wv canGoBack] == NO){
            [self loadFile];

        } else {
            linkStack--;
            [wv goBack];
        }
        return;
       
    }
}


- (void)loadFile
{
    // load local HTML file
    //....
}


I'm sure there are a few other ways to address this problem, but this is what worked for me....