I know that Apple's terms for apps disallows downloading and executing code, but there seems to be an exception for JavaScript running in a UIWebView:
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework.
Does this mean that I can download and execute interpreted code, as long as it runs in a UIWebView?
I am developing an MMO, for which I would like to allow mods. It would have clients for iOS, Android, browsers, and eventually native desktop clients. I would do it entirely in the browser, but iOS doesn't support WebGL.
Is there a way to do this without violating the license agreement? I would really like to see a full-featured version on iPad, and I would be willing to put these mods in the app store so they can be reviewed, if that's possible.
These mods would be pretty simple, but more complicated than a data file could offer.
Yes. You simply download the Javascript and put it inside script tags using a UIWebView's loadHTMLString:baseURL: method, and then getting the result of various function calls using stringByEvaulatingJavaScriptFromString: method. You'd have to define an API where your game would query specific functions in your addon, but that should be pretty easy.
In fact, you may not even need to put the UIWebView in a view anywhere - you could simply instantiate a UIWebView*, load the javascript, and make the calls.
You are correct that downloading and interpreting Javascript is acceptable.
The Facebook and Gmail apps, as well as countless others, do this.
Related
I've an electron app the start time of which is very slow - 20-30 seconds - when it runs for the first time after packaging. Subsequent times it's run the start time is 1, 2 seconds. Either; are there any thoughts on why this might happen or; are there any tools available that I might use to track the source of this.
macOS
Electron uses Chromium (Used By Google Chrome), maybe that's why when your application starts for the first time it takes time to make cache and other stuff, it also depends from Computer to Computer.
Some of the reason i've listed from the articles below.
Modules
for example you wanted to do some stuff but you are lazy and search for a module on which can do the work for you, i have no problem with that but sometimes modules have their own dependencies and those dependencies might have their own dependencies these dependencies can effect your start up time as "require" or "import" will load everything up which can cause your code be very big than it would've been if you wrote it yourself or downloaded a optimized small library to do same thing.
Using Synchronous Code
see i personally don't like the promise tree (the list of .then for handling asynchronous code) but if i use await or something it probably block my main process which can cause my application to freeze, that's why it's preferred to use promises.
Using Old APIs
In modern versions of chromium there might be better APIs for handling stuff which might be slow if you used old APIs.
Over all you don't need to worry if you're code will work on other browsers or not (until you're also making a web version of that too), because latest electron version will introduce latest APIs which will be shipped to your end users so don't worry if your code will work or not.
You Can Read These Articles Below Which may help you to increase your applications Performance:
How to make your Electron app faster - DEV.TO
Performance - ELECTRONJS.ORG
Why are desktop apps made with electron js framework slow? - QUORA
Similar to remote debugging with iOS(using Safari) or Android(using Chrome), I'd like to do the same thing with Argon.
I assume you mean debugging argon.js apps using Argon4, the current version of the iOS app (at http://argonjs.io).
Like other apps that use Apple's built-in WkWebView, you can't use a remote debugger, since Apple won’t allow the remote debugger to work for any app except mobile safari. Which makes sense, since there are lots of technologies for building mobile apps using web tech, and people don’t want folks poking around inside their apps.
When developing a website using argon.js, if you are doing geospatial AR (essentially, anything that doesn't use Vuforia), you can just run the app in mobile Safari and use the remote debugger as you might hope.
My general approach is to developing and debugging with argon.js on Argon4 is:
first pass through, I debug on desktop in Safari or Firefox or Chrome (so I get the desktop debugger of my choice). This helps find many of those annoying little errors and typos. Take a look at some of the samples, such as the Vuforia samples, which re-orient the content to ensure it's visible even when there is no Vuforia running. I did this explicitly to enable me to see the content and debug.
second pass in Argon4 (since I built the app myself during development, I can do remote debugging), but you could use mobile Safari something that's closer to Argon, and still get remote debugging.
finally, I test in Argon4 itself. You can use the console to print things to, look for errors and so forth. Not idea, I know.
FYI you may find http://vorlonjs.com/ is useful for remote debugging an app while running in Argon.
I've been recommended Vorlon.js and jconsole.com for this, any other suggestions/ideas are welcome.
I have just tried to run
meteor run ios
That command emulates my application as an app. But there is just one page that would be interesting to have as an app. Can you control this in some way?
I don't think this is possible. The whole app gets exported regardless of platform, hence the universal/isomorphic apps concept. And in the universal app concept is one that I'm starting to find fault in. That said there is a better middle ground.
We'll call it sudo-universal apps. (probably a horrible name, but whatever :D)
Essentially the concept is that you have 3 codebases, for each device (web/ios/andriod) but share many of the same modules via something like npm, or potentially some other way of sharing code.
Then you can focus on the ui for each device and its strengths and weaknesses, but keep all the important logic you've built.
Check out the following:
https://voice.kadira.io/say-no-to-isomorphic-apps-b7b7c419c634#.3bn5ovts1
https://forums.meteor.com/t/say-no-to-universal-apps/16813/7
Hope this helps!
You can check whether the client code is executed on iOS or not, and change the app accordingly:
if(navigator.userAgent.match(/(iPad|iPhone|iPod)/g)) {
// Disable the links, and redirect to which page you want
}
But Justin's answer is great, a new platform usually needs more than just some tweaks. A quickly developed app has very low value for the user.
I am new To Intelxdk and want to know whether I can achieve the points.
Handle limited/no internet connection case
Upload file from file manager to the server
Sqlite connection, execute queries(select,add,...)
Navigate between screens using variables(Ex : user_id)
Apply UI design, and handle multiple resolutions for each platform
Download file from server to device
Use maps for a given longitude and latitude
Swipe images by fingers
Package the app for Android & iOS
Push notification configuration
Capture image from camera, save it, and upload it to server
Share text to social networks(Facebook,Twitter) using their apis
Share text to social networks using intent
Call XML webservice, and parse response
Call SOAP webservice, and parse response
Handle device rotation(landscape)
Sorry for big question,
anyone who has any details about all or one of those points. Please let me know,
I will be grateful.
I've also answered this on our forum...
Please see our demo apps and documentation for answers to your questions. I'll try to provide some quick answers below.
Many of your questions presume the XDK is providing platform services -- please note that the XDK provides debug and build services that put your HTML5 code into an embedded webview (an embedded browser window), where many of the features and functions depend on what is available in the embedded webview. This embedded webview container includes JavaScript API "extensions" that provide access to device resources that you normally would be restricted from using in a standard browser, such as access to device features and contacts, but, in general, if you can do something in a browser you can do it in the webview.
Also, keep in mind that the resources available in a webview on a mobile device (memory and CPU) are much more limited than what you are used to on the desktop browser. The desktop browser has nearly unlimited resources, that is not the case with a mobile device. You must design your app to be "lean and mean" for best results. Do not include large numbers of CSS and JS files, especially if you are only using one or two elements within those included apps.
1-Handle limited/no internet connection case
An XDK apps does not require a network connection. If your app uses a network connection it is up to you to determine the behavior when there is limited or no network connectivity. If you only try to access the network when the network is available...
2-Upload file from file manager to the server
There is no such thing as a "file manager" on a mobile device. How you locate and upload files is very device dependent and how you choose to upload them to a server is also up to you to decide. There are standard HTML5 techniques and a few APIs that can help.
3-Sqlite connection, execute queries(select,add,...)
Again, this is device/target platform dependent, it is not dictated by the XDK.
4-Navigate between screens using variables(Ex : user_id)
In general, we advise against using multi-page apps, due to JavaScript context changes, inter-page reload times and resource requirements. Single-page apps that use hidden divs to represent multiple pages tend to work better in this environment, especially if you are new to writing such apps.
5-Apply UI design, and handle multiple resolutions for each platform
Again, this is completely under your control, how well you can master things like media queries and such. The App Designer tool can help you tremendously in this regard, but it is NOT required. If you have your own layout tools you can use them and utilize the HTML/CSS they generate in your project. Or, you can write your layout by hand. For example, if you like to use Zurb Foundation as a responsive web design tool you can use it here.
6-Download file from server to device
Again, what you can do with that file when you get to the device is platform dependent.
7-Use maps for a given longitude and latitude
Not XDK dependent, use whatever network mapping service you prefer. You can get Lat and Long numbers by using the geo APIs that are extensions to the normal webview.
8-Swipe images by fingers
XDK does not dictate how you handle touch events, this is up to you to design how such events and actions are handled.
9-Package the app for Android & iOS
We provide packaging services for Android, iOS and several other mobile targets.
10-Push notification configuration
There is a push notification service built-in from AppMobi. However, we are moving to a 100% compatible Cordova contain that will allow you to (in the near future) include any push notification service that has the appropriate Cordova plugin.
11-Capture image from camera, save it, and upload it to server
There are APIs present for such actions.
12-Share text to social networks(Facebook,Twitter) using their apis
These can all be done using standard HTML5 programming techniques and do not require special services from the XDK.
13-Share text to social networks using intent
Intents depend on the specific platform.
14-Call XML webservice, and parse response
Use your favorite JS library to parse XML data, the XDK does not restrict this.
15-Call SOAP webservice, and parse response
Again, if you have a favorite JS library to parse SOAP data, the XDK does not restrict your use of such a library.
16-Handle device rotation(landscape)
Events are present in the standard webviews (precise behavior varies by platform) to help you deal with rotation.
I'm writing something that I want to release as both a chrome extension and a firefox add-on.
The chrome extension is already available on github. I've factored my code into several modules using a module load format similar to what requirejs uses; I did this to separate the parts that were chrome-specific from the parts I hoped to re-use in the firefox add-on.
Specifically, I split up not only the backend work, but also the content scripts.
In chrome, when my content script needs to load another module, it sends a message to the background page saying "please load this module"; the script on the background page then does:
function onLoadLibrary(request, sender, sendResponse) {
var allFrames = request.allFrames || false;
chrome.tabs.executeScript(
sender.tab.id, {file: request.library.toLowerCase() + '.js',
allFrames: allFrames},
function () {
sendResponse({});
});
return true;
}
That is, I'm able to load additional javascript into the same sandbox as the content script that asked for that code. This is necessary to make module dependencies work.
In firefox, I can't figure out how to do this. I'll attach my initial content scripts through pageMods and by calling tab.attach from the "ready" event of tabs. That seems straightforward, but then if that content script needs to load more code I can't see how to do it.
There doesn't seem to be a way to access the sandbox my content script is running in from the main.js file so that I might inject more code into it. Even if I somehow kept a reference to the relevant tab instance (which only lets me inject into the top frame in any case), it appears that each new call to tab.attach puts injected code into a new sandbox. The object tab that's passed to my ready event handle isn't a real XUL tab that I could pass to require("tabs/util").getBrowserForTab; if it were, then I think I can follow through enough of the sdk code to create my own sandbox, though I'd worry about leaving accidental memory leaks behind.
I considered passing the code back to the content script through a "eval-this-code" message, but I really don't want to use eval in my extension because of security concerns; I also worry that using eval would make it difficult to impossible to get my firefox add-on approved for AMO. (Also, how would that interact when my add-on runs on sites with a Content Security Policy?)
The usage of traits to define the add-on API seems to close off access to objects such that I can't reach inside a Worker to get a reference to the sandbox my content script is executing in. At this point, it appears that I'd need to include nearly a full copy of the sdk in my add-on just to expose one method on WorkerSandbox.
Note: I'm using the Add-On sdk (the project formerly known as JetPack). I'm willing to use Components.utils.import if someone can tell me how to use that from inside an Add-On SDK-managed content script.
Content-scripts do not expose a public API to attach more scripts to a content-script sandbox after it was initialized. You should probably file an enhancement bug and state your use case, if there isn't one filed already (search first), and/or even come up with some patches yourself.
In cases where there is a DOM that your add-on own (widget), then it's just a matter of attaching another script tag.
For things like page-mods where there is no DOM you own, you're left with a couple of options, none of which is really satisfying. As you already found out yourself, the use of traits prohibits you from accessing "private" properties/methods.
Fork page-mod/tab/content-worker to provide the functionality you need. That would require creating your own copies of the modules and expose the necessary APIs to inject scripts into existing workers.
This is has a steep learning curve (but given that you already figured out details such as traits, should be doable for you), but more importantly hard to maintain as you need to make sure you keep up with the upstream. And AMO editors will not like you very much for it :p
On the plus side, you could try to get your stuff committed upstream, fixing this problem for everybody and become a hero to many authors using the Add-on SDK.
The eval method you propose. Not only is this eval a major source for security issues, but it also may be a performance killer, as right now IIRC evaled code will not use the JIT. And, of course, it will make us AMO editors cringe, even if used "correctly".
Do not use lazy loading at all, and specify all content scripts from the very beginning. This is what add-ons usually do (I'm almost inclined to say "always"). However, this conflicts with your current design, and depending on your add-on may pose a serious performance penalty for loading stuff you didn't really need in the end.
You could use the require mechanism to have most scripts as SDK module and not content-scripts. This is not always feasible, of course, e.g. when dealing with code that would normally modify the DOM in your content-script, but might work for some other stuff.
Replace page-mod, etc with your own Greasemonkey-like, enhanced API. This means lots of work, it is error-prone, security-sensitive and has to be maintained. So, it's not really a viable solution, IMO...
Components.utils.import does not help you. It isn't available to content-scripts anyway.