Archive for Android

Google Kotlin!

Google announced that the Kotlin programming language will now be a first class citizen alongside of Java for Android development. Since Apple had announced Swift as the replacement for Objective-C as the iOS app development programming language, there’s been a lot of speculation on what Google might do in response; some commentators even speculated that Google might also go with Swift. Google has now made their move and it’s a really smart one. Coder Radio listeners will know that I’ve been a long-time fan of Java, but I have to say if there’s going to be a successor to it, then Kotlin seems like a great choice.

For starters, it targets the JVM. That means that Kotlin code can be run on a wide variety of architectures and devices. For the purposes of Android development this was essential, since Android uses a “version” of the JVM; there’s been some legal cloud about what exactly Google’s Davlik VM was a bit too much like the JVM for Oracle. If you’ve never had a “standard” disappear on you, then you might not understand how much of risk there is in technologies simply evaporating into the air, leaving you and your users high and dry.

Speaking of the longevity of technologies (especially in the enterprise), Kotlin targets Java 6. What that means is the there’s a huge pool of enterprise Java applications that it can work on today using its interoperability with Java. In practical terms, this means that there’s no need to rewrite your legacy Java application to start writing modules in Kotlin.

Java can be a little strict in terms of checked exceptions. Basically, in Java, if there’s a possibility to throw an exception it must be checked with a try / catch block. In larger projects this makes you’re code pretty verbose and I’ve long found this to be one most annoying aspects of Java day to day. Kotlin does not have checked exceptions, giving you more flexibility in how you write your code and reducing all around cruft.

If you’re an Android developer or just a Java developer in general, I urge you to take a look at Kotlin and form your own opinion. Also, if you’re interested in learning more about Docker or DevOps in general, take a look at my Docker Compose Quickstart Guide and follow me on Twitter!

Swift on Android

SwiftRumor has it that Google may be considering making Apple’s Swift a first class language for Android development. Predictably, the internet has been pretty excited about this possibility. My lack of enthusiasm for Swift has been fairly well document, so I’m going to keep my comments to a minimum.  Swift on Android shares the same API problem as Swift on iOS and this likely has more to do with legal wrangling than technology.

Java and Objective-C are very object oriented languages and the Android SDK and Cocoa Touch APIs reflect that. Swift is a far more functional language than either of them. “Good Swift”, which I have been told is functional and not just “Objective-C in Swift” doesn’t really go so well with a OO designed API on Apple’s platform. Why should that problem not exist on Android as well? Maybe Google and Apple will rewrite their SDKs to be more functional, but that’s not where they are right now.

Oracle is suing Google and has been suing Google for Android’s use of the Java programming language, which Oracle acquired in its acquisition of Sun. The lawsuit is ridiculous and a destructive waste of resources, but that’s a pretty fair description of the US legal system, so it is likely to continue to be an ongoing concern for Google. If Google were to stop using Java on Android, that might put them in a better position regarding the suit and it’s pretty clear that the licensing on Swift would prevent any similar issue from cropping up between Apple and Google.

Yes, I’m admittedly bias, but it’s important to think about the practical and ulterior motives that Google might have for adopting Swift and not just blindly jump aboard the hype train. Swift is a decent programming language, but it’s not the right solution to every problem and we should only make changes when it makes sense to do so. Let me know what you think on Twitter or Google+.

A Farewell to Apps?

Ars Technica recently posted an article by Larry Seltzer that discusses the possibility of native mobile apps being marginalized by web-based solutions thanks to the increasing advancement of web standards on mobile. Normally, I’d ignore something like this — in most cases when you see the tech press post a headline that’s something akin to for will A kill B, you can rest assured that the content will be fairly overstated and that you’ve been taken by a click-bait title. For the most part, Seltzer does a good job of understanding some of the challenges faced when using web-based technologies to develop but overstates the desirability of having mobile websites replace apps while simultaneously overlooking obvious shortfall of a pure mobile-web only strategy: performance.

JavaScript interpreters have been getting better and better every year and most JITs (just in time compilers) are on track to annually provide “free” performance increases on most browsers for most common use cases. However, they’re not keeping up in terms of raw speed with optimized native code on specialized hardware — for instance, Swift code on Apple’s A8 processor in the iPhone 6S. Another thing to consider is that all of the code on a mobile website must be run through the browser’s JavaScript interpreter.

