How do you write unit tests for something like this? Are there frameworks that make this kind of model easier to deal with?
Offline First – A Better HTML5 User Experience
131–140 of 150 posts
Re: Offline First – A Better HTML5 User Experience
#132The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…
Having recently built an offline first app (mobile app I'll admit), we didn't use a command queue, and I regret it deeply now. I advise everyone who's reading this to go for a command queue. Saves a lot of time debugging data sync. Our biggest challenge was to sync data with relationships, especially data with circular relationships. We couldn't come up with a generic way to sync circular relationships, so we ended u…
Did you consider using an off-the-shelf solution like Realm?
In my experience it made it trivial to handle the synchronization of arbitrarily complex object graphs (including those with circular dependencies).
Re: Offline First – A Better HTML5 User Experience
#133Earlier quoted context omitted.
Conflicts are actually not all that difficult to solve. We had to solve this exact problem with a time entry solution that needed to be mostly available offline. Taking most of our inspiration from Git, it was simple. Define the atomic unit of conflict, and the definition of a conflict that cannot be automatically resolved, and simply help the end user understand and resolve the conflict. 95% of cases were fairly eas…
The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.
The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention."
Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated.
When assumptions change, you really have a management problem on your hands. There's more information (sometimes very complicated information, like "the back office changed his hours to at least 8 because of union contracts, so now he has 11") that must be communicated and decided upon, sometimes by more than one person (e.g. foreman and superintendent) to figure out the appropriate resolution.
In version control systems, this is the same, and unavoidable for asynchronous workflows. It's basically optimistic locking, really. You make changes hoping that nobody else has altered the data, then check to see if any of your assumptions (i.e. nobody else is making changes) have held. If they haven't held, then you need to recheck your assumptions and resolve the conflict; there's no way around that.
Re: Offline First – A Better HTML5 User Experience
#134The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…
You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's not a matter of pushing clients' commands anymore. Instead you have to merge changes (either backend or front end side) before fetching the new state. For example, I try to purchase an item on my desktop, but can't because I lost connectivity. So, I proceed to b…
CQRS = Command Query Responsibility Segmentation – http://martinfowler.com/bliki/CQRS.html
ES seems to be Event Sourcing – http://martinfowler.com/eaaDev/EventSourcing.html
Re: Offline First – A Better HTML5 User Experience
#135I'm surprised no one has mentioned Meteor[0]. [0] https://www.meteor.com/
And me too. Meteor becomes my most favourite development framework in 2016. The ability of offline and data sync are some-kind of "by default" once I start a project, or just a simple test on idea.
Plus, packing it into a desktop app is lightening fast. It is a "wow" factor for potential clients.
Re: Offline First – A Better HTML5 User Experience
#136Earlier quoted context omitted.
The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.
The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated. When assumptions change, you really have a ma…
The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention."
Suppose you change foo from 9 to 10. Was that because you now wanted foo to be 10 specifically, or because you wanted to increment foo and it happened to be 9 before so it becomes 10 now?
In isolation, these have the same effect. However, one is absolute and the other is relative, so if two of you happen to make that same change at the same time, your intentions matter very much to how your respective changes should be combined.
For example, if your code knows that both changes were intended to set new absolute values, it can automatically determine that the combined effect should also be 10. Similarly, if your code knows that both changes were intended to increment foo, it can automatically combine those effects to get 11. But if all it knows is that two people changed foo in concurrent updates that now need to be merged, that probably results in a conflict that requires manual resolution by a user.
Re: Offline First – A Better HTML5 User Experience
#137Earlier quoted context omitted.
Wait, what native app sandbox are you talking about? Any executable I run has access to my files, and that's how it works on every OS I've ever used. I am too trusting of browser security though, you're right about that...
There are tons of sandbox type features in most modern OSs to prevent apps from interfering with each other. For e.g.. 1) Virtual memory protection (can't access other app's memory) 2) Protection rings (safe transfer from UM to KM for system calls) 3) User interface isolation (one process can't interact with another's UI) 4) I/O privilege levels (prevents one rogue app from causing I/O starvation) 5) Process Integrit…
Yes and these protections are only used to their full potential on something like iOS. On Windows, macOS, and Linux these are not used to defend your data or system out-of-the-box like they are in a browser.
A massive wall with an open gate isn't much of a wall.
Re: Offline First – A Better HTML5 User Experience
#138Earlier quoted context omitted.
The problem I have with this approach is that you don't encode the intention with each change. You just encode the data itself. This makes it a bit of a hack, unfortunately. You can end up in conflict-resolution cases which you cannot always predict beforehand. Yes, from this viewpoint, Git (and every similar version control system) is a hack. But it works well in practice because humans are running it, not machines.
The intention was "I want to change this guy's hours from 5 to 8." I don't know what else you might mean by "encode the intention." Unless you're referring to something I'm utterly overlooking, I don't see how you'd get around the invalidated assumptions that came from being offline and having outdated information. Intent doesn't matter if the intentions were invalidated. When assumptions change, you really have a ma…
Intention has no 'from' clause. You express the intent as "I want this guy's hours to be 8."
It doesn't matter if the UI shows 5, and another mechanism has changed the value to 9 in the background, your intent to set the value to 8 is unaffected.
If, however, you assume the "from" clause and do a +3 instead of =8, you get a new invalid state 12.
Encoding intent implies declarative statements as apposed to impaitive statements.
Re: Offline First – A Better HTML5 User Experience
#139The most useful pattern I know of for offline web apps is the command queue. Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue. User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local…
Unfortunately, the "command queue" abstraction does not work very well with access control. Imagine that one day the requirements w.r.t. security change. What do you do when some parts of the state may not be viewed by all users? And what if that logic depends on the state itself?
Sorry, I don't understand. Could you give an example?
Re: Offline First – A Better HTML5 User Experience
#140Earlier quoted context omitted.
One thing I have noticed in this thread in general is that the web devs are extremely defensive. No, a web app is not inherently bad. No one is saying this. But cherry picking questions to prove a point is silly. However, to show it's not a gangup on web apps here we go: Speed of the install process? Probably slower than loading a web page for serious applications How does the update system work? Depends if you're re…
And one thing i've noticed is that "native devs" are extremely condescending. I hear a LOT about how writing an application for the web is wrong (especially on HN), but not much about why it's a good idea. I see comments about how native is faster, "less bloated", portable, "better designed", offline, and more secure. But never any comments on how long they take to install, how difficult it is to use them across mult…
Part of the issue is that you are optimising for your own time and experience, not the users.