wwdc cook federighi ive

Once again, it’s time for WWDC 2015, the 2015 edition of Apple’s Worldwide Developer Conference, where software developers who write applications for iOS and Mac OS get together in San Francisco to find out what’s coming up for Apple’s platforms. While the conference itself runs for the entire week and is aimed generally at programmers, it kicks off with a very layperson-friendly, attention-grabbing keynote.

stability and bug fixes

Stability and bug fixes…get it?

If you’ve been using iOS 7 and 8 after having used iOS 6, you may have some concerns about the upcoming version. With each successive release, the operating system appears to have become a little less reliable, a little more buggy, a little less performant. It could be because Apple no longer has a raging perfectionist like Steve Jobs at the helm, but it could also be that a feature race is a natural outcome of the fact that the smartphone war is down to two superpowers. There will be some new features announced, but don’t expect something mind-blowing along the lines of a Steve Jobs-esque “one more thing…” announcement. Personally, I don’t mind that the both iOS and Android are slowing down and cleaning up what’s already been implemented instead of rushing forward to create the next new thing, and I think that many users feel the same.

tim cook onstage

How to watch the WWDC 2015 keynote livestream

Want to see the livestream video of the WWDC keynote? You’ll need to watch it on an Apple platform:

  • On Apple desktop computers and laptops: You’ll need to run OS X 10.8.5 or later, and you can view it only on the Safari browser (Steve Jobs may no longer be with us, but his control-freakery lives on.). If you’ve got those, go here to see the livestream. 
  • On Apple phones and tablets: You’ll need an iOS device running iOS 6 or later, and if you do, go here to see the livestream.
  • On the Apple TV set-top box: There’ll be a dedicated channel for the livestream, and I’m sure if you turn it on, you’ll be told how to get to it.

Where to catch the WWDC 2015 keynote liveblogs

A number of sites will have their reporters in the WWDC keynote audience, liveblogging it as it happens. Unlike the video livestream, you’ll be able to catch these on any computing platform that supports web browsing:

this article also appears in the GSG blog

{ 2 comments }

You can never have too many smartphones

by Joey deVilla on June 7, 2015

never too many smartphones

Found via Catsmob. Click the photo to see it at full size.

I’m sure at least one of these is being used as a GPS.

{ 0 comments }

My favorite HTTP status code joke of the moment

by Joey deVilla on June 6, 2015

404 not found

Found via AcidCow. Click the photo to see the source.

{ 0 comments }

T-Mobile and Dish Networks are discussing a merger

dish network t-mobile cake topper

The Wall Street Journal reports that T-Mobile is in talks to merge with Dish Network, a deal in which T-Mobile CEO John Legere would be the CEO of the newly-combined organization. This move would offer the following benefits to each participant:

  • T-Mobile would gain Dish Network’s billions of dollars of largely unused wireless licenses, giving it the ability to expand the capacity of its network.
  • Dish Network would gain a solid broadband internet service, giving them access to the “second screen”, which broadcasters are relying on increasingly as their audience moves to the internet.

T-Mobile’s “Uncarrier” strategy, which has included data giveaways, price cuts, rollover offers, and the occasional CEO antics, has helped them grow their customer base at record rates, but they still remain the smallest of the “Big Four” mobile carriers. Dish Network’s wireless licenses, which were bought mostly as a gamble without any real plan for using them, would give T-Mobile the ability to expand their coverage and lure more customers away from its competitors.

Smallest and scrappiest

In 2013, both Dish Network and T-Mobile’s parent company, the Japanese telecom Softbank, attempted to join with Sprint. This merger between the two one-time rivals mirrors the AT&T/DirecTV and the Charter Communications/Time Warner Cable deals, a fact that wasn’t lost on Ina Fried when she wrote “a deal between Dish and T-Mobile is akin to two people who hook up because they are the last ones left in the bar at closing time.”

If the deal goes through, T-Mobile could be well-positioned to take the number 3 slot from Sprint. Keep in mind that this isn’t a done deal, and it’s being made between two rather mercurial CEOs.

For more on the merger, see:

Losing the Signal: Interesting reading on the rise and fall of BlackBerry

losing the signal

