I am building an app using worpress as the backend and ionic as the front end. I know there are a number of metods to store data offline, what is the most robust option? I will be deployning on ios and android and the data may contail larger files, i am leaning towards using the file api and saving .json files?
Did you look at the Storage guide in the Cordova docs? (http://cordova.apache.org/docs/en/4.0.0/cordova_storage_storage.md.html#Storage)
The "best" approach depends on what you are storing. If you are storing text based content, then WebSQL is probably best for you. If you are storing data that is more abstract (last article viewed, number of times something has been read, etc) then LocalStorage may be better.
Finally - I tend to only use the file system for binary data, like images, video, etc.
Related
I've been developing a NextJS project where I need to store image path of user profile pictures in the database.
Thus, my concern is can I store those images in /public/... and if I can, is it safe?
Also, if I store hundreds of images in /public/... will it affect the performance of my project in any way?
There is no problem with that, but Next JS is not created for this sake, and doesn't provide any static content related features like: optimization, caching, etc. In addition, it's not safe at all, and you need to implement authorization over the paths using custom server that decrease Next JS performance. My suggestion is using cloud storage.
I was thinking of making an app which plays a specific set of small audio files stored away in a firebase database, or any other database on the cloud.
The number of files may exceed hundreds, so wrapping all the files in the app might not be the best of ideas.
I'd really like to know how to go about this problem.
Downloading only the required file from firebase when it's clicked and playing as its being downloaded all the while caching it for future playback seems plausible, but I'm not quite sure how to implement it.
I'd appreciate a few pointers towards this, thanks
Yes. You are thinking in the right direction.
You might use these things.
App UI - Ionic2 will provide you a very nice and easy to implement platform to create a UI. Please refer this documentation for the basics and details about using Ionic2.
Local Storage - You can use this to store downloaded files. In any app where data is relatively large, using local storage is the smart choice. This helps you reducing the size of the initial app to be installed and download the content as and when needed.
A well defined database - Now, whether to use non-structured (No-SQL) or structured (SQL) is the first choice you have to make.
If it's just content - audio files download and play with no complex cross querying the database, then you can choose to use non-structured (No-SQL) database like Firebase database.
But, if you have good requirements for structuring data, query it with constraints like "Give me all the audio files list where a particular user has played it in last 10 days" or "Give me all the users who has played/downloaded a particular audio file more than 10 times" and so on, then you better use structured (SQL) database like PostgreSQL.
RxJS - Now, this might not be very important to do, but, if you use this from the start, it's a good choice. Advantages are, e.g. you might not have to wait for all the file to get downloaded before playing it. Use Observables and Promises for such a mechanism.
Could help with the specifics when needed. Hope this helps. :)
I'm beginner in eclipse and android apps. what can I do for security of database? prevent hack or steel my database of my app. And where is database of apps in mobiles with android OS?
You can't. It is pretty trivial to get it, no matter what you do. If you want to keep your data safer, you can drop the local database, and make a web service where you get your data from. Then you will have to make some restrictions, so people will not rip your data fast. This is known as anti-farming and you can see more at https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#Anti-farming
But this will only slow people down, and as the article says, large resource adversaries will still be able to get whatever they want.
What to do: don't focus on it, build a awesome app, so no other will reach your user level/profit.
Take a look at https://www.zetetic.net/sqlcipher/sqlcipher-for-android/. It is possible to create a encrypted database with that library. You should only think about where to place the key of it. One possible solution is that user has to enter the password via login dialog for example.
The database and app specific data is located at /android /data/package of your app folder.
I'm wanting to build up a pre-filled sqlite database using Django as a front-end data entry inputter; however I've read this site and on StackOverflow that isn't that easy to do; and one needs to use CSV files.
That's fine if your database is pretty small - but what if you're pre-filling it with data that has relationships (ie: Customers, Orders, Salespeople, etc); or if the database you're building requires a lot of data input (1,000+ records).
My app/database will be pretty big and have a lot of pre-filled data with multiple references/relationships -- I really don't want to re-enter all this stuff into CSV files or into the Simulator and I thought using Django would be a really quick and dirty way of getting vast amounts of related data into an iphone app.
This kinda raises the question of whether Core Data is really worth it, the learning curve is really high, the syntax can be cumbersome and I'm considering just using FMDatabase, except I can't get the LIMIT/OFFSET to display rows of data in batches correctly (any help or hints on tips how to do this would be great!).
Therefore, if you're wanting to pre-fill a database using Core Data and a large database what is the best route forward?
You might want to have a look at the Active Record port for cocoa/cocoa touch. I've done an app like this before, and what we (the client and i), choose to do was to import the data from an XML file on the first app launch. The idea being that as the parser was built into the app, we could do OVA updates if we choose to at a later date. The data did have fairly complex relationships, but i decided Core Data was still the way forward.
I've only used raw SQLite once, and that was before we had CoreData on the iPhone. Also you should consider what your solution is for doing schema migrations which are handled by CoreData.
A Hybrid solution is to load the data into Core Data in the simulator, and then ship that SQLite database with the app, and copy it into the app's document directory, on the initial load. Best of both worlds.
Good luck
I'm building an ASP .NET web solution that will include a lot of pictures and hopefully a fair amount of traffic. I do really want to achieve performance.
Should I save the pictures in the Database or on the File system? And regardless the answer I'm more interested in why choosing a specific way.
Store the pictures on the file system and picture locations in the database.
Why? Because...
You will be able to serve the pictures as static files.
No database access or application code will be required to fetch the pictures.
The images could be served from a different server to improve performance.
It will reduce database bottleneck.
The database ultimately stores its data on the file system.
Images can be easily cached when stored on the file system.
In my recently developed projects, I stored images (and all kinds of binary documents) as image columns in database tables.
The advantage of having files stored in the database is obviously that you do not end up with unreferenced files on the harddisk if a record is deleted, since synchronization between database (= meta data) and harddisk (= file storage) is not built-in and has to be programmed manually.
Using today's technology, I suggest you store images in SQL Server 2008 FILESTREAM columns (at least that's what I am going to do with my next project), since they combine the advantage of storing data in database AND having large binaries in separate files (at least according to advertising ;) )
The adage has always been "Files in the filesystem, file metadata in the database"
Better to store files as files. Different databses handle Blob data differently, so if you have to migrate your back end you might get into trouble.
When serving the impages an < img src= to a file that already exists on the server is likely to be quicker than making a temporary file from the database field and pointing the < img tag to that.
I found this answer from googling your question and reading the comments at http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html
i usually like to have binary files in the database because :
data integrity : no unreferenced file, no path in the db without any file associated
data consistency : take a database dump and that's all. no "O i forgot to targz this data directory."
Storing images in the database adds a DB overhead to serve single images and makes it hard to offload to alternate storage (S3, Akami) if you grow to that level. Storing them in the database makes it much easier to move your app to a different server since it's only the DB that needs to move now.
Storing images on the disk makes it easy to offload to alternate storage, makes images static elements so you don't have to mess about with HTTP headers in your web app to make the images cacheable. The downside is if you ever move your app to a different server you need to remember to move the images too; something that's easily forgotten.
For web based applications, you're going to get better performance out of using the file system for storing your images. Doing so will allow you to easily implement caching of the images at multiple levels within your application. There are some advantages to storing images in a database, but most of the time those advantages come with client based applications.
Just to add some more to the already good answers so far. You can still get the benefits of caching from both the web level maybe and the database level if you go the route keeping you images in the database.
I think for the database you can achieve this by how you store the images with relation to the textual data associated with them and if you can the access to the images into a particular query so that the database can cache the query (just theory though so feel free to nuke me on that part).
With the web side, I would guess since you're question is tagged up with asp.net that you would go the route of using a http handler to serve up the images. Then you have all the benefits of the framework at your disposal and you can keep you domain logic cleaner with only having to pass the key to your image to the http handler.
Here is a step-by-step example (general approach, Spring implementation, Eclipse) of storing images in file system and holding their metadata in DB --
http://www.devmanuals.com/tutorials/java/spring/spring3/mvc/Spring3MVCImageUpload.html
Here is an example too -- http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
Also you can investigate a codebase of this project -- https://github.com/jdmr/fileUpload . Pay attention to this controller.