Some days before, i saw a blog post about why we need to keep whatsapp open on our smartphone to make it work on our PC.
It said that WhatsApp fetches the data (messages) from our smartphone and shows them on our pc which seems pretty good as it will lower the load on our database.
So now i wanted to know if there is a way to do so in react-native i.e, access the localStorage of one device from another.
Why i want to do that?
I am building an app where in the profile, i also take the profile picture from the user and i don't want to store it on the database but instead store it locally and serve it from there.
The reason for that is that we need buckets to store media files and serve them from there and i wanted to cut that part when deploying my app.
Related
I'm trying to make my own system with Django-Rest-Framework which includes also register/login system for mobile application. I keep user informations in my Django server.
The deal is: I'm new at React-Native and there is really less any source or tutorial for face scanning an comparing. I need to learn how to scan face (with FaceDetector or something else) and save it to my server. I know how to send it to my server, I need to know "what should I save exactly". And that would be really good if I learn how to compare a saved face scan data with a new one (so I can authorize users).
How can i make an offline app. For ex. user needs to use an app in offline like bible, dictionary app etc..
How can I make similar like this?
Every mobile app is an offline app unless it communicate with a server via some sort of https request.
Anyway, I would suggest you look into Async Storage (built-in react-native) or i would personally use SQLite.
Make sure to save your data mostly or wherever possible as text and render it on some sort of object to display. which will take less space than images making your apps faster and smaller in size.
I am making a mobile app using Cordova and I need to save some sensitive and not so sensitive data inside the phone. I am a bit lost on what is the best way to do it.
I need to save:
A JSON web-token (for authentication).
A response from server (I save this to populate my page in case the GET request fails).
Coordinates information when user is logging data to the app (for later upload to a server from with in the app). These will be many separate logs, and can be large in size for local storage ~5-10 MB.
Till now i have been successfully saving everything I need to the local storage but I don't think that is the correct way to do it. So that is why I need some help in deciding what is the best course to take from security point of view.
Saving server response is just for better UI experience and static in size so I guess local storage is a good option to use.
But web-tokens and GPS logs is sensitive information and I dont want to keep it in the local storage as it is accessible from outside the app.
What other options do I have?
Cordova still doesn't have encrypted storage.
Is saving to files a good approach? This here says that data contained inside cordova.file.applicationStorageDirectory is private to the app.So can I use it to save the logs and the token?
The plugin also lists the file systems for Android and iOS and lists which of those are private.
I am currently working with android phones but want to extend the app to iOS later. I have never worked with file systems and caches before so I am a bit lost.
Problem: Retrieve image from S3 and load into UIButton.
I'm currently doing my research on this issue and can't seem to make up my mind. Which is a better way to do it in terms of performance and security issue?
Also, do I need to do caching or store these images in Core Data?
Thanks!
It depends on how you use them. If your app is going to retrieve the images similiar to instagram, or twitter, it's good to download them as the user requested the images via the app.
If once the images are retrieved, the application going to use the images again and again multiple times, it's a good idea to store the images after they are downloaded.
For example, let's think about an application about "social networking" concept, and this app, let's say, has a chat interface which is functional after users add each other. As the users add each other, you download the images of the users and store them on the device, then you can use the profile images of the users by retrieving the locally stored images rather than retrieving them from the server, thus, each time they chat each other, you dont use the bandwidth for nothing. And you should also use a push notification or something that has a similiar functionality for the scenario, when a user changes his profile pictures, all of his/her friends should also be notified (I mean the app is going to be notified by the server) to retrieve and update their local profile image with the newly added ones.
As I said, it depenends on the scenarios of your application/server relationship. If the images you are storing on the AWS S3 are only going to be used only once, then storing them is useless. And If the user is going to use some of the images frequently (like app is a social networking app, friendship app and the friends are going to see each other's photo or uploaded images frequently), then storing them is a good idea, only for some of the users that who has subscribed to each other.
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.