I've been writing a pretty large mobile application for a client recently and am finally getting close to releasing it, but thought it might be worthwhile to write a little bit about the experience I've had.

The Frameworks

I expected jumping into development for Android and iOS would be fairly straight-forward. Mobile development has been around for quite a while now and there dozens if not hundreds of tools to get the job done.

I began researching frameworks that would allow me to have a shared code-base across Android and iOS and was disturbed at my options:

Option 1: Write Two User Interfaces

Using RoboVM you can deploy your JVM-based application to iOS without any noticeable performance penalty, but you must still create your user interface for each separately.  In many cases this is preferred if you want to maintain compliance for device-specific standards.  However, in my case the client had a very rigid design that they want to see on both devices and writing it twice just seemed painful and wasteful.

Option 2: Phonegap

There is a huge trend for Phonegap and derivatives that let you write your mobile application in HTML and JavaScript and then deploy it to Android and iOS.  In some ways this is a compelling option since you have standards-based tools that you can use to create your user interface and can even potentially reuse some functionality from your web application.  However, on closer inspection the performance is horrible and the UI feels very clunky.  I have yet to see an application written using this methodology that feels like a native application.

Option 3: Write a Game

I'm fairly well known for taking the road less travelled and will write entire libraries to do something "the right way" in my opinion.  After rejecting the above options I realized the only common UI target between Android and iOS is OpenGL ES.  This is the graphical library games are built on and though it might seem like a crazy idea, I created a simple prototype to see if I could write a UI framework on top of it.  Though incredibly painful to write the preliminary foundation, it worked quite well.

Writing an Engine

In an effort to support my app development needs I began to write a framework that provided complete UI functionality using OpenGL ES so I could have a common User Interface.  At this point that framework has been developed out pretty far and I'm extremely happy with the results.

LibGDX

I chose to build on top of LibGDX as it provides some basic building blocks for UI already, although extremely limited and focused toward game development.  I build my framework to add all the niceties for transitions, components, dynamic font loading, etc. to provide for my UI needs.  One of the big wins here is that I am able to rapidly test on the desktop without having to run an emulator or deploy to a device.

PSD to Scala

I love writing Scala code and decided to build this application entirely in Scala. However, the design mockups were created in Photoshop.  This is a common problem converting from design to implementation.  I decided to write a tool that would load the PSD file and allow me to customize options and then export to generate a screen in Scala.  This provided me with the ability to take a design mockup and create a perfect 1 to 1 representation in the final product.  Additionally, this saved me a massive amount of time as I simply needed to integrate the real data with the design then.

Bitmap Font Service

One of the biggest problems with User Interfaces in OpenGL is drawing fonts. The most common way is to use Bitmap Fonts that is a rasterized image representation of all of the characters instead of the vector data you get with a true-type font.  In order to properly support this I created a web service that the mobile app could request fonts from and it would dynamically generate the Bitmap Font on-demand to deliver back to the mobile app. The mobile app could then cache the data for future use.

Scaling for Screens

Another huge problem on mobile devices is that the screen sizes are so wildly different from one device to another.  After lots of consideration I wrote a scaling framework that takes in a virtual width and height that the application is designed for and the content is automatically scaled to properly and intelligently fit to the screen.  For raster images this means some dynamic scaling or multiple size options if pixel perfection is desired.  For fonts it simply means that the font size is scaled before making a request to the Bitmap Font Service so that the font is properly scaled according to the dimensions available to it.  The result is an incredibly clean looking UI at any resolution.  Additionally, since I only have to think about my virtual width and height, layout is incredibly easy.

Next Steps

At this point I now have a pretty powerful engine for mobile application development. One that rivals any framework I have seen to-date.  The question is: what do I do with it now?

I'm considering open-sourcing it to allow anyone to use it, but it's entirely written in Scala, so the audience that would take advantage of it is relatively low.  Another option is to continue to improve it as a closed-source project and focus more on providing OUTR Technologies the capability of creating more powerful mobile applications.

Update

Almost immediately after posting this I received several requests from people that were very interested in using the framework so here you go:

https://github.com/outr/outrgl

It's very rough and needs lots of documentation as it was written entirely for internal use but that will change as I go forward. I'll try to create a G8 project to help create new projects in the near future. 

I've worked with and for a lot of companies over the years and with the ones that actually care about unit testing Mocking (Mockito or some other variation) typically quickly enters the scene. My argument is that in proper coding you should be able to write proper unit tests without any mock objects. I'll go a step further and say that encouraging mocking in your tests actually encourages poor code quality.

What's the purpose of Mocking?

Mocking is extremely common in unit tests, but why?  The basic idea is that you are attempting to test one specific "unit" of functionality, but you don't want calls to the database, third-party calls, or other side-effects creeping into your unit tests. On the surface this seems like a valid use-case.

Why is Mocking bad?

There are many problems related to mocking that I'll try to quickly step through.

Unnecessary Complexity and Decreased Modularity

Though the purpose of mocking is actually to reduce complexity it very often increases the complexity of your unit tests because you often end up with confusing and complicated mocking to avoid running aspects of your code that you don't want executed in your tests.  You often end up pulling your hair out trying to figure out how the internals of the system are supposed to work in order to get the mocks to operate as expected and then all your tests start breaking as soon as that internal logic changes.  You often end up in a scenario where your code works fine because it's written modularly to continue working but your unit tests break because they are essentially implementing the internal functionality via mocks.

Unit tests testing the Mocking framework

In extremely complex unit tests or even simpler unit tests that are managed over a long time or through many developers it becomes more and more confusing what the purpose of the test actually is. I can cite dozens of examples where I've been auditing unit tests only to find out that the unit test does nothing but test the mocking framework instead of the code.

Need for Mocking Represents Bad Code Separation

This is what my entire complaint really boils down to.  If you actually need mocking in your unit tests, your actual code that you're testing is poorly written in the first place.  You should be writing code in proper units to allow individual testing without the need for mocking at all.

For example:


You might have a scenario similar to the code above and you want to test the checkout functionality of your system, but you don't want the payment gateway to be called and you don't want it actually persisting to the database so you might mock those out to avoid those being called. Instead, consider the idea that there are four units of functionality clearly defined in this case:

1. Validating the Order
2. Calling the Payment gateway
3. Persisting the information to the database
4. Creating a Receipt

Herein lies the problem. You have tight coupling in your code of dissimilar things making mocking necessary. If instead you were to refactor your code to look more like this:


You can see now that each unit of functionality has been broken out into its own method that can be individually tested as needed without the necessity of mocking. Further, the code is significantly cleaner and more maintainable as a result of this refactoring. Not only does it make our unit tests cleaner and easier to maintain without mocks, but it also enforces a higher level of code quality through modularity in your code than was there before.

If you ever decided that the checkout method needed to be unit tested you could refactor it so it takes in a PaymentGateway implementation and Persistance implementation as arguments to avoid side-effects and allowing a test instance to be created to fulfill those needs. Though this is a form of mocking, it follows a better paradigm of consistency and modularity than mocking frameworks do.

As you can see, this is an all-around better way to write code and though it is understood that in existing projects mocking still may be necessary, there is no excuse for such to be necessary in new code.