i am building a application for a takeaway resturant using SOAP as a webservice.
Problem:
When i try to open the application it loads every time. and if i have slow internet it will take some time which is not good for a professional application.
How can i cache the images in my mobile so it loads automatically
Possible Solution in my mind:
i think i should use the local database and sink it with internet
Use local cache system (but what if the application close).
Use arraylist to store information.
Can you guide me in that as i am stuck i do some reading but i don't feel any reliable solution on it.
You can use some libs but you can lose images if the app is closed.
Actually you can cache images with libs and save them to sdcard at the same time. You need to save Their id in database. Then take data from sdcard by id from database in case you haven't internet.
Related
I am currently developing a web application for a local company using Java, Spring Framework and MySQL no ORM. This is the first time I have dealt with uploading files.
My situation is that part of the system allows an admin user to upload images for store items.
currently all my resources such as images are organised and located like such: (located in the unpacked .war at the ROOT of my tomcat server)
/resources/img/items/
/resources/img/items/thumbnails
However I have come to the realisation that when the web app is deployed and a user uploads an image, it will be stored in the above locations. Therefore when I redeploy, the uploaded images will not be present.
My question, is there a better location to store these images? Or am I missing something. I have been researching for the past couple of hours and seem to have not gotten far. I'd be very thankful to anyone who could offer some knowledge. Thanks in advance.
There are many options where to store files.
MySQL: Store them in your MySQL database using the BLOB datatype. The advantage is that you have all your persistent data in a single location which is handy when doing backups. On the other hand, image data may bloat your database quickly.
In the file system: Store them in the file system, e.g. in /var/yourapp/uploaded-images. You need to tell your application about where to find that directory. There are many ways to do this:
create a configuration table in your MYSQL and put the folder there
let your web container/server provide that variable
via JNDI service
...
Make sure you have a rescue plan when that disk crashes with tons of data ^^
Separate Database
Since image data may bloat your database quickly, you may want to use another database for your images. In many architectures binary data are separated from the "real" business data.
I guess these are the typical solutions to your problem. However, there is no standard recommendation what to choose for it depends on facts you didn't provide, or cannot provide at the moment:
Are the images business-critical (technical drawings)
Size of the images (8kB JPEG vs. 200 MB raw image)
What are the demands of your users and who are they (SaaS vs small intranet application)
... many more ;)
Whatever you choose, it is better than storing files in the exploded war :)
For my current project, I would like to allow a user to create a sqlite database file and have them enter some content. Then the user has the option to sign into their google drive account and upload this file. Afterwards, after the user makes further edits, the new database file is uploaded to replace the old file. Finally, if the user has multiple devices, the database should be downloaded from the google drive and replace the existing file stored on the device.
Currently, I have successfully setup Google Drive SDK authentication and I can sign in to the app with my account.
My main question is, how do I upload a sqlite database file to the APP FOLDER when I choose to press a sync button? (This method should be called when the user needs to sync)
Additionally, how do I upload a sqlite database file to the APP FOLDER?
Your question is a bit broad, but I'll try to send you in the right direction.
First you have to decide if to use the REST Api or GDAA. Both will accomplish the same (actually the GDAA's functionality is a bit narrower now, but for your situation will do).
The big difference is that GDAA will handle on-line / off-line states for you, where with the REST Api, you have to implement some kind of non-UI thread (sync service) synchronization. Also, there are latency issues you must be aware when using GDAA.
Next, the process of uploading SQLite database is the same as any other binary data stream.
Grab the 'xxx.db' file, make output stream (or byte[] buffer) and create a GooDrive file with title + mimetype metadata, push the stream into it's content and send it on it's merry way. The only difference between a standard folder and an app folder is the parent of the file.
You get an ID you can subsequently use to download the file to the device. Or you can use search by metadata (title in your case) to get this ID. Again it comes as input stream and you dump it to an 'xxx.db' file on your device.
The second portion of your question deals with multiple devices. None of the apis will notify you about a change in GooDrive, so you must implement one of the 2 strategies:
1/ Polling (ouch), preferably in sync service with sync intervals the system gives you.
2/ GCM message broadcasted to the devices / users who are interested (not trivial, but efficient ... and sexy).
Another pitfall you must be aware when using multiple devices with GDAA is described in SO 29030110 and SO 22874657.
In case you decide to play with the 2 apis, I maintain basic CRUD implementation demos for both the REST and GDAA. The GDAADemo has also an option to work with the app folder.
Good Luck
I want to build an offline browser-based app using HTML and javascript to collect survey data on Android tablets. The app would consist of some static pages with forms for users to enter data, which would then be stored locally using Web Storage or IndexedDB. However, I also want to build a small native Android app which would grab this data and transfer it to other devices. Is this possible, and if so how would I go about it?
Specifically, I want to understand if and how the native app would access the browser's data store (I can manage the rest). I would prefer to use the Android browser but can use any other if that makes it easier. I have found this blog post which suggests that it might be possible but I would appreciate some pointers as to where the data is stored by the Android browser and how easily it can be accessed by another app.
Unfortunately I don't think the data flow can work the way you want it. In the Chromium WebKit implementation, IDB stores data in levelDB files that you should not be able to access (by design).
So how do we get Java and JavaScript to play nice together? That's a great question! As I see it, the only good way to transform Java data into IDB data is via the client-side.
I've got good IDB chops but my Android experience is non-production. From what I understand of it, here's a proposed solution:
collect data via native application views
write a string to a file in your sandbox with the data stored as a JSON blob or in an .html <script> attached to a JavaScript global
load a webview that can access a local URI like file://android_asset/blah.json and then run some IDB code to bulk insert it into IDB
use your IDB store to drive your web-based views
So the answer to "if and how the native app would access the browser's data store" would be: try the opposite. Architect it to let your browser access your native app data store.
Easiest and most robust way to serialise all your records and load into your app when it first run.
It's possible if you're willing to try a slightly different approach:
Pulling data from an HTML5 app is tricky but pushing data to a native app is easier. Your HTML5 app must have a native container. Does the container API include a way to access native ContentProviders? If not, can you add your own native code to the container to do that? Basically, if you can access ContentProviders then your native app need only implement a ContentProvider with insert privileges (which can be restricted to only your HTML5 app). After an insert, the native app can do whatever it wishes with the data, including broadcasting it to to other devices.
If you insist on pulling data from the HTML5 app, this may only be possible if the native and HTML5 app are actually the same app, and that is only possible if your container allows you to add your own native code. Then you will have direct access to the WebView's storage via the WebStorage class.
Ive been reading up on where to store my files, and I am still not sure what route I should take. I am writing an application that will store images and pdf's (totaling 300MB or so). I would like the app installed on the internal storage, and then allow the user to store the pdfs and some images on there choice of storage. Is it possible to allow the user to choose which storage they use for those files only even I have this in my manifest:
android:installLocation="internalOnly"
Essentially I would like to have the user choose this when the applications start.
If it is, would I just need to have a flag in application that if the user chose external and if the external storage was available, had enough space, then save files to it. Every time the user opened the app I would check to make sure the files are available. If the users chose internal it would use openFileOutput. Does this all seem right, is this possible?
Or should I just consider making it completely internal only, because without these PDF's and images the app is not usable.
It sounds like you can set the installLocation as following to accomplish exactly what you want:
android:installLocation="preferExternal"
From the documentation:
If you declare "preferExternal", you request that your application be
installed on the external storage, but the system does not guarantee
that your application will be installed on the external storage. If
the external storage is full, the system will install it on the
internal storage. The user can also move your application between the
two locations.
If you set it to internalOnly, the user cannot move the application from internal storage to external storage, so above solution is probably your best option.
Is it possible to use SQLite as a relational database from Google App Engine? (Java) I need read/write access to it from the app itself.
Also, I am using Quercus for PHP, and if what I am asking for is possible, I can handle storing the database myself.
No, it is not possible. This would require write access to the filesystem, which App Engine does not allow.
SQL database support (MySQL like) is planned, but no release data has been given. For now, use the datastore.
I know it's a super old question and nothing concerning read-only properties of App Engine has changed since then... But actually you can use sqlite on Google App Engine. There is a writable /tmp directory (https://cloud.google.com/appengine/docs/standard/java-gen2/using-temp-files). If your app on startup first copies the db.sqlite3 file to /tmp/db.sqlite3 and references this path as database path, it will work.
The following problems are connected with this approach:
This directory is "in-memory". So if you want to use really large sqlite file, you may face problems with RAM.
Each node of the app gets its own copy of the database. If you save something on one node, these changes will not be seen by other nodes. And the new data will be lost if the app scales to 0.