Circa 2014(15?), I spent a couple of weeks working on reducing a Universal iOS App's(Trapster) payload size. This was before Asset Catelogs, so everything was in a fat binary. We converted the audio to be monoaural. We did PNG-crush. Gzipped embedded dynamic data that was preloaded. Optimized SVGs. All the hoops, they were jumped through. It only reduced binary size from 60Mb to 50Mb.
Taking another look at the payload showed that the otherwise innocuous launch images were 32ish Mb in size. The background of the images wasn't a solid colour. The background pattern was more of grayscale static similar to an unwatchable terrestrial TV feed. It was intended to resemble the initial sound of a CB radio used by truckers. (The "Chshhh" in "Chshhh 10-4 Good Buddy")
Since "staticy" audio/imagery like that is inherently random, each launch image(1 per device resolution) was composed of primarily uncompressable data. Switching out of the "staticy" background for a plain gray reduced the payload size to ~20M, a savings of ~30Mb. That change took approximately an hour.
The takeaway here is to take a good inventory of the payload before tackling size reduction. Otherwise you end up fighting the hard fight just to be pennywise
Also, uncompressable launch images for iPad Retina displays are stupid huge.
Switching out of the "staticy" background for a plain gray reduced the payload size to ~20M, a savings of ~30Mb.
I know this might sound somewhat obvious in retrospect, but you could've retained something similar to the original background and reduced the size significantly by generating it at runtime --- the code to create a random-looking background may only be not more than a few dozen bytes, and can be the same for multiple resolutions.
For more examples of this technique, see demoscene productions --- the following video was generated by a binary of less than 4096 bytes:
I've never worked with iOS but given what I've heard about the extensive restrictions on what apps can do, I'm not surprised. I guess this is more like an icon which the OS retrieves from a known place and displays, before the app even runs?
Then again, like most demosceners, I see "you can't" as a challenge... and immediately thought of whether exploiting the image format/whatever loads it to run the necessary code would do the trick. Probably wouldn't please Apple for sure. ;-)
I think it's instead brilliant that they are giving developers the opportunity to display an image that gives user feedback while the app is loading its binary, executing static constructors, dynamically linking libraries, etc. you are not forbidden to roll out your own splash screen screen, but it will not be as immediate and smooth as the builtin splash screen support.
They still aren't "full" view controllers, though. I don't think any of the controller callbacks are executed. I would be surprised if custom drawing is possible. This feature mostly seems to let you leverage autolayout and size classes, which is probably enough for most people
Yep, that's basically it. You can't link any code to it. I think it was added just to make your launch screen look as similar as possible to your app's first screen.
I take the same approach, listing the (non technical) area of study and years of attendance. People tend to assume this resulted in a BA, which is not the intent. I've struggled with whether this is duplicitous on my part. Generally I feel that listing no education would be a lie of omission and not relay the story of my professional career properly.
Amazing setup and even better write up. It shames my tiny 2x 4tb setup.
My only suggestion would be to try out gaffer tape instead of the duct/masking tape combo. I started using it about a year ago, and haven't looked back. No residue and no dry flaking over time.
The Starship Robots are really cool. The sort of stuff I dreamt of as a child after staying up too late reading Asimov by flashlight. If I found myself working on a project like that, I would be more than thrilled. I probably came off too negative in my first post. When presented with a machine out of a childhood dream, I was suddenly laden with the fear of reality.
It is a great idea, and I hope they execute it perfectly. The path they choose around the roadblocks will be the real magic.
I would be very excited to receive items from one of these robots. However, I don't know if I could bring myself to send anything of import. The risk of en route damage/theft seems really high. The trapping or taunting of them seems like a surefire activity for children. Their contribution to already congested pedestrian routes in urban areas seems like a perfect catalyst for sidewalk rage induced kicks. If they were to commonly transport high value goods, theft would be a huge issue. A few hours to build a serviceable faraday cage and you have a drop and lift job that nets significant gains. Not advocated theft, but it seems a rather obvious risk.
Also, dogs rejoice! You finally have a catchable, chewable mail courier.
Edit: There also seems to be some potential security risks here. Some cities may not be keen on unmanned, arbitrary payload carrying robots driving through throngs of pedestrians. They are going to have vet the store operators and detect if a recipient fills a unit with unexpected items. Maybe that is just paranoia.
> If they were to commonly transport high value goods, theft would be a huge issue.
That was my first thought as well. Get a van and a sledgehammer and wait a few blocks away from their depot in the morning. Sure they could phone home, but what is the cost of maintaining a staff to protect the robots vs. just having the staff deliver things.
Reminds me of a friend who was a Marine Biologist. Their lab spent a lot of money to get an underwater probe that could go around and take automated readings based on a map. But the probe cost so much money that they had to follow it the whole time in a boat to make sure it didn't get lost.
>> If they were to commonly transport high value goods, theft would be a huge issue.
The first thing I thought.
> ...they had to follow it the whole time in a boat to make sure it didn't get lost.
This should be a great input for this company making these, actually solves the issue of theft. One robot, one person to follow it from a distance and make sure it does not get lost or, ehem stolen.
> This should be a great input for this company making these, actually solves the issue of theft. One robot, one person to follow it from a distance and make sure it does not get lost or, ehem stolen.
A one to one relationship doesn't seem like it would scale. They could make their operation centers mobile by outfitting vans or buses. That would allow for visual monitoring as needed, and quick responses to breakdowns/thefts/vandalism. As an added bonus, they could see a net savings on downtown office space as well!
Maybe it's more like this: a foreperson rolls up in a truck. Then a stream of about 20 of these fulla ciggies n beer loops through to the convenience store to drop it off. No heavy hand truck.
If they were commonplace, they could monitor each other. As soon as one is tampered with, others could be re-reouted to follow the perpitrators. It would be like having a mobile CCTV network.
Here's my idea:
As soon as it detects that it's being tampered with or stolen, it locks down and sends out a distress signal to a recovery team. It goes into "hostage mode" and records all sights, sounds, GPS locations, back to the team. The recovery team already has legal stuff figured out with the local police force, and they work together to retrieve the bot and prosecute the offenders, which should be easy with all the data collected.
That should be quite effective against most thieves, and building up a reputation for 100% recovery and prosecution would deter future thieves.
A faraday cage trap might be pretty tough to deal with though. Maybe it can emit annoying sounds if it detects it's being trapped.
> If they were to commonly transport high value goods, theft would be a huge issue.
More so than normal deliveries? There's nothing stopping someone clobbering the USPS guy and emptying the van. At least with the robot it's only carrying one item and it can record the attack on its cameras.
> More so than normal deliveries? There's nothing stopping someone clobbering the USPS guy and emptying the van. At least with the robot it's only carrying one item and it can record the attack on its cameras.
People are a great deal more reluctant to attack other people. Most criminals are nonviolent.
My first thought also - I wonder what kind 'self-defense' mechanisms would be legal and/or effective.
It says on the website that the robots are monitored by humans , I think a human voice beaming from the thing saying "Hey, we're recording you messing with our robot" would be enough to deter 95% of potential attackers.
As long as the items are low value like groceries, the other 5% probably wouldn't bother. They might be wise to impose a value or insurable limit, at least initially.
Liability issues would be my concern. They device would need to record 360 video to prove it didn't cause an accident or injury.
I do see a use for delivery within an office building. Likely this might be the best way to get people accustomed to them. Simply have them operate in the office setting. Even better, connect to intelligent vending machines and they will go get you snacks, drinks, and more, all through the use of an app.
I think the biggest risk at least in a city like San Francisco is people taking their anger out against "rich techies" on these robots. Look how riled San Francisco is right now, what with the perception that techies are causing all their problems. I am certain this would have to put up with an onslaught from these segments of society.
I had an issue with my local UPS operation marking packages as 'Undeliverable as Addressed' at 20:00 the day they were supposed arrive, to meet their obligation. They would then arrive the next day without issue. I ended up calling Amazon, and they got the local UPS office on the phone and asked for the exact problem with addressing. There was none, and they issue did not reoccur.