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:

         <WebView

               android:id="@+id/webview"

               android:layout_width="match_parent"

               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:

        @BindView(R.id.webview)

        WebView webView;

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

        webView.setWebViewClientListener(this);

And finally we can override these three methods:

        @Override

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

            //Do something when a page starts loading

        }

        @Override

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

            //Do something when a page finishes loading

        }

        @Override

        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.

 

Google Looks Ahead With 2020 Vision

Share if the site was helpful

Google Looks Ahead With 2020 Vision

With 2020 upon us there’s surely been an influx of not only new years resolutions, but new decade resolutions.  Sure, you may have already fallen off on a couple of them, but we’re all looking to make this decade a better one than the last.  Well, resolutions aren’t just for the individual.  Google is looking forward to 2020 as another opportunity to grow and create a new world of tech.  Starting with Google I/O 2020.

Revisiting 2019:

The company’s annual developer conference takes place every spring, and this year will be no different with the dates being set for May 12-14.  Last year was full of useful talks sharing new advances in the ways we can envision, build, and share apps.  And beyond the scope of Android there were demonstrations of impressive advances on tech such as Google Assistant.

A lot has happened since 2019’s conference.  Android has moved on to Android X and away from the classic dessert naming convention.  New tech like the Pixel 4 and old tech like Google Glasses came back into being.  And languages like Flutter grew to gain more widespread adoption.  Here are some of the things we should prep to see continuing this tradition in 2020:

Android Hardware:

Odds are we’ll be seeing a Pixel 4a at Google I/O 2020.  We saw the 3a last year, and after hearing about how the 4 didn’t quite live up to expectations it only seems natural for a budget version to emerge.  The price will likely be lower due to weaker specs, but I would bet the 4a still runs on the newest Android version as is tradition with other Pixel devices.

I’m not that excited about the Pixel 4a though, what really captures my interest is the possibility of a Pixel watch.  We’ve seen Apple absolutely dominate the wearables market over the past few years with Samsung making a small dent as well. But loyal Android fans have been waiting for quite some time to see a watch developed by Google emerge into the mix.  If this ends up being revealed, you can be sure it will be awe inspiring.

Android Software:

And with both of these new pieces of hardware you can be sure that they will come loaded with the new software…meaning Android 11 of course.  Very little is known about it at this time, but Google has been steering towards higher security and privacy for their users over the past few rounds of Android.  With new permissions coming into the mix and higher consolidation between apps information is guarded more tightly than ever.  I’m sure Android 11 will crack down even harder on this.

But phones aren’t all about security.  We want the user to actually enjoy their experience, so it’s natural to assume we’ll see a couple new features as well.  With things like multi resume and picture in picture emerging over the past few years it will be interesting to see what else Google can bring to the table.

All the Rest:

                There is of course more the Google I/O than Android, that’s just where our focus at RootJunky tends to gravitate.  In an ever changing landscape of Machine Learning and Augmented Reality we’re sure to see some great advances on both of these fronts.  Google Assistant is probably going to come in stronger than ever with another killer demonstration showing how well it can react to a user’s voice commands.

And Augmented Reality will see its next wave of realistic lighting and other effects.  Personally I think we might see some interesting interactions with outside forces. Imagine a character being blown around on your screen because it’s actually windy outside.  The sky is the limit when you get creative with it!

Mark your calendars for Google I/O 2020, it’s going to be a good one. And be sure to let us know in the comments below what you’re most excited to see this year.

en English
X