I'm looking for an easy way to integrate Vue.js with AutobahnJS.
I've already checked this repo for guidance/template, but my main problem is that Autobahn has two layers of "wait":
First you create a Connection/Session instance
You wait for it to connect (maybe even retry N times)
Only after this can you access the session methods (subscribe/call/etc..)
With my limited JS knowledge (i'm a backend dev), i have two ideas:
Create a global variable which will be assigned to the autobahn session after connection. This will surely cause cases where the var is not yet set, so I'd have to check it's existence every time I want to subscribe from a vue instance.
Place the Vue init code into the Session connected callback, but then that would delay the whole application, which is obviously bad too.
I'm looking for a simple and efficient solution, not necessarily a full-fledged plugin (which I haven't found anywhere).
Any help/advice is appreciated!
I've been looking for a plugin like this: https://github.com/lajosbencz/vue-wamp
Plugin calls are deferred until autobahn Session is ready, unsubscribe and unregister are automatically called component-wise.
Related
Let's say I have a notes app. I want to enable the user to make changes while he is offline, save the changes optimistically in a Mobx store, and add a request to save the changes (on the server) to a queue.
Then when the internet connection is re-established I want to run the requests in the queue one by one so the data in the app syncs with data on the server.
Any suggestions would help.
I tried using react-native-job-queue but it doesn't seem to work.
I also considered react-native-queue but the library seems to be abandoned.
You could create a separate store (or an array in AsyncStorage) for pending operations, and add the operations to an array there when the network is disconnected. Tell your existing stores to look there for data, so you can render it optimistically. Then, when you detect a connection, run the updates in array order, and clear the array when done.
You could also use your existing stores, and add something like pending: true to values that haven't posted to your backend. However, you'll have less control over the order of operations, which sounds like it is important.
As it turns out I was in the wrong. The react-native-job-queue library does work, I just made a mistake by trying to pass a function reference (API call) to the Worker instead of just passing an object that contains the request URL and method and then just implement the Worker to make the API call based on those parameters.
It seems that in the Java SDK it is not implemented to delete Operations. The REST API supports it. So I'm wondering if I miss something or if this is the case.
Are there any workaround except using a REST Client to delete Operation(s) in a Java Application?
No, currently not (but feel free to send a pull request with an added method).
As background, operations should usually not be deleted by clients, but instead cycled through their process (pending -> executing -> successful/failed). If you delete an operation, it will be not available anymore and you cannot reproduce what happened on a device at a particular point in time. Deletion is usually taken care of by data retention management.
The easiest way to use an API that is not implemented in the client is calling the rest() method on your platform object.
This will return you the underlaying RestConnector for all API (fully initialised with credentials) and you can execute the calls with it (kind of manually).
My store.sync() can return success:false, and if it does, I would like to use something similar to Ext's failure callback to react to the error appropriately, but I did not find a possibility to use any builtin ST functions for this. sync has neither callback nor success nor failure option available in ST.
What did I overlook?
PS: I did find a workaround for success callback at Why is there no sync callback in Sencha Touch? but I need failure callback.
store.sync() is not where you need to look. Take a look at the proxy. Most likely you are using an Ajax request and that in turn will deliver a detailed success and failure.
I am now calling Ext.data.Model.save() on all Ext.data.Model instances that are dirty. This won't batch everything neatly together, but in 90% of the cases, only one item is edited anyways. The best is that this allows to check for failure on each and every item, and not only on the whole batch.
I am developing a site using App Engine and Webapp2.
I understand the concepts of OO and more or less how they are applied in Python. However I am confused about how App Engine uses OO. When an instance of my app is created, is one instance of each class created and re-used for each user? Or are separate instances created for each user? This will decide whether I should use instance or class variables.
So to be even more specific, when should I use self. variables (instance variables) and when should I leave out self. (class variables)?
Thanks for your help. :)
I would separate the concepts of object-orientation (OO) and request handling. First and foremost, App Engine is based on a request-driven model. A request is the base for most actions triggered on App Engine.
Second of all, be aware of the differences between an App Engine instance[0], which is like a container for you application and provided by the App Engine infrastructure, and an webapp2.WSGIApplication[1], which is an object instance of a class you defined.
To simplify things, I assume your app only has 1 webapp2.WSGIApplication . Now let's start with the first request your application gets. Before that, nothing of your app exists, except the code and configuration available on App Engine machines. Once the request reaches App Engine, a new App Engine instance[0] is created. Once the App Engine instance is in place and set up, it will instantiate a webapp2.WSGIApplication instance[1]. Now you have both relevant "instances" in place, the object being a part of the container. Next, the incoming request is routed to your webapp2.WSGIApplication instance which will handle the request according to the implementation you have done.
The App Engine system will create new App Engine instances for you dependening on the load. If a single instance is not able to handle all the requests that come in, it will create a new instance(first [0], then [1] within the former) and spread the load. If that's still not enough, a third instance is created and so on. The same is true if load decreases. If you application is currently running on 3 instances, but 2 would be enough to handle the load, 1 instance will be killed. In addition, you don't know which particular instance will handle which request.
And this leads us to your second question, should you depend on instance variables. Because App Engine creates and kills instances as it seems appropriate and you don't know which instance handles a request, you should always assume instances to be stateless. While it is not always the case, potentially every request can be handled by a completely new instance.
If you need to have state, use memcache (volatile) or datastore (persistent) or some other data backend (blobstore, files API, and so on).
[0] https://developers.google.com/appengine/docs/adminconsole/instances
[1] http://webapp-improved.appspot.com/guide/app.html
PS: people do use instance memory to optimize requests, but beginners who start to learn about App Engine should consider this an advanced technique.
I'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.