How can I store more that 5MB in HTML 5 local storage - iphone

I need to write an app to run on iPhone, iPad, Android phones & tablets. WinPhone 7 and desktop browsers would also be nice, but not necessary. I'm a desktop/Silverlight developer, but it seems this is a job for HTML 5 & javascript. Right?
I'm looking at Sencha touch, jquery, and amplify.js to simplify my life. My app has to be available in app stores, so I'm looking at PhoneGap to help with that.
The app needs to work offline which means I have need for local storage of about 10 megs. I don't know how to deal with this requirement because all the local storage options seem to top off at 5 megs.
Any ideas about how to deal with this? (Or any suggestions as to a better approach or libraries?)

I would try your best to get your app down to less than 5 Mb. This means perhaps compression of some sort before locally storing, perhaps only having the essential features available offline, and optimizing your data such that you can reduce any redundancy. Even after all of this, you are still dependent on whether or not the user's browser allows local storage, and whether it allows 5 Mb of it.

As per an answer on a question earlier today, the Web SQL Database spec is your friend here, at least on iOS 4.3

Related

Best way to store large data clientside in an gwt offline application?

We have written an Vaadin7/GWT application where the user can select multiple images and upload them. The application works offline, so we want to store the images clientside and only upload them when the user is pressing the sync button. The clue is that we want to keep the selected images, even when the user is closing the Tab/Browser. The clientside storage should also work with mobile browsers (Android and iOS)
We have found the following possibilities to store data on the client
Session Storage is killed when the tab/browser is closed. Not suited for our case.
Local Storage is limited to 5MB which is not enough. Is there a way to extend that limit?
IndexedDB does not work on IOS devices (http://caniuse.com/indexeddb)
WebSQL does work on IOS and Android devices (http://caniuse.com/sql-storage) but is deprecated
So the question are. Does anyone know a good Frameworks in conjunction with gwt? Which storage type/DB would you prefer and why? Or even more general, how would you solve the Problem?
Thanks for any advice, suggestion or experiences you had.
Unfortunately, there is no magic solution for all operating systems/browsers. I believe that you your only option for large objects is to build native apps for each platform that use a web browser for their client.

iOS: Application in production. Which Size?

I am developping my first application on iOS. I am on this language since few days and I am going to share this application in Apple Store ASAP. But I have a big question around architecture.
Currently, I have with about 40 different type of Views, others components and a lot of PNG (30x30). I know that I can reduce considerably the number of Views through the development of a small framework but as it's my first learning-by-practice application, I wanted to move on quickly about all standards components and to start this development without architecture, reusables class or design pattern ... without think too hard.
To be short, I am wondering about the real size of applications in production and the performances. Have we got some constraints with:
Apple Store (upload apps)
Ram Capacity of iPhone during using
Download application from apple store for the user
etc...
Basicly, is it acceptable to have with about 40 screens for an iPhone Application?
Best regards.
There is a limit of 50 MB for over-the-air downloads.
Number of screens is probably not going to be a problem. The amount of executable code associated with each screen is probably not going to be significant. The bigger issue is how much PNG data you are going to have embedded in the app. A single 30x30 PNG isn't very big. 40 of them probably won't very big (depending on how well they compress). But if you have dozens of them per screen, or if you have a big hi-res background image for each screen, then the total amount of data could get big.
My advice would be to just start developing everything in the most straightforward way you can. Don't worry about sizes until you have some evidence that it may be a problem. And do a lot of testing on an actual device (don't rely on the Simulator) running whatever the oldest OS version is that you are willing to support.

manifest file download size limit

I am learning to use Manifest files and had this question. What if some website created a manifest file that will make me cache files for, say, 3MB. 3MB is a lot for my IPhone when I run on 3G. So some vicious website can create such manifest file and make me use up all my data allowance?
Another question is that, as a responsible developer, is there anyway to detect if a user is using 3G or not so I can serve a smaller manifest file in the former case?
Thank you
Your question is tagged 'iPhone' so I am going to give an iOS-specific answer.
The offline storage, which holds the files linked to in your manifest, seems to be limited to 5MB. Evidence for this is all circumstantial, as the limit is not mentioned in Apple docs. However, some Apple engineers have conceded that there is a limit. The newest versions of Mobile Safari, in some circumstances, offer to allow the user to expand the storage, but you, as a developer, cannot force them to do so.
5MB is not really that much, and many users will certainly notice that something is going on, and if they don't want it to happen, simply close the tab. I understand that not every country has the same limits, but most users in the US are limited to 2GB/month. At this rate, an unsuspecting user would have to accidentally re-download your manifest, and the files it lists 100 times to use up just 25% of their bandwidth allotment. It's a fairly low limit, and the possibility of maliciously using up someone's data allotment is fairly remote.
As far as how to tell if a user is on 3G or WiFi, check out the Reachability example in the Apple Developer Center. It does exactly that. There is no way to do it in a web app (as opposed to a native app) that I am aware of.
Is there a size limit for HTML5 Manifest? No.
No, iOS does not implement W3C network information API as oppose to Andorid Webkit.
I'm not sure how you're getting this manifest file, but if you're using NSURLConnection, it's simply a matter of keeping a running total of how much data you've downloaded (best place would be connection:didReceiveData:) and cancelling the connection if it gets above 3MB. Remember to zero that number each connection though.
As for finding the device, the specifics seem trickier than they should be, but I've found a pretty simple example of how to do it (source code n' all): Determine If iPod is First or Second Generation