In 2015, it’s all too easy to dismiss BlackBerry (or RIM, as they were originally named) as merely a casualty of  the smartphone revolution, but to do so is to forget that they started that revolution in the first place. Before the iPhone and Android, there was the BlackBerry, the product brought to life by co-CEOs Mike Lazaridis, the electronics tinkerer who foresaw the possibilities that would come from merging computing and wireless technologies, and Jim Balsillie, the businessman with grand ambitions to become a figure like Bill Gates or Steve Jobs. It was the BlackBerry that tore email away from the desktop and put it in our pockets, got North American businesspeople hooked on text messaging, and introduced us to the habit of continually staring at a glowing screen in our palms.

new yorker smartphone cover

Losing the Signal is a newly-released book written by Canadian reporters Jacquie McNish and Sean Silcoff that does far more than tell the story that most of us know about BlackBerry — their fall from being the must-have smartphone after the iPhone’s announcement and release in 2007. It tells the story of RIM’s early days and the challenges they overcame, from the limits of the technology and cellular networks of the time to how other companies tried to stifle them by withholding payments for orders. More importantly, it tells the stories of two very different co-CEOs, and of their partnership, both as friends and in business.

According to co-author Sean Silcoff, it took dozens of hours of personal interviews with Balsillie and Lazaridis at their homes to get them to “open up”; on one particular day, he followed a six-hour session with Balsillie by another five with Lazaridis. Their efforts paid off; Losing the Signal is a fascinating book that’s hard to put down; I’ve been getting my readings in during lunch, at the gym, and any time I can sneak in during the day. If you’re looking for a summer read that’s both substantive and fascinating, I highly recommend picking up Losing the Signal.

For more on Losing the Signal, see:

Coming soon: the next versions of Android and iOS

google io apple wwdc

Summer is coming, and along with the warm weather and sunshine (well, we’re hoping they’re coming) are previews of the upcoming versions of Apple’s and Google’s mobile operating systems. Both OS vendors hold conferences for software developers around the beginning of summer; Google recently concluded their Google I/O conference, and Apple’s WWDC (Worldwide Developer Conference) will start on June 8th. These conferences are where both companies show sneak previews of their upcoming mobile OSs.

Android M made its first public appearance at Google I/O. According to Sundar Pincai, Google’s senior VP of products, this upcoming version of Android features a “back to basics” approach. While continuing with the visual aesthetic that premiered with Android L (better known as “Lollipop”), this upcoming version’s focus is more on usability and stability rather than flashy new features. Among the additions that you’ll find in Android M when it comes out (presumably later this year) are:

  • An easier and better way for you to grant permissions to apps to access certain sensitive phone features such as your Contacts list, camera, microphone, and current location,
  • an improved web experience with support for automatic sign-in, saved passwords, autofill, and other things we’ve grown accustomed to with our desktop browsers,
  • support for fingerprint scanners, not just to unlock your phone, but also to make in-person and online purchases,
  • mobile payments through Android Pay, Google’s answer to Apple Pay,
  • better power management for improved battery life, and
  • automatic backup of data for apps whose supporting data is 25 megabytes (that’s some pictures, but a lot of text) or smaller

We expect that iOS 9 will be announced at WWDC, as is their habit. Those of you who’ve been less than pleased with the problems that came with the upgrade from iOS 7 to iOS 8 will be happy to hear that a large part of the iOS 9 development effort is supposed to be about making the operating system more stable, optimized and reliable. As with Android, the upcoming version of iOS is less about adding flashy new features to draw in new customers and more about making the existing ones better in order to make their current user base happy. As with Android M, we expect that iOS 9 will see general release later this year.

For more on the upcoming versions of Android and iOS, see:

this article also appears in the GSG blog

this article also appears on the enterprise mobile blog

{ 0 comments }

tapping iphone

A quick recap

A couple of weeks ago, I posted an article that showed how to program an iOS text field that takes only numeric input or specific characters with a maximum length in Swift.

While that article focused on constraining what the user could enter into a text field, its example app has a couple of UI features that you’ll find in many apps:

  • It dismisses the keyboard when the user taps the Return key, and
  • it dismisses the keyboard when the user taps on the background.

Last week, I covered implementing the first of these two features in the article titled How to dismiss the iOS keyboard when the user taps the “Return” key in Swift. The one major takeaway from that article was that the way to dismiss the iOS keyboard after the user is editing a text field is to make the text field resign its role as first responder.

