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. :)
Related
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 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.
This question is about using Dropbox to sync an sqlite Core Data store between multiple iOS devices. Consider this arrangement:
An app utilizes a Core Data store, call it local.sql, saved in the app's own NSDocumentDirectory
The app uses the Dropbox Sync API to observe a certain file in the user's Dropbox, say, user/myapp/synced.sql
The app observes NSManagedObjectContextDidSaveNotification, and on every save it copies local.sql to user/myapp/synced.sql, thereby replacing the latter.
When the Dropbox API notifies us that synced.sql changed, we do the opposite of part 3 more or less: tear down the Core Data stack, replace local.sql with synced.sql, and recreate the Core Data stack. The user sees "Syncing" or "Loading" in the UI in the meantime.
Questions:
A. Is this arrangement hugely inefficient, to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?
B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so, will you please explain in detail why?
A. Is this arrangement hugely inefficient, to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?
Irrelevant, because:
B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so, will you please explain in detail why?
Yes, very much so. Virtually guaranteed. I suggest reviewing How to Corrupt An SQLite Database File. Offhand you're likely to commit at least two of the problems described in section 1, including copying the file while a transaction is active and deleting (or failing to copy, or making a useless copy of) the journal file(s). In any serious testing, your scheme is likely to fall apart almost immediately.
If that's not bad enough, consider the scenario where two devices save changes simultaneously. What then? If you're lucky you'll just get one of Dropbox's notorious "conflicted copy" duplicates of the file, which "only" means losing some data. If not, you're into full database corruption again.
And of course, tearing down the Core Data stack to sync is an enormous inconvenience to the user.
If you'd like to consider syncing Core Data via Dropbox I suggest one of the following:
Ensembles, which can sync over Dropbox (while avoiding the problems described above) or iCloud (while avoiding the problems of iOS's built-in Core Data/iCloud sync).
TICoreDataSync, which uses Dropbox file sync but which avoids putting a SQLite file in the file store.
ParcelKit, which uses Dropbox's new data store API. (Note that this is quite new and that the data store API itself is still beta).
currently I am writing a Windows 8 App with Sqlite as a database. I want to give the user the ability to view his data in every instance of the app on any device. Usually this problem could be easily solved by using a online database like Windows Azure. But this is not an option in my case.
Is it a good idea to use Microsoft's free service "Skydrive" as a platform to synchronize database files among several devices? Does somebody know any open source projects or blogs that are dealing with this problem that could save me some time for writing the necessary code?
If it's a bad idea, which other options are there that I could use. I want to keep Sqlite as the database for my App.
I am glad to get any kind of feedback or links to resources that might help me.
Best regards
Philipp
imo it isn't a good idea cause the access to db files is to easy. Ofc you can say that access to database files is easy cause you need to just know the app data path to package of your app but still it`s much more difficult than just opening skydrive. And think what would happen if someone would make this directory on skydrive as public.
I would combine local db and online db. Online db as a service for synchronizing data and local db for normal work.
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