What would you recommend to get the GMT time in mobile application even if the user change his/her local time zone or time manually? In my app, users may take offline actions and I should record actualization time of these actions. Since this app is being used where cellular reception is low, this problem produces another consistency issues.
Any idea would matter.
Related
I'm currently updating a cryptocurrency loyalty rewards application written in React Native. The app allows you to "donate" or send tokens to others.
I need to make the token total for a user change in real time after making a donation. My problem is that the Ethereum blockchain takes about 15 seconds to update the totals on-chain, and currently the reducer is reaching out to the blockchain to grab the wallet balances immediately after the donation. We don't want to make the user sit and watch a spinner for 15 seconds, but we also want the value of their wallet to reflect the transaction immediately.
One solution I can think of is to just add or subtract the proper number of tokens totally within the state of the application, and only reach out to the Ethereum API on loading the application. Is this a suitable approach? What potential issues would I be introducing?
Unlike ethereum, you can't get balance on the pending block.
You'll need to be careful deducting user's balance. Token transaction have a higher chance to fail if the gas limit is set incorrectly.
I have used Microsoft Flow to check for new emails with specific labels using their gmail connector trigger 'when a new email arrives'.
Up until now I have had four flows running perfectly for over a year, until last Friday when errors started occurring. I am now testing with just one flow, single concurrency, which runs every minute (Flow Plan 2). The mailbox being checked receives at most 200 new messages per day, fairly spread out.
This is the error message which happens after the flow runs sucessfully 2-3 times a minute apart:
{
"statusCode": 403,
"message": "Out of call volume quota. Quota will be replenished in 23:01:41."
}
Microsoft claim this is related to the gmail API limit of no more than 60 calls per 60 seconds, even though the message above suggests a refresh of the quote in something close to 24 hours. It seems more like we are hitting some kind of daily limit, but the only one I could find on the gmail usage limits page is for 1,000,000 quota units per day, and I'm certain we are far short of that.
I have tried accessing quota usage from https://console.developers.google.com but since I didn't make a project and everything is setup from the Microsoft flow, there is no quota data shown.
Q: How can I verify the number of api calls being made from Microsoft Flow via the gmail connector, if that's even possible?
Note, I also started a thread on the Microsoft Power users forum to get help, but I figure if it's gmail API related then I may get better answers here.
Edit 27th Aug: Resolution was to export the flows to a new microsoft account. For whatever reason, the flows run fine on the new account (even though it has the same flow subscription). Microsoft still cannot explain why the flows would halt on one account and not on another.
I have just developed a mobile apps which basically for users to upload, download photoes, add, update, search , delete, refresh transaction, and query report. Every action need submit request to Appengine Server.
I am using CloudEndpoint, oAuth2.0 and Objectify to implement this appengine. When I'm testing alone, The instance hours has used up 40% . How much billing for instance can I imagine if 100 people using this app? How does it calculate the instance hours? by request of submitting? or by time of instance working on multiple request??
is it worth?
If my target is more than 100 users to using my apps. Is it worth? Could you please share me what exactly I misunderstood about this instance.
Thanks
As others have commented, the question is very hard to answer. The easiest answer I can think of is by looking at the response header "X-AppEngine-Estimated-CPM-US-Dollars". You have to be a member of the Cloud Platform Project (see the Permissions page in Cloud Platform developers console) to see this header (you can check it in your browser).
The header tells you what the cost of the request was in US Dollars multiplied by 1000.
But think of it as an indication. If your request spawns other processes such as tasks, those costs are not included in the number you see in that header.
The relationship between Frontend instance hours and the number of requests is not linear either. For one, you will be charged a number of minutes (not sure if it's 15 minutes) when the instance spins up. And there are other performance settings that determine how this works.
Your best bet is to run the app for a while against real users and find out what the costs were in a given month or so.
Trello shows the information of online/offline/idle status very accurately as I personally saw. There are several solutions for tracking users online statuses, and to do so accurately requires a serious overhead. There are also the traditional problems of not knowing if a user closed the browser, disconnected etc. that cause inaccuracy in showing the offline/idle status. For a platform that does not have chat functionality (which, I believe, which would have taken the overhead of tracking users' status and therefore makes the task finally easy) how is Trello achieving this, albeit without much overhead?
Also Trello is able to detect disconnects and resume connection (not so smoothly though).
The Pushing and Polling layer of Trello is described here
Each browser tab is considered to be a session, associated with one user. Each session's activity level is tracked separately, with a user being shown with the highest activity level of all of its sessions (where active is highest, then idle, then disconnected).
Each tab periodically sends its current status to the server - every minute if it has a working WebSocket, every 5 minutes otherwise. Current status is reset to active every time the tab gains focus, or there is a keydown or mousedown event. It goes idle if it has been more than 5 minutes since the most recent of those events. The tab sends a status of disconnected in the onunload event, but we don't depend on this.
Every time a session sends its status to the server, the server looks at all of that user's sessions to determine whether that indicates a change to the user's status. If it does, it broadcasts that new status to every person watching every board that user is on (this goes through the same framework that the rest of Trello's instant updates go through, and is too complicated to explain here).
The server also checks each session to see if its been too long since we've heard from that session (2 minutes if its a WebSocket session, 10 minutes otherwise) and removes the session if it has been (removing a session indicates it is disconnected).
There are a couple of optimizations hiding in there, but that's the main story.
Trello using socket.io.. so when ever a user login it broadcast a message that user has logged in , then they show him as online.
Once he disconnects they send a message on socket again to show him offline.
Many realtime apps using socket.io for showing realtime activities.
I need to develop a windows application with .NET 3.5 that needs to have a calendar and user can schedule appointments.
I want (not with a windows-service) that while the application is on, all the reminders that are set up for this user + reminders that admins set them up, should trigger an event in the application so I can handle it (showing the user a message, notify icon or whatever), once its datetime becomes now.
The data is saved in SQL Server and accessible from many computers, the admin should be able to externally create reminders for users.
Any approaches?
Locally, you could trigger the events using a timer that check the current time e.g. every 10 seconds or more often. The clients should regularily synchronize with the database server, querying all data for the current day or (on user demand) later events. This allows the clients to run and to remind the user even when the network fails for some time.
Another very interesting option is a server side reminder tool next to the database. It generates reminders and sends them via XMPP to the clients. The client machines don't need a special software anymore - any Jabber client would be sufficient, although a special software acting as an XMPP client would be possible, too.
You should really avoid popups. Popups are generally considered not user friendly. They interrupt the user's work flow. Even worse, they steal the keyboard input. What if the users was typing an important email right now?
Instead you might provide a nice, pleasant sound and a task bar bubble or similar.