Posts

Today I’m going to discuss some pros and cons of Realm and Room for Android data persistence. Room was introduced at Google I/O 2017 as part of the Android Architecture Components. Realm is a mobile database solution that was launched for Android in May 2014 and has become a feature-rich choice for data persistence. While both serve a similar purpose, they are very different in implementation and their effectiveness may vary depending on your projects needs.

Room is just a layer over the native SQLite that comes stock with Android. As such there is a large amount of customizability in the queries (you write your queries in SQL and they are validated at compile time). However, Room also requires that relationships be created using foreign keys and the like, so complicated object graphs can be a bit of a pain to implement. Realm on the other hand requires no SQL knowledge. You do not have to write any SQL statements and object relationships are incredibly simple to implement. Referencing one object (or a list of them) from another object creates the relationship automatically.

Realm is a much larger library than Room because it includes a separate database. It adds somewhere around 3-4 MB to your app’s apk. Because Room is just a layer on top of SQLite, it only adds a few dozen KB to the APK. Room also contains far fewer methods if you are concerned about dex method limit.

Realm requires that objects not be passed between threads. Realm data objects are views into the data that respond to database changes so they are tied to whatever thread the Realm instance that they were retrieved from exists in (if that Realm instance is closed, any objects retrieved from it become invalid). In my experience this isn’t generally much of an issue if you are careful about it, but if you find yourself switching threads a lot you’ll have to create new Realm instances and re-query to get your objects. No such thread limitations exist for Room.

Room is officially supported by Google, so it should remain well supported and will likely have good community support. On the other hand, Realm has been around for a while (officially released about 4 years ago for Android) and has undergone tons of bug fixes and improvements and has an active community. Additionally, Realm supports iOS as well as Android, so developing for both platforms with virtually the same data persistence layer can allow for similar app architectures.

Both libraries support reactive queries, allowing you to subscribe to updates on a view of your data. Room achieves this using LiveData, another part of the Android Architecture Components, which can be linked to an app component (Activity, Fragment, etc.) and update intelligently based on the lifecycle of the component (i.e. not causing UI updates when an Activity is in the background). This is a nice feature to have out of the box and allows you to avoid keeping track of unsubscribing listeners in backgrounded app components. Realm objects, lists, and query results can all be directly subscribed to in order to monitor for changes, convenient features not entirely present in Room. Realm also has an additional library for an auto-updating Recyclerview adapter. While something similar isn’t too complicated to implement with LiveData, Realm’s library comes for free and works well.

Depending on your app’s data model complexity, APK size concerns, and personal experience/preference both Realm and Room are viable options for data persistence. Let us know in the comments which one you prefer.

Your Android app’s visibility in the Google Play Store can be just as important as building the app itself. Today we’re sharing a few tips to optimize your Android app’s Google Play Store listing and improve its visibility for users.

Of course, total installs and positive reviews are extremely helpful for your app’s visibility, but there are also steps you can take to ensure that Google’s search algorithm will prioritize your app as highly as possible in the search results.

Keywords in the Application Title

Use keywords in your application title. Google takes app title into account when ranking your app in search results, so adding a few relevant and descriptive keywords to your app’s title can help it rank higher. There are 50 characters (recently upped from 30) to work with, so come up with a name that succinctly summarizes your app. For example, the GrubHub Google Play Store listing’s title is not just “Grubhub” it is “Grubhub Food Delivery/Takeout”.

Keywords in the App Description

Use keywords in the app description. In the Google Play Store, description greatly affects your app’s ranking (unlike Apple’s App Store, which provides a separate keyword field and does not take the description into account when ranking). Repeat your chosen keywords several times in your description, but use them in a way that sounds natural (Google has policies against spamming keywords, see here).

Long-tail Keywords

Long-tail keywords refer to phrases that are specific enough to target users that are in the later stages of their search for an app. These users are more likely to find what they are looking for in your app, and thus are more likely to install. Long-tail keywords also face less competition than more generic keywords in search results. Think “local used car shopping” vs. just “shopping”. An app that helps users find used cars for sale in their area is more likely to show up in a search for “local used car shopping” than in a search for “shopping” because fewer apps are using that same combination of keywords. Keep this concept in mind when determining what keywords to include in your app’s store listing.

External Links

Use external links that send users to your app’s Google Play Store page. External links to your app’s listing cause Google to rank your app a bit higher in search results. You should encourage reputable sites, blogs, etc. to include links to your app’s store listing.

These few tips are easy to implement and are great options for optimizing your Android app for the Google Play Store. If you need help launching your Android App to the Google Play Store, let us know!

 

At Oak City Labs, potential clients often ask if we write apps using React Native. Why not? Isn’t that the fastest way to market — write one app for both iOS and Android? That’s the crux of React Native’s pitch. Don’t spend time writing two apps when you can write a single React Native app instead. As CTO of a mobile dev shop, I should be able to answer that, so I’ve started doing some research on what it takes to be a React Native developer. How does React Native compare to Swift/Java development in terms of efficiency, stability and maintainability? I’ll walk through some of the things I’ve found.

Just a note before we dive in: this article addresses the idea of writing apps for iOS and Android in JavaScript, focusing on Facebook’s React Native implementation, not to be confused with the reactive programming model, which may be a compelling alternative to the traditional declarative programming style.  Reactive programming is a topic definitely worth following.  

Toolboxes

How many tools does a developer need to build an app? As an iOS developer, I live in Xcode, provided by Apple and designed to build apps for the Apple platforms. Well over 95% of my development time is spent in Xcode. Apple also provides Instruments, a suite of testing tools to examine memory, CPU, etc in your app. Occasionally, I use Instruments to track down a particularly difficult bug. That’s it — Xcode and a little bit of Instruments.

The situation for Android is even a little easier. Android developers use Android Studio, a tool provided by Google with the sole purpose of creating Android Apps. Features like memory analysis and CPU monitoring are built in, so there’s really just one hammer in the toolbox. Android developers live in Android Studio.

Now onto React Native. It’s hard to find data on the amount of shared code in React Native apps, but conversations like this one suggest it can be 80% or 90%. That’s still a significant amount of platform specific code. Let’s assume we’re building an average app that has at least 15% platform specific code.

React Native developers have a bigger hill to climb just to get started. According to their instructions, here’s the list of software to install to build a cross platform app.

  • Homebrew — A package manager that makes it easier open source tools on your Mac
  • Watchman — A utility from Facebook to watch the filesystem for changes and run commands in response to those changes
  • Node — A javascript runtime built on Chrome’s V8 JavaScript engine, often used for server-side JavaScript
  • NPM — Part of Node, this is another package manager for managing JavaScript components
  • react-native-cli — Command line interface for for interacting with the React Native environment
  • Xcode — Necessary for various iOS tools
  • Android Studio — Necessary for various Android tools

In this article, Tony Mann suggests you’ll need these other tools as well.

  • Flow — A static type checker for JavaScript
  • Chrome Debugger — Chrome’s JavaScript debugger which can attach to your React Native application
  • Babel — A JavaScript to Javascript compiler

Now you’ve got everything you need to build a React Native app… except a text editor, so find one of those too.

So here’s the rundown for setup requirements

Platform Number of Tools Required
iOS 2
Android 1
React Native 10+

 

Right out of the gate, the bar is set relatively high for a React Native developer to get up and running. If this were a one-time penalty, it would be easy to write off. One day lost to setup on a six-month project isn’t significant, but this represents a whole dependency tree. Any update in one component can have a cascade effect that forces upgrading other components. Maintaining this whole setup now becomes overhead that the React Native developer must deal with. This kind of yak shaving can regularly consume a day of developer time.

Writing Code

I’m an iOS developer, so I’ll address the writing of code as a discussion of Swift vs JavaScript. For the sake of brevity, let’s assume Java (or Kotlin) developers make similar arguments.

JavaScript is not a nice language. It’s stone aged tech compared to Swift. Ariel Elkin does a fantastic job in this article walking through the many technical shortfalls of the language. Some of the highlights include

  • Weak typing
  • Lack of optionals
  • Lack of functions signatures

Issues like weak typing and lack of optionals are specific issues from Objective-C that Swift was designed to solve. In my experience, we always struggled with nil pointer exceptions in Objective-C. A rogue nil was the root cause of the vast majority of crashes in our applications. These have all but disappeared with Swift. A whole class of very common crashes has been fixed by using a language that simply doesn’t allow it. The rare nil pointer crash now usually has to do with interacting with legacy Objective-C.

Strong typing, optionals, and other features of Swift let me quickly write expressive, memory safe code that won’t crash. The compiler makes sure of that. As Elkin points out, these crashes happen frequently with React Native. JavaScript for app development is a step (or leap?) backward technically. If our goal is efficient developers, we should empower them with the best tools available.

Testing is an integral part of our app development process at Oak City Labs. One of the best ways to encourage developers to embrace testing is making it as painless as possible. With React Native, developers get another stack of dependencies to maintain just to get the unit testing framework running. In this article, Carlo Francisco goes over the testing stack they use at Refinery29 to unit test their React Native code. It’s based on Jest and Calabash / Cucumber. Jest is a JavaScript unit testing frame. Calabash and Cucumber are used together for application level acceptance testing. Calabash and Cucumber (and any customizations) are written in Ruby. The actual Cucumber tests cases are written in another language called Gherkin, one of those terrible languages for non-developers which are still too difficult for non-developers and too weird and restrictive for developers.

It’s great that there are testing mechanisms for React Native, but in order to accomplish real testing, we’ve got to add another few rooms on to the house of cards we’ve built so far. Not only do we add more 3rd party JavaScript frameworks, but we can also tack on extra languages — Ruby and Gherkin — in order to implement application level testing.

Compare this to iOS development in Xcode, which provides XCTest for unit testing and XCUITest for application testing, all written in Swift. Likewise, Android developers have JUnit and Espresso for unit testing and application testing respectively.

Stability is definitely a casualty here, mostly because of the limitations of JavaScript. React Native also loses ground on maintainability as testing tools require more third party components be placed in our growing dependency tree. I worry about efficiency too since testing now requires a React Native developer to know even more languages.

Debugging Code

Finally, once the code is written and running, there’s always debugging to do. According to React Native’s documentation, there’s no one stop shop for React Native debugging. There’s an in-app developer menu that opens the door to turn on/off some debug features and provide an onboard inspector. Using the Chrome browser’s remote debug feature seems to be the most powerful way to connect to the React Native app and view internals. There’s also a standalone version of the React Dev Tools to use when you can’t connect with Chrome’s debugger. And finally, there are the native debuggers in Xcode and Android Studio when you need to debug pieces of native code.

Debugging apps written in the native language is much more straightforward. To debug a Swift app in iOS, run it from Xcode and debug. For an Android app, run it from the Android studio and debug. It’s such an integrated part of the development cycle with the native tools, it’s easy to take it for granted.

With no one definitive debugging environment, I worry about a React Native developer’s ability to efficiently track down a bug. I assume one would start debugging in one of the JavaScript console tools, but then you might have to jump to a native tool. As context switching goes up, efficiency goes down.

Tool Quality

I’d also like to comment on the tool quality. Much of React Native’s tool chain, react-native, npm, etc, is executed at the command line. While some developers will praise the hard core grit of the command line, (“Real developers type, not click!!”), I find that it increases the entry-level barrier for new developers and generally causes friction for developers at any level. Trying to remember the flags for subcommands of the react command line tool isn’t going to help ship an app faster. Compare that to a button or menu item in a more robust tool like Xcode or Android Studio. The cognitive load added by a bunch of command line tools is just another stone weighing down the React Native developer and causing efficiency to sink.

Adding It All Up

At the end of the day, the React Native developer needs quite a big toolbox to fit all their tools in. Here’s the list:

  • Homebrew
  • Node
  • Watchman
  • NPM
  • react-native-cli
  • Flow
  • Chrome-Debugger
  • Babel
  • Xcode
  • Android Studio
  • Standalone React Dev Tools
  • Jest
  • Calabash
  • Cucumber

In order to use all these effectively, the React Native developer also needs to have a working knowledge of these programming languages:

  • JavaScript
  • Swift/Objective-C (iOS native components)
  • Kotlin/Java (Android native components)
  • Ruby (Cucumber testing)
  • Gherkin (Cucumber testing)

The single platform iOS developer needs Xcode (and maybe Instruments) to write, test and debug applications in Swift. Likewise, the Android developer needs Android Studio to write, test and debug apps in Java and/or Kotlin.

For a shop that has experienced Swift/Java developers, it’s very clear to me that there is zero reason to switch to the React Native development stack. We’re concerned about efficiency, stability and maintainability. The enormous number of tools required for React Native along with the piecemeal nature of programming environment are going to tank the efficiency of an React Native developer. Even the world’s best JavaScript developer is going to face an uphill battle on this unlevel playing field. JavaScript as a language is the biggest barrier to stability. JavaScript, by itself, is a deal breaker for us. Maintainability is another worry with so many dependencies from so many sources and keeping it all playing well together. (Not to mention dependency on Facebook’s ongoing support after the Parse.com incident.)

I believe in using the right tool for the right job. Writing mobile apps in Swift/Java is the quickest, most friction free path to shipping apps to customers. I can understand how React Native appeals to web developers, offering to turn their JavaScript experience into mobile apps, but there is no free lunch. It may work in the end, but JavaScript (plus a lot of frameworks) can’t match apps written in the native toolsets when it comes to quickly and efficiently shipping a high quality, maintainable native app.

Oak City Labs is thrilled to announce the launch of CurEat’s Android app to the Google Play store this month! CurEat, a restaurant discovery tool, is the vision of entrepreneur Steve Mangano. We are honored to have partnered with Mangano to also develop both the CurEat iOS app and cloud server, which launched earlier this year.

The CurEat team will celebrate the launch, along with the introduction of their new CurEat Experience Program, this Friday, September 1 from 6-9 pm in Raleigh at the offices of Google Fiber. The Oak City Labs team will be there and we hope you’ll join too! More information can be found here.

Want to know more about this project? Download the CurEat case study below and we’ll serve up all the details!

CurEat is available in both the Apple App Store and Google Play Store now!

If you’re in the process of preparing to release an app into the Google Play Store, you may find these quick tips helpful.

Package Name

Before releasing your app into the Google Play Store, you should review and confirm your app’s package name. It cannot be changed once the app is released. The package name looks something like “io.oakcity.appname” and is your app’s unique identifier on the Google Play Store and on Android devices. For the most part, it is not visible to users, but it is in the URL for your app’s listing on the Play Store. That means a user may see it, but it also means it can affect SEO and your app listing’s discoverability. You’ll definitely want your app’s name included somewhere in the package name.

Discoverability

Discoverability of your app may be challenging at first. Searching your app by name in the Google Play Store may not yield your app anywhere in the search results right away. More installs, ratings, and reviews will of course help, but you should make sure your app’s description and all other text content in the app listing contains relevant keywords as well. There is a ton of content on the web detailing ASO/SEO (App Store Optimization / Search Engine Optimization), this post provides a good overview.

Automation

You can automate the process of uploading builds to the Google Play Store (as well as generating your apk, running tests, and a whole host of other things) with a tool called Fastlane. Specifically, the supply tool can be used to upload your apk to any track (alpha, beta, or release) along with store listing description and other text content, images, and even app screenshots.

If you’ve ever found yourself seriously thinking about building a mobile app, but have no idea where to even begin, this post is for you! In a world where it seems like everyone has an app idea, the truth of the matter is that there is plenty of room for innovation and new ideas in the marketplace. But to take your idea and make it a reality, you’ll need to keep the following in mind.

First: Market Research

At Oak City Labs, we’re passionate about market research and strongly believe that it is the key to your success. Before writing the first line of code, it’s important to make sure that your idea is fully thought through. And while market research is definitely the most strategic route to take when your app is still just an idea, it’s also the route that can end up saving you money in the long run.

To take that first step in getting your app idea off the ground, begin by doing some free research. That’s right: FREE! Using everyone’s trusty friend Google, you can find information showing you what your app idea’s total addressable market (TAM) could be. Along the way, you’ll find competitors and possible features. You’ll also start to refine what your app idea is and what makes it unique. We also encourage those in this stage of the process to talk to people and conduct Voice of the Customer surveys and, ultimately, create a value proposition statement. The goal with all of these steps? To help you refine your app idea, discover what makes your idea unique and set you up for success as you begin the process of building the app.

Next: Partner

After doing your fair share of research and being confident in your decision to move forward with building your app, it’s time to find a partner that can help bring your idea to life. When looking for a development company, we encourage you to prioritize the following:

  1. Reputation: How experienced is the development team? How many apps or custom software projects have they led or developed before? What do their clients have to say about them?
  2. Relationship: How are they planning to communicate with you throughout the project? Will there be weekly check-in calls? Will they help you flesh out your idea strategically, advise of feature prioritization, consult with you on growth strategies and more?
  3. Results: Are they going to be able to solve your problem? Is this partner able to help you achieve the results you’re looking for?

We created Oak City Labs to answer a lot of these questions – to give you the missing pieces to transform your app idea into a real, quality product that makes a difference. Our team has spent decades in diverse roles across multiple leading tech companies. From this experience, we understand how to deliver on all facets of the app creation process – from the technical considerations, to project management, to product-market-fit, and all the important questions you might not think to ask. We’ve learned these lessons so you don’t have to.

We know how all of the pieces of development fit together so we bring a fully informed approach to your final product. By building strong client relationships – guiding you through every step, valuing your feedback, and collaborating on the process with you – we craft the well-designed, marketable app that you want to build.

Then: Build

Assuming you’ve properly validated your app idea and selected the best strategic partner, it’s now time to begin building your app. The process involved can include everything from wireframing and user testing, to visual and interaction design depending on your specific needs.

At Oak City Labs we make sure to have a full feature list in place before beginning development. Then we prioritize the feature list to ensure that the most important things are built first. If budget or time becomes an issue, we always want to ensure that your high priority needs were taken care of in the beginning.

As development proceeds you should expect lots of testing through frequent beta builds provisioned by the development company to your device. And you should expect lots of testing on their end too.

Don’t Forget: Marketing

It would be easy to wrap up this post with the next step and call it a day. But the truth is that successful apps won’t take off and have a hope of succeeding if there isn’t a marketing plan in place. While your app is in development (and, quite honestly, long beyond that), you should be working on and executing your marketing plan. From a website to social media, and even press kits, your marketing plan can make or break your app’s chances for success.

Finally: Launch (& Rinse and Repeat)

It’s the finish line! Well, sort of. At the completion of the build and testing phase of the project, it will be time to launch your app and we’ve created a whole checklist to make this process successful here, here and here.

Once that first release hits the store, you should celebrate! What an accomplishment! But keep in mind that it’s really just the beginning. Following the launch, your app will need to be nurtured on an ongoing basis if you hope to grow your audience (and therefore your business!). You’ll need to address bugs, add new features, adapt to new technology challenges and much more.

As with any business idea, there’s a lot that goes into going from an idea to a bona fide product. At Oak City Labs, we love helping entrepreneurs make their ideas a reality. If you have an idea and think we’d be a good partner for you, we’d love to chat!

We’re in the thick of testing on a large project right now. It’s a (delicious!) new release that we can’t wait to share more about later this summer. While it goes without saying that any release, big or small, should be thoroughly tested, you can often find yourselves in crunchtime near the end of a project. That crunchtime can lead to the choice between meeting a looming deadline and thorough quality assurance. Today we’re sharing all about testing and why it’s so important for your mobile app’s success.

Testing 101

When we talk about testing your mobile app, we aren’t just talking about making sure all the buttons work. Thorough testing goes well beyond that!

At Oak City Labs, we begin testing as early as possible in the development process. We’re an agile shop, so we place a lot of value on getting a (semi-)working version of the app in front of our clients for review as soon as possible while development is still in progress. As soon as we have a working, somewhat functional mobile app ready, testing begins.

Our testing process is just that: a process – a very detailed and thorough process. Armed with our trusty QA Checklist, we thoroughly test the mobile app inside and out. We try to break it in as many ways as possible (better now than when in production!). We work through each and every screen in the app comparing it with the designs, testing it against our use cases, proofreading copy and looking at scrolling and swiping behavior. We check how the app integrates with other apps, we test push notifications, observe screen orientation and more.

I said before that we test each mobile app inside and out. More than just a common phrase, we really do test inside our mobile apps. On the “inside,” we evaluate performance by testing battery usage, install/uninstall process, loading, network connection and the list goes on!

We also place priority on testing the app from the perspective of a first time user. As we near release, it’s all but certain that we’ve been using and testing the app for months. It’s important to take a step back and evaluate the app with fresh eyes to make the user experience for those who interact with it for the first time is optimal.

Why It Matters

You may be saying, “Wow, that seems a lot of work! Is it really worth it?” The answer is YES! Statistics tell us that about 25% of users use an app once and then never use it again. Add in crashes or a mediocre performance experience and you are sure to see that percentage rise.

Trying to break into a crowded market? There’s no easier way to differentiate yourself – in a bad way – than with an app riddled with bugs and performance issues. We’ve shared before about the importance of reviews for your mobile app and negative reviews left by customers frustrated by an untested app aren’t a great way to start.

Testing matters. At Oak City Labs we place high value on thorough and complete testing before a mobile app’s release. If you are looking to create a mobile app – one that is sure to be thoroughly tested – we’d love to hear from you!

NinePatch drawables in Android offer a way to create resizable bitmaps that only stretch the sections of the image that you specify. This is useful for creating backgrounds for TextViews, Buttons and any view whose size may vary depending on the content, as well as when creating splash screens that have a logo whose aspect ratio you don’t want to be distorted.

NinePatch drawables consist of the original image surrounded by a one pixel border of empty pixels by default. The top and left side one pixel border is used to specify (with black pixels) what vertical and horizontal slices of the image can be stretched to make the image to fit its container (instead of simply stretching the image and changing its aspect ratio). This way areas of the image with content you do not want to be stretched can remain at their original aspect ratio. The bottom and right side one pixel border is filled in with black pixels to specify the area of the image that any content that sits on top of the image should reside in (essentially, the padding for the view that this image will serve as the background for).

The following is an example of a NinePatch image:

The black sections of the top and left one pixel border are circled in red. The logo in the center will maintain its aspect ratio while the vertical slats designated by the top one pixel border will be stretched horizontally and the horizontal slats designated by the left one pixel border will be stretched vertically. When two or more stretchable slats are specified for a dimension as above they will maintain their size relative to each other when stretched (so the logo will stay centered).

It is important to note that if you don’t want to specify the content area (the padding) and would like content to fill the entire image, you should fill the right and bottom side 1 pixel border with black pixels as in the example above. If the content area is not specified (the bottom and right sides consist of only empty pixels), the content area will default to the area designated by the top and left side one pixel border.

Android Studio has a tool to generate and edit NinePatch drawables. To access it, right-click on your image file in the Android Studio file browser and find the “Create 9-patch file…” option. You’ll want to give the new 9-patch file a unique name so it doesn’t conflict with the existing image resource (or just delete the original). Now find the newly created NinePatch image (it will have “.9” prepended to the file extension, i.e. your_image.png becomes your_image.9.png) and open it. A full tutorial for the Android Studio NinePatch editor can be found here.

Image Classification with fast.ai

This year at their annual developer’s conference, I/O, Google announced that Android now supports Kotlin. For those that don’t know, Kotlin is a cleaner and more expressive and modern language than Java. Our Android team is excited to begin learning and implementing Kotlin. With numerous features and benefits, I thought I’d share the top four features I am excited to dig into.

Nullable types

Touted as the solution to NullPointerExceptions, nullable types in Kotlin make surprise null values in your code much less likely. There is no need for constant null checks as functions and fields on nullable types can be accessed safely with the ? operator.

Reduced to:

Kotlin properties and data classes

With properties in Kotlin, getters and setters are no longer necessary. Getters and setters are created for properties automatically and implicitly called when the property is accessed. This will significantly reduce clutter in data model classes. Additionally, the data keyword in Kotlin can be used to create a data model class with automatic implementations of methods like equals, hashCode, toString, and others.

Reduced to:

Extension methods

In Kotlin, classes can be extended to include custom functionality right where you need it as opposed to creating an entirely new class that extends the one you need custom functionality for. Behind the scenes, Kotlin actually creates static methods for the extension methods where the first parameter is an instance of the extended class.

The milesAfterTrip method used earlier could be added to the Car object as follows:

Lambda functions and Inline functions

Kotlin has better support for functional programming than Java with proper function types.

Whereas the Java code above requires the Predicate<T> interface, the same code in Kotlin could be:

Inline functions eliminate the overhead of lambda functions, which typically cause the creation of an anonymous class and the capture of a closure. Functions marked as inline will simply execute the code contained in the lambda functions that are passed to it at the call sites.

If we make the printOldCars function used earlier inline like so:

Then the result of calling printOldCars:

Is equivalent to

Functionally, this is the same as before, but now the oldCarTester lambda that is passed in does not require additional memory allocations. By the way, the let function used above is also an inline function. You can read more about inline functions here.

These are just a few of the features available in Kotlin. You can explore more Kotlin here.

Interested in an Android app? Or need help maintaining an existing one? Drop us a line. We’d love to chat with you!

Today I’m offering some tips on how to set up Google Maps in your Android application. This is not meant to be a start to finish tutorial on the process, but instead a few tips to move past some of the stumbling blocks I’ve run into.

Finding your app’s SHA-1 key

To set up a Google API key, you will need your app’s SHA-1 key. The easiest way to get both your debug and release (assuming you have a signing config setup for one of your build variants) SHA-1 keys is to use the method demonstrated here:

http://stackoverflow.com/a/34223470

in Android Studio.

Alternatively, the debug SHA-1 key can be found via command line by navigating to your ~/.android directory and running the following command (on Mac):

  • keytool -list -v -keystore debug.keystore
  • The password should be “android”.
  • Similarly, the release SHA-1 key can be found by running keytool -list -v -keystore YOUR_KEY_STORE_FILENAME.jks in whatever directory your keystore is located. The password will be the keystore password.

Getting a Google API key

  • Head to the Google API Manager console here: https://console.developers.google.com/apis/
  • Enable the Google Maps Android API
  • Go to the Credentials page and click Create credentials, choose API key.
  • When prompted with your new API key, click Restrict Key.
  • Name your key if you would like, then under the Key restriction section click “Android apps”
  • Click “Add package name and fingerprint” and enter your app’s package name (found in the android project’s AndroidManifest.xml) and the correct SHA-1 key. You will likely want at least two of these package name / fingerprint entries, one with the debug SHA-1 key and one with the release SHA-1 key. If you have build types that alter the package name, you will want to create additional package name / fingerprint entries for them. For example, say I append “.beta” to a build type that I upload to Crashlytics Beta. The package name “io.oakcity.project.beta” will need its own entry with a release SHA-1 key.

Setting Google API credentials in your app

Add the following meta-data tag to your AndroidManifest.xml file:

It is recommended that you store your Google API key in a string resource and reference it from this meta-data tag. From here, you should be able to add a SupportMapFragment to an activity and get started developing your Google Maps application. Refer to this for how to set up a basic Google Maps activity.

Customizing the Google Map

Here are a few brief tips on customizing your app’s Google Map.

Setting size of a Google Map Marker

Markers are covered extensively in the documentation https://developers.google.com/maps/documentation/android-api/marker. Setting a custom marker image can be easily done, but there doesn’t appear to be a way to set marker size directly in the MarkerOptions. Marker size can instead be set by loading and sizing a bitmap of the marker image first.

The bitmap returned by this method can be handed to the MarkerOptions as follows:

Moving the toolbar

The Google Maps toolbar contains buttons for opening a selected location in a navigation app or in Google Maps. If your user interface covers the toolbar in its default location, you can reposition the toolbar by setting the GoogleMap object’s padding.

Setting the bottom padding will move the toolbar.

Getting GPS bounds

To get the GPS bounds of the map that you see on screen, you can use the GoogleMap’s projection as follows:

The LatLngBounds object can be used to get coordinates of the center of the viewing area as well as the bounds. This can be used in conjunction with GoogleMap.OnCameraMoveStartedListener and GoogleMap.OnCameraIdleListener (implemented by the Activity) to update markers if the center of the viewing area has moved a certain amount (or even a certain percentage of the view area’s width).