5 ms·

The author has a shiny hammer, and sees every problem as a nail. For example, I just finished implementing an iOS app that uses a background operations queue f

The author has a shiny hammer, and sees every problem as a nail. For example, I just finished implementing an iOS app that uses a background operations queue for network operations. It's super energy efficient. It doesn't care whether there is an active network connection, the queue will regularly check network access and intelligently retry operations until they succeed. It will continue uploads/downloads in the background, and restart them when the app or phone is restarted. It submits some operations concurrently depending on bandwidth and server, to maximize throughput. It has a smart algorithm for syncing server and app data, that also happens in the background. The user doesn't have to know or care about any of this. They only know that submitting a form always works instantly. And that they can review filed forms from other users even when far out in the boonies, away from any network service. This is the kind of polish that's really hard to do in hybrid, especially power efficiently.

ianai 9y ago
Further, it's far from unheard of for hardware vendors to specify a toolchain.
paws 9y ago
That sounds like an excellent outcome! If you would consider writing up your experiences in a blog post I'd be interested in reading.
- valuearb 9y ago
  I would like to try. Any blogging platform you'd recommend?
exclusiv 9y ago
You can do that hybrid with PouchDB.
- valuearb 9y ago
  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.
kbenson 9y ago
> 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.
- saagarjha 9y ago
  This is part of the OS.
- matwood 9y ago
  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 https://en.wikipedia.org/wiki/Grand_Central_Dispatch
- potatolicious 9y ago
  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/operationqueue https://developer.apple.com/reference/foundation/operationqu...
- 9y ago
tropshop 9y ago
> 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-Plugin https://github.com/couchbaselabs/Couchbase-Lite-PhoneGap-Plu... https://github.com/cloudant/sync-cordova-plugin https://github.com/cloudant/sync-cordova-plugin
- robterrell 9y ago
  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.
  - tropshop 9y ago
    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.
- valuearb 9y ago
  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.
  - HodGreeley 9y ago
    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.)
lenkite 9y ago
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.
- valuearb 9y ago
  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.
  - swah 9y ago
    > 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?
    - valuearb 9y ago
      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.
- jaegerpicker 9y ago
  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.
kromem 9y ago
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."
ufmace 9y ago
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/creating-sync-adapter.html https://developer.android.com/training/sync-adapters/creatin...
- valuearb 9y ago
  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.
deleted 9y ago
[deleted]

ianai 9y ago

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

paws 9y ago

That sounds like an excellent outcome! If you would consider writing up your experiences in a blog post I'd be interested in reading.

valuearb 9y ago
I would like to try. Any blogging platform you'd recommend?

exclusiv 9y ago

You can do that hybrid with PouchDB.

valuearb 9y ago
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.

kbenson 9y ago

> 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.

saagarjha 9y ago
This is part of the OS.
matwood 9y ago
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 https://en.wikipedia.org/wiki/Grand_Central_Dispatch
potatolicious 9y ago
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/operationqueue https://developer.apple.com/reference/foundation/operationqu...
9y ago

tropshop 9y ago

> 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-Plugin https://github.com/couchbaselabs/Couchbase-Lite-PhoneGap-Plu... https://github.com/cloudant/sync-cordova-plugin https://github.com/cloudant/sync-cordova-plugin

robterrell 9y ago
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.
- tropshop 9y ago
  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.
valuearb 9y ago
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.
- HodGreeley 9y ago
  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.)

lenkite 9y ago

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.

valuearb 9y ago
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.
- swah 9y ago
  > 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?
  - valuearb 9y ago
    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.
jaegerpicker 9y ago
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.

kromem 9y ago

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."

ufmace 9y ago

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/creating-sync-adapter.html https://developer.android.com/training/sync-adapters/creatin...

valuearb 9y ago
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.

deleted 9y ago

[deleted]