I use Fabric.io custom events to track almost everything in my app, but it seems to max out at 20 events.
How many custom events can I track with Fabric Answers?
Mike from Fabric here.
You can track up to 3,000 specific events (custom or pre-defined with Answers).
Related
I want to create a realtime stock alert app where users can subscribe to specific stock instrument with target price. Once that target price hit, The subscribed user will be notified over the app.
A good example of such platform is Tradingview.com
For stock API's I will be receiving realtime stock quotes from My API vendor over.
As far my knowledge is concern, I'm looking at this app as Web socket OR MQTT pub/sub platform where users can subscribe to that specific instrument topic and get notified once stock price is hit.
But my knowledge is limited when it comes to thousands of users subscribing to thousands of alerts.
What technologies must be going at the backend for such kind of apps ? What must be the data flow ?
Bit late answer to this, I was working on something similar with all custom NodeJS server and instruments you want to subscribe on. It is very simple server and you can find it here https://github.com/markosole/yahoo-node-streamer
I am working on desktop App built on top of Electron which is used for subscribing to instruments, monitoring multiple instruments and creating visual and sound alerts for every instrument individually. I have not release Electron app source to the public yet.
Creating mobile app will be harder as it would require backround data and best bet would be using Flutter and Google Firestore to send alerts. Well this is very top level.. I will eventually make flutter app and share it on Github
Overlooking the fact that there are literally thousands of apps out there that do all of this already....
Your best bet might be to do one of two things:
1) Just send out the stock price and let the client app figure out the alert, or
2) Have a back-end system that just sends out the alert to the specific customer when their price point is reached.
Option 1 is something that MQTT could easily do. Option 2 could be done using MQTT, but its something of an overkill IMHO. MQTT is built for applications where one node is publishing data, and many nodes are subscribing to that data -- hence Option 1 is more in line with what MQTT was built for.
I have built a platform that in essence allows users:
to create a company profile and invite your colleagues,
create an office with a floor plan,
add tables and meeting rooms to the floor plan with each meeting room having a separate calendar,
book tables and meetings in meeting rooms.
The platform is built on Python/Django.
Now I am trying to implement a sync mechanism that would work with Office 365 and local Exchange distributions. The sync would be two way, that means an event created in Outlook would trigger an event to be created in our system and vice versa.
My first attempt was to use the EWS SOAP API (with exchangelib). But soon I've run into problems when figuring out how to create triggers for Outlook events. This ended in failure as synchronization would involve constant bombing of slow API-calls such as iterating through accounts and checking if anything changed in their calendars.
Second attempt involved using the Microsoft Graph API that has this neat push notification feature that would solve polling (or so I thought). But as I later found out, having the administrator link his privileged Exchange account and then being able to subscribe event changes for all associated accounts in one go was not possible (thanks to this article). So again this lead to the realization that polling (or making everyone link their personal accounts) was the only way to go.
What approach would you recommend to achieve two-way sync with Exchange that would involve only having the admin do the account linking with as little overhead and polling as possible?
Is there anyone who have developed large-scale applications that do something similar? If so, can you push me in the right direction?
A bit late to the game here, but maybe what you want is the EWS SubscribeToPushNotifications service. It's not implemented in exchangelib yet, but there's a ticket for it https://github.com/ecederstrand/exchangelib/issues/145
Implementing the basics should not be difficult.
I have following questions related to events in composer.
Question 1: Can i write a READ acl rule for event to define which participant will receive this event?
Question 2: Is there a way to send events to specific participant?
Events are simply serialised and put onto the Hyperledger Fabric event bus. At present HLF doesn't have the concept of topic/queues to segregate the messages on the bus, or rich security policies to determine who can access the events.
At this time ACLs are not applied to Events, and there isn't a way to send events to a specific participant.
However we would really like to know your use cases and requirements in this are so please raise a github issue at
https://github.com/hyperledger/composer
and of course contributions welcome.
Is there a way to avoid race conditions when inserting events into Google Calendar using the API? I have an experimental app that needs to insert events into user's calendar. However, the user should not be double booked at a particular time.
The only true way of guaranteeing something like this is if Google provides a way. Other solutions are prone to race conditions (example, some other app that the user has updating it while my app is ignorant). The options as far as I can tell:
E-Tags with If-Match option - But this option is not valid for inserts according to the docs (https://developers.google.com/google-apps/calendar/v3/version-resources).
Important: There is no support for conditional modifications for
insert operations. Instead, it is guaranteed that if you are allowed
to provide a resource ID, then the operation will only succeed if no
existing entry has that ID.
So if I provide an if-match with the calendar etag and try to insert, it always fails regardless of the fact that the etag is correct.
Using "watch" for a brief period while the event is about to be inserted (https://developers.google.com/google-apps/calendar/v3/reference/events/watch). However, this solution is prone to race conditions due to the time take to get notified. One user inserting while my app gets notified of the update is problematic.
Sync the whole calendar with server periodically and consider the source of truth as the synced version and avoid double booking. Less optimal because new events added won't get synced fast enough, but the most likely will work.
What other solutions come to mind? I think #3 is the most suitable to guarantee consistency and integrity of data to avoid double booking.
I found a solution to this on this blog which states that you'll be using Calendar Resource API instead of the Google Calendar. I think this guide is what you're looking for.
Unlike a regular calendar, resources:
-Do not allow conflicts
-Can be shared across everyone on your Google Apps domain
-Can be invited (multiple at a time) to events, just like a person
-Their ability to share availability with everyone makes resources great for managing rooms schedules. Especially in a shared work
environment like your office.
FYI: This guide assumes you already have Google Apps. Currently only
paid accounts have access to resource calendars. If you’re
grandfathered in or using a personal Gmail account, this process won’t
make much sense.
I was wondering if it is possible to develop a text messaging kind of application similar to WhatsApp, but for between WP7 devices? What difficulty programming skill level am I looking at and what would be required to develop such an app? Thanks!
In general I don't think it will be really difficult to build an app like WhatsApp. (Although I only heard about the funcationality) So I will give you the information I think you should have at a minimum.
In the first place you need your WP7 app, which I think should have push notifications to notify users about new messages. (Note: push notifications work in batches, so there will be no instant delivery notification to the end user.) You should have a login system in your WP7 app, which makes users uniquely identifiable.
Somewhere you should have a central datastore where you can store users, messages, relations between messages (replies, forwards, etc.) (Note: If your app becomes as big as WhatsApp you should have a really good scalable datastore.).
I would use WCF to communicate between your datastore and the WP7 app. Probably I have overseen something right now, but this will give you a start for defining your applications architecture.
UPDATE 12:54
As i saw your comment about where to start I searched for some documentation:
There is a free e-book from Charles Petzold which covers alot:
http://www.charlespetzold.com/phone/
Also there are a lot of code samples and documentation on MSDN:
Main overview of WP7 development:
http://msdn.microsoft.com/en-us/library/ff402535(v=vs.92).aspx
WP7 code samples:
http://msdn.microsoft.com/en-us/library/ff431744(v=vs.92).aspx
You can have a look at the Sockets Support section, which may help you to get started.