Google recently announced the launch of Android Instant Apps, a new technology which allows just the bare minumum of an App to be downloaded from links, bypassing the Play Store. This sounds cool enough on its own, but the implications of this reach far deeper than at first appears, and could end up changing the entire internet.
Updating the UI with background ViewModel tasks
- Carl Whalley 0 Comments
The ViewModel - your single source of truth
Android developers will have heard about the not-so-quiet revolution introduced at Google I/O 2018 in the form of "JetPack". This is an awesome set of tools, software components and just plain know-how which Google put together to let everyone use the best-practice they've evolved into using themselves. Sure, you can continue with your current frameworks and libraries, it's just that now, zillions of the wheels you might be tempted to reinvent are all laid out for you, and in a way that makes using them a really smart choice.
Jetpack covers UI navigation, tasks, db etc and you can read more about it here. What caught my attention was the way an old problem I've covered before can be tackled, and since you don't need an oracle to see where languages on Android are headed, I chose Kotlin rather than Java. The new killer component is called the ViewModel, and it's purpose it to hold non-UI data which lives independently from the usual app lifecycle. Even better - it can run methods in this new "outside the Activity" place, which means we have a new way to run background tasks. ViewModel predates JetPack, but is considered one of it's central components now.
What's presented here is a way to keep the UI up to date even when the app is backgrounded. There are plenty of ViewModel tutorials around, such as here, here and here, so I'll skim over the basics and focus on the backgrounded UI part, which needs some care to get right.
The source for this project is available on GitHub, and if you just want to run it, allow unknown sources on your Android device and click here.
Android Things 1.0 released
- Carl Whalley 0 Comments
Things are now stable
After eight developer preview releases, Android Things jumps directly from 0.8 to 1.0 bringing 4 new production target SoM (System on module) boards, enhanced security, fleet device management and a guaranteed automatic 3 year platform update provided by Google themselves.
This is another step on the road to global computing dominance at the point the user interacts with the device. They already own mobile, and it looks like the same strategy of giving away the hard stuff needed to get IoT projects up and running for free, is playing out nicely. They are doing the same with AI and TensorFlow, and although that runs on Android Things, it's for another discussion.
Many people were aware the dev previews of Android Things ran on the Raspberry Pi. With the release on 1.0, however, there's a clear distinction between dev boards and production ones, and unfortunately none of the Pi's made it through the stringent security/performance/compatibility requirements. The advice is to keep them for prototyping, but not for real world devices.
The US/China trade ban might mean ZTE can't officially use Android
- Carl Whalley 0 Comments
Trade War
Things turned sour very quickly following US President Donald Trumps sanctions on Chinese goods and services.
The impact on the mobile industry could be far reaching, since Android is enjoying a 78% global market share on handsets. Fearing losing economic power to China, the Trump administration said the measures were a response to a 7-month investigation into Chinese "unfair practices", including spying, hacking and what amounted to the extortion of US companies in order to gain access to the Chinese market.
Concern over an imminent trade war sent the Dow jones 700 points down on the news.
Many Chinese handsets use their own variation of the "pure" AOSP Android source tree without any Google services, such as Google Play and Maps. However, these are rarely seen outside China where a handset lacking such support is a difficult sell.
The About Process
- Carl Whalley 0 Comments
How about that?
Here's the third in a series covering some handy tools which an Android developer can wire into their build system. Ideally, this would be right when the project is started, but adding to an existing one shouldn't be too difficult either.
This one's focused on something we're all familiar with. Pretty much every app needs some way inside the app to identify itself further to the user, and the usual way is an About box. A basic one might just show the version number, but more sophisticated ones can vary according to the kind of build it relates to, for example debug or release. There are plenty of other areas it's useful to cover too, for example does this build expire? Where can the user report bugs? Who wrote it? Even functionality, such as a "Rate us" link, can be added as boilerplate then tweaked later. Or your logo, cutely being animated ;-)
When you've done this a few times too many (!) you realise there ought to be a way to automate most of this, and a skeleton one could be used so the developer can, ahem, flesh out the apps info later with most of the basics being dealt with already.
The source for this project is available on GitHub, and if you just want to run the app, allow unknown sources on your Android device and click here.
The Versioning Process
- Carl Whalley 0 Comments
Where did that APK come from?
Welcome to the second in a short series covering how to give the Android build process a little boost from the get-go.
Once an APK is built and distributed, developers know they can kiss goodbye to controlling where it ends up. This can be a problem with testing, maintenance etc, and without further care such as clear versioning identification in the app itself, make tracing bugs harder. For example, if every released APK was just called MyApp.apk, how can you tell the one released this morning from the one released last month?
Versioning systems such as Subversion, Git etc support these id's, so it's possible to match up a particular check in with the files needed to create that APK.
What's described here is a way to automatically add those version details to the produced APK file itself, so you'll end up with MyApp-debug-beta-1.1.0-368-dev.apk or whatever. The filename comes from a combination of the build variant name, the id in the version system and the source machine (eg. a CI build, or a local developer, "dev") which created it. The example uses subversion as the CM.
This project is available on GitHub.
The Signing Process
- Carl Whalley 0 Comments
Release early, release often
This is the first in a short series collecting together a few techniques for enhancing the build process for Android. It's aimed any anyone starting a project who wants a little more productivity than the default startup wizards in Android Studio (3.1) offers.
Sometimes it can be useful to see how release builds measure up early on in a project's development.
This might be to keep an eye on the final APK size, to see what performance is like without the debug code or to make pre-releases available to testers, etc. Android Studio (3.1) does a great job of setting up the builds for new projects in debug, but the variant for release isn't really there from the get-go. This is most likely because everyone's signing process is different.
Sure, when you try to run in release mode you're prompted for all the signing credentials, which is OK for occasional signed builds. However, a solid, repeatable signing system, which works unaltered with automated building tools such as Jenkins, is useful to slot into the dev process early on.
The full project presented here is available on GitHub.
Android P developer preview released
- Carl Whalley 0 Comments
It's time for P
So the Android P dev preview is here, and I've had a little play to see what's new. I did this bearing in mind, as usual, these are aimed at brave developers only, who most definitely are not scared of the odd bug or two they might encounter. They also must happen to have a spare Pixel handset lying around if they want it on hardware, with the rest of us having to make do with the emulator ;-) In the end I didn't encounter anything serious, and in fact found it pretty stable and usable.
Google are calling this an alpha build, and the roadmap is expected to deliver the final release "Q318". They publish a list of known issues and make it easy for developers to file P related bugs.
To get the Android P preview on your Pixel, follow the installation guide. The emulator is much easier - just fire up a current Android Studio, create a new emulator and at the "Platform" prompt you should see "Android P" appear as an option now that Google have made it available on their servers.
Android P developer preview coming in March 2018?
- Carl Whalley 0 Comments
Release date rumors
As usual, Google will release a developer preview of the next version of Android well ahead of the final version in order to let developers get their apps ready for it from the get-go. This pattern hasn't always been the case, but a couple of years back they let it be known that the aim is to stabilize releases annually.
As eyes turn to another upcoming Google I/O, talk of the next developer preview for Android P is heating up, since the previews for Android N and O both arrived in March. Evan Blass - renowned for his accurate predictions - has Tweeted he expects the date to be released then, too.
The speculation over exactly what the "P" will stand for has hardly begun.
However, it is interesting to note that Wednesday 14th March is Pi day - called because it's on 03/14/2018. A lovely day for an announcement, don't you think?
Android Things Launcher
- Carl Whalley 0 Comments
Android Things Development
When Googles IoT platform, Android Things was launched, it caused some rethinking for time-served Android developers.
This was necessary in order to adapt to all the anticipated hardware applications it will be used for, and it meant many familar features had to be removed. The most radical of these was the default UI, since the UI is now optional. This doesn't mean there isn't one, it just means you have to roll your own entirely. Of course you do this using the standard Android View framework you're used to in its entirety, but by default, the system supplies nothing. That means there's no status bar, no navigation bar, no back button etc - and your device has no home screen.
The idea with Android Things is you're creating a hardware applicance. Typically, this runs only one app and it's this app which starts up when your device is booted, That's the production scenario which is the one your end user expects. For development, this can be a little restrictive. You can certainly install many different apps onto Android Things devices, and developers often do this to try multiple versions of their apps, run small self-contained test apps or measure performance variants of the same one, for example. This is cumbersome without a home screen or some kind of launcher, because each has to be built and installed fresh so it "wins" in the boot race.
