Converting Your iOS Application to Android: Part 3
In the previous two articles we’ve looked at why you should consider converting your application to Android, considerations to be aware of when converting your application to Android, and then in the second article, we looked, in more detail, at the nuts and bolts of converting your iOS application to Android.
In this article, I assume you have converted the functionality of your iOS application to Android - the question now is – what next?
Before doing anything else, just as you would with an iOS application, it is a great idea to double check that you’re happy that your application meets your quality standards. Double check that your application is all working as it should, and there are no bugs or usability issues. Try to break your application. For example, if your application requires internet access, check what happens if you turn wifi off. As we saw in the first article of this series, there is a huge variety of Android devices, with different specs from memory to resolution. Try out your application on different devices or emulators and make sure it looks great on all screens.
Next, check your application meets Android’s standards and quality guidelines. Google Play provides a really useful checklist here, that goes through common issues - issues you may have overlooked, such as preserving and restoring application state, or performance issues.
Most likely you’ll be looking to launch your application on Google Play. (As mentioned in the first article of this series, you might also choose to launch on other Android compatible stores, such as the Amazon Appstore or Samsung Galaxy Store, but we’re going to focus on Google Play here.) Once you have paid your one-off registration fee of $25, you’ll want to set up a developer account in the Google Play Console, complete with a developer icon and header image. If you’re looking to earn money from your application, you’ll of course need to set up your bank account details and tax information.
Finally, you will be ready to set up your application’s store listing on Google Play.
Before you launch your application on Google Play, it’s a good idea to get a wide range of users to beta test your application.
There are three types of tests available in the Google Play Console:
Internal tests are limited to a maximum of 100 testers. They don’t need to be reviewed by Google, so are useful for quick distribution. They are most often used for internal quality assurance prior to beta testing, but if your beta test group is small enough you could use internal tests for beta tests if you like.
Closed tests offer a practically unlimited number of testers. (well, technically, you can add lists of tester email addresses up to a limit of 100,000, but alternatively you can add users via Google Groups which have unlimited membership.) To distribute to users, your application beta first needs to be reviewed by Google. You can set up multiple closed tests, to test out different features.
Open tests are completely visible to the public on Google Play. Anyone can see your beta and install your application. Open tests have unlimited testers, unless you choose to limit the number yourself. Similar to closed tests, your beta first needs to be reviewed by Google to ensure it meets policy guidelines.
It’s up to you which type of testing makes the most sense for you.
The big question really is, where can you find these kind, friendly folk to test your application? Other than enlisting your mom, your best mate, and calling in a favor from your neighbor, who else would be generous enough to take the time to provide you feedback on your application?
You’ll find groups for finding beta testers on sites such as reddit, such as alphaandbetausers. You’ll also find websites dedicated to finding you beta testers - I’ve found betabound.com useful. In both cases, to maximize take-up, you’ll want to present a compelling case for people to test your application. Maybe that’s just an early look at an interesting sounding application, or maybe you are in a position to offer something for free to beta testers. A simple way to provide a free gift, if your application is eventually going to be a paid application, is to offer testers free lifetime access.
Feedback from your beta testers is going to be invaluable for finding problems and making improvements to your application. However, sometimes beta testers may miss an issue with your application, or perhaps they might just not send you details of all bugs and issues they encountered.
A useful tip for getting maximum value from your beta testers is to include error tracking and performance monitoring in your application. To achieve this you can use a tool such as Sentry for Android crash reporting.
For those who came in late - Sentry is a tool that automatically records detailed information about any errors that cause your application to hang or crash. Sentry can also monitor how well your application is performing during any potential slow or complex operations, such as network operations or graphics processing. Once Sentry has sent event data to the server, you can access information about your application’s errors and performance in the web portal. Here you can also assign people or teams to these issues and keep track of the status of different issues across different application releases.
To begin setting up Sentry to log events in your application, you’ll need to create an account, create a project, specify Android as its platform, give it a name, hit Create Project, and your Sentry project is ready to be connected in your application. You’ll be taken to a page that covers how to configure Sentry in your application.
First you’ll add the Sentry library to your application as a dependency.
Android allows you to add dependencies, including third party dependencies, in the build.gradle file. (We looked at the build.gradle file in the previous article.) This won’t be too unfamiliar to you, if you’ve added dependencies in Xcode using Cocoapods, Carthage, or the Swift Package Manager.
The Sentry docs describe the changes you should make to the build.gradle file, but you’ll basically be doing three things:
Adding MavenCentral as a repository. (this is a public central repository, similar to the Cocoapods central repository)
Ensuring you are using the correct version of Java to ensure that Sentry is compatible with your project.
Adding the Sentry SDK as a dependency.
As soon as you make changes to the build.gradle file, you will see a Sync Now button appear. Click on that, wait a few seconds, and done. You can now use Sentry in your project.
Before anything else, you’ll want to initialize the Sentry SDK for your project with what’s called a Data Source Name, or DSN. The easiest way to do this is by adding one line to your Android manifest file. Again, see Sentry docs for more detail.
Now your application will automatically capture any errors. After your beta testers have tried out your application, you can check out the page for your application on the sentry site, where you’ll find useful information on what type of errors were being generated and what events lead up to the error occurring. These events are called ‘breadcrumbs’.
Your application will also automatically monitor the performance of your application, in all sorts of ways. It measures the performance of launches for all activities, fragments, or the application itself. It measures the performance of HTTP requests, file operations, user interaction, and even detects slow or frozen frames. Check here for a full list of what Sentry automatically monitors.
If the automatic performance instrumentation doesn’t cover your needs, you can also add custom performance monitoring to your application. For example, when a user in Subtitles Viewer downloads a subtitle, I started monitoring the performance of parsing the subtitle file. I did this by creating what is called a transaction:
ITransaction transaction = Sentry.startTransaction("parse subtitle", "parse");
When data is returned from the search, I called:
This gives you useful information on your application’s page on sentry, showing how your beta testers experienced the performance of your application. In my example, I was able to check out how quickly downloaded subtitle data is being parsed into a subtitle ready to display to my beta testers.
Of course, once you have submitted your final application to Google Play, you are able to continue to monitor for errors and performance in your users’ application using Sentry, and quickly diagnose and resolve any problems that might pop up.
Another great resource for checking your application for any improvements, is a feature of Google Play, called the pre-launch report. The pre-launch report is generated by Google Play when you upload an application for closed or open testing. Google automatically runs your application on several devices, simulating navigating and using your application as a user would, and reports back any issues it finds, such as accessibility or stability issues.
Once you have given your beta testers enough time to look over your application, you’ve made any changes based on tester feedback and data from Sentry and you are confident that your application is ready f§or the world, guess what? You are ready to submit your application.
If you have made it this far, it’s actually straight-forward to now go ahead and publish your application on Google Play. You have the choice to either ‘promote’ an existing release (perhaps one you were testing in a closed or open test), or to create a new release. You will need to fill in ‘Release notes’ - information describing what is contained in this release, and then hit ‘Review release’. You will be taken to a page where you can do a last minute check on any details. Here you could potentially find that there are still some issues that Google Play has found with your release that may need attending to. When you are happy with your release, you can now hit the Start Rollout to Production button.
Just like the App Store, your application will be under review by Google, and after a day or so, you should see your store listing on Google Play, visible to users and ready to download.
I hope this three part series articles on converting your iOS application to Android has been useful.