Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Six Months Developing Software For Wearable Computing

Soulskill posted about a year ago | from the i-need-a-HUD-that-points-out-youtube-commenters-in-real-life dept.

Google 28

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.'"

Sorry! There are no comments related to the filter you selected.

That green font (1)

Anonymous Coward | about a year ago | (#43823225)

So soothing :)

Six monthes wearing the same underwear (-1)

Anonymous Coward | about a year ago | (#43823237)

Frosty teledildonics!

Steve Ballmer said it best: (1)

Anonymous Coward | about a year ago | (#43823249)

I'll just put this here:

So... (3, Informative)

gadzook33 (740455) | about a year ago | (#43823255)

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.

Re:So... (2)

davester666 (731373) | about a year ago | (#43823521)

Welcome to slashdot. Everyone else already knows the articles don't contain useful content and skip reading them. The more senior members also know the summary also contains little information, and will generally misrepresent what the article tried to get across, and thus also skips reading it.

Re:So... (1)

Trax3001BBS (2368736) | about a year ago | (#43823573)

I read that entire article and I honestly have no idea what the point was...(snip)..nothing...

Thank you for that, thought it might be a waste of time.

I didn't get past reading "Being one of the first cyborgs in the world" then a quick scan of the text scrolling down;
figured it wasn't going to be that great of an article and heck I got what I needed from the submitter (right, wrong, or almost {grin}).

uhh wtf? (1)

gl4ss (559668) | about a year ago | (#43823297)

what does "'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 " have to do with a REST api? nothing.

there's not much cool stuff to do before the native sdk(gdk), apparently. but the guy is just pushing twilio, so hey, why not push it as "only truly scalable products" and put in arduino with something that has shit all nothing to do with the other stuff.

you know what's _truly_ scalable? RUNNING BINARIES ON END USER DEVICES. why? the only device needed to run is the one that the user has - that's truly scalable to as many users who have a device.

wasn't there some news of a rootable firmware coming out though?

Re:uhh wtf? (4, Insightful)

godrik (1287354) | about a year ago | (#43823331)

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.

Re:uhh wtf? (1)

Nerdfest (867930) | about a year ago | (#43823595)

It also limits things, as it's difficult to support a vast variety of devices unless they all happen to run the same processor, etc, or are all open source. Open source, would make me happy, limited devices makes Apple happy, but both have some downsides for a lot of developers. Web API based development has some disadvantages as well, but also some advantages to making power available on low powered hardware and scalability.

Re:uhh wtf? (0)

Anonymous Coward | about a year ago | (#43824301)

FYI, Google has announced that ads will not be allowed on Glass.

Re:uhh wtf? (0)

Anonymous Coward | about a year ago | (#43826627)

Nah, that would generate far too much bad publicity and maybe even lead to lawsuits when people have accidents while distracted, etc. That doesn't detract one iota from the OP's point, however, which is that the entire Glass business model consists of hoovering up every last detail of your private life and then selling it to the highest bidder.

Re:uhh wtf? (2)

tysonedwards (969693) | about a year ago | (#43823493)

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.

Re:uhh wtf? (0)

Anonymous Coward | about a year ago | (#43823553)

Depends on the type of data processing required. I do not expect to be crunching big data on a device like this. I do expect to see something interesting and query the relevant entry in my pre-downloaded wikipedia.
I can easily see maintaining and using a wireless connection to some cell tower to contact a far away server being much more of a drain on the battery than if everything was done locally.
The only exception would be audio/video recognition and seriously who really wants that anyway?

Re:uhh wtf? (1)

beelsebob (529313) | about a year ago | (#43824187)

You realise that web rendering, and running interpretted javascript code is significantly more intensive than a native UI rendering library, right?

What makes CSS and JS so "intensive"? (1)

tepples (727027) | about a year ago | (#43824871)

What in particular makes the CSS rendering model more processing-intensive than the rendering model of a similarly capable "native" toolkit? And what makes JavaScript more processing-intensive than .NET, Java, or any other kind of bytecode that's intended to execute on more than one brand of hardware?

Re:What makes CSS and JS so "intensive"? (1)

beelsebob (529313) | about a year ago | (#43825003)

The fact that the HTML, CSS and javascript need to be parsed and interpretted, as well as simply run, and the fact that they're designed with the flexibility to represent any web page in existance in mind, rather than with the ability to render standard UI widgets in mind with the option to add extra code if you need to do something custom.

Re:What makes CSS and JS so "intensive"? (1)

tepples (727027) | about a year ago | (#43825043)

The fact that the HTML, CSS and javascript need to be parsed and interpretted

HTML and CSS need to be parsed and interpreted. The XML definitions of forms used by modern UI toolkits likewise need to be parsed and interpreted. Java and .NET bytecode don't need to be parsed quite so much, but like JavaScript, they still need to be interpreted.

Re:What makes CSS and JS so "intensive"? (2)

beelsebob (529313) | about a year ago | (#43825147)

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 __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
25.0ms 25.5% 0.0 0x787780
1.0ms 1.0% 1.0 objc_msgSend
24.0ms 24.4% 0.0 __CFRunLoopDoObservers
23.0ms 23.4% 0.0 _runLoopObserverWithBlockContext
17.0ms 17.3% 0.0 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01253
17.0ms 17.3% 0.0 _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints
16.0ms 16.3% 0.0 -[NSWindow displayIfNeeded]
16.0ms 16.3% 0.0 -[NSView displayIfNeeded]
15.0ms 15.3% 0.0 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
15.0ms 15.3% 0.0 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
15.0ms 15.3% 0.0 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
13.0ms 13.2% 0.0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
11.0ms 11.2% 0.0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
9.0ms 9.1% 0.0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
6.0ms 6.1% 0.0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
3.0ms 3.0% 0.0 -[NSView _drawRect:clip:]
3.0ms 3.0% 0.0 0x28592d0
2.0ms 2.0% 0.0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
1.0ms 1.0% 1.0 +[NSGraphicsContext currentContext]
3.0ms 3.0% 0.0 -[NSView _drawRect:clip:]
2.0ms 2.0% 0.0 -[NSView _drawView:]
2.0ms 2.0% 0.0 -[NSThemeFrame _drawRect:clip:]
2.0ms 2.0% 0.0 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
1.0ms 1.0% 0.0 -[NSView _sendViewWillDrawInRect:clipRootView:]
1.0ms 1.0% 0.0 _CFAutoreleasePoolPop
4.0ms 4.0% 0.0 __35-[NSWindow _postInvalidCursorRects]_block_invoke_02879
2.0ms 2.0% 0.0 __38-[NSApplication setWindowsNeedUpdate:]_block_invoke_02428
1.0ms 1.0% 0.0 FlushAllBuffers(__CFRunLoopObserver*, unsigned long, void*)
5.0ms 5.1% 0.0 __CFRunLoopDoTimer
4.0ms 4.0% 0.0 __CFRunLoopDoSource1
1.0ms 1.0% 0.0 __CFRunLoopServiceMachPort
1.0ms 1.0% 0.0 mach_port_insert_member
1.0ms 1.0% 0.0 _dispatch_main_queue_callback_4CF
1.0ms 1.0% 1.0 _CFRunLoopSetCurrent
1.0ms 1.0% 1.0 CFRunLoopRunInMode
2.0ms 2.0% 0.0 SendEventToEventTarget
2.0ms 2.0% 0.0 _NSHandleCarbonMenuEvent
13.0ms 13.2% 0.0 0x1f7c50
1.0ms 1.0% 0.0 -[NSAutoreleasePool drain]

Firmware? Ugh. (1)

Smerta (1855348) | about a year ago | (#43823671)

Came here hoping the article would talk about deeply embedded firmware, CPU constraints, low power tradeoffs, etc. (I'm an embedded systems kinda guy). Left disappointed.

It blows my mind that something which on the surface screams of "deeply embedded system" is characterized as "similar to building a website".

Don't get me wrong, I know there's a lot of stuff underneath to make it all work, that's the stuff I find cool, I'm not an app developer... but for example when the Kinect came out, some of the first articles were really detailed embedded-systems level articles about the product.

Re:Firmware? Ugh. (2)

Blaskowicz (634489) | about a year ago | (#43823899)

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)

Re:Firmware? Ugh. (1)

Georules (655379) | about a year ago | (#43823991)

The article is pretty awful, but your understanding of "REST" is pretty poor. Might give that a second lookup.

Re:Firmware? Ugh. (0)

Blaskowicz (634489) | about a year ago | (#43824747)

Sure I didn't understand. Maybe I should spend the next 24 hours non-stop on studying the subject. maybe not.

Re:Firmware? Ugh. (1)

Georules (655379) | about a year ago | (#43825163)

It would really only be a 1 minute investment to understand that it's not just about HTML forms.

Re:Firmware? Ugh. (1)

Blaskowicz (634489) | about a year ago | (#43825455)

I only tried to know whether HTML forms are RESTful (or can be) and I don't know.
Also, crap, I must have mixed up what's stateful and stateless (server is stateless and client is stateful)
I only have the wikipedia article on REST and never did web dev (I can write raw 1990s html with no css and no tables, that's all)

So, I'm sorry to say some dumb stuff and showing some lazyness but I really wondered what that damn "RESTful" means, it's the only technical term in the entire article and it isn't really explained. The only thing I understand from it is that it uses HTTP since the author says it's a "RESTful web service". There's "asynchronous" too. (is google maps an asychronous application?)

Re:Firmware? Ugh. (2)

EETech1 (1179269) | about a year ago | (#43825369)

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!

Red mustache (1)

Dan East (318230) | about a year ago | (#43825089)

'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

Do you see that red mustache? He drank the cool-aid. The whole pitcher.

I'm also trying to figure out how online social networks, a software development company, a hardware / software company, and an experimental hardware board for hobbyists all fit together with Google Glasses in some way. That cool-aid was spiked with buzz words.

Thread knitting fashionable spaz software /. stem (1)

axonis (640949) | about a year ago | (#43827865)

does the composition of your slave threads you are wearing right now stem from a computing device ? naked truth is its built into the computation composition of your clobber, just ware IT on your sleave as its just a passing fashion.

Smart work (0)

Anonymous Coward | about a year ago | (#43828679)

"No company is omniscient enough to imagine every potential use of their products."

Yes that's true. World is smarter than a single company. So why would a company need to do everything when developers across the world can do more smarter work.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?