Apple's Touch ID may be getting more than just software enhancements this fall. The fingerprint sensor system is slated to expand beyond unlocking the iPhone 5s and making purchases in the App Store and iTunes. Apple announced at their WWDC event that Touch ID would be accessible to app developers for remembering passwords for authentication. Imagine paying via PayPal with your fingerprint!

Obviously, the next iPhone will have Touch ID; there's no going back. But Touch ID could come to the iPad and iPod touch (assuming Apple keeps making those.) After all, the iPad Air and iPad mini with Retina display were released after Touch ID, so the absence of a fingerprint reader was conspicuous. This fall, that oversight is likely to be fixed.

However, we may not see the old Touch ID. Rumors from Taiwan, reported by Apple Insider, suggest an improved Touch ID sensor could be on the way. Apple may be making efforts to deliver a more reliable and durable home button fingerprint sensor. Apple's supplier, Taiwan Semiconductor Manufacturing Co. is forecasting 120 million Touch ID units, which signals more than just iPhones.

Apple does so much right. iOS is not a perfect operating system but it is the best one out there. I can't speak for the Mac OS because, sadly, I don't own a non-iOS device (...yet). 

When I purchased my iPad Air a few months ago, I started using iWork's Numbers and Pages and found these apps incredible for spreadsheets and word processing. By the way, I wrote this article outside on my porch on my iPad Air using Pages. 

My gripe regarding Apple is what I call their minor apps: Reminders, Calendar, and Notes in particular. Let me take these on one by one, briefly. But before I do, let me point out that unlike third-party apps, native iOS apps integrate seamlessly with Siri, which is a huge plus. Also, these apps backup to the iCloud. Unfortunately, these two advantages aren't strong enough to overcome the flaws of these apps.

I get the impression that for these minor apps, Apple put some person in charge and gave them just an hour to create them. I could be wrong. 

