Hacker News Reader

> This is the kind of polish that's really hard to do in hybrid, especially power efficiently.

Actually, CouchDB is great at supporting offline-first, local data that syncs behind the scenes.

Here are two mobile implementations that will work cross-platform:

https://github.com/couchbaselabs/Couchbase-Lite-PhoneGap-Plu...

https://github.com/cloudant/sync-cordova-plugin

That proves his point -- Couchbase Lite is native code and the PhoneGap plugin just calls out to it. A pure web app might use PouchDB in Cordova, but I suspect native beats it for energy efficiency every time.

He is not talking about a pure web app, he actually explicitly said _hybrid_

Hybrid definition: a thing made by combining two different elements; a mixture.

Using a cordova plugin to tap into native code while developing with web standards is a hybrid approach.

I already use Coredata for local persistence. I use Mongo behind a REST API for data storage.

So what would CouchDB give me? Offline data sync? That's useful but wasn't hard to implement on my stack.

The reason I didn't use something like CouchDB is the time saved up front probably wasn't worth the cost in optimizing/debugging. It's just much harder to track down and fix bugs and address bottlenecks when relying on a large library designed for general use cases to do much of it.

I'd also have to buy-in having CouchDB on my server.

In this case I'm pretty sure I made the right decision. If the requirements were less rigorous, CouchDB Orr something similar might be better.

Couchbase (not CouchDB) gives you a whole bunch of things. You get the embedded document database, sync/replication, conflict management, auth, scale, data routing, querying, and more. Not every project needs all these things, of course. It's just damn hard to get this stuff right when you do need it.

I also personally find it way easier to use than the standard stores on Android and iOS for on-device persistence. 2.0 is coming up and should simplify the use a bit, too. So as it stands now I'd say the main sweet spots are, ironically, around the two ends of the spectrum. Easy to use for persistent local storage with no sync, and the industrial strength solution when used with sync.

(I work for Couchbase on the mobile side.)

Actually, it looks really good, I'll look into it more.

I have lots of business logic on back-end tho, how hard is that to implement on the server?

I haven't used Mongo before. I have always been a Ruby/SQL shop, but now using Elixir/CouchDB. It was an awkward transition away from SQL, but I'm betting on this as a future stack.

Most notable: You write your logic in JS (See _view and _list functions). There are no transactions. Geolocation is not easy.

MEAN, transitioning away from angular though.

I thought this was a native app?

My product is essentially a SaaS for location based data collection with mobile app front ends. It's for businesses that service lots of clients at client locations and want to track work done. It's super easy to setup and is super customizable, has a flexible custom form builder, etc.

> I just finished implementing an iOS app that uses a background operations queue for network operations.

As someone who has never developed for mobile, is that OS provided, or something you had to implement yourself? It seems like something like that (at least for HTTP) should be included, and with some rich controls to toggle whether jobs should persist app closes and restarts, or jobs should wait for wireless or are okay on cellular, whether jobs of type X should replace other jobs of type X (no reason for 5 queued requests for latest updates to the same feed to all fire when conditions are right...), etc.

This is part of the OS.

Native iOS/MacOS provide a rich set of libraries around multi-threaded/background processing. Look up Grand Central Dispatch (GCD).

https://en.wikipedia.org/wiki/Grand_Central_Dispatch

iOS doesn't provide any high-level network constructs of this sort out of the box.

There are lots of classes to help with setting up and tearing down network connections, and convenience classes for standard things like encoding/decoding, parsing, etc, but complex task management is entirely up to the developer.

Operation Queues[1] do provide some of this functionality in a non-network-specific context and can handle priority/concurrency/dependencies between multiple tasks, but it's still up to the developer to layer any network activity on top of it.

Things like limiting some connections to cell/wifi, job persistence between app instances, and job deduplication, are entirely in the dev's hands - though the system does provide all the necessary APIs to implement all of the above.

