So I am trying to use a OCR to translate text that I record with my phone's camera to a string, I am currently using Google vision OCR for android and have implemented the OCR correctly, the problem is that sometimes the result is not as good as expected thats why a solution I think might work is matching the result given by the OCR with my database. For example if my camera reads "How you?" then I would find in my database a entry that is similar "How are you?" and would display this instead. So the real problem is that the OCR is constantly reading from the camera, so that means that I would need to make an HTTP request to a server and query the database for a similar match every second or two and wait for the response, that could be very bad execution if there are many users overloading the server. One solution that I thought was downloading the list of all strings in the database and make the matching locally, but what if the data changes after that in the database? What would be a good approach to this?
I'm using this to read text from supermarket products such as name and description, so what I thought was match the products name and then query my database for all complementary information. Its important to note that this is going to be used by visually impaired people so reading bar codes is not a good choice right now.
Here is my 2 cents.
One solution that I thought was downloading the list of all strings in the database and make the matching locally, but what if the data changes after that in the database? What would be a good approach to this?
It depends how big is your database. If it is not too big then you can download it on user's device. If there is an update to the database, then you can implement a push mechanism using FCM, letting the app know that there is a new version of database to fetch. Then you can fetch it in the background and update your local database. Also I understand that since you are creating the app for visually impaired people, it might not work if you just ask your users to take a picture and perform OCR on it. This way it would have prevented the calls every second.
Related
I am currently learning android programming and creating an app that will store some integers representing user choices (values inserted several times a day, must be displayed in the results activity) and steps data collected Google Fit HISTORY Android APIs, also displayed in the results activity. I am looking for the most efficient way to store this data. I know that it might be possible to insert the custom data types in the GOOGLE fit database. However, I am not sure if it is a good idea if the app mostly works offline, and it needs to immediately represent only a small set of results, for example, the values inserted in the last 2 weeks, with step counts. On the other hand, I am not sure if it is ok to have two databases storing the data.
My apologies if the question sounds a bit too amateur, I am doing my best to find an optimal solution in terms of performance.
Thank you for your answers.
So, to give you my opinion and answer (mainly opinion)
Android has 3 ways (mainly) for storing data:
Files
Online database/API
Local database
for this specific scenario you have listed, wanting the data to be available offline, you should probably be looking at using Room: https://developer.android.com/training/data-storage/room, as it supports storing primitive types without having to write any type converters, you can store models and custom data as well, it uses very basic SQL (because it's a wrapper for the older Sqlite database methods) and is part of android (not an external 3rd party library). Room also requires most operations to be done off of threads, instead of main threads and this will improve your performance as well (also has support for livedata/rxjava to observe straight onto any changes as they happen)
However, as I told this user here:
Should i store one arrayList per file or should i store all my arrayList in the same file?
When starting out, don't worry about the best way for doing something, instead, try something out and learn from it, worrying about the best solution now is rather pointless, either way, happy learning and coding :P
The problem
I need to do a T9 contact search for an Android project I'm working on. Now, it would be simple if I just had to pull contacts from the native contacts storage and then do T9 on that, but the problem I have is that I have an additional local database where we store extra content for some contacts in the form of additional numbers that our application displays and handles. I need to do a search based on the contact’s name, number, and the extra numbers (if any) contained in the local database. The local database has IDs that match those of the contacts in the native Android database.
I have been looking for a solution to this problem, and I have gone through these ideas, but none of them seem to be the right solution.
Try #1
Write a ContentProvider for our local database, in order to be able to perform a simple join operation between the native Android contacts table and our table, however, it seems that joining tables via ContentProviders is only possible when you write your own ContentProvider, thus making this solution not viable for me, not to mention that Android documentation states that you should not write a ContentProvider if you don’t want to share your data with other applications, which we currently don’t.
Try #2
Copy all the needed data from Android’s contacts database into our database, and use ContentObservers to update it constantly. This solution had two major problems: 1) It seemed to have a big overhead, not just on the processor of the device, but also on the development, as we would have to introduce some really delicate update/read/write mechanisms and ensure that our data always stays relatively fresh, while also being performant; 2) A colleague has stated that during contact sync, the ContentObserver fires off events very often, thus making a need for special code to delay the updating, which he says has never really worked out great.
Try #3
Use a CursorJoiner to join the two cursors that I have received and then use a MatrixCursor to display all the data, but that solution is not viable since all the data would be kept in memory, and we are working with datasets that have more than 10k rows of data. Even if the memory could handle it, it would be slow to load, which for T9, isn’t really an option. This also pretty much excludes any solution that doesn't use a Cursor to look over data, which is why I am going in that direction.
Question
Am I missing something obvious? If I am, please point me in the right way. All of the things that I have tried don’t seem feasible to me, but I’m open to someone modifying them in order to make them worthwhile.
I need to sync my MySQL database to android phone. I am new to this. So I am referring this tutorial from Programmer Guru.
The Problem is in this tutorial they have used 3 classes, DBController, SampleBC.java, MyService.java. I have almost 10 tables to sync. So how can I change this to a better one?
Is there a way to sync the whole database?
I couldn't see correct tutorial for this.
This really depends on what your app does, and how it uses the remote data.
I have written apps which have an 'update' feature - which basically serialises the whole mysql database as json, and then decodes it in to the sqlite database on the device.
Other apps will just fetch a smaller amount of data as and when they need it.
There is no better way per se. Just different options for different situations. You need to look at how frequently your mysql data will change, and what will the experience be for your app users. Nobody likes slow apps which spend 50% of their time displaying a progress dialog while they download data.
I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.
I'm in the process of developing an Android application that will need to connect to a central database. Users should be able to access records and add records to the database through the application. The data itself will be fairly simple with each record being made up of a number of text fields.
The database will be developed specifically for the application and only needs to be accessed through the application. Initial reading seems to indicate that a web service should be written to parse data into xml format, for use by the app.
Seen as the database is being developed from scratch, specifically for this purpose, I would like to make sure I am heading in the right direction. I have very little experience with databases and would really just like a pointer on where to start reading. Any suggestions on the format the database should take would be greatly recieved too.
Thank you
You seem to have the idea down, if it were me, I would recomend using JSON instead of XML for the Webservice, they work in very similar ways, but JSON is a lot smaller and will make the application noticeably (as in it will make a diference for the user) faster. This is specially true if you are sending large amounts of data.
Take a look at this:
GSon
If your familiar with other aspects of Java, you could make the implementation entirely server side by means of JSPs. You could access the database via the phone's browser or any other browser. If you implemented a DAO factory on the server, this would enable you to switch databases from say Oracle, to MySQL etc by means of a properties file.