Scrolling a UIView to keep the keyboard from obstructing the view of the current UITextField

Henrik Carlsson posted this on 31 mar 16 and tagged it with iOS Narrating my work Objective-C UIKit

Wow, that’s an unwieldy title!

Anyway, during some spare time today I’ve struggled with something in Objective C and Cocoa Touch that I’ve been struggling with before. When a UITextField in an iOS app becomes ”active”, allowing the user to enter text, almost half of the screen gets covered by the software keyboard. That’s all well and good, but that keyboard is likely to obstruct the view of something, maybe even of the UITextField in question and that’s not good.

To avoid this problem, I the developer am supposed to move or resize (or something) the view. There are multiple questions about this on StackOverflow and multiple answers. After some digging and a lot of trial and error I came up with a solution that differed at least somewhat from all other solutions that I could find. As far as I can tell my solution works and it’s pretty short in terms of code, which I like.

I don’t know, maybe it’s a bad solution. If so, please let me know.

The solution

First, embed all the views that need to move inside a UIScrollView.

In my case I have multiple UITextFields that needs to move so I placed them all inside a UIScrollView. I then added the following property to my ViewController:

@property (strong, nonatomic) UITextField *activeTextField;

1 2	@property (strong, nonatomic) UITextField *activeTextField;

This property is updated on textFieldShouldBeginEditing like so:

- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField {
    self.activeTextField = textField;
    return true;
}

- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField {

self.activeTextField = textField;

return true;

}

Then , in my viewDidLoad I added the following two observers:

[ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidShow: ) name:UIKeyboardDidShowNotification object:nil ];
[ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidHide ) name:UIKeyboardDidHideNotification object:nil ];

[ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidShow: ) name:UIKeyboardDidShowNotification object:nil ];

[ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidHide ) name:UIKeyboardDidHideNotification object:nil ];

These will trigger the methods keyboardDidShow and keyboardDidHide when the keyboard appears and disappears respectively. It is in those methods that ”the magic” happens:

- (void)keyboardDidShow:( NSNotification *)notification {
    // Find out the frame of the keyboard
    NSDictionary *userInfo = [notification userInfo];
    CGRect keyboardFrame = [[userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];

    // Calculate how heigh of an available content area we have now by 
    // subtracting the keyboards height from the height of the main view.
    NSInteger heightOfAvailableContentArea = self.view.frame.size.height - keyboardFrame.size.height;

    // Make a point with a y that's the y of the activeTextField minus half
    // the height of the available content area and then scroll the 
    // UIScrollView to this position.
    CGPoint scrollPoint = CGPointMake( 0, self.activeTextField.frame.origin.y - heightOfAvailableContentArea / 2 );
    [ self.scrollView setContentOffset:scrollPoint animated:YES ];
}

- (void)keyboardDidHide {
    // Return the UIScrollView to 0 position.
    CGPoint scrollPoint = CGPointMake( 0, 0 );
    [ self.scrollView setContentOffset:scrollPoint animated:YES ];
}

- (void)keyboardDidShow:( NSNotification *)notification {

// Find out the frame of the keyboard

NSDictionary *userInfo = [notification userInfo];

CGRect keyboardFrame = [[userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];

// Calculate how heigh of an available content area we have now by

// subtracting the keyboards height from the height of the main view.

NSInteger heightOfAvailableContentArea = self.view.frame.size.height - keyboardFrame.size.height;

// Make a point with a y that's the y of the activeTextField minus half

// the height of the available content area and then scroll the

// UIScrollView to this position.

CGPoint scrollPoint = CGPointMake( 0, self.activeTextField.frame.origin.y - heightOfAvailableContentArea / 2 );

[ self.scrollView setContentOffset:scrollPoint animated:YES ];

}

- (void)keyboardDidHide {

// Return the UIScrollView to 0 position.

CGPoint scrollPoint = CGPointMake( 0, 0 );

[ self.scrollView setContentOffset:scrollPoint animated:YES ];

}

Coda

As I said, this works but it’s very possible that it’s a bad solution. If you like the solution, feel free to use it. If you think it’s bad, please tell me so and why so that I can learn and become a better programmer.

∞

iTunes U-kurs i iOS utveckling med Swift

Henrik Carlsson posted this on 27 jan 15 and tagged it with iOS iTunes U Programming

Stanford University har nu börjat publicera sin kurs Developing iOS 8 Apps with Swift i iTunes U.

I somras lärde jag mig Objective-C och iOS-utveckling genom att följa en äldre, liknande Stanford-kurs. Det var otroligt lärorikt och värdefullt så om du är intresserad av att lära dig att utveckla program för iOS-plattformen så ska du definitivt ta en titt på den här kursen.

Utan att själv ha provat Swift så skulle jag ändå rekommendera att du börjar med en äldre upplaga av kursen där Objective-C används. Detta eftersom det är ett mycket mera ”moget” programmeringsspråk. Konventionerna är mera etablerade och expertisen bättre.¹

Observera också att det här inte är en nybörjarkurs i programmering. Har du aldrig programmerat förr så bör du börja med något annat.

Paul Hegarty som höll de gamla Objective-C-kurserna verkar vara en gammal NeXT/Apple-programmerare som var med och tog fram Objective-C och Foundation/Cocoa, så han sitter på verklig experkunskap. ↩

∞

Market share on the one hand, developer revenue on the other

Henrik Carlsson posted this on 21 dec 11 and tagged it with Android iOS Links

the combined app store revenue for iOS devices is almost 6x that of Android Market.

This, combined with the fact that Google actually makes more money on iOS than on Android, is in my opinion the biggest threat against Android in the long run.

∞

The iPad as a travel companion, part 2

Henrik Carlsson posted this on 08 jul 11 and tagged it with Apple IMHO iOS

Last week I wrote a blog post about my upcoming trip to Warsaw with the band Hedningarna and the fact that I would use my iPad as my main digital entertainment during the trip, and as my only computer-like work device. The trip ended on Saturday last week but didn’t really turn out the way I thought. (I will likely write a separate post about the music-related part of the trip.)

The plane ride was over a lot faster than I thought, which meant I really didn’t get to use the iPad as much as I thought I would on the way there or on the way home. This in turn meant I didn’t spend as much time watching movies and video clips as I thought. However in Warsaw I used the iPad a lot, both for entertainment/infotainment and for business.

For the entertainment part I mainly used Instapaper. I always have a fairly long list of unread articles in it that I never seem to get around to in my everyday life. However on a trip abroad I’m usually unable to update the list (due to horrible data roaming fees) which in turn gives me the time to read ”old” news. The work-related stuff was mostly done with Evernote because of it’s great offline-functionality.

At the time of this writing (Tuesday around 7 pm) I’m once again traveling. This time I’m on a train from Falun to Gothenburg. Al though a much shorter distance then from Falun to Warsaw, the fact that the trip is made by train means a whole lot of time to use the iPad. So far I’ve used it for everyday stuff like checking twitter (Twitteriffic), checking my RSS-subscriptions (Reeder) and checking mail. I’ve also watched a movie (Vanilla Sky), looked at some video clips (from Webstock ’11), composed and sent an invoice (with Numbers) and now I’m blogging, so it’s safe to say that the iPad enables me to do a whole lot of things.

What’s really great is mainly the fact that I can use it for most of the stuff that I would normally use a laptop for, but with a whole lot less weight to carry around and a whole lot longer battery life. It’s super easy to simply pick it out of the bag, do one or two quick things and then put it away. The on screen keyboard is probably not something I would write a novel on, but it’s a lot easier to use than I imagined before buying the unit.

When I bought it I decided to go for the 32GB WiFi-only version, a decision that I’m now happy that I made. The 32GB was chosen to be able to store my entire iPhoto library on it (which is somewhere around 20-20GB in size) but that proved to be a real overkill since iTunes optimizes image sizes to match the resolution of the iPad. But the extra headroom proved very useful once I started to want to put multiple movies on it. Since syncing can be a pain in the ass, I’d prefer to do it as seldom as possible. (I can’t wait for iCloud!) The fact that it’s WiFi-only hasn’t been a problem at all since I always keep my iPhone with me and sharing Internet from it is really easy.

What’s less great is the highly reflective glass screen. Sure, glass I pretty and it does make it look really expensive, but the high reflectiveness of it makes watching movies in any sort of daylight really hard. Seeing my own reflection in everything can be quite distracting. (In contrast, when I watched a movie in a pitch black room last night the iPad was perfect.) The fact that glass is quite heavy is another thing that’s not so great. The iPad is not really heavy per se, but if it were even less heavy it would be even more great, especially for long form reading when I’m sitting with it in my hand.

And speaking of long form reading, that’s one thing that is really, really awesome on the iPad. Instapaper is such a great app and the fact that I can sit in much couch or chair (or airplane seat or train seat etc.) and read articles like I would read a magazine is simply amazing. For this train ride I’ve also bought my first Kindle book (Clear and Present Danger, by Tom Clancy) for the Kindle for iPad app. So far I have not had time to read anything in it so I guess I will revisit this topic with yet another blog post.

To be concluded…

∞

The iPad and iPhone as travel companions

Henrik Carlsson posted this on 30 jun 11 and tagged it with Apple IMHO iOS

Today I will be flying to Poland with the folkrock band ”Hedningarna” for a gig in Warsaw. I’m going to be their FOH engineer. (The guy that controls the sound that the audience hears). This post will not be about sound engineering or about Hedningarna though. It will be about the fact that this little adventure will involve a plane flight from Stockholm to Warsaw. During this flight I will really try out my iPad (and iPhone) as travel companion.

I liked my iPhone from the second I bought it, however I think that my love for it started when I took a long train ride from Arvika to Falun two years ago. I had an Apple keynote video loaded into it and I’d just started using Instapaper. That long boring train ride with poor Internet coverage had never felt fater and less boring.

Now I’m hoping that the iPad will do the same for the plane ride. It’s loaded with a lot of articles in Instapaper, a few comics and some videos from Webstock ’11.

I will revisit this topic (although in a new post) once I’m back from the trip.

∞

Replies and comments

Henrik Carlsson's Blog
8 juli, 2011 00:32

[…] week I wrote a blog post about my upcoming trip to Warsaw with the band Hedningarna and the fact that I would use my iPad as my main digital entertainment […]

Podcaster for iPhone

Henrik Carlsson posted this on 15 jun 11 and tagged it with App Tips iOS Podcasts

I spend a big part of my life with my iPhone headset on. For the last six months or so most of that time has not been about listening to music, it’s been about podcasts.

My podcast craze started last summer when I discovered Boagworld.com, just as it took a break from regular production. The addiction was furthered as 5by5.tv came into my life. I could write a whole post about why Boagworld and various 5by5-shows are awesome, but I won’t. Not now anyway.

In the beginning of my podcast listening i was perfectly happy with the podcast feature in iTunes. When I browsed through Boagworld’s extensive back catalogue it was easy to just download huge chunks of episodes on my Mac and sync it to the iPhone. However as I started listening to more and more new podcasts the tethering of the iPhone to the computer started to feel more and more annoying. Enter Podcaster for iPhone.

Everything that iTunes does, Podcaster does better. It also does a whole lot of stuff that iTunes doesn’t, primarily keeping good track of my subscriptions, let’s me chose whether I wan’t to limit my downloads to WiFi connections only or not (regardless of file size) etc. It also keeps a handy archive of podcasts to browse through. (Yes, off course you can add any podcast to your list simply by entering the RSS-feed URL of the podcast.) And it also gives you push notifications whenever a podcast you’re subscribing to has been updated (highly customizable).

Do you listen to podcasts and own an iPhone? Then it’s a no-brainer in my book. Visit Podcaster.fm or head straight to the App Store and buy Podcaster!

∞

Why Instapaper still matters to me

Henrik Carlsson posted this on 12 jun 11 and tagged it with Apple Instapaper iOS macOS WWDC

A few days ago Apple opened its WWDC with a keynote showcasing some of the news in iOS 5, OS X Lion and the semi-new service iCloud. One of the features that was announced was Safari Reading List, a special bookmarks folder inside Safari where you can save pages for later reading. This is more or less in direct competition to one of my very favorite iOS apps; Instapaper.

If you by any chance haven’t heard of Instapaper, here is a quick explanation. Instapaper let’s you save articles from the web to a list of things to read later. You can do all your reading for free on instapaper.com, or you can buy (for $5 i think) the iOS app that also downloads the articles you saved so you can read them offline (perfect for people like me who chose the WiFi iPad).

I could go on and on about the greatness of Instapaper because it’s an app and service that is absolutely essential to the way I browse content on the web, but I won’t. There’s however one more thing I have to explain about Instapaper before I get to the point of this post and that is the way you get articles to Instapaper. Thera are a few different ways to do this. The most important ones (according to me, off course) is:

Copy a URL and when you open the app it will ask if you want to add that url to your read later list.
Use a bookmarklet in your browser to send your current page to the read later list.
Use Instapaper’s API.

Safari Reader uses more or less the same approach as the second point. Though not a bookmarklet it will be a special menu alternative inside Safari. The first item in my list is not really something that the user of Safari Reading List will miss since it is not necessary because Reading List is inside Safari. You do not interact with another app.

For some people this might replace the functionality of Instapaper. Marco Arment, the creator of the Instapaper software and the owner of Instapaper LLC (and also the host of the brilliant 5by5 podcast Build and Analyze) has commented on it, both in his blog (link to Marco’s blog post), in his podcast (link the the episode ”Circling Birds”) and in some other tech related news. He brings up a lot of valid arguments why Safari Reading List might actually prove to strengthen his business. However I think he misses one very important feature where Instapaper will likely kick Reading Lists ass; The API.

The Simple Instapaper API allows third-party applications to add URLs to Instapaper.

And a lot of third-party applications on iOS and OS X does this. As far as I know every respectable RSS-reader or Twitter-client (again on iOS and OS X) is integrated with Instapaper via the API. Whenever you stumble upon an article in you RSS-feed that is too long to read right now, just send it to Instapaper. When you browse you Twitter-stream and find a link to an article but haven’t got time to follow the link, send it to Instapaper. Especially for twitter this is great for me since I usually check my twitter-feed when I’m on the go or have a few minutes break. It’s enough time to see what’s new, but not to do any quality reading. (Yes, I know that by now I’m starting to sound like an Instapaper commercial.)

So that’s that. Quite a lot of text to make a small point; Instapaper’s API is it’s best feature compared to Safari’s Reading List, for me and probably for a lot of other geeks.

∞