A caveat though - the OS itself imposes some concurrency (max concurrent network connections for a single app) limits in an opaque way for the purposes of throttling, but the developer doesn't really have access to this.

[1] https://developer.apple.com/reference/foundation/operationqu...

I think Intent services do this on Android. I'm not sure as I am new to it.

Did you build that system yourself? I worked on an app for Android that did a few similar things, and tried at first to build all of the sync machinery myself. After spending a little time wresting with getting it working, I eventually discovered that Android really wants you to use the [0]System AbstractThreadedSyncAdapter class to do all of that, and let the Android system handle the details of periodic retries, network connections, and all of those other details for you.

I bring that up because this seems to be a common pattern in Android development, where in contrast to native desktop work, you look to the system first to do anything hard, and only build things yourself if the system absolutely can't do it, or the way the system does it can't be bent to do what you need. I'm not sure how much this applies to iOS development too, but I presume it's similar.

That means that hybrid development may be much more practical than you would think, because you aren't supposed to be building the things that are hard in hybrid/JS, as the system already handles it for you much better than you could. I'm not actually sure how these hybrid frameworks handle calling out to things like that, presumably they have a way to abstract it out, since they wouldn't have much point to existing without that.

[0] https://developer.android.com/training/sync-adapters/creatin...

Yea, I'm not that familiar with Android yet, it is next on my project timeline. One part of my decision was I wanted to learn Android, again to understand how to do everything the best possible way on native, before trying any cross platform code that insulated me from the OS.

You can absolutely build your own custom "behind the scenes" modules you hook the UI into.

I remember prior to Cordova building an app that had native image resizing/uploading code for both iOS and Android, and native notification support, but used a WebKit view for the UI.

That was a significant amount of work that would otherwise need to be duplicated across the two platforms, and double code maintenance.

Hybrid doesn't mean "don't ever touch native code," it simply means "don't touch native code unless you really have/want to."

I assume you wrote this in Swift right ? (seems it would have been painful in Obj-C). But then you would now need to re-write your app once again from scratch in Java (or now Kotlin) if you want your app to run on Android.

Believe me I thought about cross platform. If I had chosen that route I certainly wouldn't have used web views, I would have probably used Xamarin.

But ultimately my plan was to try Kotlin, and full rewrite so it was as optimal as possible.

> But ultimately my plan was to try Kotlin

Didn't get this - you will write an Android version?

Also, do you think two apps (one in Kotlin and another in Swift) can be done faster than a React Native (JS + platform specific code) that works on both, due to the tooling being so mature for each platform?

No, I think React Native should be faster. But my concern again is how much control it offers. I don't want to get coded into a corner, and not be able to address certain parts of the user experience as well as possible. But I admit my exposure to RN is very limited, one sample app project.

I'm starting a new job next week, and ironically I'm planning to ask if they've considered react native.

I'm not the Author but that's likely true though it could be in C++ and shared between the platforms.

In a bigger sense I don't understand why people make it such a big deal that you need to learn two languages. Swift and Kotlin are really simple to learn. Granted I've been programming for a long time (over 25 years and 19 professionally) but I've worked in at least 10 different languages over my career and learning a new one is ALWAYS the easiest part of working on a new platform.

I think the parent comment is criticizing the fact that you have to write an app twice, and not the languages per se.

That sounds like an excellent outcome!

If you would consider writing up your experiences in a blog post I'd be interested in reading.

I would like to try. Any blogging platform you'd recommend?

You can do that hybrid with PouchDB.

Nope.

It's not energy efficient, you can't control concurrency, and you can't utilize iOS app background time.

PouchDB is a nice solution that gets you most of the way for most uses, but it's also another layer. When your pouchdb database suddenly won't sync on iOS, or your battery usage skyrockets, you are in debug hell trying to figure out why.

I really like knowing what operations are running on which threads, so it's easy to tune/debug. For a commercial app, debugging problems can easily be most of the work, I want to make solving these problems correctly to be as easy as possible.

Further, it's far from unheard of for hardware vendors to specify a toolchain.