The idea that native apps aren’t necessarily right for all business needs is pretty obvious and I agree with the author up to that point, but most of the technical issues that he mentions have been addressed by hybrid apps. Hybrid apps using Cordova-based tool-kits such as Ionic address the most common performance issues seen with mobile sites and the lack of web-based APIs for some many hardware features by actually having native level tie-ins. Basically, they implement native API’s a layer below where the developer writes his app logic and expose a JavaScript version of the APIs for the developer to use. From a technical perspective, developers can write any hybrid plugin for any functionality released in a future version of Android or iOS, then access that functionality via JavaScript.

Mobile websites do have one advantage of packaged apps and that’s that they do not have to be distributed via the AppStore. This, however, is not a technical problem, but rather a policy one. Apple still opts to manually approve every single app submission and app update for their iOS store and that creates an artificial delay between developers completing a release and users being able to install it; in cases where the developer is fixing a major security issue, this can be devastating and needlessly exposes users to risk. Still, the advantages of being able to tie directly into device functionality and the performance increases gained make publishing apps via the AppStore mechanism or some enterprise deployment scheme the right choice for the vast majority of apps whether you are developing using native or HTML5 technologies.

Review: Dell Venue 7

tablet-venue-7-mag-965-mixed-set-video-comOver the last few weeks, I’ve had the opportunity to try out the Dell Venue 7 and use it as a test device but also a day to day media tablet.

The Good: The tablet ships with a fairly recent version of Android: 4.2.2. Additionally, the UX is pretty much stock Android — in fact, I’m at a strain to find anywhere that Dell has significantly modified the OS. At $150, it is nothing if not affordable. This low price point is made all the more impressive by the beautiful screen that holds up fairly well to its higher-end competitors.

The Bad: Unlike most popular Android tablets, the Venue is based on an Intel chipset. Taken by itself, that’s not necessarily a bad thing, but there is a trend of developers (especially mobile game developers) tweaking their software to optimize for Tegra and SnapDragon processors — or more broadly put, developers of high-end Android software, have been optimizing for ARM systems. In fact, on a few higher end games, I’ve seen a bit of sputtering on the Venue that I don’t see on the Nexus 7.

The Ugly: Dell’s decision to go with Intel also seems to have affected the industrial design of the tablet. It is noticeably thicker than the Nexus 7 and feels like it is a year or two behind the likes of the Nexus and Nokia’s Sirius tablet in terms of its industrial design aesthetic.

Conclusion: Dell’s’ Venue 7 is not a bad tablet by any means and will probably excel in certain arenas where price matters more than performance: ie corporate deployments. However, if you can spring for the Nexus 7, then you’ll probably be a bit happier with Google’s tablet.

Moto X Review

motox-story-gettoknowI’ve been living with the Moto X Developer Edition for about a week now and have been using it as my daily driver for as long as I’ve had the device.

The Good: The natural language processing in the extended Google Now functionality is impressive to say the least. In my limited and admittedly anecdotal testing, the voice response is the best of any device currently on the market; it beats the pants off of Siri for instance. Though the X does not run stock Android, it’s pretty close to it and is far snappier than any recent skin from other vendors.  Though this might be a bit of a personal quirk, the fact that the device is assembled in the USA is a big plus for me — call it sentiment I suppose.

The Bad:  Pound for pound the camera doesn’t match that of the HTC One. The body is plastic. Despite the plastic being fairly solid and high-end it is still plastic and the device looks a little low-end when stacked against the HTC One; however, it holds up just fine compared to the Galaxy S4, another plastic device.

The Ugly: Beyond the plastic body the phone is pretty well designed. However, it is a bit underwhelming when compared to the marketing that preceded it. In particular, a lot has been made of how customizable the body is but unless you are an AT&T customer (at least in the US), you aren’t going to be able to customize the device’s body any further than “black or white”.

Conclusion: The voice recognition software in the X is impressive, however, beyond that it is basically an Android 4.x device. In a way, one of the best features of the X is how close it follows stock Android and allows the elegance of the system to shine through, only slighted hindered by customizations.


2013 Nexus 7 Review

BQNK5AYCEAAM_vEThis weekend I got a tip that my local Best Buy was selling the new Nexus 7s early, so I jumped in my car and bought one of the 16GB ones. Strangely, they didn’t have a display out or even a sign for the tablet but after speaking to a salesman, he told me that he could sell me one but wasn’t allowed to put the display out yet. I agreed to purchase one and within a few minutes was driving home, excited to unpackage my new device. I’m not going to bother with a description of my unboxing as it was nothing special and frankly those feel a bit fetish-like to me.

The Good: The new Nexus comes with the latest version of Android installed and has Google Play Games, Google’s Game Center competitor, preinstalled. It is impossible to stress how thin and light the Nexus is — I am really impressed by this. The biggest advantage this tablet has over competitors however is speed. It is a performance monster; if you want specs, please take a look at the product page. In short, this is probably the best Android tablet for gaming that is currently on the market and will probably remain so for at least six months — a virtual eon in the Android world.

