I am developing a mobile app with the AppMobi tools and xdk. If I make a call to (accepts POST only) http://mg.smartmax.com/sightmaxwebservices/sightmaxwebservice.svc/jsoperator/TestjqMobi
The returned json fails parsing on iOS only (android works fine). This same call works fine in mobile safari, but it seems when its called from the app, it takes a different path and errors. This seems to be a known issue and was wondering if anyone had a good workaround?
I work at appMobi - this appears to be a bug with the native container in iOS. Have you tried building your app and testing (app*lab doesn't have the latest code base).
What are you using to parse the JSON? Something like
var obj = JSON.parse(data);
As a workaround for now I suppose you could just include and use another parser.
Make sure that your server is properly encoding the JSON.
I ran into this exact same issue. If you are using Drupal as your backend, use their function drupal_json_encode instead of PHP's json_encode. The information I was passing to the app was generated by a WYSYWIG editor, and perhaps that is what drupal's json encoding function takes into account that php's json encoding doesn't.
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I have gone to https://try.jsonata.org/ and copied the addresses json file. I have entered into my code the expression on the right side and run my app. I do not get the result in my app that is shown in https://try.jsonata.org/. So, I know this is a very generic question, but is there anything "special" I need to do to get JSONata to work in an Electron app?
Turns out that I was evaluating the stringified JSON. Once I evaluated on the actual JSON object, everything worked as expected.
I'm trying to create a webview with the capability to block/redirect certain urls requested inside the webview (not just the page url, but also the requests sent from the page, think of it as what a browser extension is able to do).
After some research, the closest I get was this Swift/Obj-c approach of use NSUrlProtocol: https://www.raywenderlich.com/2292-using-nsurlprotocol-with-swift, and the doc of the native-webview-ext mentioned something about WKURLSchemeHandler https://github.com/Notalib/nativescript-webview-ext .
I'm new to mobile development and this feature is crucial for my project. I wonder if anyone has experience building this out in NativeScript, I hope I don't have to convince my team and my boss to write this in Swift instead :(.
As you see in the webview-ext plugin docs, it does support overriding resource urls. Refer the registerLocalResource method.
Just in case, even if that is not supported you don't have to write your whole project in Swift as you can always access all native apis from JavaScript / TypeScript itself, read more about it here.
The App that I'm working on requires to parse a very big Json file (17.5 MB or 17mil characters).
I have coded and tested the App using smaller Json file and was successful doing the parsing, Only when I test using that 17.5 MB file it returns me null object.
I'm using iOS 5.1 and used JSON reader API of iOS 5.0 as well as JSONKIT which both return the same response, NULL.
Any advice would be highly appreciated
Thanks
If it is really a size problem you might break it into pieces on some natural boundaries. I have done that with large xml files in the past with good results.
But as #Alladinian mentions in the comments do verify that it is a valid JSON file.
fwiw, i recently uncovered a bug where NSJSONSerialization fails when the JSON file being parsed is > 32k in size. when we trimmed the source JSON down, the same code path works just fine.
Till now i was using SDK 5.0 and was able to dispaly local html text using net.rim.device.api.browser.field2.BrowserField but now my requirement has changed and have to use SDK 4.6. The problem is that now i'm getting compiler error for the BrowserField. Can anyone help me in displaying HTML text in SDK 4.6
As there is no BrowserField class supported in earlier versions of RIM SDK, you can launch local browser session for a html file, embedded in your cod-application.
Let say your application cod name is mymodule.cod
And you have attached a document.html file to your project, and this file is located in your source code folder, not outside.
You can launch browser session via this code:
BrowserSession session = Browser.getDefaultSession();
session.displayPage("cod://mymodule/document.html" );
Note, that module name is case sensitive.
And note that it is not documented way to access local html files.
If you are going to test this in simulator, make sure that MDS simulator is launched and is working.
It is still possible to display local HTML content with the APIs available for earlier BlackBerry OS versions. It is just a bit more complicated to make it work. Doing this involves the older BrowserField API (as opposed to the newer BrowserField2 API you've already discovered). I think the SDK includes a "BrowserField" example app that partially demonstrates this. It involves using the RenderingSession class to retrieve a BrowserContent object, which has a method to return a UI Field that you can actually show within your screen.
The trick is that RenderingSession expects you to supply it with an HttpConnection (or InputConnection) that it can read the data from. Since these are interfaces, you just have to implement them in such a way they they return your own HTML data instead of wrapping an actual HTTP connection.
It may be a little specific to the context of my own application, but here is an example of a class I wrote that wraps this API for local HTML content display: BrowserFieldRenderer