Mine Rejser

When Bo Frese grew frustrated with the mobile options offered by Denmark’s public transportation network, he did what any enterprising developer would do: he created his own application — called Mine Rejser — to make the experience more convenient. Now Mine Rejser regularly appears in the top 5 most popular travel apps in the Danish App Store. We chatted with Bo to find out more about Mine Rejser and his thoughts on Realm.

Tim Anglade, VP of Product at Realm: Obviously the mobile development scene in general is booming, but I don’t think people know that much about Copenhagen and the mobile development scene there. How would you characterize it?

Bo Frese: There’s quite a bit that’s going on. CocoaHeads is really active and more active than some of the other meetups that I’ve been joining. A lot of people show up every time, and there are a lot of interesting presentations each time, so people are very active and also willing to share.

Tim: It definitely seems like a tight-knit community. Even the Android groups are seemingly pretty active, and there’s no shortage of startups and people doing cool stuff. So how did you get into mobile apps?

Bo: Well, I’ve been developing software for more than 25 years and got in on the Web movement quite early on. Then mobile caught up and sounded interesting. I’ve been busy doing other stuff — usually Web consulting gigs — but I’ve been trying to squeeze in the time to develop for the iPhone.

T: So you’re an independent contractor these days, right?

B: Yeah, I am.

T: I was seeing online you do a little bit of everything. Some typical consulting, Web stuff, some Agile stuff, some Scrum. Do you usually take on a range of projects?

B: Yeah, I tend to have some long contracts and mix it up with lots of short, interesting stuff. I’ve been fortunate to have some customers here where there’s a flexibility so I can do the small stuff as well, instead of wanting to book me for 100% or 200% or something.

T: It’s that Danish work-life balance I keep hearing about. It’s a very foreign concept for the US [laughs].

B: I wouldn’t say that’s the norm. I guess I was just lucky or convincing enough to make the customer accept that kind of arrangement.

T: That’s great. I really like your outlook. I’ve been talking to a couple of other Danish users, and they had the same outlook you do about mobile, where it’s just very natural. I find a lot of people in other places who see it as a big obstacle, that they *have* to move to mobile and they do it against their will. They just want to be able to keep doing what they’re doing. So I really like the approach and outlook you have of just saying, “Yeah, of course mobile is the next thing. And of course I’m really excited to move my career from one phase to the next.” So props for that. I think it’s a very refreshing, very modern way of looking at things.

B: I guess there’s a natural sort of mix-and-match. Most of the interesting mobile apps have a backend somewhere, so you kind of need to know both ends.

T: That makes sense. So where did the idea for Mine Rejser come from? Can you speak a little bit about what the app does?

B: Yeah, it really only has a Danish audience. A couple of years ago the government introduced electronic payment travel cards for trains and buses and so on.

T: So it’s just kind of like a card, like you would have in Europe or Boston or Paris, that allows you to pay for your rides on public transportation?

B: Yeah, like in London, they have something called an Oyster card. And I don’t know what you have in the US.

T: We have a really bad system in the US for public transportation. [Laughter] But in San Francisco, it would be like the Clipper card.

B: So they’re doing sort of a gradual rollout of the electronic version, and I was one of the first people to have one. And I was kind of annoyed that I couldn’t get a quick overview of my actual travels and what I had paid for and not paid for, except through their webpage, which was not very mobile friendly. You have to remember your password and log in each time. It’s just not something you want to do on the move. And some people have a card where it doesn’t automatically take the money from your bank account — you have to put electronic money on the card, and so you want to know in good time when you’ll need to fill it up again.

So I thought, “Why haven’t they created an app yet?”

Mine Rejser is basically an independent project and not done in collaboration with the creators of the card. I’m logging in on the website, on behalf of the user, and doing Web scraping. That’s kind of the protocol that was available.

So it’s sort of a typical mobile need of an app, to have the ability to take a quick look at something while you’re on the move. Do one thing and do it well and do it simple.

T: I like the design; I think it’s very straightforward, very clean, very clear, and it’s really good to be able to have that information on the go.

I was actually surprised about the number of options I had for mobile travel when I was in Copenhagen. I could buy some one-way tickets directly from my phone and that kind of stuff. You mentioned that the system is fairly new, right? So it’s going to be a national transportation card for all the cities?

B: Yes, it already is. They started out about 2 years ago, I think, and eventually want to replace the physical cards, a sort of cardboard thing, with this electronic version. But they’ve had so many startup problems and people weren’t super happy with it. [Laughter] But it is national now. You can use it in all of the markets. It’s one of the options but, eventually, it will be the only option.

T: That’s really forward looking, to be able to do that at the national level and kind of simplify things.