The Bad: Other than the weight and thinness of the device, there is little to love in the hardware design of the device; it feels like the sort of design that you’d get from an engineer driven company and frankly it doesn’t hold up to Apple’s devices in terms of visual aesthetics. Despite the new Nexus being a performance monster, there don’t seem to be too many apps on the Play Store that really take advantage of that; time will probably solve this problem but for a launch experience it is disappointing. Still, none of that is particularly terrible. However, the device required two (that’s right two!) system updated before I was able to use it. It’s 2013 and I understand, though I am not pleased, that most devices will need a day one patch but to require two patches on day one is ridiculous.

The Ugly: I’ve already dinged Google for the hardware design of the Nexus 7 but I’d be remiss if I didn’t mention the absurd top and bottom bevels of the device — they’re too big and it makes the device look awkward Additionally, as strange as this might sound, the device feels aggressively masculine; it is stark black and comes installed with a metallic blue default background. I’m not sure why marketers feel that Android devices need this weird manly feel (take a look at any Verizon “Droid” ad for an example of what I mean) but I assume this device is meant to appeal to more than just twenty something males, so a more neutral approach might be the way to go.

Conclusion: The Nexus 7 update is about what I’d expect from a hardware device from Google — a lot of power with design as little more than an afterthought. To be fair, it isn’t much worse in terms of user experience than the previous Nexus 7, but since HTC has released the One the bar for hardware design on Android devices has been raised  (at least in my eyes) and Google needs to get with the program.


Ouya Review

imgresCoder Radio listeners will know that I was an early Ouya backer and was a little disappointed in the backer unit. Earlier in the week, I received a consumer unit and know feel that it is appropriate to write a full review of the device; previously I felt that it would be unfair to write up a review of a developer unit.

The Good: The developer unit had some issues with controller lag and buttons often sticking, however, the full release unit addresses those issues for the most part. On a few games, there was some input lag, but that is likely caused by shoddy programming in those games rather than any issue with the input device itself. It might seem a bit picky but input lag is a deal breaker and it is great that the Ouya team has been able to address these issues. The Ouya store was originally extremely slow and that has been for the most part addressed, however, it does appear that the store does not (or often fails to successfully) cache the cover images which causes the store’s images to be slow everytime you load it; still, the store is far more usable than it previously was and some of the lag issues might be due to it being still very near its launch day rush. I was also pleased to see a few interesting independant games on the Ouya that were designed for consoles rather than just being mobile ports from Android.

The Bad: The majority of games available on the Ouya are pretty bad. This is caused less by the laissez-faire approach that Ouya take to its submission process, though that is certainly a contributor, and more by the fact that a lot of the early games are bad ports of touch games. It is more than a little jarring to see games that are excellent on my Nexus 7 perform so badly on the Ouya. Still, it is hard to blame the Ouya for lazy developers, but these poor ports do make me wish there were some kind of submission review process or at least testing for input lag and other very obvious bugs. Another pain point in my review was that the Ouya does not list the full price of a title or the in game purchases available for that game on the game’s store page. This is a little frustrating, since I would like to be able to know if a game is based on a traditional purchase model or a microtransaction model when browsing the store; this issue is by no means a major problem but would be worth further review by the Ouya UX team.

The Ugly: Based on information that has become available from retail and the Kickstarter numbers, the Ouya has sold well, but it is not entirely clear what that means for independent game developers. For instance, a significant emulation community has sprung up around the Ouya and there is some concern that the device may become little more than an emulation box — potentially limiting the market of owners interested in purchasing original independant games on the console. At this point, removing emulators from the Ouya store would be politically damaging for Ouya, but it is also unclear to what degree (if any) emulators are cannibalizing what could have been original game sales.

The Bottom Line: The consumer release of the Ouya solves a lot of the issues found in the developer release and is definitely worth taking  a look at from a consumer perspective. As a developer, the consumer release definitely makes it worth taking another look at, but the issues around emulation and the newness of the platform temper somewhat any enthusiasm in the platform.


HTC One Review

I recently acquired HTC newest Android device the HTC One. I can say with confidence that the One is the best Android phone I’ve seen. In fact, it is really the only one worth buying.  In the One HTC has learned what every other Android device manufacture still fails to understand — hardware design matters.

Unlike its nearest current competitor (the Samsung Galaxy S4) the One is made from something a bit more substantial than plastic.

