Daikin Integration to BACnet, Modbus, KNX, WIFI, Mobile Apps
| APPs, AppStores,
and what you should get
A good deal of the push towards APPS (applications loaded directly onto devices) versus browser-based was stimulated by the device vendors themselves.
Fundamental Objects, Inc.
A Building Manager
(ABM) is faced with many things as automation
replaces labor and paper. One of these things is deciding which -- of
the massive amount available -- of hardware and software options should
be used in their buildings.
Depending upon the facility's size, the building manager may be able to
decide upon and purchase these things directly; or the manager may be
part of a decision-making team that collectively decides what should be
ABM may also need to make the decision on whether to purchase the software/devices from a 3rd party, or if some of these things can be done in-house.
There was an AutomatedBuildings (AB) article recently
about how the author believes that technical details are no longer more important than function in devices nowadays, and that APPs are better than browser-based applications.
B U T, the technical aspects of devices, platforms and software must still remain a top factor in helping to decide on what ABM purchases. Here's why:
A good deal of the push towards APPS (applications loaded directly onto devices) versus browser-based was stimulated by the device vendors themselves. Apple really started this trend by deciding that they can more easily control what is in the applications run on their iOS iPhone/iPad platform -- if they were in the form of applications directly on the device themselves -- rather than in web-based applications that could change after Apple had approved them.
And by the way, then Apple could also charge a hefty fee for each application purchased from their app store as well. This is a revenue source that they would not get if applications were run directly from the internet in a browser. Soon, the other mobile OS vendors were rushing to create App Stores of their own as well.
As a byproduct of
this, the software developers writing the
applications that ABM actually cares about, now have to write separate
versions of their applications specifically for the generally closed
APP frameworks of each platform vendor. (See Figure 1).
The benefits from all of this really are more for the device vendor, than the user, or the software developers -- who must now [usually] create separate versions for any of the device platforms that they wish to support. That is, if they expect optimal performance from the underlying device.
One immediate impact to ABM is that they may need to handle different APP versions (and contracts; and vendor contacts; and feature upgrade timelines; and costs) for the same application running across different platforms in their buildings. All as opposed to a browser-based app, that would be bought once and run on everything.
App versus browser-based
I am not as quick to say that the move to Apps versus browser-based applications on mobile devices is a good thing for users (or for developers).
What really is happening here is more of the device/platform vendors (e.g. like Apple/Microsoft) realizing that the dollars of the old model of being able to sell applications as packages on PCs was going to drop precipitously, as customers moved toward mobile devices. Users wanted applications to be web-based, and therefore available from anywhere. Not just as a package installed on just one PC/Mac. The platform vendors found that by evolving (forcing?) the APP model on devices, that they could replicate the model flow (and approximate dollars) of the sell-an-application-as-a-package on a PC or Mac model.
The trade-off is
that developers have to develop separate versions for
each of the desired target platforms, with more development dollars
being spent on rebuilding apps specifically for each platform and less
on new or improved features for the application itself.
How does ABM decision today -- affect tomorrow?
It's not all about functionality. Really. There is also the impact on your buildings if the company providing the devices makes a dramatic, unexpected change in the way they do things. Or, worse, if their underlying technical platform can not keep up with changes in the market.
For a good
example, consider all of the users of the Blackberry from RIM. The
growth of the Blackberry was tied to a very easy to use push email
interface. The email framework was wonderful and many bought into the
platform as a result. But in the long run, RIM struggled because their
underlying platform was difficult for 3rd party vendors to build
applications for and they could not keep up with the massive jumps in
functionality offered by Android and iOS (Apple) devices. Blackberry
became a closed platform, that no one wants to build for now.
To be fair, there are many other examples of companies pulling the rug out of proprietary platforms.
Microsoft has, almost shamefully, changed their platforms at their will.
The latest example is how all Windows Mobile 6 and below applications just won't work on the new Windows Phone 8. Why should users have to replace all of their apps? -- other than for the obvious answer that Microsoft gets the App Store revenue from all of the replacement apps that must be re-bought.
Apple's Firewire anyone?
If you have hundreds ... or thousands ... of Blackberry devices now,
purchased only for the features that they offered, then you have
already learned that the underlying technology of these things are
important and really needs strong consideration as well.
If you had bought into the RIM experience on a large scale before, you are probably looking at switching out much of your infrastructure now for more flexible devices, and those with wider support. And you are probably learning a good bit about Android versus iOS technical aspects, because you want to get something flexible. Something that will grow and that will not lock you into one type of device.
I have to note that with the tools we make at Fundamental Objects, that we are not really affected either way. (We have both browser-based and APP versions for most of the mobile platforms). So whether users want either type -- or even both -- we are set. So the point of this article as it affects us is not to push one way or the other -- but to choose the one that is best for ABM and the ABM's users.
What is ABM to do?
So, what kinds of things should a building manager look for when purchasing software and devices?
Here are some things to look out for, or at least to consider when making hardware/software decisions for mobile devices:
Microsoft Shuts Down Windows Mobile 6.x Marketplace Today
RIM Collapsing? BlackBerry Sales Drop 43% in a Quarter
Mobile OS Market Trends
foAudits, mobile energy audits
About the Author
Bill Shadish has been working with (ok, and evangelizing) mobile energy audits for commercial and residential applications since 1998. He created and still manages foAudits, the very first mobile audit platform; and has written over 250 articles for both print and online readers.
You can reach Bill at http://foAudits.com?screen=contact.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]