I'm developing a mobile app with React Native and Expo managed workflow. The app is supposed to serve as a song book with lyrics to songs and hymns. All of the lyrics are stored in Firebase' Firestore database and clients can load them in app. However, I also want to implement offline functionality, where all of the lyrics are stored on the user's device.
When researching how to achieve this, I came across two packages: Expo FileSystem and AsyncStorage. I'm wondering which one of these is a better fit for my application. I tried to find some comparisons but couldn't find anything relevant. Can anyone advise me on this?
I've read that AsyncStorage has a cap of 6MB of data you can store. I did some math and found out that if I have a double headroom for my data, the total size would be around 2MB. (lyrics for one song which I have stored in .txt file are between 500-900 bytes, there will be around 1000 songs. So if I take 1000 * 800 bytes = 0.7 MB and if I double the number of songs, which will probably not happen, it's around 1.5 MB)
The songs are stored as objects in database, I used the .txt file just for size calculations, so I think the final size will be even smaller.
So, is there anyone who can tell me the difference between FileSystem and AsyncStorage and maybe advise me on which one to choose for my project?
You don't have to store them yourself, you can access them directly from Firestore local persistence.
From the Firestore docs:
This feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline. You can write, read, listen to, and query the cached data. When the device comes back online, Cloud Firestore synchronizes any local changes made by your app to the Cloud Firestore backend.
Full docs here.
Also a nice tutorial here here.
Related
I'm facing a problem while developing an app in React Native - I'm not sure what kind of local (persisted) storage I should use. The data I'm trying to fetch is sensitive, so it needs to be encrypted. Additionally, I don't know what properties the objects will contain, so I'm not convinced that using SQL-like engines is the best option.
MMKV sounds cool, but in the end, I'm not sure if string parsing a huge amount of non-paginated data is a good idea. Also, filtering that amount of data in-memory doesn't feel right.
Data needs to be encrypted in device storage. It gets synchronized every time user logs in. It need to be persisted during session. Records might get updated or even deleted during user session. All data gets wiped when user logs out. It does not need to be persisted between sessions or app installs.
What approach would be most efficient? Is using SQL-like engine is inevitable in this case?
I am new to React native Apps, And developed a basic news app which contains video posts, Everything was fine but videos are loading very slow.
Video will be uploaded from app to the backend server, and posts will be displayed in flat list and server is very fast but still having same low speed loading.
using Backend as Laravel, tried so many trick but still same issue,
How can I improve video loading speed? Any help will make save my time, Its is more than a month but still no solution,
Is these any better option to display video post in flat list?
How can I improve slow video loading?
Yeah, seriously problem is my shared server, my server is fast and data is loading very fast, but when it comes to videos and images,speed is bit slow... so I shifted my storage to AWS s3 and with AWS CLOUD FRONT And, that was the perfect solution for me.
I am developing an app, and I need a database that my app can get data from.
I know that there are a lot of solutions to this question, and I have already tried a few:
My online solution: Hosting the data in a SQL table on Azure DB (too expensive, ~$100/month)
My local solution: Including the data within the app itself using SQLite (data won't update automatically unless the app is updated)
The size of the data is around ~20MB. It is expected to grow at around 5MB every year.
I am building the front-end of my app on the UWP (Win10 native app) and ASP .NET (web app) platforms.
I do not know very much at all about the best ways to host data for an app, and when I researched the topic I was overwhelmed by the amount of options available to me.
Given my situation, would it be best to store this data locally? Or online? Maybe there is a way to host it on my own computer? What is the best strategy for this situation?
Edit:
The privacy/security of the app is not important, in fact I hope to make it as accessible as possible for others who wish to use this data.
In my asp.net core 2.0 application, upon user's request, I need to present the user a zip file of the photos currently stored in a sqlserver database. The photos are about 1M in size on an average.
I saw a few examples that use MemoryStream over ZipArchive to create a stream-based zip file. However, this requires that all the photos (1000+) be zipped first before getting transferred. I may not even have that much memory to hold the entire collection. I am wondering if there is a mechanism such that I can continue to fetch and archive photos while streaming is going on. Also, are there any sqlserver timeout or website timeout constraints I need to worry about? Regards.
I'm developing a app with a list of products. I wanna let the user have 1 picture for each products.
Now, the problem is what to do next. I think that the best way is that the photos get sync when the user connect to their computer & itunes, and acces them from the app (something like: /photos/catalog/ref1.jpg.
The other option is put them on my sqlite database, but I worry that that get bigger. I have data + picture, data change a lot but pictures are rarely modified (if much, I expect the user take 2-3 new pictures each time).
I would just use the network connection available on the device, and not bother with sync through iTunes.
When you download the images, write them to the apps Documents folder, then load them from there. Network usage vs. disk space will be concern. Keep in mind some carrier networks can be crazy expensive for data transfer.
If the images are named with a systematic format, then you can maintain them by comparing the image identifiers against your data, pruning out the older or irrelevant ones.
Do the math and ballpark just how much disk space you think it would take for a local copy of all the images.