Of course, the HTC One is still an Android device (sorry Android fans) and there are still a lot of compromises. Some of them don’t really matter (or shouldn’t matter) to the average user, such as the lack of a removable battery. Others, however are a bit more jarring. For instance the One does not have stock Android and, though this version of Sense is by far the best yet, Sense still leaves a lot to be desired.

Still even the downside of Sense isn’t really that bad. For instance, HTC has done a lot of impressive work with the phone’s camera that you lose if you route and install another ROM on the device.

Bottom line, if you are in the market for an Android device, then the HTC One is the one to get. Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC

Play Means War

google-play-logo11Google IO fever is in full swing and, though there are a lot of interesting things coming out of this year’s IO, but there is only one real threat to Apple’s leading position in mobile Monetization. This is Play Games. Play Games functions a lot like Game Center with a bit more and (naturally) a focus on Google+. Play Games allows many of the features that Game Center does but has one killer feature: it is cross platform, supporting Android and iOS. You might wonder why this matters, but the truth is (according to the Apple App Store top grossing and top paid charts) the developers that are making the most money are the game developers. It has been argued that one of the big advantages that iOS has is that it is the prefered platform for mobile game developers — meaning that they release on iOS only or iOS first.

Play Games looks really impressive, but the most attractive aspect of it is that it is a backed Game Center like service that is not run by Apple. Let’s be honest, Apple makes great devices and some pretty good client-side software, but their backend services leave a lot to be desired. Game Center in particular was crippled when Letterpress — one of the first games to actually take advantage some of Game Center’s more advanced functionality — was released and became an overnight success. The reality is that Apple left this door open by not focussing on backend-technologies and now Google is going to be able walk through it.

If Android is able to generate roughly the same revenue as iOS for developers, Apple will have to act quickly to preempt an exodus of developers. This might sound a little overboard, but there is a frustration in the iOS community in all but the most hardcore Apple fans that Apple’s policies are increasingly hostile toward independant developers, but as long as the business case is strongly in Apple’s favor, Apple can do whatever it wants. If Google was able to change the business story, they’d be changing the entire landscape.


Whose Android is it Anyway?

imagesAndroid is now the majority smartphone OS in terms of market share and a significant portion of that Android market is owned by Samsung. What’s interesting is that Samsung is not just shipping Google’s Stock Android but rather is skinning it with its own custom UI. I am not a fan of third party skins on Android, but it seems a very large portion of the consumer base seems to be in love with their Samsung Android phones. It’s good to see a manufacturer doing so well with Android, but it is becoming hard to tell what the relationship of Samsung to Android is. We Google as the operating system vendor and a number of hardware vendors taking that software and selling it on their devices. In this simplified scenario, it sounds a lot like the Microsoft PC manufacturer system; where Microsoft licenses Windows to them (for a fee) and those vendors are allowed to ship Windows with (optionally) some of their own software installed but not real modifications to Windows itself. In the Android world, we have a slightly different story. Manufacturers take Android but also (can and often do) modifications to it before they bring it to market. The end result of this seems to be that a lot of  non-tech consumers are identifying with Samsung (or another hardware vendor) rather that the Android brand.

This seems a bit strange but also inevitable to me. That’s mostly because Google has dropped the ball on branding Android from day one. Sure the tech community is fully aware of Google’s relationship to Android, but the tech community is a relatively small community and (though I hate to say it) not terribly important outside a certain amount of developers the ecosystem needs to make apps. In the early days of Android, Google allowed Verizon to coop the Android brand with its “Droid” campaign. This was a terrible blunder. Anecdotally, I have had conversations with consumers that had seen the campaign but had no idea what Android is and that it was from Google. When you ask a “normal person” who makes Windows or Mac OS X, they pretty much all know.

The question becomes what influence if any does Google actually have over Android? Sure they have terms for using their foolishly named Play Store (notice that it is no longer branded “Android”) and Google Apps apps, but that feels like a wiffle ball bat rather than Louisville Slugger — most of those apps could be easily replaced if a large manufacturer (ie Samsung) wanted to. Beyond that Google can’t really do anything. Due to Android’s licensing terms Google is not in a great position for any sort negotiations.

It might sound silly now but there is a very real possibility that Android could live on with manufacturers’ support (again mainly Samsung) even without Google’s support. To me, this sounds like a very real possibility as Google seems to be favoring Chrome and web technologies over Android’s Java based technologies. None of this is really bad, but it just makes me wonder where Android would be had Google stuck to its guns regarding branding and maintaining control of the project and code; before all of you write in, yes I know attempting to lock up the code would have been legally difficult given the OSs license, but I do believe we would have a better operating system for it. Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, IN