Networking in Android


Networking in Android is hard. The standard pattern has been to pass a callback to the service performing the request, which performs some action on completion. Often these callbacks are anonymous inner classes created inside your Activity or Fragment. This works fine - until the user rotates their device, or hits the home button, or switches to another app. Then your Activity can be destroyed before the callback returns, resulting in your activity context leaking and your callback updating an Activity that no longer exists.

The issue is not the callback pattern itself - the issue is that the callback is tied to your Activity, but the lifecycle of the request is not. Google has released a networking library called Volley that allows for cancelling requests, tying them to the Activity lifecycle, and we have integrated it with our CloudMine library.

Volley works by creating new Request objects which encapsulate all the information needed to make and respond to an HTTP request - URL, headers, body content, success and error listeners, etc. These requests are then added to a RequestQueue, which performs the request. The Requests can be canceled from the RequestQueue, which is what allows us to tie the lifecycle of the Request to the lifecycle of the Activity. An example of this is given below:

For more information on Volley and all the neat things you can do with it, check out the Google IO introduction to Volley.

CloudMine: Now With Swift


The recent unveiling of iOS 8 introduced a new programming language: Swift.

Many are wondering when their favorite services will support this innovative new language. For CloudMine, that time is now. With the new CloudMine Swift library, it’s easier than ever before to upload, download, and manage your data and access other CloudMine functionality.

To use our library in your Swift projects, import the header file into your project’s bridge header.

You can download our library here, or install it using CocoaPods. A bridge header is a file that allows a developer to use Objective-C libraries in her Swift code. Be sure to designate this header in the Swift Compiler section of project’s target. For a more complete discussion, see this StackOverflow answer.

Both Swift and CloudMine are based upon the principles of speed and simplicity. Here are some quick examples to get you up and running with CloudMine:

First, create a CloudMine object to facilitate the transfer of data:

This can be created wherever the object is needed.

In the past with Objective-C, this is how you would save an object:

To save an object with Swift you simply call the save method on your object:

Here’s a shorter version:

Object retrieval in Objective-C:

The same in Swift:

It’s as simple as that. In less than 10 lines of code you’re on your way to building better apps, more easily, with CloudMine. Send us an email at if you have any questions at all. We are always here to help.

Why Biomeme is Using CloudMine


This is a guest post by Maximilian Maksutovic, Biomeme’s software lead responsible for iOS, web, and Arudino development. Biomeme is a startup developing a smartphone attachment that can perform realtime DNA analysis, and is backed by Mark Cuban and Dreamit Ventures. Product systems will sell for around $2,000, but the company is hoping to bring it to drugstores around the world for around $200 in a few years’ time. Just a few applications include tracking diseases, testing food and water for pathogens, and serving as a detector for bioterror agents.

Being a relatively young developer, I am fortunate enough to work in an era of incredible tools: sophisticated IDEs, excellent compilers, and every sort of library and API imaginable. The one thing I am most thankful for is cloud-based backend systems. I can imagine some older, more stubborn developers would like to say that building and maintaining custom servers “builds character.” However, I also understand that most startups, including Biomeme, do not have the time or money to properly build these systems. In addition, these systems are often painfully overkill unless your startup is serving large amounts of users and data concurrently; which, let’s be honest, it isn’t.

My first introduction to cloud-based backends was Parse. I used it for my thesis software engineering project, where I built a self-guided tour for iOS of the Fairfield Osborne Preserve at Sonoma State University. The app consisted of a map with the trail of the preserve overlaid on it. As you would walk on the trail, the app would trigger certain geopoints that would attract the user to a specific cultural, geological, or ecological point of interest. The user would then be asked to look around their current position and be quizzed about certain features regarding the point of interest.

Using a cloud-based backend made this project feasible in a very short amount of time. It took only 4 weeks. I was able to capture geopoints for both the trail and points of interest. I could easily tag the data necessary for the internal database for the app. Using this system also allowed for my biology major collaborators to have a central place to upload additional content (the quiz questions, detailed narratives, additional photos/maps/scientific data/etc.) without the need for email attachments and USB drives.

Prior to graduation I was hired at Biomeme, an incredible startup that enables anyone to do mobile real-time DNA analysis on a smartphone. We had some initial talks about the data management that would be required: we would have to collect and store both experimental and patient data. We would need to configure, save, and share different tests. We must have been able to display data on different devices, porting it to the web, integrating with disease monitoring sites such as, HealthMap, and SAGES, as well as electronic health records. Working with such sensitive data, I knew HIPPA compliance was going to be an issue and needed to be addressed from the start. My main problem with Parse is that it had directly stated it is not HIPPA compliant, and hadn’t made any promises of being compliant in the future. Regardless, we were at such an early stage that I told the team we should use Parse to get off the ground. I was thinking that, by some miracle chance, I could address the HIPAA compliance with some other solution or subcontract someone to help me do it.

When I moved to Philadelphia to join the team, we were working out of VentureF0rth, a co-working space that also played home for CloudMine. I hadn’t heard of them, but after some introductions they told me they had an open source API that was similar to Parse’s. I was certainly interested, especially considering that they said the magic words of, “Oh, and we’re HIPPA compliant.” After building up their MVP to our first beta, it came time to start the data integration.

After a very clear and simple “getting started” guide and tutorial, I noticed one thing right away working with CloudMine: the API felt so natural to the iOS SDK, as if it was written by Apple engineers.

