iBuddies Retired (2010-2016)

iBuddies was the first app I wrote and published for the iOS platform. While ridiculous, it served an important function. It introduced me to the platform and enabled my goal of making an app available in the store. Publishing an app was the benchmark that made the experience real. It demonstrated I knew the ecosystem well enough to turn a concept into a published app, and it paved the way for the apps that came later.

The premise behind iBuddies was to enable iOS devices to come alive and have an out loud conversation with one another. They would learn each other’s name, comment on their life experiences of being iPads or iPhones, and gossip about how they are treated by their owners.

There were four different personas to choose from, which changed their appearance, voice, and some of the things they said. At times one device might complement or insult another device, which lead to it responding in like.

The idea for it came about while hanging with friends one night. We all had our iPhones on the table and we thought it would be cool if they could chat with each other, kind of like how the original Furbi’s would spout gibberish at each other if two or more were present.

At the time, I had just started learning about Objective-C and the Xcode development environment, which was a tedious exercise without an app idea in mind. The talking phones concept was unique and seemed fun to try. It was also compelling because It would expose me to a variety of APIs, like the one used for peer to peer Bluetooth and Wi-Fi communication.

At the end of iBuddies’ run in the iTunes App Store, it was suffering from the full effects of neglect. With my attention directed to other projects, it hadn’t received an update in over 5 years and it was not looking good on iOS 10 and current generation devices. I had ideas for refreshing it, but ultimately decided my time was better spent on a new project. With that, iBuddies was retired from the app store as of September 2016. Gone, but not forgotten. At least not by me.

Tactics for Using Auto Layout Effectively

Auto Layout and Size Classes enable apps to gracefully conform to varied screen sizes and orientations. It future proofs your apps, so they render correctly in new contexts. Unfortunately, these technologies are also a continued source of frustration for many developers learning Apple’s iOS platform. Some even give up on them entirely, by choosing to stick with struts and springs, or by defining their layouts programmatically. Ignoring it is quickly becoming a less viable option for developers wanting to produce polished user interfaces that look great on the latest devices.

iPad multitasking, introduced with iOS 9, is a good example of a feature that is reliant on Auto Layout and Size Classes. They are needed to properly conform an app to the size constraints of a split screen. In many cases, apps effectively leveraging Auto Layout are ready to work in a multitasking environment. Enabling multitasking for apps using manual layouts often produces ugly results.

I resisted Auto Layout for a time because it was a struggle to create even basic layouts using it. Eventually, I identified the mistakes that caused me endless grief and I developed tactics that achieved the desired results. With these practices, I’ve since found Auto Layout to be a faster and more expressive method for building user interfaces. By sharing my tactics, I hope others may avoid hours of frustration and learn to appreciate Auto Layout and Size Classes for the powerful design tools they are.


Segment Your Interfaces into Proportional Regions

Before working with the Interface Builder, it is useful to sketch out an interface on paper or in a wireframe tool. This helps in determining which content should be emphasized most on each screen. The most important content will generally take up the most screen space, allowing you to arrange your content into proportional regions by their relative importance. Implementing a proportional layout is easily accomplished using basic constraints.

Such constraints are created by setting the width or height of a view to the match the corresponding dimension of the super view and changing the constraint’s multiplier to a fractional value. For example, setting the multiplier to 0.5 guarantees a dimension will always be half the size of the parent’s corresponding dimension.

Minimize Constraints

A layout can often be expressed several different ways using constraints. Strive to implement your interfaces using the fewest constraints possible. Using fewer constraints reduces complexity, making debugging easier and leaving less to go wrong.

Create Base Value Constraints

The overall number of constraints a layout requires can be kept minimal by defining constraints applicable to multiple sizes classes. This is because similar constraints won’t need to be established for each context. These constraints take advantage of the Base Value classes that include “Any”. “Any” is a wild card that enables a constraint for both Regular and Compact displays. “Any x Any” is the most general setting. Constraints created under this context are enabled for all Size Classes.

When designing your layout, take note of view relationships that are consistent across devices and screen orientations. Consistent relationships are great candidates for base value constraints.

Design for Final Value Classes

When creating your layout, it is tempting to try and make it look perfect for all Size Classes, including Base Value classes. There is no point in doing this because only the Final Values map to actual devices. New developers sometimes fall into the trap of trying to make the default “Any x Any” mode look good, without realizing their actions are actually breaking their interfaces for the classes that matter.

Use the Preview Assistant

A lack of immediate feedback from the Interface Builder is another source of frustration. To see the impact of your changes, you either need to tell it to adjust the views to match your constraints, or run the app in the simulator. Both options are tedious, but there is a better way.

