In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.
For years developers (and consequently consumers), have had to accept the fact that the Tablets (and some phones) would always have the System/Navigation Bar visible on their screens. A 10.1 inch advertised screens, offered in fact a 9.8 inch usable screen.
Finally Google’s latest Android OS, KitKat, introduces a decent user-friendly tool that gives us ownership of that last bit of screen.
As one would expect with a fine product, it would work best right out of the box. In the case of Android Studio, some assembly is required. The issue I found was that a newly created project with default settings wouldn’t compile. I thought that this bug might have been specific to my setup, but after reproducing it on 3 different computers and finding several outstanding questions as well as a few open bugs with Google concerning the issue, I decided that a fix would be a fine thing to write up, hoping it enables other people to develop as painlessly as possible.
With the release of iOS 7, there are several changes in how you lay out and customize the appearance of your UI. In particular, the status bar is now transparent, and your views will show through it. Now this is a great opportunity to redesign your app and take advantage of this new look and feel, but what if you aren’t ready and you want to the old iOS 6 status bar back? Well, I’m excited to tell you that there is a way to do this!
The Android library is constantly growing. New widgets are built, and existing ones get deprecated. We’ll see how we can make XML layouts versioning more maintainable and more OO using the <include/> element. For that we’ll take as an example the ActionBarSherlock SearchView.
On a recent project, we needed a widget that would allow users to select a photo from their Facebook albums. “Surely the new Facebook Android SDK must support this.” I thought. Alas, my hopes were unfulfilled. “Well, I bet there is a third-party solution for this!”, I surmised, but again, my search was for naught. At this point I decided to roll up my sleeves and do it myself.
Google’s AppEngine is a very useful platform in the way it allows developers to have an application server up and running within 10 minutes.
It leverages the Google infrastructure, too, offering high speed, high capacity, etc.
Wow (Awesome!)
However (Hmm), AE does not allow for the usual multi-threading mechanisms…
On my previous project, I was busy delving into the relatively new world of Unity game scripting as my go-to solution for dynamic content. Now I’m working on a game that has me going back into the world of Flash, so I thought I would write a brief commentary on the differences I perceive between the two frameworks as it pertains to 2D game-crafting.
I’m am working on a project currently that is leveraging an Enterprise CMS. At the outset, I did an analysis of existing CMS systems to select the one that best fit our clients needs. That turned out to be Magnolia (www.magnolia-cms.com).
However, another one of our clients is using the Alfresco CMS for their business. I reviewed it over the weekend and was impressed by the slick and intuitive user interface. The creators of Alfresco come from Documentum and Interwoven.