My biggest pet peeve with Parse was subclassing, let’s compare the difference: Parse Subclassing:

After setting up the class, you then have to “register” the subclass in your AppDelegate:

Now let’s compare how we would implement this ISCoordinate subclass in CloudMine:

So let me explain some of my resistance with Parse. For the subclass you need to add this class method +(NSString) parseClassName, which was needed for my purposes just to return a string. This certainly seems a little superfluous. Next, the class has to delegate to <PFSubclassing>, which seemed cryptic to begin with. If one looks under the hood to better understand this process, the result is even more incomprehensible. You also need @dynamic instance variables, which are not well explained. Finally, you are forced to create a Parse instance method which requires the following line: MySubclass object = [MySubclass object]. The [… object] message, again, seems rather cryptic; and again, looking under the hood is even less helpful.

With CloudMine, the code is standardly defined, using the default initWithCoder and encodeWithCoder methods. This is helpful because now all of your CMObjects are compliant with NSSerialization. With this, we can store all of our objects locally in case the user does not have an active Internet connection, and the app can continue to function without an active connection. Moreover, nothing about subclassing with CloudMine feels out of the ordinary; I feel completely at home making CMObjects just as I would NSObjects. A good API written for a specific platform should feel completely native to the parent language, and I feel that CloudMine does perfectly.

Now, some developers reading this are thinking “Big deal. Every API has its quirks. Every language has its quirks. We just have to grunt, bear it and learn it.” Do you want to work with an API that forces its own architecture down your throat and requires a workaround from the developer, or do you want an API that works hard to conform to the language you are working with? I prefer the latter.

To drive the issue further, lets talk about business. Every choice of language, platform, and API has a direct business cost, especially for a small startup. A quick example: Biomeme’s app needs chart functionality, which a previous developer quoted nearly $20,000 plus many months to implement. I looked at the (free) Core Plot API and thought it was feasible, but to make it look pretty and perform well it would take a large chunk of time we just didn’t have. I decided to get a ShinobiCharts license (which was $400), however I had a beautiful Biomeme branded chart running in less than 3 hours. Should have I used a free API? Maybe. Would the extra time learning and the API to deliver a half-baked product been a good decision for Biomeme? Definitely not. The same goes for our cloud backend. Wouldn’t it be an amazing, fun project to build a HIPPA compliant backend hooked up to a Rackspace server, shuttle data in and out using Ruby or Python scripts, and encrypt and isolate the data with OpenSSL? Definitely! Would the massive time sink to do that, —plus the bug hunting, —plus writing the necessary documentation for other recently on-boarded developers be a good decision for Biomeme? Definitely not! All that time I would of taken to build such a solution would take me away from building core functionality of the Biomeme App, delay the ability to demo the system to customers, and delay our chances of making it as a startup.

By using CloudMine, I was able to deliver a brilliant product with all the necessary data being stored and retrieved from the app, hassle free. Better yet, all of the code and architecture I have currently written is completely future-proof for when we want to extend this data to web apps and other platforms such as Android. Best still, once we require HIPPA compliance, all CloudMine has to do (in the words of co-founder Ilya Braude) is “flip a switch” and we are fully compliant. I recently brought on a contractor for some work and he helped augment some data management within the app, and immediately fell in love with the ease of CloudMine’s API. Within a weekend, we had created a perfect, elegant, future-proof solution for shuttling data back to CloudMine, even in scenarios where there is no active Internet connection.

Of course I could have done all of this with Parse. Despite my minor problems, it is a fine API and used fairly extensively across the development world. But without HIPPA compliance and the lack of personal support, the platform falls flat for me. CloudMine is a company that I feel partners with you to help bring your product to a higher level. The level of support that CloudMine provides is second to none, and that is worth every expense of the platform. If I were to receive strange messages or if code seemed to not work right with the API, I could contact CloudMine and within a few hours have a detailed response, complete with code examples.

All in all, I chose CloudMine because I want a system that simply works. I want a system that allows me to write native Objective-C, perform tasks asynchronously, subclass to my heart’s content, and to be future-proof for things like HIPPA compliance. And most importantly, I want a system that has the incredible support CloudMine offers.

Business Continuity


StackMob, a mobile backend infrastructure company, recently shook the industry by announcing that they are shutting down their service after being acquired by PayPal several months ago. While significant speculation surrounds the situation, there are many customers seeking alternative backend solutions to power their mobile applications. StackMob has offered a CSV data exporter, allowing customers to extract their application data and continue development either on their own, or with the help of other backend providers.

In response to increasing requests, CloudMine has created a CSV/JSON importer to help ease transitions for those who enjoy the many benefits of a cloud-based backend platform. We understand that the migration of mission critical applications is not simply a matter of importing data, so our team is prepared to work closely with you to understand exact requirements, offer objective advice and insight, and help guide you towards your best path to success — even if our platform is not the final destination of your application.

As a long-standing enterprise mobility company we understand the business continuity concerns expressed about the future of BaaS providers. To address these concerns, CloudMine assures both our current and future customers that, in addition to you always owning your data, applications will always have the backend infrastructure they need due to the platform’s portability and flexibility to reside in any environment, in the cloud or on-premise.

If you would like to explore a conversation with CloudMine, please send an inquiry to and our team will be in touch. It would be a pleasure to build new relationships with you and we look forward to supporting your mobile development needs.

About Us