First, Notes. I have no need for this app. None whatsoever. One word: Evernote (free). Enough said. Evernote does everything Notes does (which isn't much) and so much more.  

Next up, Calendar. Since converting over to iOS back in November 2012, I have tried numerous calendar apps. None have been worse than the default calendar app. Of course, while you can use third-party calendar apps, there are functions that they still can't do. Yet. I'm guessing Apple blocks some part of the code for these third-party app developers. Personally, I have finally settled (for now, at least) on Readdle's Calendar 5 (free) app.   Despite its $6.99 price tag, I can assure you that this app is worth it's price.  I'm a Google Calendar user and found that Calendars 5 works seamlessly with it. 

Finally, Reminders. I love having the ability to ask Siri to remind me of something  hands free. But, the iOS Reminders app is unstable at best. I would check off a task via the Notification Center on my iPhone but then when I went into my Reminders app on my iPhone, the task would still be there, unchecked. 

And then, if I am able to check off a task on my iPhone 5s, it may or may not be updated on my iPad Air. Even when I wait several minutes. Even when I wait 30. When I searched for this problem online, I found out on the Apple forum that this is an iCloud issue (and I'm not going there in this post). You can force an updated sync by going to the iOS Calendar app, clicking on calendars and pulling down and forcing a sync. But why should we have to do this?

As a side note, when I called Apple about this, they told me because the Reminders app could not be uninstalled and reinstalled that I had to do a backup and restore. Which didn't work. Then they told me to do a restore but not to put my backup on my iPhone and use it for a week or two. I'm sorry, but that isn't going to happen. I use my iPhone as my office and I can't do that. 

It would be nice (and this is not an original idea from me) if Apple allowed us—their dedicated fans—to not only set a third-party version of the Notes, Calendar, or Reminders apps as default, but also to delete the native iOS apps we don't want.

Apple does a lot right, but minor apps is not one of them. Give us more control, Apple. I love you too much to ever want to leave. 

What say you? 

Top image credit: 360b / Shutterstock.com

One of the earliest computer games was Sokoban, a well-crafted Japanese puzzle creation whose name literally meant "warehouse keeper." The 1982 PC-based game featured a pixelated person in a warehouse, moving boxes from one point to another to solve a puzzle.

Over the years, Sokoban has influenced many game creators, who have added their own bells and whistles and new game dynamics (such as adding pulling or picking up boxes in addition to pushing). Sokoban-inspired games provide a perfect challenge for puzzle fanatics because they're great for your brain—several studies have even backed that up! The difficulty of these puzzles in computer science terms is "NP-Hard", a way of judging the most difficult kinds of algorithms, and something our brains do naturally to find the paths that will allow us to reach ever-more-difficult goals.

In the past few months, a handful of great games with Sokoban-inspired gameplay or elements have come on the iOS scene. If you're feeling the need for some puzzle-solving in your iOS life, one of these game is likely to do the trick.

1. CLARC (free demo, full version $3.99)

iPhone Life rating:  5 out of 5 stars

One of the cutest games to show up this year is CLARC, a sweet and surprising story puzzle by Golden Tricycle about a dedicated robot who is trying to keep things working while his colleagues party. Who knew diesel fuel could get robots drunk? The puzzles get more complicated right along with the story, and eventually CLARC goes from moving blocks out of the path and placing them on buttons, to moving and controlling drones, who all seem to have a mind of their own. The controls are perfect, and after a while you'll move through the environment without even thinking about directions, turning, or picking up and dropping your cargo. While this game goes far beyond the pure Sokoban-style, it's too lovely to leave out of this lineup. Plays well on both iPhone and iPad.

2. Kelso's Quest (free, IAPs)

iPhone Life rating:  4.5 out of 5 stars

From indie developer Avocoder comes a wonderful story puzzle game that combines elements of adventure, Sokoban-block-pushing, avoidance, and more. You play as Kelso the Koala, searching for his kidnapped son, and you must face all the dangers of the environment through which you travel. From dart-spitting totems to lava pits, it's a dangerous world out there! The story is endearing, the art unlike anything else you'll see this year, and play is extremely intuitive, if a bit more difficult on the small screen of an iPhone. While this game does have IAPs, they are true micro-transactions. They don't interfere with the game, and, for a small amount, you can unlock more worlds than the one you get for free. If there is one downside, it's the ads that pop-up after every level, but an ad-free version is available.

3. Sokoboom 2 (free demo, full version $1.99)

iPhone Life rating:  4.5 out of 5 stars

For an absolutely great-looking take on the classic, you can't do better than this year's Sokoboom 2. Pure Sokoban-style game play combines with sharp graphics and a perfect implementation on the touch screen to guarantee a straight-up challenge. The demo only has six levels, and the difficulty curve really ramps up as soon as you hit that first paid level, but it's worth it for the mental workout. This game provides a single step-back undo button, which can come in handy at times. While there is not much in the way of a story, it's enough to make you want to help the cute little chub of a boy make his way out of the dungeon...if it ever ends, that is! The graphics are tiny, so playing on an iPad makes it considerably easier.

My ratings are based on the following rubrik:

• Mechanics (features, controls, modes) - 10 points
• Presentation (art, graphics, sound, layout) - 10 points
• Difficulty (appropriate to game, curve) - 5 points
• Story (why do we care?) - 5 points
• Playability (playable, easy to grasp, recommendable)- 10 points
• Replay value - 5 points
• Other (IAPs, ads, social entreaties, etc.) - 5 points

...for a total of 50 points, which are then integrated with the 5-star rating system.

The iPhone's built-in flashlight can come in handy in all sorts of situations, such as digging through camping equipment while you look for a real flashlight during a power outage, cleaning up after your dog on late-night walks, or locating the eyeglasses you just knocked off your bedside table in the middle of the night without turning on a lamp and waking your spouse.

But since your iPhone usually goes to sleep while you are completing these tasks, opening Control Center to turn off the flashlight when you are finished can feel like too many steps—especially if you prefer not to allow access to Control Center from your lock screen. 

Fortunately, it turns out it's not necessary to open Control Center again to switch the flashlight off.

All you have to do is press the Sleep/Wake button or the Home button and then tap the camera icon on the lock screen to turn the flashlight off. 

Top image credit: Terry Underwood Evans/Shutterstock.com

Do you have an idea for an app but lack the programming knowledge to begin building it? In this weekly blog series, How to Unleash Your Inner App Developer, I will take you, the non-programmer, step by step through the process of creating apps for the iPhone, iPod touch, and iPad. Join me each week on this adventure, and you will experience how much fun turning your ideas into reality can be! This is Part 12 of the series. If you're just getting started now, check out the beginning of the series here (this post has been updated to iOS 7.1.)

One of the best software development books of all time is Steve McConnell's Code Complete. Whether you are a seasoned software developer or a brand new programmer, regardless of the platform or language in which you write code, I highly recommend checking out this book. It will change your way of thinking and vastly improve the quality of the code you write.

'Software Accretion'—Building Over Time

After reading Code Complete years ago, the book's comparison of software development to oyster farming really stuck with me. McConnell used the term software accretion to describe the process of building software over a period of time. The word "accretion" refers to any growth or increase in size by a gradual external addition or accumulation. This is the way an oyster makes a pearl; by gradually adding small amounts of calcium carbonate over a period of time, a pearl grows larger and larger.

With incremental software development, you start out by making the simplest version of a system that will run. You create a skeleton strong enough to hold the real system as it's developed, just like an oyster that begins building a pearl with a small grain of sand. This is exactly what we have done so far in this column with the iAppsReview app. We built a prototype of the app first, and gradually, over time, we have added code each week with the final goal of creating a fully-functioning app.

Hardening Your Code

As part of the incremental process of building an app, you need to take a look at your code and ask the question, "What could go wrong?" Typically, one of the biggest variables to consider is your users. They will constantly surprise you by using your app in ways you didn't even consider. I've worked with quite a few development teams over the years, and I have yet to see a case where developers weren't astonished by watching people use their software. When it comes to app development, it is critical that you let others kick the tires on your app before submitting it to the App Store. Their feedback will absolutely improve the quality of your app's user experience.

Let's take a look at iAppsReview, identify areas where problems may occur, and then harden our code to avoid any issues. You can get the project we have completed so far at this link. If you get stuck following the step-by-step instructions, you can get the completed project for this post at this link.

As it stands right now, if the user doesn't enter an app name or comments in the Write Review scene, the app doesn't crash; but when they try to share the review on Twitter, they will get an empty tweet except for the hyphen as shown in Figure 1.

Figure 1 - The user can send an empty tweet.

So how should we address this problem? It's a best practice to look at the built-in iOS apps to see how Apple handles a particular situation, and use that as a guide for our own apps. For example, when specifying a Twitter account in the Settings app, the Sign In option is disabled until the user enters both a User Name and Password (Figure 2).

Figure 2 - The Sign In button is disabled until the user enters a User Name and Password.

This also is a good approach for the Write Review scene. Ultimately, we only want to enable the Share button if there is text in both the App Name text field and comments text view. This means each time the user types a character, we need to check both user-interface controls. If either is empty, the Share button must be disabled. If both controls contain text, the Share button can be enabled. We have to perform this check for every character the user types, because they could press the delete key, leaving one of the user-interface controls empty.

Creating a Share Button Outlet

Since we need to access the Share button so we can enable and disable it, our first step is to create an outlet for the button. To do this, follow the steps listed below.

1. Open the iAppsReview project in Xcode;

2. In the Project Navigator, select the MainStoryboard.storyboard file;

3. In the Write Review scene, click on the Share button in the top-right corner of the scene;

4. Go to the Attributes Inspector (the third button from the right in the Inspector toolbar), and uncheck the Enabled check box as shown in Figure 3. This causes the Share button to look disabled at design time and when the scene first appears at run time;

Figure 3 - Uncheck the Enabled check box.

5. Next, display the Assistant Editor by clicking the center button in the Editor button group at the top of the Xcode window. This should display the WriteReviewViewController.m file in the Assistant Editor;

6. Hold the control key down, click on the Share button, and drag down into the WriteReviewViewController.m file as shown in Figure 4;

Figure 4 - Create an outlet for the Share button.

7. When you see the Insert Outlet, Action, or Outlet Collection popup, let go of the mouse button and the control key. This displays the Insert Outlet popup. Enter btnShare as the outlet Name and then click the Connect button (Figure 5). This adds a new btnShare outlet property to the header file.

Figure 5 - Create an outlet named btnShare.

Configuring the App Name Text Field

Now let's configure the App Name text field to enable and disable the Share button. First we need to create an outlet we can use to reference the text field.

1. Control+Click on the App Name text field in the design surface, and then drag down into the WriteReviewViewController.m fileas shown in Figure 6.

Figure 6 - Create an outlet for the text field.

2. In the Create Outlet popup, set the Name field to txtAppName, and then click Connect (Figure 7). This creates a new outlet property named txtAppName.

Figure 7 - Enter txtAppName in the Name field.

3. With the App Name text field still selected, go to the Connections Inspector (the button on the far right in the Inspectors toolbar). Under the Sent Events section, click the connection well to the right of the Editing Changed event and drag down into the WriteReviewViewController.m file as shown in Figure 8. The Editing Changed event fires each time the user enters or deletes a character in the text field;

Figure 8 - Create an action method for the Editing Changed event.

3. When the Insert Action popup appears, let go of your mouse button and the control key. This displays the Create Action Method popup (Figure 9). Enter appNameChanged as the method Name and then click the Connect button. This adds a new action method to the WriteReviewViewController.h file. You can close the Assistant Editor now by clicking the left button in the Editor button group;
   

   Figure 9 - Create an action method named appNameChanged.

4. Now let's implement the new method. To do this, scroll down in the WriteReviewViewController.m code file and enter the code shown in Figure 10. 

Figure 10 - The code in this method enables and disables the Share button.

This is the first time I have shown this type of code in my blog post so I'll explain how it works. This is an Objective-C if else statement. It belongs to a family of conditional statements and it allows you to execute one set of code or another based on a condition.

The condition that is checked by this statement is contained within parentheses immediately following the if as shown in the first line of code in this method. This particular condition contains a compound comparison, where two values are checked. The double vertical lines between the two conditions ( || ) is a logical OR operator. This means if the first condition OR the second condition evaluates to YES, then the code within the curly braces directly following the if is executed. Otherwise, the code contained in the curly braces following the else statement is executed.

First, a test is performed to see if the length of the text in the tvwReview control is equal to zero, which it will be if the text field is blank. If this part of the condition is true, then the code that disables the button is executed without checking the second part of the condition. There's no need to check because if either part of the condition is true, the button should be disabled. If the first part of the condition is true, then the second part of the condition is checked. If the length of the text property in the text field is equal to zero, then the code that disables the button is executed.

If both parts of the condition are false, then the code in the else statement executes, which enables the Share button;

Configuring the Review Comments Text View

Now you're ready to set up the review comments text view. We have to take a different approach with the text view because it doesn't have an Editing Changed event as the text field does (you can click on the text view in the design surface and then go to the Connections Inspector to see what I mean).

As is the case with the text view, if you don't find the event that you need with a particular user-interface control, your next step is to check if the control has a delegate protocol that can be adopted so that you can be notified of important events (see my previous post for a discussion of delegates and protocols). If you look at the UITextView documentation, you will find there is indeed a delegate property whose type is a protocol named UITextViewDelegate. This protocol contains a textViewDidChange: method (Figure 11), which is exactly what we need. As the documentation states, this method is automatically called on the delegate when the user changes the text in the text view.

Figure 11 - The textViewDidChange: method is called when the user changes the text in the text view.

Let's adopt this protocol now.

1. We no longer need the Assitant editor, so click the button on the left in the Editor button group to get rid of it. Next, in the Project Navigator, select the WriteReviewViewController.h header file;

2. Add the code shown in Figure 12 to adopt the UITextViewDelegate protocol, and remember to add a comma after the UINavigationControllerDelegate protocol at the end of the previous line of code;

Figure 12 - Adopting the UITextViewDelegate protocol

3. Now let's implement the protocol. To do this, click the WriteReviewViewController.m implementation file in the Project Navigator and add the new, empty textViewDidChange: shown in Figure 13 directly below the appNameChanged: method.

Figure 13 - Add the textViewDidChange: method.

Line for line, we need the code in the textViewDidChange: method to do exactly what the code in in the appNameChanged: method is doing. So what should you do? First of all, let's talk about what you should not do.

One of the biggest mistakes rookie developers (and unfortunately even some seasoned developers) make is copying the code from one method and pasting it into another. Why is this a problem? One of your goals as a developer is to avoid creating duplicate code. Why? If you ever have to make a change to the code (and eventually you will) it means there is more than one place where you have to make the change.

So what should you do instead? You should break the code out into a separate method that can be called from multiple places in your app. That's exactly what we're going to do now;

4. Add a new, empty isReadyToShare method as shown in Figure 14 directly below the textViewDidChange: method. When we finish adding the code, this method will return YES if the Share button should be enabled, and NO if it should not;

Figure 14 - Add the new isReadyToShare method.

5. Now, instead of doing a copy and paste, we are going to cut and paste the code from the textViewDidChange: method into the new isReadyToShare method. To do this, select all of the code in the textViewDidChange: method as shown in Figure 15 by clicking and dragging from the first line of code to the last line of code in the method;

Figure 15 - Select all code in the appNameChanged: method.

6. Next, type Command+X to cut the code from this method;

7. Now click inside the curly braces of the isReadyToShare method and press Command+V to paste the code into the method. When you're finished, these three methods should look like Figure 16;

Figure 16 - The code has been cut from appNameChanged: and pasted into isReadyToShare.

8. Now we need to change the code in this method to return a NO if the Share button should not be enabled, and YES if it should. To do this, replace the code between curly braces in the if else statement as shown in Figure 17;

Figure 17 - isReadyToShare returns NO to disable the Share button and YES to enable it.

9. Now add the code shown in Figure 18 to the appNameChanged: and textViewDidChange: methods. This code passes an isReadyToShare message to the view controller and stores the returned value into the enabled property of the Share button.

Figure 18 - Pass an isReadyToShare message from both methods.

10. There's one more step we need to take to make this work properly. We need to store a reference to the WriteReviewController in the delegate property of the text view.

To do this, go to the Project Navigator and select the MainStoryboard.Storyboard file and then go to the Connection Inspector (the button on the far right in the Inspectors toolbar). Click the connection well to the right of the delegate outlet and drag down to the Write Review View Controller icon in the dock below the Write Review scene as shown in Figure 19. When you release your mouse, the delegate outlet and view controller will be connected.

Figure 19 - Connect the text view's delegate property to the WriteReviewViewController.

Kicking the Tires!

Now we're ready to kick the tires and see how our changes work.

1. Click the Run button in Xcode and when the app appears in the Simulator, select the Write a Review option;

2. Type text into the App Name text field first, and then type in the text view afterwards. Notice as soon as you type the first character into the text view, the Share button is enabled!

3. Try deleting all the characters in one of the controls and then the other to see the Share button get enabled and disabled.

Growing the Pearl

If you were building this app for a client, you may show them the app to get some feedback after adding this new functionality. At this point, what if the sponsor tells you a zero star rating is not acceptable (just as in the App Store)? Now you need to change the app to ensure the Share button is not enabled until a rating is selected.

I'd like you to think about what you would have to do if you had simply copied the code that checked for an empty text field and text view from the appNameChanged: method and pasted it into the textViewDidChange: method. Now you would have two places where you would have to add code that checks if the user selected a rating for the app! This is not the kind of app you want to create. It is far better to do what we have done in this post and create a separate method that can be called from the appNameChanged: and textViewDidChange: methods, because there is only one place where we have to change the code.

Conclusion

Creating high quality apps is both a science and an art. The effort you put into creating a well-designed app will pay itself back in dividends many times during the life of your app. I recommend you read through books such as Code Complete to learn even more great coding practices and elevate your app development skills!

<<Previous         Next>>

Armchair athletes may be fine with products from FitBit, Jawbone, and the like, but Apple appears to be going for top shelf athletes. This fall's announcement of an Apple iWatch is an all-but-foregone conclusion, but the difference may be that Apple is seeking the feedback from star athletes like Kobe Bryant. The Beats acquisition demonstrates Apple's attention to celebrity endorsements. While rappers and musicians care deeply about sound quality, professional athletes care deeply about their health!

If true, these rumors, reported by 9to5mac and others, would also represent a shift from Apple's deep security measures, where even Apple employees are not allowed to see next generation products. Allowing someone from the outside to use such a gadget is a major shift from the days when an Apple engineer accidentally left an early iPhone 4 prototype in a bar. Additionally, Apple should have learned a lesson from Dr. Dre's late night social media admission that he was about to become the first billionaire rapper.

This time, the athletes were said to have signed non-disclosure agreements and had a private tour of Apple's facility with design guru JonyIve. Unlike Elvis, it's unlikely that any proprietary Apple gear has left the building. Also of note, Mr. Bryant already signed an endorsement deal with luxury watch maker, Hublot. This could get interesting. If the iWatch is treated more as a health and fitness device, then it shouldn't be a conflict.

Still, Apple has no smartwatch line of products to protect. Unlike the original iPhone, an iWatch will not be a shocker at this stage. Pebble raised millions for their smartwatch on Kickstarter. Samsung, Google, and Motorola have all released or announced a variety of gear for your wrist. Apple's Tim Cook has already admitted that Apple will play in new categories. WWDC's announcement of the HealthKit framework telegraphs Apple's direction for smart wearable devices. If rumors of a Kobe Bryant endorsed iWatch make potential buyers wait for Apple instead of springing for a competitor's gadget, then that could be a good strategy!

It's photo contest time again. We know you enjoy taking occasional artistic shots with your iPhone, so why not get rewarded for it! Enter our iPhone Photography Contest for a chance to win awesome prizes and a spot in our magazine! 

Submit your best iPhone photograph(s) at iphonelife.com/enterphoto by July 4. You must take and edit all photos with an iOS device, using only iOS apps. Don't forget to give each photo a title, and tell us which apps, if any, you used to process each image with.

If your submission is among the three top-voted photos on our Facebook page, you’ll win an olloclip quick-connect lens set ($70 value) and an olloclip Quick-Flip Case ($50 value). The top 10 photos will be featured in an upcoming issue of iPhone Life magazine. Deadline to submit photos is July 4. Voting ends July 9. In addition, we’ll feature the top 10 photos in an upcoming issue of iPhone Life magazine.

Get your friends to vote through Facebook to increase your chances of winning. And get this—They can vote every day! (Voting ends July 9 and is limited to one vote per image per day.) 

You still have time to create a winning masterpiece, so get out there and do it!

Check out some of the entries we've already received at the top of this post by Natalie C. and below by Alyssa T. for inspiration:

Yo. No really, just yo. 

Sometimes there are those apps that are so simple, so basic, so mind-blowingly elementary that they take off and rack up thousands of users, leaving you scratching your head and thinking, "Dear God, what have tweens done to this world?" Enter Yo (free), a new social networking app that became popular this week, racking up $1 million in angel funding and gathering over 50,000 users. 

The simple push notification app, available on iPhone and Android, sends the single message of "Yo" to users with the tap of a button. The app has been compared to a modern day pager or a updated version of Facebook Poke. It may be simple, and it may seem pointless, but it is certainly poised to be the next "big thing." With this prediction, I wanted to be the first to establish some lingo for the newbie app. 

Yo Lingo: 

1. Uh-yo

Probably the most common reason a Yo is sent, an uh-yo is an accidental Yo. The uh-yo mostly affects people with fat fingers and creates an awkward situation depending on who you send it to. 

2. Yo-yo

A yo-yo is a one-to-one yo exchange. Your friend sends a Yo, you respond -- simple as that. 

3. Yopocalypse 

Best performed at 1 a.m. on a close friend as they are just falling asleep, the yopocalypse is when you send upwards of 50 yos. This can create massive panic attacks and cause one to throw a phone into the next room. 

4. Yo-Yo Ma

This is when your mom joins Yo (like she has every other social media network) and insists on Yo-ing you every day. When this happens, you should immediately delete the app. No questions asked. 

Monoprice has made quite a name for themselves lately, with their high-quality, low-price tech gear. Recently I had the opportunity to try out their newest pair of Bluetooth headphones, the Monoprice 10585 ($89.50). To say that these are an awesome pair of headphones would be an understatement. These are definitely one of the most comfortable pair of on-ear headphones I've ever tried on, at any price, and for under $90 these affordable and great sounding headphones might be hard to pass up. The 10585 sets itself apart from the crowd with a very unique sonic signature and physical design. If you think I'm kidding, then check out these specs:

Design:

Within any given category, all headphones are similar. But they are certainly not all created equal. An exceptional case in point is the 10585s from Monoprice, the increasingly popular manufacturer of discount audiophile and electronic gear. These headphones are a stylish accessory, and with their convenient folding design, they are the perfect travel companion. Made of resilient plastics, these super lightweight, wireless Bluetooth headphones are extremely convenient for today's mobile life on the go.

The 10585 is an on-ear headphone set, which means that technically it rests ON your ears as opposed an over-ear pair, which would theoretically encompass most if not all of the ear lobe. That said, unless you have really large ears (I myself have large ears), these oversized on-ear headphones may fit you almost like an over-ear pair of headphones; they are so spacious, comfortable, and noise isolating. For the record, typically an over-ear pair of headphones would cost more than a similar, smaller, on-ear  model. Considering that the 10585 earcup fits more like a circumauralearcup, they become an even greater bargain for the price. So while the manufacturer may call the 10585 "on-ears", I'd say that from experience and as someone with larger ears, that they are more like compact over-ears.

The Sound:

Here's where the 10585 headphones really shine and show their mettle. These cans boast some impressive acoustics backed by an ingenious speaker driver layout. The internal design of the 10585's earpieces consists of 2 woofers (50mm 32O) and 6 3D speakers (13mm 16O), which work in concert to ensure a rich, vibrant audio experience with incredible depth and range. Now keep in mind, most headphones of this style employ one speaker driver which delivers all of the sound, sometimes two when the headphones are designed to deliver extra bass, so for these cans to pack 8 speaker drivers into the earpieces is pretty impressive and it's where the 3D Surround Sound capabilities of these headphones stem from. Additionally, as mentioned above, the 10585 headphone covers your ears fully so their very efficient noise isolating ability is also worth emphasizing.

Pros:

• 25 hours of Bluetooth playback, the most of any on-ear Bluetooth headphone I've come across.

• Full-function controls built in to the headphones for hands free playback control or calling.

• Collapsible and weighing in at only 7.4 oz, the 10585s make for easy transportation, include a leather carry bag.

• Well-balanced sound with plenty of bass response when the music drops.

Cons:

• Some people who offered online reviews of this headset complained of the huge Monoprice logo emblazoned across the headband, saying they found it embarrassing. However I'd suggest that as Monoprice continues it's trajectory of ascent, gaining respect from audio enthusiasts as it does so, any stigma associated with its reputation as a discount store will be forgotten. I think of them as the Amazon.com of the tech-specific sector.

• The headphones will not play with a dead battery, even with the included 3.5 mm audio cable plugged in. Furthermore, you only get 16 hours of playback if the audio cable is what you opt to use.

Verdict:

This is an outstanding pair of headphones, and for the quality of comfort and acoustics it delivers, it is a steal of a deal. I would highly recommend these headphones as a great alternative to many of the higher priced but comparable performance, popular name brands. I give the Monoprice 10585 headphones a rare 4.5 out of 5 Star rating.

I'm on an Amtrak train heading from Rochester, NY, to New York City to attend CE Week. CE Week is like a mini CES, with hundreds of vendors instead of thousands; but it's a nice way to see the latest technology, in one location, in a short time. I will be writing about many of the new products this week and next, but for now, I thought I'd write about some of the gear that makes it practical to work on the train.

First, Amtrak offers Wi-Fi on select routes along with the power outlets at each seat. Sure, I wouldn't recommend streaming Netflix on the train's cellular-based Internet connection, but it's fine for uploading blog postings and checking email.

Speaking of power, I brought along TYLT's Energi Backpack. This thing is amazing. Forget for a second that it has a huge battery with three USB ports, the TYLT backpack has so many compartments, I find a new one every time I use it! Several of the compartments are crush proof too. Most are lined with a velour-like microfiber which can protect and even clean your tablet as you slip it in and out. I was able to fit everything I need for three days in New York City in one backpack. And the fact that it charges my iPad, iPhone, and Bluetooth keyboard is a nice plus!

The Bluetooth keyboard in question is the iPad Flip Case from uuber (formerly IGEAR.) I've used their cases before and have been impressed, so I was very interested in this case/keyboard combination, which is available for numerous iPads including the mini versions. My iPad Air snapped right in, and feels quite secure. The case works like a clamshell, so it looks like I'm using an ultralight touchscreen laptop! There's a twist, literally, as the case mimics the "Yoga" feature from Thinkpad and other convertibles. You can spin the display around and use the case as a display stand for movies, or close it with the screen facing out, and use it as a clipboard-style case. they even include a hidden stylus that tucks away under the keyboard with the iPad Air model. The keys are nice chiclet style, although some of the number and function keys are a bit smaller than I'd prefer. There's a backlighting option (adjustable via Fn6 on the iPad Air model) that helps locate the right keys, as touch typing is possible but tricky when special characters are needed. For this trip, it's a perfect companion. And I'm using it to write this article, and more from my cozy mobile office on Amtrak.

The investment bank Pacific Crest Securities yesterday predicted in an opinion piece in Barron’s that the iPhone 6 will not only boost Apple Inc., it will also benefit component makers like InvenSense, NXP Semiconductors, and Synaptics.

After a recent trip to Asia to scout local manufacturing plants of those publicly traded companies, Pacific Crest analysts Kevin Chen and John Vinh report that the iPhone 6 will likely support near field communication and optical image stabilization. “Following supply-chain conversations, we are increasingly confident that the iPhone 6 will support near field communications (NFC) radios supplied by NXP,” the analysts note in their Barron’s piece. “This is consistent with our prior view of NFC in the iPhone 6 given the deployment of mobile NFC-enabled VeriFone terminals in Apple stores, the China UnionPay agreement, Apple payment patents and NXP's mobile-payment licensing agreement.”

 The investment bankers believe Apple will deploy an NFC radio without the secure element in the iPhone 6. “While some investors may be disappointed by an NFC-only solution, we view this as a positive and incremental revenue opportunity for NXP,” Chen and Vinh report.

Do you have an idea for an app but lack the programming knowledge to begin building it? In this weekly blog series, How to Unleash Your Inner App Developer, I will take you, the non-programmer, step-by-step through the process of creating apps for the iPhone, iPod touch, and iPad. Join me each week on this adventure, and you will experience how much fun turning your ideas into reality can be! This is Part 13 of the series. If you are just getting started now, check out the beginning of the series here. (This post has been updated to iOS 7.1)

This post contains some of the most important information you need to know to build a well-designed app that easily adapts to changes requested by users, the constant changes Apple makes to iOS, and the ever-changing landscape of iOS devices. It all comes down to a solid app architecture. We're going to take a quick digression from the iAppsReview app this week to look at a simpler Calculator app to help us establish good architectural principles.

The word architecture usually evokes images of planning the construction of a building. Whether you are building something as small as a dog house or as large as a skyscraper, a solid architecture is important to make sure the design is sound. This is no less true of constructing software. Whether you are creating a small app or a large business application, good architecture can make it easier to design, build, and extend your software.

Design Patterns to the Rescue

Recently, when I needed to build a shed, rather than starting from scratch, I went online to see what architectural plans other people were sharing. I knew others had already learned from experience what to do and what not to do. I wanted to learn from others' experience and mistakes rather than make the same mistakes myself.

This same principle applies to building software. Through trial and error, other software developers have distilled their experience into what we call design patterns. When you come across a particular problem, you can look up a list of design patterns to see what other developers have done in your situation. Although it's a bit of a heavy read, the most definitive source on design patterns is the book Design Patterns: Elements of Reusable Object-Oriented Software Designby Gamma, Helm, Johnson, Vlissides. For a little lighter reading on a few specific design patterns for iOS development, check out Apple's article at this link.

Anticipating Change

Your app is going to change, not just a few times, but many times over—and that's even before you release it to the App Store! After it's released, your app will change even more as people use it, provide feedback, and suggest enhancements.

If your app is designed to anticipate change, this process is much easier. If your app design doesn't anticipate change, you are headed for a lot of tedious and unnecessary rework. If you get a change request from a user and you find you need to completely rework your app to implement the change, you didn't do your job as an architect! You want to make sure you have designed your app using an architecture that anticipates change to make this process as smooth as possible.

Where Do You Put Your Code?

In a previous post, I discussed the three main parts of an app:

• User Interface
• Core Logic
• Data

Having these separate parts in mind when creating your app is a great start in creating a solid architecture that anticipates change. When these different parts are too tightly bound together, you create a situation where you can't change one part of the app without changing another.

Ultimately, where you put your code has everything to do with how easy it is to write, extend, and maintain your app. Putting your code in logical, predictable places also helps you avoid the game of "Where's that code?" that many developers play on a daily basis.

Introducing Model View Controller

A more formal way to look at the three main parts of an app is by means of the Model View Controller (MVC) design pattern. This pattern has been around for many years and helps you maintain a clear separation between the main parts of your app.

I've been using Model View Controller and its many cousin-patterns for many years. So when I first came to the iOS platform back in 2008, I was intrigued to hear that Apple encouraged the use of the MVC pattern in iOS app development.

Here's how the MVC pattern maps to the main parts of your app:

• Model → Data
• View → User Interface
• Controller → Core Logic

Let's break this down by first looking at a traditional implementation of the MVC pattern, and then we can look at Apple's implementation.

Model

The Model is your application's data, and in iOS, it normally takes the form of entities. An entity usually represents an object in the real world. For example, if you are creating an app that handles customer orders, you might have a Customer entity, Order entity, and Product entity. If you are creating a card game app, you might have a Dealer entity, Player entity, and a deck of cards comprised of individual Card entities.

An entity has properties that represent the attributes of the real-world object it is modeled after. For example, a Customer entity might have companyName, webAddress, phone, address, and other properties that hold this information for each customer as shown in Figure 1. 

Figure 1 - A CustomerEntity has properties that represent attributes of the real-world object that it represents.

View

The View is the part of the app the user interacts with directly, and it contains user-interface objects such as buttons, text fields, sliders, and so on. Because of this, Apple refers to each screen full of information in an app as a view.

Controller

The Controller acts as an intermediary between the Model and the View. The Controller is where your app's core logic goes. Figure 2 shows the interaction that occurs between the Model, View, and Controller.

Figure 2 - Model, View, and Controller interaction

In the MVC pattern, the user interacts with the view—they can touch, tap, pinch, or flick a user-interface object. In response, the View passes a call to the Controller, and the Controller does something based on that interaction. For example, the user might change information in a text field and touch a Done button. The controller could take that new information and update a Model entity.

Sometimes when you save a Model entity, it gets new or default values. The model can fire an event that tells the controller, "I've got updated data." The controller can then update the view and the new data can be displayed in the user interface.

The Controller is the place where you should put your app's core logic. For example, in a Calculator app, you could have a Calculator controller object that adds, subtracts, multiplies, and divides.

Separation of Concerns

MVC is a great pattern for "separating concerns"—keeping the three parts of your app separate. In the MVC diagram shown in Figure 2, there are communication lines between the Model and the Controller and between the Controller and the View, but you will never see communication between the Model and the View. This allows your data and core logic to be used independently of the user interface. When you are creating a universal iOS app (one that runs on both the iPhone and iPad), this is a very important consideration!

Apple's MVC Implementation

Design patterns are a great tool for building high-quality apps quickly. However, I have found that the implementation of a particular pattern may not be true to the pattern's original intent. For example, I was surprised at Apple's use of the MVC pattern because it wasn't a traditional implementation. This isn't just an academic, ivory-tower concern. Unfortunately, Apple's implementation of MVC doesn't provide well-defined boundaries between the three main parts of an app, which is the whole purpose of the MVC pattern.

I think nothing helps the understanding of architectural principles more than looking at a real example. So, I have created a sample app that follows Apple's MVC pattern, and then I have recreated the app using a better implementation of MVC.

Calculator Sample App with Apple MVC

The first app I have created is a Calculator that looks and acts just like the built-in iOS Calculator. It can be downloaded from this link. Follow the steps in this section to get a look at how this app works behind the scenes.

1. Open the App in Xcode. To do this, you can select File > Open... from the Xcode menu, navigate to the Downloads folder, drill into the CalculatorDemo folder, and double-click the Calculatordemo.xcodeproj file;

2. In the Project Navigator, select the MainStoryboard file and you will see the scene shown in Figure 3;

Figure 3 - The main scene in the CalculatorDemoproject

3. To see what the app looks like at run time, first make sure Xcode's Scheme control is set to the iPhone Simulator, and then click the Run button. When the app appears in the Simulator, click any number, and then click an operator such as the minus sign. Notice a highlight appears around the operator, just as it does in the built-in Calculator. This indicates the currently selected operation;

4. Click another number and the equal sign, and you can see the Calculator is fully functioning. You can use the memory keys, add, subtract, read, and clear the Calculator memory. You can even use common Calculator shortcuts. For example, if you type 1+=, and then repeatedly click the = key, the Calculator continually adds one to the previous number;

5. Next, hold down any of the number or operator keys and notice the shading changes slightly to indicate the button has been pressed.

Now let's take a look at the Calculator app at design time to see what makes it tick.

1. Go back to Xcode and click the Stop button;

2. With the MainStoryboard file selected, display the Document Outline panel by selecting Editor > Document Outline from the Xcode menu. As shown in Figure 4, the Document Outline displays a hierarchical view of all the UI objects on the currently selected scene. There are five images (identified by the "img" suffix), and there are quite a few button objects;

Figure 4 - User-interface objects in the Document Outline pane

3. Now go to the Project Navigator, expand the Support Files group, and select the CalculatorBackground.png file. This displays the image in the Interface Builder editor (Figure 5).

Figure 5 - The Calculator background image

You may be surprised to see the buttons are not separate images. The calculator background is a single image that includes all the buttons you see at run time! How is the illusion of separate buttons created when you run the app? There is an invisible, rectangular button over each of the buttons;

4. To see this, go back and select the MainStoryboard file in the Project Navigator. Click on the number 9 button. As you can see in Figure 6, you have selected an invisible button that is positioned directly over the button. 

Figure 6 - An invisible button sits on top of each button in the main app image.

With the invisible button selected, go to the Attributes Inspector (the third button from the right in the Inspector toolbar). Notice that in the header at the top of the Inspector pane it indicates the object you have selected is a Button. By default, this button is invisible, allowing the number button on the image below it to show through.

At run time, when the user taps an invisible button above a number, another image, CalculatorButtons.png, is displayed in the area of the invisible button. This image's Alpha value is set so that it is mostly transparent. That's why when you tap one of these buttons at run time, it looks a little darker, giving the appearance of being pressed. When an operation button is tapped at run time, a hidden highlight image is made visible which displays a white border around the selected button.

At the top of the scene is the Calculator display. This is simply a Label with its Alignment set to Right-Justified sitting on top of a greenish-gray view. As number buttons are pressed and calculations are performed, the Calculator's current value is stored in the text property of the Label.

Calculator Core Logic

Now let's take a closer look at the code in the view controller associated with this scene to see how the Calculator's user interface interacts with the core logic code.

As shown in Figure 7, there are three action methods associated with the Calculator buttons found in the ViewController class:

• operationTouched: is connected to all operation buttons.

• highlightOperation: is connected to the add, subtract, multiply, and divide buttons. This method adds the highlight around the selected button and removes it from the previously highlighted button.

• numberTouched: is connected to all number buttons, including the decimal point button.

These methods are all user-interface specific since they are tied directly to UI controls.

Figure 7 - Calculator action methods

To see a list of the other Calculator core logic methods found in the ViewController class, check out Figure 8. All of the methods you need for a Calculator are found within the ViewController.

Figure 8 - Calculator methods in the ViewController class.

Figure 9 provides a high-level overview of the interaction between the numeric buttons of the Calculator in the user interface and the methods of the ViewController class.

Figure 9 - Calculator numeric button interaction with code

1. The user touches a numeric button;

2. The view controller's numberTouched: action method is called;

3. In the numberTouched: method, some user-interface processing is executed, and then the view controller's processNumber: method is called;

4. The processNumber: method executes the Calculator's core logic for handling a new number and returns the new Calculator value;

5. In the numberTouched: method, the return value from the processNumber: method is stored in the text property of the lblTotal label.

Now let's take a quick look at how the user-interface and view-controller code interact when an operation is selected as outlined in Figure 10.

Figure 10 - Operation button and code interaction

1. The user taps an operation button;

2. The view controller's operationTouched: action method is called;

3. In the operationTouched: method, after executing user-interface processing code, the view controller's performOperation: method is called;

4. The performOperation: method executes the Calculator's core logic for performing an operation and returns the Calculator's new value;

5. In the operationTouched: method, the return value from the performOperation: method is stored in the text property of the lblTotal label.

What's Wrong With This Architecture?

The Calculator App seems to work well. It adds, subtracts, multiplies, divides, and performs all other operations properly. So what's the problem?

Check out the strong link between the Calculator user interface and the view controller as shown in Figure 11. In object-oriented programming terms, this is known as tight coupling.

Figure 11 - Tight coupling between the Calculator UI and core logic

The Calculator user interface is inseparably linked to the view controller. There are properties and methods in the view controller to which the user-interface controls are directly connected. According to Apple's documentation, a view is typically bound to a single view controller. Ultimately, the view controller is a user-interface object. It's not the tight coupling between the view and view controller that's the problem—that's perfectly fine. The problem is the core logic that's in the view controller. Why is this a problem?

A good app is often a victim of its own success. Let's say you release the Calculator app with its current architecture. If it does well in the App store, you may consider creating a Scientific Calculator app. Wouldn't it be great to reuse some of the Calculator app functionality since the Scientific Calculator does everything the regular Calculator does and more?

Unfortunately, because the Calculator's core logic is buried inside the view controller, there isn't a clean way to reuse this logic in another app. It's "stuck in the weeds" of the user interface.

A Better MVC Implementation

So, how do you fix this problem? You need to put the Calculator's core logic in some other place where you can access it from multiple apps, or from multiple view controllers in a single app. If you shouldn't put your core logic in a view controller, where should you put it?

Business Controller Objects

The answer is a business controller object (also known as a business object or domain object). A business object provides a neutral place to put your core logic that can be reused from any user interface, which includes view controllers. As shown in Figure 12, you can create a Calculator business class in which you put all of the Calculator's core logic methods.

Figure 12 - Implementing a Calculator business object

In this figure, the Calculator UI and View Controller are tightly bound together, which is fine—they are both user-interface objects. When users tap buttons on the Calculator at run time, action methods in the view controller are called directly.

The only code you should put in the view controller is code that has something to do with the user interface. However, when core logic needs to be performed, the view controller should make a call to an appropriate method in the Calculator business object.

With your core logic in the Calculator class, you can easily create a ScientificCalculator subclass that inherits all the basic functionality of the Calculator and extends it by adding operations as shown in Figure 13.

Figure 13 - You can easily extend the Calculator core logic when it resides in its own class.

Other Benefits of Using Business Objects

When you create business objects, you are creating a representation of objects in the real world. In the Calculator app, you are creating a representation of a real-world Calculator. In a real estate app, you can create House, Buyer, Owner, and RealEstateAgent business classes that represent real-world entities (Figure 14).

Figure 14 - Business objects represent real-world objects.

Creating business objects helps you bridge something called the semantic gap. The semantic gap is the difference between real-world objects and how you model, or describe these objects in your software applications. In many apps, this gap is extremely wide because the developer has not created any business objects. You will find that when you narrow the semantic gap by creating business objects that represent real-world objects, your apps are much easier to conceive, build, maintain, and extend.

You model real-world object attributes by means of properties, and you model their behavior by means of methods. For example, a house has attributes such as an address, a number of bedrooms, a number of baths, a price, and so on, which can be described, or modeled by class properties. A house can also have behavior such as "put on the market,""take off the market," and so on, which can be modeled as methods on a business object class.

Another benefit of using business objects is it helps you avoid playing the game of "Where's the code?" I mentioned earlier. All the core logic that has something to do with a homeowner is in the HomeOwner business object. All the code that has something to do with a real estate agent is in the RealEstateAgent business object, and all the code that has something to do with the user interface is in a view controller.

Using business objects also helps you avoid code redundancy. When you don't use business objects, it's easy to create duplicate code because you often forget you have already created a piece of functionality in another view controller. When you are using business objects, it's less likely you will create two methods on a business class that perform the exact same function.

The Improved Calculator Sample App

Now that you've seen how not to design an app, let's take a look at the new-and-improved CalculatorPlusDemo sample app that uses a Calculator business object, which you can download from this link.

After opening the project in Xcode, go to the Project Navigator, drill down into the CalculatorPlusDemo node and then expand the User Interface and Core Logic groups. As you can see in Figure 15, under the User Interface group are the storyboard and view controller user-interface files. Under the Core Logic group are the Calculator business-object class files.

Figure 15 - CalculatorPlusDemo project files

Let's check out the improved message flow of the CalculatorPlusDemo app. Figure 16 provides a high-level overview of what happens when a user touches a numeric button.

Figure 16 - The improved Calculator numeric button and code interaction

1. The user touches a numeric button;

2. The numberTouched: action method in the view controller is called, which contains user-interface-specific code;

3. After executing the user-interface processing code, the view controller calls the Calculator's processNumber: method;

4. The Calculator object's processNumber: method executes the core logic for handling a new number and returns the Calculator's current value;

5. The view controller takes the value returned from the Calculator's processNumber: method and stores it in the text property of the lblTotal label.

Now let's look at a high-level overview of what happens when the user touches an operation button as shown in Figure 17.

Figure 17 - The improved Calculator operation button code interaction

1. The user touches an operation button;

2. The operationTouched: action method in the view controller is called, which contains user-interface-specific code;

3. After executing the user-interface processing, the view controller calls the Calculator object's performOperation: method;

4. The Calculator object's performOperation: method executes the core-operation logic and returns the Calculator's current value;

5. The view controller takes the value returned from the Calculator's performOperation: method and stores it in the text property of the lblTotal label.

The big difference here is that the performOperation: method has been moved from the ViewController class to the Calculator class.

Conclusion

When it comes to the Model View Controller design pattern, you have learned that the View and View Controller comprise your user interface, and together they are the View in the MVC pattern.

You also have learned that your App's core logic should be contained in business objects that represent real-world entities. These business objects are the Controller in the MVC pattern.

But what about the Model? As I mentioned earlier in this post, the Model is your app's data and usually takes the form of business entities. In my next post, I'm going to talk about an iOS technology known as Core Data that uses something called entity objects. These entity objects are the other half of the business-object picture that will complete your understanding of the MVC pattern.

<<Previous         Next>>

Apple does not limit the character count for iMessages; but if you are sending a message to a non iUser it will be sent as an SMS and will therefore be limited to 160 characters. This means characters over 160 will be sent in a second text or possibly even deleted, depending on your recipient's carrier. To avoid this situation, turn on Character Count so you can always know when you've reached the SMS character limit.

To enable the Character Count setting, Go to Settings>Messages, scroll down to Character Count, and toggle it on.

Now whenever you are composing a message, the number of characters used will appear to the right of the unsent message.

Top image credit: EpicStockMedia/Shutterstock.com

One thing great thing about the iPhone and other iDevices is the ever-improving video recording feature. More and more, smaller design teams and other individual artists are shooting video with iPhones. Of course, shooting on an iPhone or iPad does mean having to shell out extra for accessories to help stabilize your device while shooting. Having witnessed a couple of iPad video shoots myself, I know it can be a process just getting accessory pieces on for a smooth one-take shot. The Horizon app ($1.99) may be a solution to all of that hassle. 

Horizon is essentially an app that lets you record video horizontally without having to place the phone in a horizontal position. Ever. This alone is monumental. It relies on the iPhone's gyroscope, so you can go back and forth between having your phone be vertical or in landscape mode while shooting, and even at various angles in between. The steadiness of shooting is assured even in hectic situations; I gave it a test run at a live show in the midst of an animated crowd, and the resulting video was smooth.

You can also switch between this free-flowing shooting mode and a locked horizontal mode. For those who have concerns about video resolution quality, you can shoot up to 1280 x 720 and 640 x 480 on your rear and front-facing cameras respectively. Another neat feature the app has is the ability to not only choose from eight different filters but to see in real-time how those filters would look applied to your video. And of course, you can choose whether to use flash or not. Evil Window Dog P.C., the makers of Horizon, have gotten quite a bit of buzz since the app's release this January. And they show no signs of stopping when it comes to pushing the envelope on the app's possibilities, as you can see in this video featuring Horizon running on an iPhone 5 while strapped to the spinning wheel of a car: 

There's one or two cons about Horizon that users may find. The first is the preview orientation once you open the app. Some may not be comfortable with a preview window not taking up the entire screen. The other problem is that enabling the constant stabilization does reduce the video frame slightly. These points are minor though when you consider just how revolutionary Horizon is.

It's an app that could not only help to advance the usage of iDevices as video camera and DSLR alternatives with further updates, but it could encourage smartphone makers to think outside the box when developing the video recording features people want right now.

iPhone Life Rating: 4 stars out of 5

What do you do when you're recording a video on your iPhone and a perfect picture-taking moment arises? Do you stop recording? Or do you let the moment go by? If you have an iPhone 5 or later model, you can relax and take the picture while you continue to record your video. Here's how:

When you are recording a video on your iPhone, a shutter button appears to the left of the record button where you usually see a thumbnail of your most recent photo. Tap the shutter button to capture the the photo while your video continues to record.

Top image credit: 1000 Words / Shutterstock.com

Perhaps you didn't attend Apple's Worldwide Developers Conference, either by choice or you didn't win Apple's lottery to earn the privilege of paying for WWDC. Or maybe you were one of the lucky ones to make it to Apple's event. Either way, you will be interested in attending the independent MacTech Conference in Los Angeles, the first week in November.Unlike Apple's show, MacTech is run by programmers, engineers, and other experts who are not on the Apple payroll. That means you get to hear the straight scoop, warts and all. There are certain topics, like programming with Swift, that could benefit from an independent perspective.

All work and no play makes for a boring conference, so don't worry there. Last year, we got up close and personal with the Space Shuttle Endeavor and engineers from NASA. We also had the chance to test drive a $100,000 Tesla Model S. The latest email update from MacTech suggests that this year, attendees can expect more out-of-this-world activities! Even though iPhone Life is a media partner for the MacTech Conference, they're not telling me exactly what is planned. But I'm expecting something pretty magical.  

Here's the text from the organizers' email:

What are we doing this year?

It’s one of the most common questions people are asking us right now about MacTech Conference.

You see, MacTech Conference is not only about learning, but about forming relationships and building networks. MacTech is known for conference activities that not only give you an opportunity to spend time with your peers, but help you get to know new people and expand your network.

As an immersive conference, we'll have you busy from morning until night … having a whole lot of fun in the process.

We’re not ready to give full details on our Wednesday evening event …

… but you now have enough of a hint to guess what we’re up to.

 Be sure to book early to save on the conference price. And if you see me at the conference, be sure to say Hi!

A new Kickstarter campaign is garnering a lot of interest from consumers and tech media alike. The campaign is for a new set of small wireless earbuds simply called Earin. Earin is the brainchild of Swedish designer Olle Linden, who conceived of the device after seeing the opening scenes of Definitely, Maybe starring Ryan Reynolds. In these scenes, Reynolds is walking through New York City wearing wireless earphones. Linden saw a real-life need for this bit of fantasy technology. The opportunity was there; thanks to Beats, the industry is now fixated on earbuds. Earin looks to break the industry mold.

Earin is billed as "the world's smallest wireless earbuds." The tech specs back up that claim: Earin weighs in at 5 grams without the recharging and storage capsule, which adds another 25 grams. So you're talking about earbuds that barely weigh an ounce. There's a focus on eliminating parts and features that aren't necessary, hence the lack of wires and microphone. Earin utilizes Bluetooth technology via AptX and is compatible with both the 3.0 and 4.0 versions. You can use Earin earbuds for up to three hours on a full charge. The recharging capsule will apparently double that time if the earbuds are inside. The size dimensions stand in at 14 milimeters by 20 milimeters. Fearful of losing the earbuds as you go about your day or when you're exercising? The inventors have created a "'concha lock" that helps secure the Earin snugly in place. The major selling point of the Earin however lies in the high emphasis on superior audio quality. The designers underwent a year long process of coming up with speakers that rely on armature technology that is also found in hearing aids and other in-ear devices. Combined with the AptX, greater audio performance is delivered. Earin designers also created a unique Bluetooth chip to handle the demands that audio earbuds would encounter without wired connections.

As a concept, Earin is outstanding. And now that it is in fundraising, it is captivating many. The aforementioned Kickstartercampaign has already earned close to one million U.S. dollars, with a month still left to go. That's almost triple the initial goal of $304,000. Earin will be available to backers first in January 2015, then to the public.

Summer is here, and that means festival season. I've had to demonstrate my apps at various outdoor events this week. Making sure I have power where there are no outlets is always a concern. I also have to bring a stand or case for my iPad for display purposes. This makes the Kanex GoPowerPack ideal, as it not only offers up to 11,000 mAh of power, it has a slide out stand built in! I can display my iPad at a convenient angle and keep it running for hours on end. A 6,000 mAh model is also offered. 

Like most of Kanex' products, the GoPowerPack comes in a simple, white, rounded design. It blends in with the background and lets the iPad do the talking. Speaking of talking, I can charge my iPhone using the second 1.0 Amp port in addition to the 2.1 Amp port required for an iPad! Of course you could charge most anything, not just Apple products, as long as you provide the right USB cables.

Kanex offers a broad line of iOS and Mac accessories. If you have a lot of iPads to charge, consider their Sydney multi-charge station, which could be great for schools. Stay tuned for my review of their Multiport USB 3.0 dock!

Do you have an idea for an app but lack the programming knowledge to begin building it? In this weekly blog series, How to Unleash Your Inner App Developer, I will take you, the non-programmer, step-by-step through the process of creating apps for the iPhone, iPod touch, and iPad. Join me each week on this adventure, and you will experience how much fun turning your ideas into reality can be! This is Part 14 of the series. If you are just getting started now, check out the beginning of the series here. (This post has been updated to iOS 7.1.)

Core Data is the technology that allows you to store and retrieve information on an iOS device. Although it is an advanced technology often difficult to grasp, my goal in this post is to simplify Core Data so it can be easily used by beginners.

I'll start out by giving you the big picture of how Cora Data works. Afterward, we'll take a look at Apple's default implementation of Core Data, and then I'll show you how we can easily improve on it.

Core Data and Entities

As mentioned in my previous post, your app's data usually takes the form of entities, which are the Model in the Model-View-Controller design pattern. An entity represents an object in the real world and has attributes that model a real-world object. For example, the main purpose of the iAppsReview app that we have been building is to give users a place to write reviews of apps. When modeling entities for this app, you can create a ReviewEntity that describes a real-world review. You can create an AppCategoryEntity that describes the different categories you can assign to an app, and you can even create a UserEntity to describe the person using your app.

1. Model, or define the entities in an entity data model;
2. Use Xcode to generate an entity class from each entity in the data model;
3. Add code to your app that creates entity objects from the entity classes and manipulates them.

Let's find out more about each of these steps.

Modeling Entities With an Entity Data Model

Xcode provides a visual tool called an entity data model (or just "data model" for short) that you can use to model your app's entities. For example, check out the ReviewEntity shown on the left side of the entity data model shown in Figure 1.

Figure 1 - An entity data model

This entity has attributes such as appName, comments, image, rating, category and reviewer. As you can see, there also is an AppCategoryEntity and a UserEntity that possess their own attributes and each have a relationship to the ReviewEntity.

Generating Entity Classes From an Entity Data Model

The entities that you define in an entity data model are not Objective-C classes. They are simply a representation of your entities that are defined in a diagram. However, you really do need entity classes in your app, so after defining entities in the entity data model, your next step is to create an Objective-C class from each entity in the model as shown in Figure 2.

Figure 2 - You need to generate entity classes from the entities in the data model.

Fortunately, Xcode can do this for you in one easy step, as you will see.

Creating Entity Objects

Once you have generated classes from your entities, you can then add code to your app that creates objects from these entity classes and manipulates them.

For example, as shown in Figure 3, in response to a user writing a review, you can create a new ReviewEntity object and store the category, rating, app name, comments, and image into the properties of the object.

Figure 3 - You can save user-interface control values into properties of an entity object.

Saving Entity Objects in a Database

After creating an entity object and storing information in its various properties, how do you save the entity so that the next time you open up the app you can see the review again? This is where Core Data comes to the rescue.
 

Core Data saves your entities in a database. Most non-programmers are familiar with the term "database" and at least have a vague notion that it's a place where your data is stored and from which it can be retrieved at a later date. Let's dive in and find out more about the structure of a database.

Behind the scenes, Core Data creates a database for your app and then adds a table in the database for each of the app's entities as shown in Figure 4. Notice Core Data creates a table with the same name as your entity but with a "Z" prefix.

Figure 4 - Core Data stores your entities in a database.

A table can contain multiple data records of the same type. So, for example, all of your reviews are stored in the ZREVIEWENTITY table, all app categories are stored in the ZAPPCATEGORYENTITY table, and user information is stored in the ZUSERENTITY table.

Core Data creates a column in the table for each property on the associated entity. For example, as shown in Figure 5, the ZAPPCATEGORYENTITY table has two columns, categoryID and name, one for each attribute in AppCategoryEntity.

Figure 5 - Core Data creates a table column for each entity property.

In Figure 5, there are three records in the table, also known as rows. Every time you save a new AppCategoryEntity object, a new record is added to the ZAPPCATEGORYENTITY table.

The magic, which Core Data performs in converting your entities into rows of data in a data table, is known as object-relational mapping (ORM). It's called this because Core Data converts your entity objects into data stored in a relational database (called such because the tables in a database can have relationships between them). Using Core Data spares you the burden of learning the intricacies of database programming. You can save, retrieve, update, and delete entities without learning a database programming language!

The database Apple has chosen to use on iOS devices is SQLite. The SQLite database is compact and is one of the most widely-deployed databases in the world, used in other popular systems such as Google's Android, Microsoft's Windows Phone 8, RIM's Blackberry and Nokia's Maemo. For more information on SQLite, check out this link.

Working With the Object Context

Core Data is comprised of a set of classes in the Cocoa Touch Framework. The primary Core Data class you will work with is NSManagedObjectContext. You send messages to an instance of the object context to create, retrieve, insert, update, and delete your app's entities. The object context keeps track of all the entities you have retrieved or created as well as any changes you have made to the entities.

The object context offers an all-or-nothing approach to updating your entities. When you send it a saveEntities message, it saves all the entities that have changed. It doesn't offer the option to save changes to one or more select entities.

Behind the scenes, the object context uses a persistent store coordinator object (an instance of the NSPersistentCoordinater class), which it uses to communicate with the SQLite database. The persistent store coordinator knows the name and location of the database. It uses a managed object model (an instance of NSManagedObjectModel) that knows about all the entities in the data model and their relationships.

Out-of-the-Box Core Data

The out-of-the-box Core Data architecture leaves something to be desired. To show you what I mean, Figure 6 provides an overview of the default architecture you get when you create a new project in Xcode and select the Use Core Data option.

Figure 6 - The out-of-the-box Core Data Architecture

As you can see, the AppDelegate object stores a reference to a Managed Object Context. The object context uses a Persistent Store Coordinator, which in turn uses a Managed Object Model to retrieve and update entities from the SQLite database.

In this default architecture, a single object context attached to the AppDelegate is referenced by all view controllers in your app. As each view controller is created, a reference to the AppDelegate's object context is passed to the controller, which it then stores in its own managedObjectContext property. Apple recommends that you put code in your view controllers that sends messages to the object context to create, retrieve, update, and delete entities.

The problem with this approach is that it breaks the rule of separating your app into these distinct sections:

• User Interface
• Core Logic
• Data

The more formal way of separating sections is into Model, View, and Controller.

As you learned in my previous post, the view controller is part of the user interface. The only code that belongs in the view controller is code that has something to do with the user interface. Therefore, code that is used to retrieve, manipulate, and update entities does not belong in the view controller.

This isn't just ivory-tower thinking. Putting your entity manipulation code in the user interface has practical implications that can make it difficult to extend your app in the future. For example, if you enhance your app at a later date to save and retrieve entities from the web, you're going to have to find all the places that use this Core Data logic and change them.

What you need is a place to put this code that encapsulates or hides it from the user interface.

Improved Core Data Model

So where should you put your entity manipulation code? You should put it in a business controller class!

 

Figure 7 shows an improved Core Data model where the Managed Object Context is attached to a Business Controller, and the code to retrieve and save entities is stored in the methods of the Business Controller.

 

Figure 7 - An improved Core Data Architecture

 

What are the benefits to this approach?

 

First of all, it encapsulates the entity manipulation code within the business controller. You can now pass messages from within the view controller to the business controller to retrieve and update entities, and the mechanics of how those entities are retrieved and updated are hidden from the user interface. This means you can change where and how entities are stored at a later date without affecting the user interface.

 

Another benefit of this model is reusability. When you place your entity retrieval, manipulation, and update code in the methods of a business controller, you can call those same methods from multiple view controllers and even from multiple apps. This is what we call reusability!

 

There is another benefit to this architecture that may not be readily apparent. As I mentioned earlier, an object context is an all-or-nothing proposition. When you ask it to save changes, it saves changes to all entities in your app. Allowing each business controller to have its own object context allows finer control over when and how entities are saved to the database. You can have a Customer business controller and an Order business controller, each with their own object context. This allows you to retrieve and update CustomerEntity objects without affecting OrderEntity objects.

 

However, there are times when you do want or need multiple business controllers to share the same object context. As you shall see in a future post, this architecture also allows you to do just that.

Conclusion

We covered a lot of conceptual ground in this post. You have learned about entity data models, databases with their tables, columns, rows, and how Core Data handles much of the heavy lifting of manipulating entities for you. In next week's post, we will apply what you have learned this week and add Core Data to the iAppsReview project.

<<Previous         Next>>