You mentioned the app, the way it works internally. So there’s no API for this; you just kind of have to log onto their mobile website to get the data into usable form? You’re literally just scraping the HTML into content you can render inside the application?

B: Yeah. It is a bit of a challenge, of course, because I’m relying on them not changing the interface too much.

T: I’ve built too many products like that. [Laughter]

B: I was a little bit worried doing it like that, but it has been surprisingly stable. Although, actually, like a month ago they changed some things and, all of a sudden, my app stopped working. So that was not so much fun. I got a lot of user-based complaints.

T: Yeah, that can be tricky. But at the very least, that’s a good way of bringing attention to the fact that they should have a mobile app or an API. There’s no better way to get them to move and put that out there.

So what are you using Realm for inside this application?

B: Well, actually, when I first made the app about a year and a half ago, I made it fairly quickly and I saw it as just, you could say, a customized browser. Obviously it didn’t look like a browser, but it behaved like one. So I actually didn’t install the data. You would connect and it would get the data for you, and when you turned off the app, it would forget all about it. Just like a Web browser would just keep it in-memory.

That was a quick and easy way to do it. But then, after a while, I thought, “Well, why not keep it and store it online so it would respond faster and I would only have to download the new content?”

T: And then you can see all your travel history.

B: Yeah. And I wouldn’t have to download all of it to provide along all your rides. I think they provide one year of travel now on the webpage, but they could potentially keep more. And then some people have several accounts and many cards per account.

T: That can add up really quickly, especially if you’re doing scraping.

B: Yeah.

I had been looking at Core Data for some of the other apps I’ve been developing. And I thought it was way too complicated. I’ve been doing so much other development over the years, and I was quite surprised that it was so complicated just to get a database and install some data.

So my initial reaction was just like, “That can’t be right. There must be some other way to do it.”

Eventually I did end up using Core Data, but I wasn’t quite happy with it. Then I heard the presentation on Realm, and I said, “Well, that’s definitely worth a try.”

This app was sort of the obvious candidate to try it out for real because it’s already out there on the App Store and fairly popular with a big user base. Make it for real instead of a toy project.

T: How hard was it to switch? Did you switch over from your Core Data implementation, or did you switch directly from your in-memory version?

B: This app actually didn’t have Core Data. I was using it in some of the other apps I’m working on. This one would just download the data and keep it in an array or something and display it, and then forget all about it when the app was closed.

T: So was it hard to go from that — those in-memory objects and arrays — to using Realm?

B: No. I would say that it was surprisingly fast and easy because it is just classes, objects — the natural kind of way. It was really a pleasure to get started with Realm.

T: That’s great. Do you think you’re going to give it a spin on some of your other applications and other scenarios, or do you think there are still things that are maybe a little bit too complex or that you’d rather still do with Core Data for now?

B: No, I’ll definitely use it on other apps, for sure.

T: Did you encounter any particular issues with Realm — stuff that didn’t work as you expected? We always want to spend time talking about those things so we can improve the product.

B: I think many issues you have sort of solved over time. Testing was one of the first things and I’m still a little unsure about it. I wanted to have some automatic testing frameworks so that way would be obvious to use the in-memory Realm for that, and I had some problems just linking things. There was something on the Google Groups about it, and various solutions, but I had already tried it and failed before the solutions came up. So I tried to sort of untangle what I’d tried to do, just to get it working.

T: Yeah, testing is surprisingly hard when you need file system access in Xcode. I was following up on that thread. And we had a couple of ideas beyond what we recommended to try to make it as easy as possible, but I’m always kind of surprised how tricky it can be to do things that are seemingly simple in other environments. So yeah, that’s one I know we have an eye on.

B: Yeah, first of all, make it easy to install the CocoaPods. Have a nice recipe for “This is the way you make both your test target and your normal target work.” There is some snivel about it on the Google Groups, I think, but I’m not quite sure it’s in your core documentation. Some dos and don’ts on how to set up a unit testing in a decent way.

T: You’re right. We should add that.

B: I just saw on the newest version, you said that the default Realm can’t be in-memory anymore. Because that would be a natural way (for testing). And that’s the way I’ve set it up so far, very early in my app, if I’m in testing mode or not. If I am in testing, I’d say default Realm should just be this in-memory Realm. But if it has to be something else, and not a main thing, then how do I set up my testing? I haven’t looked at it yet. I haven’t tried it out yet. But I’m just saying, “Hey, there’s something here. Does that still work then?”

T: Yeah, absolutely. This is something that we had to change for a mix of complex reasons related to how the in-memory Realm worked. And part of it, if I remember correctly, was being able to keep a reference to it, which the default Realm doesn’t really make as easy as for other Realms. So that’s why I think we are strongly moving people towards not using the default Realm for in-memory, so that we can maintain that more easily. But I could be wrong. All I know is that there was a very good reason why we changed that in the API design from only the default Realm being possible in-memory to every Realm *but* the default Realm being possible in-memory.

