I’ve been getting to grips with Socket programming lately, with the aim of writing custom software to stream images from camera to server to client(s). Basic CCTV stuff.
So far I’ve been getting tripped up in the logic of which application should be the server and which should be the client. The waters get a bit muddy once you start adding extra parts to the architecture, and adding features.
My goal, by the end of the week I suppose, is to have a client connect to the image server – which will be receiving mocked image data – and have that returned and rendered on the client.
I can see frustration ahead! Will post code, if it ends up looking palatable enough.
I’ve just made a list of what I believe to be the final hurdles in front of the Beta release of GrappleApp.
Doesn’t seem like much, even though I have a good idea about how much hard work this actually represents, but to be honest it’s nothing compared to the amount of effort I’ve already put in.
I did do some estimates, and came up with a date, but that is assuming I work flat out on this until it’s done – and that will likely not happen, since I do need to return to MakingTracksGPS pretty soon (I will put up a barriers to release post on that at some point).
I have arbitrarily added some time to that initial estimate and come up with a release date of 13th May 2017 .
If it’s finished sooner, so be it, but if I don’t get it released before September 2017 I’m packing the whole thing in.
I mean it.
I’ve just taken the plunge and registered an Amazon Web Services account. It’s time to see what all this cloud nonsense is all about.
I’ve just been playing around with a basic Lambda function for now, just finding my feet really. I’ll be looking for some decent tutorials today, to get some ideas on what would be valuable to learn/implement, and what services are worth tying together.
I definitely like the idea of leaving the infrastructure, high availability, scalability etc. concerns to another entity, and just focusing on the code (and minimising the cost of running said code).
Let’s see where this goes anyway, I might be considering migrating my other services over to AWS soon if I’m suitably impressed with its capabilities.
I’ve got the whole download and decompress functionality sorted now (including nice informative loading bars), and even managed to squeeze the zip file down to 190 Mb (from an initially ridiculous – albeit non-compressed – 341 Mb). Technically, I could include this archive as an expansion pack on Google Play, but I’m really unfamiliar with how that works, so I will be hosting it myself regardless.
I do still have to test the complete end-to-end download and decompress functionality, but I’ve proven each part in isolation and I’m confident there will be no issues.
I think my next focus will be to begin planning the GrappleApp character generation system.
No, I’m not quitting coding. I’m referring to file compression (and decompression). I’ve decided to implement the downloading and unpacking of a compressed file of all GrappleApp image sequences during initial setup of the application (still keeping the image server for individual images as backup for now).
So far I’ve worked on just the decompression of a basic .zip file, which is performing okay.
I’ve just been looking at .7z compressed files, which are considerably smaller, but don’t seem as cooperative when trying to unzip ’em in Android. Probably going to abandon that for now.
I’m contemplating having another look at the code which produced all the processed images, because they seem to come out larger (in kb) after that process – entire original folder: 298.7 Mb, processed folder: 420 Mb – and that is not good at all. I’ll have to sort that out.
I’ll also be looking at implementing a reportable file downloader class that allows its current progress to be queried by the UI, and I might be implementing some resumability – unless that’s already built in for downloading (which I doubt).