For some reason, an application we're working on at dynalog-qa.catalogs.com seems to consistently crash as soon as the zoom level is above 1.3. This only happens on iOS and isn't occuring on my iOS simulator. It's extremely hard to debug, of course, because the logs provide mostly machine code and a bunch of stuff that I'm unable to understand.
So far, we've tried quite a few things:
Removing any calls to webkit animations / transitions
Removing a large (and often troublesome and buggy) JS plugin turn.js from the repository
Changing the meta viewport user-scalable setting (we tried various increments and found that at 1.3, the crashing stopped)
Unfortunately, this entire site is a Backbone application, so many articles suggestion to remove Javascript won't help much (because we can't really test without Javascript).
I know this is an insanely hard issue to debug and test, much less explain––but that being said, anyone's help or advice would be as always greatly appreciated.
Related
I have an iOS app and i'm trying to run automated tests on it using Appium.
Some of my tests are failing because some objects are missing from the DOM tree. But when I look at the simulator screen, I see that those objects are there.
What can possibly create those differences? I'm not even sure who's fault is this -
Is it bad iOS code in it? Is it Apple's fault? Or is it Appium's fault?
Help would be much appreciated
Taking your feedback into account, there could be several reasons why a element does not show up in Appium but clearly visible on the screen of the device/emulator you use. The ones I know off or read about:
It's a OS problem. Appium depends on the accessibility layer from the OS. Updating or downgrading your OS could solve this problem, but no warranty here.
The app is using custom controls. A custom control will only be accessible if the devs that made the controls implemented accessibility for it.
There is also the possibility that you encountered a bug, known or unknown. Be sure to check the Appium github issues for known bugs, or to get help from the devs tackling a new one.
If trying another version of the OS or implementing accessibility does not solve the problem or is not possible, you will need to tap your element using coordinates. This is a last resort solution if everything else fails.
A very useful article on the problems mentioned above can be found here. It also contains all the resources to address these specific problems, like how to tap by coordinates the right way.
I am trying to wrap my website into an app that I made with AngularJS.
I got a website with lots of "cards" divs, and each of them hv an image on them.
you can find the link here: cow.aforadrian.com
screenshot of what i did in the web version
each page will hv about 100 "cards" with each unique image, loading from local JSON file. It went well in the browser
I package all the images locally into an app.
It worked all good on iOS simulator and even on my new iPad Air.
But then I realise it wont work in other devices with lesser memories.
It averagely took up to 260MB ram... and sometimes go way up to 500MB...
I tried to disable all css visual or transformation effects but it didnt help much.
At first I thought it was the size of the images, but I hv checked and try using small thumbnail to test, the memory issue still persists.
so I guess it had to do with how the screen handles the rendering of this amount of images.
I m not very good with angularjs and barely get this site up and running. it got me scratching my head on how to fix this. I never worked with an app before so the memory issue really didnt occur to me and i dun hv a concept of how to deal with this.
Other threads hv talked about similar issues on creating image carousel, that one should lazyload the image before and destroy the image after. Yet I am not sure if this is the right approach for me, and I am not sure how to achieve this.
UPDATE:
I am using ng-repeat to load image links pointing to a local image folder.
Is this the reason why it is using up a lot of RAM/Memory? are there better way to achieve this? will it help if i revamp the website in ionic framework instead of pure Angularjs + Cordova?
I programmed with DirectX 9 / OpenGL and C++ some years ago and I wanted to start a new hobby project with SharpDX and DirectX 11. I made the first basic steps and everything looks nice, but I only the opened my application and saw, that everything's as expected and closed them afterwards.
Today, my application was opened for about 20 seconds and suddenly my whole window content disappeared. I checked the official SharpDX samples and I had the same problem with the official MiniTri sample from SharpDX. Finally, I tested the offical samples from Microsoft in Microsoft DirectX SDK (June 2010)'s Direct3D11 Tutorial 02, which does nothing more than showing a colored triangle. Even the official sample from Microsoft (which does neither use SharpDX nor C#) has the same issue on my computer. Of course, I used my favored search engine for quite some time, but I was not able to find anyone with the same issue. Maybe I searched for the wrong keywords.
After around 14-20 seconds, the content (i.e. vertices) of the window disappear. I have no rotation, animation, movement or anything, just simple triangles with a simple color.
I'd be very happy, if you can help me!
I spent several hours to figure out, why some simple official SharpDX and DirectX tutorials do not work correctly on my machine. Finally, I decided to ignore that issue and contine with the development of my game. It was a great decision since it turned out, that I don't have any issue with the advanced tutorials! The MultiCube sample from SharpDX worked very well and its content did not disappear. So, I figured out that my problem does not occur, if my graphics card is kept busy. I continued my development while running Fallout 4 minimized in the background. Developing this way, my content did not disappear.
I started to implement a user interface for my game using Direct2D1 (with SharpDX). It turned out that using Direct2D1 solves my issue and the content stopped to disappear.
I am not absolutely sure what caused my issue, but apparently my GPU got bored and stopped rendering my simple primitives. :-D Using Direct2D1 for UI solves this problem anyhow.
Having decided to go with D3.js and SVG for visualizations it now looks like SVG will work fine in a desktop browser or native shell but I'm really perplexed by the drop in performance speed on the iOS mobile platform.
According to the following tests it now looks like SVG performance is getting better and not that far behind Canvas speeds, this is the good news:
http://bl.ocks.org/2647924
http://bl.ocks.org/2647922
The bad news is that if you run these tests in the Safari browser on the new iPad the speeds drop a lot for both SVG and Canvas. The terrible news is that if you run these tests in the new Chrome browser for the iPad the speeds drop much more.
I've read that Google is forced to use the UIWebview that is not accelerated by Apple's Nitro JavaScript engine. I've also read that Apple is pushing HTML5 but the demos only run in their own Safari browser.
What is the problem here anyways? The best target for my app is mobile yet even with great API's like D3.js and HTML5 standards like SVG performance is being pinched, is this just because Apple wants to hold up progress for their own agenda? Thats how it looks to me anyways. I'm not sure what these tests look like on Android? It would be great to know. If the tests would be positive maybe I will get rid of the iPad and just go with Android already.
The bottom line is that I'm just not sure if it is feasible to make my app using HTML5 technology due to these speed issues? I also have no interest in learning Objective-C as the future is going to HTML5. I believe in the web and its standards but it looks like they are being blocked. I'm very interested in knowing solutions to this dilemma.
iOS7 has notably bad performance animating SVG with JavaScript - although static SVG drawing is massively faster. We wrote a blog on the performance of the iOS7 release, which you can see for more gory details.
Update: iOS7.1 fixed the javascript animation performance problem. It's back to 50 fps
I found d3.js/SVG on my first gen iPad massively slower than running the same app on desktop browsers (FF/Chrome/IE 9+).
I wrote up the various improvements I attempted here: http://hivemindmap.blogspot.co.uk/2013/01/html5-and-interactive-graphs.html
Performance will usually be lower on mobile devices than on desktop kit. In general their hardware is less powerful (it's geared more towards low power consumption than outright speed) and they have a hell of a lot less RAM and storage to play with. Chrome on my desktop has multiple processors, 8gb RAM and a ludicrously powerful GPU at it's disposal. On my iPad it doesn't have anywhere near that level of power.
3rd party iOS applications (including Chrome) cannot use Nitro, that much is correct. I believe this is because Nitro is able to mark memory as executable and (for security reasons) 3rd party applications are not trusted to do that. Most HTML5 stuff will work in any browser on iOS (with the possible exception of Opera Mini). Canvas and SVG animation will be slower than in Safari because it's all driven by Javascript - again the lack of access to Nitro holds them back. This is no longer true: As of iOS 8 third party apps can now use the WKWebView framework which does have access to the same high speed javascript engine as Safari.
Native code will usually be faster because it's much closer to the hardware, hitting the display APIs directly, rather than going through the web stack.
The solution is usually to simplify everything. In the same way that native game developers had to massively reduce the complexity of their 3D games to make them work on iOS devices, so web developers have to reduce the complexity of their SVGs and canvas apps. Less stuff flying around the page means higher performance, in general.
There's a number of tricks you can do, and a lot of reading around the subject. Have a read of http://www.html5rocks.com/en/tutorials/canvas/performance/, http://www.html5gamedevs.com/tag/performance/, and the rest of Google. Personally I'd build a proof of concept and test it before completely abandoning the idea :)
We've just released an app using the Crittercism framework. After some time, we've had about 125K app loads, and 95 crashes - a rate of less than 0.08%.
One crash happened 19 times, another 10, but the other 41 all occurred 3 or less. If there were any major problems with the app, I would expect to see significantly more failures in particular areas, so I'm happy with the level of figures I'm seeing.
A quick look shows many of them to be low level failures, not obviously caused but programmer error.
Examples
The largest group are all to do with CFNetworking on a background thread while static HTML is being being rendered in a web view on the main thread.
There are some KVO failures in free_list_checksum_botch
But my question is, in a sufficiently complex OS (iOS in this case), with a sufficiently complex app (which I think it is), should I, as a developer, expect to see this level of "background noise"?
Should I expect to see one app crash per 1-2000 loads, just because the OS isn't perfect? Has anyone else had a similar experience?
(I'm not looking for solutions to the errors themselves.. thanks!)
Crittercism conducted an analysis on app crashes. Their report was based on Android vs iOS crashes.
They concluded that the most popular apps on iOS crash 0.51% of app launches. So #Ashley Mills, if you're getting 0.08%... you're doing well. (i think I have my figures correct, anyway).
Not sure where the original report is, but I read it here:
Forbes app crash rates, conducted by Crittercism
Actually another shot in the dark non-technical answer could be. What added value will it bring you (the developer) to keep digging into that particular issue, when you could be spending more time and effort either developing more capability within your tool, or another tool completely.
If your app is simply for fun and learning, then I could see digging into this issue as a fun adventure. From a business perspective, what is your time worth and is figuring out this 0.08% problem going to sell enough (more) copies to make your efforts worth it.
An analogous would be, what requirements are essential, and what requirements are desirements?
Just food for thought. I know many of the companies I have worked for don't see the value in stressing about that low of a yielding bug.
I am an iOS developer, employed professionally. I take it personally when my apps crash, because that is not the user experience I was aiming for. A crash is a bad user experience. One crash, per user, is too many. A crash is a bug.
That being said, I have definitely seen crash logs that appear to be unsolvable because they seem to be indicating a problem way down deep in the SDK. What I have learned, however, is that more than likely there is something about my own code that is ultimately the cause.
There are any number of bizarre crashes that can be caused by timing issues between threads or blocks or just because I did something wrong. Just recently I discovered I was doing something entirely wrong with respect to a complex table I was updating. The crash logs for this problem provided almost no clues except for the general area of code I might look at. As I dug into the code and started experimenting, I realized my mistake, which ultimately was a timing issue caused by what I thought was a clever separation of main-thread vs. non-main-thread activity. I was too clever for my own good, in this case. :-)
So, to sum up:
One crash is too many crashes and ultimately a bad user experience.
Often, bizarre low-level crashes are the result of your own code's complexity and possibly timing issues there in.
Finally, I offer this question to consider:
Are you willing to piss off or dismiss some of your users simply because they fall into the 0.08% of users experiencing crashes?
Food for thought. :-)
I'm a professional iPhone developer, and what I've seen is the crash frequency isn't what upsets users, it's the funnel for how the crashes happen.
If they are intermittent you are usually okay, the problem starts to occur when one user experiences a specific crash multiple times. This is unacceptable.
Striving to remove every crash is always a good thing, but in many cases it's simply not realistic, you have to decide where your time is best spent. If you have the opportunity to rework a portion of the UX flow or fix an intermittent crash, you need to decide which one benefits more users.
The important thing to remember is, if you choose not to fix a crash that happens 0.08% of the time, you aren't writing off the users experiencing it unless they are experiencing it multiple times.
Although not a technical answer, on my iPhone I'd personally expect to have an app I use a lot crash at least once or twice over a year. I'd say that level is perfectly acceptable, and since generally I find they crash a lot more on the first time you start it I believe it's something to be expected.