Why Modular Smartphones Are Such a Nightmare To Develop
itwbennett writes: Last week Google postponed tests of its Project Ara until next year. Mikael Ricknäs has written about why developing such devices is particularly difficult. The biggest challenge, writes Ricknäs, 'is the underlying architecture, the structural frame and data backbone of the device, which makes it possible for all the modules to communicate with each other. It has to be so efficient that the overall performance doesn't take a hit and still be cheap and frugal with power consumption.' For more on Project Ara and its challenges, watch this Slashdot interview with the project's firmware lead Marti Bolivar.
It is literally a circular network connected to one CPU and a bunch of dumb nodes.
Each node has a network ID. They can pass messages and only the nodes that are listening for it will get it.
High bandwidth data bus for it.
Why is that so complex?
Anything can be made to sound easy by describing the overall concept in a few sentences. Devices are built in the real world, not on a whiteboard, and here in real world, the devil is in the details.
Irony: Agile development has too much intertia to be abandoned now.
Sorry Ara team; but the whole concept is a fail.
I do lots of electronic product development, and this concept has so many problems
- Electromagnetic Compliance. Every time a new module is created, are you going to go through the expense & time of compliance testing.
- Where is consumer demand for such a device? Consumers are becoming dumber; they are flat out finding a power button, let alone selecting complex modules for a phone. This makes it a niche market device, thus low volume, thus expensive.
- Connectors in any design are one of the common fail points. In this design you have lots of them.
- There's a lot of effort just to reliably mechanically retain the modules.
- Having discrete modules makes layout inefficient, as you have to per-decide the size of a function.
- A lot of added complexity/power consumption, as each module needs a hardware/software interface layer common to all modules to abstract their native interface.
- plus all the other mentioned in the link
Now if Google has some spare cash lying around, I've got a lot great projects going on they could invest in!!!
46137
I want a modular device like this so bad.
I plan to buy five of them. Me, my wife, and each of my kids.
I'm hoping tablet and laptop versions soon follow so I can mix and match more modules over time. and I'll get multiples of them, too. it just makes sense to be able to repair them year after year, instead of buying another bloatware crap machine.
Even later I'm hoping I can use the modules for other projects. using the same standardized data bus for a huge variety of things. wearables, pet projects, maker movement stuff.
This is grownup LEGO.
AND a way to save money over time,
AND a way to escape the damned branding going on.
I'm not going to buy a phone until I can get something like this, and I don't really care if it's made by google or someone else.
Nobody who has done Android development is surprised to hear this.
I generally find the opposite, the ones crowing about fragmentation tend to be the ones who have no experience in development on Android (and indeed any non-iPhone platform) and handling perfectly pedestrian problems that we've been working with for all of programming history...
Different hardware and OS versions is standard standard, part of being a programmer...
This.
If you want to avoid version issues with Android, target the lower API levels. Sure you miss out all of the newer features, but you dont need those for a fart app. Android itself handles most (or all of, in most cases) of the backwards compatibility.
Besides this, we've seen the problems inherent in monocultures in IT. Remember I.E. 6... This is why aged web developers never complain about writing compatibility layers for Firefox, Chrome and Webkit browsers.
Calling someone a "hater" only means you can not rationally rebut their argument.