We try to keep those changes to a minimum, but we are pre-1.0, so there are still a few things that may change while we get there. But I think so far, we haven’t broken too much API.

B: But it would be nice to have an overview of, like, “This is the recommended way to build an app with automated unit testing.”

T: Absolutely. I’m writing up the Asana task for this right now [laughs].

B: There’s also the null values thing. I’m currently doing all kinds of weird, bizarre workarounds to get around that fact.

T: We appreciate the effort that people go through for that. It’s a big part of our design that we felt strongly about when we designed the core a long time ago. A lot of people feel like allowing null values is where relational databases went wrong, opening up a whole set of problems that app developers have to care for.

But I think, obviously, times have changed now and people deal with JSON everywhere and they need to have null values, and it’s just not possible to build a database that doesn’t support null values. So we really appreciate people dealing with all these workarounds. We actually have somebody working on this right now, in allowing null values in the core, and then we’re going to expose that in Cocoa and in Java as quickly as possible.

B: That’s high on the list because you end up with these pretty bizarre workarounds if you don’t have it built into the core.

T: Yeah, absolutely. There are a few things like that that we feel pretty ashamed about, to be honest. We really understand the pain that it causes, and we want to fix it as quickly as possible. The other one is fine-grained notifications. We’re also doing a lot of work around being able to do asynchronous queries on the background thread. There are a few things that we understand are kind of critical and that we wish were fixed yesterday.

B: Another issue was the rollback. I mean, if everything is a transaction, then you should be able to easily roll it back.

T: Yeah, we just shipped that, as you probably saw, in 0.87.4, I believe. So that should be in pretty good shape. The big reason for our transaction was actually not from an asset standpoint, although it’s related. It was being able to manage the locking of the database. The original design was approaching it from the locking angle, and so it took us a little bit to get to the rollback. But I’m glad it’s there at the Cocoa layer now.

B: I upgraded to 0.87 yesterday, actually. I was on 0.85 until then because 0.86 was playing tricks on me for some reason.

T: Oh, really?

B: Maybe not because of Realm. Maybe because of the CocoaPods and Xcode. That’s actually one of my annoyances with the whole Xcode environment, is sometimes I end up with all kinds of really bizarre things when upgrading CocoaPods.

T: We updated some API things, but I don’t think we broke much on the CocoaPods side. So yeah, the best thing to do is to flag those issues on the Google Group. And usually we’re pretty fast to respond, so let us know. We’ll be glad to help out even if it’s not technically Realm’s fault that the project isn’t working. We’re here to help.

B: Yeah, I got some useful input from you all, so I appreciate it. I’m just wishing that somebody would build an even better CocoaPod so that it actually always works with no hiccups.

T: It’s tricky. We talk with a lot of those people. And I have a ton of respect for what they’re trying to do. I think it’s really hard to do it, especially because Apple has very poor documentation sometimes about how these different components of the ecosystem work. I think they’re doing something pretty neat, considering the amount of access they have and considering it’s everybody’s side job.

But I agree that it’s also tantalizing because it’s so close to being exactly what we want but, in some ways, I’m sure they acknowledge that it’s not entirely there yet. And maybe that’s the way people feel about Realm too. We’re getting really close to the way people want to be dealing with their data on their app, but I know we fall short in some aspects. And I know that must be very infuriating.

What CocoaPods is doing is a tough problem, and I try to make sure we give them as much help as we can on our side. I know they can definitely use the help from the community as well, with anybody jumping in on GitHub and taking a look at some of the stuff that’s broken. Quite a few people are working on it. I’m sure they’ll get it right as quickly as they can.

B: Yeah, I’m guessing it’s mostly because of Apple’s way of setting up the whole build environment. It’s a little bit bizarre, I think, or too complicated.

T: Yeah, and it also changes a lot without notice, and then you find yourself having to deal with stuff like Swift all of a sudden, from nowhere.

It’s really a tricky environment to play in. I’m glad that they’re courageous enough to actually jump in and try to do that. I think we need more people with that kind of courage, even if it sometimes feels infuriatingly close to being perfect.

So what’s next for you? Are there any other cool apps that we should keep an eye out for? Anything that’s on the burner right now that’s going to be launching soon from you?

B: Nothing that’s launching soon. I’m still sort of in the lab experimenting.

T: Well, we’ll keep an eye on your LinkedIn page to stay in touch and see what you come up with next. Thank you so much for taking the time to chat.

B: Absolutely.