Hi i'm trying to make my HTML webpage offline for android and IOS devices. My problem is that I need to store a lot of data. This data (css,js,images,html) needs to be persistent. (even after shutdown of the device)
USE: Someone types the URL and gets the whole page offline available.
What is the best way to persist your data? and is it possible without making a hybrid or native app, just with caching and maybe appcache/indexeddb.
EDIT: i have found that indexed db in combination with dexies my best guess is for a solution. are there any do's or don'ts, alternatives or tutorials you guys suggest ?
depending on the application personality I sometimes render the entire site/application in the service worker when the service worker is installed/activated.
I wrote about an example app I did last October for a conference, https://love2dev.com/pwa/pubcon/
As far as strategy, I vary things. For data (think JSON) I tend to cache in IndexedDB (I like localforage b/c it is simple).
For site assets (HTML, JS, CSS, Fonts and often media) I use service worker cache.
If a site is heavy on media, I persist images and video in IDB b/c iOS limits service worker cache to 50MB. 50MB should be more than enough for any web application core assets as they should really be measured in kb, not MB anyway.
iOS gives you several GB of IDB storage, depending on how much disk space is available on the device.
I have built multiple SAAS apps using this strategy and never hit data quotas. Of course lots of video or images will of course consume more space and you need to watch for quota exceeded errors.
Users will also be prompted to give permission for extended storage as well, so be aware of that barrier as you may need to educate the user about this.
Related
I am building an android app which requires to have >300 images and ca. 100 audio files for an apk size of around 50mb (after webp compression and proguard).
It is not huge and I could probably live with that. But since I am planning to add other features the size will get bigger and bigger.
I am still interested though, since I'm quite new to android development, if there is a better way to store all this files, perhaps remotely and access them when required.
When the app starts I would have to load all the images into a list and once an element of the list is tapped I would need to open a separate activity and load the sound. So there is no upload from the App, just a resource gathering.
I do not know if it is more efficient this way or to store all the files locally.
Either way I would like to know what my options are. what are the pros and cons of a server (and if it would be a viable solution for me at all) and what is the advantage of storing them locally instead.
Please keep in mind that I working by myself and haven't got money to invest on premium servers or stuff like that.
FILE STORAGE will be best for you. Performance depends on the type and amount of data you are using. You do not need too much of data manipulation so go for file storage if privacy is not your concern for the data as it will be available for all the applications.
Use SQLite Database if the files needs to be protected from other applications.
Use File Storage(internal/external memory) if other applications can also access your files.
Avoid Fetching data from server using JSON parsing/Http requests it will make your app rely on the internet all the time. Unless you are using it to update your database or file storage.
I'm in the process of developing an Android (just Android for now, maybe iOS later) app which relies heavily on taking pictures, storing those pictures on a server somewhere, and being able to retrieve any picture whenever a user needs it which will be very often.
The problem I'm fearing before even getting that far into the coding is how I'm going to cost-effectively store all of these pictures on a server. If the app were a success there could potentially be hundreds of gigabytes of images being stored and many users requesting 1 picture at a time each.
So I'm wondering what approach I should take. It seems to me my options are either use a web host or use some cloud computing/storage service. I think hosts might be out of the question because I don't think a host would support that amount of storage. That leaves me with cloud computing.
I've looked into GAE and AWS. AWS seems like the best approach because I could use S3 to store my images and then RDS to store information for each user in a relational database. I know next to nothing about server stuff, so I don't really know what all I should use in the AWS setup. I know I need S3 and I know I need a relational database, that's all. So what features exactly would I need?
Or does anyone know a better approach all together I should take?
Also, in Android is compressing images an option so they won't take up as much space on the server? Is the quality affected a lot?
I have used AWS for storing images uploaded from Android devices. What I did was to upload the images directly to s3 using AWS Android SDK and then keep records in database of the keys/paths where each user uploaded his images.
This approach has the advantage that you don't use your server (for example EC2) for the image uploading, leaving you server available for other tasks.
If you are going to use AWS I think you will need at least the following services:
S3: for storing the images.
EC2: For deploying your server code.
RDS: For your database (assuming you are using a relational database)
There are a lot of tutorials out there about uploading files to s3.
http://aws.amazon.com/articles/3002109349624271
You can estimate costs using Amazon's calculator
I am rendering a webview on button click and am using the shouldInterceptRequest to intercept requests to resources like images, css and js files and serving them locally instead of over the network. I expected to see a considerable amount of difference in the load time but it reduced only by a small fraction. Is it possible to parallelize the shouldInterceptRequest ?Are there any other suggestions.
Thanks in advance
The new Chromium WebView present in KitKat will read multiple InputStreams returned from shouldInterceptRequest in parallel. The Classic WebView implementation present in previous versions of Android would perform the reads serially and there is no way around that.
Without knowing the details of the content you're trying to serve it's hard to offer specific suggestions. How are you measuring this? Maybe the total time to display went down, but you perceive the load as being slower because only one thing is loading at a time? You should also try experimenting with what to cache locally - maybe the biggest gain is from only having the biggest file be served via shouldInterceptRequest?
If you can afford the extra memory usage you could store your resources in memory (by reading them into a string, for example) and serve them to the WebView using a ByteArrayInputStream. It would be ideal if you could predict what the next required resource would be (that way you'd need less memory).
Note: the Classic WebView would use shouldInterceptRequest "under the hood" for reading file:///android_asset and content: scheme resources, so there is no benefit in transferring between any of those, however doing so (specifically using the file:///android_asset/) might simplify your code.
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 have to distribute large content to be consumed by my application. The data size can be upto a few gbs. What is the best way the data can be sent out?. The solution has to be efficient and cost effective. I ve thought about giving out sd cards (bad solution, since most devices have just one slot and nobody will use it solely for the apps purpose), downloadable from the internet (nobody will download gb's worth data from the internet),package it with the app(Not possible to upload the app to the market)
Is all of the information needed from the very beginning of the app? Maybe you can incrementally download it in the background and prioritize the data. You can set it so that it only downloads on wifi as well of give an option for it.
Android market has now extended the maximum APK file size to 4GB.
I would suggest that in the use case of downloading from the internet (i.e on the phone) then you restrict it to wifi only. THere are plenty examples of this out there using connectionmanager detection.