React Native production app remote diagnostics / user assistance - reactjs

I have published an app built with React Native. Currently it's iOS only, but eventually may be released for Android as well. I'd like a cross-platform solution to remotely assist customers that run into bugs, crashes or any unexpected behavior. While the app could continuously log everything to a server, I've found that that's not very helpful since customers usually have very specific points in time that they need help with. Sifting through continuous logs is time consuming and generally a waste of resources.
My hope is to give the user the ability to press a button to send the stack trace, the last N minutes worth of logs, etc directly to me. This wouldn't work in the case of a hard crash of course. The vast majority of the time the app is functional when there's something they need help with.
A pie-in-the-sky idea would be to let the user share their screen with me.
Found this related question but it doesn't fully encompass what I'm trying to accomplish:
Release mode diagnostics in React Native

BugSnag looks promising. It's a paid service.
https://www.bugsnag.com/platforms/react-native-error-reporting

I tried BugSnag and a few other services. In the end, Sentry has the most reliable and simplest RN library. It's also free for the Developer plan (5k errors per month is plenty enough for us, and supports multiple apps).
https://sentry.io/pricing/

Related

Get running / walking pace in steps per minute using React native

I'm developing an app in which i'll play music which is synced your current walking or running pace. In order to do so i have tried using a pedometer input from expo, however this isn't working too great. Input of the pedometer is delayed and is therefore hard to fix. Is there a "better" way to get pedometer inputs in react native more reliably? Otherwise i could opt for trying to guess a walking / running pace by deeming how fast the user is travelling with google maps or similar.
How would you approach my problem?
I would drop expo. With expo you will be limited in the capabilities of your app, meaning you won't be able to add 3rd party native libraries to your app. These are what you are looking for to get the data you want. A quick google search found this, and I guarantee there are many other similar packages if this doesn't quite fit your needs: https://github.com/mathieudutour/react-native-pedometer
Once you drop expo, a world of possibilities will open up to you, but if you are unable to drop expo ... Not being an expo expert, I'm not sure what can be done to get better data. Depending on what you have made so far, dropping expo may be a difficult experience. Either way, good luck.

GCP App Engine flex (GAE): Error when deploying

When deploying using gcloud app deploy I get the following error:
Timed out waiting for the app infrastructure to become healthy gcp
I contacted GCP Support and they told me the same thing I had read in other threads:
the error you are referring to may be related to the Compute Engine “In-Use IP Addresses” Quota limit. You can view your current quota limit information by accessing from your GCP menu “IAM & Admin > Quotas”.
I checked the "In-Use IP Addresses" and it doesn't seem like I have a problem with quotas:
Looking for the error, I found that in the Activity tab, when deploying, I get an error. Apparently , when App Engine is trying to delete a VM, the process starts to loop trying to delete it. You can see the error:
(I intentionally covered the project ID)
Edit: It seem like the problem is only with southamerica-east1. I created a new project in southamerica-east1 but I kept getting the same error, so then I created a new project with the App Engine in us-west2 and worked like a charm (I used the same application and app.yaml). I wonder if the problem is GCP southamerica-east1 or a unknown bad configuration by my side.
This is probably related to this issue: https://issuetracker.google.com/u/2/issues/73583699. It does mentioned the "in-use IP Address" quota, but many people have posted in recent days (Nov 2018) indicating that they are seeing the error and have verified that they have not hit their quota.
Unfortunately, no solution has been posted and there hasn't been any recent comment from the devs.
First, our apologies that you’ve experienced this issue. Be assured that we are aware of the situation and the team works hard to resolve it.
Our goal is to make sure that there are available resources in all zones. This
type of issue is rare. When a situation like this occurs, or is about to
occur, our team is notified immediately and the issue is investigated.
We recommend deploying and balancing your workload across multiple zones or
regions to reduce the likelihood of an outage. Please review our documentation
which outlines how to build resilient and scalable architectures on Google
Cloud Platform.
For the time being, you can try relaxing your requirements (e.g. requesting a smaller instance or one with fewer resources) or removing the external IP requirement.
If that proves not to be enough, you can try deploying your application to another region
Again, we want to offer our sincerest apologies.
Thanks for understanding.
At the end we didn't find a real solution so we moved all our services from Brazil to US-2. I'm not sure if the Region is the problem, but there in US-2 all works like a charm

What Blockchain projects run in native mobile apps & What are the challenges in implementing it?

