Photographers can’t professionally fine-tune an image of a mountainous landscape’s foreground and background on a tiny little iPhone screen. A data scientist can’t layout graphs, matrices, vectors, and spreadsheets on a tiny little iPhone screen. A customer service representative can’t troubleshoot a technology problem without searching through several device schematics, handle several different calls at once, be on the phone with one customer, be texting with another customer, and looking at a user’s guide that shows which buttons and switches do what things on a tiny little phone screen. Can you imagine trying to design, read, write, and debug code, and layout your UI with Xcode on an iPhone? (I could on a large iPad or MacBook, but not a phone).
My original article — Introduction to HealthKit with Core Bluetooth — was published on appcoda.com.
In a previous tutorial, I discussed the technology, applications, and benefits of Apple’s
Core Bluetooth framework. I showed you how to build an app that wirelessly connected to a Bluetooth® heart rate monitor (HRM) — a small, portable, and “wearable” device. My sample app’s code read heart rate data from the HRM, but it didn’t do anything with the heart rate data except display it in real-time on an iPhone’s screen. While edifying and interesting, there are already a bazillion apps in the App Store that can read heart rate data, and other wearable data, using
Core Bluetooth. What about doing something interesting with that data, like analyzing it, deriving value-added and meaningful results from it, and sharing it with researchers? That’s where Apple’s
HealthKit framework shines. Please download the Xcode 9 project written is Swift 4 so you can follow along with my discussion.
NOTE: The second installment of this article, “Controlling chaos: Error Handling in Swift 4 with do, try, catch, defer, throw, throws, Error, and NSError,”, has just been released.
In this tutorial, the first in a series of tutorials, we’re going to discuss the arduous topic of looking for unexpected values, events, and conditions that arise during program execution, using a technique I like to call “error checking.” Today, I’ll concentrate on the reasons why you should check for errors. I’ll mention a number of techniques I use but leave detailed discussion of those techniques and sample code to subsequent articles. The purpose of this tutorial is to convince you to make use of error checking in your apps. You ignore errors at your own dire peril. This is sink or swim. If you put out a crappy app, no one’s going to use it because you’ll get a bad reputation at Internet speed, and employers/customers will be more than happy to leave you behind forever for other app developers who aren’t too lazy to write quality code.
The original article – Working with Core Bluetooth in iOS 11 – was published on appcoda.com.
As iOS developers, we’re very aware that humans love connectivity. Obviously, we love to communicate with each other using wireless devices. More recently, we’ve come expect that we can communicate with what once were considered standalone, ordinary devices. We’ve come to love, even expect, that some of those wireless devices can gather and analyze data about ourselves (usually “wearables”). So many devices have become intrinsic parts of our lives that we’ve coined a now commonly-used phrase, the “Internet of Things” or “IoT.” There are now billions of wireless, communicable devices on the planet. In this tutorial, we’re going to focus on just one segment of the IoT: Bluetooth®.
I’ll explain the essential concepts behind Bluetooth® technology, show you how getting proficient in Bluetooth® software development presents you with a tremendous career opportunity, remind you that you can’t distribute an app that uses Bluetooth® without determining if you need to go through “qualification,” provide you with an overview of Apple’s
Core Bluetooth framework (see also here), and finally, walk you through the development of an iOS app in Swift 4 that monitors a person’s heart rate via
Core Bluetooth via a Bluetooth® device.
It can be good to be an iOS app developer, but not easy to be a great one (we’ll talk about that later in this article). There are many opportunities for app programmers looking to work as employees for companies. There are plenty of opportunities for developers who prefer freelancing. It’s frustrating, trying to come up with novel apps that generate any significant revenue, when it seems that every idea under the sun has already been turned into an app by “someone else.” Apple continues to push out buggy versions of iOS, the iOS SDK, and Xcode — especially in early versions of new products. Yet most of us would agree that Apple’s hardware and software, even their development tools, continue to be elegant and cutting edge. It’s hard to argue with the bottom line as “Apple App Store developers raked in $20 billion in 2016, up 40% year over year,” according to an article from CNBC: