Posts

, ,

Quick Intro to Kanban & Scrum

In our previous post, we learned what the Agile methodology is and how you can apply it to your team environment. We quickly mentioned two words (Kanban & Scrum) that are a part of the Agile process and drive the progression of a workflow. Today, we will introduce Kanban and Scrum in greater detail and walk you through each framework.

Let’s start with Kanban…

Kanban is a framework for managing and improving the workflow within a system. Kanban is the combination of two Japanese words, Kan (“sign”) and Ban (“a board”). In Kanban, user stories are represented as cards on a board with columns that distinguish the different stages of the development process. For our team at Oak City Labs, our user stories represent each task that must be completed for each software feature. The cards are filtered through the Kanban board, starting in the “Backlog” column and working their way through “To Do”, “In Progress”, “Testing”, and “Complete”. See an example Kanban board below:

Traditionally in Kanban, each column limits the number of user stories that can exist at one time, which helps prevent work from piling up in one stage of the process. This also encourages teams to limit their work in progress (WIP) and prioritize the most important items. By visualizing the flow of work, teams can identify blockers that prevent tasks from being completed, they can remove waste, and optimize their performance.

Now let’s talk about Scrum…

Scum is another Agile framework for managing and completing complex projects. It was originally created for software development, but it can also be applied to several other project types. 

Scrum commits its teams to complete an increment of work through sprints that vary in length, most sprints lasting between two and four weeks. The goal is to create learning loops to quickly gather and integrate feedback from both the team and the stakeholders. At the beginning of each sprint, the team holds a planning session to define the sprint goal and to identify the work items that will be addressed during that sprint. The team then works on those items during the sprint, holding daily stand-up meetings to check progress, identify, and resolve any issues that arise.

There are three main roles in Scrum:

  • The Product Owner who works with stakeholders or clients to create the vision of the product that will be conveyed to the team.
  • The Scrum Master who usually serves as a project manager to oversee planning sessions and daily stand-ups, and removes blockers that prevent tasks from being completed.
  • The development team who creates, tests, and deploys the product to the client.

At the end of the sprint, the team holds a sprint review to demo the work that was completed during the sprint and to receive feedback from stakeholders. The team also holds a sprint retrospective meeting to reflect and identify areas for improvement in the next sprint. 

Scrum provides a framework for teams to collaborate and deliver value to customers in a transparent and flexible way. It encourages teams to work in an interactive and incremental way, to prioritize work based on customer value, and to continuously improve their processes.

The flexibility offered by both Kanban and Scrum offers advantages to teams who want to adopt various aspects of each framework and incorporate them into their workflow. Each team and project has unique requirements and working styles. Kanban and Scrum allow teams to harness their strengths resulting in a more efficient and adaptable process, ultimately leading to better project outcomes.

Are you ready to take your software solution to the next level? Schedule a call with us today.

/by
,

How to Build a Healthcare App

It’s the era of all things tech, and medical companies are partnering with developers like never before. In 2021 alone, 90,000 new digital health apps were created.  Since the early days of Covid-19, digital health has continued to skyrocket and the results have been overwhelmingly positive. Research has shown that many patients are now making many of their healthcare decisions based on their access to digital health resources.

If you’re a doctor or entrepreneur in the medical field who is considering a healthcare app of your own, this post is for you! We’ve complied a comprehensive list on how to build your own healthcare app.

Determine what kind of Medical App You Want to Build

There are hundreds of approaches that you can take when creating a software solution, so it is important to narrow down a specific focus and determine what the purpose of your app will be. Identify a pain point or problem to solve and write down how your software solution will resolve it. For example, if your medical office is looking to streamline its training process for new employees, an online platform that includes training modules, videos, and exams would be a software solution. During the planning phase, you will also need to consider the necessary features to include in your first version of the app. You can determine this by categorizing your “must have, “should have”, “nice to have” and “next version” features.

Web or Mobile? 

Once you have determined the problem and solution, you’ll need to decide if the app will be Web or Mobile based. This will be one of your biggest decisions and we strongly encourage you to talk to the experts about this. Our team determines web and mobile apps on a case by case basis. There is no “one size fits all” answer to this question! There are pros and cons to each option, so it will be important to consider these four questions:

What is the purpose of the app? What is the budget? Who is target audeince? Why will this specific software solution stand out?

We would love to talk you through this decision – feel free to schedule a call with us! In the meantime, read our blog on Web and Mobile Apps.

Cross or Native Platform?

The next step in the development process is to consider if the app will live on a cross or native platform. To summarize, “native development is the process of building apps for a specific operating system like Android and iOS. Each system has a specific design language, integrated development environment, and guidelines…cross-platform development involves the usage of a single code base across platforms. The codebase is combined with OS runtime environments for execution. So, these environments interpret the app’s code at runtime and execute it.” Similar to the Web vs. Mobile discussion, there is not a single correct answer. Many factors determine this decision such as your budget, timeline, and goals for the app. It is recommended that you talk to experienced developers who can walk you through the differences and benefits of each option before you hand off your app to development. Read more about cross and native platforms here.

Design the App

Here’s where the development really comes to life! Wireframes display the UI (User Interface) or design of the software. There are two types of wireframes – low and high fidelity.

 

 Low fidelity wireframes include basic and static content to visualize layout of the interface. These wireframes are built with publishing software, such as the Microsoft Office suite. “Low-fidelity wireframes usually serve as a checkpoint for the product team and stakeholders at the beginning of the design process. They help teams visualize and test early concepts, requirements and design assumptions at the beginning of a web design project.”

High fidelity wireframes are extensive prototypes that include color, content, and interactive buttons. They offer a finalized view of the app. Though they are more expensive than low fidelity wireframes, they provide an accurate depiction of the product and allow stakeholders to see the style of the app and interact with the interface.

Development and Launch

Your healthcare app is ready for development, testing, and launch! The developers have all of the information they need to build the healthcare app. Keep in mind that medical apps require HIPAA compliance guidelines throughout the development process. We recommend that you reserve 10% of the project budget for HIPAA compliance protocols.

It’s important for you and any key decision makers to meet frequently with the development team to communicate any changes that need to be made throughout the process. You should feel empowered to be a part of the development, even if you don’t understand the “tech talk”. We always say that a sign of a good development team is if they can take complicated concepts and communicate them in a way that anyone can understand.

After development, it’s time to test the app and get it LIVE! Our team at Oak City always encourages our clients to spend a good amount of time using the app, asking questions, and making sure that each feature displays the desired behavior.

Conclusion

We understand that developing a healthcare app is a long and complex process – but it is worth every step. We believe that technology exists to make day-to-day tasks simpler. With healthcare apps, the potential to improve lives is unfathomable.

Are you ready to build your own healthcare app? Schedule a call with our team to get started!

/by

Realm vs. Room for Android

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.

/by

Optimizing Your Android App for the Google Play Store

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!

 

/by

React Native? Not so fast.

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.

/by

A Delicious New Release

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!

/by

3 Tips for Releasing your App to the Google Play Store

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.

/by

From Idea to Reality: Steps to Take to Bring Your Mobile App Idea to Life

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!

/by

Why Testing Matters for Your Next Mobile App

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!

/by

NinePatch Drawables in Android

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.

/by