In that article, we dismissed the keyboard when the user tapped the Return key by doing the following:

  • We made the view controller adopt the UITextFieldDelegate protocol,
  • We made that same view controller the delegate for all text fields contained within its view, and
  • We implemented the delegate method textFieldShouldReturn(textField: UITextField), which is called when the Return key is tapped, and provides us a reference to the text field that was being edited when user tapped it:

In this article, we’ll look at how to dismiss the keyboard when the user touches the view in the background while editing a text field.

Dismissing the keyboard when you don’t know which text field is the first responder, but know which view the text field is in

The textFieldShouldReturn(textField: UITextField) method can be implemented to resign the first responder for a specific text field because a reference to that specific text field is passed to it. Unfortunately, we don’t get that information when the user taps on the view, and there’s no method or property in UIView that tells us which of the text field contained within it is the first responder.

In the Apress book Beginning iPhone Development with Swift, they take the “brute force” approach and implement a method that looks like this:

It works, but you need to update the method whenever you add a text field to or remove a text field from the view.

A more flexible approach is to loop through the contents of the view’s subviews property (an array of AnyObject), calling the resignFirstResponder() method for any text fields encountered along the way. I’ve seen code similar to this:

It works — as long as all the text fields in your view are immediate subviews of the view. If your view hierarchy runs deeper, you’ll have to write more code to deal with subviews or subviews. I’ll leave that as an exercise for the reader.

It turns out that there’s a simple and effective way to dismiss the keyboard for a view without knowing which text field is the first responder: call the view’s endEditing(_:) method. This method scours the view’s subview hierarchy, find the text field that is currently the first responder and asks it to resign that status. If its parameter is set to true, it forgoes the pleasantry of asking the text field to resign as first responder and simply makes it resign. If we use this method, our userTappedBackground method becomes very short and sweet:

Now that we have a method that dismisses the keyboard no matter which text field is the first responder, we need to hook it up to an event that gets fired whenever the user taps on the view.

Responding to taps on the view

These next steps will show you how to use Interface Builder to change a view so that it can respond to events, and then connect that view to the userTappedBackground method we just created.

01

1. Go to the storyboard and select the view.

2. Switch to the Identity Inspector. You can do this by either:

  • Clicking on the Identity Inspector icon (shown beside the number 2 in the screenshot above; I think the icon is meant to look like photo ID) in the Inspector Bar at the top of Xcode’s Utilities Area, or
  • Pressing command-option-3 on your keyboard.

3. In the Identity Inspector’s Custom Class section, you’ll find the Class drop-down menu. It indicates the underlying class of any object in the storyboard, and it also lets you change it. If you have the view selected, the Class drop-down menu will display UIView. We’ll change this in a moment, but let’s take a quick detour first.

02

4. With the view still selected, switch to the Connections Inspector. You can do this by either:

  • Clicking on the Connections Inspector icon (indicated by the number 4 in the screenshot above) in the Inspector Bar at the top of Xcode’s Utilities Area, or
  • Pressing command-option-6 on your keyboard.

5. Take a look at the available connections for the view. You can make a couple of different of kinds of connections, but none of them are for events. We need to make event connections available to the view, which we’ll do in the next few steps.

03

6. Switch back to the Identity Inspector.

7. Make sure that the view is still selected.

8. Change the value in the Class drop-down from UIView to UIControl. This changes the view’s underlying class, as you may have guessed, from UIView to UIControl. We’ll see the effect of this change in a moment…

04

9. With the view still selected, switch to the Connections Inspector.

10. Make a note of the available connections for the view. Since the underlying class for the view is now UIControl, it has UIControl‘s connections available to it, which include events.

We want to dismiss the keyboard as soon as the view gets a Touch Down event. We use this event rather than Touch Up Inside (the one we typically use for buttons) because we want to dismiss the keyboard as soon as the user taps the view without first waiting for him/her to release or move his/her finger.

5

11. Drag from the Touch Down event to the View Controller icon above the view.

12. A list of action methods in the view controller (any method prefaced with @IBAction is an action method) will appear. Select userTappedBackground:.

6

13. If you look at the Identity Inspector now, you’ll see that the Touch Down event is now connected to the view controller’s userTappedBackground method, and when you run the app, tapping on the view dismisses the keyboard.

Bonus: Dismissing the keyboard when you don’t even know which view the text field is in

There may come a time when you need to dismiss the keyboard from code that:

  • doesn’t have a reference to the text field that’s currently the first responder and
  • doesn’t even have a reference to the view that contains that text field.

In such a case, use this line of code:

Here’s what happens in this line:

  • UIApplication.sharedApplication() gets a reference to the instance of the app itself.
  • sendAction(_:to:from:forEvent:) sends an action message to a target object within the app. If the target (the to: parameter) is nil, the message — resignFirstResponder in this case — gets sent to whatever object in the app is currently the first responder.

My guess is that this approach is more computationally heavy that calling a view’s endEditing(_:) method, so use that if you have a reference to the view, and use the approach above when you don’t.

Resources

zip file iconYou can see this code in action by downloading the zipped project files for the demo project, ConstrainedTextFieldDemo [83K Xcode project and associated files, zipped].

{ 1 comment }

What’s cramming?

cramming

Cramming is the very apt name for a form of fraud where third parties unauthorized charges are added to your wireline, wireless, or bundled services telecom bills. Crammers rely on the combination of telecom bills being so confusing and making sure that the charges they add — often with vague, yet plausible-sounding names — are small enough not to raise suspicion. The FCC (Federal Communications Commission) says that cramming affects tens of millions of household in the U.S., and a Senate Commerce Committee investigation released a report in 2011 that said that cramming costs U.S. consumers $2 billion a year.

The FCC’s web page on cramming provides examples of what these unapproved charges can look like:

  • Charges for services that are explained on your telephone bill in general terms such as “service fee,”  “service charge,” “other fees,” “voicemail,” “mail server,” “calling plan” and “membership.”
  • Charges that are added to your telephone bill every month without a clear explanation of the services provided – such as a “monthly fee” or “minimum monthly usage fee.”
  • Charges for specific services or products you may not have authorized, like ringtones, cell phone wallpaper, or “premium” text messages about sports scores, celebrity gossip, flirting tips or daily horoscopes.

Cramming came about when telecom carriers saw an opportunity to increase their profits by acting like credit cards. They now allow third parties to charge customers through their telecom bills, treating their phone numbers like credit card numbers, and they collect a small percentage of the transaction. While convenient for customers and lucrative for carriers, this introduces a number of opportunities for fraud. While credit card numbers are treated as confidential, phone numbers are published openly; some crammers have made money simply by charging phone numbers obtained from directories while others incentivize people into divulging their phone numbers through fake contests and offers.

The key to protecting yourself from cramming is to pay close attention to your phone bill. Review it as closely as you’d review your credit card statement, and ask yourself these questions:

  • Are there any names of companies on your phone bill that you don’t recognize?
  • Does your bill include charges that can’t be accounted for — calls you didn’t make or services you didn’t sign up for?
  • Are there small “mystery charges”, typically less than $10, and often as little as $1, with non-descriptive names that don’t seem to be tied to any service that you’ve signed up for?
  • Are the rates and line items that appear on your bill consistent with the rates and line items that you were quoted?

If you’re thinking about signing up for a service that charges you through your phone bill, be sure to read the fine print. If you’re thinking of signing up for a service that texts you things like “love tips”, “fun facts” and “celebrity gossip”, think again: last year, a crammer by the name of Andrew Bachman was found to be cramming users at $9.99 a month for these services without their approval.

You should also keep a record of all services that you subscribe to that charge via your phone bill.

A settlement for Sprint and Verizon customers

hands holding smartphones

The FCC, along with the CFPB (Consumer Financial Protection Bureau) and state attorneys general have been pursuing cramming activity in telecom bills, charging the third parties involved in cramming and issuing over $350 million in penalties to the “Big Four” carriers, more than $250 million of which was returned to affected customers.

On May 12, 2015, it was announced that…

  • Sprint Corporation will pay $68 million and
  • Verizon will pay $90 million