When editing storyboards or .xib files in Interface Builder, a Preview pane is available from the Assistant Editor. The Preview pane displays your layout as it will appear on various devices and automatically updates as you make changes. This feature makes it much easier to experiment and see how each change impacts the layout’s appearance.

Don’t Adjust View Location or Size

Before Auto Layout, views were manually arranged by explicitly setting each view’s location and size. When using Auto Layout, the developer defines constraints to have it arrange the views for them. Interface Builder does nothing to discourage developers from manually setting these values, so it is common for novices to still tweak them. This ultimately leads to confusion and frustration because Auto Layout overrides these values and inevitably fails to produce their desired results.

Don’t Rely on Suggested Constraints

Interface Builder has features to generate constraints for you, but in practice this is not that helpful. While the “Add Missing Constraints” and “Reset Suggested Constraints” work as advertised, they fail to work in the way many beginners think. They mistakenly believe that generated constraints are optimal and will result in an interface that renders properly on all devices. In reality, your interface won’t look right in most contexts.

A lot of assumptions are built into the constraints that Interface Builder creates for your layout. It has no way of discerning between assumptions that are reasonable and ones that don’t make sense. At best, generated constraints are a starting point for your layout implementation.

Don’t Over Use Constants

At a recent meetup, a developer shared his neat little app. During his presentation, he spoke about how he wrestled Auto Layout into submission by using numerous constraints to force each view’s placement and size based on hard coded constants. While this approach did produce the desired result, it is not a good practice.

The advantage of using Auto Layout is that it will dynamically adjust your interface to display optimally across all devices. It can do this because well-constructed constraints allow for flexibility in the arrangement of views. If there are too many constraints that are set using constants, the end result is equivalent to using a manual layout, but with a lot more effort.

More Information

Visit the links below for more in depth information about working with Auto Layout and Size Classes. I found them quite helpful.

Ray Wenderlich – Auto Layout Tutorial in iOS 9 Part 1: Getting Started

Apple WWDC 2015 – Mysteries of Auto Layout, Part 1

CC3200 Revisited

For a while, I’ve wanted to take another look at my CC3200 LaunchPad. For one thing, it has a temperature sensor that I wanted to get working. I also wanted another crack at programming the device because small, wifi enabled, Arduino compatible boards are now prolific and are handy for inexpensively implementing sensors for use in projects around the home.

The CC3200 features the TMP006, a very common temperature sensor included on a variety of boards, like the ones available from Adafruit. In fact, Adafruit’s TMP006 library comes packaged with Energia, a development environment geared for CC3200 LaunchPad and other devices.

Initially, I thought the onboard TMP006 was designed to provide ambient temperature readings, but it’s actually more sophisticated than that. The first clue is in the functionality exposed by the library. It provides two functions that return temperature readings from the sensor, readDieTempC and readObjTempC.

Why two temperature readings? Well, according to the TI’s datasheet, “The TMP006 and TMP006B are fully integrated MEMs thermopile sensors that measure the temperature of an object without having to be in direct contact.” In other words, readObjTempC reports the temperature of whatever it’s aimed at. How cool is that?

What about readDieTempC? Looking at section 5 of the TMP006 User’s Manual, it becomes clear that the die temperature is important for calibrating the device and is used to compensate for its own heat emission. A handful of equations are provided to help you calculate accurate readings.

I haven’t done anything beyond proving I can get values from the sensor, but I plan to experiment with it more, in the near future.

Swift: First Experiences

I began learning Swift shortly after its surprise introduction at the WWDC 2014, but last week marked the first time it was put to accomplishing my App development goals. Swift is new programming language, created by Apple, for building applications for OSX, iOS, and WatchOS. It is appealing because it has the capabilities and feel that developers expect from a modern language, and for many it was a breath of fresh air in comparison to Objective-C, the defacto option of the time.

Many developers learning to build iOS applications struggled with Objective-C because of its unusual syntax. It is a blend of the familiar C syntax with a uniquely different and awkward syntax used for working with objects. Like C++, Objective-C is a superset of C, so I like thinking of it as a C++ implementation that came from a bizarre parallel universe. After years of experience working with Objective-C, I’m still not as efficient at reading it as I am with C#, Java, and C++. That said, it is unfair to write the language off because of its syntactical peculiarities. It has an excellent library of well-designed APIs and its object paradigm is arguably cleaner in some ways than the C++ approach. Objective-C’s utilization of selectors over traditional method calls also offers flexibility not readily available in C or C++.  In all, I found it to be a productive language despite its short comings.

