So we have built an app that is almost completely dynamic.
You build the content on a website and then the app pulls the content that the administrators created for the user using a REST api.
The content can be videos, images, rich text, or form controls. All of this is stored externally on our servers...not locally.
We have hundreds of pages (kinda like a choose your own adventure).
We cache some stuff...usually about 3 - 5 pages at a time, but we don't store any content locally...we save to our server only.
So we noticed something weird while testing...when we go to Settings/General/Usage/Manage Storage we noticed our app keeps getting bigger and bigger. If we drill down into the app we can see that the app itself is only 15 megs, but as you use the app it can grow to over 100 Megs.
When we close the app out completely it will shrink down by about 20%, but somehow the app is keeping stuff and I am not sure why.
Does iOS cache things on its own? Is there a way to clear that on exit?
Again, we are purposefully not saving anything...but something obviously is.
Any thoughts?
Update
So I was asked more about the tech...it is a PhoneGap app that uses JQuery ajax calls to hit a .Net Web API project.
I don't mind caching while the app is running, but when the app has been closed by the user...why is there data being stored?
Thanks,
David
Related
I have a set of iPads (3rd gen) running iOS 9.3.5. This is the highest they support. I am attempting to replace the functionality of a custom iOS app with an equivalent web application. The site is built in Angular 11, targeting es2015, and I've declared iOS > 9 in the browser support file. The majority of the site performs exactly as I would expect for such old devices. The linchpin of the whole thing is this third party form that needs to be filled out that is served up as an iframe, and it performs so, so horribly.
Here is the code of component HTML with the iframe (URL changed for privacy):
<div class="row header"><a class="restart" (click)='restart()'>Start Over</a><a routerLink='/welcome'><i class="fa fa-times close-x"></i></a></div>
<iframe src="https://notarealsite.com" (load)="waiverLoaded()"></iframe>
The waiverLoaded function is a simple boolean flip to detect the embedded page reloading upon completion so that I can route to a different component in my app. The performance is unchanged if the iframe is the only element on the page. Other pages that play nice when embedded do not suffer a performance drop like the waiver does, so I have to assume it's something in the code of the waiver page.
The original custom iOS app uses a webviewer to load the page, and it loads in 2 seconds or less. The same performance can be seen by visiting the page directly in Safari. In both instances the responsiveness of the dynamic form is reasonable given the age of the devices. When loading the page via an iframe the performance tanks. We're talking 30-45 seconds of loading, and sometimes up to a full second delay between tapping a button or field, and the form reacting.
I have attached the device to my computer and used the remote inspector in the MacOS Safari to view the timeline. The majority of the initial load time is the several 1-2 kb image files used by the form like the scroll bar and some icons. Usually one of these items ends up taking 20-25 seconds all for themselves. When interacting with the form there's an XML resource that appears in the timeline every field change or button press, and that is what takes around a second or two before the page is up to date again.
I'm not well versed in troubleshooting web application performance like this, and this is my first real Angular application that I've built, so I might be missing something painfully obvious. What can contribute to such a difference in performance between a page being visited directly, vs being placed in an iframe?
Some additional info:
The performance is the same between running locally via npm serve or built and deployed to my local server.
I have tried hosting it via HTTP and HTTPS in case it was some security hangup, as the form is only delivered via HTTPS. However I only have a self-signed cert at the moment.
I have seen no discernable difference in load times between the two methods on my other devices, including an iPad Air running iOS 12.5.2.
There is a warning in the console about jQuery support on iOS 9.3.5 being outdated, but it occurs in both scenarios.
Additional Troubleshooting
I've tried to look into some of the suggestions I've received. I've checked the timings and headers on the slow loading elements in Safari in the following configurations:
In the iframe on my app on the iPad.
Visited directly on the iPad.
In the iframe on my app on my MacBook Pro.
Visited directly on my MacBook Pro.
On my laptop the performance is nearly identical. Comparatively, on the iPad the actual load times of all the elements is within a millisecond or two of their times on my laptop. What ends up being notably different is the latency between request and response for the elements.
The latency when visiting directly is higher than on my laptop. When loading through the iframe all the timings increase fairly proportionally. A time of 750ms jumps to 4s. A time of 6s jumps to 30s.
Lastly, a real oddity to me, is the super high latency image for some reason results in a 302 to Cloudflare, but only on the iPad. It doesn't matter if it's through the iframe or direct. Both devices are using the same WiFi network. I can't think of a reason for the redirect to happen unless the destination site is handling the iPad differently somehow. Changing the UserAgent in Safari on my laptop to match the iPad doesn't result in the same redirect.
So I've confirmed that even outside of the iframe the site in question behaves differently on iOS 9.3.5 than on newer versions, and compared to my computers.
Please post your code for us to diagnose and help. In general there is more overhead for an IFrame my suspicion is the jQuery handler or cookie policy, to be sage I also listed other items to check.
It looks like you already checked the previous unsecured elements which was an issue. Both in the network graph and the calls, double check there are no dependencies or URL calls of the Iframe of unsecured elements then it wont display, it used make multiple round trips if Https had mixed content between secure and non-secure stuff, there's a ticket for A new TLS issue.
Once you fix that ensuring its hosted/called securely, clear the cache, cookies, data completely and reloading the page fixes the problem even on mobile browsers.
Redirects/Bouncing Your order of loading scripts/css, if there are dependent scripts and they are not cached it could be blocking, or if its redirecting back to HTTP this will also slow it down.
For IOS mobile apps only (doesn't apply here) - if you are using the 3rd gen, check the default for Cookie Security policy (HTTPCookieAcceptPolicy) for UIWebView has changed to NSHTTPCookieAcceptPolicyOnlyFromMainDocumentDomain
Animations Are slow in safari Iframes
You have the click event in your code, could be the issue
..."Turns out that any non-anchor element assigned a click handler in jQuery must either have an onClick attribute (can be empty like below):"...
Put the following element declaration cursor:pointer or tap event
here is a question from a total beginner in mobile app development :)
I am building a React Native application for iOS platform first. I am stuck with decision on how to deliver icons to the application. Imagine:
I have a reference data set with eg travelling options (bike, motorbike, etc).
The actual set is much bigger though - I am expecting rather 100-200 items with one icon each for the UI.
These should be cached in the application.
Most of them wont change, new ones might come to the set periodically, but not even every week.
Now to the options I was thinking of:
Deliver a sqlite database with images as BLOB and update the database when new icons arrive
Deliver a sqlite database with image URLs for S3 bucket items and update the database when new icons arrive
Deliver the app with initial sqlite bundled with BLOB or URLs(?) and update over the air when new icons arrive
Do not use sqlite database at all and deliver all with REST API call on startup with image URLs. Load images when needed and cache them. Update database with new icon URLs when new icons arrive.
I think I tend to be using Option 4 because it seems least heavy on the client - he can always download the icon whenever he needs one. But it also has a latency because of downloading the icon for the first time from private s3 bucket.
However I am missing real-world experience in mobile apps and probably missing important details. Hoping for some insight from experts. Thanks for any pro and con you can deliver on this options!
You are right, no database needed at all.
So basically you have to load those icons only once and cache them inside the app. You can you something like react-native-fast-image or do caching by yourself.
If URL of icon was changed - the new image will be cached.
So on real-world apps, you usually have the image placeholders (example below) or loaders (more rare).
If you have multiple types of vehicle, you can create multiple placeholders and show them unless the original image is loading/not available.
Using react native firebase storage and firestore is a good option. The images can be loaded remotely and the caching is done automatically
We're using Parse in our iOS app and we've discovered that our app is using an enormous amount of space -around 2.3GB in some devices- in storage. After downloading app data to my Mac, I've realized almost all of that data is the cached images in a folder called PFFileStaging, it contains highest resolution PNGs of all the PFFiles that the user has viewed in our app, ever. How can we disable this behavior, at least limit it? Is that the intended behavior? I heavily doubt using GBs of space is the intended behavior. Is this a bug?
Unfortunately this is not cache related (as per Parse's engineers: "this is used to ensure that no concurrent modification happens to the file after you request uploading").
They're planning to implement automatic trimming of PFFileStaging folder on every app start (as per road plan this should appear in next version 1.8.2).
See the the whole thread on GitHub.
I have an issue I'm hoping someone can help with. I have an application that, for all intents and purposes, is working great. It's basically a picture viewer type of application - for something very specific. What it is is about 500 pictures.
I have all pictures set as Content and I load/unload one at a time. For the 500 pictures, I have a class that is used as data about each picture. So things like "place taken" , "index", "short description", etc. I never need to insert or delete from this list, but I may need to make some changes to each individual one, like "user viewed this picture on..." (date) or "favorite = true" (boolean where user marks a picture as a favorite picture).
When I deploy the app, this "picture metadata" is in xml file. It is then deserialized and saved to IsoStorage upon first run. A copy of it is maintained in memory and that is what is used to run my whole app. I have 3 different pages that all use that data, which is set as a static property in app.xaml.cs. Upon Deactivate/Closing the data is serialized back to xml - upon relaunching it is deserialized. Everything works fine and fast - everywhere. Including tombstoning.
The problem is resuming from Deactivation where the app is not tombstoned. It can take up to 10-15 seconds and definitely is returning from e.IsApplicationInstancePreserved in Application_Activated (i.e. it's not tombstoned).
Activating from brand new it takes about 3-4 seconds for the app to start. Returning from tombstoning it also takes about 3 seconds.
What I'm not understanding is why returning from e.IsApplicationInstancePreserved = true; is taking so long (and it won't allow me to pass certification). I've tested and found that if it is about 10 items in the List its incredibly snappy for FAS. If there are about 50 items in the List then it's not immediate. If there are 100 items, it's the first time you can see "Resuming..." (yep, that word coming from FAS, not tombstone). Where I have it, at 500 in the List, it is painfully slow to watch FAS, which is SAS.
It's interesting that in the emulator, FAS works perfectly fine, even with 1000 objects in memory. It's on an actual device where it is incredibly slow (Samsung Focus) in both debug and release mode.
Now I know the easy answer may be something like "why maintain a class with a list of 500 objects all the time?", but my whole architecture and user experience is based on having data about the pictures available on all three pages all the time. Linq is heavily used to report data everywhere.
Any thoughts or guidance on this situation?
Great to hear you found the problem.
"sounds a serialization/deserialization issue to me. Are you storing the list in a State 'variable' ? were the framework will serialize when leaving the app and deserialize it when you return"
Remember, your PC + Emulator is MUCH faster and more powerful than your phone's 1GHz single core ARM processor with 500MB RAM!
When your app is activated with e.IsApplicationInstancePreserved == true, then you shouldn't need to restore any state and you should be able to pick up where the user left off.
If you're saying that when your list catalogs 500 items, the performance is horribly slow when resuming the app, I wonder whether you're also keeping the 500 images in memory and your phone is having to swap all that data into your app's memory space. This will be further compounded if your app has multiple pages each containing copies of your 500 images!
I strongly encourage you to profile your app to measure its memory footprint and to see where the big memory, storage, IO and perf issues are.
I'm having a problem with the app I'm building the RAM of the BB 9800 is too small.
I have a html5 application that I use in IOS and Blackberry.
I'm using phonegap plugin to pull data form server by using Sybase.
On IOS everything runs fine but on blackberry I frequently get a message "low on memory, please stop applications" and the only app running is mine. And usually this is followed by "app closing because its too big".
How can I either increase the memory available for my app (unlikely)
or decrease the amount my app is using (tips and guide lines)
I'm using:
Sencha Touch for our interface
Phonegap to access the native api
Sybase to do the sync between our local data and the server data
No toolkits - only one is sencha touch
everything is loaded at index.html - no ajax at all
index.html is a local file - no request loading
Sencha does the DOM stuff - not all screens in one main DOM - the screens are created on demand.
You mention you pull data from Sybase - is that when you get that memory error?
Unfortunately sencha/phonegap/sybase sync/your js will take memory (specially since it's all in one page), and those frameworks are big enough to cause troubles...
My suggestions:
if the error happens only when you load data, the question is how much data are you loading? maybe it's trying to download 1gb of data and trying to do that in memory? I would look into server-side paging to reduce your data-footprint
try to split into multiple .html pages each doing a subset of the work you are now doing in one big file...
Hope this helps