The Project

A short while back, I wrote a post asking if we could do more with mobile. To find the answer, I decided to do some testing and program a real project natively on mobile devices.

The project was a divisible room with two video projectors and screens, two audio zones, two handheld microphones, two laptop connection points per room and two iPad Mini's. Certainly not the most complicated system ever, but combining and dividing the rooms based on feedback from the removable wall required just enough logic to make the programming less than trivial.

Nevertheless, the requirements were such that if the mobile solution did not work out, I would be able to quickly program a traditional control processor and avoid jeopardizing the project.

The Setup

The first step was deciding on a platform. Android, iOS, Microsoft or cross platform? Cross platform was the most alluring choice to start with, but iOS won out in the end. Going cross platform would have introduced an element of complexity that was not needed for this project. Also, some native features are not available in cross platform environments.

According to Apple, their newest programming language Swift, makes writing code “interactive and fun… and apps run lightning-fast”. Reason enough to give it a try.

Setting up an iOS developer account and installing Xcode, the iOS development environment, was a painless process. The prerequisites being a Mac computer and $99.00 for a developer account.

Climbing The Learning Curve

Now the real fun began. A general roadmap to getting started can be broken down into these points:

GUI Design

Understanding Object-Oriented Programming

Writing a reliable TCP/IP Client

Program the system!

For GUI design, there are several options available. I quickly limited the options to pure code or Storyboards. Storyboards are a tool to visually layout views or pages and the transitions between them. This would probably be the best option for most AV programmers.

The GUI can also be done completely in code. Graphics, button size, color, position and view transitions are all done in programming. I like to keep my GUI somewhat dynamic, so this was the route I took for this project. I also saw this as an opportunity to spend more time exploring the programming environment and minimize the amount of new skills, like Storyboarding, that would need to be acquired.

An absolute must before programming in Swift is a basic foundation in object oriented programming. A degree in Computer Science is not needed, but some time needs to be spent learning the basic concepts. There are plenty of resources online and with the right amount of time and motivation, I do not see any reason why AV programmers could not learn these skills. My adventures in C# over the past few years were enough preparation to dive right into Swift.

Being that mobile device communications are entirely network based, writing a solid TCP client was high on the list of priorities. There are many ways to approach this and unfortunately, there were not any ready-to-go solutions available online. On the other hand, having to write a TCP client from scratch gives one the best understanding of what is actually happening on the network. Trial and error, Wireshark captures and lots of Google were needed to develop a network communications module that worked every time.

Once the hurdles of understanding Object Oriented programming and writing a solid TCP client were out of the way, programming was quite similar to traditional AV programming environments. Button presses, sending commands, polling devices and parsing responses all drew upon my existing AV programming skills. No need to reinvent the wheel.

Any Questions?

I had many, many questions during this process and the internet was at my side the entire time. StackOverflow was by far the best resource for finding answers. Most answers were found within seconds. Specialized questions took a little more digging.

There is an interesting effect of using internet search for support. The sheer amount of information forces one to intensely focus and clearly describe their thoughts to find what they need. This process alone increased understanding and opened up new ways of approaching issues.

Distribution

A big concern was how the app would be distributed to the end customer. After all, it does not make much sense to put a custom project in a public app store. There are also security concerns when controlling devices on the customer’s network. One solution is for the customer to enroll in Apple’s Value Purchase Program for businesses. This program allows developers to offer custom apps directly to a specific company. The company can then distribute the app internally as needed. A happy consequence of this setup is that the customer can allow BYOD control of their AV system to authorized users.

During the testing phase, ad-hoc distribution was used. This allows an app to be run on a device that is registered with the developer. There is no review process needed for ad-hoc testing so changes can be tested immediately. Only 100 devices per year can be registered to a developer, so this option is useful for testing only.

Conclusion

Overall, the experience was a positive one. After the initial growing pains that are present with adopting any new technology, the workflow was very similar to that of a typical AV project. The biggest difference being the app review and distribution process. While this added some friction to delivering the project, enabling BYOD may make it worthwhile for some projects.

The advantages can be summed up as follows:

A modern software development environment

A large and active online support community

Use of native device features

Reduced hardware costs

BYOD control of AV and Building Systems

This is certainly not a replacement for traditional control system design, but yet another solution to offer customers when appropriate. I hope you will share your thoughts or experiences with mobile control in the comments.