This is my last day at work before my weekend (Thursday and Friday) and it is interesting to see that once again the ‘doom and gloom’ merchants regarding Apple’s ‘eventual demise’ are once again proven to be incorrect (link). You’d think at this stage that those who call themselves ‘analysts’ that claim they can predict the future yet get it wrong every single time would find a new day job but alas they’re doing what they’re doing and providing me with plenty of laughs in the process.
For whatever reason I’ve found myself reading through Google’s API knowledge base to see the rational behind why they have their own Calendaring and Contacts API even though there is CardDAV and CalDAV which are available. The reading has reminded me why open standards aren’t always the best solution specifically if you have a bespoke software stack and you a particular way of getting things done. As long as the protocol is well documented and well maintained then I can see the benefits of not having to deal with the minefield that is dealing with an open standards body where every man and their dog want to put their 10 cents into the discussion even if they have no skin in the game directly (see Adobe and their persistent undermining of HTML5).
Looking forward to the big Google I/O conference next week where we’ll probably hear the official name of the next version of Android, the greater insight into the future direction, maybe even some information on where their Fuchsia operating system fits into their larger vision they have for Google. I don’t see there being a major change any time soon but I could imagine a unification will make for overlaps between Flutter based applications and Chrome which has essentially become a portable framework with a run time engine. It is one of the reasons I think it is important to consider that when talking about how ‘heavy’ Google Chrome is given the scope of functionality that exists and that the functionality isn’t necessarily the most efficient (when compared to if you wrote an application that used native API’s and compiled into native code) but with every move forward in terms of abstraction there are also benefits gained to the end user even if it means shaving off a few minutes from ones battery life. It is always good when competition heats up because it forces both sides to lift their game and the consumer ends up benefiting.
Ubiquiti has released an update to their USG which will hopefully mean a few more releases before ipv6 comes out of alpha/beta into being full supported. One of the things I love about Ubiquiti is everything just works – once you install and configure it then it is hassle free computer from that moment onward with zero dramas.
Back to Google again, it is interesting that they’re giving the messaging game a go once again with the rumours that they’re going to extend functionality of Android Messneger with RCS which leaves one wondering where Allo is going to fit into this. It truly is mind boggling that all they have to do is merge Allo and Android Messenger then make Allo an automatic sign up process in much the same way that takes place in the world of Apple then make it a requirement that if you want Google Playstore access you have to include that. Really, the solution is simple but it appears that Google is doing everything posible to avoid it but that being said will it all matter in the end given that most people I know use Facebook Messenger, WhatsApp and so on for their messaging needs thus negating the whole purpose of iMessage in the first place.