BT

Barbara Fusinska on Building Offline Mobile Applications
Recorded at:

| Interview with Barbara Fusinska Follow 0 Followers by Werner Schuster Follow 9 Followers on Feb 10, 2015 |
09:59

Bio Barbara is a software developer, architect and team leader with 10 years experience having worked with companies from fast-paced startups to intl. corporations. Barbara enjoys building beautiful system architectures using best practices, modern patterns with a significant amount of common sense and a strong belief in team work and building the best environment for people to reach their potential.

Sponsored Content

Begun in 2012 this now annual conference hosted in Vilnius, Lithuania brings the best of the developer world to the Baltic's. The overall theme is building stuff, we have a heavy focus on lessons from trenches from the people that were there.

   

1. We are here at Buildstuff in Lithuania in 2014, and I am sitting here with Barbara. Barbara, who are you?

I am basically a developer, I've been a developer for ten years now, I am also a software architect but I like to merge those roles. I’ve been a manager for some time. I’ve never been on the UX design side, which I regret a bit because nowadays it becomes trendy. But yes, basically software developer.

   

2. Your talk here was about mobile applications or offline applications. So can you give us a summary?

So the summary is: more and more applications need to go offline because even though we have more and more places when we actually have Internet connection the places that provide us with Wi-Fi, like planes still there are some blind spots some dead zones, like basements, like in Krakow where I am from, a lot of clubs are in the basement, where you don’t have 3G and they don’t provide Wi-Fi because you’re in a club and you’re dancing. So this is the main point that it makes sense and sometimes you want to use our apps and you don’t want them to crash and say “You can’t use me because you’re offline”. Second point was that I was promoting two types of data synchronization, actually they're offline patterns which was deferred updating and full local database synchronization, and I focus on the second one because I was working with an app that was using it, and it was a full offline app, so I was talking about how to build your own API to allow full local database synchronization, and how to deal with conflicts when they appear and they will appear.

   

3. When you say full local database does that mean that all my data that’s on the server is also in the client?

At some point, because you might be an employee of the company and you might not be able to get all of the data. There are things like access rights, and also there might be a decision that we have so much data so we only download data that is a maximum of two years old, for example, but on a high level yes, we are gathering all the data that is on the server and also uploading our local data to the server.

   

4. As a developer who works on the server side, are there any mistakes that I can make that prevent offline applications, are there any mistakes that you’ve noticed?

Not mistakes per se but when you are doing offline apps like a fully offline experience, I am not talking about apps like Twitter or Facebook, that are partially offline, I mean they enable you to work offline but you can’t do everything. But when you have a full offline application, you need to have a separate API for data synchronization. And if you don’t do it, this is a mistake, right? Also when your app relies on some external services while working not on your local database storage, if that’s the case it won’t work if you try to use those functionalities, so this is a mistake, it is actually a frequent mistake. For example if you are doing an application that provides you a way of calendar, events, appointments creation and you do integration with Google calendar, or iOS calendar or whatever calendar there is, you need an external service, and when you are offline it’s obviously impossible right? But it doesn’t have to be a mistake; you can tell the user that “We’re offline, just wait until you are online so you can do it then”. So when I am saying full offline applications they can’t be fully offline if some of your functionalities are based on an online network.

   

5. You mentioned the word synchronization which is always a big problem, what have you learnt? Are there any pitfalls; are there any anti patterns that you can warn us about in synchronization? Are there any ways to do it right, or is it just a problem?

I think we are dealing, for example as developers, we are dealing with source code, and working in collaborative environments for so many years we still haven't figured out the silver bullet. And it was a problem it is a problem now. But the problem is only with one thing: with conflicts, so it’s not a problem with synchronization, which is basically simple because you post data and you get data, the problem is when there are conflicts, and when there are conflicts there are three ways to go: either you accept local data, local changes, or server changes, or you ask the user to decide, like Git does or any decent source control, or you apply some customized behavior, which basically nowadays means some kind of a merge. And merge also can be done automatically, behind the scenes, or you can ask the user to apply it or like some synchronization tools you can apply some code. So the very very customized behavior. Can you make mistakes then? Yes, a lot because there are so many edge cases and users are still inventing new ones, but basically those are the three ways to deal with conflict.

   

6. One other question is what is the difference between using synchronous APIs on the server and messaging, can it be helpful if you make everything messaging based on the server? Or is that a stupid question?

It’s not a stupid question it’s actually a very good question and I would say those are not the different things when we talk about synchronization itself, those are two different approaches on how we treat data in our systems. And if we have it event driven so we have a list of actions and those actions are applied to some objects, then when it happens on the server or on our local device, we just do it while synchronizing just posting the new objects that are there. So it’s still synchronization, we are just posting new objects. Still there can be conflicts, because if there are updates of the data, changes on the same objects, and they for example are applied to the color, still we need to decide which color to apply; local, server, the one with the most recent date, but the color change was driven by some data that weren’t there, so many problems, so many decisions to make. So I would say in general, event driven is the way to go to building the system, not necessarily when we are dealing with data synchronization, I think it makes data synchronization easier, but doesn’t solve conflicts, they will still be there.

Werner: So event sourcing and similar approaches would help there I guess.

Yes, actually Git uses event driven behavior.

   

7. Right. I guess to wrap up, so you don’t see that ten years from now when we have wireless access everywhere, this problem will go away?

No, I don’t think so. But still we’ve gained so much experience, we’ve gained so many examples of how it can go wrong, and we solve it one by one but I believe in our users' creativity.

Werner: To make more problems.

Yes.

Werner: That’s what they do.

That is a good thing, it is a good thing. I know developers don’t like that.

Werner: Not on a Saturday night when the problems come up.

Oh, but then there is an opportunity for us to show off.

Werner: Yes. To wrap up, are there any blogs or other things that you write that you want to promote?

Yes, with an opportunity like that I invite you all to go to my blog, it’s basically my name and surname http://barbarafusinska.com/ you can see it’s also on the Buildstuff agenda.

Werner: Ok, we’ll all check that out and thank you Barbara.

Thank you.

BT