If you upgrade Android Studio 3.4 to 3.5, you may run into a problem where
reformatting an XML file (e.g., via Ctrl-Alt-L) reorders the XML elements in
each level of the hierarchy. So, for example, you might have a <uses-permission>
before <application> in your <manifest> element; reformatting would flip
the order of those elements. It seems to be alphabetizing them.
For the manifest, this might almost be survivable. However, lots of things in
Android are dependent upon XML element order, such as the children of a LinearLayout,
the children of <menu>, the children of <layer-list>, and so on.
The original issue for this appears to be this one.
It is marked as “fixed”, though that appears to be overly optimistic. A number
of developers are running into the problem, filing other issues and
asking Stack Overflow questions.
I ran into it myself in my “daily driver” Android Studio setup.
Based on some experiments, the problem seems to be limited to upgraders.
I cannot reproduce the effect with a fresh Android Studio 3.5 installation.
The simple fix is outlined in the aforementioned Stack Overflow question:
-
Go into the Settings screen (File > Settings, or Apple > Settings, depending on your OS)
-
Navigate into Editor > Code Style > XML
-
In the upper-right of that dialog, choose Set From > Predefined Style > Android
The real problem lies in the “Arrangement” tab in that XML code style screen.
After an upgrade from 3.4 to 3.5, you wind up with arrangement rules like these:
There may be a more surgical fix that can be applied to those rules, editing
each of them to limit them to attributes, but I have not tried this. Applying
the Android predefined style replaces the buggy post-upgrade rules with valid
rules:
Because the problem lies with an upgrade, it might be tricky for Google to fix
it with yet another upgrade to some future 3.5.1 version. With luck, they’ll find a solution.
Regardless, when you upgrade to Android Studio 3.5 from 3.4, double-check these
arrangement rules and fix them if they appear broken.
Many thanks to Birju Vachhani for his writeup of the steps to fix the problem!
—Aug 21, 2019
Subscribers now have
access to Version 0.1 of Elements of Kotlin Coroutines,
in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page to download it,
or set up an account and subscribe!
Originally, I thought that I would just have a chapter on basic coroutines in
Elements of Kotlin. However, I quickly realized that to cover enough
for Android app developers, I would need a lot more than just one chapter.
Elements of Kotlin Coroutines is the result.
As with all my 0.x editions, this one is partially complete, with a number
of placeholders for future chapters. However, it covers the basics of coroutines,
including suspend functions and Flow. It also includes a “hands-on” appendix
that walks you through converting a small RxJava-based app to use coroutines.
And most of the samples are in the Klassbook,
so you can run and modify them from the comfort of your favorite Web browser.
This book will get updated every month or two for a while, as I flesh out the
remaining material.
—Aug 19, 2019
Android Studio offers type hints for Kotlin code. Basically, the IDE adds “fake”
type declarations where your code does not have them, for places where the compiler
is inferring the type:
The types with the gray backgrounds (e.g., PackageInstaller) are added by the
IDE. Other types (e.g., Uri) are really there in the typed-in code.
This can be handy for helping to ensure that your types are being inferred the
way that you expect. They are also good for educational scenarios, such as
conference presentations, to help make the implicit more
explicit for people spending a limited amount of time in the code.
I got these by default with IntelliJ IDEA, and I wanted to enable them on Android
Studio, particularly for tomorrow’s Android Summit workshop.
This is possible, but you have to dig a bit in Settings
to find them. Or, you can stumble across a helpful Stack Overflow answer.
In Settings > Editor > General > Appearance, you need to check “Show parameter name hints”:
Then, click the adjacent “Configure…” button and choose Kotlin from the
“Language” drop-down in the resulting dialog:
The “Options” set of checkboxes are where you indicate the scenarios in which
you want the type hints to show up. The large text field above those checkboxes
are a blacklist, indicating situations where the IDE will skip the type hints,
even if they otherwise would qualify based on your “Options” choices.
—Aug 13, 2019
Huawei’s rumored operating system
is now less of a rumor and more of a reality. At the Huawei Developer Conference,
they announced Harmony OS,
to be used on the Honor Vision TV and perhaps
the Honor Smart Screen.
They indicated that they would continue to use Android on phones and tablets…
but that is contingent on the current trade ban. As XDA Developers’ Mishaal Rahman noted:
Yet, this new OS is still “plan B” for the Chinese technology giant, since Huawei will need to solve the biggest hole in the adoption of Harmony OS: the app ecosystem. Huawei is building up its AppGallery platform as an alternative to the Google Play Store, and this week the company unveiled Huawei Mobile Services as an alternative to Google Play Services. Huawei is in the process of building its own ecosystem, and if the trade ban doesn’t lift by the end of this year or early next year, then Huawei will be forced to switch to Harmony OS for its new devices, including the upcoming Huawei Mate 30 series. In fact, Richard Yu confirmed that the Mate 30 did not receive certification to use Google Play Services before the trade ban was enacted, so Huawei is considering using Harmony OS on the device if the ban isn’t lifted in time.
Little of this shocks me. Even if the trade ban gets relaxed enough that
Huawei can continue with Android internationally, I would expect them to start
shipping Harmony OS devices within China as soon as they decide that it is practical.
However, there were some particularly interesting nuggets in XDA’s coverage
of the announcement, with similarly-interesting follow-on effects.
Open Source?
From the XDA post:
Finally, Huawei announced its plans to open-source Harmony OS, establish an open-source foundation, and create an open-source community for collaboration.
Simply making an operating system open source is insufficient on its own to guarantee
success. If it were, Ubuntu Phone and Firefox OS would be significant players. Unfortunately,
neither “crossed the chasm”, in part due to lack of manufacturer and carrier
support.
Huawei is a manufacturer, and their moves are likely to result in at least some measure
of carrier support, at least within China. Hence, Harmony OS has a significant advantage
over other attempts to compete with the Android/iOS duopoly.
If Harmony OS actually does wind up in a truly independent foundation, that would make
it easier for other manufacturers to adopt it. On the other hand, it could be that
the foundation is a pleasant fiction, much along the lines of how
the Open Handset Alliance
turned out. And, if you do not recognize the name “the Open Handset Alliance”… well,
that’s not surprising. It is the closest thing that Android has had to a foundation
for overseeing it. Needless to say, Android is very firmly in Google’s control,
and it remains to be seen how Huawei handles Harmony OS in this regard.
App Compatibility?
From the XDA post:
Developers will be able to use Huawei’s ARK Compiler to compile code from multiple languages like C/C++, Java, and Kotlin for Harmony OS. Huawei will be providing an IDE to support app development across multiple device types, including televisions, car kits, smart speakers, smartphones, smartwatches, and more… Harmony OS is not compatible with Android apps out-of-the-box, confirms Richard Yu, CEO of Huawei Consumer Business Group. That means you won’t be able to merely side-load any Android app of your choosing. In a press conference, Mr. Yu says that app developers will have to make “small changes” to their apps in order to compile them to run on Harmony OS. He states that it is “very easy” to transfer Android apps to Harmony OS.
All of this information comes from media events, so we have to assume there is
some amount of “spin” here. Certainly, if Harmony OS supports Java and Kotlin,
it would be easier to migrate an Android app to Harmony OS than, say, iOS. However,
“easy” is quite a high hurdle to reach in terms of the level of effort of app
migration.
One way that it could be “easy” is if they take the approach that BlackBerry
did with their early Android efforts. Before BlackBerry retired BlackBerry OS and
moved to Android, they had an Android runtime for BlackBerry OS. Developers could
use some tools to convert an Android APK into a different file (BAR), and a BAR
could be distributed to a BlackBerry OS device. This approach failed for BlackBerry
for several reasons, none of which would preclude Huawei from trying and perhaps
succeeding. It might still require a fair amount of work to port an Android
app to be a native Harmony OS app, though, if this is Huawei’s approach.
Another possibility for this being “easy” is if Huawei
basically adopts the Android SDK. Basically, they would have their own SDK
with the same class structure, perhaps with some cosmetic changes (e.g., you
have to convert android. to harmony. in packages). I would be somewhat surprised
if they went this route, as it ties them to Google and Android more than they
might like. It also raises interesting parallels to the Oracle v. Google series
of lawsuits, with Huawei in the role of Google.
Yet another possibility is some sort of a converter, that can take code that
makes Android SDK calls and convert it to making Harmony OS SDK calls instead.
That would be difficult to pull off, since it has to convert both app code
and libraries. But the Jetifier (sorta) accomplished it for converting Android Support Library
references to AndroidX ones, so I certainly cannot rule it out.
Regardless, we would need more details to be able to judge whether moving an
app to Harmony OS will really be “easy”.
Ratcheting Interest?
However, Huawei does not need getting an app over to Harmony OS to be easy.
It simply needs such a move to be compelling.
Huawei sells more devices than does Apple. If Apple can convince developers to
write apps for iOS, Huawei should be able to convince developers to write apps
for Harmony OS.
The catch is that Apple already has a large installed base of iOS users. Huawei
has zero users of Harmony OS today. And unless Huawei has better success than a
lot of manufacturers have had with smart TVs and smart displays, they will still
have relatively few users by the time that they start shipping Harmony OS phones. Huawei will
only have success selling Harmony OS phones if there is a critical mass of
apps for those devices.
However, once again, Huawei has an advantage: initially, they might not need
the world’s apps. They might only need China’s apps. One imagines that they can
broker deals with major Chinese app brands, and a good developer outreach program
can help pull in apps from “the long tail” of the app distribution curve. If they
can get a reasonable Chinese app catalog at the outset, success can breed success, with
Harmony OS device sales convincing more Chinese developers to port their apps to
Harmony OS, helping to improve sales of those devices, etc.
If Huawei is able to convert their existing domestic smartphone sales over to Harmony OS,
non-Chinese developers already distributing to China would need to take notice and
consider Harmony OS ports of their own. This could accelerate if Huawei is open enough
with Harmony OS to convince some other manufacturers to adopt it. And it would
accelerate if Huawei starts selling Harmony OS devices outside of China.
You will know when Huawei thinks that they have succeeded: when they start offering
support for converting Harmony OS apps to Android, believing that there is enough
“Harmony first” development going on to warrant that kind of support.
What Now?
If you write apps for Android TV, you might peek at the Honor Vision TV and Harmony OS,
to see if there are any “first-mover” sorts of advantages that you can
leverage.
For Chinese developers, pay very close attention to what Huawei does. Even if
you do not plan on shipping an app for TVs, you might experiment with Harmony OS
on a TV, just to get a better sense for what Harmony OS development is like.
That will help you decide how to react if and when Huawei starts selling
Harmony OS phones.
And, if you are a “bleeding edge” sort of developer anyway, Harmony OS
represents an interesting opportunity, comparable to those poking at Google’s
Fuchsia right now. Fuchsia advocates might scoff at that notion, and right now,
Fuchsia is ahead simply by being publicly available, if not on shipping production
hardware. However, I think that Huawei has an easier path to 250 million
Harmony OS devices than Google does for getting to 250 million Fuchsia devices.
Huawei already sells more devices than that, whereas Google would need to convince
other manufacturers to distribute Fuchsia-powered devices.
Huawei still has to execute, and there are any number of ways that Harmony OS
could wind up being “a whole lot of nothing”. After all, Samsung’s Tizen was
in a similar position and has not had much success with developers or mobile devices.
For everyone else… check back in 2020, and let’s see where Huawei and Harmony
OS are.
—Aug 10, 2019
At next week’s Android Summit, I will be leading a
workshop, “From RxJava to Coroutines”. The idea is that we would take a small
Retrofit-and-Room app and rewrite it to use coroutines rather than RxJava.
When writing the app, though, I realized that Room did not yet support channels
or flows. The app relied upon Room’s invalidation tracking to deliver fresh results
when the database changed. The only way that I could get a Flow was to have
the DAO use Flowable, then use coroutines’ Reactive Streams support to convert
the Flowable to a Flow. This worked, but it meant that I had leave RxJava
in the app, to get the Flowable.
And so I prayed to Saint Yiğit
that Room would get Flow support in time for the Summit.
Yesterday, my prayers were answered! Room 2.2.0-alpha02 advertised Flow
support, and in light testing, it works as expected! So now your DAO can have
stuff like:
@Query("SELECT * FROM observations ORDER BY timestamp DESC")
abstract fun loadFlow(): Flow<List<ObservationEntity>>
…and you can consume that Flow from within your favorite coroutine builder
(e.g., launch()) or a suspend function.
Of course, not only is this Room version an alpha, but Flow itself is still
in a release candidate state right now. Experimenting with this stuff is fine,
but be careful about shipping production code using this. At least wait until the beta.
But, if you are “coroutines-curious” and are attending the Android Summit,
come to my workshop, and I’ll show you how to nuke RxJava from orbit.
UPDATE: Many thanks to Dany Aguacate,
who implemented the Flow support in Room!
—Aug 08, 2019