to settle investigations that showed that they were party to third parties billing customers hundreds of millions of dollars in unauthorized third-party premium text-messaging services, a.k.a. cramming. $120 million of the sum of their payments will be repaid to customers, and you may be due for some of that payback! If you’ve been a customer of Sprint, Sprint’s prepaid subsidiaries (Virgin Mobile, Boost Mobile, Sprint prepaid, and Assurance Wireless) or Verizon in the past five years, you may be eligible:

  • If you might be an eligible Sprint (or subsidiary) customer, visit their site at sprintrefundpsms.com or call the Sprint settlement hotline 1- 877-389-8787. Sprint customers should use the claims form in the FAQ section, and subscribers to Sprint’s prepaid subsidiaries (once again, Virgin Mobile, Boost Mobile, Sprint prepaid, and Assurance Wireless) can file for a one-time $7 refund.
  • If you might be an eligible Verizon customer, visit their site at CFPBSettlementVerizon.com or call the Verizon settlement hotline at 1-888-726-7063.

this article also appears in the GSG blog

{ 0 comments }

dismissing ios keyboard with return key

A quick recap

A couple of weeks ago, I posted an article that showed how to program an iOS text field that takes only numeric input or specific characters with a maximum length in Swift.

It covered the Delegate pattern (something you’ll use often in iOS development), introduced the UITextFieldDelegate protocol, and showed you how to use one of its methods, textField(_:shouldChangeCharactersInRange: replacementString:), to intercept the characters that the user inputs into text fields.

zip file iconThe article included the Xcode project files for the featured app, ConstrainedTextFieldDemo. You can download it here [83K Xcode project and associated files, zipped]. When you run it, you’ll the screen pictured above, with text fields constrained so that they’d accept only characters from a specified set, or reject characters from a specified set.

Undocumented feature #1: Dismissing the keyboard when the user taps the “Return” key

One of the features that was included in the app but discussed only in passing was the dismissal of the keyboard when the user tapped the Return key. While this is convenient for the user, it’s not iOS’ default behavior. You have to watch for the event where the user taps the Return key, and then respond accordingly.

The UITextFieldDelegate protocol’s textFieldShouldReturn(textField: UITextField) method is called whenever the user taps the Return key while editing a text field. It accepts a single parameter, textField, which is a reference to the text field the user was editing when s/he tapped the Return key. It returns a bool — true if the text field should implement its default behavior for the Return key; otherwise, false otherwise. It’s where you should place code to intercept the Return key event.

What should that code be? If you remember only one thing from this article, let it be this:

The way to dismiss the iOS keyboard after the user is editing a text field is to make the text field resign its role as first responder.

What’s the first responder, you ask?

  • The short answer is that the UI object that currently has the first responder role in iOS is roughly analogous to the UI object that currently has the focus in other systems (such as Android, HTML, and .NET).
  • The long answer is that the first responder is the first view in the responder chain to receive many events. Most of the time, it’s the view in a window that an app deems best suited for handling an event. You can find out more by reading these Apple documents: Event Delivery: The Responder Chain and their Responder object documentation.

Take a look at code in the example app in my earlier article, particularly ViewController.swift.

Combining the textFieldShouldReturn(textField: UITextField) method and The One Thing You Should Remember From This Article, we get this method definition:

After all that preamble, the method itself seems pretty short and anticlimactic. This method lives in the ViewController class, which has adopted the UITextViewDelegate protocol…

…and in its viewDidLoad() method, it declared itself as the delegate of every text field in the corresponding view:

All this setup means that whenever the user edits any of the text fields in the view — whether it’s vowelsOnlyTextFieldnoVowelsTextFielddigitsOnlyTextFieldnumericOnlyTextField, or positiveIntegersOnlyTextField — and then hits the Return key, the textFieldShouldReturn(textField: UITextField) method gets called.

And when the textFieldShouldReturn(textField: UITextField) method, it does just two things:

  • It tells the text field to resign its first responder role (by invoking its resignFirstResponder() method). In this application, we want the keyboard to disappear when the user taps the Return key regardless of the text field, so we don’t bother trying to identify the text field; we simple call textField.resignFirstResponder().
  • Aside from dismissing the keyboard, we want the Return key to function as it normally would, so we have the method return true, which states that text field should implement its default behavior.

Resources

zip file iconOnce again, here are the zipped project files for the demo project, ConstrainedTextFieldDemo [83K Xcode project and associated files, zipped].

 

 

{ 1 comment }