Network Connection Required

One thing I see time and again in mobile app development is bugs caused by syncing a local persistent data store with centralized data on a server accessed via API calls. An incredible amount of software development time goes into making the sync process smooth, elegant, and robust. Yet, in a mobile world with nearly-always-on network connections, we need to ask ourselves if the effort makes sense for all apps, especially for MVPs (Minimum Viable Products) of apps focused on content consumption.

Why is sync hard? Generally, it's a matter of the server and the client having radically different data store technologies. The translation that needs to mediate that disconnect can be complicated. A common scenario is for a mobile app developer to use a BaaS (Backend as a Service) like Parse. To take the example and run with it, Parse has an arguably excellent, easy-to-use API. Yet once the mobile app pulls data down from Parse, which will be in the form of Parse objects (PFObjects), he needs to translate it into a format suitable for storage in something like Core Data or SQLite.

This translation needs to happen in two directions (SQLite -> Parse and Parse -> SQLite). Further, consider the situation where the client accesses the application from two different devices simultaneously. Perhaps device one makes changes to the same piece of data as device two in their respective local data stores, and then both are synced with the Parse data store. Which revision should take priority? There are solutions to this problem (of course), and they're not necessarily complicated - but they are intricate when one considers corner cases.

Parse together with SQLite was just one example - perhaps the server-side is using an ORM wrapping around MySQL and the client-side is using Realm. Perhaps the client-side is just using NSUserDefaults... It really doesn't matter. The bottom line is it gets complicated. So complicated in fact that the well-known and highly regarded Mac/iOS developer Brent Simmons wrote a "diary" about his experience implementing sync for the note taking app Vesper.

Is it worth it? I don't believe so for the majority of apps, especially when they're in the get traction phase. It's not worth the potential bugs and it's not worth the development time. What's the alternative? Keeping the local data in a more flexible in-memory store - essentially a cache - and requiring a network connection to do any content creation.

The advantage here is that it takes away a step in the translation process. After the data is deserialized from the remote server, it can be used instantly and we're not beholden to worrying about multiple devices. The copy on the server is always the canonical copy when it's the only permanent data store. If the user tries to post a comment/post a rating when not connected to the net, we simply tell him he needs a network connection. Keep it simple. It's not ideal, but in a content consumption app, it's probably a minor annoyance rather than a deal breaker.

This doesn't work for apps that feature long form content creation (such as a note taking app like Vesper - or perhaps a video sharing app). They need something robust that ensures even if the network connection dies the user will not lose his work. But for apps that are all about consumption of content not produced by the user, or where the user's data input will never be more than a short blurb, perhaps the syncing madness is unjustified. I rather the user have the risk of once in a blue moon losing a star rating than be subject to a crash-prone MVP.

It goes without saying that as apps move from the MVP phase to the "we have more resources" phase, syncing becomes a much larger priority. The point here is that early on, sometimes syncing is just too much of a distraction.

A Purposeful Personal Loss of Anonymity

This blog has existed for nearly three years and it's time for its author to stand behind its writing. Up to now, it's been unsigned. Sure, if one wanted to lookup who owned the domain name, the authorship could be easily obtained. However, it was purposely presented as anonymous to offer the subject matter a certain degree of freedom.

Yet, retrospectively, none of the content has been that controversial and there is certain merit to signing one's work:
  • It informs the reader about the biases of the author. Some may even argue it's a more ethical way of writing.
  • It may help to create a sense of connection between the author and the reader.
  • It may pique the reader's interest in continuing to read if he finds the author somehow relatable.
  • It lets the reader know what other works are by the author so that he can judge the work in the right context.
  • It allows the reader to judge whether the author is a reliable source.

So, my name is David Kopec, and I'm the author. I'm a software consultant in New York. That means I build iOS and Web apps (mostly for startups). I'm also the author of Dart for Absolute Beginners which in my highly biased opinion is an excellent starting point for learning how to program. I haven't yet written about politics or foreign affairs here and I don't plan to. I hope to keep the hate mail to a minimum. I also plan to start using this blog as a platform to write about more technical topics.

I started this blog in early 2012 when I was quite interested in the concept of anonymous content creation. Just a few months before that, I had launched the anonymous poetry app Poemz as an experiment, which has been mildly successful. As its sole moderator, having to read thousands of mostly anonymous poems, I've learned a lot about the strengths and weaknesses of anonymous content creation. The biggest feature requests are for less anonymity - users want to have profiles and commenting systems. They want to have some sort of identity and voice. Some users find ways to link to their real-life online profiles, which is of course against the anonymous spirit of the app.

In that time period we've also seen the rise of anonymous social networks like Secret. Anonymous content certainly has its place. It gives voice to those with something valuable to say who for whatever reason can't risk their reputation by putting their name behind it. The Federalist Papers were famously published by Alexander Hamilton, John Jay, and James Madison anonymously. Was there ever a better collection of thoughts on governmental theory?

I recently met with a startup founder focused on an "anonymous social network for positivity." They had built a cool app that was out in the wild and had some good ideas. The anonymous space is hot right now. Yet, positivity is not usually what people want to use anonymity for. Usually they want to use it for negativity. Think Reddit, 4Chan, black-hat hackers, and violent flash mobs.

I used to believe that the future of the Web was anonymity. The Web boom of the '90s focused on anonymous content consumption. The '00s were all about signed content creation (think Facebook, YouTube). I thought the third era would be a combo of the two - anonymous content creation. But anonymous content creation has its limits. We want to trust our sources, so we need to know who they are. We want to connect with other people, not just ideas.

For most long-form writing, for all of the reasons stated above, you should sign your work. That's what I've come to believe and that's what I'm now going to practice. I think Poemz and Secret are great platforms for short-form expression. I think long-form expression should usually be coupled with ownership/authorship. Especially, if it wants to be taken seriously. And I do.

About Me

I teach Computer Science to college students, develop software, podcast, and write books about programming including the Classic Computer Science Problems series. I'm the publisher of the hyper local newsletter BTV Daily.

You can find me on Twitter and GitHub. Check out my podcasts Kopec Explains Software and Business Books & Co. You can subscribe to my very low volume newsletter to find out about my future book, media, or software projects.


©2012-2023 David Kopec. As an Amazon Associate I earn from qualifying purchases.

Based on tdSimple originally by Lasantha Bandara and released under the CC By 3.0.