General questions regarding mobile development

I am working on iPhone app development currently (primarily native app using Obj-C and some web app using jQTouch). My question is regarding the future of this space;
In say 3 years time, what do you think would be preferred (native or web app) ?
What are the strengths going to be for native app (I know for certain types like Games, people prefer native than browser-based, but will that remain that way forever)
Some people say HTML5 will replace native app development, as it will be "code once, run anywhere" kind of thing (like common for iPhone, Android, BB phones). So do you think HTML5 can completely eliminate native app development.
I know the mobile space is constantly changing with new technologies coming up regularly and hence one cannot say with certainty what the situation will be 3 years forward. But I think there are projections being made by many agencies. So are there any reputed ones which can give a general idea or some sense of what might happen in future.
My main aim is what exactly should be my focus (like what technology/platform/native-web apps), if I want to look at the mobile space for the next 5-10 years.
Please provide as many responses as possible.
My 2c.
The popularity of web based apps will continue to grow. Whether it will pass native apps I don't know. For them to be on par in terms of numbers in 3 years doesn't seem unrealistic.
Native apps have the following benefits:
Better performance (potentially)
Fewer restrictions on accessing device resources
Greater control of execution of application
HTML5 won't completely eliminate the need for native apps (see point 2 above). Even Google who are creating an entirely web based OS (ChromeOS) don't seem to be looking to get rid of Java/Dalvik for Android based dev.
"code once, run anywhere" is very unlikley for anything but the simplest of apps/functionality.
"Code once, compile for each supported platform then test everywhere" is much more realistic.
I'd recommend focusing your education on what makes a great mobile regardless of platform and looking at web based development.
1: Native. It will always be preferred, as it is the most convenient type of app. Personally, I only have one web-app on my phone.
2: The iOS-framework. It is really the largest upside of the native apps. And the fact that they are easily downloadable through the App Store.

Comparison mobile devices as dev. platforms iPhone, Blackberry Windows Mobile

I was trying to compare the three above mentioned platforms and what considerations one needs to think about when programming in order to create some kind of code base that could run on all three.
This is what I have collected for the iPhone - it would be great if somebody else could write something similar for the other two.
Only one application can run at any
given time. i.e. that is why the
SQLLite database is loaded as a file
into the app instead of as
traditionally having some kind of
server to connect to.
Only one fixed size window 480x320
pixels
Runs in a sandbox, when the app is
deployed a sandbox is created
"around" the app, the app can only
read/write files from within that
area. Also low-level access to the
phone is restricted.
Since a program can be stopped at
any time (see point 1) this needs to
be considered when designing the
app, at any time must the app be
able to write its current state to
disk so that it can resume later. If
this takes longer than five seconds
the app will be aborted.
128MB RAM, about half of that 64MB
is available to the app. There is
typicall 4GB storage (depends on
model), no virtual memory, if memory
is running out the app may be
aborted.
Edit: just to be clear, I am not after which platform/os is best for the developer, I am just interested in spec. comparison to know what can be expected if one has three target platforms and using native language for each (not web apps), what the memory and other considerations are.
Edit: removed language as its assumed that native language for the platform will be used.
There is an excellent article on Codeproject which would be of benefit to your question. Head on over here to read it.
Hope this helps,
Best regards,
Tom.
For Windows Mobile I want to add:
Windows Mobile in comparison to iPhone allows multiple applications to run at same time.
It comes with variable screen sizes and has different sdks (
Windows Mobile Professional for 'Windows Phones' (smartphones) with touchscreens and
Windows Mobile Standard for 'Windows Phones' with regular screens)
The framework which is generally used is .Net Compact Framework besides some people also prefer open-net which is a open source framework.
Unlike in iPhone, Windows Mobile has no private api's which means it gives more power to developers.
The memory size allowed for a program is 32 mb
You do not need a developer license for developing and shipping applications on windows mobile although windows mobile itself prompts you to avoid installing apllications which are from unknown publishers.( which is more interesting unlike in iPhone you need to have a license while you only want to debug your applcation on your device(not for the jailbroken devices.))
And for some bad things about windows mobile, see this link.
Thanks,
Madhup
I feel like the final list will be of little use, as all data points collected will differ substantially in content apart from your last one. Some corrections to your iPhone list:
1) Local databases such as SQLLite are"not traditionally" implemented as a server on other mobile platforms either (they also use various file-oriented DB's).
2) Very soon that single fixed size assumption may well be inaccurate.
3) The App is in a sandbox but can write to some areas outside of the sandbox via API calls (for instance, photo library or address book).
5) That number varies between 3Gs and 3G/2G/Touch (the older models have half the memory)
6) Monotouch is available, but I'm not sure there's anything that far along for Java based iPhone development. There's also a Flash compiler from Adobe.
Basically if you are thinking cross platform, memory/screen size/system access/common databases will all differ - so the whole thing boils down to language AND LIBRARIES. And that is where you really have an issue with a cross-platform approach, because the libraries are very different per system... in the end you MIGHT be able to share data structures and some pure data processing code across the platform binaries, with very different GUI code for each system. But is it really worth it to constrain the development of each client?
On a side-note Blackberry is Java-based, so it presents yet another hurdle for such an attempt.
If you really want to see what cross platform ends up looking like, take a look at the codebase for Waze - a cross-platform open source navigation app:
http://www.waze.com/wiki/index.php/Source_code
Client source for iPhone and Windows Mobile lives there.