You might have read this article when I published it originally.

Or, maybe not.

If not, then please do.  It lays out a pretty decent case, I think.

What I've now completed is the majority of the back-end work to make implementing a mobile app a rather trivial piece of coding -- instead of a lot of work.

Let me lay out the how and why for you on this.

The "hard way" to do a mobile app is to have it do all the work.  The easy way, every time, is for the mobile app to be little more than a terminal into something.

But this is a problem in the general sense even when there's a web server included because you then have to parse the web output.  That's somewhat of a pain in the ass.  So what you need to make mobile app development easy is a trivially-parsable reply format, preferably one that updates in real time for you.

HTML5 makes "dynamic updates" pretty easy, which is nice.  You send down a little javascript "listener" and then make a call to a resource that comes back with the MIME type "text/event-stream", and then sends updates.  Each has a tag, which matches that tag in your HTML document.  This connection can be (and should be!) persistent, in that this reduces overhead greatly.

Well, that's nice, but the persistence can be a problem from a resource consumption and management standpoint.  If you're not particularly persistent then the "retry" stanza will reconnect, so many pages and servers do exactly that -- they send the data but then allow the connection to close, relying on the connection cache ("Connection: keep-alive")  to cut down the overhead to something reasonable.  This will give you "every 3-5 seconds" updates -- good enough for most implementations such as social media and messaging.

What you want with an app, however, is an actual dynamic stream that stays open for minutes at a time because otherwise the overhead is a five-alarm pain in the butt.  Implementing true persistence on the server end gives you the ability to push updates as fast as you're willing to burn the CPU to handle.  You can get single-digit millisecond latencies (or better) if you are willing to burn the CPU for it, but getting latencies down into the couple hundred millisecond range, or ten to twenty times faster is an utterly-trivial exercise and actually cuts load since connection renegotiation frequency goes down enormously.

HomeDaemon did the first, until now.  It now has had the web code refactored to implement the second, which means that it is now very easy to add to the web backend a specific calling sequence that will output a table of units with locations, names, types and similar parameters followed by a stream of updates of status with one call that is nothing more than a glorified "GET" instance, and key it all off a given security level to match the user's privilege set.  Since SSL is in play the call (with authentication) and reply, plus the data stream that comes is secure.  And since the lifetime of a connection is now minutes where after the initial burst updates of status take just a few tens of bytes the overhead becomes extremely small -- which is fabulous both for data and power consumption on a handheld.

So there's no app for Android -- yet.  But the predicate for the back-end support for one is now 80% complete with the other 20% in process.  Yeah, implementing that was a five-alarm pain in the ass -- but now it's done.

After the back end is complete, along with the calling sequence, I'm going to teach myself how to write Android apps.

And yeah, somewhere between now and the endpoint of that the asking price is going to go way up for all the obvious reasons, so if you believe in the "MAGA" stuff and want to prove me wrong then get rich at the same time -- read this article again, then contact me.