Android 11 Beta Gets Postponed

Share if the site was helpful

Android 11 Beta Gets Postponed

Android 11 first made its debut as a developer beta back in March, and it was all set to go public at the start of June.  Unfortunately, the pattern of event delays and cancellations will be continuing with the new release.  The public beta has officially been postponed. And most Pixel users will have to wait before seeing what’s on the horizon.

We’ll Get There Soon:

Yesterday the Android Developers Twitter account tweeted “We are excited to tell you more about Android 11, but now is not the time to celebrate.  We are postponing the June 3rd event and beta release.  We’ll be back with more on Android 11, soon.”  Originally set to be revealed at Google I/O 2020 (also cancelled), the beta would have taken the current developer beta and made it public to the world.

What does that mean?  Right now anyone with a Pixel can still get Android 11 on their phone, it just takes a little work. Here’s a post about how to flash your device. Flashing your phone allows you to load a different version of Android as long as you have access to the system image.  And that’s available on for anyone who wants it.  There are a few critical things to note before flashing your device. The biggest being that it erases all data from your device.  So if you wish to go this route make sure you have everything backed up!

Android 11 For Now:

Otherwise you can just hold off on upgrading to Android 11 until it’s a more streamlined process (i.e. when the public beta is released). But in the meantime you can still start learning about some of the new features that Android 11 is introducing.  From Facebook-esque chat bubbles to new notification interactions, there’s plenty to explore.

That being said, it doesn’t seem there is anything revolutionary being released in 11.  All the same its changes are welcome.  Improvements to things like permission requests and user security are always a good thing, and for the most part shouldn’t require legacy apps to change too much.  As mentioned in another post here at RootJunky an expansion on Project Mainline will also allow Google to update key parts of the OS via Google Play Store.  These will seem like subtle changes to the user, but their impacts can be huge.

Hopefully we’ll see Android 11 go public in the near future, but for now we’ll have to be patient.  What are your thoughts on the new beta?  Let us know in the comments below.

Working With WebViews

Share if the site was helpful

Working With WebViews

It’s a different kind of www, but working with WebViews can completely change your development potential.  If you’re an experienced developer but have very little mobile app experience, WebViews might be exactly what you’re looking for.

Taking a Step Back:

Before diving into this newly hyped up feature, let’s take a second to actually explain what a webview is. To your app it’s not much more than a black box (the term for something that performs logic you’re unaware of).  A lot of stuff happens in a webview but for the most part your app can ignore it.  It’s just another View the same way Buttons or TextViews are.

But webviews are so much more to your user.  They’re a view that displays a web browser and allows the user to navigate to new web pages.  Access to the entire internet with almost zero development!  There’s a little set up logic but that’s all you need.

So why would you want this?  Well usually the answer is work efficiency.  If you’re building an app and a website, it’s not ideal to do twice the work.  It is ideal to build good experiences for your userbase though, and that’s why not everything is a webview.  Native app experiences will be a lot smoother and responsive, whereas with a webview you’ll have to wait for everything to load on the page.  That being said there are uses for either scenario

Setting It Up:

Setting up a WebView in your app is extremely simple.  As with most views there are two parts to it, defining the view in your xml activity and then syncing it up with an actual WebView object in your java/kotlin code.  To declare the view in your xml you’ll create it the same way as other views:




               android:layout_height="match_parent" />


And that’s it!  Now to sync it up with your logic you’ll need to create an instance of the WebView class and anchor it to the xml view.  Using a popular Android library like Butterknife it looks something like this:


        WebView webView;

Then you’ll need to implement WebViewClientListener and add this associated method:


And finally we can override these three methods:


        public void onPageStarted(final WebView view, final String url, final Bitmap favicon) {

            //Do something when a page starts loading



        public void onPageFinished(final WebView view, final String url) {

            //Do something when a page finishes loading



        public void onPageCommitVisible(final WebView view, final String url) {

            //Do something when a page is visible


What we’ve done at this point is added a WebView to our screen.  We’ve also added methods to respond whenever a page changes on the WebView.  What this means is our app is now able to natively respond to new URLs a user loads in the WebView.  What you do at this point is up to you and your creative limits!

Interacting With WebViews:

While we said earlier that a WebView is a black box, there are a couple different ways you can interact with them.  Like we saw above you can see the URLs that are loaded and use those in your apps. But you can also get much more intertwined by either listening for JavaScript methods or calling JavaScript methods on the WebView.  To do these you need to know what’s going on with the website users are looking at, but it can create some really cool experiences.

You can also track what cookies are on the site.  There are a couple useful interactions to be aware of, and we’ll cover them all in another post soon.  In the meantime you should try adding a WebView to your apps and let us know what you think in the comments below.




Google Maps Crashes Around The World

Share if the site was helpful

Google Maps Crashes Around The World

A few days ago, panic struck apps around the world.  In a nightmarish turn for any developer, every app using Google Maps crashed.  Not just once, but every time it attempted to load Google Maps.  The result being if you launched the Maps SDK on launch, 0% of users could open your app.  Not. Good.

Fallout and Recovery:

A little while after the crisis bubbled up Google released a hotfix.  But users who had experienced the crash were doomed to continue experiencing it.  That is until they either cleared their cache or uninstalled the app.  Developers were forced to release their own updates with a suggested bit of solution code.  Unfortunately, even with this fix only users who updated their app could be free of the bug.

Apps are still climbing back from this fall, but the experience brings up a couple key components of app development that we’ve talked about here at RootJunky before.  These include error handling, dealing with live production changes, and utilizing crash reporting tools like Firebase.

Ignorance Is NOT Bliss:

When it comes to app crashes, it is never a good thing to turn a blind eye.  Something like the above may have occurred that isn’t necessarily your app’s fault, but you still need to know when to react.  Google has now released a new version of Google Play Services that fixes the issue, but this took days and every hour counts when it comes to things like app ratings and revenue.

Being aware of the crash at hour 1 gives your team time to evaluate the issue and begin investigating possible solutions.  And let’s not forget about the pesky fact that ALL developers introduce bugs sometimes.  Seeing your new app version start to crash more often than others can be crucial if you need to address something before it is released to all users.  Long story short: without crash reporting from a tool like Firebase you’re up a creek without a paddle.

Error Handling:

When our apps do experience issues, it’s also important they are able to be handled correctly.  Sometimes crashing an app can be the best outcome of a situation, but what about scenarios where the issue isn’t that serious?  For example what if our app couldn’t load a user’s info.  Would it be better to display a message to the user telling them to try again later?  Or would it be better to inexplicably crash the app on them?

This is where error handling comes in.  Using things such as try-catch statements can allow us to handle issues in the app’s code without destroying the user’s experience.  In the “try” section of your code you attempt to do something.  And then in the “catch” section you handle any error that may have taken place.  If you’ve ever built an app you’ve undoubtedly used try-catch, but are you using it in all the right places?

Remote Config to the Rescue?

One other option that we’ve discussed before is Remote Config.  Using this tool you have the ability to change settings of your app remotely without having to release an update.  Let’s relate this to the Maps SDK crash.  We could set something up in our code to check if a Remote Config value shouldInitializeMaps is true.  If so then we load a map, otherwise don’t even present this option to a user.  By setting things up this way we now have the option to shut off Google Maps if it becomes problematic.

Bill Gates captured it quite well when he said “It’s fine to celebrate success but it is more important to heed the lessons of failure”.  When things go wrong we should view them as a learning opportunity for how to make our apps even stronger down the road.


en English