This is the third of a four-part story documenting my somewhat excruciating and wholly uncharted experience developing an indie game for Panasonic’s obscure VIERA Connect television app market several years ago.
In the first part of this postmortem, I detailed the pains of becoming a VIERA Connect third party developer and struggles of setting up the rigid development environment required by Panasonic.
When I list items for sale on eBay, I use a custom-developed HTML template with the item's pictures uploaded externally and embedded into the description for more visual appeal than what eBay provides. This allows me to apply custom styles to the images via CSS, provide descriptive content below specific images and generally offers a lot more flexibility and professionalism.
By default, eBay allows you to upload up to 12 images for free to be included in the ad, and requires uploading at least one image through their service to be displayed in the auction results and so forth. The images uploaded in this manner appear at the very top of the auction page alongside the auction metadata. These eBay-hosted pictures are scaled to 500x375px regardless of the user's screen resolution, with an option to view larger versions by clicking/hovering over them.
I recently built a new computer to better accommodate the forthcoming line of resource-intensive tech products, namely the Oculus Rift and related VR devices. While my old computer was nothing to shake a stick at, its hardware was not satisfactory enough to produce a consistently smooth experience on the Developer Kit 2 (DK2). The second iteration of the developer headset kit requires rendering a 1920x1080 display (960x1080 per eye) 75 times per second or else latency and lag lead to a jittery and nauseating experience. When the consumer version drops next year the hardware demands will be even greater.
With my latest PC upgrade (Geforce GTX 980 TI, MSI Z97 Gaming 5 motherboard with an Intel i7 4790k CPU, 32GB RAM, Samsung SSD 840 Pro, Sound Blaster Zx) I made the sudden, albeit fully expected observation—none of these new components provided any Windows XP support by the manufacturers. After all, Microsoft itself ceased mainstream support for XP way back in 2009 and officially declared it to be 'end of life' and fully unsupported in April 2014. It makes zero sense for any manufacturers to waste additional developer resources maintaining support for such an archaic and unsupported operating system, even as millions of diehards still cling on.
For the past couple of months, I've been working on a much-delayed update to my Android application Scribblify. The original Android version was released back in early 2013 and hadn't been updated on Google Play since then. Although it paled in comparison to the iOS counterpart, the first Android version still received positive reviews and was downloaded 200,000 times. Having released a major 4.0 update to the iOS version earlier this year, it was time to bring the Android version up-to-speed.
One of the greater challenges experienced with Android development occurs when it comes time to test. I previously wrote about the increasingly fragmented iOS platform, but even with a handful of different iOS devices sporting different resolutions and technical specs, nothing quite compares to Android device dispersion. In my updated Android app, for instance, I support all Android devices from API Level 15 (Android 4.0.3) up. According to Google Play, this makes the app compatible with 9,098 Google-certified devices. This list encompasses at least four years of devices including phones, tablets, phablets and more. Understandably, with such a large range of devices comes an equally large range of technical specs.
The common way of deleting files and folders in Windows is via Windows Explorer (a.k.a. File Explorer). This method is perfectly acceptable under normal circumstances, but becomes a real drag when dealing with large and complex folder structures. There is, in fact, a significant amount of of overhead when you trigger the standard delete action in Windows including when either emptying the Recycle Bin or directly deleting files via Shift+Del.
Upon flagging a folder for deletion in the traditional fashion, Windows begins by calculating the total folder size, number of items contained within it, and the estimated completion time. This "Preparing to Delete" phase can consume a sizable amount of time itself depending on the contents being deleted. During the actual deletion process, Windows continues to query and report various statistics about the process including how many items are deleted per second, how many remain, the current item being deleted and so forth. You may also be prompted via the Windows dialog if any conflicts arise during the process.
