A perfectly valid way to animate some views.

For an app I'm developing I wanted to have two UITextFields animate on screen. There are a thousand different ways to do this. I ended up using and IBOutletCollection containing my two views and some fast enumeration blocks (no different then a for in loop other then indexes and a boolean stop pointer). You can take a look at my code here. I had to allocate an array for my CGRects because I can only access a reference inside the blocks, so by putting them into an array I was able to grab the pointer that was allocated. Then in my completion block I freed the arrays, if I did this outside the UIView animation block, I would have lost my arrays before the animation completed and I would inevitably end up seg faulting. This was just another different way at looking at a problem that I wanted to share.

CGRect endFrame1 = [_inputFields[0] frame];
CGRect endFrame2 = [_inputFields[1] frame];
CGRect startFrame1 = endFrame1;
CGRect startFrame2 = endFrame2;
startFrame1.origin.y -= 100;
startFrame2.origin.y -= 50;
CGRect *start = calloc(2, sizeof(CGRect));
start[0] = startFrame1;
start[1] = startFrame2;
CGRect *end = calloc(2, sizeof(CGRect));
end[0] = endFrame1;
end[1] = endFrame2;
[_inputFields enumerateObjectsUsingBlock:^(UITextField   *obj, NSUInteger idx, BOOL *stop) {
    [obj setFrame:start[idx]];
    [obj setAlpha:0.0];
}];
[UIView animateWithDuration:0.6 delay:0.0 usingSpringWithDamping:1.0 initialSpringVelocity:0.5 options:UIViewAnimationOptionCurveEaseIn animations:^{
    [_inputFields enumerateObjectsUsingBlock:^(UITextField *obj, NSUInteger idx, BOOL *stop) {
        [obj setFrame:end[idx]];
        [obj setAlpha:1.0];
    }];
} completion:^(BOOL finished) {
    free(start);
    free(end);
}];

New Business Cards!

Hey everyone, this is going to be a short post, I have something bigger in store that I'm working on. But I wanted to maybe get some feedback on the business card that me and my amazing friend Katie designed.

Let me know what you think or if you know of any good places to get them printed. Check back soon for an exciting post about what I've been up to this week!

New to the blog-o-sphere and a tad on iOS keyboards.

So I want to start off by introducing myself, and telling you a little about me. My name is Michael Timbrook and I have just finished up my first year of school studying Software Engineering at the Rochester Institute of Technology. I'm starting this blog because I want to share some of my work with the world beyond just source code. I will  mainly blog about ways I go about implementing features and more importantly why I decided to do it that way. As a Software Engineer, developing efficient software systems is the one of main goals.

Going into a bit more about what I do, I am mainly an iOS developer. I am working as an undergraduate researcher for Dr. Ludi at RIT. This summer I am working full time on two projects, AccessBraille and AccessMath. While iOS and the objective-c language is where I am most comfortable programming, I am familiar with many other languages as well. While I would love to keep talking about myself but it's getting late and I want to show you how I deal with keyboards in iOS.

So to get started, I want to look at a simple problem (You can look at the source code that I'm referencing here). Dealing with the keyboard on iOS. This is something that I've always done a different way every time I tackle this problem, this problem with the iOS keyboard. What I've run into the most is that your content is not in the right place when the keyboard is brought up. I've read a few tutorials on dealing with this, and they all work, but I think you can do better then putting a button behind your view and just moving your view up. While this works, it doesn't do much, and I believe that all user experiences should simple and still provide the best functionality. My fix to this simple problem utilizes some great, maybe not so known, APIs. NSNotification listeners and the setGestureRecognizers method on UIViews. I discovered these when trying to look at this problem differently. When your keyboard is open what are you using? JUST your keyboard right? Now look back at your application, what user interaction is needed that was there before? Nothing, when the keyboard opens the way the user interacts with the application changes and can be pre defined. All the application needs to do is move the view and dismiss the keyboard. This can be done with two gestures, in my case I used an pan to move the back view and a tap to dismiss the keyboard. So when the keyboard becomes active (called from here) I remove the and store any gestures that may have existed on the view and replace them with only the ones I need for interactive with the keyboard. When the keyboard resigns, I replace the original gestures. This allows you too look at the keyboard active state as just that, a separate state. 

Taking this back a step and looking at the bigger picture, you can really improve design and functionality when you take the time to only give the user what they need when they need it. This also creates cleaner code prone to less bugs and it becomes easier to test. I want to stop here and hope that this helped maybe solve your keyboard bugs, but also maybe take a different approach toward you application design. This was just a different way of looking at one problem and this is only the start of what I might find as I dig deeper into my education. I will be posting on topics regarding my school work and also my work work; I hope that you like what you see and I love feed back. If you have any questions or you just want to give some feedback, please I really appreciate it, leave a comment.