The Inside Scoop on Internal App Sharing

Share if the site was helpful

The Inside Scoop on Internal App Sharing

 

            Testing your apps is a crucial component in a successful release.  Every time you issue updates to your app you run the risk of introducing bugs that can ruin a user’s experience.  We do what we can with unit and UI tests to check and limit these bugs, but some still manage to slip by (no one’s perfect!). So how can we deal with these bugs before they actually get into the hands of a user?

 

Internal App Sharing:

 

            Whether you’re a solo developer or working for a larger company, Internal App Sharing can help with this.  It essentially allows you to upload a second version of your app onto the Google Play Store.  It’s a private upload though that’s only available to people you share the URL with.  What this does is allow you to keep your production app intact while simultaneously letting a select group of people test the new version.

It’s somewhat similar to the beta feature that has been available for quite some time.  But the key difference here is that the app is private. It’s only available to those friends/family/coworkers that you choose to share it with.  It offers a great way for you to limit your testing to people you know. Very aptly names Internal App Sharing!

 

Some Caveats:

 

            Internal App Sharing was first released to us at Google I/O this year so it’s still very new.  After playing around with it and reading the documentation there are a few things to note.  First off, there is a maximum of 100 users that can download the app using this link. So if you are crazy popular then you won’t be able to let all of your friends test! Realistically this probably isn’t a big deal as 100 testers should be plenty to see major bugs that are introduced, but all the same the limit exists.

 

Another limit that might impose a little more on you is that the app you upload has to have a matching package name.  For most cases this will always match since it’s the same app, but if you have different schemes you’re building your app with (debug vs release) that offer different features you’ll need to make sure nothing is different in those package names. Other than these limits though it’s a fairly straightforward process with a positive experience.

 

I currently use Internal App Sharing and I would recommend that you check it out as well!  It’s a great way to share a build of your app with changes to those closest to you before officially releasing anything to the public.  What are your thoughts on the feature?  Let us know in the comments below.

Android Dev Summit Is Coming!

Share if the site was helpful

Android Dev Summit Is Coming!

If you’re an Android junky then you’re probably still coming off of this years Google I/O high.  We saw some really cool stuff we can leverage in our apps to create great user experiences.  But the development fun is far from over.  It’s already time to mark your calendars for another big upcoming development conference: Android Dev Summit 2019.

Last Year’s Summit:

Last year at Android’s annual developer conference we saw some big changes.  These included things like App Bundles in place of old APKs to reduce the size of your app.  On average app sizes were decreased 8% and some saw much bigger changes (30+ percent!). The idea behind an App Bundle is to only download the resources needed for your specific phone/version instead of downloading everything and then using what you need.  We’ll actually be going into detail on it in another post soon.

That was a big size change, but a big code change was focused around Jetpack.  Another topic we’ll dive into further with some tutorials if you haven’t applied it yet is updating your legacy support libraries to AndroidX. Basically your app functions the same way, but moving forward things are a lot cleaner on the Android support library!

What’s Coming This Year?

Those are some good topics that you should definitely be leveraging in your apps today, but the purpose of this post is to ask what may be coming this year.  And if Google I/O is any indicator of it, then the answer is a lot.  There’s not an official roster of topics posted yet, but we’ll likely be seeing deeper dives into some of the topics covered at I/O such as Android Q gestures and dark mode. And now with Kotlin as the preferred language for Android development I’m sure we’ll see some technical dives into what’s happening under the hood.

Along with some of these unique sessions come other perks for those of you attending in person.  There will be more hands on experiences with product demos, and you’ll be able to meet with members of Android’s team and discuss topics in more detail.  If you’re interested in attending then here’s a huge plus: ITS FREE!  Yep no purchase necessary for a ticket, but you do haver to be accepted by invite, so there are no guarantees.  Still, applications are open until August 15thso I’d highly recommend applying!

We’re Almost There:

There are a plethora of changes that could get whole sessions focused around them (permission changes, internal app sharing, optimizations).  And if you want to make sure you’re up to date on it then keep an eye on our page or on the official Android Dev Summit page.  If you can’t make it in person (Cali isn’t just around the corner for some of us), then don’t worry.  All the sessions will be live streamed on the site as well.

What are you most excited about for Android Dev Summit 2019? Let us know in the comments below!

 

Using Kotlin DSL For Gradle

Share if the site was helpful

Using Kotlin DSL For Gradle

If you’re an Android developer then you’ve undoubtedly worked in the build.gradle file.  And you’ve undoubtedly wanted to throw things at your computer when it didn’t work as intended.  It’s a file (2 actually) essential to your app’s well being, but it’s written in Groovy which pretty much no one knows well.

This has created frustration for countless users when they can’t compile things correctly.  Thankfully there’s a better way, and as with most things Android the answer is Kotlin!

Kotlin Instead of Groovy:

Gradle recently released version 5.0, and along with this comes Gradle Kotlin DSL v1.0.  This is what lets us write our Gradle build scripts in Kotlin.  But before doing so we should ask if this is even a good idea.  Why would we want to write our build scripts in Kotlin?  Well for starters Groovy is a dynamically typed language (type is associated with run-time variables).  This means that it’s tough for Android Studio to warn you about much until after the script is already running.  Kotlin on the other hand is statically typed, so lots of bugs can be checked by the compiler before the script is ever run.

Along with this check comes autocomplete.  Android Studio will be able to suggest common method names and variables to you the way it already does in Kotlin or Java files you type in.  Couple this with the comfort that you already (hopefully) have with Kotlin, and it’s an instant improvement.

Prepping for the Leap:

So we’ve decided it may be worth looking into. What’s the first step? Step 1 setting yourself up to make the transition less painful.  Certain things are allowed in Groovy that aren’t in Kotlin, so if we make those conversions in the plain text, then converting the file will be easier.  One of these “things” is quotation marks. Groovy uses single quotations a lot, but those aren’t allowed in Kotlin.  So step one is replacing any single quotation marks you have with doubles.

Next you should make sure that your “apply plugin” uses are replaced with the plugin DSL block.  This is one plugin block that should encompass all of the plugins your project is using.  When your done here’s an example of what your plugins should look like:

There are unfortunately some limitations with this new plugin though, so if you encounter errors it is possible to still use the legacy plugin.

The final thing you’ll need to do is assign variables and call methods.  What I mean by this is that since Groovy doesn’t require you to explicitly write the = when declaring a variable or the () when running a method, these changes need to be made for Kotlin.  Here are a few examples:

Taking The Leap:

Ok, now we’ve made our prep changes, so hopefully things go smoothly with the actual changes.  We have three files we need to rename to include .kts. Our two build.gradle files now become build.gradle.kts, and our settings.gradle file should become settings.gradle.kts.  Rename these files and try to compile the project. Fingers crossed nothing erroneous pops up, and if that’s the case then congratulations you officially have a project running on Kotlin DSL!

These are just the basics, and I’m sure if your project is complex at all there will be a few more jumps in the process to Kotlin.  If that’s the case Gradle has documentation on their website that helps walk through how to go about some of these common changes.  I’d highly recommend checking them out if you feel lost.  And if you don’t need them, then your app should run just fine now, and any time you make changes to Gradle you can do so in Kotlin.

 

 

 

en English
X