Now that there is an alternative, what is the drive for a developer, like myself, to switch after an already considerable investment into developing Apps with Objective-C? Well, for one thing it adds modern language features that were not available in Objective-C, like generics. It seems to have borrowed heavily from other contemporary languages, like C#, and introduced new concepts of its own which makes it a more expressive and productive. In addition, Apple claims there are substantial performance benefits. The performance of Objective-C is adequate for most purposes, but greater efficiency can also lead to reduced power consumption and positively influence battery life.

My first Swift project was an experiment to see how quickly I could rewrite Keep Time’s timing code. Swift and Objective-C are fully interoperable to the point where both languages can coexist together within the same project, which enables developers to utilize Swift to add on to existing Objective-C projects, or to gradually rewrite entire applications one class at a time. My experience was a favorable one and working with the language was actually enjoyable because it eliminates all of the cruft that Objective-C inherited from C. I also appreciated that the syntax is far less tedious, which means more energy was directed at solving problems and less was spent on figuring out how to express myself in the language. One thing is clear, Swift’s designers are not afraid to challenge long established conventions. For example, it was surprising to discover there is no concept of a protected accessibility modifier. Working with a language that challenges established notions sometimes feels frustrating; however, it is provoking me to rethink my approach to software design and it is through experiences like these that developers hone their craft and produce ever more elegant and maintainable code.

Apple Watch

My Apple Watch arrived a few days ago and I find myself using it more than anticipated. The decision to purchase it was primarily based on my need for a hands on device for use with development. Apple made development tools available shortly after announcing the Apple Watch, but it proved difficult to get a good feel for what the device was capable off within the simulator. Owning one is really the only way to understand how to design apps that leverage it well.

When the package arrived, I was surprised at how large it was. I didn’t expect it to arrive in a long box because Apple products tend to be fitted to minimally sized boxes. It is weird that the smallest Apple product I own also came in one of their largest boxes. Out of the box, the watch exceeded my expectations in terms of both look and feel. Pairing it with the phone was amazingly easy. The dynamic pattern it displays for the phone to read using its camera is a bit over the top, and, admittedly, also very cool.

I’ve worn the watch every day since it arrived to gauge how practical it really is, and surprisingly, it has gotten a lot of use. When I ordered it, I feared its features were too gimmicky and that I would quickly go back to not wearing a watch at all. Turns out everything I tried with it works very well, and its capabilities come in handy. Sometimes it is less than convenient to access your phone; like when I’m walking the dog. The watch has proven itself handy for quickly reading and dictating replies to text messages. Convenient access to the iPhone has definitely been the watch’s largest benefit at this point and I think that is why I can’t come up with a compelling reason for why anyone needs an Apple Watch; however, it is clear that it complements the iPhone’s capabilities in a substantial and worthwhile way and we’re just seeing the beginning of what can be done.

Based on what I’ve already experienced, the Apple Watch has a future and will become even more capable as Apple opens up more of its APIs for use by developers. I’ll provide some insights from an App development perspective after I have spent more time with the tooling.

Internet of Thing!

Today, I attended one of the free AT&T Devlab workshops to learn about developing for The Internet of Things (IoT). IoT is the name given to the continuing trend of computing devices becoming smaller, cheaper, and ultimately more prolific. Many of these devices are capable of participating in conventional WiFi networks, which is what enables them to communicate over The Internet. Basically, we’re seeing the dawn of an age where everything and anything is connected to networks. For example, in a not so distant future, your washing machine will be able to push a notification to your Smart Phone to tell you it is done. With an exciting future of connected appliances upon us, I jumped at the chance to learn more about what is out there to help developers build applications to leverage this trend.

About the workshop; it was aimed at getting developers exposed to the tooling that powers the Internet of Things. Their vision is like this, you select one or more low cost devices that collect data using sensors and relay the data to AT&T’s M2X cloud service. There are sensors out there for just about every situation. For example, a temperature sensing device would be handy for keeping tabs on the temperature of a refrigerator. At regular intervals the device would send temperature status to the cloud service where the data is stored and analyzed.

While their platform played a central role in the training exercises, the event was far from being a commercial. All participants received a free Texas Instruments CC3200 Launch Pad, which is about $30 value. It is literally a thing with Internet connectivity. It features WiFi connectivity, temperature and orientation sensors, and ports to extend it further using daughter boards. The session introduced us to working with the board and getting acquainted enough with the tooling and code to create a minimalist application that tied the board’s sensors back to M2X. Any developer will attest that it takes time to get up to speed on a new platform and that it often involves a non-trivial amount of trial and error. An outcome of this event is that there are now a bunch more developers ready to be productive at writing applications that take advantage of the Internet of Things and for me it opens up some more possibilities for future applications.