I am looking for the list of blockchain projects which are implemented in mobile apps natively. If you can find some, please point me to the list. If not, please let me know why there are no much blockchain projects implemented in mobile natively. Could it be due to performance, gas cost, complexity etc?
There are many risks that you as mobile app developer need to take care of when you ship your DApp in a form of mobile application.
1: Security - building your own app for blockchain means you have to built key management by yourself.
In current state of DApp, we have MetaMask, Cipher browser, Status browser, Trust browser and many others. The main problem that they're trying to solve is account management, the private key management, recovery process & good UX.
All of these need to be taken care of by yourself if you want allow your users to sign up for an account aka creating private key and store it securely in the phone. If hackers managed to reverse engineer and exploit your mobile app, they will be able to crack down the private key vault (the place where you store the private keys for your customers in their phones). You are screwed.
MetaMask and the gang above have experts that know what they are doing and always put security as their main pillar in the engineering process. Apart from that, they also have design team that always come out with better UX ideas so that everyone can adopt blockchain easily.
Bottom line, if you have security and design experties in your team that know well how to handle the key management, recovery process (mnemonic/seed phrases) & etc, it's probably a good idea to build your own inside your mobile app. Otherwise, I strongly recommend you just build web DApps and leverage MetaMask or DApp browsers above.
2: Trust - the idea of blockchain itself it to make everything decentralize and transparent. When you build a mobile app for your DApp, means you making it centralize. Your solution lives somewhere, in a server.
You will be relying on Apple and Google everytime you want to push app updates. Imagine you are an iOS developer and Apple is taking very long time to review and approve your app update submission? There's nothing much you can do because you are in centralized/close loop environment.
If you make it as web based DApp, you can deploy your DApp updates at any time you want. In addition to that, you also can host it to IPFS or Swarm to make it really decentralized application.
The beauty of not making it as a mobile app here is, your users can browse the code because all they have in their browser are static files; HTML, CSS and JS. Your users can tell if you are doing something bad in your code. Because they can right click on your web DApp and see the page source.
But if you are doing this as mobile app, your users can't really know what is 'behind' the app and you will find hard times to convince them later that they are in a good company.
3: Development - Web3JS is the most popular and stable project right now. It acts like a bridge layer between your DApp UI and the blockchain. And of course, it's written and needs to be implemented in JS.
Even now we started to see Web3 has been ported out to many other flavors i.e. for Swift and Kotlin, they are still new. Means, you will spend a lot of man hours later trying to debug and solve issues that only less people know to help/fix it.
To share my experience, I'm a Rubyist and there are some Web3 flavors for Ruby now. But, from what I've tested, they are still far from perfect and stable and at last, I decided to port everything to Web3JS for front-end components and Go for back-end. components.
FYI, the Ethereum Geth client is written in Go, check-out go-ethereum project. That means, everything that you need to do later i.e. creating transaction, signing transaction, querying blocks/transactions, creating/retrieving private key & etc has been tested and being used in real production. At any time when you are stuck, you can go ahead, read the source code of go-ethereum to learn how they do specific thing (the list above).
I'm not going againts all these new flavors. What I'm trying to tell you here is, it's going to take time for all this new flavors to get matured and stable enough. My advice for you now, if you want to do DApp, use Web3JS. If you need some back-end work (your centralized server <> blockchain), use Go.
I hope this helps!

Extra long loading time on Angular/django app

I just lauched a website http://www.dicorico.com running on AngularJS and Django for the back-end. The performances of Google Page Speed insight are not great and my Google anaytics indicates a page loading time under Chrome of 10 sec on average since launch on 22nd of October ... I'd like to identify the issue and have no clue where to start looking. Your help would be much appreciated.
Note, the app uses http://www.michaelbromley.co.uk/blog/171/enable-rich-social-sharing-in-your-angularjs-app to render HTML so that the content is crawlable by google.
Thanks,
Laurent
You need to first exclude the fact that it's your code that made the performance suffers. To debug the performance of django projects, use django-debug-toolbar in your dev environment.
There are too many other facts that could also slow down your website, the instance you use might not be performant enough to handle the traffic, or you are doing some backend process in crontab that eats up the resource, or your database is not optimized, or you simply didn't configure web server correctly, etc.
You might need to login into the box and check the memory/cpu/disk usage to determine where the bottleneck is, then try to improve that. There's no straight answer for that, hope it helps.

Database locked in Google App Engine

I was running two different versions of my app with the same api_version number, and I started receiving Database locked exception. I've closed both apps, removed both from the app engine launcher, and then reloaded the one i'm currently working on; and I'm still getting the same error.
I've been googling it for 30 minutes, and it doesn't seem like there is a lot of information on this topic specifically related to GAE.
I would like to know how to go about fixing the issue, but more than that, I'd like to know what's causing it in the first place.
I gave to 2 api versions different version numbers but the same api number with the hope that I'd be able to run them concurrently and have them share a datastore instance, but if its displaying this behavior locally, I'm sure its not going to work when deployed. I suppose I have less of an understanding of the versioning than I thought. If anyone has a brief explanation of that process, what causes locking and how to fix that would be great. Thanks!
EDIT:
'api_version' refers to google's api for app engine; nothing to do with one's personal application. still trying to figure out how to deal with 'version' and #endpoints.api. What's the diff?

Resources