Slashdot Mirror
Six Months Developing Software For Wearable Computing
An anonymous reader writes "Twilio's Jon Gottfried has written an article about the lessons he's learned after six months of developing software for Google Glass. He has some insightful points: 'I expected it to be very similar to building mobile applications for Android. In fact, I began learning to build Android applications in preparation. My efforts were for naught, because the Mirror API is a RESTful web service. This means that developing applications for Glass is actually more similar to building a website than it is to building an Android application.' He also talks about how this fits in with the future of technology: 'I would argue that Google took the only option available to them. The only truly scalable products of the future will be developer platforms. Facebook, Twitter, Twilio, Google, Apple, Microsoft, Arduino – all of these products have been successful in large part by embracing and empowering their developer communities. No company is omniscient enough to imagine every potential use of their products. This gives developers an immense amount of power to define the success or failure of an entire product line.'"
I read that entire article and I honestly have no idea what the point was. I was excited to learn about how a RESTful API was employed in a heads-up application and learned...nothing.
But if the users run their application on their own device and never report back to Central Command, how are we supposed to sell them ads and know when they brush their teeth?
What you suggest is unacceptable, we'll just claim it is not scalable to do that. And in fact, it is true, it does not scale out amount of profit.
Except running binaries on end user devices requires processing power.
Processing power uses electrical power.
Google Glass has a battery that only runs for 2 hours under any kind of local processing load.
Imagine where things would be if Google *didn't* rely on web-based services processing the results and calling this device a display. Sure, that may not be as scalable as alternatives, however when runtime is paramount than you can expect some different behavior.
Thirty four characters live here.
Actually all the guy says is the thing uses a client server API (I had to google "RESTful") which uses HTTP (unless otherwise) and from wikipedia it sounds similar to what a website with forms and no javascript would do, but maybe you can do web 2.0 shit while respecting the constraints (stateless client and what have you)
He doesn't even tell us where the client and server reside. The client is the glasses, sure. But where's the server? Is it running on the computer inside the pair of glasses, on an Android smartphone you have in the pocket or on the world wide web? Do the glasses run Android, Chrome OS, other? All high level questions are left unanswered as well.
On the not-deep hardware side we don't even get to know anything about the CPU and RAM (such as ARM, 1GB or MIPS, 32MB) nor anything about the networking (3G, 4G, bluetooth 4.0, wifi)
Except that the XML definitions of forms used by modern UI toolkits are describing a much more simple structure, and doing so with significantly less flexibility in terms of ability to style.
The internal method to render a button is simple on most of these platforms –likely to be a matter of a single image draw to render the background, and a single image draw to render the label. It's dimensions and position are likely to be recalculated, and trivial to deal with.
Compare that against what needs to happen to render a button on an HTML page. The entire page must be laid out again (as bounds may have changed, and had knock on effects for other elements). The button's bounds recomputed. Now, an html element (presumably a div) must have its style computed, a general function that can render all kinds of properties must be called, and in doing so many irrelevant chunks of code executed, just in case the style specifies those properties. The same must happen for anything held within the button.
Here's a profile of OS X rendering a single button 5 times:
Note, the actual render method does not actually even appear in the profile, because it runs so quickly
Running Time Self Symbol Name
2.0ms 100.0% 0.0 Main Thread 0x10e87b
2.0ms 100.0% 0.0 start
2.0ms 100.0% 0.0 NSApplicationMain
2.0ms 100.0% 0.0 -[NSApplication run]
2.0ms 100.0% 0.0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
2.0ms 100.0% 0.0 _DPSNextEvent
2.0ms 100.0% 0.0 BlockUntilNextEventMatchingListInMode
2.0ms 100.0% 0.0 ReceiveNextEventCommon
2.0ms 100.0% 0.0 RunCurrentEventLoopInMode
2.0ms 100.0% 0.0 CFRunLoopRunSpecific
2.0ms 100.0% 0.0 __CFRunLoopRun
1.0ms 50.0% 0.0 __CFRunLoopDoObservers
1.0ms 50.0% 0.0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
1.0ms 50.0% 0.0 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208
1.0ms 50.0% 0.0 _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints
1.0ms 50.0% 0.0 -[NSView displayIfNeeded]
1.0ms 50.0% 0.0 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
1.0ms 50.0% 0.0 -[NSWindow flushWindow]
1.0ms 50.0% 1.0 objc_msgSend
Meanwhile, here's chrome rendering a div with some text on it, and a grey background, once (note, unfortunately, chrome doesn't have symbols in it's binary, so we can't see what it's actually doing in that time):
Chrome's engine is taking more than 400 times longer to render just a single button, and the button doesn't even have an image to represent the button – it's just a simple grey rectangle.
Running Time Self Symbol Name
83.0ms 84.6% 0.0 Main Thread 0xfe5ac
83.0ms 84.6% 0.0 0x7ef20
83.0ms 84.6% 0.0 main
83.0ms 84.6% 0.0 ChromeMain
83.0ms 84.6% 0.0 0x6913f0
83.0ms 84.6% 0.0 0x692030
83.0ms 84.6% 0.0 0x2a17cc0
83.0ms 84.6% 0.0 0x2a19650
83.0ms 84.6% 0.0 0x2a18d80
83.0ms 84.6% 0.0 0x1fd950
83.0ms 84.6% 0.0 0x7ca120
83.0ms 84.6% 0.0 0x7b62f0
83.0ms 84.6% 0.0 0x787650
83.0ms 84.6% 0.0 0x787a60
83.0ms 84.6% 0.0 -[NSApplication run]
69.0ms 70.4% 0.0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
69.0ms 70.4% 0.0 _DPSNextEvent
65.0ms 66.3% 0.0 BlockUntilNextEventMatchingListInMode
65.0ms 66.3% 0.0 ReceiveNextEventCommon
64.0ms 65.3% 0.0 RunCurrentEventLoopInMode
63.0ms 64.2% 0.0 CFRunLoopRunInMode
63.0ms 64.2% 0.0 CFRunLoopRunSpecific
63.0ms 64.2% 1.0 __CFRunLoopRun
26.0ms 26.5% 0.0 __CFRunLoopDoSources0
26.0ms 26.5% 0.0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
25.0ms 25.5% 0.0 0x787780
1.0ms 1.0% 1.0 objc_msgSend
24.0ms 24.4% 0.0 __CFRunLoopDoObservers
24.0ms 24.4% 0.0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
Having developed products with embedded GUIs using both C code, and .NET I have to agree that running bloated HTML based graphics will suck the life out of any embedded application. The performance is so drastically different that a 200 MHz processor and C code will run circles around a 1.2 GHz processor running .NET and be much more stable.
It might take a different class of programmer to make the C code work, but in the end it will be a much more interactive platform that does what it should every time you give it input, instead of having to sit there and wait for the OS to catch up with you, while watching an hourglass kinda-sorta spin.
We ran 100 MSec screen refreshes with C code (plus we had about 20 PID loops running) and no problems with CPU load while running on that 200 MHz processor, but the 1.2 GHz .NET application that replaced it struggled to be interactive at a 500 MSec screen refresh rate, processing half as much input data, and forget about doing any real time control with it.
When you changed the screen fast enough, the .NET app would eventually go off to la-la land and push 2 or 3 (or 20) rounds of PID calculations on the stack while not updating the outputs, and then run the calculations in reverse order on the way back off, and cause all sorts of bad_things to happen. Not only was the hardware almost 3X as expensive to run the .NET solution, We had to add an extra black box to do the real time stuff with C code anyways.
But hey you can just make 1 screen layout in Blend and have .NET resize it for you when it's drawn instead of having to do take the time to support a few different screen resolutions in development, and have every customer wait every time they change the screen instead. Vastly better user experience!