I am looking for offline database because the app needs to support read operations in the areas without internet. However, once the machine is brought into an area with the internet access, we should be able to connect to the internet and should be able see the updated data.
Use pouchdb. Couchdb and pouchdb is best pair for offline data sync.
Related
This article describes how a websocket server for a chat application can look. We are planning to implement something similar; when a message is sent to the server it is sent to the correct recipient based on an authentication token and the message gets saved in a mysql database.
We will eventually host the server on Google App Engine, and I suspect that that will cause some issues with the above described approach, since that depends on all clients being connected to the same server, and that probably won't be the case since multiple instances will be created as needed. Is there a way to connect all instances so that this won't be a problem (Pub/Sub maybe? (That will cause additional costs though)), or should we find a different solution?
One idea I had was to use mysql-events to monitor the binlog from the websocket server for the creation of new rows in the messages table, but I read somewhere that that wasn't recommend. But I can't find where I read that, and maybe that is the best solution.
Since you asked about other solutions, I would recommend looking at Firebase and specifically the Realtime Database. Out of the box it provides all of the functionality that you need for realtime communication between connected clients and Cloud Messaging for clients who aren't.
Here's a tutorial that uses Firestore to create a realtime chat web app, but it can all be applied to the Realtime Database with minor modification. I say that because Firestore has expensive writes, which in my opinion make it unsuitable for a chat backend.
What is the best strategy to synchronize the local database with the server one?
The idea is to use a 100% HTML5 application, so every morning, the server database will be duplicated to clients, so the clients will only work on IndexedDB, untill the end of the day, where the clients will send all the data to the server, and then the server will gather them and save them again, but as you can see, it is a lot of work, so is there a better way the IndexedDB or MongoDB offer to connect to each other?
If all your logics are in client, you don't need MongoDB. Just key-value store with REST API and collection query by last-modified is good enough.
I had a sample sync app with Google cloud storage.
I am currently looking into making a basic video game.
I have programming knowledge in Web technology, but not much in Android so I am most likely going to start by making a Web app on Android.
I haven't used Web storage much in the past, but I do know about local storage and indexed db, which could be considered as a way to store data, but this kind of data seems too easy to delete by mistake because people just generally wipe out Web data once in a while without filtering out important data.
What is the most appropriate way to store Web app game data?
The storage type relies on the characteristics of the data.
If you want to store small amount of data in key-value standards, you can use Key-Value Sets.
If you want to store structured data, you should consider to use a SQLite Database.
You can also use the Internal Storage to keep files.
Since you want an approach more user-proof, I prefer the SQLite approach. Be aware that no method is 100% guaranteed, since rooted phones can grant access to physical data. At least, consider to encrypt sensitive data before sending to the database.
You also have the option of hosting a web service that is consumed by the app to gather information. It can be a lot safer, it is easier to be accessed by all instances of the application, but introduces internet dependecy.
Hope it helps.
I have a broad question that I would like some advice on.
Currently, I have a number of databases in a shared location on our company's network. When at the office, these can be accessed quickly (but through VPN, it's slow).
We have multiple locations around the country and can access the drives of each location to pull up excel sheets, pdf's, etc. The problem is, Access applications are Extremely slow when accessing another location's shared drive.
Is there anything that can be done to increase performance other than migrating to SQL server and using a web-based app? Just looking for general advice here.
The reason why the VPN is slow is well because your VPN is likely 50 to 100 times slower than your LAN (local area network). In effect you asking the following question:
Why does it take longer to walk to the store then to drive to the store?
Answer:
because you going slower along the way (not really rocket science here).
A few solutions are:
Consider moving the back end data part to SQL server. So while ADP's are being depreciated, this in no way affects the great choice and suggestion to keep the Access application as a front end and move the tables (data) to SQL server.
If you only need a few forms, then Access 2010 (and 2013) does now support web publishing. Here is a video of an Access application of mine, and note how at half way point I switch to running the application in a standard browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
As noted, another great solution is to use some type of remote desktop solution. I explain why your connection is slow and give some suggestions for using Access on a WAN here:
http://www.kallal.ca//Wan/Wans.htm
So the basic issue here is your VPN is too slow and is far slower then your LAN.
You cannot increase performance over slow connections of an Access Database. There is no server serving records to the client, so Access has to download the whole dataset to do operations on it. You don't have to have a we-based app, though.
You can try to convert your .mdb to a .adp, or access data project. If successful, you will still use Access as the client, but all your data would be migrated to SQL Server. Queries on this data will be handled by the server, and you will see drastic performance improvements over slow connections.
I have a client that wants to use Filemaker for a few things in their office, and may have me building a web app.
The last time I used, or thought about, or even heard of, Filemaker was about 10 years ago, and I seem to remember that I don't want to use it as the back end of a sophisticated web app, so I am thinking to try to sell them on MySQL.
However, will their Filemaker database talk to MySQL? Any idea how best to talk them down from Filemaker?
You may have a hard time talking them out of FileMaker, because it was actually a pretty clever tool for making small, in-house database applications, and it had a very loyal user base. But you're right--it's not a good tool for making a web application.
I had a similar problem with a client who was still using a custom dBase IV application. Fortunately, Perl's CPAN archive has modules for talking to anything. So I wrote a script that exported the entire dBase IV database every night, and uploaded it into MySQL as a set of read-only tables.
Unfortunately, this required taking MySQL down for 30 minutes every night. (It was a big database, and we had to convert free-form text to HTML.) So we switched to PostgreSQL, and performed the entire database update as a single transaction.
But what if you need read-write access to the FileMaker database? In that case, you've got several choices, most of them bad:
Build a bi-directional synchronization tool.
Get rid of FileMaker entirely. If the client's FileMaker databases are trivial, this may be relatively easy. I'd begin by writing a quick-and-dirty clone of their most important databases and demoing it to them in a web browser.
The client may actually be best served by a FileMaker-based web application. If so, refer them to Google.
But how do you sell the client on a given choice? It's probably best to lay out the costs and benefits of each choice, and let the client decide which is best for their business. You might lose the job, but you'll maintain a reputation for honest advice, and you won't get involved in a project that's badly suited to your client.
We develop solutions with both FileMaker and PHP/MySQL. Our recommendation is to do the web app in a web app optimised technology like MySQL.
Having said that, FileMaker does have a solid PHP API so if the web app has relatively lightweight demands (e.g. in house use) then use that and save yourself the trouble of synchronisation.
FileMaker's ESS technology let's FileMaker use an SQL db as the backend data source, which gives you 2 options:
Use ESS as a nice tight way to synchronise right within FileMaker - that way you'd have a "native" data source to work with within the FileMaker solution per se.
Use ESS to allow FileMaker to be used as a reporting/data mining/casual query and edit tool directly on the MySQL tables - it works sweet.
We've found building a sophisticated application in FileMaker with ESS/MySQL backend to be very tricky, so whether you select 1 or 2 from above depends on how sophisticated and heavy duty that FileMaker usage is.
Otherwise, SyncDek has a good reputation as a third party solution for automating Synchronisation.
I've been tackling similar problems and found a couple of solutions that emk hasn't mentioned...
FileMaker can link to external SQL data sources (ESS) so you can use ODBC to connect to a MySQL (or other) database and share data. You can find more information here. we tried it and found it to be pretty slow to be honest
Syncdek is a product that claims to allow you to perform data replication and data transmission between Filemaker, MySQL and other structured sources.
It is possible to use Filemaker's Instant Web Publishing as a web service that your app can then push and pull data through. We found a couple of wrappers for this in python and php
you can put a trigger in the FileMaker database so that every time a record is changed (or part of a record you are interest in) you can call a web service that updates a MySQL or memcached version of that data that your website can access.
I found that people like FileMaker because it gives them a very visual interface onto their data - it's very easy to make quite large self-contained applications without too much development knowledge. But, when it comes to collaboration with many users or presenting this data in a format other than the FileMaker application we found performance a real problem.