4 ms·
I worked as a contractor at Parkeon/Flowbird, on the next version. IIRC, this one is called N² and runs a headless Android on a limited hardware, which explain
by grokx 4y ago
I worked as a contractor at Parkeon/Flowbird, on the next version.
IIRC, this one is called N² and runs a headless Android on a limited hardware, which explains the slowness of this thing.
The next version (called streetsmart) on which I worked 2 years ago is a real mess. It is based on Android 5.1 (Android 8 or 9 was available when the project started), and features a touch screen. There is absolutely no isolation between ticketing apps and maintenance apps (which allow among other things to withdraw the cash). A custom launcher gives access to one set of apps or another, depending on the current mode. An hardware token and a gesture allow agents to switch from vending mode to maintenance mode, but if one gains access to a shell, one just has to send particular intents to access to maintenance apps.
Some anecdotes:
- We shipped debug Android builds for internal testing (with root, adb enabled, etc) which somehow got sent to the customer, deployed on a public network and got infected by crypto miners. That triggered overheat of the CPU and reboots of the devices.
- Those are supposed to be deployed in Barcelona, I don't know if it's actually in production right now.
- Those were supposed to be deployed in NYC, but the deal got cancelled (not really a surprise to me).
- They run on a 12v car battery and a solar cell. I had a partial machine to dev (with no solar part), and I had to buy a car battery charger to power the battery.
The work itself was rather interesting (have you ever worked on a Android device that has a built-in printer and a cash machine?), but project management, collaboration between teams and vision were terrible. The main board seemed really well designed also.
- LaundroMat 4y agoWhy was this such a mess? Undersold budgets, company culture, ...?
- grokx 4y agoI was not an employee so this could not be really accurate but, I would say: - There was way too much bureaucracy. - Software, security, design choices were decided by some kind of committee that didn't have sufficient expertise. - Competition between teams. - They wanted to do scrum, without knowing how to do it. I think their actual expertise was focused on hardware design and manufacture (they build and assemble most of their hardware components in their own factory), and probably firmware devevelopment.
- Someone 4y ago> runs a headless Android on a limited hardware, which explains the slowness of this thing. Does it? Must be very limited hardware, then. I haven’t even ever seen one of those, but I would think a parking meter UI wouldn’t be particularly taxing on hardware.
- grokx 4y agoIt's just that Android might be too much "heavy" for the actual hardware. I don't have any details, sorry. That's what I heard when I was working there.
- atonse 4y agoI haven’t worked with Parkeon but have interacted with their competitors’ software. It is just as ugly as you describe. The rest of the whole parking enforcement/payment industry is probably full of really old incumbents like those two and an absolute shit show.